Simon Bernard

> Just for changing the secret, it's not required to remove the old connection, or? Not really but this it seems to be the behavior expected (see https://github.com/eclipse/leshan/issues/162) and I...

Ok I get your point, a solution could be to warn user in documentation about which method MUST be called in the "serialized execution". (In all case this kind of...

> I don't get it! Why should the return value not be used to define, if the connection or what ever should be removed? You said we have an enum...

It can but it's hard to me to understand why it seems so important to avoid users to directly use their connection store.

@jimsch, here is [a discussion about this](http://ietf.10.n7.nabble.com/DTLS-how-to-handle-unknown-identity-and-bad-psk-td561060.html) on the TLS ietf mailing list. > In practice there is a big difference between doing this during a handshake and after the...

1. There are big differences between TLS and DTLS. One of them is the transport layer. So this could be a security issue in DTLS and not in TLS ......

(@boaks I know we only discuss about that, and I agree this is not a priority, I just open this ticket to be able to reference it)

> for DTLS you may use the sharedExecutor also, so only 1 additional receiver thread will be required per client. Thx for the clarification, I fix the issue description and...

Is there any reason to keep this issue open ?

I will first go for a fix in Leshan (ensuring that I do not schedule several time the cleaning task) I will see If I found time to add message...