Re: [port-srv-reg] Four final points for discussion

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 03 September 2010 08:31 UTC

Return-Path: <alexey.melnikov@isode.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 3137D3A67FF for <port-srv-reg@core3.amsl.com>; Fri, 3 Sep 2010 01:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.522
X-Spam-Level:
X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, 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 l3Z7-mLPQzNA for <port-srv-reg@core3.amsl.com>; Fri, 3 Sep 2010 01:31:10 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 51C5D3A67FB for <port-srv-reg@ietf.org>; Fri, 3 Sep 2010 01:31:10 -0700 (PDT)
Received: from [188.28.97.130] (188.28.97.130.threembb.co.uk [188.28.97.130]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <TICyaABIED7F@rufus.isode.com>; Fri, 3 Sep 2010 09:31:38 +0100
Message-ID: <4C80B256.3090007@isode.com>
Date: Fri, 03 Sep 2010 09:31:18 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Lars Eggert <lars.eggert@nokia.com>, Stuart Cheshire <cheshire@apple.com>
References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <5D2DD7D7-A429-4CFC-BD27-EF09CEF5AE1B@apple.com> <29A788ED-1768-4BD8-B0BA-0D79C7B9843B@nokia.com>
In-Reply-To: <29A788ED-1768-4BD8-B0BA-0D79C7B9843B@nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "port-srv-reg@ietf.org" <port-srv-reg@ietf.org>
Subject: Re: [port-srv-reg] Four final points for discussion
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: Fri, 03 Sep 2010 08:31:12 -0000

Lars Eggert wrote:

>Hi,
>
>On 2010-9-3, at 10:16, Stuart Cheshire wrote:
>  
>
>>1. Name of the Registry
>>
>>Right now the document calls it:
>>
>>  Transport Protocol Port Number and Service Name Registry
>>
>>However, Section 5 says:
>>
>>  Service names are the unique key in the Port and Service Name registry.
>>
>>Since Service names really are the primary identifier, and the port number is optional, and we expect to see more and more registrations without port numbers, would it make sense to switch the order of the words, and make it:
>>
>>  Registry of Service Names and Transport Protocol Port Numbers
>>    
>>
>agree that we should use one name for the registry throughout. Am OK with your proposal; the main reason I put port numbers first in the title was that historically, that was what the registry was known as, and I didn't want to confuse people.
>  
>
BTW, Alfred also raised this point, so changing the registry name would 
keep him happier.

>>2. Service Name Rules
>>
>>I liked Joe's earlier suggestion to disallow all-numeric service names, to avoid service names that look like a numeric port number. However, even with that rule, we still allow service names like this: "6000-6063" (looks like the X Window System port range). Do we care? We could prevent that by requiring that all service names contain at least one alphabetic character.
>>    
>>
>I like that proposal.
>  
>
Fine with me.

>>3. Inconsistent terminology.
>>
>>We use the term "Registered Ports" in some places to mean "ports in the range 1024-49151", and in other places to mean any "port recorded by IANA in the Registry".
>>
>>For example, the first meaning:
>>
>>         <t>the Well Known Ports, also known as the System Ports, from 0-1023
>>         (assigned by IANA)</t>
>>
>>         <t>the Registered Ports, also known as the User Ports, from
>>         1024-49151 (assigned by IANA)</t>
>>
>>         <t>the Dynamic Ports, also known as the Private Ports, from
>>         49152-65535 (never assigned)</t>
>>
>>and now the second:
>>
>>     <t>It is important to note that ownership of registered port numbers and
>>     service names remains with IANA. For protocols developed by IETF working
>>
>>     Thousands of applications and application-level
>>     protocols have registered ports and service names for their use, and
>>     there is every reason to believe that this trend will continue into the
>>     future.
>>
>>Would it be better to strictly use the terms "System Ports" and "User Ports" to denote the ranges, and keep the term "registered port" to just mean generically, "recorded by IANA in the Registry"?
>>    
>>
>We can also use the term "assigned" instead of "registered" in the second case.
>  
>
Works for me.

>>4. Aliases
>>
>>The document says:
>>
>>     <t>IANA is also instructed to indicate which service name aliases in the
>>     existing registry are the primary aliases (see <xref target="srvname"/>).</t>
>>
>>Why should we burden IANA with this decision making? I bet there aren't that many. Let's just work it out ourselves, and list them in the document. I'll grep the IANA ports page and send a followup email with the list of aliased names.
>>    
>>
>OK.
>
Is this text talking about future registrations as well? I.e. if there 
are future requests to register an alias, this requires IANA to show in 
the registry which is primary. IANA doesn't necessarily needs to make 
the decision, IANA just needs to show this somehow.