Original text:
A QUIC packet with a long header has the high bit of the first byte set to 1.  All other bits in that byte are version specific. <del> The next four bytes include a 32-bit Version field (see version). </del>  The next byte contains the length in bytes of the Destination <del> 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. </del>  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 Length field and is between 0 and 255 bytes in length. </del>  The remainder of the packet contains version-specific content.

Reviewer comments:
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 Gorry, these are all quite helpful. 1) I understand the acronyms DCID and SCID, but these aren't really expanded on first use in sect 5.1. 2) There's mention of "the high bit", but there doesn'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 don'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.

Revised text:
A QUIC packet with a long header has the high bit of the first byte set to 1.  All other bits in that byte are version specific.  <ins> The next four bytes include a 32-bit Version field.  Versions are described in version. </ins> The next byte contains the length in bytes of the Destination  <ins> 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. </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  <ins> integer.  The Source Connection ID field follows the Source Connection ID Length field and is between 0 and 255 bytes in length. </ins> The remainder of the packet contains version-specific content.