Code change:
also ignores a Version Negotiation packet that contains incorrect connection ID fields; see QUIC-INVARIANTS. <del> Upon receiving the Version Negotiation packet, the client will search for a version it supports in the list provided by the server.  If it doesn't find one, it aborts the connection attempt.  Otherwise, it selects a mutually supported version and sends a new first flight with that version - this version is now the negotiated version. </del> <ins> Upon receiving the Version Negotiation packet, the client SHALL search for a version it supports in the list provided by the server. If it doesn't find one, it SHALL abort the connection attempt. Otherwise, it SHALL select a mutually supported version and sends a new first flight with that version - this version is now the negotiated version. </ins> The new first flight will allow the endpoints to establish a connection using the negotiated version.  The handshake of the

Related discussion:
text: URL in this example, it would be very stupid of the client to select version C and start another negotiation after the sever has indicated D is what it prefers. The server can again select D as preferred and there exits a potential loop. However, it is possible. What are the rule we have in the specification that stops this kind of loop?
I'm not sure that I understand this question. A client makes a choice about what version to attempt (and offer) when it creates a connection. It might learn that its versions are incompatible with a server (with a Version Negotiation packet) and try again, but that retry would be a separate action. But if the connection is successfully established, the negotiation is done.
There is at most one round of incompatible VN followed by one connection that may or may not use compatible VN to switch versions again. There is no potential for a loop here. NAME can you clarify what you meant?
The scenario i was thinking is a follows - Chosen = A, Other Versions = (A, B) -----------------> <----------------- Chosen = G, Other Versions = (G,H) ........ the draft only says the client's first flight contain This contains the list of versions that the client knows its first flight is compatible with (A,B). It does not force the client to list ALL the compatible versions, so it might not list all the compatible versions. I think, there is also no requirement on the server to list ALL the compatible versions. Now server sends back another list of compatible versions (D,C). This new list triggers the client to realise it knows about versions that are compatible (E,F), and sends it back to the client as it has not interest in D or C. That trigger the server to reply with new list of compatible version (G,H).. and this goes on. It is also possible that client made a mistake by not listing all the compatible version (well it does not have to) and as it is not interested in D or C, it wants to list (E,F) and keep in negotiating. I would like to understand the with current specification this kind of interaction is not possible and the negotiation should not go on like that.
The scenarios you describe aren't allowed: if the server performs compatible version negotiation it MUST select a that was included in the client's :
yes, but servers are allowed to do incompatible version negotiation.