I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ace-key-groupcomm-oscore-18 Reviewer: Russ Housley Review Date: 2025-09-16 IETF LC End Date: 2025-09-25 IESG Telechat date: Not scheduled for a telechat Summary: Not Ready Major Concerns: This document builds upon so many other documents. To me, more is needed than the last paragraph in Section 1. It would help to add something to the Introduction that explains how they all fit together. A diagram would be extremely helpful, but I am not sure that is possible. Minor Concerns: Section 1.1: It would have been useful to me to include the Gid and Birth Gid concepts from [I-D.ietf-core-oscore-groupcomm]. Section 2 says: All communications between the involved entities (Client, Group Manager, Authorization Server) MUST be secured. I expected this to say how they are secured. This MUST statement does not tell an implementer what to do. The details come in the next paragraph. I suggest replacing this MUST statement with an introduction to the following paragraph. I would make them one paragraph as well. Section 3 describes the computation of the R value. I think the reader would more quickly understand the algorithm if it was described as a bitmask carried in a CBOR unsigned integer. In Section 6.3, the text about the HKDF parameter is confusing. Is the hash function named, or is the HMAC algorithm named? The default is neither one of these choices (HKDF SHA-256), which adds to the confusion. The example in Figure 4 shows "HMAC with SHA-256", which seems like the intent is to name the HMAC algorithm. Section 6.3 says: This parameter MUST be present if and only if the node does not join the OSCORE group exclusively with the role of monitor, ... Please reword. This is a very complex way of saying that the parameter MUST be present if the node has at least one role other than monitor. Section 9.1.1 says that "The 'exp' parameter SHOULD be present." Please provide the consequences if the 'exp' parameter is not present. Section 9.1.2 says that "The 'exp' parameter SHOULD be present." Please provide the consequences if the 'exp' parameter is not present. In Section 14.1, the text about the HKDF parameter is confusing. Based on the example in Figure 4, which shows "HMAC with SHA-256", the HMAC algorithm should be discussed as the default. In Section 16.1, the formatting does not make it clear that two OAuth parameters are being registered. Please make two sets of bullets. In Section 16.3, the formatting does not make it clear that five ACE Groupcomm parameters are being registered. Please make five sets of bullets. In Section 16.6, the group_SenderId entry does not include a registry, but the other entries in this section do so. In Section 16.6, the formatting does not make it clear that six ACE OSCORE Security Context parameters are being registered. Please make six sets of bullets. In Section 16.8, the formatting does not make it clear that two AIF Media-Type sub-parameters are being registered. Please make two sets of bullets. In Section 16.9, the formatting does not make it clear that two CoAP Content-Formats are being registered. Please make two sets of bullets. In Section 16.9, the formatting does not make it clear that three ACE Groupcomm Errors are being registered. Please make three sets of bullets. Nits: Section 4: I suggest rewording: OLD: The joining node is currently a group member acting not exclusively as monitor, and it is re-joining the group not exclusively as monitor. NEW: The joining node is currently a group member with at least one role other than monitor, and it is re-joining the group with at least one role other than monitor. Section 5.3: s/an 8-byte long random nonce/an 8-byte random nonce/ Section 5.3: s/Consistently with Section/To align with Section/ (twice) Section 5.3.2: s/to join or interact with/to join or monitor/ (twice) Section 6.1: s/an 8-byte long random nonce/an 8-byte random nonce/ Section 6.1: s/that could have happened/proof-of-possession could occur/ Section 6.1: s/In either case, the N_S/The N_S/ Section 6.1: s/HKDF Algorithm HKDF SHA-256/HKDF Algorithm with SHA-256/ Section 6.2: s/In such a case /In such a case, / Section 6.2: s/stored value (if any)/stored value, if any/ Section 8.6: s/newly defined earlier in Section 8/defined in Section 8/ Section 9.5.2: s/an 8-byte long random nonce/an 8-byte random nonce/ Section 9.10: s/Furthermore, since it/Since the signature verifier node/ Section 10: s/not exclusively the role of/at least one role other than/ Section 15.2: s/an 8-byte long random nonce/an 8-byte random nonce/ Section 15.2: s/take 8-byte long values/take 8-byte random values/ Note: I did not review the Appendices.