Stateless retry relation to version negotiation

[mikkelfj]

If a server decides to send a version negotiation packet and also a stateless retry, which one should it choose, and should the client retain a negotiated version if it receives a stateless retry? If it does not, the cryptographic context in the retry might not make sense but text says to start new connection state.

Also, retry might be related to which server version is supported, so there could potentially be a lot of ping pong going on. On the other hand, a retry might not know the versions supported by other servers.

[mikkelfj]

Wasn't mentioned in version negotiation nor in Stateless Retry section, but stateless retry packet does section mention it:
"the client MUST remember the results of any version negotiation that occurred "

I keep the issue open for review in case the text can be clarified a bit.

UPDATE:
There is a potential for hung handshakes (until timeout) if a retry causes a client to send a new initial client packet and the server responds with version negotiation, possibly because it was a different version from the server sending retry. In this case that client could either ignore version negotation packets, believing they are old retransmissions, or it could remember the retry mode and consider this a hard error. But a hard error is not good because it is open to attack.

[martinthomson]

This isn't really a valid question. The draft is pretty clear that version negotiation happens before stateless retry.