Hello Jim, Thanks for your comments - the authors are now looking into these and we'll reply again as soon as we have answers. I also copy this to the CoRE WG list; as the draft targets the CoRE WG.
Esko -----Original Message----- From: Jim Schaad <[email protected]> Sent: Wednesday, May 29, 2019 00:45 To: [email protected] Cc: [email protected] 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. 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? * 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? 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). 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. 5. In section 2.1.1 - you should state that the centralized directory would be pre-configured in the device. 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. 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. 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. 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. 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. 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. 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. 13. Section 3.2.3 - Need to talk about multicast messages, proxies and caching of results. 14. Section 3.2.5 - Does RFC7641 define behavior about receiving a "duplicate" observer request? Would you reply a second time or not? 15. Section 6.1 - next to last paragraph - /values does not/values, but does not/ 16. Section 6.2 - Should have a consideration about the speed of re-keying vs the frequency of joins/leaves. Jim _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
