Thanks for the extensive reply and changes. I will initiate the IETF LC now.
Paul On Sun, Feb 1, 2026 at 4:47 AM Marco Tiloca <marco.tiloca= [email protected]> wrote: > Hello Paul, > > We have just submitted version -14 to address your AD review. Please find > in line below our replies to your comments. > > This version also addresses the following points: > > * Aligned with increasingly common expectations and with the > recommendations in draft-opsarea-rfc5706bis, we have added a new section > "Operational Considerations", right before the section "Security > Considerations". > > * The parameter 'gp_enc_alg' from draft-ietf-ace-key-groupcomm-oscore is > now called with that name in this document too, thus resolving a long-time > pending Editor's note. > > * Two CoAP error response codes have been fixed, to use more appropriate > ones (code 4.05 in Section 6; code 4.00 in Section 6.8). > > * Minor fixes in the examples of message payloads (registered and > placeholder codepoints) and in the example algorithm of Appendix A. > > * Minor clarifications and editorial fixes, largely building on applicable > feedback from the IETF Last Call of draft-ietf-ace-key-groupcomm-oscore. > > Best, > /Marco > > ------------------------------ > *From:* Paul Wouters <[email protected]> > *Sent:* Wednesday, October 1, 2025 4:47 AM > *To:* Ace Wg <[email protected]> > *Subject:* [Ace] AD review of draft-ietf-ace-oscore-gm-admin-13 > > > AD review of draft-ietf-ace-oscore-gm-admin-13 > > Thanks for this document. All in all it is very clear. > I do have some questions and comments/nits: > > TLS version > > this can rely on DTLS [RFC9147] as per [RFC9202] > > Does this mean it requires DTLS 1.3, or is DTLS 1.2 allowed? Should this > be made more explicit? > > ==>MT > > The DTLS profile of ACE specified in RFC 9202 does cover both DTLS 1.2 and > DTLS 1.3. However, the text of the quoted paragraph talks more specifically > of the secure communication protocol used between two involved entities, > pointing to DTLS as an example and without normative recommendations. > > In other words, the focus of that sentence is about the possible use of > the DTLS protocol, rather than the DTLS profile of ACE. Since there was no > specific need to mention exactly DTLS 1.2, we followed the (good?) practice > of omitting RFC 6347, as obsoleted by RFC 9147. > > To be aligned with what the DTLS profile of ACE offers, we have extended > the quoted sentence in Section 1.1 to also use the informative reference to > RFC 6347, i.e.: > > NEW > > ... this can rely on DTLS [RFC6347][RFC9147] as per [RFC9202] ... > > Note that, later on in Section 4, two sentences mentioning DTLS only refer > to RFC 9147, per the same rationale used when writing the quoted original > text from Section 1.1. > > <== > > > Default values and their use > > While the defaults use RECOMMENDED, things like Section 6.6 state the > value from defaults MUST be used. It is a little unclear to me what > this means when the RECOMMENDED value was not used. Should it use the > different value or the RECOMMENDED to comply to the MUST ? > > ==>MT > > Quoting text from Section 6.6 for context: > > > For each other parameter not specified in the POST request, the Group > Manager MUST use default values as specified in Section 5.2. > > Agreed that the original text is misleading. > > The intent is that the Group Manager refers to the default values in > Section 5.2, where it is said that such default values SHOULD be used. As > also stated in Section 5.2, the Group Manager might have reasons to deviate > from the recommended default values and thus MAY choose different values to > use as default ones. > > Here in Section 6.6, the text should be revised to use the same wording of > Section 6.3 about the same topic. That is, Section 6.3 says: > > > For each parameter not specified in the request, the Group Manager > refers to the default values specified in Section 5.2. > > > With that in mind and aiming for additional editorial consistency, we have > rephrased the text in both Sections 6.3 and 6.6 to use exactly the same > wording: > > OLD (Section 6.3) > > For each parameter not specified in the request, the Group Manager > refers to the default values specified in Section 5.2. > > OLD (Section 6.6) > > For each other parameter not specified in the POST request, the Group > Manager MUST use default values as specified in Section 5.2. > > NEW (Sections 6.3 and 6.6) > > For each parameter not specified in the POST request, the Group Manager > refers to default values as specified in Section 5.2. > > > For additional clarity, we have also rephrased related text in other > sections when referring to recommended default values, to point exactly to > Section 5.2.1 and Section 5.2.2 where those recommended values are defined. > That is: > > OLD (Section 6.3) > > ... and the Group Manager used default values different from the ones > recommended in Section 5.2, ... > > NEW (Section 6.3) > > ... and the Group Manager used default values different from the ones > recommended in Section 5.2.1 and Section 5.2.2, ... > > OLD (Section 6.3) > > ... or the corresponding default value recommended in Section 5.2.1 > otherwise. > > NEW (Section 6.3) > > ... or the corresponding default value recommended in Section 5.2.1 or > Section 5.2.2 otherwise. > > OLD (Section 6.6) > > ... and the Group Manager used default values different from the ones > recommended in Section 5.2, ... > > NEW (Section 6.6) > > ... and the Group Manager used default values different from the ones > recommended in Section 5.2.1 and Section 5.2.2, ... > > OLD (Section 6.6) > > ... or the corresponding default value recommended in Section 5.2.1 > otherwise. > > NEW (Section 6.6) > > ... or the corresponding default value recommended in Section 5.2.1 or > Section 5.2.2 otherwise. > > <== > > > Fix reference on draft-amsuess-core-cachable-oscore > > det_hash_alg refers to draft-amsuess-core-cachable-oscore but this should > be draft-ietf-core-cacheable-oscore. > > ==>MT > > Fixed. > > We have also fixed the reference > draft-ietf-ace-revoked-token-notification, which is now RFC 9770. > > <== > > > default values > > This section defines the default values that the Group Manager > uses for the configuration and status parameters. > > But the next sentence says these are the RECOMMENDED values. So perhaps it > should say that here too? > > ==>MT > > Aligned with the update made to address a previous comment about Section > 6.6, we have rephrased the text here in Section 5.2 as below. > > OLD > > This section defines the default values that the Group Manager uses for > the configuration and status parameters. > > > > The Group Manager MAY choose different default values instead of those > recommended in this section. A possible reason is ... > > NEW (emphasis mine) > > This section defines the default values that the Group Manager **refers > to** for the configuration and status parameters. **In particular, Section > 5.2.1 and Section 5.2.2 define the default values that are RECOMMENDED to > use for the configuration and status parameters, respectively.** > > > > **Exceptionally, the** Group Manager MAY choose different default values > instead of those recommended in **Section 5.2.1 and Section 5.2.2**. A > possible reason is ... > > <== > > > Section 6.6.1 > > Why is this listed here? Isn't this regular operation unrelated to this > document? > > ==>MT > > It is good to have this content here for completeness and to build a clear > relationship with the other interface specified in > draft-ietf-ace-key-groupcomm-oscore. > > At the same time, it is true that the text in Section 6.6.1 of the present > document does not define new behavior, and therefore it should avoid > normative language. > > We have rephrased the first paragraph as below: > > OLD > > After having overwritten a group configuration, if the value of the > status parameter 'active' is changed from true (0xf5) to false (0xf4), the > Group Manager MUST stop admitting new members in the OSCORE group. In > particular, until the status parameter 'active' is changed back to true > (0xf5), the Group Manager MUST respond to a Join Request with a 5.03 > (Service Unavailable) response, as defined in Section 6.2 of > [I-D.ietf-ace-key-groupcomm-oscore]. > > NEW (emphasis mine) > > After having overwritten a group configuration, if the value of the > status parameter 'active' is changed from true (0xf5) to false (0xf4) **and > thus the group becomes inactive**, the Group Manager **stops** admitting > new members in the OSCORE group. In particular, until the status parameter > 'active' is changed back to true (0xf5) **and thus the group becomes active > again**, the Group Manager **replies** to a Join Request with a 5.03 > (Service Unavailable) response, as defined in Section 6.2 of > [I-D.ietf-ace-key-groupcomm-oscore]. > > (Through the document, we have consistently replaced "respond" with > "reply") > > <== > > > Section 6.6.2 > > 6.6.2 also repeats this text: > > If the value of the status parameter 'active' is changed from true > (0xf5) to false (0xf4): > > The Group Manager MUST stop accepting requests for new individual > keying material from current group members > > Should this not read that the group members MUST stop sending requests ? > If not, why is this text repeated from 6.6.1? Note that it does say so > in the second bullet point: > > * Every group member, upon learning that the OSCORE group has > been deactivated (i.e., 'active' has value false (0xf4)), SHOULD > stop communicating in the group. > > then: > > Every group member, upon learning that the OSCORE group has > been reactivated (i.e., 'active' has value true (0xf5) again), > can resume communicating in the group. > > Am I correct in that group members "learn" this via the pairwise connection > with the GNM by requesting a LIST command filtered by Active state? > > ==>MT > > Note that Section 6.6.1 refers to nodes that are not group members, hence > its considerations are limited to stopping those nodes from joining an > inactive group. > > Instead, Section 6.6.2 is about group members, hence its considerations > cover the broader set of operations that those nodes can normally perform > with the Group Manager and with one another. > > If the status parameter 'active' is changed from true (0xf5) to false > (0xf4) and thus the group becomes inactive, it's not simply that group > members "MUST stop sending requests". They have to stop communicating with > one another, and they have to stop sending to the Group Manager the two > types of request that are specifically mentioned in the text. However, they > can send other types of requests to the Group Manager as per the interface > defined in draft-ietf-ace-key-groupcomm-oscore, e.g., in order to learn > when the group becomes active again or to leave the group. > > Specifically regarding a group member that learns about the group becoming > active again: > > * The group member does rely on the pairwise secure communication > association that it has with the Group Manager. > > * The group member does **not** rely on any operation for the interface > defined in the present document (which is intended for Administrators). The > operation to learn about the current status of the group with name > GROUPNAME is defined in Section 9.9 of draft-ietf-ace-key-groupcomm-oscore > , i.e., a GET request to the resource /ace-group/GROUPNAME/active at the > Group Manager. > > Just to clarify: an Administrator can effectively retrieve the current > status of a group with name GROUPNAME by retrieving the 'active' status > parameter from the group configuration. The Administrator does that by > sending a GET or a FETCH request to the /manage/GROUPNAME resource at the > Group Manager (see Sections 6.4 and 6.5 of the present document). > > With the above in mind and in the same spirit of the update that addresses > the previous comment about Section 6.6.1, we have also rephrased the text > in Section 6.6.2 as below. > > OLD > > * If the value of the status parameter 'active' is changed from true > (0xf5) to false (0xf4): > > > > - The Group Manager MUST stop accepting requests for new individual > keying material from current group members (see Section 9.2 of > [I-D.ietf-ace-key-groupcomm-oscore]), until the status parameter 'active' > is changed back to true (0xf5). Until then, the Group Manager MUST respond > to a Key Renewal Request with a 5.03 (Service Unavailable) response, as > defined in Section 9.2 of [I-D.ietf-ace-key-groupcomm-oscore]. > > > > - The Group Manager MUST stop accepting updated authentication > credentials uploaded by current group members (see Section 9.4 of > [I-D.ietf-ace-key-groupcomm-oscore]), until the status parameter 'active' > is changed back to true (0xf5). Until then, the Group Manager MUST respond > to an Authentication Credential Update Request with a 5.03 (Service > Unavailable) response, as defined in Section 9.4 of > [I-D.ietf-ace-key-groupcomm-oscore]. > > > > * Every group member, upon learning that the OSCORE group has been > deactivated (i.e., 'active' has value false (0xf4)), SHOULD stop > communicating in the group. > > > > Every group member, upon learning that the OSCORE group has been > reactivated (i.e., 'active' has value true (0xf5) again), can resume > communicating in the group. > > NEW (emphasis mine) > > * If the value of the status parameter 'active' is changed from true > (0xf5) to false (0xf4) **and thus the group becomes inactive**: > > > > - The Group Manager **stops** accepting requests for new individual > keying material from current group members (see Section 9.2 of > [I-D.ietf-ace-key-groupcomm-oscore]), until the status parameter 'active' > is changed back to true (0xf5) **and thus the group becomes active again**. > Until then, the Group Manager **replies** to a Key Renewal Request with a > 5.03 (Service Unavailable) response, as defined in Section 9.2 of > [I-D.ietf-ace-key-groupcomm-oscore]. > > > > - The Group Manager **stops** accepting updated authentication > credentials uploaded by current group members (see Section 9.4 of > [I-D.ietf-ace-key-groupcomm-oscore]), until the status parameter 'active' > is changed back to true (0xf5) **and thus the group becomes active again**. > Until then, the Group Manager **replies** to an Authentication Credential > Update Request with a 5.03 (Service Unavailable) response, as defined in > Section 9.4 of [I-D.ietf-ace-key-groupcomm-oscore]. > > > > * Every group member, upon learning that the OSCORE group has been > deactivated (i.e., 'active' has value false (0xf4)), **stops sending > messages to other group members and stops processing messages from other > group members, until the group becomes active again. In the meantime, the > group member can still interact with the Group Manager, e.g., in order to > check whether the group has become active again**. > > > > Every group member, upon learning that the OSCORE group has been > reactivated (i.e., 'active' has value true (0xf5) again), can resume > **taking part in communications with other group members (i.e., sending > messages and processing incoming messages)**. > > > > **A group member can learn about the current group status of a group > with group name GROUPNAME by accessing the /ace-group/GROUPNAME/active > resource at the Group Manager, as specified in Section 9.9 of > [I-D.ietf-ace-key-groupcomm-oscore]. Optionally, the group member may > subscribe for updates to such a resource, e.g., by using CoAP Observe > [RFC7641].** > > The wording above is aligned with how a previous comment was addressed in > draft-ietf-ace-key-groupcomm-oscore, to not erroneously suggest that a > group member has to stop communicating also with the Group Manager. > > (Through the document, we have consistently replaced "respond" with > "reply") > > <== > > > Section 6.8 > > Otherwise, the Group Manager continues processing the request, > > I am not sure where this "Otherwise" comes from. Eg if "otherwise" is the > "else" part, what was the "if" part? What part of the processing was done > before this statement was reached? > > ==>MT > > When re-reading the document before processing this review, indeed we > noticed that the quoted paragraph and the immediately following one did not > read well. > > Besides the "Otherwise" issue raised in this comment, the error handling > described by the two paragraphs was not presented in a clean and linear way. > > Consequently, we have rephrased the fourth and fifth paragraphs of Section > 6.8 as below: > > OLD > > Otherwise, the Group Manager continues processing the request, which > MUST fail it the OSCORE group is active. That is, the DELETE request MUST > yield the deletion of the OSCORE group only if the corresponding status > parameter 'active' has current value false (0xf4). The Administrator can > ensure that, by first performing an update of the group-configuration > resource associated with the OSCORE group (see Section 6.6 and Section > 6.7), and setting the corresponding status parameter 'active' to false > (0xf4). > > > > If, upon receiving the DELETE request, the current value of the status > parameter 'active' is true (0xf5), the Group Manager MUST respond with a > 4.09 (Conflict) response. The response MUST have Content-Format set to > application/concise-problem-details+cbor [RFC9290] and is formatted as > defined in Section 4.1.2 of [RFC9594]. Within the Custom Problem Detail > entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set > to 10 ("Group currently active"). > > NEW > > If the OSCORE group is active, i.e., the current value of the status > parameter 'active' is true (0xf5), then the request MUST fail and the Group > Manager MUST reply with a 4.00 (Bad Request) response. The response MUST > have Content-Format set to "application/concise-problem-details+cbor" > [RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594]. Within > the Custom Problem Detail entry 'ace-groupcomm-error', the value of the > 'error-id' field MUST be set to 10 ("Group currently active"). > > > > That is, the request yields the deletion of the OSCORE group only if the > OSCORE group is inactive, i.e., the corresponding status parameter 'active' > has current value false (0xf4). The Administrator can ensure that, by first > performing an update of the group-configuration resource associated with > the OSCORE group (see Section 6.6 and Section 6.7) and setting the > corresponding status parameter 'active' to false (0xf4). > > Note that this update includes also a fix to the error response code, > i.e., from 4.09 (Conflict) to the most appropriate 4.00 (Bad Request). > > Also note that a similar spurious "Otherwise" was present at the beginning > of the fourth paragraph of Section 6.4, i.e., "Otherwise, after a > successful processing of the GET request, ...". We have fixed that by > simply starting the sentence as "After a successful processing of the GET > request, ..." > > <== > > > I wonder if [I-D.amsuess-core-cachable-oscore] should be normative? > > ==>MT > > Like discussed and agreed on the mailing list [0], we have kept the > reference informative. > > As also proposed, we have improved the three instances of a related > sentence, in Sections 5.1.1 and 6.6.2: > > OLD > > ... as defined in [I-D.amsuess-core-cachable-oscore] > > NEW > > ... (see [I-D.ietf-core-cacheable-oscore]) > > [0] https://mailarchive.ietf.org/arch/msg/ace/7K8wTvzHpQGgC0nXukiUsagbOCg/ > > <== > > > [I-D.tiloca-core-oscore-discovery] is definitly normative. > > ==>MT > > Like discussed and agreed on the mailing list [0], we have kept the > reference informative. > > As also proposed, we have updated two sentences as below. > > * In Section 6.3, rephrased as below: > > OLD > > The Group Manager can register the link to the group-membership > resource with URI specified in 'joining_uri' to a Resource Directory > [RFC9176], as defined in Section 2 of [I-D.tiloca-core-oscore-discovery]. > > NEW (emphasis mine) > > The Group Manager can register the link to the group-membership > resource with URI specified in 'joining_uri' to a Resource Directory > [RFC9176], **e.g., by using the approach described in** > [I-D.tiloca-core-oscore-discovery]. > > * In Section 6.6, removed the reference altogether, i.e.: > > OLD > > If the link to the group-membership resource was registered in the > Resource Directory [RFC9176], the Group Manager is responsible to refresh > the registration, as defined in Section 3 of > [I-D.tiloca-core-oscore-discovery]. > > NEW > > If the link to the group-membership resource was registered in the > Resource Directory [RFC9176], the Group Manager is responsible to refresh > the registration. > > [0] https://mailarchive.ietf.org/arch/msg/ace/7K8wTvzHpQGgC0nXukiUsagbOCg/ > > <== > > > RFC9176 is probably normative too > > ==>MT > > Like discussed and agreed on the mailing list [0], we have changed the > reference to be normative. > > [0] https://mailarchive.ietf.org/arch/msg/ace/7K8wTvzHpQGgC0nXukiUsagbOCg/ > > <== > > > > NITS: > > The Constrained Application Protocol (CoAP) [RFC7252] can also > be used for group communication [I-D.ietf-core-groupcomm-bis], > where messages are exchanged between members of a group > > I would remove "also" and the comma before "where. > > ==>MT > > Fixed like suggested. > > <== > > > as well as how it should be configured and later on updated > or deleted, e.g., based on the current application state or > pre-installed policies > > I had to read this a few times.. how abour "and later on how it should > be updated or deleted" > > ==>MT > > We agree that the original text can be simplified. > > At the same time, the suggested new text as-is risks to miss the specific > point about configuration upon creation. > > Building on the suggestion, we have rephrased as below: > > OLD > > In some deployments, the application running on the Group Manager may > know when a new OSCORE group has to be created, as well as how it should be > configured and later on updated or deleted, e.g., based on the current > application state or pre-installed policies. > > NEW (emphasis mine) > > In some deployments, the application running on the Group Manager may > know when a new OSCORE group has to be created, **how the group should be > configured upon creation, and later on how the group should be updated or > deleted, e.g., based on the current application state or pre-installed > policies**. > > <== > > > and is poorly flexible > > and is not very flexible. > > ==>MT > > Fixed like suggested. > > <== > > >
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
