Subject: [core] Martin Stiemerling's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS)

From: "Martin Stiemerling" <[email-masked]>
Date: Fri, 15 Aug 2014 07:14:51 -0700

Martin Stiemerling has entered the following ballot position for
draft-ietf-core-groupcomm-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have no general objection to this draft being published, but I have a
doubt about the normative language used in this informational draft. What
does it mean that an informational draft is using RFC 2119 language to
describe how CORE is being operated for multicast?

My confusion started in Section 2.5. Is this solely repeating what's
anyway specified by CORE or is it giving different advice? Or is it
trying to override the CORE spec? What is happening if there are
inconsistent guidances?

I am not yet through with the whole document, but I would like to get a
clarification about the above point before doing any further review of
the draft.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 15 Aug 2014 11:21:19 -0400

Hi Martin,

Thanks for the review.  With regards to your question:

> My confusion started in Section 2.5  Is this solely repeating what's

Response
------------
First some background.  If you look at RFC 7252, then you will see that
the main CoAP over IP multicast processing protocol operation is
concentrated in section 8.  There is also some other scattered
references to multicast processing in some other sections (e.g. section
4.8 & Appendix A).  However, the WG felt early on that there was not
enough explanatory and guidance information in RFC 7252 for someone to
correctly implement a complete CoAP over IP multicast system (i.e. CoAP
group communication).

So, we wrote the groupcomm document with the principle of strictly
following RFC 7252 rules, and then providing extra guidance in the areas
where RFC 7252 was silent or vague.  So to answer the first part of your
question.  As far as we are aware there is never contradictory advice
between the two documents.  We spent a lot of time in the WG verifying
this.  So I'm pretty confident about it.

For your specific question about groupcomm Section 2.5.  We put that
section because RFC 7252 did not have any clear guidance for the re-use
of Token values in the multicast case.  RFC 7252 only clearly specified
the unicast case of re-use of Token values.  So again there should not
be any contradiction, but only extra guidance.

Does that clarify things a bit?

(Please note that we had a separate but related question from the
Gen-Art reviewer (Ben Campbell) regarding the "management" interface we
specified in Section 2.7.  This was not specified in RFC 7252.  So the
question was whether an informational document like groupcomm should
specify a new management interface.  You can see my response in
http://www.ietf.org/mail-archive/web/core/current/msg05536.html ).

/Akbar

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Martin
Stiemerling
Sent: Friday, August 15, 2014 10:15 AM
To: The IESG
Cc: [email-masked];
[email-masked]; [email-masked]
Subject: [core] Martin Stiemerling's Discuss on
draft-ietf-core-groupcomm-21: (with DISCUSS)

I have no general objection to this draft being published, but I have a
doubt about the normative language used in this informational draft.
What does it mean that an informational draft is using RFC 2119 language
to describe how CORE is being operated for multicast?

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 18 Aug 2014 17:49:30 +0200

Hi Akbar,

> trying to override the CORE spec? What is happening if there are

I do see the point and also appreciate drafts that pull together the 
differnet pieces so that information becomes earier accessible for 
implementers.

> this.  So I'm pretty confident about it.

I can live with this and do believe that the group double checked this.

> be any contradiction, but only extra guidance.

Extra guidance casted in normative language in an informational draft 
makes we feeling really weird. This does not provide benefit, strictly 
speaking, as this RFC is not updating RFC 7252 with respect to the token 
handling in the multicast use, as it should, isn't it?

> Does that clarify things a bit?

Thanks for your prompt reply, but I do see the need for further 
discussions with your AD, as this draft is, at least, modifying the 
protocol behaviour of RFC 7252 in two places (Sections 2.5 and also 
2.7). But the draft is never saying this explicity.

Thanks,

   Martin