Original text:
5.  [EDITOR'S NOTE: give some guidance here about the steps an application should take; however this is still work in progress] <del> 6. </del>  QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established,

Reviewer comments:
hopefully addresses issue
I don't think "the same port number as would be used for the same application over TCP" is necessary general-purpose guidance. I would argue for something more like:
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:
5. <ins> As QUIC is a general purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC in general.  Instead, the same port number is used as would be used for the same application over TCP.  In the case of HTTP the expectation is that port 443 is used, which has already been registered for "http protocol over TLS/SSL".  However, QUIC-HTTP also specifies the use of Alt-Svc for HTTP/QUIC discovery which allows the server to use and announce a different port number. In general, port numbers serves two purposes: "first, they provide a demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the application protocol and associated service to which processes connect" RFC6335.  Note that the assumption that an application can be identified in the network based on the port number is less true today, due to encapsulation, mechanisms for dynamic port assignments as well as NATs. However, whenever a non-standard port is used which does not enable easy mapping to a registered service name, this can lead to blocking by network elements such as firewalls that rely on the port number as a first order of filtering. 6. </ins> [EDITOR'S NOTE: give some guidance here about the steps an application should take; however this is still work in progress]  <ins> 7. </ins> QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established,