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

Lars Eggert <lars.eggert@nokia.com> Thu, 02 December 2010 17:58 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: port-srv-reg@core3.amsl.com
Delivered-To: port-srv-reg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F2C3A6979 for <port-srv-reg@core3.amsl.com>; Thu, 2 Dec 2010 09:58:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.067
X-Spam-Level:
X-Spam-Status: No, score=-104.067 tagged_above=-999 required=5 tests=[AWL=1.532, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 pxtxM1BdIHZ5 for <port-srv-reg@core3.amsl.com>; Thu, 2 Dec 2010 09:57:57 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id B30C93A6967 for <port-srv-reg@ietf.org>; Thu, 2 Dec 2010 09:57:57 -0800 (PST)
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oB2Hx9UO009169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Dec 2010 19:59:10 +0200
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/signed; boundary=Apple-Mail-5--527071653; protocol="application/pkcs7-signature"; micalg=sha1
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <4CF7D183.3040704@ericsson.com>
Date: Thu, 2 Dec 2010 19:59:00 +0200
Message-Id: <B9C2EAA2-78D7-4CB2-B584-5F1BE48E17FB@nokia.com>
References: <4CC971F7.1000504@ericsson.com> <4CF71688.4050404@isi.edu> <4CF7D183.3040704@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.1082)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 02 Dec 2010 19:59:06 +0200 (EET)
X-Nokia-AV: Clean
Cc: "port-srv-reg@ietf.org" <port-srv-reg@ietf.org>
Subject: Re: [port-srv-reg] Fwd: Re: [DNSOP] New version of document for review
X-BeenThere: port-srv-reg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of updates to service name and transport protocol port registry <port-srv-reg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/port-srv-reg>, <mailto:port-srv-reg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/port-srv-reg>
List-Post: <mailto:port-srv-reg@ietf.org>
List-Help: <mailto:port-srv-reg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/port-srv-reg>, <mailto:port-srv-reg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Dec 2010 17:58:01 -0000

Hi,

On 2010-12-2, at 19:04, Magnus Westerlund wrote:
> Joe Touch skrev 2010-12-02 04:46:
>> Catching up, was this ever addressed?
> 
> No, even I forgot about them.

oops.

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

Agreed. Or we merge it in case we need to rev after IETF last call or IESG evaluation.

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

Agree.

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

Or we add a sentence into the current working version now, to be included whenever we issue one.

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

*Is* there even such a reference? I thought it was a historic artifact.

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

Agreed.

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

Not sure, if it comes up again and again, it may make sense to put it into both documents.

Lars

> 
> 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  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> _______________________________________________
> Port-srv-reg mailing list
> Port-srv-reg@ietf.org
> https://www.ietf.org/mailman/listinfo/port-srv-reg