Document: draft-ietf-core-groupcomm-bis Title: Group Communication for the Constrained Application Protocol (CoAP) Reviewer: Sean Turner Review result: Has Issues Hi! Started out comparing this I-D to RFC 7390; there are a LOT of changes, but that is a good because RFC 7390 is experimental and this I-D is bound for standards track. I have one issue worth discussing and the rest are nits. Issue) It is possible that I am missing the point of the document, but I am left wondering if I follow the recommendations herein will I end up with an interoperable solution. s2.2.2 is pretty explicit about there not being a mandatory group creation protocol, but shouldn't there be a key management protocol? s5.2 includes the following: The key management operations mentioned above are entrusted to the Group Manager responsible for the OSCORE group [I-D.ietf-core-oscore-groupcomm], and it is RECOMMENDED to perform them as defined in [I-D.ietf-ace-key-groupcomm-oscore]. Based on the following IESG statement (https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-normative-and-informative-references-20060419/) and with RECOMMENDED = SHOULD, isn't I-D.ietf-ace-key-groupcomm-oscore a normative reference? With 15 examples of the "x can be used to do y" (not normative requirements), I left feeling like ¯\_(ツ)_/¯ that I can get to an interoperable solution even after skimming the references to: - RFC 9176 (normative) - I-D.ietf-ace-key-groupcomm-oscor (informative) - I-D.ietf-ace-oscore-gm-admin (informative) - I-D.ietf-core-oscore-groupcomm (normative) - I-D.ietf-core-groupcomm-proxy (informative) - I-D.tiloca-core-oscore-discovery (informative) Nits: n0) s2.2.3.2: This sentence was a little awkward for me: The following discusses a number of methods to discover application groups and CoAP groups, building on the following assumptions. would this work: The following discusses a number of methods to discover application groups and CoAP groups. n1) s4 includes: Consistent with such security implications, the use of the NoSec mode should still be avoided whenever possible. should that should be a SHOULD? n2) s4 & s6.1 consistency: s4 includes (right before this is refers to s6.1): It is NOT RECOMMENDED to use CoAP group communication in NoSec mode. s6.1 includes: Except for the class of applications discussed above, and all the more so in applications that obviously have hard security requirements (e.g., health monitoring systems and alarm monitoring systems), CoAP group communication MUST NOT be used in NoSec mode. Are these consistent? n3) s5.3 includes: For a client performing a group communication request via a forward- proxy, end-to-end security should be implemented. should that should be SHOULD? n4) s6.7 includes: In a home automation scenario using Wi-Fi, Wi-Fi security should be enabled to prevent rogue nodes from joining. should this should be a SHOULD? Cheers, spt -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
