Subject: [core] AD review of draft-ietf-core-groupcomm-20, part 2

From: Barry Leiba <[email-masked]>
Date: Sat, 26 Jul 2014 12:49:45 -0400

And here's the rest of my review, Section 3 and beyond.

As with the others, please discuss these with me if you need to, and
tell me that you think I'm wrong about any that you think that way
about.

I'm going to put the document into "Revised I-D Needed" substate while
you work on addressing these reviews.

Barry, as AD

==========================
General:

The RFC Editor will probably get this, but as long as you're making
changes, note that correct use of "for example" and "e.g." has them
set off by commas.  Wherever you have "xxx, for example due to yyy",
it should be "xxx, due, for example, to yyy".

-- Section 3.2 --

   o  A large room (Room-A) with three lights (Light-1, Light-2, Light-
      3) controlled by a Light Switch.  The devices are organized into
      two subnets.  In reality, there could be more lights (up to
      several hundreds) but these are not shown for clarity.

Nit: make it, "but, for clarity, only three are shown."

-- Section 3.4 --

Nit: I would make items 3 and 4 in the numbered list be 3a and 3b, to
make it clearer that the second is an alternative to the first.

-- Section 3.6 --

   In our particular use case, a group of three lights is defined with
   one IP multicast address and hostname "Room-
   A-Lights.floor1.west.bldg6.example.com".  The commissioning tool has

The FQDN should not be split on multiple lines.  If you use xml2rfc, I
suggest coding it this way, to put it on a line by itself, indented:

      <list style="empty"><t>
      Room-A-Lights.floor1.west.bldg6.example.com
      </t></list>

-- Section 4.3 --

   It requires the RPL
   Mode of Operation (MOP) to be 3 (Storing Mode with multicast

Nit: As this is the only place you use MOP, there's no reason to abbreviate it.

On the other hand, you do need to expand DAO on first use.

-- Section 4.4 --

   2.  Manual configuration of edge router(s) as MPL Seed(s) for
       specific IP multicast traffic.  E.g. in above example, first
       configure Rtr-1 and Rtr-2 to act as MLD Address Listeners for the
       Room-A-Lights IP multicast group.

"E.g. in above example" is awkward (and you have that in another
paragraph, too).  Also, the paragraph is complicated.  I think it
would be clearer this way:

NEW
    2.  Manual configuration of edge router(s) as MPL Seed(s) for
       specific IP multicast traffic.  In the above example, this could be
       done through the following three steps: First, configure Rtr-1 and
       Rtr-2 to act as MLD Address Listeners for the Room-A-Lights IP
       multicast group.
END

-- Section 5 --
I really think the security aspects of this are horrid, and it's not
clear to me that this should be advanced, especially not at Proposed
Standard, as long as that's the case.  With questionable
authentication, questionable confidentiality, and apparently no access
control, I don't know that we should be proposing it now.  But is the
working group has consensus on doing so, I will send it to the
community and the IESG.  Were I you, I'd expect to get lambasted in
the SecDir review and by the Sec ADs.  Just a warning.

-- Section 6.2 --

The registration template changed in RFC 6838; please make sure your
filled-in template is aligned with that version.
==========================

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sun, 27 Jul 2014 02:12:24 -0400

Hi Barry,

Thank you again.  I  have given point by point feedback inline below
(identified by: **[Akbar-x]).   Please especially see [Akbar-7] and tell
us if you agree with our response.

As I mentioned previously,  we will do a fast update of the draft once
we have agreement with you on all your comments in this and your first
email.

Best Regards,

Akbar

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Saturday, July 26, 2014 12:50 PM
To: [email-masked]
Cc: core WG
Subject: [core] AD review of draft-ietf-core-groupcomm-20, part 2

Barry, as AD

The RFC Editor will probably get this, but as long as you're making
changes, note that correct use of "for example" and "e.g." has them set
off by commas.  Wherever you have "xxx, for example due to yyy", it
should be "xxx, due, for example, to yyy".

**[Akbar-1] - Ok.  Will make these global changes.

-- Section 3.2 --

**[Akbar-2] - Ok, will update as you suggested.

-- Section 3.4 --

**[Akbar-3] - Ok, will update as you suggested.

-- Section 3.6 --

      <list style="empty"><t>

**[Akbar-4] - Ok, will update as you suggested.

-- Section 4.3 --

   It requires the RPL

Nit: As this is the only place you use MOP, there's no reason to
abbreviate it.

**[Akbar-5] - Ok, will update as you suggested.

-- Section 4.4 --

"E.g. in above example" is awkward (and you have that in another
paragraph, too).  Also, the paragraph is complicated.  I think it would
be clearer this way:

NEW
    2.  Manual configuration of edge router(s) as MPL Seed(s) for
       specific IP multicast traffic.  In the above example, this could
be
       done through the following three steps: First, configure Rtr-1
and
       Rtr-2 to act as MLD Address Listeners for the Room-A-Lights IP
       multicast group.
END

**[Akbar-6] - Ok, will update as you suggested.

-- Section 5 --
I really think the security aspects of this are horrid, and it's not
clear to me that this should be advanced, especially not at Proposed
Standard, as long as that's the case.  With questionable authentication,
questionable confidentiality, and apparently no access control, I don't
know that we should be proposing it now.  But is the working group has
consensus on doing so, I will send it to the community and the IESG.
Were I you, I'd expect to get lambasted in the SecDir review and by the
Sec ADs.  Just a warning.

**[Akbar-7] - First, please note that this document (groupcomm) is
proposed to be Informational and not Proposed Standard.  As we stated in
section 1.2 (Scope), the normative aspects of group communications is
specified in RFC7252 (e.g. basic rules for multicast are in
http://tools.ietf.org/html/rfc7252#section-8 and for security in
http://tools.ietf.org/html/rfc7252#section-9.1 ).  The intent of this
groupcomm draft is just to explain/illustrate the normative rules of
RFC7252 which is fairly terse and sometimes a bit hard to understand
without a lot of background knowledge.  The only really "new"
functionality we are introducing is in section
2.7.2 (Membership Configuration RESTful Interface).  This functionality
for setting the group membership is not covered in any other CoAP
document.  Can you please confirm that an Informational document can
define the functionality included in section 2.7.2.  We have brought
this up in the WG several times and the answer was always positive.  But
we would like to ask you again.

-- Section 6.2 --

**[Akbar-8] - Ok, will update as you suggested.

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