Original text:
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>  The new first flight will allow the endpoints to establish a connection using the negotiated version.  The handshake of the

Reviewer comments:
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. in my 1st scenario, the server initiates incompatible version negotiation, the server selects D instead of C as chosen by client. The expectation here is that D will be the final negotiated version, and the version negotiation will end. But is there anything stopping the client to try to enforce it's chosen one (C) again? shall we have some to avoid this case? in the 2nd scenario, it is not possible if A, B, C,D, E,F all are compatible. if the server starts incompatible version negotiation with (C,D) and client does not find any supported version, it aborts the connection. I just realized - there is no normative text for aborting the connection attempt.. As the server expresses all the versions it support in the supported versions list, the client knows there is not point on continuing with another attempt with (E,F). Unless I am mistaken there is nothing now prohibiting the client to do so. It can continue to do so.
That doesn't make sense. The server initiates incompatible version negotiation by sending a VN packet, there's no notion of chosen version in the VN packet. There's no need for normative text when there's nothing else a client can do, are you saying the client could do something wrong as opposed to aborting due to lack of versions? The client will ignore any VN packet apart from the first one:
right, my bad. I think I have drawn the picture wrong. Server send (D,C) and the client choses C but the server choses D. does this make sense? and the main issue goes away? sniped from my previous comment. >The expectation here is that D will be the final negotiated version, and the version negotiation will end. But is there anything stopping the client to try to enforce it's chosen one (C) again? shall we have some to avoid this case? yes . and should we try to prevent it? OK, I see the client ignores, but what does happen then ? does it abort the connection attempt ? Is it possible for the client to start another connection attempt with complete new original versions and a new set of other versions?
Zahed and I discussed this first scenario offline. In this scenario, the client indicated that it was happy with D by sending it in its Other Versions, so the client will be happy when D is negotiated even if it preferred C. If the client didn't like D, it could have removed D from Other Versions and then the connection would have negotiated C. Fair enough, this can be fixed with a small tweak - see below. Zahed and I discussed this second scenario offline as well. I wrote up to make the incompatible VN text more normative and that addresses Zahed's concern here. Now we have normative text to guarantee a failure in that scenario. If the client wants to start a separate connection attempt later, it will restart the algorithm from the top. We explicitly decided as a WG to avoid telling the client to remember information from previous connection attempts because VN packets don't carry an expiration date so caching them is fraught.
LGTM

Revised text:
also ignores a Version Negotiation packet that contains incorrect connection ID fields; see QUIC-INVARIANTS.  <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