>
>
> [CS] Yes. We opted for not keeping any state because that indeed had too
> many problematic issues. One was, as I already mentioned, extra state kept
> for a time determined by the client (session expiry) - which we thought
> would cause trouble. There are some non-normative text in MQTT spec
From: Cigdem Sengul
Sent: Monday, March 9, 2020 5:35 AM
To: Jim Schaad
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg
Subject: Re: Comments on the MQTT draft
Hello Jim,
Comments inline.
Yes, I can see this can be problematic but this was to avoid the broker keeping
stat
Hello Jim,
Comments inline.
Yes, I can see this can be problematic but this was to avoid the broker
> keeping state for clients that are no more authorised to receive those
> messages. The session state can include actual messages if QoS>=1, so maybe
> high overhead.
>
>
> The Session Expiry is a
From: Cigdem Sengul
Sent: Sunday, March 8, 2020 3:30 PM
To: Jim Schaad
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg
Subject: Re: Comments on the MQTT draft
Hello Jim,
Comments inline.
On Sun, Mar 8, 2020 at 7:04 PM Jim Schaad mailto:i...@augustcellars.com> > wrote:
1.
Hello Jim,
Comments inline.
On Sun, Mar 8, 2020 at 7:04 PM Jim Schaad wrote:
> 1. I want to verify that the following is the desired statement: There is
> a strong preference that TLS not use PSK for authentication. This follows
> from the recommendation to use TLS:Anon-MQTT:ace for the auth
1. I want to verify that the following is the desired statement: There is
a strong preference that TLS not use PSK for authentication. This follows
from the recommendation to use TLS:Anon-MQTT:ace for the authentication
option. I have no problems with this statement, I just want to be sure that
