On Sep 1, 2014, at 4:20 PM, Rahman, Akbar <akbar.rah...@interdigital.com> wrote:
> Hi Martin/Kathleen/Barry, > > > > We fixed one small but important point (in groupcomm-24): > > o Clarified in section 2.6.1.2 (Configuring Members) that ABNF rules > from Section 3.2.2 of [RFC 3986] should be used for the IP address > parsing. > > > Can you please review and tell us if you have any remaining comments on the > document? [...] Hi, Here's an update to my Gen-ART review at the IETF last call of version 21: Summary: This version is almost ready for publication as an experimental RFC. I think there are still a few minor issues and nits that might be worth considering prior to final publication. Note: Much of my original review has been addressed, especially through the move to experimental. I quoted comments from that review below. I removed those that did not seem to warrant further comment, and added a few additional comments. > **** Major issues: None. All major issues from my previous review have been addressed. [...] > > > **** Minor issues: > [...] > > -- 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? > It's more clear to me now that this replaces the entire set. It's still not clear if different clients can manage different subsets. [...] > > > **** Nits/editorial comments: [...] > -- 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. I see there is a new disclaimer in the 2119 section, pointing out that lower case words are not normative. Personally, I don't like that approach, because 1) It's confusing, and 2) lots of people ignore such disclaimers. But that's just a personal opinion, and I've seen an number of RFCs that do exactly this. [...] > > -- 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. > > [...] -- Additional Nit: You have several citations to RFCs that include a space in the tag (i.e. [RFC XXXX] ), while the references do not have the space (i.e. [RFCXXXX]). _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
