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

From: [email-masked]
Date: Mon, 01 Sep 2014 14:12:15 -0700

A new version (-24) has been submitted for draft-ietf-core-groupcomm:
http://www.ietf.org/internet-drafts/draft-ietf-core-groupcomm-24.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-24

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 1 Sep 2014 17:20:49 -0400

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?  

Also, as a reminder:

- Kathleen's DICSUSS: Please see point 7 (of the change log of Rev. 22)
- Martin's DISCUSS: Please see points 8-9 (of the change log of Rev. 22)and point 1 (of the change log of Rev. 23).

Best Regards,

Akbar & Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 01, 2014 5:12 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification - draft-ietf-core-groupcomm-24.txt

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.

---

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

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 5 Sep 2014 11:12:42 -0400

Thank you for the additional text to expand the pervasive monitoring to
also include targeted monitoring threats.  The updated text looks great and
I cleared my discuss.

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

> - Martin's DISCUSS: Please see points 8-9 (of the change log of Rev.
> 22)and point 1 (of the change log of Rev. 23).
>
>
>
> Best Regards,
>
>
> Akbar & Esko
>
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> IETF Secretariat.
>
>

-- 

Best regards,
Kathleen

---

From: Badis Djamaa <[email-masked]>
Date: Wed, 10 Sep 2014 14:58:34 +0100

Hi Akbar,

I am reading draft-ietf-core-groupcomm-24.txt.

In the background section of the introduction you write:

"Constrained Application Protocol (CoAP) is a Representational State
Transfer (REST) based web transfer protocol for      resource constrained
devices operating in an IP network [RFC7252]."

I have a worry about the term "IP" in the above as CoAP can be deployed
over non-IP links such as SMS (CoAP over SMS draft:
http://www.ietf.org/id/draft-becker-core-coap-sms-gprs-05.txt)

best,
badis

On 5 September 2014 16:12, Kathleen Moriarty <
[email-masked]> wrote:

> On Mon, Sep 1, 2014 at 5:20 PM, Rahman, Akbar <
> [email-masked]> wrote:
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 10 Sep 2014 19:26:57 +0000

Hi Badis,

Thank you for your concern and question.  The current wording in the groupcomm-24 is correct (i.e. referring to running CoAP in an IP network).  This is because:

1)      Groupcomm-24 assumes CoAP runs over UDP over IP as per RFC7252 (section 3):

   “CoAP is based on the exchange of compact messages that, by default,
   are transported over UDP (i.e., each CoAP message occupies the data
   section of one UDP datagram) …  It could also be
   used over other transports such as SMS, TCP, or SCTP, the
   specification of which is out of this document's scope …”

        http://tools.ietf.org/html/rfc7252#section-3

2)      The draft that  you referenced (http://tools.ietf.org/html/draft-becker-core-coap-sms-gprs-05) is very interesting but it is not adopted as a WG draft yet.  Also, please note that even section 12 of that draft says:

   “Multicast is not possible with SMS transports.”

          http://tools.ietf.org/html/draft-becker-core-coap-sms-gprs-05#section-12

Best Regards,

Akbar

From: Badis Djamaa [mailto:[email-masked]]
Sent: Wednesday, September 10, 2014 9:59 AM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] New Version Notification - draft-ietf-core-groupcomm-24.txt

Hi Akbar,

"Constrained Application Protocol (CoAP) is a Representational State Transfer (REST) based web transfer protocol for      resource constrained devices operating in an IP network [RFC7252]."
I have a worry about the term "IP" in the above as CoAP can be deployed over non-IP links such as SMS (CoAP over SMS draft: http://www.ietf.org/id/draft-becker-core-coap-sms-gprs-05.txt)

best,
badis
On 5 September 2014 16:12, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
Thank you for the additional text to expand the pervasive monitoring to also include targeted monitoring threats.  The updated text looks great and I cleared my discuss.

On Mon, Sep 1, 2014 at 5:20 PM, Rahman, Akbar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Martin/Kathleen/Barry,

Also, as a reminder:

Best Regards,

Akbar & Esko

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, September 01, 2014 5:12 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: New Version Notification - draft-ietf-core-groupcomm-24.txt

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

IETF Secretariat.

--

Best regards,
Kathleen

_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core

---

From: Badis Djamaa <[email-masked]>
Date: Wed, 10 Sep 2014 21:58:49 +0100

Hi Akbar,

Thank you for the clarifications.

BTW, I have two other comments

- Page 8,

"However the port number is selected, the same port MUST be used
across all CoAP servers in a group and across all
CoAP clients performing the group requests."

I did not quite get it. I think there is a missing ", if": "However the
port number is selected,..." -> "However, if the port number is
selected,..."

- Page 11, paragraph 2, it might be better to reference DNS-SD (RFC 6763).

All the best,
badis

On 10 September 2014 20:26, Rahman, Akbar <[email-masked]>
wrote:

>  Hi Badis,
>
>
>
>
>
> Thank you for your concern and question.  The current wording in the
> groupcomm-24 is correct (i.e. referring to running CoAP in an IP network).
> This is because:
>
>
>
>
>
> 2)      The draft that  you referenced (
> http://tools.ietf.org/html/draft-becker-core-coap-sms-gprs-05) is very
> interesting but it is not adopted as a WG draft yet.  Also, please note
> that even section 12 of that draft says:
>
> *From:* Badis Djamaa [mailto:[email-masked]]
> *Sent:* Wednesday, September 10, 2014 9:59 AM
> *To:* Rahman, Akbar
> *Cc:* [email-masked]
> *Subject:* Re: [core] New Version Notification -
> draft-ietf-core-groupcomm-24.txt
>
>
>
> Hi Akbar,
>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 11 Sep 2014 03:53:34 +0000

Hi Badis,

Here is my feedback for your two comments:

- Page 8

"However the port number is selected, the same port MUST be used across all CoAP servers in a group and across all
CoAP clients performing the group requests."
I did not quite get it. I think there is a missing ", if": "However the port number is selected,..." -> "However, if the port number is selected,..."

[Akbar] – Okay.  I see now how it (i.e. in Section 2.3) could be misinterpreted.  We will re-word it.  What was meant was:

“Regardless of the method of selecting the port number, the same port MUST be used across all CoAP servers in a group and across all CoAP clients performing the group requests.”

- Page 11, paragraph 2, it might be better to reference DNS-SD (RFC 6763).
[Akbar] – Somehow, I think you must be seeing a different pagination scheme then I do on my screen.  Can you clarify exactly which Section number (and paragraph) that you are referring to?   Also, please note that we did have another (perhaps related?) comment on adding RFC 6763 in the Gen-Art comment resolution:

http://www.ietf.org/mail-archive/web/core/current/msg05604.html

---------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------

Best Regards,

Akbar

From: Badis Djamaa [mailto:[email-masked]]
Sent: Wednesday, September 10, 2014 4:59 PM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] New Version Notification - draft-ietf-core-groupcomm-24.txt

