Draft: draft-ietf-quic-invariants

Commentary: Editorial NiTs when reviewing the invariant text . These NiTs address readability issues , and do not intend to change the meaning of the text . 
 Is there an associated issue ? 
 Thanks  , these are all quite helpful . 1 ) I understand the acronyms  and SCID , but these are n't really expanded on first use in sect 5.1 . 2 ) There 's mention of " the high bit " , but there does n't seem to be any statement of bit order saying . Is it worth declaring network byte / bit order earlier in section 4 ? This also clarifies the placement of fields within a byte , which was basically assumed knowledge otherwise . 3 ) Personally , I do n't think : " The length of the Destination Connection ID is not specified " is a great choice of words . Surely , this needs to be specified somewhere for a protocol instance to use it ? This reads better as something like : The length of the Destination Connection ID is not encoded in packets with a short header and is not constrained by this specification . 4 ) The brackets here seem to point to connection IDs in general , not the DCID " ( see Section 5.3 ) " . Is it worth writing that as " Connection IDs are described in Section 5 " , rather than use brackets ? The same is true for versions . 5 ) In section 5.3 : " the wrong endpoint " is taken as the wrong transport endpoint , but some of our IP and subIP colleagues would use the term endpoint for other uses , so one insertion of " transport " would perhaps help ? 6 ) In the appendix A , this : " QUIC forbids acknowledgments of packets " - still has me wondering what is actually intended to be understood , because the list of bullets is not guarenteed ... : /The last packet before a long period of quiescence might be assumed to contain an acknowledgment ( it should be assumed that QUIC could allow acknowledgments of packets that only contain ACK frames)/ I 'm not sure what to say here I think the combination of not ... forbids threw me off the meaning . Changes proposed in 
 Thanks for changing SCID / DCID to " Source Connection ID " and " Destination Connection ID " , that seems like a good change .
Paragraph (version A):
The next four bytes include a 32-bit Version field (see version).
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 Length 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 Length
field and is between 0 and 255 bytes in length.
Paragraph (version B):
The next four bytes include a 32-bit Version field.  Versions are
described in version.
Paragraph (version B):
The next byte contains the length in bytes of the Destination
Connection ID field that follows it.  This length is encoded as an
8-bit unsigned integer.  The Destination Connection ID field follows
the Destination Connection ID Length field and is between 0 and 255
bytes in length.  Connection IDs are described in connection-id.
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 Source
Connection ID Length field and is between 0 and 255 bytes in length.
Paragraph (version A):
A QUIC packet with a short header includes a Destination Connection
ID immediately following the first byte.  The short header does not
include the Connection ID Lengths, Source Connection ID, or Version
fields.  The length of the Destination Connection ID is not specified
in packets with a short header and is not constrained by this
specification.
Paragraph (version B):
A QUIC packet with a short header includes a Destination Connection
ID immediately following the first byte.  The short header does not
include the Connection ID Lengths, Source Connection ID, or Version
fields.  The length of the Destination Connection ID is not encoded
in packets with a short header and is not constrained by this
specification.
Paragraph (version A):
The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP, and below) don't cause
packets for a QUIC connection to be delivered to the wrong endpoint.
The connection ID is used by endpoints and the intermediaries that
support them to ensure that each QUIC packet can be delivered to the
correct instance of an endpoint.  At the endpoint, the connection ID
is used to identify which QUIC connection the packet is intended for.
Paragraph (version B):
The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP, and below) don't cause
packets for a QUIC connection to be delivered to the wrong QUIC
endpoint.  The connection ID is used by endpoints and the
intermediaries that support them to ensure that each QUIC packet can
be delivered to the correct instance of an endpoint.  At the
endpoint, the connection ID is used to identify which QUIC connection
the packet is intended for.
Paragraph (version A):
The client populates the Source Connection ID field with a value of
its choosing and sets the SCID Length field to indicate the length.
Paragraph (version B):
The client populates the Source Connection ID field with a value of
its choosing and sets the Source Connection ID Length field to
indicate the length.
Paragraph (version A):
fig-auth-cid shows the connection IDs that are used in a complete
handshake.  The exchange of Initial packets is shown, plus the later
exchange of 1-RTT packets that includes the connection ID established
during the handshake.
Paragraph (version B):
fig-auth-cid shows the connection IDs (with DCID=Destination
Connection ID, SCID=Source Connection ID) that are used in a complete
handshake.  The exchange of Initial packets is shown, plus the later
exchange of 1-RTT packets that includes the connection ID established
during the handshake.
Paragraph (version A):
The Destination Connection ID field follows the DCID Length field
and is between 0 and 20 bytes in length. negotiating-connection-
ids describes the use of this field in more detail.
Paragraph (version B):
The Destination Connection ID field follows the Destination
Connection ID Length field and is between 0 and 20 bytes in
length.  negotiating-connection-ids describes the use of this
field in more detail.
Paragraph (version A):
The Source Connection ID field follows the SCID Length field and
is between 0 and 20 bytes in length. negotiating-connection-ids
describes the use of this field in more detail.
Paragraph (version B):
The Source Connection ID field follows the Source Connection ID
Length field and is between 0 and 20 bytes in length. negotiating-
connection-ids describes the use of this field in more detail.
Paragraph (version A):
The Initial packet contains a long header as well as the Length and
Packet Number fields.  The first byte contains the Reserved and
Packet Number Length bits.  Between the SCID and Length fields, there
are two additional fields specific to the Initial packet.
Paragraph (version B):
The Initial packet contains a long header as well as the Length and
Packet Number fields.  The first byte contains the Reserved and
Packet Number Length bits.  Between the Source Connection ID and
Length fields, there are two additional fields specific to the
Initial packet.