[Ace] Re: Last Call comment on draft-ietf-ace-oscore-gm-admin (defaults + error handling)

[Marco Tiloca <[e-mail]>]

Hello Meir,

Thanks for you comments!

Please see our replies inline below.

Best,
/Marco

________________________________
From: Meir Goldman <fazon=[e-mail]>
Sent: Friday, February 13, 2026 3:24 AM
To: [e-mail] <[e-mail]>
Subject: [Last-Call] Last Call comment on draft-ietf-ace-oscore-gm-admin (defaults + error handling)

You don't often get email from fazon=[e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Thanks for the -14 update and the added “Operational Considerations” section.

Two suggestions to further reduce interop and security risk:
1) Please ensure consistent normative language around defaults across all sections (avoid any remaining MUST/SHOULD ambiguity when defaults are referenced).

==>MT

We have re-checked the whole document, and we think that all is already consistent.

In particular, we do not find any MUST/SHOULD ambiguity.

In Section 5.2:

* The defined values are overall RECOMMENDED to be used as default values. Exceptions are allowed and one reason for that is explicitly mentioned.

* Each of the specific default values is introduced using SHOULD. This also applies for those that rely on an external definition in Sections 14.1-14.3 of draft-ietf-ace-key-groupcomm-oscore. That document also defines default values in the same spirit, i.e., as RECOMMENDED to be used as default values, and by introducing those using SHOULD.

In Section 5.3:

* It is stated that the Group Manager refers to the default values from Section 5.2, where further details are specified. As per Section 5.2, those are RECOMMENDED to use as default values, and deviations are allowed. See:

  > For each parameter not specified in the POST request, the Group Manager refers to default values as specified in Section 5.2.

* It is stated that, if the Group Manager uses a default value different from the recommended one for a given parameter, then the Group Manager MUST indicate the chosen, non-default value in its response to the Administrator client. See:

  > If the POST request did not specify certain parameters and the Group Manager used default values different from the ones recommended in Section 5.2.1 and Section 5.2.2, then the response payload MUST also include those parameters, specifying the values chosen by the Group Manager for the current group configuration.

(The same applies to other operation defined in Section 6.4)

<==


2) For error handling, confirm that all CoAP response codes and problem-details payload requirements are specified in a clean, linear way so implementations behave consistently and do not leak unnecessary information.

==>MT

We have re-checked the whole document, and we think that CoAP response codes and problem-details payload requirements are indeed specified in a clean, linear way and as intended.

Please note that error responses from the Group Manager are not necessarily all of the same kind. In fact, they belong to different areas of pertinence.

For example, some requests that result in an error response are bad/unauthorized request from an access control point-of-view, hence they are handled from the perspective of the ACE framework as such, consistent with RFC 9200. In such cases, we are intentionally not using a problem-detail payload. If a payload ought to be present at all, that is actually expected to have Content-Format "application/ace+cbor". Examples of such error responses are:

* In Section 4, the error responses with error code 4.00, 4.01, 4.03, 4.00.

* In Section 6, the 4.03 error response.


Another case is purely transport-related, and simply inherited from the intended use of CoAP and its extensions. While a problem-detail payload is in principle possible to be used here (unless otherwise expected), it is not required by this document. Examples of such error responses are:

* In Section 4.1, the 4.04 error response.

* In Section 6, the 4.05 error response.

* In Section 6.6 and 6.7, the 4.04 error responses.

* In Section 6.7, the 4.09 error response.


Another case is broadly related to a request being malformed. While a problem-detail payload is in principle possible to be used here (unless otherwise expected), it is not required by this document. Examples of such error responses are:

* In Sections 6.3 and 6.7, the 4.00 error responses.


Finally, some requests result in an error response specifically pertaining to an error at the application level, when those requests are processed by one of the resource handlers defined in this document.

For some of those cases, where applicable, we have indeed defined the payload of the error response to have Content-Format "application/concise-problem-details+cbor". That's intended to provide the Administrator client with actionable feedback, again related to actual application-level processing at the resource handlers defined in this document. Examples of such error responses are:

* In Section 6.3, the 5.03 error response, with problem-detail error-id 12 or 11.

* In Sections 6.6 and 6.7, the 5.03 error response, with problem-detail error-id 12.

* In Section 6.6.1, the 5.03 error response, with problem-detail error-id 4 or 9 as specified in the referred Section 6.2 of draft-ietf-ace-key-groupcomm-oscore.

* In Section 6.6.2, the 5.03 error responses, with problem-detail error-id 9 as specified in the referred Sections 9.2 and 9.4 of draft-ietf-ace-key-groupcomm-oscore.

* In Section 6.8, the 4.00 error response, with problem-detail error-id 10.

* In Section 6.8.1, the 4.04 error response, with problem-detail error-id 6.

<==


Regards,

Meir Goldman
FAZON Foundation
[e-mail]
https://fazon.org