[core] WGLC comments for draft-ietf-core-groupcomm-17

["FOSSATI, Thomas (Thomas)" <[e-mail]>]

Hi Akbar, Esko.

Good job with the document.  The “Use Cases” section is especially
enjoyable.

There are no major issues on my side; the following comments are mostly
editorial.

Cheers, Thomas.

Section 1.1

- httpbis has been sent to IESG for publication, I guess it's ok to
reference it instead of 2616;
- last para: it'd be super nice to have pointers to sections while topics
are enumerated;

Section 1.3

- "IP multicast" definition could be made a bit richer?  To me IP
multicast is not just a matter of addressing, is also the membership
management, the routing and forwarding, the abstraction built on top of
different L2 protocols.

Section 2.2

- first para: is it necessary for the two MAY's to be RFC2119?
- second para, last sentence: is there any reason why the "may also be
enabled" is not RFC2119?
- fourth para: it's not clear to me what the "group communication request
API" is
- fifth para: is the "It is recommended" meant to be RFC2119?
- last para: not clear what the use case for the reverse DNS mapping would
be.

Section 2.3

- isn't bullet 3. (i.e. use the default CoAP port) just a special case of
1. (i.e. pre-configured port number)?

Section 2.4

- I guess it's the unreliable (more then the lossy) nature of IP multicast
that makes POST unusable?

Section 2.5

- second para: it looks like the server can unilaterally decide to
suppress a response to a multicast request.  But there is no mention about
which conditions could trigger the actual response suppression.  A pointer
to Section 2.8 perhaps?


Section 2.7

- The title/name is very generic.  "Group Membership RESTful Interface"
(or similar) would be more easily and consistently referenced in
subsequent text (where it appears as "RESTful CoAP interface", and then as
"RESTful interface").
- first para: missing comma "[...] only as [...]" -> "[...] only, as [...]"
- second para: the "Thus only authorized controllers [...]" is not clear
to me: it seems to imply that DTLS provides authorisation, which it
doesn't.

Section 2.7.2.1

- the beginning of this section could have a small description of the
semantics, before going deep into syntactic details?
- second para: "A resource offering this representation": it's not clear
to me what "this representation" refers to;
- third para: "[...] in a format as defined [...]" -> "[...] in the format
defined [...]";
- problem with the defined syntax: it's impossible to specify a
non-literal group with a non-default port.  I'd suggest adding the
optional port to the non-literal format as well;
- fifth para: "SHOULD NOT be included if unknown" isn't this more a MUST
NOT?  What should I put into it if I don't know what to put into it?
Also, the preceding MUST sounds more like a SHOULD?

Section 2.7.2.2

- I'd add a note about the need for the Group index to be unique
- what happens when a client tries to register a duplicate "a"?
- last para: add context/rationale for the re-join requirement on POST of
an already registered

Section 2.7.2.3

- the "/" in  "/{+location}" looks redundant
- would be nice to have text that describes the actions that are to be
done by the server on successful deletion

Section 2.7.2.4

- the "/" in  "/{+location}" looks redundant

Section 2.7.2.5

- last para: add reference to RFC5952?

Section 2.7.2.6

- would be nice to have text that describes the actions that are to be
done by the server on successful update

Section 2.7.2.7

- first para: it's not clear what makes a CoAP client responsibile for the
group membership objects
- would be nice to have text that describes the actions that are to be
done by the server on successful update

Section 2.8

- It is said that the response suppression should be configurabile, which
is great.  But then why not allowing this via the "Group Membership
RESTful Interface"?

Section 2.10

- shameless plug: the "Multipart Content-Format Encoding for CoAP" I-D
could provide the aggregation format needed ;-)