Change:
Remove the normative reference to -transport in -invariants. This is an editorial change, but I'll pass it to the list. Includes some consistency updates.
Yes, but I think that - at least in principle - each should be as independent of the other as possible. Sure, -transport is a concrete instantiation of -invariants, but you can implement it without -invariants. Similarly, -invariants exists to support -transport, but it describes something bigger than it. So while we might have some pointers, you can read each without the other, which is nice.
introduced a new bespoke packet format. I don't have issues with the format itself, but as I reviewed I was surprised to see it used there without any explanation as to how to decipher it. I think it would be nicer if each document that uses this format either: References the "Notational Conventions" section from draft-ietf-quic-transport Has a "Notational Conventions" section of its own explaining this format
-- URL There is a lot more that the document leans on than the packet format grammar, so any expansion of this might explode. I tend to think that this is adequate.
I agree that the reference is sufficient, except for one aspect: We do want the invariants drafts to be readable without needing to get into the v1 spec, because the target audience is people who need to handle QUIC without regard to versions. I think it's wrong that the reference to QUIC-TRANSPORT is normative instead of informative, and this reference for conventions and definitions is the only reference in the doc that actually needs to be normative. I'm almost be more inclined to move the notation definition across, just as we ultimately did for the definition of VN, and let -transport refer to -invariants for it.
Looks good. Technically, we could reference this draft for the notation, but we don't need to if it makes transport easier to read.

Discussion:
4. <del> A QUIC packet is the content of the UDP datagrams exchanged by QUIC endpoints.  This document describes the contents of those datagrams. </del> <ins> Packet diagrams in this document use a format defined in QUIC- TRANSPORT to illustrate the order and size of fields. Complex fields are named and then followed by a list of fields surrounded by a pair of matching braces.  Each field in this list is separated by commas. Individual fields include length information, plus indications about fixed value, optionality, or repetitions.  Individual fields use the following notational conventions, with all lengths in bits: Indicates that x is A bits long Indicates that x can be any length from A to B; A can be omitted to indicate a minimum of zero bits and B can be omitted to indicate no set upper limit; values in this format always end on an octet boundary Indicates that x has a fixed value of C Indicates that x is repeated zero or more times (and that each instance is length E) fig-ex-format shows an example structure: 5. QUIC endpoints exchange UDP datagrams that contain one or more QUIC packets.  This section describes the invariant characteristics of a QUIC packet.  A version of QUIC could permit multiple QUIC packets in a single UDP datagram, but the invariant properties only describe the first packet in a datagram. </ins> QUIC defines two types of packet header: long and short.  Packets with long headers are identified by the most significant bit of the

Aside from the values described here, the payload of QUIC packets is version-specific and of arbitrary length. <del> 4.1. </del> <ins> 5.1. </ins> Long headers take the form described in fig-long.

The next byte contains the length in bytes of the Destination Connection ID (see connection-id) field that follows it.  This length is encoded as an 8-bit unsigned integer.  The Destination Connection <del> ID field follows the DCID Len field and is between 0 and 255 bytes in length. </del> <ins> ID field follows the DCID Length field and is between 0 and 255 bytes in length. </ins> The next byte contains the length in bytes of the Source Connection ID field that follows it.  This length is encoded as a 8-bit unsigned <del> integer.  The Source Connection ID field follows the SCID Len field and is between 0 and 255 bytes in length. </del> <ins> integer.  The Source Connection ID field follows the SCID Length field and is between 0 and 255 bytes in length. </ins> The remainder of the packet contains version-specific content. <del> 4.2. </del> <ins> 5.2. </ins> Short headers take the form described in fig-short.

The remainder of the packet has version-specific semantics. <del> 4.3. </del> <ins> 5.3. </ins> A connection ID is an opaque field of arbitrary length.

methods.  Packets for the same QUIC connection might use different connection ID values. <del> 4.4. </del> <ins> 5.4. </ins> QUIC versions are identified with a 32-bit integer, encoded in network byte order.  Version 0 is reserved for version negotiation

additional properties which apply to a specific QUIC version, or to a range of QUIC versions. <del> 5. </del> <ins> 6. </ins> A QUIC endpoint that receives a packet with a long header and a version it either does not understand or does not support might send

that supports QUIC version 1 generates and consumes a Version Negotiation packet. <del> 6. </del> <ins> 7. </ins> It is possible that middleboxes could use traits of a specific version of QUIC and assume that when other versions of QUIC exhibit

by off-path attackers.  QUIC versions MUST define a mechanism that authenticates the values it contains. <del> 7. </del> <ins> 8. </ins> This document makes no request of IANA. <del> 8.  References </del> <ins> 9.  References </ins> <del> 8.1.  URIs </del> <ins> 9.1.  URIs </ins> [1] mailto:quic@ietf.org