(added CC to tsvwg)
Hello, Alfred,
Thanks so much for your feedback! Comments inline....
(1) Fundamental, general issue: Terminology
A few voices have caused the authors to adopt a rather questionable
terminology throughout the draft, during its last few revisions.
- "Randomization" : My 5-vol. Dictionary of Mathematics defines
(translated into English): Randomization; Randomized Algorithm:
The introduction of randomness into mathematical algorithms.
In practice, pseudo-random numbers are used.
[....]
I therefore request that these inappropriate changes in terminology be
backed out again. "Port number obfuscation" is a serious misnomer;
port numbers still are transmitted in the clear under the methods
presented in this draft; so "port number randomization" or, for short,
"port randomization" is the proper term -- and it is widely adopted
by the community since several years.
I really don't know how to proceed here. That is, I'd honor your
comment, but clearly that's not just up to me. What do the chairs and
ADs think?
(2) Abstract, last sentence
The new elaborations on RTP seem to be inappropriate.
RTP isn't a "classical" transport protocol.
RFC 3550 says (Section 11, 2nd para):
"RTP relies on the underlying protocol(s) to provide demultiplexing of
RTP data and RTCP control streams. For UDP and similar protocols, ..."
[...]
Therefore, I suggest to drop the clause on RTP entirely:
FWIW, Dan Wing suggested this as one of the possible ways forward for
the RTP issue. So unless anybody disagrees I will apply your prosed change.
(3) Abstract and Section 1 (1st para)
"Recently, awareness has been raised ..."
^^^^^^^^
The same words had been written in the first draft version in 2006.
For not overstressing the word "recent" too much, I suggest to change
that to:
"During the last few years, awareness has been raised ..."
^^^^^^^^^^^^^^^^^^^^^^^^^
Fixed.
(4) Section 2.1
There is ongoing confusion on the role of the IANA managed port number
range. This is caused by the lack of distinguishing between the roles
of ports -- server ports ((semi-)static port numbers used to 'listen')
vs. client ports (ephemeral choice for activating a transport session
with a 'listening' peer). In certain 'symmetric' protocols (peer-to-
peer applications) without out-of-band agreement on port numbers,
both communicating parties are to be regarded as taking the 'server'
role, and for these the document is not applicable.
To avoid the above confusion, I strongly suggest to clarify that the
IANA registry *only* deals with *server port numbers*.
First paragraph of 2.1:
The Internet Assigned Numbers Authority (IANA) assigns the unique
parameters and values used in protocols developed by the Internet
| Engineering Task Force (IETF), including well-known ports [IANA].
[...]
---
The Internet Assigned Numbers Authority (IANA) assigns the unique
parameters and values used in protocols developed by the Internet
| Engineering Task Force (IETF), including well-known server ports
[IANA]. [...]
^^^^^^
With this clarification, it should become evident that the use of
arbitrary port numbers as ephemeral port numbers on a particular node
does not conflict with the IANA registry, unless the same port number
is in use by a (listening) server application on the same node.
Ok. Given that the port numbers issue has been debated recently, I'd
like Lars to comment on this proposed change.
The last paragraph of 2.1 is not backed by RFC 1122 (cf. sect. 4.2.2.1).
Wrt the IANA Port number registry, Dynamic / Private Ports are simply
those ports that are recommended for *server* programs that want to
dynamically bind to a port they are listening on afterwards.
Neither the TCP standard nor STD 3 contains verbiage to globally
constrain port usage as ephemeral (client) ports.
Therefore, IMO the last paragraph of 2.1 should be deleted or changed
as follows:
The dynamic port range defined by IANA consists of the 49152-65535
| range, and is meant for the selection of ephemeral ports.
---
The dynamic port range defined by IANA consists of the 49152-65535
| range; it is meant for the dynamic selection of server ports and is
| unrelated to ephemeral port selection, although this interpretation
| has been promoted in the past.
Your suggested change makes sense to me. But as with the previous one,
I'd like to hear what Lars thinks about this one.
(5) General
A few editorial nits will be reported to the authors off-list ASAP.
Looking forward to them!
Thanks!
Kind regards,
--
Fernando Gont
e-mail: fernando(_at_)gont(_dot_)com(_dot_)ar || fgont(_at_)acm(_dot_)org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf