Liaison statement
Reply LS on port allocation for the W1 interface

The IESG apologizes for not providing a more timely reply to your liaison
statement. We hope that at least the approval of the assignment of the port
for the W1 interface was timely. We positively recognize that 3GPP has
initiated work to figure out suitable solutions to handle port usage for
network internal interfaces without the need for a static port assignment
from IANA.



It was further requested by the 3GPP's liaison to IETF that some additional
guidance and clarifications in regards to the future possibilities for port
registrations by 3GPP with IANA are desirable. Below we will attempt to
provide such clarifications.



We like to point to the rules and policies documented in BCP 165 (RFC6335
and RFC7605) apply to any future request. The one that is most relevant to
3GPP for any future request is the expectation that assignment of only a
single port number per transport  protocol will be sufficient across all the
future external services, i.e. all 3GPP interfaces that 3GPP defines that
use that transport protocol. This can be realized in multiple ways and is
something that your own work items should address. Some example of such
methods include:




*	When using (D)TLS one can apply for application-layer protocol
negotiation (ALPN) labels (RFC7301) to identify the protocol being used
within a (D)TLS session.
*	Multiple servers with different names can share an IP address and
port number when protocols enable demultiplexing by server name.  An example
is (D)TLS using Server Name Indication (RFC6066).
*	When using HTTP-based services, use the URI namespace to efficiently
separate the different services.
*	Other protocol-specific methods for upper layer protocol
demultiplexing, such as SCTP's Payload Protocol Identifier (PPID) (RFC4960),
which enable routing of individual messages to the right consumer on a
server.
*	A 3GPP-defined service discovery solution that redirects to other
ports for the individual services.



In general we recommend that 3GPP completely avoid the need for port
registrations in the system and user range with IANA. Service names
(RFC6335) use first-come-first-served registration and have low bars for
registration due to the almost unlimited size of the name space, basically
only intended to prevent abuse and mass registration. Service names can be
combined with DNS and SRV records to look up a service's port number or can
be incorporated into a service demultiplexing solution.



3GPP is still requested to apply for a port assignment if you have a need
for a port assignment in the user port range (1024-49151). These should meet
the rules and policies of the port registry. Further, to enhance any future
IANA requests and their handling, the IESG recommends that any future
assignment request should be very clear on how this port assignment will
ensure that no further port assignments to 3GPP will be necessary for that
protocol and have a versioning mechanism to handle future upgrades.



In case 3GPP has further questions about a potential port assignment request
they are welcome to contact the Transport Area directors per email on
<mailto:tsv-ads@ietf.org> tsv-ads@ietf.org.