Original text:
compatible versions SHOULD use the same mechanism. Note that, after the first flight is converted to the negotiated <del> version, the handshake completes in the negotiated version.  The entire handshake (including the converted first flight) needs to conform to the rules of the negotiated version.  For instance, if the negotiated version requires that the 5-tuple remain stable for the entire handshake (as QUIC version 1 does), then this applies to the entire handshake, including the first flight. </del>  Note also that the client can disable compatible version negotiation by only including the Chosen Version in the Other Versions field of

Reviewer comments:
thanks for the fix.
URL here it is not clear to me if we are talking about first flight or converted first flight. I am assuming the negotiated version is in the converted first flight. May be we can be more clear here.
In this particular case, it probably doesn't matter. I don't know if it would be possible to convert a flight so that it had a different address tuple. I guess maybe you could, so I would say that this applies to the converted flight. BTW, NAME I really appreciate the quoting of text, but when you quote the text, you can select a range of lines, which might be useful here. Click the first/last line, then hold shift and click the last/first line.
Ok then probably best to clear about this int he spec. by the way, thanks for the tip NAME
I'm sorry, what is unclear here?
NAME the inclusion of "including the first flight" in the last sentence is confusing. it says - "For instance, if the negotiated version requires that the 5-tuple remain stable for the entire handshake (as QUIC version 1 does), then this applies to the entire handshake, including the first flight." Actually now I think the whole thing is very hard to parse. what does it mean? So, the negotiated version comes second and how does the first flight comply with that? should it not be the case that if the first flight requires the 5-tuple to be stable the negotiated version must comply with that? or does it mean when the client receives the negotiated version it should not change the 5-tuple? I think this is what we want but that is not clear from the example text or entire paragraph. as MT, mentioned it might be possible to convert the flight to different address tuple. If we don't want that then we need to change this text - " The entire handshake (including the converted first flight) needs to conform to the rules of the negotiated version" to include normative MUST.
All this says is "any requirements from the negotiated version also apply to the first flight". So if the negotiated version required the addresses to be stable, if it detects that they changed then it fails the handshake. That's just a way of saying "follow the spec of the versions in use". I don't think that's needed. I'm fine with a future document defining conversion such that it changes the address tuple. There's no need to prevent that. Perhaps you could propose text that you find clearer?
I would simple suggest to make it clear in this document and rewrite - Also I would suggest to change the example to reflect what you said here -
This is unclear, who does this normative requirement apply to? Who is "it" in "it fails the handshake"? At this point, it's sounding like this issue is editorial about how best to phrase one paragraph. I propose we don't block IESG review on this editorial work.
The draft says - >The entire handshake (including the converted first flight) needs to conform to the rules of the negotiated version. it seems like it is then unclear who does this "needs" apply to? Then we have problem. the "it" is I suppose same as in your previous reply :-) it is editorial yes, but I am assuming if what is written is not clear to me I think it won't clear to others as well. Hence, I think it is worth clarifying. And I don't think this will block any longer than the consensus call we have now on update tag if we work on to improve the text. May be we should just say do we lose big if we drop the "including the first flight" part?
How about this:
This is much better, specially clear about the converted first flight. Thanks

Revised text:
compatible versions SHOULD use the same mechanism. Note that, after the first flight is converted to the negotiated  <ins> version, the handshake completes in the negotiated version.  If the negotiated version has requirements that apply during the handshake, those requirements apply to the entire handshake, including the converted first flight.  In particular, if the negotiated version mandates that endpoints perform validations on handshake packets, endpoints MUST also perform such validations on the converted first flight.  For instance, if the negotiated version requires that the 5-tuple remain stable for the entire handshake (as QUIC version 1 does), then both endpoints need to validate the 5-tuple of all handshake packets, including the converted first flight. </ins> Note also that the client can disable compatible version negotiation by only including the Chosen Version in the Other Versions field of