Re: [port-srv-reg] Fwd: Re: [DNSOP] New version of document for review

[Magnus Westerlund <[e-mail]>]

Joe Touch skrev 2010-12-02 04:46:
> Catching up, was this ever addressed?

No, even I forgot about them.

> 
> My cycles for this doc this month have expired; can anyone else address 
> these if needed?

Ok

>> -------- Ursprungligt meddelande --------
>> Ämne: Re: [DNSOP] New version of document for review
>> Datum: Mon, 1 Mar 2010 03:38:12 +0100
>> Från: Doug Barton<[e-mail]>
>> Till: Michelle Cotton<[e-mail]>
>> Kopia: [e-mail]<[e-mail]>, [e-mail]
>> <[e-mail]>rg>,	[e-mail]<[e-mail]>
>>
>> On 01/15/10 08:16, Michelle Cotton wrote:
>>> Attn: TSVWG Working Group, DNSOPS Working Group and APPS AREA Working Group
>>>
>>> There is a new version of the Internet Assigned Numbers Authority (IANA)
>>> Procedures for the Management
>>> of the Transport Protocol Port Number and Service Name Registry document:
>>>
>>> draft-ietf-tsvwg-iana-ports-04.txt
>>>
>>> Please review and send comments.  Your feedback is much appreciated.
>>
>> I'm writing to provide both review and support of this draft. Before I
>> do however it's probably useful for me to make some explicit statements,
>> some of the "should go without saying" variety and some to provide
>> context for my comments.
>>
>> I was the General Manager of the IANA from late 2003 through mid 2005.
>> In that capacity I was proud to manage Michelle as one of my employees.
>> One of my responsibilities was to oversee the port number allocation
>> process, including occasionally making the final decisions on these
>> assignments myself. Other than her public messages regarding these
>> drafts I have had no communication from Michelle or anyone else from
>> ICANN regarding this topic. Other than this message today I've not
>> communicated with them about it. (IOW, ETINC.) I also have experience
>> with port numbers from the operating system implementer's perspective as
>> part of a large group of people who have "commit privileges" to the
>> FreeBSD code base.
>>
>> With all that out of the way, I would like to commend Michelle and the
>> other authors on this much needed piece of work. It is clear, well
>> written, and covers the topic very well. I know that I would very much
>> like to have had such a clear set of guidelines to operate under while I
>> was making these decisions. I do have some feedback, none of which I
>> consider to be show-stopper issues. If the draft were to progress in its
>> current condition I would be supportive.
>>
>> I also think it is important to move this draft forward sooner rather
>> than later since it will allow us to start using, and encouraging the
>> use of SRV in a much more meaningful way.
>>
>> I've attached a diff with some mostly minor edits. Most of them are
>> simple English language nits such as:
>> 1. Comma reduction (a topic which I'm very sensitive to since it's one
>> of my major faults when writing)
>> 2. Capitalizing the first letter of bullet points

Well, if the above are real issues then RFC-editor will do something
about them.

>>
>> I've also included some textual changes which I hope improve and/or
>> clarify the text. In all cases the authors are free to adopt or deny my
>> suggestions as they see fit.
>>
>> More substantive issues, in more or less increasing order of importance.
>> * In Section 3 I think the readability would improve by switching the
>> first and second paragraphs.

Not done, but not that important.

>> * In Section 7.2, paragraph 7, I think the change to "IANA converting
>> the reservation" makes the desired outcome (that designers not use the
>> port without IANA authorizing the change) more clear.

Seem to be approval of how things are formulated now.

>> * In Section 8.1 (and/or perhaps elsewhere?) I think it would be useful
>> to suggest (perhaps at the SHOULD level?) that when appropriate the
>> administrative contact e-mail address should be a role account, and the
>> problem this is designed to mitigate (individuals sometimes leave the
>> company/organization that is responsible for the assignment resulting in
>> a dead e-mail address).

Not discussed currently, but something that IANA themselves can make
clear in any form.

>> * In Section 6 (and elsewhere) there does not appear to be a normative
>> reference for the division of port numbers into the Well Known,
>> Registered, and Dynamic categories.

Still not present in that section.

>> * Section 7.2 mentions several suggestions to designers for reducing the
>> number of port numbers that they need for an application. I think it
>> would be useful to add 2 explicit suggestions to that list, one is the
>> idea of a "master" application with one Registered port number that can
>> coordinate communications between the various components of more
>> complicated applications without requiring each element of the
>> application to have its own assigned port number. The other suggestion I
>> think should be made explicitly in the document is the use of multicast
>> DNS to avoid port number assignments altogether.

The mDNS part is only present in section 3. However, the current draft
is much more focused on the basic principles in suggestions on how to do
anything. I think this bullet belongs in Joe's future guidelines document.

>>
>> My final area of concern is the idea people have that without an
>> assigned port number from IANA that no firewall administrators will
>> allow their traffic. You mention this issue briefly in 7.2, and in
>> Section 9 (Security Considerations) you include the text that I wrote in
>> number 2 of "PLEASE NOTE THE FOLLOWING" on the
>> http://www.iana.org/assignments/port-numbers page, both of which I think
>> are good things to include. However I believe that it would be useful to
>> have the whole concept described in more detail in 7.2. In my
>> communication with port number applicants this issue came up over and
>> over again, and was either the primary or sole consideration in filing
>> the application in the first place; resulting in more than one
>> otherwise-spurious application. I won't quibble if my opinion on the
>> importance of this topic isn't shared by others, but I felt it was
>> important to mention it.

If more discussion around this is wanted, I don't think it belongs in
the IANA policy document, more in Joes guidelines doc.

So in summary I don't see anything substantial that we have missed. Some
things for a guidelines doc to consider.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------