Hi Ben,
>I understood one of the purposes of this draft is to clarify the usage of group CoAP. I think it's reasonable to expect such clarification to include(normative or otherwise) guidance on how to use it safely. I recognize that there is some guidance there already, but I think you could take a stronger position on some aspects. Response: ------------- Okay. I agree with that suggestion. We will update the text to make stronger recommendations as per your previous comments once we get the guidance from Barry about how to handle the normative text. Best Regards, Akbar -----Original Message----- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Tuesday, August 19, 2014 5:44 PM To: Rahman, Akbar Cc: gen-art@ietf.org; c...@ietf.org; draft-ietf-core-groupcomm....@tools.ietf.org Subject: Re: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 On Aug 14, 2014, at 5:12 PM, Rahman, Akbar <akbar.rah...@interdigital.com> wrote: > Hi Ben, > > > Thank you for your thorough review. Here is my initial feedback on > the two major issues that you raised: > > >> The draft contains significant material that I do not believe is > appropriate for an informational RFC, at least without some clear > explanations about why it appears. It purports to clarify the > normative stuff in RFC 7252 concerning multicast, but it does quite a > bit more than that. Section 2.7 defines protocol ... > > Response: > ------------- > The majority of the document is geared towards explaining how RESTful > group communications protocol should work based on the protocol > primitives defined in CoAP (RFC 7252). This was certainly the > original intent of the document (i.e. expand and explain CoAP group > communications protocol processing defined in RFC 7252 but do not > introduce any new functionality). Then at a late(r) stage of > development of the document, the WG decided that we should also include > some "management" aspects of CoAP group communications. This resulted > in addition of Sections 2.6, 2.7, 3.6, 6.1, & 6.2. The offending > (new) functionality is pretty clearly limited to these sections. > > Therefore, I think we have two possible options to address your comment: > 1) Remove Sections 2.6, 2.7 & 3.6 that focus on the management aspects > from the current document and spawn a new document (or potentially > migrate them to I-D.ietf-core-resource-directory if that makes sense). > 2) Change the status of the document from Informational to Standards > Track or BCP (and clearly indicate that the new functionality beyond > RFC > 7252 is introduced in Sections 2.6, 2.7, 3.6, 6.1, & 6.2). > > Ben/Barry - Can you give us some guidance here? I think this is really up to you and Barry, but I think either approach would be okay. Option 1 would allow you to treat different sections differently, which might have some advantage. If you chose option 2, Standards Track seems the better option as long as the new functionality is included. > > > > >> The security aspects of group CoAP are pretty bad. To its credit, the > draft does a pretty good job of calling that out, and that work is in > progress to improve it. But I have to wonder if we would be better off > not encouraging multicast CoAP at all until such improvements are > available. > > Response: > ------------- > Well, I think that we could definitely add stronger language > recommending not to use CoAP group communication until stronger > security solutions are developed in IETF. However, as you noted, the > fact is that RFC 7252 already allows the current unsecured CoAP group > communications. So I don't really appreciate how this could be a > blocking issue on progression of this document. I agree that 7252 already has this issue. It also has some normative language around not using it without some type of authentication, but IIRC it doesn't say much about protection from eavesdroppers or privacy issues. I understood one of the purposes of this draft is to clarify the usage of group CoAP. I think it's reasonable to expect such clarification to include(normative or otherwise) guidance on how to use it safely. I recognize that there is some guidance there already, but I think you could take a stronger position on some aspects. For example, you mention how the smart grid example may be high risk. It would be helpful to also point out how it by nature cannot be secured by the mitigation approaches mentioned in section 5, nor the minimal scope recommendation in section 5.4. Therefore, perhaps group CoAP should not be used for that application? > > > > Looking forward to your response, > > > Akbar > > > -----Original Message----- > From: core [mailto:core-boun...@ietf.org] On Behalf Of Ben Campbell > Sent: Thursday, August 14, 2014 5:06 PM > To: draft-ietf-core-groupcomm....@tools.ietf.org > Cc: gen-art@ietf.org Team (gen-art@ietf.org); c...@ietf.org > Subject: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21 > > (Oops, I screwed up the CC list the first try. Please send any replies > to this distribution. Apologies for the repeat.) > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-core-groupcomm-21 > Reviewer: Ben Campbell > Review Date: 2014-08-14 > IETF LC End Date: 2014-08-14 > IESG Telechat date: > > Summary: This draft is not ready for publication as an informational > RFC. It has some significant issues, detailed below. > > **** Major issues: > > -- The draft contains significant material that I do not believe is > appropriate for an informational RFC, at least without some clear > explanations about why it appears. It purports to clarify the > normative stuff in RFC 7252 concerning multicast, but it does quite a > bit more than that. > > Section 2.7 defines protocol, in the form of a RESTful methods and > attributes to manage multicast group membership.I agree in some cases > it makes sense for an informational RFC to define protocol. A common > example is when we want to document a proprietary protocol for some > reason. As written, this does not seem to fall unto such a case. If > the authors and working group believe it does, it would be helpful to > add text explaining that, and how the reader should interpret the section. > (I recognize that this interface is optional--but I don't think making > it optional changes whether it should be standards track.) > > In addition to that, the draft contains quite a bit of guidance that > might be more appropriate BCP. For example, there is guidance here > where not following it might do harm to the network. Additionally, I > don't see how anyone could expect to achieve interoperability the > multicast features of RFC 7252 without understanding this draft. (I > have to wonder why RFC 7252 did not have a normative dependency on > this draft.) > > -- The security aspects of group CoAP are pretty bad. To its credit, > the draft does a pretty good job of calling that out, and that work is > in progress to improve it. But I have to wonder if we would be better > off not encouraging multicast CoAP at all until such improvements are > available. Section 5.3 calls out some reasonable examples of > mitigation approaches, but I am a little concerned at the guidance > that one should worry about these for "sensitive" or "safety-critical" > data. People are not good at knowing what data is "sensitive" until it > gets used against them. I think this is especially true for IoT > applications where we have less deployment experience. > > Along those lines, the Pervasive Monitoring Considerations section > (kudos for having one, btw), tries to balance application needs vs > protecting information. But the smart-grid example seems to be a case > where the two are really at odds. I am afraid people will interpret > this along the lines of "well, the smart-grid application requirements > force me to send unprotected data all over the place", when I think > the right answer is "Group CoAP should not be used for this sort of > application until we can protect the data". > > > > > **** Minor issues: > > -- 2.2, 5th paragraph: "For sending nodes, it is recommended to use > the IP multicast address literal in a group URI." > > Can you elaborate on why? I can guess, but anytime we suggest using > literal IP addresses rather than DNS names, it's worth elaborating. > > -- 2.4: " ... if the resource being POSTed to has been designed to > cope with the unreliable and lossy nature of IP multicast." > > Can you elaborate on what it means to be "designed to cope..."? (Or > reference something that does?) > > -- 2.6: > > I think the Resource Directory reference needs to be normative. (I > see the discussion of this from Barry's AD review, where the authors > argued that the reference is optional for implementations. But our > definition of normative references also includes things necessary to > fully understand this draft. Fully understanding even optional > features is part of that.) > > -- 2.7.1, 2nd paragraph: > > Does this imply a need to coordinate pre-configured group addresses to > avoid collisions? > > -- 2.7.2.1: 2nd 2 last paragraph: > > Are there any scenarios where a missing port might be determined from > DNS, rather than just assuming the default? > > -- 2.7.2.6, 1st paragraph: "This operation MUST only be used to delete > or update group membership objects for which the CoAP client, invoking > this operation, is responsible" > > Do I understand correctly that this replaces the entire set? Is it > possible for two different clients to be responsible for two different > subsets? If so, how? > > -- 2.8 and (especially) 2.9: > > Lack of 2119 language in the "additional guidlines" seems inconsistent > with other parts of this draft that do use 2119 language. (I agree the > places where you talk about what 7252 already says should not use 2119 > language.) I can maybe see the difference for 2.8, but the > congestion-avoidance stuff in 2.9 seems as appropriate for 2119 > language as most anything else in the draft. > > (To be clear, I'm not suggesting more or less normative language--only > consistency in its use.) > > > > > **** Nits/editorial comments: > > -- Abstract: > > Please expand CoAP on first use in abstract. (But don't remove the > expansion in the body.) > > -- 2.2, 4th paragraph: " ... it is recommended ..." > > Was that intended as normative? > > Along those lines, I see a number of sections where 2119 words are > used in lower case where it looks like they were not intended as > normative (e.g., where you talk about normative requirements from RFC > 7252), but in other areas it's not as clear (like this one.) It would > be best to either avoid lower case versions of 2119 words, or make it > very clear whether they should be interpreted normatively or not. > > -- 2.7.2, 2nd paragraph: > > Wording is confusing. Do you mean MUST use the DTLS method, or MUST > use some method, with DTLS an option? Sentence seems to mean the > former, in which it would be more clear to say "MUST use DTLS as described in ..." > > -- 2.7.2.1, 3rd paragraph: > > Please expand JDON on first use. > > -- 2.7.2.1, paragraph after examples: > > You mention an optional port for "a" attributes, but not for "n" > attributes. The BNF for group-name seems to allow an optional port. > (and you mention an optional port for "n" later. > > > > _______________________________________________ > core mailing list > c...@ietf.org > https://www.ietf.org/mailman/listinfo/core _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
