Hi Ben,
Thanks for closing all the major issues. Below are Esko's and my responses to your remaining minor issues and nits (identified by "####[Author's reply]"). Please write back if you have any further questions. Best Regards, Akbar & Esko -----Original Message----- From: Ben Campbell [mailto:[email protected]] Sent: Tuesday, September 02, 2014 6:24 PM To: Rahman, Akbar Cc: Barry Leiba; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; The IESG; [email protected] Team ([email protected]) Subject: Re: New Version Notification - draft-ietf-core-groupcomm-24.txt On Sep 1, 2014, at 4:20 PM, Rahman, Akbar <[email protected]> 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. ####[Author's reply] - Thank you, Ben, for your very useful comments, and below are our responses to hopefully close your final issues. >[...] > >> >> >> **** 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.) >> ####[Author's reply] - We have moved the calling of the RD reference to 2.6.1.1. (Background- Member Discovery). We believe that the reference is truly informative because it falls under the "background" description (see paragraph 2, 3rd sentence) of the IESG reference below: https://www.ietf.org/iesg/statement/normative-informative.html >> -- 2.7.1, 2nd paragraph: >> >> Does this imply a need to coordinate pre-configured group addresses to avoid collisions? >> ####[Author's reply] - No more coordination is required then in any other application use of IP multicast. Whoever is provisioning (pre-configuring) the group information must of course ensure that they are provisioning the correct IP multicast address or FQDN. >> -- 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? >> ####[Author's reply] - Indeed, using SRV records or DNS-SD an IP address and the port number can be returned. So we will rephrase to: "If the port number is not provided, then the endpoint will attempt to look up the port number from DNS if it supports a method to do this (e.g. SRV records or DNS-SD). If port lookup is not supported or not provided by DNS, the default CoAP port (5683) is assumed." We would also need to add RFCs RFC2782 (SRV records) and RFC6763 (DNS-SD) as normative references. We can add this in the next update of the draft (after we hear back from the remaining IESG members). >> -- 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. > >[...] ####[Author's reply] - Yes, different clients can manage different subsets in the following way. Suppose client #1 has already written its subset of group membership objects to an endpoint. 1. Client #2 reads (GET) all current group memberships in one operation. The endpoint (server) generates an ETag (5.10.6.1. of RFC7252) for the resource. 2. Client #2 adds a number of group memberships to the read data object 3. Client #2 writes back the updated JSON object to the endpoint; using the earlier obtained ETag in the CoAP If-Match option (5.10.8.1. of RFC7252) to make sure that client #1 is not performing updates at the same time. Similarly, client #1 or #2 could add or delete group object that they manage. However there is no 'marker' or such in the group membership object defined to point out who is the owner. This could be done by using custom (proprietary) additional JSON key/value pairs within a group membership object. This all gets into implementation detail so we prefer not to add this level of information to the spec. >> >> >> **** 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. > ####[Author's reply] - We know that there are multiple views on how to do this. We decided to follow Barry's guidance as stated in: http://www.ietf.org/mail-archive/web/core/current/msg05593.html and http://www.ietf.org/mail-archive/web/core/current/msg05596.html >[...] > >> >> -- 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. >> >> >[...] ####[Author's reply] - To clarify, we could add the same text "(and optionally the port number)" also for the "n" key/value pair. We can add this in the next update of the draft (after we hear back from the remaining IESG members). >-- 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]). ####[Author's reply] - We believe that most of these are auto-generated by the xml2rfc tool. (Ignoring the ones in "Appendix B - Change Log" that were hand typed. But this section will be deleted before publication) Hopefully the RFC Editor will be able to do the required format changes when it gets to them. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
