Last Call Review of draft-ietf-core-groupcomm-21
review-ietf-core-groupcomm-21-genart-lc-campbell-2014-08-14-00

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.