Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues

Alfred Hönes <ah@TR-Sys.de> Mon, 11 January 2010 12:27 UTC

Return-Path: <A.Hoenes@TR-Sys.de>
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 D88553A67F2 for <port-srv-reg@core3.amsl.com>; Mon, 11 Jan 2010 04:27:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.714
X-Spam-Level:
X-Spam-Status: No, score=0.714 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
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 MmIzJKHYhNB1 for <port-srv-reg@core3.amsl.com>; Mon, 11 Jan 2010 04:27:57 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 4E5493A67BD for <port-srv-reg@ietf.org>; Mon, 11 Jan 2010 04:27:53 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA164512851; Mon, 11 Jan 2010 13:27:31 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA07916; Mon, 11 Jan 2010 13:27:29 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@TR-Sys.de>
Message-Id: <201001111227.NAA07916@TR-Sys.de>
To: lars.eggert@nokia.com, michelle.cotton@icann.org
Date: Mon, 11 Jan 2010 13:27:28 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Cc: port-srv-reg@ietf.org, fernando@gont.com.ar
Subject: Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues
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: Mon, 11 Jan 2010 12:27:57 -0000

(1)
Paraphrased from collected wisdom:

   "allocate" or "assign" :
         IANA choses the code point, hands it out and
         publishes it; if the requester proposes a value,
         it is not binding for IANA and can be changed
         without further notice/interaction.

   "register" :
         The requester usually proposes an (already established) code
         point, and if feasible, IANA accepts and publishes the value;
         otherwise, IANA must contact the requester for another
         proposal and iterate the procedure until acceptable.

AFAICS, under the past (and present) rules, the WELL-KNOWN PORTS
have been "assigned", and ports in the range 1024-49151 have been
"registered".

If I understand correctly, under the new regime, Service Names will
be "registered" and *all* Port Numbers (if any) will be "assigned".
Is that correct?
(The draft says the requester may "suggest" a value "for allocation".)


(2)
It also should be pointed out that in the most recent predraft
I've seen (December 2, 2009 version), there still is no possibility
in the proposed registration template to distinguish between
a request for a Well Known port number without a proposed value and
a request for a Registered Port without a proposed port number --
both have to supply "Port Number: ANY".
The distinction is clear whenever a value is proposed (requested?).
In the past, I already had proposed (at least twice) to introduce
something like "ANY-WELL-KNOWN" as an alternative meta-value for
the Port Number field to make it clear to IANA what is requested.
Alternatively, a distinct field "Port Range" could be added to
the Registration template for this purpose.

(3)
Furthermore, to make sensible use of Service Names w/o assigned
port number, the Transport Protocol(s) field should not be made
optional (as in the predraft I got), but mandatory; otherwise
the clarified rules for SRV owner naming would lack a fundament.
(The need for having registered {Service Name, Protocol} pairs was
the main reason for the original Service Prefix registry proposal.)
Thus, I strongly suggest to strike the phrase,
   "If assignment of a port number is desired,"
in the description of the Transport Protocol(s) field and
strike "(if port number requested)" in the overview in 8.1,
precding the bullets for the template fields.


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+