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:ben@nostrum.com] 
Sent: Tuesday, September 02, 2014 6:24 PM
To: Rahman, Akbar
Cc: Barry Leiba; mls.ietf@gmail.com; Kathleen.Moriarty.ietf@gmail.com;
core@ietf.org; core-chairs@tools.ietf.org;
draft-ietf-core-groupcomm@tools.ietf.org; The IESG; gen-art@ietf.org
Team (gen-art@ietf.org)
Subject: Re: New Version Notification - draft-ietf-core-groupcomm-24.txt


On Sep 1, 2014, at 4:20 PM, Rahman, Akbar
<Akbar.Rahman@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.


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