Re: [DNSOP] New version of document for review
Doug Barton <dougb@dougbarton.us> Mon, 01 March 2010 02:45 UTC
Return-Path: <dougb@dougbarton.us>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55EAC3A88C0 for <apps-discuss@core3.amsl.com>; Sun, 28 Feb 2010 18:45:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbKpNYvB6Uqv for <apps-discuss@core3.amsl.com>; Sun, 28 Feb 2010 18:45:20 -0800 (PST)
Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by core3.amsl.com (Postfix) with ESMTP id C7BD33A862F for <apps-discuss@ietf.org>; Sun, 28 Feb 2010 18:45:19 -0800 (PST)
Received: (qmail 32682 invoked by uid 399); 1 Mar 2010 02:38:31 -0000
Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Mar 2010 02:38:31 -0000
X-Originating-IP: 127.0.0.1
X-Sender: dougb@dougbarton.us
Message-ID: <4B8B2894.40702@dougbarton.us>
Date: Sun, 28 Feb 2010 18:38:12 -0800
From: Doug Barton <dougb@dougbarton.us>
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1
MIME-Version: 1.0
To: Michelle Cotton <michelle.cotton@icann.org>
Subject: Re: [DNSOP] New version of document for review
References: <C775D4C1.1F7D2%michelle.cotton@icann.org>
In-Reply-To: <C775D4C1.1F7D2%michelle.cotton@icann.org>
X-Enigmail-Version: 1.0.1
OpenPGP: id=D5B2F0FB
Content-Type: multipart/mixed; boundary="------------030700080506000703090203"
X-Mailman-Approved-At: Mon, 01 Mar 2010 08:16:19 -0800
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2010 02:45:20 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 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 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. * 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. * 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). * 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. * 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. 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. I hope that these comments are helpful, and I apologize for not offering them sooner. Best regards, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEAREDAAYFAkuLKJQACgkQyIakK9Wy8PtcaACg5lEBJw12OwUGCn6i98VDlkHQ oI0AoLfNB0fMMGJ42dPV6d38V+i3pPr0 =giEw -----END PGP SIGNATURE-----
- New version of document for review Michelle Cotton
- Re: [tsvwg] New version of document for review tom.petch
- Re: [tsvwg] New version of document for review Joe Touch
- Re: [DNSOP] New version of document for review Doug Barton