Subject: [Gen-art] Gen-ART LC Review of draft-ietf-core-groupcomm-21

From: Ben Campbell <[email-masked]>
Date: Thu, 14 Aug 2014 16:06:25 -0500

(Oops, I screwed up the CC list the first try. Please send any replies to this distribution. Apologies for the repeat.)

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-core-groupcomm-21
Reviewer: Ben Campbell
Review Date: 2014-08-14
IETF LC End Date: 2014-08-14
IESG Telechat date: 

Summary: This draft is not ready for publication as an informational RFC. It has some significant issues, detailed below.

**** Major issues:

-- The draft contains significant material that I do not believe is appropriate for an informational RFC, at least without some clear explanations about why it appears. It purports to clarify the normative stuff in RFC 7252 concerning multicast, but it does quite a bit more than that.

Section 2.7 defines protocol, in the form of a RESTful methods and attributes to manage multicast group membership.I agree in some cases it makes sense for an informational RFC to define protocol. A common example is when we want to document a proprietary protocol for some reason. As written, this does not seem to fall unto such a case. If the authors and working group believe it does, it would be helpful to add text explaining that, and how the reader should interpret the section. (I recognize that this interface is optional--but I don't think making it optional changes whether it should be standards track.)

In addition to that, the draft contains quite a bit of guidance that might be more appropriate BCP. For example, there is guidance here where not following it might do harm to the network. Additionally, I don't see how anyone could expect to achieve interoperability the multicast features of RFC 7252 without understanding this draft.  (I have to wonder why RFC 7252 did not have a normative dependency on this draft.)

-- The security aspects of group CoAP are pretty bad. To its credit, the draft does a pretty good job of calling that out, and that work is in progress to improve it. But I have to wonder if we would be better off not encouraging multicast CoAP at all until such improvements are available. Section 5.3 calls out some reasonable examples of mitigation approaches, but I am a little concerned at the guidance that one should worry about these for "sensitive" or "safety-critical" data. People are not good at knowing what data is "sensitive" until it gets used against them. I think this is especially true for IoT applications where we have less deployment experience.

Along those lines, the Pervasive Monitoring Considerations section (kudos for having one, btw), tries to balance application needs vs protecting information. But the smart-grid example seems to be a case where the two are really at odds. I am afraid people will interpret this along the lines of "well, the smart-grid application requirements force me to send unprotected data all over the place", when I think the right answer is "Group CoAP should not be used for this sort of application until we can protect the data".

**** Minor issues:

-- 2.2, 5th paragraph: "For sending nodes, it is recommended to use the IP multicast address literal in a group URI."

Can you elaborate on why? I can guess, but anytime we suggest using literal IP addresses rather than DNS names, it's worth elaborating.

-- 2.4: " ... if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of IP multicast."

Can you elaborate on what it means to be "designed to cope..."? (Or reference something that does?)

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

-- 2.8 and (especially) 2.9:

Lack of 2119 language in the "additional guidlines" seems inconsistent with other parts of this draft that do use 2119 language. (I agree the places where you talk about what 7252 already says should not use 2119 language.) I can maybe see the difference for 2.8, but the congestion-avoidance stuff in 2.9 seems as appropriate for 2119 language as most anything else in the draft.

(To be clear, I'm not suggesting more or less normative language--only consistency in its use.)

**** Nits/editorial comments:

-- Abstract:

Please expand CoAP on first use in abstract. (But don't remove the expansion in the body.)

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

-- 2.7.2, 2nd paragraph:

Wording is confusing. Do you mean MUST use the DTLS method, or MUST use some method, with DTLS an option? Sentence seems to mean the former, in which it would be more clear to say "MUST use DTLS as described in ..."

-- 2.7.2.1, 3rd paragraph:

Please expand JDON on first use.

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

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 14 Aug 2014 18:12:44 -0400

Hi Ben,

Thank you for your thorough review.  Here is my initial feedback on the
two major issues that you raised:

>The draft contains significant material that I do not believe is
appropriate for an informational RFC, at least without some clear
explanations about why it appears. It purports to clarify the normative
stuff in RFC 7252 concerning multicast, but it does quite a bit more
than that.  Section 2.7 defines protocol ...

Response:
-------------
The majority of the document is geared towards explaining how RESTful
group communications protocol should work based on the protocol
primitives defined in CoAP (RFC 7252).  This was certainly the original
intent of the document (i.e. expand and explain CoAP group
communications protocol processing defined in RFC 7252 but do not
introduce any new functionality).  Then at a late(r) stage of
development of the document, the WG decided that we should also include
some "management" aspects of CoAP group communications.   This resulted
in addition of Sections 2.6, 2.7, 3.6, 6.1, & 6.2.  The offending (new)
functionality is pretty clearly limited to these sections.

Therefore, I think we have two possible options to address your comment:
1) Remove Sections 2.6, 2.7 & 3.6 that focus on the management aspects
from the current document and spawn a new document (or potentially
migrate them to I-D.ietf-core-resource-directory if that makes sense).
2) Change the status of the document from Informational to Standards
Track or BCP (and clearly indicate that the new functionality beyond RFC
7252 is introduced in Sections 2.6, 2.7, 3.6, 6.1, & 6.2).

Ben/Barry - Can you give us some guidance here?

>The security aspects of group CoAP are pretty bad. To its credit, the
draft does a pretty good job of calling that out, and that work is in
progress to improve it. But I have to wonder if we would be better off
not encouraging multicast CoAP at all until such improvements are
available.

Response:
-------------
Well, I think that we could definitely add stronger language
recommending not to use CoAP group communication until stronger security
solutions are developed in IETF.  However, as you noted, the fact is
that RFC 7252 already allows the current unsecured CoAP group
communications.  So I don't really appreciate how this could be a
blocking issue on progression of this document.

Looking forward to your response,

Akbar

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Thursday, August 14, 2014 5:06 PM
To: [email-masked]
Cc: [email-masked] Team ([email-masked]); [email-masked]
Subject: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21

(Oops, I screwed up the CC list the first try. Please send any replies
to this distribution. Apologies for the repeat.)

Summary: This draft is not ready for publication as an informational
RFC. It has some significant issues, detailed below.

**** Major issues:

-- The draft contains significant material that I do not believe is
appropriate for an informational RFC, at least without some clear
explanations about why it appears. It purports to clarify the normative
stuff in RFC 7252 concerning multicast, but it does quite a bit more
than that.

Section 2.7 defines protocol, in the form of a RESTful methods and
attributes to manage multicast group membership.I agree in some cases it
makes sense for an informational RFC to define protocol. A common
example is when we want to document a proprietary protocol for some
reason. As written, this does not seem to fall unto such a case. If the
authors and working group believe it does, it would be helpful to add
text explaining that, and how the reader should interpret the section.
(I recognize that this interface is optional--but I don't think making
it optional changes whether it should be standards track.)

In addition to that, the draft contains quite a bit of guidance that
might be more appropriate BCP. For example, there is guidance here where
not following it might do harm to the network. Additionally, I don't see
how anyone could expect to achieve interoperability the multicast
features of RFC 7252 without understanding this draft.  (I have to
wonder why RFC 7252 did not have a normative dependency on this draft.)

-- The security aspects of group CoAP are pretty bad. To its credit, the
draft does a pretty good job of calling that out, and that work is in
progress to improve it. But I have to wonder if we would be better off
not encouraging multicast CoAP at all until such improvements are
available. Section 5.3 calls out some reasonable examples of mitigation
approaches, but I am a little concerned at the guidance that one should
worry about these for "sensitive" or "safety-critical" data. People are
not good at knowing what data is "sensitive" until it gets used against
them. I think this is especially true for IoT applications where we have
less deployment experience.

Along those lines, the Pervasive Monitoring Considerations section
(kudos for having one, btw), tries to balance application needs vs
protecting information. But the smart-grid example seems to be a case
where the two are really at odds. I am afraid people will interpret this
along the lines of "well, the smart-grid application requirements force
me to send unprotected data all over the place", when I think the right
answer is "Group CoAP should not be used for this sort of application
until we can protect the data".

**** Minor issues:

-- 2.2, 5th paragraph: "For sending nodes, it is recommended to use the
IP multicast address literal in a group URI."

Can you elaborate on why? I can guess, but anytime we suggest using
literal IP addresses rather than DNS names, it's worth elaborating.

-- 2.4: " ... if the resource being POSTed to has been designed to cope
with the unreliable and lossy nature of IP multicast."

Can you elaborate on what it means to be "designed to cope..."? (Or
reference something that does?)

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

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?

Lack of 2119 language in the "additional guidlines" seems inconsistent
with other parts of this draft that do use 2119 language. (I agree the
places where you talk about what 7252 already says should not use 2119
language.) I can maybe see the difference for 2.8, but the
congestion-avoidance stuff in 2.9 seems as appropriate for 2119 language
as most anything else in the draft.

(To be clear, I'm not suggesting more or less normative language--only
consistency in its use.)

-- Abstract:

Please expand CoAP on first use in abstract. (But don't remove the
expansion in the body.)

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.

-- 2.7.2, 2nd paragraph:

Wording is confusing. Do you mean MUST use the DTLS method, or MUST use
some method, with DTLS an option? Sentence seems to mean the former, in
which it would be more clear to say "MUST use DTLS as described in ..."

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.

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 Aug 2014 16:44:26 -0500

> than that.  Section 2.7 defines protocol ...

I think this is really up to you and Barry, but I think either approach would be okay. Option 1 would allow you to treat different sections differently, which might have some advantage. If you chose option 2, Standards Track seems the better option as long as the new functionality is included.

> not encouraging multicast CoAP at all until such improvements are

I agree that 7252 already has this issue. It also has some normative language around not using it without some type of authentication, but IIRC it doesn't say much about protection from eavesdroppers or privacy issues. 

I understood one of the purposes of this draft is to clarify the usage of group CoAP. I think it's reasonable to expect such clarification to include(normative or otherwise) guidance on how to use it safely.  I recognize that there is some guidance there already, but I think you could take a stronger position on some aspects. 

For example, you mention how the smart grid example may be high risk. It would be helpful to also point out how it by nature cannot be secured by the mitigation approaches mentioned in section 5, nor the minimal scope recommendation in section 5.4. Therefore, perhaps group CoAP should not be used for that application?

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 19 Aug 2014 22:37:07 -0400

Hi Ben,

>I understood one of the purposes of this draft is to clarify the usage
of group CoAP. I think it's reasonable to expect such clarification to
include(normative or otherwise) guidance on how to use it safely.  I
recognize that there is some guidance there already, but I think you
could take a stronger position on some aspects.

Response:
-------------
Okay.  I agree with that suggestion.  We will update the text to make
stronger recommendations as per your previous comments once we get the
guidance from Barry about how to handle the normative text.

Best Regards,

Akbar

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, August 19, 2014 5:44 PM
To: Rahman, Akbar
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21

On Aug 14, 2014, at 5:12 PM, Rahman, Akbar
<[email-masked]> wrote:

> Hi Ben,
> 
> 
> Thank you for your thorough review.  Here is my initial feedback on 
> the two major issues that you raised:
> 
> 
> explanations about why it appears. It purports to clarify the 
> normative stuff in RFC 7252 concerning multicast, but it does quite a 
> bit more than that.  Section 2.7 defines protocol ...
> 
> Response:
> -------------
> primitives defined in CoAP (RFC 7252).  This was certainly the 
> original intent of the document (i.e. expand and explain CoAP group 
> in addition of Sections 2.6, 2.7, 3.6, 6.1, & 6.2.  The offending 
> (new) functionality is pretty clearly limited to these sections.
> 

> Ben/Barry - Can you give us some guidance here?

I think this is really up to you and Barry, but I think either approach
would be okay. Option 1 would allow you to treat different sections
differently, which might have some advantage. If you chose option 2,
Standards Track seems the better option as long as the new functionality
is included.

> recommending not to use CoAP group communication until stronger 
> security solutions are developed in IETF.  However, as you noted, the 
> fact is that RFC 7252 already allows the current unsecured CoAP group 

I agree that 7252 already has this issue. It also has some normative
language around not using it without some type of authentication, but
IIRC it doesn't say much about protection from eavesdroppers or privacy
issues. 

I understood one of the purposes of this draft is to clarify the usage
of group CoAP. I think it's reasonable to expect such clarification to
include(normative or otherwise) guidance on how to use it safely.  I
recognize that there is some guidance there already, but I think you
could take a stronger position on some aspects. 

For example, you mention how the smart grid example may be high risk. It
would be helpful to also point out how it by nature cannot be secured by
the mitigation approaches mentioned in section 5, nor the minimal scope
recommendation in section 5.4. Therefore, perhaps group CoAP should not
be used for that application?

> explanations about why it appears. It purports to clarify the 
> normative stuff in RFC 7252 concerning multicast, but it does quite a 
> bit more than that.
> 
> attributes to manage multicast group membership.I agree in some cases 
> it makes sense for an informational RFC to define protocol. A common 
> reason. As written, this does not seem to fall unto such a case. If 
> the authors and working group believe it does, it would be helpful to 
> add text explaining that, and how the reader should interpret the
section.

> might be more appropriate BCP. For example, there is guidance here 
> where not following it might do harm to the network. Additionally, I 
> don't see how anyone could expect to achieve interoperability the 
> multicast features of RFC 7252 without understanding this draft.  (I 
> have to wonder why RFC 7252 did not have a normative dependency on 
> this draft.)
> 
> -- The security aspects of group CoAP are pretty bad. To its credit, 
> the draft does a pretty good job of calling that out, and that work is

> in progress to improve it. But I have to wonder if we would be better 
> off not encouraging multicast CoAP at all until such improvements are 
> available. Section 5.3 calls out some reasonable examples of 
> mitigation approaches, but I am a little concerned at the guidance 
> that one should worry about these for "sensitive" or "safety-critical"

> data. People are not good at knowing what data is "sensitive" until it

> gets used against them. I think this is especially true for IoT 
> applications where we have less deployment experience.
> 
> where the two are really at odds. I am afraid people will interpret 
> this along the lines of "well, the smart-grid application requirements

> force me to send unprotected data all over the place", when I think 
> the right answer is "Group CoAP should not be used for this sort of 
> application until we can protect the data".
> 
> 
> 
> 
> **** Minor issues:
> 
> -- 2.2, 5th paragraph: "For sending nodes, it is recommended to use 
> the IP multicast address literal in a group URI."
> 
> -- 2.4: " ... if the resource being POSTed to has been designed to 
> cope with the unreliable and lossy nature of IP multicast."
> 
> 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:
> 

> congestion-avoidance stuff in 2.9 seems as appropriate for 2119 
> language as most anything else in the draft.
> 

> 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.
> 
> -- 2.7.2, 2nd paragraph:
> 
> Wording is confusing. Do you mean MUST use the DTLS method, or MUST 
> use some method, with DTLS an option? Sentence seems to mean the 
> former, in which it would be more clear to say "MUST use DTLS as
described in ..."
> attributes. The BNF for group-name seems to allow an optional port. 
> (and you mention an optional port for "n" later.
> 
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Aug 2014 17:02:47 +0300

Ben, Thank you very much for your on-spot review. I agree with your comments. And thank you Akbar for starting to address Ben’s questions.

I have also reviewed the draft, and observe that a few other ADs have raised the Informational classification as an issue as well. One of the suggested ways out of the issue is to re-classify the document as Experimental. Perhaps that might be a way forward, while being able to retain some of the protocol definitions/extensions that this document does.

I will not hold a Discuss on this document, because other ADs already do. However, I have a number of my own comments that you may consider if you find them useful. I’ll send them shortly.

Jari