Original text:
2.3.  New QUIC connections are established using a handshake, which is distinguishable on the wire and contains some information that can be passively observed. the 0-RTT data.  The amount of 0-RTT protected data is limited by the initial congestion window, typically around 10 packets RFC6928. <del> 2.4. </del>  As soon as the cryptographic context is established, all information in the QUIC header, including information exposed in the packet header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. <del> 2.5. </del>  The connection ID in the QUIC packet headers allows routing of QUIC packets at load balancers on other than five-tuple information, the new connection ID being negotiated via encrypted frames.  See Section 6.1 of QUIC-TRANSPORT. <del> 2.6. </del>  The packet number field is always present in the QUIC packet header; however, it is always encrypted.  The encryption key for packet end-to-end cryptographic context.  Packet numbers are therefore not part of the wire image that is useful to on-path observers. <del> 2.7. </del>  Version negotiation is not protected, given the used protection mechanism can change with the version.  However, the choices provided

Reviewer comments:
also to address issue
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN

Revised text:
2.3. <ins> Applications that have a mapping for TCP as well as QUIC are expected to use the same port number for both services.  However, as with TCP- based services, especially when application layer information is encrypted, there is no guarantee that a specific application will use the registered port, or the used port is carrying traffic belonging to the respective registered service.  For example, QUIC-TRANSPORT specifies the use of Alt-Svc for discovery of QUIC/HTTP services on other ports. Further, as QUIC has a connection ID, it is also possible to maintain multiple QUIC connections over one 5-tuple.  However, if the connection ID is not present in the packet header, all packets of the 5-tuple belong to the same QUIC connection. 2.4. </ins> New QUIC connections are established using a handshake, which is distinguishable on the wire and contains some information that can be passively observed. the 0-RTT data.  The amount of 0-RTT protected data is limited by the initial congestion window, typically around 10 packets RFC6928.  <ins> 2.5. </ins> As soon as the cryptographic context is established, all information in the QUIC header, including information exposed in the packet header information will lead to a failed integrity check at the receiver, and can even lead to connection termination.  <ins> 2.6. </ins> The connection ID in the QUIC packet headers allows routing of QUIC packets at load balancers on other than five-tuple information, the new connection ID being negotiated via encrypted frames.  See Section 6.1 of QUIC-TRANSPORT.  <ins> 2.7. </ins> The packet number field is always present in the QUIC packet header; however, it is always encrypted.  The encryption key for packet end-to-end cryptographic context.  Packet numbers are therefore not part of the wire image that is useful to on-path observers.  <ins> 2.8. </ins> Version negotiation is not protected, given the used protection mechanism can change with the version.  However, the choices provided