(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@xxxxxxxxxxx || fgont@xxxxxxx PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf