Re: Split the IANA functions?

Patrik Fältström <paf@frobbit.se> Tue, 07 January 2014 16:03 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562A81ADFA6 for <ietf@ietfa.amsl.com>; Tue, 7 Jan 2014 08:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.789
X-Spam-Level:
X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_5XRsDhOIy4 for <ietf@ietfa.amsl.com>; Tue, 7 Jan 2014 08:03:42 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 235E91ADF72 for <ietf@ietf.org>; Tue, 7 Jan 2014 08:03:42 -0800 (PST)
Received: from [IPv6:2a02:80:3ffc::2087:3375:684d:61f8] (unknown [IPv6:2a02:80:3ffc:0:2087:3375:684d:61f8]) by mail.frobbit.se (Postfix) with ESMTPSA id 9303E206A0; Tue, 7 Jan 2014 17:03:31 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_B60BA311-0084-4FA8-AFEB-895E320336E1"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: Split the IANA functions?
From: Patrik Fältström <paf@frobbit.se>
In-Reply-To: <52CC1618.1090605@cisco.com>
Date: Tue, 07 Jan 2014 17:03:30 +0100
Message-Id: <886B4045-4115-489E-8127-3F3B9A233119@frobbit.se>
References: <CAMm+LwinAb6+7BoMzwBWyu63vofndxK9VY6DSNN0Ykza4SxuMQ@mail.gmail.com> <52CB0010.5010407@gmail.com> <CAMm+LwhN8+z9q4KQXVY9bWA6TAqxx1=Qg0OUfK=VGCSDg5uWEA@mail.gmail.com> <DD618936-0D13-41F1-8D89-2E3171D864B5@istaff.org> <52CB31F4.3090703@cs.tcd.ie> <52CB987A.20300@cisco.com> <20140107144412.GB11068@mx1.yitter.info> <52CC1618.1090605@cisco.com>
To: Eliot Lear <lear@cisco.com>
X-Mailer: Apple Mail (2.1827)
Cc: "ietf@ietf.org Discussion" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 07 Jan 2014 16:03:43 -0000

On 7 jan 2014, at 15:58, Eliot Lear <lear@cisco.com> wrote:

> Andrew,
> 
> It's clear that I wasn't clear.  Deciding on a tree structure has
> political implications, be that DNS, RPKI, or other (and there are
> other).  To ignore those implications would be unwise.  They are weighed
> against technical considerations, as always.
> 
> Eliot

One have to go back to the basics for requirements of identifiers, and one of them has to do with uniqueness (others are persistence, human readability, lookup mechanisms, scale, stability, homogeneity, ability to do searches, inverse functions, and more...). Uniqueness can be local or global. And global uniqueness can in turn, if that is necessary, be done in an opportunistic way or a fool proof way. If one really need guaranteed global uniqueness and at the same time easy lookups (but not searches, inverse and other things) global distributed hierarchal allocation is a very efficient way of doing it.

What I think you say Eliot is that when one look at the requirements on whatever name space is designed, one have to take also political arguments into account. That I agree with.

But for some set of requirements, doing things in a different way than hierarchal delegated allocation is darn difficult. Instead one have to work around the political problems by (as you say) not ignoring them, but understanding the issues exist and design around them.

   Patrik