Subject: Re: [Gen-art] New Version Notification - draft-ietf-core-groupcomm-24.txt

From: Ben Campbell <[email-masked]>
Date: Tue, 2 Sep 2014 17:24:19 -0500

On Sep 1, 2014, at 4:20 PM, Rahman, Akbar <[email-masked]> 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]).

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 4 Sep 2014 15:27:18 -0400

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-masked]] 
Sent: Tuesday, September 02, 2014 6:24 PM
To: Rahman, Akbar
Cc: Barry Leiba; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; The IESG; [email-masked]
Team ([email-masked])
Subject: Re: New Version Notification - draft-ietf-core-groupcomm-24.txt

On Sep 1, 2014, at 4:20 PM, Rahman, Akbar
<[email-masked]> wrote:

>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.
>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 

>> 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.

>> 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.

>> 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 

>> 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.