[tsvwg] Re: Ketan Talaulikar's Discuss on draft-ietf-tsvwg-usr-exp-12: (with DISCUSS and COMMENT)

["[e-mail]" <[e-mail]>]

Hi, Ketan,

Thank you for your review. Responses are included below.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Sep 12, 2025, at 6:09 AM, Ketan Talaulikar via Datatracker <[e-mail]> wrote:
> 
> Ketan Talaulikar has entered the following ballot position for
> draft-ietf-tsvwg-usr-exp-12: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-usr-exp/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thanks to the author and the WG for their working on the document. I support
> efforts to make experimenting easier and more effective.
> 
> However, there are some implications of the proposal in the document that I
> have concerns about and like to understand if they have been considered.
> 
> Disclaimer: I am not a transports or security expert, so please bear with me.
> 
> discuss#1
> The IANA registry for experimental codepoints (what is proposed for the PExIDs)
> seems odd. From a quick reading both RFC4340 and RFC6335 that cover similar
> port numbers for experimenting/testing do not allow for registration. I find
> the argument in the document for registration unconvincing. The unavailability
> of registration is a good motivation for new protocols to move to the use of
> "standard" registration/allocation procedures and moving away from the
> experimental code points once the experiment has been conducted and proved
> successful.

RFC4340 and 6335 do not allow for registration of assigned ports for individual experiments. This document does not do that.

This document registers two new ports for *all* experiments, in the “user” space rather than the “system” space (the latter was already done).

This document creates a registry within the use of those ports, which neither RFC above prohibits. The purpose of this registry is, as described, to help alleviate the frustration of experimenters in not being able to obtain ports form the assignable space.

As background, there are 48K assignable ports - 1K in the system range of which 70% are assigned, the remainder in the user range of which 14% are assigned, as described in detail in RFC7605. Even though there are approximately 43K remaining user ports, that is not enough to support the number of experiments that would need them without impacting a resource needed to sustain the Internet for public use.

The PExID space allows for 4B concurrent uses of the experiment ports, a resource that can then be assigned for more ephemeral purposes that would not qualify for a port assignment per RFC 6335 or 7605.

> discuss#2
> My other concern is that the proposal uses well-known ports for such
> experimentation. 

The doc does not introduce that concept; it has been around for decades, 
The use of assigned codepoints for experiments goes back to RFC 739 in 1977 (for link fields).

The system experiment port numbers were assigned in 2006 by RFC 4727.


> …I get the impression that this is being done to circumvent to
> go around firewalls and filters - does that not have security implications? In
> conjunction with the registration feature, could this be not just an experiment
> but a way to go around those security infrastructure? Why not instead pick
> something from the registered port range instead? I'd like to discuss this with
> the SEC ADs.

Ports and port assignments themselves do not get around firewalls. Firewalls are generally configured to block all ports not explicitly allowed.

There are some experiments that firewall administrators WANT to open their firewalls to - e.g., experiments by a company involving a group of alpha testers. However, some firewalls are designed to prohibit entry of port numbers outside the assignable range (in the dynamic/self-assigned range) and some users want to do experiments without privileged (root) access; that’s the case in which the new user port assignments would be useful.

> discuss#3
> IANA considerations section 8 says:
> 
>   This document directs IANA to create a "Port Experimental Option
>   Experiment Identifiers (PExIDs)" registry linked under the IANA
>   ports registry [SP-reg], using the same format and structure as the
>   TCP option ID registry [TCP-reg].  The registry records PExIDs as
>   32-bit unsigned integers, including a brief description, document
>   pointer (if available), assignee name, and e-mail contact for each
>   entry.
> 
> However, a look at the TCP-reg does not match the desired registry record. Why
> not specify the precise table desired in the document?

The “same format” is a precise description of that table. The text has been updated in coordination with IANA to be sufficiently unambiguous to them.

> discuss#4
> IANA considerations section 8 says:
> 
> IANA will also record known duplicate uses to assist the
>   community in both debugging assigned uses as well as correcting
>   unauthorized duplicate uses.
> 
> How will IANA come to know of this?'

We (I as team lead for the ports review, in specific) get reports of such duplicate uses of assigned ports occasionally via email.

> Why would there be duplicates if everyone
> is being asked to register.

It happens for assigned ports; it will happen for PExIDs. It happens for all codepoints.

A rule is not a law; IANA is not an enforcement agency.

> And if there are duplicates, then does the argument
> for having a registry itself not fail?

See above; registries are cooperative agreements among consenting parties. They are there to help those who want to be helped.

We do not create laws for the lawless - doing so, as you note, would be useless.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support the DISCUSS position from Med.