I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational and manageability aspects of the IETF drafts. 

This documents defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework which depends on the following specifications:

- RFC 7252 for Constrained Application Protocol specification
- RFC 8613 for Object Security for Constrained RESTful Environments
- RFC 9052 and 9053 for CBOR Object Signing and Encryption
- RFC 9200 for Authentication and Authorization
- RFC 9254 for Key Provisioning for Group Communication 
- draft-ietf-core-oscore-groupcomm for Group Object Security

I have been studying these documents, its relationships in order to understand how operational and manageability aspects are addressed to understand how draft-ietf-ace-key-groupcomm-oscore as application profile for authentication and authorization fit in and failed to do so because none of the above mentioned documents describe the operational and manageability aspect as described in https://datatracker.ietf.org/doc/html/draft-opsarea-rfc5706bis#section-3.

To my current understanding, none of these documents describe or refer to configuration models or how the defined protocols and mechanisms can be monitored.

Here my feedback to the document:

In section 1.1 terminology, the term "Monitor" is being defined and referred to "silent server" in draft-ietf-core-oscore-groupcomm. Why is a different term being used? Both document fails to describe the role and intend of that function. For instance in "Signature verifier" it states "intended to verify the signature of messages exchanged".

In section 2 it describes "A network node can join an OSCORE group by interacting with the responsible Group Manager. Once registered in the group". My understanding is based from reading RFC 9594 that the intent is to support multiple application profiles where draft-ietf-ace-key-groupcomm-oscore describes one.

The documents misses to describe under normal operation:

- How can network operation verify which network nodes joined an OSCORE group successfully and which application profile has been used?
- How can network operation determine that there were unsuccessful attempts in the past and from which network nodes at which time.
- How does "Monitor" resp. "silent server" contribute to a troubleshooting process?

Throughout the document error codes such as

https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-18#section-6.2

- The Group Manager MUST reply with a 5.03 (Service Unavailable) error response in the following cases
- The Group Manager MUST reply with a 4.00 (Bad Request) error response in the following cases:
- the Group Manager MAY reply with a 4.00 (Bad Request) error response in case all the following conditions hold:

are used but no references are given where those error codes are being defined.

To my understanding they relate to https://www.rfc-editor.org/rfc/rfc7252#section-5.9 and a description in section 2, "Protocol Overview", describing that Response Code Definitions from https://www.rfc-editor.org/rfc/rfc7252#section-5.9 are used, is required to understand error code meaning and relationship to the CoAP protocol.

What is unclear to me is how besides a CoAP client an operator would have visibility in the individual errors, are they logged?, or how an operator could obtain a statistical view on the errors occurring.

For an statistical example, the CoAP Management Interface, https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-20#section-6 describes the error handling and how they are represented statistically in a data model. To my current understanding, this is missing in context of the Authentication and Authorization for Constrained Environments (ACE) framework.

Best wishes
Thomas Graf