IETF Logo Mail Archive

Re: Multiple Namespaces Re: Split the IANA functions?

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 09 January 2014 21:04 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 57EF21AE0F9 for <ietf@ietfa.amsl.com>; Thu, 9 Jan 2014 13:04:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.747
X-Spam-Level:
X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_52=0.6] 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 RT1TXUPQcyvZ for <ietf@ietfa.amsl.com>; Thu, 9 Jan 2014 13:04:03 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 51F2C1AE118 for <ietf@ietf.org>; Thu, 9 Jan 2014 13:04:03 -0800 (PST)
Received: from [10.20.30.90] (50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s09KhrP1050441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 13:43:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230] claimed to be [10.20.30.90]
Content-Type: multipart/signed; boundary="Apple-Mail=_C7F8BEFC-B5DD-4F36-A929-FEB74808625D"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: Multiple Namespaces Re: Split the IANA functions?
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <87AA61A3-DC75-44AA-9E87-93DC4210A404@virtualized.org>
Date: Thu, 09 Jan 2014 13:03:35 -0800
Message-Id: <5E189F2C-29A2-446D-A77E-A5185349AAD3@vpnc.org>
References: <94F13021-48B9-4CE9-995A-1081DC75A52D@isi.edu> <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> <2520.1389225982@perseus.noi.kre.to> <03224C28-8623-41FE-839F-A544D174DDB3@ogud.com> <52CEF4E9.1070505@gmail.com> <87AA61A3-DC75-44AA-9E87-93DC4210A404@virtualized.org>
To: David Conrad <drc@virtualized.org>
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: Thu, 09 Jan 2014 21:04:04 -0000

On Jan 9, 2014, at 11:40 AM, David Conrad <drc@virtualized.org> wrote:

> On Jan 9, 2014, at 11:13 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>> Working out a timeline to complete an effort to make all of this work is left as an exercise to the reader
>> 
>> Since it's an infinite regression (any N namespaces can be converted to a single
>> namespace by adding N unique suffixes or prefixes) I think the timescale
>> is infinite.
>> 
>> Seriously. We have a perfectly fine unambiguous namespace. Enough already.
> 
> The problem is that this issue keeps repeating, particularly in (shall we say) non-technical venues. In a private message I semi-seriously suggested someone should write an RFC that deprecates classes other than IN.  However, I'm beginning to think this might not be that bad of an idea -- at least there would be a document that the non-technical folks who keep raising the issue could be pointed at...

I would propose exactly the opposite document: "Want your own namespace? Here are most of the known the pros and cons of owning your own DNS CLASS." Talk about the know pitfalls, but don't assume that those pitfalls are fatal for a given scenario. Give out the new classes liberally for a few years. The result might be someone else really does find good uses for them, and takes pressure of CLASS=IN for some things that really shouldn't be in the global Internet.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email