Original text:
all versions, and one "compatible" that allows saving the round trip but only applies when the versions are compatible. <del> The client initiates a QUIC connection by choosing an initial version and sending a first flight of QUIC packets with a long header to the server QUIC-INVARIANTS.  The client's first flight includes Version Information (see vers-info) which will be used to optionally enable compatible version negotiation (see compat-vn), and to prevent </del>  version downgrade attacks (see downgrade). Upon receiving this first flight, the server verifies whether it to be compatible with version B and for B not to be compatible with A.  This could happen for example if version B is a strict superset of version A: if version A includes the concept of streams and STREAM <del> frames, and version B includes the concepts of streams and tubes along with STREAM and TUBE frames, then A would be compatible with B but B would not be compatible with A. </del>  Note that version compatibility does not mean that every single possible instance of a first flight will succeed in conversion to the

Reviewer comments:
Instead of creating separate issues for each minor editorial comments I will put them all in this issue - I am not a fan of having normative language in the definitions. I feel those normative languages are out of context and hard to reason. It is the case for MSL definition. I would suggest that besides definition, we have some description where MSL is used and put the recommended value there. What is the difference between the initial version and original version ? if there is none why do we need to use two different call sign for the same thing? What is Tubes? we need to explain it. otherwise use other example.
I personally disagree. Mentioning the recommended value when defining the term makes it easier to understand and implement. Agreed, there was only one mention of "initial version" so I replaced that with original in It's a hypothetical example. That doesn't make it unhelpful.
:-) hmm, the example makes little sense if one does not understand the terms used in the example. If "Tube" is a hypothetical term here, then let's just mention that.
There was no reasoning, this was pulled out of a hat just like the original MSL from RFC 793. Can you send us a PR describing the reasoning you'd like to see added? Fair enough, I've added the word "hypothetical" to PR

Revised text:
all versions, and one "compatible" that allows saving the round trip but only applies when the versions are compatible.  <ins> The client initiates a QUIC connection by choosing an original version and sending a first flight of QUIC packets with a long header to the server QUIC-INVARIANTS.  The client's first flight includes Version Information (see vers-info) which will be used to optionally enable compatible version negotiation (see compat-vn), and to prevent </ins> version downgrade attacks (see downgrade). Upon receiving this first flight, the server verifies whether it to be compatible with version B and for B not to be compatible with A.  This could happen for example if version B is a strict superset of version A: if version A includes the concept of streams and STREAM  <ins> frames, and version B includes the concept of streams and the hypothetical concept of tubes along with STREAM and TUBE frames, then A would be compatible with B but B would not be compatible with A. </ins> Note that version compatibility does not mean that every single possible instance of a first flight will succeed in conversion to the