Original text:
response for the client.  The access token MUST be bound to the RPK of the client by means of the "cnf" claim. <del> The response MUST contain an "ace_profile" parameter if the"ace_profile" parameter in the request is empty, and MAY contain this parameter otherwise (see Section 5.8.2 of I-D.ietf-ace-oauth- authz).  This parameter is set to "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server.  The response also contains an access token with information for the resource server about the client's public key. The authorization server MUST return in its response the parameter </del>  "rs_cnf" unless it is certain that the client already knows the public key of the resource server.  The authorization server MUST ascertain that the RPK specified in "rs_cnf" belongs to the resource any re-coding.  This allows the resource server to retrieve the shared secret directly from the "cnf" claim of the access token.  If a resource server receives a ClientKeyExchange message that contains a "psk_identity" with a length greater than zero, it MUST parse the contents of the "psk_identity" field as CBOR data structure provide similar forward-secrecy properties to using ephemeral Diffie- Hellman (DHE) key exchange mechanisms.  For longer-lived access tokens, DHE cipher suites should be used, i.e., cipher suites of the <del> form TLS_DHE_PSK_*. </del>  Constrained devices that use DTLS RFC6347 are inherently vulnerable to Denial of Service (DoS) attacks as the handshake protocol requires

Reviewer comments:
It is perhaps a stretch to call the description of using a for DLTS 1.3 as "editorial", but it really is the analogous way to do it, so this seems like just some additional exposition and not new content. I think that it will be okay to just include this in the XML file provided to the RFC Editor when they ask for one after approval.

Revised text:
response for the client.  The access token MUST be bound to the RPK of the client by means of the "cnf" claim.  <ins> The response MUST contain an "ace_profile" parameter if the "ace_profile" parameter in the request is empty, and MAY contain this parameter otherwise (see Section 5.8.2 of I-D.ietf-ace-oauth-authz). This parameter is set to "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server.  The response also contains an access token with information for the resource server about the client's public key.  The authorization server MUST return in its response the parameter </ins> "rs_cnf" unless it is certain that the client already knows the public key of the resource server.  The authorization server MUST ascertain that the RPK specified in "rs_cnf" belongs to the resource any re-coding.  This allows the resource server to retrieve the shared secret directly from the "cnf" claim of the access token. <ins> DTLS 1.3 does not use the ClientKeyExchange message; for DTLS 1.3, the access token is placed in the "identity" field of a "PskIdentity" within the "PreSharedKeyExtension" of the "ClientHello". </ins> If a resource server receives a ClientKeyExchange message that contains a "psk_identity" with a length greater than zero, it MUST parse the contents of the "psk_identity" field as CBOR data structure provide similar forward-secrecy properties to using ephemeral Diffie- Hellman (DHE) key exchange mechanisms.  For longer-lived access tokens, DHE cipher suites should be used, i.e., cipher suites of the  <ins> form TLS_DHE_PSK_* or TLS_ECDHE_PSK_*. </ins> Constrained devices that use DTLS RFC6347 are inherently vulnerable to Denial of Service (DoS) attacks as the handshake protocol requires