Re: [core] Comments about draft-dijk-core-groupcomm-bis-00

[Esko Dijk <[e-mail]>]

Hello Jim,

Thanks again for your review. Below the responses of the groupcomm-bis authors ("[GC]") on your review comments. Some of these were already addressed in the -01 version. Others will be worked on for the -02 version.

Esko

-----Original Message-----
From: Jim Schaad <[e-mail]> 
Sent: Wednesday, May 29, 2019 00:45
To: [e-mail]
Cc: [e-mail]
Subject: Comments about draft-dijk-core-groupcomm-bis-00 

Comments on this draft.

1.  I have an existential problem with this document.  This is a standards track document that is claiming to do an update to an experimental draft.
However, this is something that I would not expect to be done and it is not clear just what the updates to that document are and how one would make
edits to that document in order to apply the updates.   My general
expectation for an experimental document is that it would be 1) declared a failure and killed, 2) declare a partial success and updated for a new experiment (and thus a new experimental document) or 3) declare a resounding success then replaced with either a standards or information document.  

[GC] After some discussion this was now resolved in -01 by obsoleting RFC 7390. Any relevant content that needs to be kept will be copied over into the new draft.

2.  You are claiming to update RFC 7641, but it is not clear to me what is being updated and just what the implications of doing this update are.  As an example of the types of thing that should be clarified are:
*  If a server does not return a response, should it setup to do a later observe operation?

[GC] The specific update to 7641 will be written more explicitly in -02. If a server does not return a response due to an error status in the request, then the server will not add the client to the observers list following RFC 7641. This case is not specified in our draft currently; this seems already covered by 7641.
If the server suppresses the first success response 2.xx ; and then adds the client to the observers list - that would be possible per the current text ,but strange. If a client wants to observe a resource value then the server better not suppress the response with that value. (This could be something to add).

*  More information on how correlation should be done with responses.  As an example, if you do unary observe and the response is routed through a proxy, there are no problems as long as the responses are not later re-routed through a new proxy.  However for multicast, if you have two different servers on the far side of a proxy how does one distinguish between the two of them if everything is coming through a single proxy?

[GC] The use of a proxy is now described in -01, section 2.2.3. (Independent of whether an Observe option is included or not.) Current statement is that a proxy SHOULD NOT process a multicast CoAP request due to these issues, unless a specific set of proxy capabilities can be ensured.

3.  The introduction does not acknowledge that the same thing can be done via pub-sub.  It is ok to declare this out of scope but it needs to be done in up front in the introduction (and probably also in the abstract).

[GC] The scope section 1.1 now mentions pub-sub, in -01. The abstract already mentions the UDP/IP-multicast transport scope so there's no need to list other approaches there that are not in scope.

4.  I am not sure that it makes sense to say one should be familiar with terms from Group OSCORE as one would expect this to be from the general to the specific for terminology not the other way around.

[GC] We have removed such a reader requirement.
In fact, before current Section 4, the only related terms used in the text are: “security context to decrypt and/or verify group messages”, in current Section 2.1.1;  “OSCORE group” and “cryptographic material”, in current Section 2.1.4. It should be fair to expect any potential reader to grasp them for understanding that section.

5.  In section 2.1.1 - you should state that the centralized directory would be pre-configured in the device.

[GC] In -01 we have moved the use cases to Appendix A; and added to A.1.1 this: “This requires that the address of the central directory is either preconfigured in each device or configured during operation using a protocol.”
(For example, draft-resource-directory defines the RDAO option to distribute an RD address via ND data.)

6. In section 2.1.1 - Do we have any set of properties that are commonly defined for doing this?  Services in the form of resources are easy to understand but I don't know how to do this easily.

[GC] In -01 some pointers to relevant specifications are added; RFC 6690/7252. Using CoRE Link Format attributes a single resource can be hosted on a CoAP server that represents the device, i.e. a single service which provides descriptors for the hosting device itself. It could be a “root” resource that has specific services of the devices as sub-resources. How this is exactly chosen is currently not defined by IETF; each compatible ecosystem of connected IoT devices could have its own method.

7. In section 2.3 - It would make sense to distinguish between the cases of announcing a software update is available and actually distributing the software update by multicast.

[GC] In -01 the following was added:
   Prior to multicast software update, the group
   of recipients can be separately notified that there is new software
   available and coming, using the above network-wide or group
   notification.
The phrase “above … notification” refers to the new use case A.2.4, “Network-wide / Group Notification”. Now the notification could also be sent by unicast to target devices, but this is not mentioned currently.

8. Section 3.1.1 - It should potentially be stated here, but definitely somewhere that for non-secure groups membership in the group is defined by an endpoint and not by a central endpoint.  This is important in terms of somebody "attacking" a non-secure group.

