Let's see if I can get the mailing list right this time -----Original Message----- From: Jim Schaad <i...@augustcellars.com> Sent: Monday, June 8, 2020 3:02 PM To: 'draft-ietf-ace-mqtt-tls-prof...@ietf.org' <draft-ietf-ace-mqtt-tls-prof...@ietf.org> Cc: 'c...@ietf.org' <c...@ietf.org> Subject: Review draft-ietf-ace-mqtt-tls-profile-05
* Style Issue. "Abbreviations should be expanded in document title and upon first use in the document. Full expansion of the text should be followed by the abbreviation in parentheses." Some items such as TLS are considered to be known by everybody and thus do not need to be expanded. https://www.rfc-editor.org/materials/abbrev.expansion.txt contains both "known" and "unknown" abbreviations. (Yes this means you are going to have a really long title.) (I might argue that OASIS should be listed as well known.) * Section 1 - para 1 - Sentence two has a plurality mismatch between client and server. I think in this case server (and broker) should be pluralized. * Section 1.3 - Broker - s/publishes/publish/ The set of pluralized items seems to be too large by one. * Section 1.3 - I think we ought to define Session given that we no longer require that Clean Session be used. * Section 1.3 - I do not believe that CONNACK is always the first packet from the broker to a client. An AUTH message may be the first one. * Section 2.1 - para 3 s/the public key used by the RS/the public key to be used by the RS/ * Section 2.1 - I think (but am not sure) that we may need to do some registrations around the use of thumbprints in a confirmation claim. If I forget, please remind me to track this down. * Section 2.2.2 - para #1 - s/using client authentication/using server authentication/ If we are doing MQTT as the default then the server not the client is authenticated here. You may not want to have lost the potentially here. * Section 2.2.3 - I think that the client state MUST include the token and either the same token is supplied or a token with the same key is supplied in order to match with an existing state. * Section 6.2 - I think it makes sense to put in a note that between the fact that the server will disconnect on almost any error and is not required to keep session state between connections, clients need to make a greater effort to ensure that tokens remain valid and they do not attempt to publish to topics that they do not have permissions for. * Section 8 - The storage of tokens long term can be restricted to only current valid ones if an immediate validation of the token is done. This means that the RS spends time doing the validation, but does not need to consume memory. This is looking really good. I think we have only two technical issues open at this point. The question of registrations for hash identifications in confirmation claims and if changes to the default scope structure are to be done. Jim _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
