| 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@xxxxxxxx> 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). |
