| Newsgroups |
gmane.ietf.apps-discuss,gmane.ietf.tsvwg |
| Message-ID |
<[email protected]> |
--===============1187905497227312344==
Content-Type: multipart/alternative;
boundary="Apple-Mail=_3EC7A9BC-39D2-4709-AB2E-D2E4EF634A9A"
--Apple-Mail=_3EC7A9BC-39D2-4709-AB2E-D2E4EF634A9A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Hi, Martin,
Thank you for your detailed review.=20
Responses below.
Joe
=E2=80=94
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com
> On Aug 4, 2025, at 2:25=E2=80=AFAM, Martin D=C3=BCrst via Datatracker =
<[email protected]> wrote:
>=20
> Document: draft-ietf-tsvwg-usr-exp
> Title: User Ports for Experiments
> Reviewer: Martin D=C3=BCrst
> Review result: Ready with Issues
>=20
> Hello everybody,
>=20
> This is my artart review of draft-ietf-tsvwg-usr-exp-10.
>=20
> 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.
>=20
>> =46rom 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=E2=80=99ve checked occurrences and revised those uses for clarity.=20
> 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 =E2=80=9Cbury =
the lede=E2=80=9D (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=E2=80=99s 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 =E2=80=98un-block=E2=80=
=99.
> - "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 (=E2=80=98random=E2=80=99) =
selection would require a mechanism for =E2=80=9Cduplicate detection=E2=80=
=9D and resolution. Further, there is precedence for such registration =
(TCP ExIDs and soon UDP ExIDs as well). We also don=E2=80=99t want to =
encourage =E2=80=99squatting=E2=80=99, 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=E2=80=9D, 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 =E2=80=9Cnetwork-standard=E2=80=9D protocol and command =
language, respectively, more recent uses in RFC 5925 and 6994 do. I=E2=80=99=
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=3D16).
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=E2=80=99t quite know to whom, though).
> Regards, Martin.
>=20
>=20
>=20
--Apple-Mail=_3EC7A9BC-39D2-4709-AB2E-D2E4EF634A9A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;">Hi, =
Martin,<div><br></div><div>Thank you for your detailed =
review. </div><div><br></div><div>Responses =
below.</div><div><br></div><div>Joe</div><div><br =
id=3D"lineBreakAtBeginningOfMessage"><div>
<meta charset=3D"UTF-8"><div dir=3D"auto" style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: =
after-white-space;"><div dir=3D"auto" style=3D"caret-color: rgb(0, 0, =
0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: =
after-white-space;">=E2=80=94<div>Dr. Joe Touch, temporal =
epistemologist<div>www.strayalpha.com</div></div></div></div>
</div>
<div><br><blockquote type=3D"cite"><div>On Aug 4, 2025, at 2:25=E2=80=AFAM=
, Martin D=C3=BCrst via Datatracker <[email protected]> =
wrote:</div><br class=3D"Apple-interchange-newline"><div><div>Document: =
draft-ietf-tsvwg-usr-exp<br>Title: User Ports for =
Experiments<br>Reviewer: Martin D=C3=BCrst<br>Review result: Ready with =
Issues<br><br>Hello everybody,<br><br>This is my artart review of =
draft-ietf-tsvwg-usr-exp-10.<br><br>The document proposes to reserve two =
ports for use in experiments; different<br>experiments are distinguished =
by using a kind of 'magic number' at the start of<br>the application =
data.<br><br><blockquote type=3D"cite">=46rom an application =
perspective, I'd want to see more discussion about =
what<br></blockquote>should happen when something moves from an =
experiment to deployment. (My<br>understanding is that in that case, an =
actual port should be applied for, and<br>that the document should =
clearly say so.)<br></div></div></blockquote><div><br></div>That is now =
addressed in the end of section 4. Detailed guidance already has =
been published in RFC7605, which is cited =
there.</div><div><br><blockquote type=3D"cite"><div><div>In general, the =
document is well written, but there are too many "could",<br>"might", =
and similar words. Here is an example (only half of a =
sentence,<br>because the sentence is very long): "to reduce the =
potential that experimental<br>uses of PExIDs that could be tested in =
the public Internet might interfere with<br>each other.": This can (and =
should) be rewritten without loss of clarity to "to<br>reduce the =
potential that experimental uses of PExIDs that are tested in =
the<br>public Internet interfere with each other." There are many =
similar cases in =
the<br>document.<br></div></div></blockquote><div><br></div><div>I=E2=80=99=
ve checked occurrences and revised those uses for =
clarity. </div><br><blockquote type=3D"cite"><div><div>Individual =
comments:<br>- I'm not sure why the update text to RFC 4727 is in the =
introduction. It's<br>fine to mention in the introduction that RFC 4727 =
is updated by this document,<br>but the actual text should come =
later.<br></div></div></blockquote><div><br></div><div>The text does =
come later, but the abstract is sufficiently brief that removing that =
detail does not seem necessary and would only =E2=80=9Cbury the lede=E2=80=
=9D (or at least one lede).</div><br><blockquote type=3D"cite"><div><div>-=
Section 3 should say that the actual port definitions are given in =
section =
8.<br></div></div></blockquote><div><br></div>Done</div><div><br><blockquo=
te type=3D"cite"><div><div>- "User ports are also more likely to allow =
configuration<br> to pass through firewalls, where system =
and dynamic ports can be<br> difficult to 'un-block'.": The =
way I understand it, it's data, not<br> configuration, that =
passes though =
firewalls.<br></div></div></blockquote><div><br></div><div>It was worded =
poorly; that=E2=80=99s not the intent. It was revised =
as:</div><div><br></div><div><span style=3D"caret-color: rgb(0, 0, 0); =
color: rgb(0, 0, 0); font-size: 12pt; font-family: "Courier =
New";">User ports are also more likely be allowed in firewall =
configurations, where system and dynamic ports can be difficult to =
=E2=80=98un-block=E2=80=99.</span><span style=3D"caret-color: rgb(0, 0, =
0); color: rgb(0, 0, 0); font-family: -webkit-standard; font-size: =
medium;"></span></div><br><blockquote type=3D"cite"><div><div>- "the bar =
for PExID registration is low (first-come, first served) =
and<br>encouraged.":<br> No, the bar isn't encouraged; it's the =
registration that's =
encouraged.<br></div></div></blockquote><div><br></div><div>Revised =
as:</div><div><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, =
0); font-size: 12pt; font-family: "Courier New";">PExIDs are =
obtained as first-come, first-served with no additional requirements, so =
registration is both easy and encouraged</span><span style=3D"caret-color:=
rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: -webkit-standard; =
font-size: medium;"></span></div><br><blockquote type=3D"cite"><div><div>-=
I wonder whether it's necessary to bother IANA with PExID registration. =
There<br>could potentially be a large number of registrations. Simply =
requiring random<br>selection would make the potential for collisions =
quite low, and the fact that<br>PExIDs aren't registered would clearly =
give the message that these are only<br>experimental, and any =
protocol/application desiring wider use should apply for<br>a dedicated =
port.<br></div></div></blockquote><div><br></div><div>Mechanisms for =
self-registration via arbitrary (=E2=80=98random=E2=80=99) selection =
would require a mechanism for =E2=80=9Cduplicate detection=E2=80=9D and =
resolution. Further, there is precedence for such registration (TCP =
ExIDs and soon UDP ExIDs as well). We also don=E2=80=99t want to =
encourage =E2=80=99squatting=E2=80=99, 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, <span =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, =
0);"> </span><span style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0);">to encourage protocol designers to *expect* to register =
*before* deployment.</span></div><br><blockquote type=3D"cite"><div><div>-=
Section 5 should immediately start with a subsection entitled =
"General<br>Considerations for PExID Use" (or some such), because the =
reader expects<br>Section 5 to be as short as the previous ones and is =
then surprised when seeing<br>the "SCTP and DCCP PExID Use" =
section.<br></div></div></blockquote><div><br></div><div>Fixed; added =
new 5.1 header for "PExID Use in General=E2=80=9D, prefaced =
by:</div><div><br></div><div><p class=3D"MsoNormal" style=3D"margin: 0in =
0in 12pt 0.3in; line-height: 12pt; font-size: medium; font-family: =
"Courier New"; caret-color: rgb(0, 0, 0); color: rgb(0, 0, =
0);">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.</p></div><blockquote type=3D"cite"><div><div>- There should =
be some advice on whether different PExIDs can/should be used =
to<br>distinguish protocol versions in the 'same' overall experiment, =
e.g. to avoid<br>ossification (see e.g. RFC =
9170).<br></div></div></blockquote><div><br></div><div>The new Section =
5.1 addresses this, but recommends against it as =
follows:</div><div><br></div><div><span style=3D"caret-color: rgb(0, 0, =
0); color: rgb(0, 0, 0); font-size: 12pt; font-family: "Courier =
New";">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].</span><span style=3D"caret-color: rgb(0, 0, 0); =
color: rgb(0, 0, 0); font-family: -webkit-standard; font-size: =
medium;"></span></div><div><br></div><blockquote type=3D"cite"><div><div>-=
"network-standard byte order" (one instance) -> "network standard =
byte order"<br></div></div></blockquote><div><br></div><div>Although RFC =
1876 does not use the hyphen (as do RFCs 206 and 55 when referring to a =
=E2=80=9Cnetwork-standard=E2=80=9D protocol and command language, =
respectively, more recent uses in RFC 5925 and 6994 do. I=E2=80=99ll =
keep it as-is, noting that the RFC Editor will ensure it is consistent =
per their guidelines anyway.</div><br><blockquote =
type=3D"cite"><div><div>- Section 6: The second paragraph is about STUN, =
then the third paragraph seems<br>to be about TURN, but falls back to =
STUN. Confusing at least to this =
reader.<br></div></div></blockquote><div><br></div><div>The text on STUN =
has been moved to the second paragraph.</div><br><blockquote =
type=3D"cite"><div><div>- Section 7: DPI is mentioned without expansion. =
I tried to find out what was<br>meant by looking up Section 5.3.1 of RFC =
6973, but that RFC doesn't have a<br>section =
5.3.1.<br></div></div></blockquote><div><br></div>Fixed; it should be =
5.2.1 and the expansion is provided.</div><div><br><blockquote =
type=3D"cite"><div><div>- "Experimenters are encouraged to include =
security in any new experiment...":<br>I'm sure this isn't mean this =
way, but it sounds as if one could just sprinkle<br>a bit of security =
over an experiment. Something such as "Experimenters are<br>encouraged =
to design and implement their experiments with the necessary<br>security =
features..." seems more =
appropriate.<br></div></div></blockquote><div><br></div><div>Fixed to =
mimic the text in RFC 7605:</div><div><p class=3D"MsoNormal" =
style=3D"margin: 0in 0in 12pt 0.3in; line-height: 12pt; font-size: =
medium; font-family: "Courier New"; caret-color: rgb(0, 0, 0); =
color: rgb(0, 0, 0);">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]).</p></div></div><div><blockquote type=3D"cite"><div><div>- =
Section 8: "system (EXP1, EXP2)" ports: It would be good to give the =
port<br>numbers here again (they are given in the introduction). It may =
also be better<br>to use lowercase, to match what IANA does =
(see<br>https://www.iana.org/assignments/service-names-port-numbers/servic=
e-names-port-numbers.xhtml?&page=3D16).<br></div></div></blockquote><d=
iv><br></div><div>Port names are case-insensitive; we use uppercase to =
make them stand out in the text (this is noted =
now).</div><br><blockquote type=3D"cite"><div><div>- At the bottom =
of<br>https://www.iana.org/assignments/service-names-port-numbers/service-=
names-port-numbers.txt,<br>I found (regarding the EXP1 and EXP2 system =
ports) "[1] It is only appropriate<br>to use these values in =
explicitly-configured experiments; they MUST NOT be<br>shipped as =
defaults in implementations. See RFC 3692 for details." That =
text<br>strangely enough doesn't turn up in the paginated version (see =
last comment).<br>Maybe something similar should also be include in this =
document?<br></div></div></blockquote><div><br></div><div>It is (see =
above now). It might be useful to report the pagination error (I don=E2=80=
=99t quite know to whom, though).</div><br><blockquote =
type=3D"cite"><div><div>Regards, =
Martin.<br><br><br><br></div></div></blockquote></div><b=
r></div></body></html>=
--Apple-Mail=_3EC7A9BC-39D2-4709-AB2E-D2E4EF634A9A--
--===============1187905497227312344==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KYXJ0IG1haWxp
bmcgbGlzdCAtLSBhcnRAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBh
cnQtbGVhdmVAaWV0Zi5vcmcK
--===============1187905497227312344==--