Hi Akbar,

"However the port number is selected, the same port MUST be used across all CoAP servers in a group and across all
CoAP clients performing the group requests."
I did not quite get it. I think there is a missing ", if": "However the port number is selected,..." -> "However, if the port number is selected,..."

On 10 September 2014 20:26, Rahman, Akbar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Badis,

Best Regards,

Akbar

From: Badis Djamaa [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, September 10, 2014 9:59 AM
To: Rahman, Akbar
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [core] New Version Notification - draft-ietf-core-groupcomm-24.txt

Hi Akbar,

best,
badis

Also, as a reminder:

Best Regards,

Akbar & Esko

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, September 01, 2014 5:12 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: New Version Notification - draft-ietf-core-groupcomm-24.txt

IETF Secretariat.

--

Best regards,
Kathleen

---

From: Badis Djamaa <[email-masked]>
Date: Thu, 11 Sep 2014 08:55:05 +0100

Thank you Akbar,

sorry for the confusion regarding the DNS-SD comment. Yes, it is the same
 as yours. I meant to add a normative reference for DNS-SD in section
2.6.1.2 ,  paragraph 3 of groupcomm-24 below:

For the second case, a CoAP endpoint may look up its group membership
using techniques such as DNS-SD
and Resource Directory [I-D.ietf-core-resource-directory
<http://tools.ietf.org/html/draft-ietf-core-groupcomm-24#ref-I-D.ietf-core-resource-directory>].

Best,
badis

On Thursday, 11 September 2014, Rahman, Akbar <[email-masked]>
wrote:

> [Akbar] – Okay.  I see now how it (i.e. in Section 2.3) could be
> misinterpreted.  We will re-word it.  What was meant was:
>
>
>
> “Regardless of the method of selecting the port number, the same port MUST
> be used across all CoAP servers in a group and across all CoAP clients
> performing the group requests.”
>
>
>
>
>
>
>
> [Akbar] – Somehow, I think you must be seeing a different pagination
> scheme then I do on my screen.  Can you clarify exactly which Section
> number (and paragraph) that you are referring to?   Also, please note that
> we did have another (perhaps related?) comment on adding RFC 6763 in the
> Gen-Art comment resolution:
>
>
>
> *Sent:* Wednesday, September 10, 2014 4:59 PM
> *To:* Rahman, Akbar
> *Cc:* [email-masked]

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 11 Sep 2014 18:56:37 +0000

Hi Badis,

Thanks for the clarification and your comments.  We have already agreed to add a normative reference to DNS-SD elsewhere in the document (due to the comment from the Gen-Art review).   We will try to send out an updated draft in the next 1-2 days.

Best Regards,

Akbar

From: Badis Djamaa [mailto:[email-masked]]
Sent: Thursday, September 11, 2014 3:55 AM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] New Version Notification - draft-ietf-core-groupcomm-24.txt

Thank you Akbar,

sorry for the confusion regarding the DNS-SD comment. Yes, it is the same  as yours. I meant to add a normative reference for DNS-SD in section 2.6.1.2 ,  paragraph 3 of groupcomm-24 below:

For the second case, a CoAP endpoint may look up its group membership using techniques such as DNS-SD
and Resource Directory [I-D.ietf-core-resource-directory<http://tools.ietf.org/html/draft-ietf-core-groupcomm-24#ref-I-D.ietf-core-resource-directory>].
Best,
badis

On Thursday, 11 September 2014, Rahman, Akbar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Badis,

- Page 8

>> -- 2.7.2.1<http://2.7.2.1>: 2nd 2 last paragraph:
>>

Best Regards,

Akbar

Hi Akbar,

Best Regards,

Akbar

Hi Akbar,

best,
badis

Also, as a reminder:

Best Regards,

Akbar & Esko

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, September 01, 2014 5:12 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: New Version Notification - draft-ietf-core-groupcomm-24.txt

IETF Secretariat.

--

Best regards,
Kathleen