Hi, Ben, and thanks for the review. Did you send it to the "dime" list by accident, instead of to the "core" list? In any case, would you please re-send it to include the "core" list (along with the other addresses as well, so that reply-all works)? Thanks.
Barry On Thu, Aug 14, 2014 at 4:20 PM, Ben Campbell <b...@nostrum.com> wrote: > 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. > > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