[GC] In -01 Section 2.1.3 this is now stated:
   For unsecure group communication, any CoAP endpoint may become a
   group member at any time: there is no (central) configuring entity
   that needs to provide the security material for the group.  This
   means that group creation and membership cannot be tightly
   controlled.

9.  Section 3.1.2 - It would make sense to point to group naming as part of a directory as well as being for DNS.  

[GC] Do you mean to include a reference to for example draft-ietf-core-resource-directory (Appendix A)? This describes registering groups including group name as RD entries. In -01 Section 2.1.2 this reference is now included. Perhaps the text should be more specific about the format of the group name that RD uses.

10.  Section 3.1.3 - One of the things that I had a problem with when implementation group broadcast was trying to decide which of the different local groups should be used for an IPv6 multicast address.  A number of these different groups are defined for CoAP and a discussion of the differences or a pointer to the differences would be useful.

[GC] Do you mean here the choice of different IPv6 scopes for a given multicast group ID? There’s a choice between link-local, realm-local, admin-local, site-local or global depending on the scope/propagation requirements. This choice needs to be made for application groups (like ff1X::Y) as well as for the general “All CoAP Nodes” address ff0X::fd that can be used for discovery. RFC7252 Section 12.8 states for the “All CoaP Nodes” address:
    CoAP needs the Link-Local and Site-Local scopes only
but I don’t think this is necessarily the case. For 6LoWPAN networks, Realm-Local is also useful. Admin-local can also be used in specific configured deployments. So we could add more discussion or guidelines for using the different scopes - would that be useful?

11. Section 3.2.1 - Another issue to highlight with tokens is that in the unicast case, the response is expected to come in on the same connection it was sent on.  Thus two different connections can re-use the same token without any problems.  That is not true for multicast as the connection it comes it on will, by definition, not be the one it was sent on.

[GC] CoAP defines a client as a single CoAP endpoint, so one client uses a single UDP source port to send its requests. (Sending on another port makes it another CoAP client, per RFC 7252.) So multiple CoAP clients (using different UDP source ports on the same host) can re-use the same token without any problems. Any CoAP response sent by a server goes back to the specific CoAP client that sent it.
We added some text in -01 section 2.2.1 about additional UDP port matching, but this needs to be updated since CoAP already solves it in the way indicated above.  The details may be not obvious at first due to CoAP’s definition of “client” which goes against the intuition that people have of a single client on a host that may use multiple UDP source ports.
So effectively the CoAP specified “only match on Token” for multicast means match both on Token and UDP destination port of the response. And the latter then allows Token reuse across multiple CoAP clients.

12. Section 3.2.1 - Might want to mention the use of Accept as one way to think about server response delay as you at least know that you are expecting a response from the server if you have received an accept.

[GC] This sounds like a new usage of Accept to tell the server “don’t suppress the response”. However the No-Response option in RFC 7967 can be used to indicate exactly this. Suppression of response only plays a role if there’s nothing of interest to return by the server (which may be a 2.xx without payload, or a 4.xx or 5.xx - “interest” is also depending on application context) .  The Accept option doesn’t work in the scope of these status codes, it tells something about content-formats so only scoped to the case that some content/payload is returned. It tells something about that payload and the preferred format. So seems not ideal as a way to control response suppression.
So with current defined specs, the server would by default return a response with a payload (conforming to the Accept Option if that was included in the request) if there’s something non-empty to return to the client. And a No-Response Option can be added to ensure that also empty 2.xx responses (e.g. a zero-length resource) or error responses are returned to the client. This is normally only done when the client knows through application context that the server could be suppressing , or is normally suppressing, these responses.

13. Section 3.2.3 - Need to talk about multicast messages, proxies and caching of results.

[GC] In the -01 update, we took over the RFC 7390 text on proxy use. That is a “SHOULD NOT” requirement on multicast operation by a proxy (see also a previous related reply)

14. Section 3.2.5 - Does RFC7641 define behavior about receiving a "duplicate" observer request?  Would you reply a second time or not? 

[GC] A duplicate observe request is handled using standard CoAP deduplication, that is, based on Message ID - defined for both unicast and multicast in RFC 7252. Now assuming that the request had a different MID: then in addition RFC 7641 (4.1) defines that a new request for a same resource, by the same client, using the same Token as an already active observe registration, does not lead to a new entry in the observers table. Rather, the existing entry is updated. Of course the response is sent again in this case with the latest resource value included, since a GET + Observe always has the same behaviour as a regular GET request.

15. Section 6.1 - next to last paragraph - /values does not/values, but does not/

[GC] Now fixed in -01, in current Section 5.1.

16. Section 6.2 - Should have a consideration about the speed of re-keying vs the frequency of joins/leaves.

[GC] We have added such considerations in -01, in current Section 5.2.1.

Jim