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

Joe Touch <touch@ISI.EDU> Wed, 13 January 2010 14:51 UTC

Return-Path: <touch@ISI.EDU>
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 B20633A67DA; Wed, 13 Jan 2010 06:51:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 ZW3v2YJf1dTx; Wed, 13 Jan 2010 06:51:00 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id C0B9D3A6837; Wed, 13 Jan 2010 06:50:57 -0800 (PST)
Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o0DEo7T5021722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Jan 2010 06:50:08 -0800 (PST)
Message-ID: <4B4DDD9E.8040009@isi.edu>
Date: Wed, 13 Jan 2010 06:50:06 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Lars Eggert <lars.eggert@nokia.com>
References: <201001111508.QAA08192@TR-Sys.de> <54E3D339-1E62-4BD1-9AA0-80F3C348724F@nokia.com>
In-Reply-To: <54E3D339-1E62-4BD1-9AA0-80F3C348724F@nokia.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: o0DEo7T5021722
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= <ah@tr-sys.de>, "port-srv-reg@ietf.org" <port-srv-reg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
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: Wed, 13 Jan 2010 14:51:01 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Lars Eggert wrote:
> Hi,
> 
> responding to Alfred and Joe in one go.
> 
> On 2010-1-11, at 17:08, ah@tr-sys.de wrote:
>> If no specific port number is specified in the request to IANA,
>> how can IANA determine which port *range* to use for the assignment ?
>>
>> That's the question for which I see no answer in the text of
>> Section 8.1 (unless it has been changed since we have been
>> provided with a working copy dated Dec. 2).
> 
> I checked and the text says:
> 
> 	If the text "ANY" is specified, IANA will choose
> 	a suitable number from the Registered Ports range.
> 
> So in order to get a Well Known port, the applicant has to specify
> which one. That's OK, because you need to pass IETF Review anyway, which
> means you need a draft, and all requests for the Well Known range I've
> ever seen had already picked their port.

I think that IANA would be glad to pick a Well Known port number if the
applicant doesn't care, though (see below). As you've seen in other
cases, the text on the current IANA forms and web pages may not have
been chosen to be so specific.

> On 2010-1-11, at 17:06, Joe Touch wrote:
>> Lars Eggert wrote:
>>> On 2010-1-11, at 14:27, ah@tr-sys.de wrote:
>>>> Paraphrased from collected wisdom:
>>>>  "allocate" or "assign" :
> ...
>>>>  "register" :
>>> I'd like to hear if IANA is of the same opinion. My impression was that assign = register.
>> There's a third variant, and it isn't covered above:
>>
>> 	requester usually proposes a code point, and IANA
>> 	can either approve it or propose a different one.
>> 	IANA usually confirms the requester's acceptance
>> 	of the code point offered.
> 
> Maybe I'm dense, but I don't understand how that is a third option.
> Either IANA views "registered" and "assigned" as synonyms or they don't :-)

I think they do. The two variants you gave were also different in how
the code point was picked, though - the third option is in that aspect:

(as you listed):
	- IANA picks the code point

	- requester usually picks the code point
		if IANA disagrees, then
		IANA asks the requester to pick a different one
                ^^^^^^^^^^^^^^^^^^^^^^^

I was suggesting that:
	- requester usually picks the code point
		if IANA disagrees, then
		IANA proposes an alternate and asks for confirmation
		^^^^^^^^^^^^^^^^^^^^^^^^^^

The difference is what happens when IANA doesn't like the suggested code
point. I don't think it matters much who suggests the alternate, but in
practice it's usually IANA that does the suggesting. Maybe it's OK to say:
	an different code point is selected until agreed

>>>> (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.
>>
>> IMO, this basically treats SRV names as old port numbers were treated -
>> i.e., ask for a name, get ALL transports. That's how port number
>> assignments were done until recently, where now only the needed
>> transport is assigned.
>>
>> So IMO a service means something only relative to a transport. However,
>> it'd be useful to require the transport be specified only if the same
>> name would mean different things for different transports. Do we ever
>> see that happening?
> 
> Right. Or, in other words, if you have a service name, it's yours for
> all transports, just as ports used to be. (There are so many service
> names that we can burn combinations that aren't used, and limit
> interactions with IANA.)

Agreed - you claimed that a service name is for a service, not a
service/transport combo. I think it's worth nothing that a service is
*always* indicated as a service/transport combo, and that a service name
is intended for all current and future transports - the port number or
other code points (DCCP extras?) can vary on a per transport basis, though.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAktN3Z0ACgkQE5f5cImnZrumdwCglZOJxgIwQImN3h1H165/7RZk
I2UAoL/7JHydkRONeHUL/PyvxBkc7FiH
=ya+9
-----END PGP SIGNATURE-----