Original text:
Note that "version 2" is an informal name for this proposal that indicates it is the second standards-track QUIC version.  The <del> protocol specified here will receive a version number other than 2 from IANA. Discussion of this work is encouraged to happen on the QUIC IETF mailing list <quic@ietf.org> or on the GitHub repository which contains the draft: <https://github.com/quicwg/quic-v2>. </del>  1. 3. QUIC version 2 endpoints MUST implement the QUIC version 1 <del> specification as described in QUIC, QUIC-TLS, and RFC9002.  However, the following differences apply in version 2. </del>  3.1. The Version field of long headers is 0x709a50c4.  3.2. All version 2 long header packet types are different.  The Type field version.  Endpoints have no need to generate the keying material that would allow them to decrypt or authenticate these packets. <del> If the server's version_information transport parameter does not contain a Chosen Version field equivalent to the version in the server's Handshake packet headers, the client MUST terminate the connection with a VERSION_NEGOTIATION_ERROR. </del> The client MUST NOT send 0-RTT packets using the negotiated version, even after processing a packet of that version from the server. Servers can apply original version 0-RTT packets to a connection

Reviewer comments:
, ,
It would be nice to have the references use a consistent format (e.g. all having a name instead of the RFC number for some)
OK, I've only left document number references where the subject is indicated beforehand, e.g. Alt-Svc {{?RFC7838}}
fixed by
Draft currently states: This repeats the QUIC VN document, should we remove it?
Yes, good catch.
fixed by
The draft currently says: Could we add a note to be removed by the RFC editor that clarifies whether or not we're going to change the version number before publication or not?
fixed by
The abstract currently contains: I'm pretty sure the second one won't be included, but there's no note saying so. I don't know if the first one is meant to stay. Can we add a note to make this explicit? Markdown can do it for you for the second one.
Actually the second note can be removed entirely because it repeats the paragraph that's autogenerated.
Thanks!

Revised text:
Note that "version 2" is an informal name for this proposal that indicates it is the second standards-track QUIC version.  The  <ins> protocol specified here uses a version number other than 2 in the wire image. </ins> 1. 3. QUIC version 2 endpoints MUST implement the QUIC version 1  <ins> specification as described in QUIC, QUIC-TLS, and QUIC-LOSSRECOVERY. However, the following differences apply in version 2. </ins> 3.1. The Version field of long headers is 0x709a50c4. <ins> This version number will not change in subsequent versions of this draft, unless there is a behavior change that breaks compatibility. </ins> 3.2. All version 2 long header packet types are different.  The Type field version.  Endpoints have no need to generate the keying material that would allow them to decrypt or authenticate these packets.  The client MUST NOT send 0-RTT packets using the negotiated version, even after processing a packet of that version from the server. Servers can apply original version 0-RTT packets to a connection