Change:
based application identification impossible through passive measurement. <ins> 3.3.1. If the SNI is not encrypted it can be derived from the QUIC Initial packet by calculating the Initial Secret to decrypt the packet payload and parse the QUIC CRYPTO Frame containing the TLS ClientHello. As both the initial salt for the Initial Secret as well as CRYPTO frame itself are version-specific, the first step is always to parse the version number (second to sixth byte of the long header).  Note that only long header packets carry the version number, so it is necessary to also check the if first bit of the QUIC packet is set to 1, indicating a long header. Note, that proprietary QUIC versions, that have been deployed before standardization, might not set the first bit in a QUIC long header packets to 1.  To parse these versions example code is provided in the appendix (see sec-google-version), however, it is expected that these versions will gradually disappear over time. 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 Client Destination Connection ID needs to be extracted to calculate 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 itself. To determine the end of the header and find the start of the payload further the packet number length, the source connection ID length, as well as the token length need to be extracted.  The packet number length is defined by the seventh and eight bits of the header as described in section 17.2. of QUIC-TRANSPORT.  The source connection ID length is specified in the byte after the destination connection ID.  And the token length, which follows the source connection ID, is a variable length integer as specified in section 16 of QUIC- TRANSPORT. Finally after decryption, the Initial Client packet can be parsed to detect the CRYPTO frame that contains the TLS Client Hello, which then can be respectively parsed similar as for all other TLS connections.  The Initial client packet may contain other frames, so the first byte of each frame need to be checked to identify the frame type and the skip over the frame.  Note that the length of the frames is dependent on the frame type.  Usually for QUIC version 1, the packet is expected to only carry the CRYPTO frame and optionally padding frames.  However, padding which is one byte of zeros, may also occur before or after the CRYPTO frame. </ins> 3.4. The QUIC Connection ID (see rebinding) is designed to allow an on-

Discussion:
This PR adds a new section on extracting the SNI. I also copied (most of) the pseudo code from Davids document into the appendix. We need to decide if we want to keep this and if so, potentially add some more explanation there. Also we could further strengthen the point out that both the 5-tuple and conn ID can change (as in David's doc). There is already text directly following the new SNI section on "flow association". If we want stronger text there, maybe we can capture that in a separate issue though.
I don't think that you should include the entirety of David's code. There are ways in which that will contribute to ossification. Indeed, I don't think that it is helpful to list draft versions here either.