Hello Mike, Thanks a lot for your review!
The just submitted version -21 of the draft addresses your comments and other reviews/feedback received. Please find in line below our detailed replies to your comments. Best, /Marco ________________________________ From: Mike Bishop via Datatracker <[email protected]> Sent: Tuesday, February 3, 2026 6:34 PM To: The IESG <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Rikard Höglund <[email protected]> Subject: Mike Bishop's No Objection on draft-ietf-ace-key-groupcomm-oscore-19: (with COMMENT) Mike Bishop has entered the following ballot position for draft-ietf-ace-key-groupcomm-oscore-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Caa6e6c1bccf6433b3fc708de634a8a6d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057368982269299%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v83NqStMNmiqJwcwnFnyjwlzs%2F1%2FiR6d%2FnZr0LKoFaE%3D&reserved=0<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-key-groupcomm-oscore%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Caa6e6c1bccf6433b3fc708de634a8a6d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057368982301121%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QXs0z5X4BBu5ZdKaksysuTofxNr95QGIfPLr5LZG9tg%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/> ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # IESG review of draft-ietf-ace-key-groupcomm-oscore-19 CC @MikeBishop ## Comments ### Section 3, paragraph 23 ``` Future specifications that define new Group OSCORE roles MUST register a corresponding numeric identifier in the "Group OSCORE Roles" registry. ``` It generally doesn't make sense to apply normative requirements to future specifications. You can simply note the expectation without 2119 keywords. ==>MT Right; we have updated the text as below. OLD Future specifications that define new Group OSCORE roles MUST register a corresponding numeric identifier in the "Group OSCORE Roles" registry. NEW Future specifications that define new Group OSCORE roles must register a corresponding numeric identifier in the "Group OSCORE Roles" registry defined in Section 17.12 of this document. <== ### GROUPNAME I did a little tracing through various RFCs to find any character constraints on GROUPNAME, and didn't determine anything stricter than "UTF-8 string." Since this is used as part of a URI, consider explicitly restricting GROUPNAME to URI-safe characters. ==>MT Yes, that's indeed the intention. Inheriting from RFC 9594, GROUPNAME is "used in URIs to identify a group", which implies that GROUPNAME is restricted to URI-safe characters. Then Section 8 of the present document says: > The GROUPNAME segment of the URI path MUST match with the group name > specified in the scope entry of the scope in the access token (i.e., 'gname' > in Section 3.1 of [RFC9594]) (REQ7). The above implies that the group name (that is mapped one-to-one in GROUPNAME) has to be restricted to URI-safe characters. We have updated the draft as below, to clarify specifically this point. OLD (Section 3) The object identifier ("Toid") is a CBOR text string, specifying the group name for the scope entry. NEW (Section 3) The object identifier ("Toid") is a CBOR text string, specifying the group name for the scope entry. As defined later in Section 8, a group's name matches with the GROUPNAME segment within the URI path of the group-membership resource and corresponding sub-resources that are associated with that group and hosted at the Group Manager. Therefore, a group name has to be consistent with the semantics of URI path segments (see Section 3.3 of [RFC3986]). OLD (Section 8) The GROUPNAME segment of the URI path MUST match with the group name specified in the scope entry of the scope in the access token (i.e., 'gname' in Section 3.1 of [RFC9594]) (REQ7). NEW (Section 8) The GROUPNAME segment of the URI path MUST match with the group name specified in the scope entry of the scope in the access token (i.e., 'gname' in Section 3.1 of [RFC9594]) (REQ7). Therefore, a group name has to be consistent with the semantics of URI path segments (see Section 3.3 of [RFC3986]). <== ### Section 5.3, paragraph 6 ``` to the N_S value, it is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be a random value. The joining node can use ``` Why are these lengths and randomness RECOMMENDED rather than required? ==>MT We have taken the same approach used for N1 and N2 in the OSCORE transport profile of ACE defined in RFC 9203 (see Sections 4.1, 4.2, and 7 of that document). Regarding the length: this is discussed in the security considerations of Section 16.2, and plays a role in the probability of a possible collision/repetition of values. With that in mind, one considers the number of issued and transferred access tokens against the expected group joinings under the same Group Manager. Deviations that consider a different length remain possible, in setups with particular rates of token provisionings and group joinings. Regarding the randomness: this is discussed in the security considerations of Section 16.3, as a convenient way to ensure freshness. As discussed in the second paragraph of Section 16.3, non-random alternatives are possible (e.g., a counter), in which case care must be taken to avoid that generated values were not used before with the other party, even in case of reboot and loss of state. <== ### Section 11, paragraph 8 ``` * If any of such "elder members" is found in the group, then the Group Manager MUST evict them from the group. That is, the Group ``` Is the term "elder members" a useful or widely-used term here? I would think "any such members are found" would be sufficient. ==>MT We prefer to keep the current "elder members", to be consistent with the same expression used in the related Section 12.2.1.1.1 of draft-ietf-core-oscore-groupcomm and referred to in the present document. <== ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flarseggert%2Fietf-reviewtool&data=05%7C02%7Cmarco.tiloca%40ri.se%7Caa6e6c1bccf6433b3fc708de634a8a6d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057368982319004%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DFCaYt7YTRInolliSmOS3EKZfh9K7T5tdPTl9Y5suOM%3D&reserved=0)<https://github.com/larseggert/ietf-reviewtool>, so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ==>MT Almost all the nits below have been fixed as suggested, except in sentences that are actually as intended. <== ### Typos #### Section 1.1, paragraph 15 ``` - * Monitor: member of an OSCORE group that is configured as responder + * Monitor: member of an OSCORE group that is configured as a responder + ++ ``` #### Section 5.3, paragraph 6 ``` - to the N_S value, it is RECOMMENDED to be at least 8-byte long and - ^ + to the N_S value, it is RECOMMENDED to be at least 8 bytes long and + ^ + ``` #### Section 6.1, paragraph 6 ``` - least 8-byte long and it is RECOMMENDED to be a random value. - ^ + least 8 bytes long and it is RECOMMENDED to be a random value. + ^ + ``` #### Section 6.2, paragraph 30 ``` - * If the group uses (also) the group mode of Group OSCORE, then the - ------- ``` #### Section 6.2, paragraph 31 ``` - * If the group uses (also) the pairwise mode of Group OSCORE, then - ------- ``` #### Section 6.2.1, paragraph 2 ``` - RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be - ^ + RECOMMENDED to be at least 8 bytes long and it is RECOMMENDED to be + ^ + ``` #### Section 6.3, paragraph 39 ``` - OSCORE group, in case the joining node is configured (also) as - - - -- - ``` s/(also) as/as a/ #### Section 6.3, paragraph 39 ``` - is configured (also) as responder or monitor. - - - -- - ``` s/(also) as/as a/ #### Section 6.3, paragraph 45 ``` - N_KDC value, it is RECOMMENDED to be at least 8-byte long and it - ^ + N_KDC value, it is RECOMMENDED to be at least 8 bytes long and it + ^ + ``` #### Section 8, paragraph 4 ``` - Section 8.5 provides a summary of the CoAP methods that are admitted - ^^ + Section 8.5 provides a summary of the CoAP methods that are permitted + ^^^ ``` #### Section 8.4.1, paragraph 4 ``` - 8.5. Admitted Methods - ^^ + 8.5. Permitted Methods + ^^^ ``` #### Section 8.4.1, paragraph 5 ``` - Table 2 summarizes the CoAP methods that are admitted for accessing - ^^ + Table 2 summarizes the CoAP methods that are permitted for accessing + ^^^ ``` #### Section 9.1, paragraph 1 ``` - OSCORE Security Context invalid and to be renewed. This happens, for - --- ^^ + OSCORE Security Context invalid and needs to renew it. This happens, for + ++++++ ^^^ ``` #### Section 9.2, paragraph 12 ``` - Consistently with Section 2.6.3.1 of - -- ``` #### Section 9.5.2, paragraph 3 ``` - it is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED - ^ + it is RECOMMENDED to be at least 8 bytes long and it is RECOMMENDED + ^ + ``` #### Section 11, paragraph 8 ``` - * If any of such "elder members" is found in the group, then the - --- ``` #### Section 11.1, paragraph 16 ``` - This distribution approach requires group members to act (also) as - ------- ``` #### Section 11.1, paragraph 17 ``` - to act (also) as servers. A number of such approaches are defined in - ------- ``` #### Section 11.3.1, paragraph 1 ``` - When realizing to have missed one or more group rekeying instances - - ^^ + When realizing it has missed one or more group rekeying instances + + ^ ``` #### Section 14.2, paragraph 1 ``` - This section applies if the group uses (also) the group mode of Group - ------- ``` #### Section 14.3, paragraph 1 ``` - This section applies if the group uses (also) the pairwise mode of - ------- ``` #### Section 16.2, paragraph 2 ``` - As to the N_C value, it is RECOMMENDED to be at least 8-byte long and - ^ + As to the N_C value, it is RECOMMENDED to be at least 8 bytes long and + ^ + ``` #### Section 16.2, paragraph 5 ``` - least 8-byte long and it is RECOMMENDED to be a random value. - ^ + least 8 bytes long and it is RECOMMENDED to be a random value. + ^ + ``` ### Grammar/style #### Section 1.1, paragraph 7 ``` rs of the group. A responder may reply back, by sending a response message to ^^^^^^^^^^ ``` Consider using just "reply". #### Section 1.1, paragraph 20 ``` lication profile, a group member communicate with other other group members u ^^^^^^^^^^^ ``` "Member" is a singular noun. It appears that the verb form is incorrect. #### Section 1.1, paragraph 20 ``` a group member communicate with other other group members using CoAP [RFC725 ^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 5.3.2, paragraph 2 ``` r Section 4.3.1.1 of [RFC9594]. Additionally to what is defined in Section 4. ^^^^^^^^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Additionally". Consider "In addition" #### Section 6.4, paragraph 14 ``` fferent roles in the group or as non members (REQ11). The GROUPNAME segment ^^^^^^^^^^^ ``` This expression is normally spelled as one or with a hyphen. #### Section 9.9, paragraph 4 ``` ns the group, the Group Manager can rely, e.g., on the ongoing secure commun ^^^^ ``` The verb "rely" requires the preposition "on" (or "upon"). #### Section 10, paragraph 6 ``` rial. a. The group member has participated to a rekeying process that has dis ^^^^^^^^^^^^^^^ ``` The usual preposition for "participated" is "in", not "to". #### "In case" The phrase "in case" is generally meant to prepare for a possible eventuality. Consider using "In the case that" or "If" in most places.
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
