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-----