Draft: draft-ietf-quic-invariants

Commentary: 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 do n'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 
 -- 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 do n't need to if it makes transport easier to read .
Paragraph (version A):
A QUIC packet is the content of the UDP datagrams exchanged by QUIC
endpoints.  This document describes the contents of those datagrams.
Paragraph (version B):
Packet diagrams in this document use a format defined in QUIC-
TRANSPORT to illustrate the order and size of fields.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
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
ID field follows the DCID Len field and is between 0 and 255 bytes in
length.
Paragraph (version A):
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
integer.  The Source Connection ID field follows the SCID Len field
and is between 0 and 255 bytes in length.
Paragraph (version B):
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
ID field follows the DCID Length field and is between 0 and 255 bytes
in length.
Paragraph (version B):
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
integer.  The Source Connection ID field follows the SCID Length
field and is between 0 and 255 bytes in length.