Telechat Review of draft-ietf-tsvwg-usr-exp-12
review-ietf-tsvwg-usr-exp-12-artart-telechat-duerst-2025-09-07-00

Hello Joe,

Many thanks for integrating my comments into your draft.

As far as I'm concerned, the draft is ready to move to the next stage.

Regards,    Martin.

On 2025-09-02 13:22, touch@strayalpha.com wrote:
> Hi, Martin,
>
> Thank you for your detailed review.
>
> Responses below.
>
> Joe
>
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com
>
>> On Aug 4, 2025, at 2:25 AM, Martin Dürst via Datatracker <noreply@ietf.org>
wrote: >> >> Document: draft-ietf-tsvwg-usr-exp >> Title: User Ports for
Experiments >> Reviewer: Martin Dürst >> Review result: Ready with Issues >> >>
Hello everybody, >> >> This is my artart review of draft-ietf-tsvwg-usr-exp-10.
>> >> The document proposes to reserve two ports for use in experiments;
different >> experiments are distinguished by using a kind of 'magic number' at
the start of >> the application data. >> >>>  From an application perspective,
I'd want to see more discussion about what >> should happen when something
moves from an experiment to deployment. (My >> understanding is that in that
case, an actual port should be applied for, and >> that the document should
clearly say so.) > > That is now addressed in the end of section 4.  Detailed
guidance already has been published in RFC7605, which is cited there. > >> In
general, the document is well written, but there are too many "could", >>
"might", and similar words. Here is an example (only half of a sentence, >>
because the sentence is very long): "to reduce the potential that experimental
>> uses of PExIDs that could be tested in the public Internet might interfere
with >> each other.": This can (and should) be rewritten without loss of
clarity to "to >> reduce the potential that experimental uses of PExIDs that
are tested in the >> public Internet interfere with each other." There are many
similar cases in the >> document. > > I’ve checked occurrences and revised
those uses for clarity. > >> Individual comments: >> - I'm not sure why the
update text to RFC 4727 is in the introduction. It's >> fine to mention in the
introduction that RFC 4727 is updated by this document, >> but the actual text
should come later. > > The text does come later, but the abstract is
sufficiently brief that removing that detail does not seem necessary and would
only “bury the lede” (or at least one lede). > >> - Section 3 should say that
the actual port definitions are given in section 8. > > Done > >> - "User ports
are also more likely to allow configuration >>    to pass through firewalls,
where system and dynamic ports can be >>    difficult to 'un-block'.": The way
I understand it, it's data, not >>    configuration, that passes though
firewalls. > > It was worded poorly; that’s not the intent. It was revised as:
> > User ports are also more likely be allowed in firewall configurations,
where system and dynamic ports can be difficult to ‘un-block’. > >> - "the bar
for PExID registration is low (first-come, first served) and >> encouraged.":
>>   No, the bar isn't encouraged; it's the registration that's encouraged. > >
Revised as: > PExIDs are obtained as first-come, first-served with no
additional requirements, so registration is both easy and encouraged > >> - I
wonder whether it's necessary to bother IANA with PExID registration. There >>
could potentially be a large number of registrations. Simply requiring random
>> selection would make the potential for collisions quite low, and the fact
that >> PExIDs aren't registered would clearly give the message that these are
only >> experimental, and any protocol/application desiring wider use should
apply for >> a dedicated port. > > Mechanisms for self-registration via
arbitrary (‘random’) selection would require a mechanism for “duplicate
detection” and resolution. Further, there is precedence for such registration
(TCP ExIDs  and soon UDP ExIDs as well). We also don’t want to encourage
’squatting’, which would suggest that users should self-select an assignable
port number rather than a PExID. PExIDs are intended to lower the bar vs a port
assignment,  to encourage protocol designers to *expect* to register *before*
deployment. > >> - Section 5 should immediately start with a subsection
entitled "General >> Considerations for PExID Use" (or some such), because the
reader expects >> Section 5 to be as short as the previous ones and is then
surprised when seeing >> the "SCTP and DCCP PExID Use" section. > > Fixed;
added new 5.1 header for "PExID Use in General”, prefaced by: > > The remainder
of this section describes PExID use in transport protocols in general, the
detailed issues associated with SCTP and DCCP use, and PExID coordination
during state negotiation. > >> - There should be some advice on whether
different PExIDs can/should be used to >> distinguish protocol versions in the
'same' overall experiment, e.g. to avoid >> ossification (see e.g. RFC 9170). >
> The new Section 5.1 addresses this, but recommends against it as follows: > >
However, PExIDs SHOULD NOT be used to differentiate versions of a protocol or
service, because such a service would be more difficult to transition to use of
an assigned port for all future versions, as required by [RFC7605]. > >> -
"network-standard byte order" (one instance) -> "network standard byte order" >
> Although RFC 1876 does not use the hyphen (as do RFCs 206 and 55 when
referring to a “network-standard” protocol and command language, respectively,
more recent uses in RFC 5925 and 6994 do. I’ll keep it as-is, noting that the
RFC Editor will ensure it is consistent per their guidelines anyway. > >> -
Section 6: The second paragraph is about STUN, then the third paragraph seems
>> to be about TURN, but falls back to STUN. Confusing at least to this reader.
> > The text on STUN has been moved to the second paragraph. > >> - Section 7:
DPI is mentioned without expansion. I tried to find out what was >> meant by
looking up Section 5.3.1 of RFC 6973, but that RFC doesn't have a >> section
5.3.1. > > Fixed; it should be 5.2.1 and the expansion is provided. > >> -
"Experimenters are encouraged to include security in any new experiment...": >>
I'm sure this isn't mean this way, but it sounds as if one could just sprinkle
>> a bit of security over an experiment. Something such as "Experimenters are
>> encouraged to design and implement their experiments with the necessary >>
security features..." seems more appropriate. > > Fixed to mimic the text in
RFC 7605: > Experimenters are expected to support security capabilities in any
new experiment, regardless of whether an experimental or assigned port is being
used (per Section 7.4 of [RFC7605]). > >> - Section 8: "system (EXP1, EXP2)"
ports: It would be good to give the port >> numbers here again (they are given
in the introduction). It may also be better >> to use lowercase, to match what
IANA does (see >>
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=16).
> > Port names are case-insensitive; we use uppercase to make them stand out in
the text (this is noted now). > >> - At the bottom of >>
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt,
>> I found (regarding the EXP1 and EXP2 system ports) "[1] It is only
appropriate >> to use these values in explicitly-configured experiments; they
MUST NOT be >> shipped as defaults in implementations.  See RFC 3692 for
details." That text >> strangely enough doesn't turn up in the paginated
version (see last comment). >> Maybe something similar should also be include
in this document? > > It is (see above now). It might be useful to report the
pagination error (I don’t quite know to whom, though). > >> Regards,    Martin.
>> >> >>