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

Lars Eggert <lars.eggert@nokia.com> Mon, 11 January 2010 12:47 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 95B823A67D1 for <port-srv-reg@core3.amsl.com>; Mon, 11 Jan 2010 04:47:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level:
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 adXx8RC0QP3L for <port-srv-reg@core3.amsl.com>; Mon, 11 Jan 2010 04:47:54 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A68273A6403 for <port-srv-reg@ietf.org>; Mon, 11 Jan 2010 04:47:54 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0BCkhjJ001937; Mon, 11 Jan 2010 06:46:46 -0600
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 14:46:35 +0200
Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 14:46:35 +0200
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0BCkXSp022247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jan 2010 14:46:34 +0200
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/signed; boundary=Apple-Mail-2--708542631; protocol="application/pkcs7-signature"; micalg=sha1
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <201001111227.NAA07916@TR-Sys.de>
Date: Mon, 11 Jan 2010 14:46:22 +0200
Message-Id: <D0C0A51B-5A8A-414E-9E56-033EFA8ED71C@nokia.com>
References: <201001111227.NAA07916@TR-Sys.de>
To: ah@tr-sys.de
X-Mailer: Apple Mail (2.1077)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 11 Jan 2010 14:46:27 +0200 (EET)
X-OriginalArrivalTime: 11 Jan 2010 12:46:35.0763 (UTC) FILETIME=[1C2BF430:01CA92BC]
X-Nokia-AV: Clean
Cc: "port-srv-reg@ietf.org" <port-srv-reg@ietf.org>, "fernando@gont.com.ar" <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:47:55 -0000

Hi,

On 2010-1-11, at 14:27, ah@tr-sys.de wrote:
> (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.

I'd like to hear if IANA is of the same opinion. My impression was that assign = register.

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

The draft was written under the assumption that assign = register.

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

And that's on purpose: for both regions of the port number space, requesters may (but need not) suggest a number

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

Why? A service name is a name for a service, and not for a service/transport combination.

Lars

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