Re: [core] 🔔 WG Call for Adoption on draft-tiloca-core-multicast-oscoap

[Esko Dijk <[e-mail]>]

I also support the adoption of this draft as a work item for CoRE. Below are the results of a quick review, also.

Best regards
Esko Dijk


Overall comments – or work that the WG could take up next
·         Detailed example with message sizes would be useful. Since it’s important for multicast over 6lowpan performance that the IPv6 packets stay small enough (one 802.15.4 frame). At this moment, I can’t judge that yet easily based on the draft.
·         Normally, for applications (e.g. Building automation and lighting) groups do need a stable and non-random group ID, that identifies the group over time even as changes occur, e.g. members added/removed. The “Gid” in the draft however changes. There could be some text added to explain how Gid is linked to a stable ID. E.g., this could be configured by the Group Manager. The stable group ID is then not used over-the-wire for multicast OSCORE.
·         There is normative text in the Appendices; it could be clarified what the status of this is. E.g. only normative if one chooses to implement the optional element described in the Appendix?
I have a preference for avoiding normative text in the Appendices, but I’m curious to hear what others think.
·         The text sometimes suggests that a secure group context is linked to one and only one multicast IP address. In practice, there may be more variety – e.g. one multicast IP address plus one or more unicast IP addresses to which the group message is subsequently delivered. E.g. repeat of the group message to members which did not get it yet. The proposed solution could be reviewed with that view in mind, that there may be multiple (multicast/unicast) IP destination addresses to which a group message will be sent. I did not do that yet; can do so in a future in-depth review.

Section 2.1
Some things here are listed as out of scope, but they do come back later in the doc – such as forward security and backward security , which are addressed I think – certainly not out of scope.

Section 3
" Gid MUST be random " -> seems to contradict Appendix B which uses an Epoch counter in the Gid.  Should it say “MUST have a random component” ?

Appendices

  *   Appendix B, a concrete example instance is missing. E.g. “w3fj90f0a_0042” or its bstr equivalent  (just guessing here to the format)
  *   Appendix C, is this an example blueprint of how to do it – fully optional to follow or not follow this?

Minor

  *   ligthing -> lighting
  *   enpoint  -> endpoint
  *   Pg 25 , [I-D.ietf-ace-dtls-authorize] reference breaks across line and as such becomes non-searchable in the browser. And I like these refs to be searchable 😉





From: core [mailto:[e-mail]] On Behalf Of Jaime Jiménez
Sent: Thursday, November 23, 2017 17:59
To: [e-mail] WG ([e-mail]) <[e-mail]>
Cc: [e-mail]
Subject: [core] 🔔 WG Call for Adoption on draft-tiloca-core-multicast-oscoap

Dear all,

The draft on "Secure group communication for CoAP" ( draft-tiloca-core-multicast-oscoap<https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap/> ) had in room consensus for adoption during IETF99 already, now we are clear to confirm it on the mailing list.

Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment.

Target to end the WGA is 14th of December.

Ciao,
- - Jaime Jiménez


________________________________
The information contained in this email may be confidential and/or legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original email.