jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-ace-mqtt-tls-profile

Commentary: Let 's assume we 're talking about what the AS puts in the token ( not the token response ) . That means that " cnf " always has to be present . The flow where " cnf " is only required in the symmetric case and is optional for the asymmetric case is the use of the " cnf " parameter in the token response , from AS to client .
This document follows RFC7800 for PoP semantics for JWTs (CWTs MAY
also be used).  The AS includes a "cnf" (confirmation) parameter to
the PoP token, to declare that the Client possesses a particular key
and RS can cryptographically confirm that the Client has possession
of that key.  The "cnf" parameter is REQUIRED if a symmetric key is
used, and MAY be present for asymmetric PoP keys, as described in I-
D.ietf-ace-oauth-params.
This document follows RFC7800 for PoP semantics for JWTs (CWTs MAY
also be used).  The AS includes a "cnf" (confirmation) parameter in
the PoP token, to declare that the Client possesses a particular key
and RS can cryptographically confirm that the Client has possession
of that key, as described in I-D.ietf-ace-oauth-params.
Draft: draft-ietf-ace-mqtt-tls-profile

Commentary: Thanks  ! I 'll go clear my DISCUSS :) 
 I see . These did n't cause a problem on my side .
Description/Specification: Topic Filter as defined in mqtt-defs.
Description/Specification: Topic Filter as defined in scope.
Description/Specification: Permissions for MQTT client.  Tperm is
a string with a value either "pub" or "sub".
Description/Specification: Permissions for MQTT client as defined
in scope.  Tperm is an array of one or more text strings that each
have a value of either "pub" or "sub".
Draft: draft-ietf-ace-mqtt-tls-profile

Commentary: I believe this " if you 're happy with it now we 're ( assumed ) targetting MQTT v5.0 we should refer to Clean Start acknowledge that RETAINed messages could be made irrelevant by further publishes 
 yes , that 's much better , thanks ! ( see ) 
 Section 2.5 - The last sentence in the first paragraph could be state more clearly . Specifically there would appear to be some ambiguity on who the associated tokens are attached to . " messages as long as the publisher token for that message remains valid . " Might be better . 
 Better working might to " the retailed message until the token for that message has expired , " That avoids the question if all of the tokens have expired or just the one with the message .
In the case of a Client DISCONNECT, due to the Clean Session flag,
the Broker deletes all session state but MUST keep the retained
messages.  By setting a RETAIN flag in a PUBLISH message, the
publisher indicates to the Broker that it should store the most
recent message for the associated topic.  Hence, the new subscribers
can receive the last sent message from the publisher of that
particular topic without waiting for the next PUBLISH message.  The
Broker MUST continue publishing the retained messages as long as the
associated tokens are valid.
In the case of a Client DISCONNECT, due to the Clean Start flag (or
Clean Session flag with MQTT v3.1.1), the Broker deletes all session
state but MUST keep the retained messages and token expiry
information.  By setting a RETAIN flag in a PUBLISH message, the
publisher indicates to the Broker that it should store the most
recent message for the associated topic.  Hence, new subscribers can
receive the most recent message from the publisher of that particular
topic without waiting for the next PUBLISH message.  The Broker MUST
continue publishing each retained message until the token for that
message has expired, or another RETAIN message is published on the
associated topic.
Draft: draft-ietf-ace-mqtt-tls-profile

Commentary: fixed ID reference to ietf - ace - dtls - authorize doing this first so it 'll build from makefile ( 
 The correct reference is I - D.ietf - ace - dtls - authorize and not I - D.gerdes - ace - dtls - authorize .
This section describes how the Client transports the token to the
Broker (RS) via the CONNECT control message after the TLS handshake.
This is similar to an earlier proposal by Fremantle et al.
fremantle14.  Alternatively, the token may be used for the TLS
session establishment as described in the I-D.gerdes-ace-dtls-
authorize.  In this case, both the TLS PSK and RPK handshakes MAY be
supported.  This may additionally require that the Client transports
the token to the Broker before the connection establishment.  To this
end, the Broker MAY support /authz-info endpoint via the "authz-info"
topic.  Then, to transport the token, Clients publish to "authz-info"
topic unauthorized.  The topic "authz-info" MUST be publish-only for
Clients (i.e., the Clients are not allowed to subscribe to it).  This
option is described in more detail in app-authzinfo.
This section describes how the Client transports the token to the
Broker (RS) via the CONNECT control message after the TLS handshake.
This is similar to an earlier proposal by Fremantle et al.
fremantle14.  Alternatively, the token may be used for the TLS
session establishment as described in the I-D.ietf-ace-dtls-
authorize.  In this case, both the TLS PSK and RPK handshakes MAY be
supported.  This may additionally require that the Client transports
the token to the Broker before the connection establishment.  To this
end, the Broker MAY support /authz-info endpoint via the "authz-info"
topic.  Then, to transport the token, Clients publish to "authz-info"
topic unauthorized.  The topic "authz-info" MUST be publish-only for
Clients (i.e., the Clients are not allowed to subscribe to it).  This
option is described in more detail in app-authzinfo.