Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework
draft-ietf-ace-mqtt-tls-profile-17

Thanks to Jean Mahoney for her ARTART review.  I encourage the authors to respond at least to what she identified as minor issues.

Thanks for resolving my DISCUSS issue.

The final SHOULD in Section 2.4.2 seems weak to me.  I recommend using a non-BCP 14 "should" instead.

** Section 2.

   If the Client is resource-constrained or does not support HTTPS, a
   separate Client Authorization Server may carry out the token request
   on behalf of the Client, and later, onboard the Client with the
   token.  

Appreciating that the CAS is out of scope, I’m trying to understand which of the (A) – (F) interactions are handled by the Client and which would be handled by the CAS.  Figure 1 is a ambiguous.  (A) and (B) seem like they would be covered by the CAS, but I’m assuming (C) and (D) are the Client after being provisioned with the access token (from A and B).  Is that correct?  If so, it would be helpful to clarify that in the text and/or diagram.

** Section 3.3.
   As a response to the SUBSCRIBE packet, the Broker issues a SUBACK.
   For each Topic Filter, the SUBACK packet includes a return code
   matching the QoS level for the corresponding Topic Filter.  In the
   case of failure, the return code is 0x87, indicating that the Client
   is 'Not authorized'.  A reason code is returned for each Topic
   Filter.  

This may be a detail of MQTT.  Does the explicit use of “not authorized” vs. “not authorized/not found” leak the existence of a topic name to an off-path attacker?  It seems that with “not authorized” semantics, one could try to guess topic name with enumeration, say, try 1: “/topic/is-the-sensitive-project-called-A”, try 2: “/topic/is-the-sensitive-project-called-B”, etc.

Editorial Nits 

** Section 1. Editorial. s/The Client-AS and RS-AS/The Client-AS and RS-AS communication/

** Section 1.3.  Editorial.  Chose either the “65535” or “65,535” convention (comma or no comma).  “UTF-8 string” uses the former and “binary data” uses the latter

** Section 1.2. Editorial.  SUBACK.  Describe the who is the sender and receiver like in the other message types.

OLD
Subscribe acknowledgement.

NEW
Subscribe acknowledgement from the Broker to the Client.

** Section 2.  Editorial.
   The token request and
   response use the token endpoint at the AS, specified for HTTP-based
   interactions in Section 5.8 of the ACE framework
   [I-D.ietf-ace-oauth-authz].

This reference should likely read Section 4 of [I-D.ietf-ace-oauth-authz] as this section included the bullet protocol flow from (A) – (E).

** Section 2.3.  Should it be MQTT messages vs. MQTT packets?  For example, in “… to allow a Client’s future PUBLISH and SUBSCRIBE packets”.

** Section 3.3.  Editorial.  s/token token/token scope which/

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "master"; alternatives might be "active", "central", "initiator",
   "leader", "main", "orchestrator", "parent", "primary", "server".

 * Term "his"; alternatives might be "they", "them", "their".

 * Term "invalid"; alternatives might be "not valid", "unenforceable", "not
   binding", "inoperative", "illegitimate", "incorrect", "improper",
   "unacceptable", "inapplicable", "revoked", "rescinded".

Thanks to Theresa Enghardt for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/-D0Fe7Px8IRU5yIFmngv6SR420c).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.1. , paragraph 5, nit:
>    This document follows [RFC7800] for PoP semantics for JWTs (CWTs can
>    also be used).  The PoP token includes a 'cnf' parameter with a

s/can/MAY/ ?

Section 2.2.2. , paragraph 4, nit:
-    DISCONNECT packet as explained below.
+    DISCONNECT packet, as explained below.
+                     +

Section 2. , paragraph 4, nit:
> e RPK case is handled as described in in Section 3.2.1 of the DTLS profile [
>                                    ^^^^^
Possible typo: you repeated a word.

Section 2.2.1. , paragraph 2, nit:
> lient MUST validate a public key from a X.509 certificate or an RPK from the
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.2.1. , paragraph 7, nit:
>  equal to 0, and the token is invalid or the claims cannot be obtained in the
>                                      ^^^
Use a comma before "or" if it connects two independent clauses (unless they are
closely connected and short).

Section 2.2.3. , paragraph 2, nit:
> to an earlier proposal by Fremantle et al [fremantle14]. After sending the C
>                                     ^^^^^
A period is misplaced or missing.

Section 2.2.4.2. , paragraph 3, nit:
>  as shown in Figure 7 and includes the the 8-byte Client nonce, and the signa
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 2.2.5. , paragraph 3, nit:
> ame or filter in question is either an an exact match to or a subset of at le
>                                     ^^^^^
Possible typo: you repeated a word.

Section 2.4.1. , paragraph 3, nit:
> est for topic "a/b/*", and has a token token permits "a/*", this is a valid s
>                                  ^^^^^^^^^^^
Possible typo: you repeated a word.

Section 10.1. , paragraph 23, nit:
>  broker. * Added a statement that the the broker will disconnect on almost an
>                                   ^^^^^^^
Possible typo: you repeated a word.

Uncited references:
     [I-D.ietf-ace-oauth-params], [RFC8422], [RFC7251], and [RFC8705].

Document references draft-ietf-ace-aif-05, but -06 is the latest available
revision.

Document references draft-ietf-ace-pubsub-profile-01, but -04 is the latest
available revision.

These URLs in the document did not return content:
 * http://www.ietf.org/internet-drafts/draft-ietf-ace-pubsub-profile-01.txt

These URLs in the document can probably be converted to HTTPS:
 * http://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html
 * http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
 * http://dx.doi.org/10.1109/SIoT.2014.8