Re: Use of "unassigned" in IANA registries

Lars Eggert <lars.eggert@nokia.com> Tue, 18 January 2011 14:41 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E03828C0EB for <ietf@core3.amsl.com>; Tue, 18 Jan 2011 06:41:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.355
X-Spam-Level:
X-Spam-Status: No, score=-104.355 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 lhY+sqh4mltK for <ietf@core3.amsl.com>; Tue, 18 Jan 2011 06:41:48 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 3FE5F28C117 for <ietf@ietf.org>; Tue, 18 Jan 2011 06:41:48 -0800 (PST)
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0IEiL8i003909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 16:44:22 +0200
Subject: Re: Use of "unassigned" in IANA registries
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/signed; boundary="Apple-Mail-17--772926297"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <AANLkTin9d1qyCHBzmfgJiscijDKqMvvCw4gaO8G+Kwg4@mail.gmail.com>
Date: Tue, 18 Jan 2011 16:44:13 +0200
Message-Id: <3A80901E-5D2D-4EAC-9D3E-809C0CD299FE@nokia.com>
References: <201101142206.p0EM6XNB027935@fs4113.wdf.sap.corp> <06456B13-F9E5-4530-B7E8-7CF7F41000E0@muada.com> <AANLkTiksCOABzGAVqrHQzpbyROhMPVR65zsuGVe=Q6Wg@mail.gmail.com> <27DB0613-457D-4B99-89B4-D13DC2D7232E@nokia.com> <AANLkTinHxBS7h-Y+=9fAoJgR=Az3jqd6c_bD05+K5_Lt@mail.gmail.com> <2DE3ADEAB1B54D65ADA8007B79FB4647@china.huawei.com> <AANLkTin9d1qyCHBzmfgJiscijDKqMvvCw4gaO8G+Kwg4@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
X-Mailer: Apple Mail (2.1082)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 18 Jan 2011 16:44:18 +0200 (EET)
X-Nokia-AV: Clean
Cc: Iljitsch van Beijnum <iljitsch@muada.com>, paul.hoffman@vpnc.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jan 2011 14:41:49 -0000

Hi,

On 2011-1-18, at 16:32, Phillip Hallam-Baker wrote:
> That would work IF the reason this is happening is that people don't
> understand that unassigned means reserved for future assignment.

that *is* the reason, for at least those cases that I have been involved in.

> But I rather suspect that the reason that this is happening is that people
> know full well that there is a process and choose to ignore it because they
> either can't be bothered to put up with the hassle or don't think that the
> application will be accepted.

Suspect all you want, but it doesn't match my experience.

> SRV code points are an even bigger mess because there isn't even a proper
> registry to enter them in.

We're very close to fixing this: http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports

> I think it is rather more likely that the root cause here goes back to the
> fact that the old three track standard process has broken down and the
> criteria for acceptance as a PROPOSED standard are now essentially those for
> DRAFT.

RFC2026 has almost nothing to do with IANA allocation procedures. (The only relation is that some registries require a Standards Action, but even then it is irrelevant which level of the standards track the RFC is on. And yes, it's somewhat more difficult to have a Standards Action occur than passing the bar for the other RFC5226 policies, but then again, few registries actually need a Standards Action.)

Lars