Original text:
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 bits of the header are both set to 0.  Then the <del> Destination Connection ID needs to be extracted to calculate the Initial secret using the version-specific Initial salt, as described in Section 5.2 of QUIC-TLS.  The length of the connection ID is indicated in the 6th byte of the header followed by the connection ID itself. </del>  To determine the end of the header and find the start of the payload, the packet number length, the source connection ID length, and the Finally, an extension might define additional frame types which could be present. <del> Note that subsequent Initial packets might contain a Destination Connection ID other than the one used to generate the Initial secret. Therefore, attempts to decrypt these packets using the procedure above might fail unless the Initial secret is retained by the observer. </del> 3.5. The QUIC connection ID (see rebinding) is designed to allow a

Reviewer comments:
Addresses
... doesn't make it clear that only the Initial from the client (and only those sent before receiving packets from the server) contain a Destination Connection ID field that can be used to decrypt the packet. Any initial from the server, or any initial sent by a client after receiving Initial packets from the server, probably won't work.
Hmm, this is the last paragraph. Too late?
More broadly, it would be nice if Sec 2.4 discussed the property that the server CID changes pretty much immediately. We wouldn't want people to bind to a 2-tuple of CIDs and have that immediately fail.
NAME I create PR based on your comment. Is that sufficient? NAME which section are you talking about?
I think will fix NAME comment here.
Much better. My comment here is mostly a nit. I think that you are implicitly talking about the first packet from the client, so maybe you can avoid using the "Client Initial" thing here (if you are using the abstract concept you introduced), "client Initial" (that is, Initial packets sent by a client), or anything that might be confusing.

Revised text:
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 bits of the header are both set to 0.  Then the  <ins> Destination Connection ID needs to be extracted from the packet.  The Initial secret is calculated using the version-specific Initial salt, as described in Section 5.2 of QUIC-TLS.  The length of the connection ID is indicated in the 6th byte of the header followed by the connection ID itself. Note that subsequent Initial packets might contain a Destination Connection ID other than the one used to generate the Initial secret. Therefore, attempts to decrypt these packets using the procedure above might fail unless the Initial secret is retained by the observer. </ins> To determine the end of the header and find the start of the payload, the packet number length, the source connection ID length, and the Finally, an extension might define additional frame types which could be present.  3.5. The QUIC connection ID (see rebinding) is designed to allow a