Re: Last Call: <draft-ietf-quic-applicability-14.txt> (Applicability of the QUIC Transport Protocol) to Informational RFC

Speaking in my role on the port experts review team:

   As QUIC is a general-purpose transport protocol, there are no
   requirements that servers use a particular UDP port for QUIC.  For
   applications with a fallback to TCP that do not already have an
   alternate mapping to UDP, usually the registration (if necessary) and
   use of the UDP port number corresponding to the TCP port already
   registered for the application is appropriate.  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.
The above section glosses over two critical issues that should be addressed:

1. Whether QUIC should use port number assigned to an existing transport that does not currently assume QUIC

2. Whether / when QUIC designers should seek new port numbers

Both issues come back to a key issue that this document does not yet address: although QUIC is a new “transport”, it does not use or have its own transport protocol code point. This is by design, i.e., QUIC could easily have been designed with as a true Internet transport layer, but instead leverages NAT traversal support and other benefits of existing transports.

IMO, this section should be more clear and detailed on the consequence if this decision in the advice in this doc, e.g., IMO:
	- QUIC MUST use existing port assignments where they already exist
		- QUIC MUST differentiate between non-QUIC and QUIC use of that port, if preexisting non-QUIC assignment exists

	- the doc needs to address the cases where QUIC doesn’t have an assignment
		i.e., IMO, because QUIC isn’t a transport, it would not itself be eligible for a port assignment
		so again, it seems like applications for new ports need to be for “QUIC and non-QUIC use over UDP" (or TCP, or both)

It wouldn’t hurt to also refer to RFC7605, notably its SHOULD for use of security and to be explicit about exceptions, if any.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Jan 24, 2022, at 7:49 AM, The IESG <iesg-secretary@ietf.org> wrote:
> 
> 
> The IESG has received a request from the QUIC WG (quic) to consider the
> following document: - 'Applicability of the QUIC Transport Protocol'
>  <draft-ietf-quic-applicability-14.txt> as Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-call@ietf.org mailing lists by 2022-02-07. Exceptionally, comments may
> be sent to iesg@ietf.org instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document discusses the applicability of the QUIC transport
>   protocol, focusing on caveats impacting application protocol
>   development and deployment over QUIC.  Its intended audience is
>   designers of application protocol mappings to QUIC, and implementors
>   of these application protocols.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce