Original text:
The next four bytes include a 32-bit Version field (see version). <del> The next byte contains the length in bytes of the two Connection IDs (see connection-id) that follow.  Each length is encoded as a 4-bit unsigned integer.  The length of the Destination Connection ID (DCIL) occupies the high bits of the byte and the length of the Source Connection ID (SCIL) occupies the low bits of the byte.  An encoded length of 0 indicates that the connection ID is also 0 bytes in length.  Non-zero encoded lengths are increased by 3 to get the full length of the connection ID; the final value is therefore either 0 or between 4 and 18 bytes in length (inclusive).  For example, a byte with the value 0xe0 describes a 17 byte Destination Connection ID and a zero byte Source Connection ID. The connection ID lengths are followed by two connection IDs.  The connection ID associated with the recipient of the packet (the Destination Connection ID) is followed by the connection ID associated with the sender of the packet (the Source Connection ID). </del>  The remainder of the packet contains version-specific content. This field indicates which version of QUIC is in use and determines how the rest of the protocol fields are interpreted. <del> The byte following the version contains the lengths of the two connection ID fields that follow it.  These lengths are encoded as two 4-bit unsigned integers.  The Destination Connection ID Length (DCIL) field occupies the 4 high bits of the byte and the Source Connection ID Length (SCIL) field occupies the 4 low bits of the byte.  An encoded length of 0 indicates that the connection ID is also 0 bytes in length.  Non-zero encoded lengths are increased by 3 to get the full length of the connection ID, producing a length between 4 and 18 bytes inclusive.  For example, a byte with the value 0x50 describes an 8-byte Destination Connection ID and a zero-length Source Connection ID. </del>  The Destination Connection ID field follows the DCID Len and is between 0 and 20 bytes in length. negotiating-connection-ids

Reviewer comments:
I noticed this earlier today when trying to resolve conflicts relating to the connection ID change.
Suggestions accepted.
A couple of changes

Revised text:
The next four bytes include a 32-bit Version field (see version).  <ins> 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. 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. </ins> The remainder of the packet contains version-specific content. This field indicates which version of QUIC is in use and determines how the rest of the protocol fields are interpreted.  <ins> The byte following the version contains the length in bytes of the Destination Connection ID field that follows it.  This length is encoded as an 8-bit unsigned integer.  In QUIC version 1, this value MUST NOT exceed 20.  Endpoints that receive a version 1 long header with a value larger than 20 MUST drop the packet.  Servers SHOULD be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation packet. </ins> The Destination Connection ID field follows the DCID Len and is between 0 and 20 bytes in length. negotiating-connection-ids