Original text:
packets have an associated packet number; however, this packet number is encrypted, and therefore not of use to on-path observers.  The offset of the packet number is encoded in long <del> headers, while it is implicit (depending on Destination Connection </del>  ID length) in short headers.  The length of the packet number is cryptographically obfuscated. connection.  Connection IDs for either endpoint may change during the lifetime of a connection, with the new connection ID being negotiated via encrypted frames.  See Section 5.1 of QUIC-TRANSPORT.  Therefore, <del> observing a new Connection ID does not necessary indicate a new </del>  connection. Server-generated connection IDs should seek to obscure any encoding, The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the <del> Connection ID in the Connection ID itself, instead of remembering it. </del>  <del> QUIC_LB further specified possible algorithms to generate Connection </del>  IDs at load balancers. 2.7. server can generally be confirmed by an on- path observer.  An attempted connection after Retry can be detected by correlating the token on the Retry with the token on the subsequent Initial packet <del> and the Destination Connection ID of the new Initial packet. </del>  3.3. When the version has been identified as QUIC version 1, the packet type needs to be verified as an Initial packet by checking that the third and fourth bit of the header are both set to 0.  Then the <del> Client Destination Connection ID needs to be extracted to calculate </del>  the Initial Secret together with the version specific initial salt, as described in QUIC-TLS.  The length of the connection ID is indicated in the 6th byte of the header followed by the connection ID after the CRYPTO frame. Note that client Initial packets after the first do not always use <del> the Destination Connection ID that was used to generate the Initial </del>  keys.  Therefore, attempts to decrypt these packets using the procedure above might fail. 3.4. <del> The QUIC Connection ID (see rebinding) is designed to allow an on- </del>  path device such as a load-balancer to associate two flows as identified by five-tuple when the address and port of one of the endpoints changes; e.g. due to NAT rebinding or server IP address indicates the willingness of the server to communicate with the client. <del> The QUIC header optionally contains a Connection ID which can be used </del>  as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the <del> Connection ID is present and what length it has.  However, Connection </del>  IDs may be renegotiated during a connection, and this renegotiation <del> is not visible to the path.  Keying state off the Connection ID may </del>  therefore cause undetectable and unrecoverable loss of state in the <del> middle of a connection.  Use of Connection ID specifically </del>  discouraged for NAT applications. 4.2.

Reviewer comments:
We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!

Revised text:
packets have an associated packet number; however, this packet number is encrypted, and therefore not of use to on-path observers.  The offset of the packet number is encoded in long  <ins> headers, while it is implicit (depending on destination connection </ins> ID length) in short headers.  The length of the packet number is cryptographically obfuscated. connection.  Connection IDs for either endpoint may change during the lifetime of a connection, with the new connection ID being negotiated via encrypted frames.  See Section 5.1 of QUIC-TRANSPORT.  Therefore,  <ins> observing a new connection ID does not necessary indicate a new </ins> connection. Server-generated connection IDs should seek to obscure any encoding, The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the  <ins> connection ID in the connection ID itself, instead of remembering it. </ins>  <ins> QUIC_LB further specified possible algorithms to generate connection </ins> IDs at load balancers. 2.7. server can generally be confirmed by an on- path observer.  An attempted connection after Retry can be detected by correlating the token on the Retry with the token on the subsequent Initial packet  <ins> and the destination connection ID of the new Initial packet. </ins> 3.3. When the version has been identified as QUIC version 1, the packet type needs to be verified as an Initial packet by checking that the third and fourth bit of the header are both set to 0.  Then the  <ins> client destination connection ID needs to be extracted to calculate </ins> the Initial Secret together with the version specific initial salt, as described in QUIC-TLS.  The length of the connection ID is indicated in the 6th byte of the header followed by the connection ID after the CRYPTO frame. Note that client Initial packets after the first do not always use  <ins> the destination connection ID that was used to generate the Initial </ins> keys.  Therefore, attempts to decrypt these packets using the procedure above might fail. 3.4.  <ins> The QUIC connection ID (see rebinding) is designed to allow an on- </ins> path device such as a load-balancer to associate two flows as identified by five-tuple when the address and port of one of the endpoints changes; e.g. due to NAT rebinding or server IP address indicates the willingness of the server to communicate with the client.  <ins> The QUIC header optionally contains a connection ID which can be used </ins> as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the  <ins> connection ID is present and what length it has.  However, connection </ins> IDs may be renegotiated during a connection, and this renegotiation  <ins> is not visible to the path.  Keying state off the connection ID may </ins> therefore cause undetectable and unrecoverable loss of state in the  <ins> middle of a connection.  Use of connection ID specifically </ins> discouraged for NAT applications. 4.2.