jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-ace-dtls-authorize

Commentary: 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 .
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
"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
server that the client wants to communicate with.  The authorization
server MUST protect the integrity of the access token such that the
resource server can detect unauthorized changes.  If the access token
contains confidential data, the authorization server MUST also
protect the confidentiality of the access token.
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
"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
server that the client wants to communicate with.  The authorization
server MUST protect the integrity of the access token such that the
resource server can detect unauthorized changes.  If the access token
contains confidential data, the authorization server MUST also
protect the confidentiality of the access token.
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".
form TLS_DHE_PSK_*.
form TLS_DHE_PSK_* or TLS_ECDHE_PSK_*.
Draft: draft-ietf-ace-dtls-authorize

Commentary: Change last sentence of Introduction from : While other formats could be used as well these are out of scope for this document . to : While other formats could be used as well , those are out of scope for this document . 
 Good point , thank you !
As recommended in Section 5.8 of I-D.ietf-ace-oauth-authz, this
specification uses CBOR web tokens to convey claims within an access
token issued by the server.  While other formats could be used as
well these are out of scope for this document.
As recommended in Section 5.8 of I-D.ietf-ace-oauth-authz, this
specification uses CBOR web tokens to convey claims within an access
token issued by the server.  While other formats could be used as
well, those are out of scope for this document.
Draft: draft-ietf-ace-dtls-authorize

Commentary: This change addresses the issue raised by among the authors that it is worth mentioning This is already addressed in the framework document but to avoid implementation errors it seems worth mentioning here as well . 
 Merged as two other authors have agreed .
The client cannot always know a priori if an Authorized Resource
Request will succeed.  If the client repeatedly gets error responses
containing AS Creation Hints (cf.  Section 5.1.2 of I-D.ietf-ace-
oauth-authz as response to its requests, it SHOULD request a new
access token from the authorization server in order to continue
communication with the resource server.
The client cannot always know a priori if an Authorized Resource
Request will succeed.  It must check the validity of its keying
material before sending a request or processing a response.  If the
client repeatedly gets error responses containing AS Creation Hints
(cf.  Section 5.1.2 of I-D.ietf-ace-oauth-authz as response to its
requests, it SHOULD request a new access token from the authorization
server in order to continue communication with the resource server.