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

Michelle Cotton <michelle.cotton@icann.org> Fri, 03 September 2010 19:01 UTC

Return-Path: <michelle.cotton@icann.org>
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 867073A6960 for <port-srv-reg@core3.amsl.com>; Fri, 3 Sep 2010 12:01:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.141
X-Spam-Level:
X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 af2Xp+G67aAp for <port-srv-reg@core3.amsl.com>; Fri, 3 Sep 2010 12:01:22 -0700 (PDT)
Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 020DB3A6902 for <port-srv-reg@ietf.org>; Fri, 3 Sep 2010 12:01:22 -0700 (PDT)
Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Fri, 3 Sep 2010 12:01:51 -0700
From: Michelle Cotton <michelle.cotton@icann.org>
To: Alexey Melnikov <alexey.melnikov@isode.com>, Lars Eggert <lars.eggert@nokia.com>, Stuart Cheshire <cheshire@apple.com>
Date: Fri, 3 Sep 2010 12:01:49 -0700
Thread-Topic: [port-srv-reg] Four final points for discussion
Thread-Index: ActLQn6PKUCq8JxiRY274UB/wmZb2wAV/efH
Message-ID: <C8A6942D.282AF%michelle.cotton@icann.org>
In-Reply-To: <4C80B256.3090007@isode.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C8A6942D282AFmichellecottonicannorg_"
MIME-Version: 1.0
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 19:01:23 -0000

I agree with all the changes below.
Regarding the last point, can the service name aliases for future registrations go in the notes column?

Michelle


On 9/3/10 1:31 AM, "Alexey Melnikov" <alexey.melnikov@isode.com> wrote:

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.

_______________________________________________
Port-srv-reg mailing list
Port-srv-reg@ietf.org
https://www.ietf.org/mailman/listinfo/port-srv-reg