At 11:04 PM 3/2/2010, Fernando Gont wrote:
(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?
Fernando and Alfred
"randomization" in computing -- at least to me -- requires or
necessitates a randomizer (pseudo or not), which this document
doesn't attempt to specify or produce, so I'll have a hard time
getting by this recommendation of yours.
FWIW -- this was a specific point of discussion within the TSVWG, and
not just a passing comment. We discussed this at length during a
meeting, and in email with the ADs involved.
My co-chair ought to chime in here if he feels strongly one way or the other.
James
<with my TSVWG chair hat on>
> (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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf