Re: [auth48] AUTH48: RFC-to-be 9431 <draft-ietf-ace-mqtt-tls-profile-17> for your review

[Cigdem Sengul <[e-mail]>]

Hello,
Thank you for the revisions. I only have the following change:

2.2.5.  Broker Token Validation

OLD: i.e., a CWT token uses COSE, while a JWT token uses JOSE.

NEW: i.e., a CWT  uses COSE, while a JWT uses JOSE.

The rest looks great, and after this minor edit, I approve this RFC for
publication.
Thank you very much for all your work.
Kind regards,
--Cigdem


On Tue, 20 Jun 2023 at 22:56, Alanna Paloma <[e-mail]> wrote:

> Hi Cigdem,
>
> Thank you for your reply.  We have updated as requested.
>
> The files have been posted here (please refresh):
>  https://www.rfc-editor.org/authors/rfc9431.xml
>  https://www.rfc-editor.org/authors/rfc9431.txt
>  https://www.rfc-editor.org/authors/rfc9431.html
>  https://www.rfc-editor.org/authors/rfc9431.pdf
>
> The relevant diff files have been posted here:
>  https://www.rfc-editor.org/authors/rfc9431-diff.html (comprehensive diff)
>  https://www.rfc-editor.org/authors/rfc9431-auth48diff.html (AUTH48
> changes)
>
> Please review the document carefully and contact us with any further
> updates you may have.  Note that we do not make changes once a document is
> published as an RFC.
>
> We will await approvals from each party listed on the AUTH48 status page
> below prior to moving this document forward in the publication process.
>
> For the AUTH48 status of this document, please see:
>  https://www.rfc-editor.org/auth48/rfc9431
>
> Thank you,
> RFC Editor/ap
>
>
> > On Jun 20, 2023, at 8:34 AM, Cigdem Sengul <[e-mail]>
> wrote:
> >
> > Thank you for your email. Please see my responses below.
> > --Cigdem
> >
> > On Tue, 20 Jun 2023 at 00:00, <[e-mail]> wrote:
> > Authors,
> >
> > While reviewing this document during AUTH48, please resolve (as
> necessary) the following
> > questions, which are also in the XML file.
> >
> > 1) <!--[rfced] To avoid awkward hyphenation, may we update the title as
> follows?
> >
> > Original:
> > Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication
> > and Authorization for Constrained Environments (ACE) Framework
> >
> > Perhaps:
> > Message Queuing Telemetry Transport (MQTT) and TLS Profile for the
> > Authentication and Authorization for Constrained Environments (ACE)
> > Framework
> > -->
> >
> > I suggest:
> >
> > Message Queuing Telemetry Transport (MQTT) and Transport Layer Security
> (TLS) profile of Authentication
> > and Authorization for Constrained Environments (ACE) Framework
> >
> >
> >
> > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the
> > title) for use on https://www.rfc-editor.org/search. -->
> >
> > publish-subscribe, authorization information format
> >
> >
> >
> > 3) <!--[rfced] Please clarify; how does "and setting up the keying
> material"
> > relate to the rest of the sentence? Is it a second topic for which
> > assumptions are made? Or, should "and" be "while"?
> >
> > Original:
> >    This document makes the same assumptions as Section 4 of the ACE
> >    framework [I-D.ietf-ace-oauth-authz] regarding Client and RS
> >    registration with the AS and setting up the keying material.
> >
> > Perhaps:
> >    This document makes the same assumptions as Section 4 of the ACE
> >    framework [RFC9200] regarding Client and RS registration with the AS
> >    and regarding the setup of the keying material.
> > -->
> >
> >
> > Suggested:
> > This document makes the same assumptions as Section 4 of the ACE
> >    framework [RFC9200] regarding Client and RS registration with the AS
> >    for setting up the keying material.
> >
> >
> > 4) <!--[rfced] Should this instance of "JWT token" be updated to read
> simply as "JWT" to
> > avoid redundancy (if expanded, "JWT token" would read "JSON Web Token
> token")?
> >
> > Original:
> >   A JWT token uses JOSE, while a CWT token uses COSE
> >   [RFC8152] for security protection.
> >
> > Perhaps:
> >   A JWT uses JOSE, while a CWT token uses COSE
> >   [RFC8152] for security protection.
> >
> > Suggested (as the same argument applies to CWT):
> >  A JWT uses JOSE, while a CWT uses COSE
> >   [RFC8152] for security protection.
> >
> >
> >
> > Similarly, should "PSK key be updated to "PSK" (if expanded, "PSK key"
> would read
> > Pre-Shared Key key")?
> >
> > Original:
> >    To use TLS 1.3 with pre-shared keys, the Client utilizes the PSK key
> >    extension specified in [RFC8446] using the key conveyed in the "cnf"
> >    parameter of the AS response.
> >
> > Perhaps:
> >    To use TLS 1.3 with pre-shared keys, the Client utilizes the PSK
> >    extension specified in [RFC8446] using the key conveyed in the "cnf"
> >    parameter of the AS response.
> > -->
> >
> > Yes, accepting the suggestion.
> >
> >
> >
> > 5) <!--[rfced] As "confidentiality" is not a term listed in RFC 4949 but
> "data
> > confidentiality" is listed, we have updated the list below accordingly.
> > Please let us know if further updates are needed.
> >
> > Original:
> >    Certain security-related terms such as "authentication",
> >    "authorization", "confidentiality", "(data) integrity", "message
>
> >    authentication code", and "verify" are taken from [RFC4949].
> >
> > Perhaps:
> >    Certain security-related terms such as "authentication",
> >    "authorization", "data confidentiality", "(data) integrity",
> "message
> >    authentication code", and "verify" are taken from [RFC4949].
> > -->
> >
> > Yes, accepting the suggestion.
> >
> >
> >
> > 6) <!--[rfced] Please clarify; what does "labeled with their topics"
> > refer to?
> >
> > Original:
> >    The Clients are MQTT Clients, which connect to the
> >    Broker to publish and subscribe to Application Messages, labelled
> >    with their topics.
> >
> > Perhaps (if the Clients are labeled):
> >    The Clients are MQTT Clients, which connect to the
> >    Broker to publish and subscribe to Application Messages, and are
> labeled
> >    with their topics.
> >
> > Or (if the Application Messages are labeled):
> >    The Clients are MQTT Clients, which connect to the
> >    Broker to publish and subscribe to Application Messages (which are
> >    labeled with their topics).
> > -->
> >
> > The Or version is correct version and accepted: the Application Messages
> are labeled.
> > (This was written like this because MQTT v5 standard defines Topic Name
> as
> > The label attached to an Application Message which is matched against
> the Subscriptions known to the Server.)
> >
> >
> > 7) <!--[rfced] Should "Connection" be "Network Connection"?
> >
> > Original:
> >   If the Network
> >   Connection is closed without the Client first sending a
> >   DISCONNECT packet with Reason Code 0x00 (Normal
> >   disconnection) and the Connection has a Will Message, the
> >   Will Message is published.
> >
> > Perhaps:
> >   If the Network
> >   Connection is closed without the Client first sending a
> >   DISCONNECT packet with reason code 0x00 (Normal
> >   disconnection) and the Network Connection has a Will Message, the
> >   Will Message is published.
> > -->
> >
> > It should remain as original.
> > This was taken from MQTT v5 document: "If the Network Connection is
> closed without the Client first sending a DISCONNECT packet with Reason
> Code 0x00 (Normal disconnection) and the Connection has a Will Message, the
> Will Message is published".
> > The second "Connection" refers to MQTT Connection.
> >
> > Perhaps if unclear:
> >   If the Network Connection is closed without the Client first sending a
> >   DISCONNECT packet with reason code 0x00 (Normal
> >   disconnection) and the MQTT Connection has a Will Message, the
> >   Will Message is published.
> >
> >
> >
> > 8) <!--[rfced] Figure 1 has been widened slightly for readability;
> > please review. Specifically, a single space was added after
> > (C), (D), (E), and (F), which matches how (A) and (B) appear,
> > and the second lines of labels were indented. The side-by-side diff
> > file is here: https://www.rfc-editor.org/authors/rfc9431-rfcdiff.html
> > -->
> >
> > This is all good.
> >
> >
> >
> > 9) <!--[rfced] Regarding Figure 2, may "Len." be changed to "Len" to
> match
> > other instances within this figure, or is this difference intentional?
> > Also, will it be clear to readers how to read this diagram? Specifically,
> > the "Authentication Method" and "Authentication Data" portions seem
> unclear.
> > -->
> >
> >
> > Please change "Len." to "Len".
> > The figure is explained in  2.2.4.2.
> > Old:
> > To use AUTH, the Client MUST set the Authentication Method as a property
> of a CONNECT packet by using the property identifier 21 (0x15). This is
> followed by a UTF-8-encoded string containing the name of the
> Authentication Method, which MUST be set to "ace". If the Broker does not
> support this profile, it sends a CONNACK packet with reason code 0x8C (Bad
> authentication method).
> >
> > New:
> > Figure 2 shows the Authentication Method and Authentication Data fields
> when the client authenticates using AUTH property. The Client MUST set the
> Authentication Method as a property of a CONNECT packet by using the
> property identifier 21 (0x15). This is followed by a UTF-8-encoded string
> containing the name of the Authentication Method, which MUST be set to
> "ace". If the Broker does not support this profile, it sends a CONNACK
> packet with reason code 0x8C (Bad authentication method).
> >
> >
> >
> > 10) <!-- [rfced] Please review the "type" attribute of each sourcecode
> element
> > in the XML file to ensure correctness. If the current list of preferred
> > values for "type" (
> https://www.rfc-editor.org/materials/sourcecode-types.txt)
> > does not contain an applicable type, then feel free to let us
> > know. Also, it is acceptable to leave the "type" attribute not
> > set.
> >
> > In addition, review each artwork element. Specifically,
> > should any artwork element be tagged as sourcecode or another
> > element?
> >  -->
> >
> > "cddl" type is correct for the artwork in Figure 8.
> >
> > Fig 9 should be tagged with "sourcecode", with type "json".
> >
> > There is no other artwork to be tagged as source code.
> >
> >
> >
> > 11) <!--[rfced] As "PINGREQ" is defined in Section 1.3, we have updated
> > "PINGREQUEST" to "PINGREQ". Please let us know if further updates are
> needed.
> >
> > Original:
> >   The Broker SHOULD check
> >   for token expiration on receiving a PINGREQUEST.
> >
> > Current:
> >   The Broker SHOULD check
> >   for token expiration on receiving a PINGREQ packet.
> > -->
> >
> > Thank you.
> >
> >
> >
> > 12) <!--[rfced] Do you agree with these changes (added 'the',
> capitalized 'Client'
> > to match usage within the document)? If so, we will ask IANA to update
> the
> > description in the registry (
> https://www.iana.org/assignments/media-type-sub-parameters/)
> > accordingly.
> >
> > Original: Permissions for MQTT client as defined in ...
> >
> > Current:  Permissions for the MQTT Client as defined in ...
> > -->
> >
> > That is OK.
> >
> > 13) <!--[rfced] Please clarify the last part of this sentence;
> specifically,
> > what does the "which" clause describe? Is it the transport tokens that
> > the Broker may need to store until they expire?
> >
> > Original:
> >    If the Broker supports the public
> >    "authz-info" topic, described in Section 2.2.2, then this may be
> >    vulnerable to a DDoS attack, where many Clients use the "authz-info"
> >    public topic to transport tokens that are not meant to be used, and
> >    which the Broker may need to store until the tokens expire.
> >
> > Perhaps:
> >    If the Broker supports the public
> >    "authz-info" topic, described in Section 2.2.2, then this may be
> >    vulnerable to a DDoS attack, where many Clients use the "authz-info"
> >    public topic to to transport tokens that are not meant to be used
> >    and that the Broker may need to store until they expire.
> > -->
> >
> > Yes, it is the tokens that need to be stored. Accepting the suggestion.
> >
> >
> > 14) <!--[rfced] RFC 7525 has been obsoleted by RFC 9325, and RFC 8152
> has been
> > obsoleted by RFC 9052. May these references be updated accordingly?
> >
> > RFC 7525 is cited once:
> >    For TLS 1.2, however, a client
> >    MUST support TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 for PSKs [RFC8442]
> >    and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for RPKs [RFC8422], as
> >    recommended in [RFC7525] (and adjusted to be a PSK cipher suite as
> >    appropriate).
> >
> > RFC 8152 is cited once:
> >    A JWT token uses JOSE, while a CWT token uses COSE
> >    [RFC8152] for security protection.
> > -->
> >
> >
> > Yes, please.
> >
> >
> > 15) <!-- [rfced] FYI, we have added expansions for the following
> abbreviations
> > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> > expansion in the document carefully to ensure correctness.
> >
> > Concise Binary Object Representation (CBOR)
> > JSON Web Encryption (JWE)
> > -->
> >
> > Correct.
> >
> >
> > 16) <!--[rfced] We have made the following terminology capitalized for
> consistency.
> > Please review this occurrences carefully and let us know if further
> updates
> > are necessary.
> >
> > Will
> > Will Delay Interval
> > Will Flag
> > Will Message
> > Will Properties
> > Will Retain
> > Will Topic
> > Will QoS
> > -->
> >
> > All capitalizations are correct.
> >
> >
> > 17) <!--[rfced] Throughout the text, the following terminology appears
> to be used inconsistently.
> >
> > a) We have updated to use the form on the right. Please let us know of
> any objections.
> >
> > Control Packet / control packet
> > Fixed Header / fixed header
> > password / Password
> > Payload / payload
> > username / Username
> > Variable Header / variable header
> >
> > "Control Packet", "Fixed Header", and "Variable Header" are capitalized
> in the MQTTv5 specification and, therefore, were capitalised here. (Source:
> https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html)
> >
> > Password - capital is correct.
> >
> > "Username" is "User Name" in MQTTv5, and would be good if we keep the
> same field names exactly as the MQTT protocol specifies in their
> specification.
> > (I acknowledge that the original text did not do a consistent job of
> that).
> >
> > b) Please review the terms below and let us know if/how they may be made
> consistent.
> >
> > Session vs. session
> > Subscription vs. subscription
> > -->
> >
> > For session, the following need to be capitalised:
> > Section 1.3
> > Old:
> >  A Subscription comprises a Topic Filter and a maximum QoS. A
> Subscription is associated with a single session.
> > New:
> >   A Subscription comprises a Topic Filter and a maximum QoS. A
> Subscription is associated with a single Session.
> >
> > Section 2.2.4.1
> > Old: The Connect flags in the variable header specify the properties of
> the MQTT session.
> > New: The Connect flags in the variable header specify the properties of
> the MQTT Session.
> >
> > Old: In MQTT v5.0, the Client signals a clean session (i.e., that the
> session does not continue an existing session) by setting the Clean Start
> flag to 1 in the CONNECT packet. In this profile, the Client SHOULD always
> start with a clean session. The Broker MAY also signal that it does not
> support session continuation by setting the Session Expiry Interval to 0 in
> the CONNACK. If the Broker starts a clean session, the Broker MUST set the
> Session Present flag to 0 in the CONNACK packet to signal this to the
> Client.
> >
> > New: In MQTT v5.0, the Client signals a new Session (i.e., that the
> Session does not continue an existing Session) by setting the Clean Start
> flag to 1 in the CONNECT packet. In this profile, the Client SHOULD always
> start with a new Session. The Broker MAY also signal that it does not
> support the continuation of an existing Session by setting the Session
> Expiry Interval to 0 in the CONNACK. If the Broker starts a new Session,
> the Broker MUST set the Session Present flag to 0 in the CONNACK packet to
> signal this to the Client.
> > --------
> > Old: The Broker MAY support session continuation, e.g., if the Broker
> requires it for QoS reasons. In this case, if a CONNECT packet is received
> with Clean Start set to 0 and there is a Session associated with the Client
> Identifier, the Broker MUST resume communications with the Client based on
> the state from the existing Session. In its response, the Broker MUST set
> the Session Present flag to 1 in the CONNACK packet to signal session
> continuation to the Client. The session state stored by the Client and the
> Broker is described in Section 5.
> >
> > New: The Broker MAY support continuing an existing Session, e.g., if the
> Broker requires it for QoS reasons. In this case, if a CONNECT packet is
> received with Clean Start set to 0, and there is a Session associated with
> the Client Identifier, the Broker MUST resume communications with the
> Client based on the state from the existing Session. In its response, the
> Broker MUST set the Session Present flag to 1 in the CONNACK packet to
> signal the continuation of an existing Session to the Client. The Session
> State stored by the Client and the Broker is described in Section 5.
> >
> > Old: When reconnecting to a Broker that supports session continuation,
> the Client MUST still provide a token in addition to using the same Client
> Identifier and setting the Clean Start to 0. The Broker MUST still perform
> PoP validation on the provided token. If the token matches the stored
> state, the Broker MAY skip introspecting a token-by-reference and use the
> stored introspection result. The Broker MUST also verify the Client is
> authorized to receive or send MQTT packets that are pending transmission.
> When a Client connects with a long Session Expiry Interval, the Broker may
> need to maintain the Client's MQTT session state after it disconnects for
> an extended period. Brokers SHOULD implement administrative policies to
> limit misuse.
> >
> > New: When reconnecting to a Broker that supports continuing existing
> Sessions, the Client MUST still provide a token in addition to using the
> same Client Identifier and setting the Clean Start to 0. The Broker MUST
> still perform PoP validation on the provided token. If the token matches
> the stored state, the Broker MAY skip introspecting a token-by-reference
> and use the stored introspection result. The Broker MUST also verify the
> Client is authorized to receive or send MQTT packets that are pending
> transmission. When a Client connects with a long Session Expiry Interval,
> the Broker may need to maintain the Client's MQTT Session State after it
> disconnects for an extended period. Brokers SHOULD implement administrative
> policies to limit misuse.
> > ------
> > Old: Note that, according to the MQTT standard, the Broker uses the
> Client Identifier to identify the session state. In the case of a Client
> Identifier collision, a Client may take over another Client's session.
> >
> > New: Note that, according to the MQTT standard, the Broker uses the
> Client Identifier to identify the Session State. In the case of a Client
> Identifier collision, a Client may take over another Client's Session.
> > ---------
> > Section 2.4.2
> > Old: If the Broker starts a new session, it MUST also set Session
> Present to 0 in the CONNACK packet to signal a clean session to the Client.
> Otherwise, it MUST set Session Present to 1.
> >
> > New: If the Broker starts a new Session, it MUST also set Session
> Present to 0 in the CONNACK packet to signal a new Session to the Client.
> Otherwise, it MUST set Session Present to 1.
> >
> > Section 5
> > Old: In the case of a Client DISCONNECT, if the Session Expiry Interval
> is set to 0, the Broker doesn't maintain session state but MUST keep the
> retained messages. If the Broker maintains session state, the state MAY
> include the token and its introspection result (for reference tokens) in
> addition to the MQTT session state. The MQTT session state is identified by
> the Client Identifier and includes the following:
> >
> > the Client subscription state,
> >
> > New:
> > In the case of a Client DISCONNECT, if the Session Expiry Interval is
> set to 0, the Broker doesn't store the Session State but MUST keep the
> retained messages. If the Broker stores the Session State, the state MAY
> include the token and its introspection result (for reference tokens) in
> addition to the MQTT Session State. The MQTT Session State is identified by
> the Client Identifier and includes the following:
> >
> > the Client Subscriptions,
> > ----
> > Old:
> >    * if the Session is currently not connected, the time at which the
> Session will end and session state will be discarded.
> > The token/introspection state is not part of the MQTT session state, and
> PoP validation is required for each new connection, regardless of whether
> MQTT session continuation is used.
> >
> > New:
> > * if the Session is currently not connected, the time at which the
> Session will end and the Session State will be discarded.
> > The token/introspection state is not part of the MQTT Session State, and
> PoP validation is required for each new connection, regardless of whether
> existing MQTT Sessions are continued.
> >
> > (Note that Session State is capitalised in MQTT Spec.)
> >
> > Section 6.1
> > Old:  The Client SHOULD set the Clean flag to 1 to always start a new
> session. If the Clean flag is set to 0, the Broker MUST resume
> communications with the Client based on the state from the current Session
> (as identified by the Client Identifier). If there is no Session associated
> with the Client Identifier, the Broker MUST create a new session. The
> Broker MUST set the Session Present flag in the CONNACK packet accordingly,
> i.e., 0 to indicate a clean session to the Client and 1 to indicate session
> continuation. The Broker MUST still perform PoP validation on the provided
> Client token. MQTT v3.1.1 does not use a Session Expiry Interval, and the
> Client expects that the Broker maintains the session state after it
> disconnects. However, the stored session state can be discarded as a result
> of administrator action or policies (e.g., defining an automated response
> based on storage capabilities), and Brokers SHOULD implement administrative
> policies to limit misuse.
> >
> > New: The Client SHOULD set the Clean flag to 1 to always start a new
> Session. If the Clean flag is set to 0, the Broker MUST resume
> communications with the Client based on the state from the current Session
> (as identified by the Client Identifier). If there is no Session associated
> with the Client Identifier, the Broker MUST create a new Session. The
> Broker MUST set the Session Present flag in the CONNACK packet accordingly,
> i.e., 0 to indicate a new Session to the Client and 1 to indicate that the
> existing Session is continued. The Broker MUST still perform PoP validation
> on the provided Client token. MQTT v3.1.1 does not use a Session Expiry
> Interval, and the Client expects that the Broker maintains the Session
> State after it disconnects. However, the stored Session State can be
> discarded as a result of administrator action or policies (e.g., defining
> an automated response based on storage capabilities), and Brokers SHOULD
> implement administrative policies to limit misuse.
> >
> > Section 6.2
> > Old: Therefore, the Broker will disconnect on almost any error and may
> not keep the session state, necessitating that clients make a greater
> effort to ensure that tokens remain valid and do not attempt to publish to
> topics that they do not have permissions for.
> >
> > New: Therefore, the Broker will disconnect on almost any error and may
> not keep the Session State, necessitating that clients make a greater
> effort to ensure that tokens remain valid and do not attempt to publish to
> topics that they do not have permissions for.
> >
> > Section 8
> > Old: After the Broker validates an access token and accepts a connection
> from a client, it caches the token to authorize a Client's publish and
> subscribe requests in an ongoing session.
> >
> > New: After the Broker validates an access token and accepts a connection
> from a client, it caches the token to authorize a Client's publish and
> subscribe requests in an ongoing Session.
> >
> > Old: For MQTT v5.0, when a Client connects with a long Session Expiry
> Interval, the Broker may need to maintain the Client's MQTT session state
> after it disconnects for an extended period. For MQTT v3.1.1, the session
> state may need to be stored indefinitely, as it does not have a Session
> Expiry Interval feature. The Broker SHOULD implement administrative
> policies to limit misuse of the session continuation by the Client.
> >
> > New: For MQTT v5.0, when a Client connects with a long Session Expiry
> Interval, the Broker may need to maintain the Client's MQTT Session State
> after it disconnects for an extended period. For MQTT v3.1.1, the Session
> State may need to be stored indefinitely, as it does not have a Session
> Expiry Interval feature. The Broker SHOULD implement administrative
> policies to limit misuse by the Client resulting from continuing existing
> Sessions.
> >
> > =====================================
> > All "subscription" instances are to be capitalised to "Subscription"
> with the following exceptions, which suggest additional changes following
> MQTT specification:
> >
> > Section 3.2
> > Old: To forward PUBLISH packets to the subscribing Clients, the Broker
> identifies all the subscribers that have valid matching topic subscriptions
> to the Topic Name of the PUBLISH packet (i.e., the tokens are valid, and
> token scopes allow a subscription to this particular Topic Name).
> >
> > New: To forward PUBLISH packets to the subscribing Clients, the Broker
> identifies all the subscribers that have valid matching Topic Subscriptions
> to the Topic Name of the PUBLISH packet (i.e., the tokens are valid, and
> token scopes allow a Subscription to this particular Topic Name).
> > ---------------------
> > Section 3.3
> > Old: For example, if the Client sends a subscription request for topic
> "a/b/*" and has a token that permits "a/*", this is a valid subscription
> request, as "a/b/*" is a subset of "a/*". (The process is similar to a
> Broker matching the Topic Name in a PUBLISH packet against the
> Subscriptions known to the Server.)
> >
> > New: For example, if the Client sends a SUBSCRIBE request for topic
> "a/b/*" and has a token that permits "a/*", this is a valid SUBSCRIBE
> request, as "a/b/*" is a subset of "a/*". (The process is similar to a
> Broker matching the Topic Name in a PUBLISH packet against the
> Subscriptions known to the Server.)
> > -------------------------------
> >
> >
> >
> > 18) <!-- [rfced] Please review the "Inclusive Language" portion of the
> online
> > Style Guide <
> https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> > and let us know if any changes are needed.
> >
> > Note that our script did not flag any words in particular, but this
> should still
> > be reviewed as a best practice.
> > -->
> >
> > This was reviewed earlier, and no issues are expected.
> >
> > Please let me know if i need to make further clarifications.
> > Kind regards,
> > --Cigdem
> >
> > On Jun 19, 2023, [e-mail] wrote:
> >
> > *****IMPORTANT*****
> >
> > Updated 2023/06/19
> >
> > RFC Author(s):
> > --------------
> >
> > Instructions for Completing AUTH48
> >
> > Your document has now entered AUTH48.  Once it has been reviewed and
> > approved by you and all coauthors, it will be published as an RFC.
> > If an author is no longer available, there are several remedies
> > available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> >
> > You and you coauthors are responsible for engaging other parties
> > (e.g., Contributors or Working Group) as necessary before providing
> > your approval.
> >
> > Planning your review
> > ---------------------
> >
> > Please review the following aspects of your document:
> >
> > *  RFC Editor questions
> >
> >   Please review and resolve any questions raised by the RFC Editor
> >   that have been included in the XML file as comments marked as
> >   follows:
> >
> >   <!-- [rfced] ... -->
> >
> >   These questions will also be sent in a subsequent email.
> >
> > *  Changes submitted by coauthors
> >
> >   Please ensure that you review any changes submitted by your
> >   coauthors.  We assume that if you do not speak up that you
> >   agree to changes submitted by your coauthors.
> >
> > *  Content
> >
> >   Please review the full content of the document, as this cannot
> >   change once the RFC is published.  Please pay particular attention to:
> >   - IANA considerations updates (if applicable)
> >   - contact information
> >   - references
> >
> > *  Copyright notices and legends
> >
> >   Please review the copyright notice and legends as defined in
> >   RFC 5378 and the Trust Legal Provisions
> >   (TLP – https://trustee.ietf.org/license-info/).
> >
> > *  Semantic markup
> >
> >   Please review the markup in the XML file to ensure that elements of
> >   content are correctly tagged.  For example, ensure that <sourcecode>
> >   and <artwork> are set correctly.  See details at
> >   <https://authors.ietf.org/rfcxml-vocabulary>.
> >
> > *  Formatted output
> >
> >   Please review the PDF, HTML, and TXT files to ensure that the
> >   formatted output, as generated from the markup in the XML file, is
> >   reasonable.  Please note that the TXT will have formatting
> >   limitations compared to the PDF and HTML.
> >
> >
> > Submitting changes
> > ------------------
> >
> > To submit changes, please reply to this email using ‘REPLY ALL’ as all
> > the parties CCed on this message need to see your changes. The parties
> > include:
> >
> >   *  your coauthors
> >
> >   *  [e-mail] (the RPC team)
> >
> >   *  other document participants, depending on the stream (e.g.,
> >      IETF Stream participants are your working group chairs, the
> >      responsible ADs, and the document shepherd).
> >
> >   *  [e-mail], which is a new archival mailing list
> >      to preserve AUTH48 conversations; it is not an active discussion
> >      list:
> >
> >     *  More info:
> >
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >
> >     *  The archive itself:
> >        https://mailarchive.ietf.org/arch/browse/auth48archive/
> >
> >     *  Note: If only absolutely necessary, you may temporarily opt out
> >        of the archiving of messages (e.g., to discuss a sensitive
> matter).
> >        If needed, please add a note at the top of the message that you
> >        have dropped the address. When the discussion is concluded,
> >        [e-mail] will be re-added to the CC list and
> >        its addition will be noted at the top of the message.
> >
> > You may submit your changes in one of two ways:
> >
> > An update to the provided XML file
> > — OR —
> > An explicit list of changes in this format
> >
> > Section # (or indicate Global)
> >
> > OLD:
> > old text
> >
> > NEW:
> > new text
> >
> > You do not need to reply with both an updated XML file and an explicit
> > list of changes, as either form is sufficient.
> >
> > We will ask a stream manager to review and approve any changes that seem
> > beyond editorial in nature, e.g., addition of new text, deletion of
> text,
> > and technical changes.  Information about stream managers can be found
> in
> > the FAQ.  Editorial changes do not require approval from a stream
> manager.
> >
> >
> > Approving for publication
> > --------------------------
> >
> > To approve your RFC for publication, please reply to this email stating
> > that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> > as all the parties CCed on this message need to see your approval.
> >
> >
> > Files
> > -----
> >
> > The files are available here:
> >   https://www.rfc-editor.org/authors/rfc9431.xml
> >   https://www.rfc-editor.org/authors/rfc9431.html
> >   https://www.rfc-editor.org/authors/rfc9431.pdf
> >   https://www.rfc-editor.org/authors/rfc9431.txt
> >
> > Diff file of the text:
> >   https://www.rfc-editor.org/authors/rfc9431-diff.html
> >   https://www.rfc-editor.org/authors/rfc9431-rfcdiff.html (side by side)
> >
> > Diff of the XML:
> >   https://www.rfc-editor.org/authors/rfc9431-xmldiff1.html
> >
> > The following files are provided to facilitate creation of your own
> > diff files of the XML.
> >
> > Initial XMLv3 created using XMLv2 as input:
> >   https://www.rfc-editor.org/authors/rfc9431.original.v2v3.xml
> >
> > XMLv3 file that is a best effort to capture v3-related format updates
> > only:
> >   https://www.rfc-editor.org/authors/rfc9431.form.xml
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> >   https://www.rfc-editor.org/auth48/rfc9431
> >
> > Please let us know if you have any questions.
> >
> > Thank you for your cooperation,
> >
> > RFC Editor
> >
> > --------------------------------------
> > RFC9431 (draft-ietf-ace-mqtt-tls-profile-17)
> >
> > Title            : Message Queuing Telemetry Transport (MQTT)-TLS
> profile of Authentication and Authorization for Constrained Environments
> (ACE) Framework
> > Author(s)        : C. Sengul, A. Kirby
> > WG Chair(s)      : Daniel Migault, Loganaden Velvindron
> > Area Director(s) : Roman Danyliw, Paul Wouters
>
>