2.2.2 - para 1, the last sentence seems to imply that the first connection to publish to authz-info is not being done over a TLS connection. But the sentence before that states that a TLS connection MUST be used for this. Perhaps s/and is expected to try reconnecting over TLS./and reconnects, potentially using client authentication with TLS./
2.2.2 - I am unclear under what circumstances you could end put with a token which does not parse when processing a PUBLISH message. If the token cannot be parsed at connection time, that I can understand. However having parsed the token then it does not make sense that the token becomes not parsable at the time of publishing. Am I missing something? 2.2.2 - The last paragraph is causing me confusion. Is this supposed to be referencing the RS or the AS? If it is the AS, then I don't see how there could be any confusion. Please expand this so it is clearer. 2.2.4 - I am having a problem with trying to parse the content of the AUTH property. I have no problems with 2.2.4.3 because this is a zero length sequence of bytes. However for 2.2.4.1 and 2.2.4.2 there is a token (possibly binary with no length prefix) followed by an optional binary cryptographic value. For introspection, I would need to figure out the length of the token before I could make a guess at the length of the cryptographic value. However given that there is no divider this does not seem possible. This may also become a problem for the response from the client in the event that there is a change from an 8-byte nonce to a variable length one. 2.2.4.1 - In my view it is not the secret, but the content that is being obtained from the TLS exporter. That is one is signing (or MACing) the exporter value not using that value to compute a MAC on something else. While it is true that only the two parties know that value, exposure to a third party does not lead to a compromise. 2.2.4.3 - I am not sure if the text is supposed to require an empty authentication data field or to allow for the authentication data field to be absent as well. 3 - It might be worth while to put a pointer to section 4.7 of the MQTT V5 spec here so that there is an indication of what the different wild card characters do. I had to pop over there to make sure that I could figure it out. 3.1 - Should you state that for a QoS of 0, the client should close the connection w/ an '0x87' in the event of an authorization failure? I think that this is supposed to happen but you have left it open. 6 - It is not clear to me if the authentication method described in this section is permitted with MQTT v5 or not. It does not say, but it appears to be a true statement. This should probably be explicit. 2.2.4.3 - What is the name of the user property that is being returned here? I am going to play with something else. I am sure I will find other issues at a different time. Jim Nits: Section 2 Para 1 s/Broker.Figure 1/Broker. Figure 1/ Section 2 Para 1 s/setup.The/setup. The/ Section 2.2.2 Last Para s/when the AS/when the RS/ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
