From: Cigdem Sengul <cigdem.sen...@gmail.com> Sent: Monday, August 17, 2020 8:50 AM To: Jim Schaad <i...@augustcellars.com> Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg <ace@ietf.org> Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 Hello Jim, Responses inside. On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> > wrote: Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous session number/ - I think it should be stated that the session number is provided, which is what the state is associated with. To the best of my knowledge, and from what I read from the MQTT v5 spec: The ClientID MUST be used by Clients and by Servers to identify state that they hold relating to this MQTT Session between the Client and the Server. I do not think the server uses anything other than the Client ID to look up the state. [JLS] I got the name wrong, the need for the identifier remains. [CS] I see - I realise I did a shortcut to say MQTT broker keep session state. Actually, I think I should give examples of session state as I need to explain what could be problematic by identifying state only with client-id as discussed in the last IETF meeting. (i.e., The Session State in the Client consists of: * QoS 1 and QoS 2 messages which have been sent to the Server, but have not been completely acknowledged. * QoS 2 messages which have been received from the Server, but have not been completely acknowledged. The Session State in the Server consists of: * The existence of a Session, even if the rest of the Session State is empty. * The Clients subscriptions, including any Subscription Identifiers. * QoS 1 and QoS 2 messages which have been sent to the Client, but have not been completely acknowledged. * QoS 1 and QoS 2 messages pending transmission to the Client and OPTIONALLY QoS 0 messages pending transmission to the Client. * QoS 2 messages which have been received from the Client, but have not been completely acknowledged.The Will Message and the Will Delay Interval * If the Session is currently not connected, the time at which the Session will end and Session State will be discarded. ) Section 2.2.4 - Last sentence. There is a difference between the connect and re-auth flows in that the first and last messages are going to be AUTH '25', AUTH '0' not CONNECT/CONNACK. Everything else does stay the same. - Might just want to say a similar flow and point forward. Will clarify that this is only for CONNECT as it is under section 2- Authorizing Connection Requests. Will direct to section 4 for re-authentication. Section 2.2.6.1 - I am not sure where you got this from: "Note that this is different in MQTT v5.0, the Broker is allowed to process AUTH packets even if the Broker rejects the CONNECT)." I think that if the broker rejects the connect it must CONNACK and disconnect. I've got that from MQTT v5 spec: If a Client sets an Authentication Method in the CONNECT, the Client MUST NOT send any packets other than AUTH or DISCONNECT packets until it has received a CONNACK packet [MQTT-3.1.2-30]. and: If the Server rejects the CONNECT, it MUST NOT process any data sent by the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6]. [JLS] I read this as the following would not do the publish CONNECT --> PUBLISH --> <-- AUTH AUTH --> <-- CONNACK fail The PUBLISH can be received but is not processed unless the CONNACK is going to be a success. [/JLS] [CS] I think this sequence should not happen, as Client MUST NOT send PUBLISH before CONNACK. I did not know what brokers do if they receive PUBLISH (and still processing a CONNECT) - drop or buffer until process. I quickly browsed mosquitto src. It looks like the broker sets a context flag to mark the session active after CONNECT is processed and accepted. If this flag is not set when processing publish, it goes to an error state and doesn't look like it keeps the packet. [JLS] No, Clients are allowed to send further MQTT Control Packets immediately after sending a CONNECT packet; Clients need not wait for a CONNACK packet to arrive from the Server. – this is the preceding two sentences to requirement MQTT-3.1.4-6. I would agree that this is going to be server specific. The following paragraph suggests that clients SHOULD wait for the CONNACK but it is non-normative. I think that I would write my client code to wait. I would have to work really hard to figure out what my code base would do for this as I know it does queue packets for later processing but I am not sure what it would do for this case. So, the spec allows clients to send AUTH after CONNECT before CONNACK, and servers to process AUTH after CONNECT (before CONNACK I suppose). I agree the wording may be confusing: What I want to say is that: the servers in our profile do not process anything after CONNECT before CONNACK. So, the AUTH flow is strictly initiated by the server during the connection handshake. After that, the client may do AUTH first, for re-authentication. [JLS] Given that a client may only send an AUTH in response to an AUTH, I don’t know how much this is needed. [JLS] I think if you just delete the aside (in parens) then it says what needs to be said and is not confusing. [CS] OK, agreed, less is more in this case. Will delete the parentheses text. Section 3.1 - Missed a case of "publish_+/topic3" Yes, in previous version, example was for publish only for topic3. I thought I should give a pub/sub, pub only, and sub only examples. Is that OK? Yes, I was just pointing out that this was using the old syntax. Nothing more. [CS] Found it. OK, that was very buggy. Will change to: Following the example in the previous section, a client sending a SUBSCRIBE message to 'a/topic3' would be allowed to subscribe, as the scope includes "["+/topic3",["sub"]]". Thanks again for catching it. --Cigdem Jim Thanks, --Cigdem Jim _______________________________________________ Ace mailing list Ace@ietf.org <mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
