Draft: draft-ietf-quic-applicability

Commentary: Both documents provide limited guidance on use of ports , however , there was an open question if the applicability statement should maybe say more and e.g. also talk about ALPN . 
 pending consensus on use of ALPN in -transport 
 We already have consensus to require ALPN . Unless you meant to refer to In that case , yes , you might want to explain how this works for HTTP/3 specifically . That is , the HTTP/3 ALPN refers to QUICv1 . For now . We have apparently reserved the right to revise that when we define QUICv2 . If you start to explain the controversial aspects of this ( does ALPN refer to the layer or the stack as a whole ) then you will soon find that you do n't have any concrete answers . 
 Yep , I meant quicwg / base - drafts . This document should provide some advice to application mappings other than HTTP on how / whether to use ALPN , but that advice really will depend on the larger discussion of what ALPN means ( is is app - only , a stack designator , or something in between ) . Having that discussion in this draft is probably not the right thing to do , so holding this issue open until it converges in TLS / HTTP / QUIC . 
 Probably it would be good to have a more general section on service discovery and point to the HTTP/3 doc as one example . 
 Create a new section in applicability , and reference the -http draft section 3.1 as an example .
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
As QUIC is a general purpose transport protocol, there are no
requirements that servers use a particular UDP port for QUIC in
general.  For applications with a fallback to TCP which do not
already have an alternate mapping to UDP, the registration (if
necessary) and use of the UDP port number corresponding to the TCP
port already registered for the application is RECOMMENDED.  For
example, the default port for HTTP/3 QUIC-HTTP is UDP port 443,
analogous to HTTP/1.1 or HTTP/2 over TLS over TCP.
Paragraph (version B):
Applications SHOULD define an alternate endpoint discovery mechanism
to allow the usage of ports other than the default.  For example,
HTTP/3 (QUIC-HTTP sections 3.2 and 3.3) specifies the use of ALPN
RFC7301 for service discovery which allows the server to use and
announce a different port number.  Note that HTTP/3's ALPN token
("h3") identifies not only the version of the application protocol,
but also the binding to QUIC as well as the version of QUIC itself;
this approach allows unambiguous agreement between the endpoints on
the protocol stack in use.
Paragraph (version B):
Note that given the prevalence of the assumption in network
management practice that a port number maps unambiguously to an
application, the use of ports that cannot easily be mapped to a
registered service name may lead to blocking or other interference by
network elements such as firewalls that rely on the port number for
application identification.
Paragraph (version A):
This document has no actions for IANA.
Paragraph (version B):
This document has no actions for IANA; however, note that ports
recommends that application bindings to QUIC for applications using
TCP register UDP ports analogous to their existing TCP registrations.