Change:
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

Discussion:
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.