Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

"Richard L. Barnes" <rbarnes@bbn.com> Wed, 28 September 2011 01:54 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA95521F8E58 for <rai@ietfa.amsl.com>; Tue, 27 Sep 2011 18:54:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.786
X-Spam-Level:
X-Spam-Status: No, score=-105.786 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_REPLICA=1.634, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuO9a5P+i0ku for <rai@ietfa.amsl.com>; Tue, 27 Sep 2011 18:54:18 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id AABA921F8E56 for <rai@ietf.org>; Tue, 27 Sep 2011 18:54:18 -0700 (PDT)
Received: from [128.89.253.171] (port=64332 helo=[192.168.1.4]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1R8jOT-0002nO-8C; Tue, 27 Sep 2011 21:57:05 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE220CE44FF@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Date: Tue, 27 Sep 2011 21:57:03 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D74629EC-D802-4A33-82AE-DA2A76EA5996@bbn.com>
References: <CD5674C3CD99574EBA7432465FC13C1B222B1F590A@DC-US1MBEX4.global.avaya.com> <CAA62EE0.3B275%jason_livingood@cable.comcast.com> <38726EDA2109264987B45E29E758C4D6022C0F@MISOUT7MSGUSR9N.ITServices.sbc.com> <00ab01cc7d31$2cfa1c40$86ee54c0$@us> <4E820778.1070807@softarmor.com> <EDC0A1AE77C57744B664A310A0B23AE220CE44FF@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1084)
Cc: "rai@ietf.org" <rai@ietf.org>
Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Sep 2011 01:54:19 -0000

If you've got someone to delegate it to, it's not unheard of for URN namespaces to get delegated to other organizations.
<http://tools.ietf.org/html/rfc5165>

Depending on who it gets assigned to, though, that may change its utility for a general Internet protocol.

--Richard


On Sep 27, 2011, at 7:39 PM, DRAGE, Keith (Keith) wrote:

> Just to note that issuing 1,000,000 registrations in one year would require IANA to handle something like 10 registrations a minute for every working hour of every working day of the year. 
> 
> That would mean increasing the current staff at least 10 fold, just to handle this load, and require a substantially different financing and operating model.
> 
> If you think we are ever going to get anything like these numbers, then the IANA registration route is not the way to go. You need a space where you can devolve the allocation to subsidiary parties and so on.
> 
> Regards
> 
> Keith
> 
>> -----Original Message-----
>> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Dean
>> Willis
>> Sent: 27 September 2011 18:27
>> To: rai@ietf.org
>> Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-
>> provider-identifier-urn-01
>> 
>> On 9/27/11 11:19 AM, Richard Shockey wrote:
>>> +1
>>> 
>>> Of all the things to worry about here I doubt this is one of them.
>>> 
>>> Personally I think folks and enterprises small or large prefer buy
>> services
>>> from service providers even if the service provider is internal to the
>>> enterprise or cloud. Life is too short.
>> 
>> Having once been in the business of setting up internet connections for
>> small technology companies all the way up to big retail/industrial
>> firms, I can say that most of them really WANTED to own their IP address
>> space so that they could, if they wanted to, dual-home it via two
>> connections and advertise the routes via BGP routing adverts. I
>> therefore suspect that more of them want to have SPIDs than you might
>> expect.
>> 
>> So while I think that SPID is a Very Important Thing and I'm strongly
>> sympathetic to the "just reuse ITAD" argument (and no, the reference to
>> "telephone" in ITAD doesn't bother me; all of telephony and all of the
>> Internet are semantically merging anyhow), it does seem that we might
>> want to think about address space concerns.
>> 
>> We're at about ten billion entities today -- some "natural persons",
>> others "legal persons" like corporations, co-ops, government branches,
>> independent business units of a larger entity, ships, factories,
>> warehouses, office buildings, and so on.
>> 
>> With any luck, the population will merely double over the next
>> generation. It could be worse. Also with any luck, we're going to need
>> comms identifiers for interplanetary and perhaps extrasolar resources.
>> Not to mention the "internet of things". How many SPIDs does a swarm of
>> von Neumann probes
>> (http://en.wikipedia.org/wiki/Self-replicating_machine) require so that
>> all of those little ETs can phone home? Just one, or are they going to
>> subdomain by stellar cluster?
>> 
>> While I don't expect every entity to require a SPID, there's an argument
>> to be made that the number needed might well exceed 32-bits worth at
>> some point in time.
>> 
>> Consider also the model of "permanent allocation". We don't currently
>> reclaim ITAD numbers from failed entities or those who no longer need
>> them. Given churn and time, that will eventually eat up a lot of
>> numbers. If we only issue a million a year, we burn through
>> 4,294,967,296 in a mere 4,294 years. But if we're issuing a hundred
>> million a year, we've only got a 42 year window.
>> 
>> Of course, one could do "reclamation" within a number space. For
>> example, the PEN registered to KRAP might, on Hadriel's expiry, be sold
>> with his effects. This artificial scarcity potentially creates a
>> lucrative market. Consider that New York City taxicab medallions have
>> historically been a safer investment than gold; supposedly they have
>> never declined in value, and currently sell for somewhere north of
>> $600,000 each. I believe that New Mexico state liquor licenses have
>> similar properties. If we have a 10% annual reclamation cycle, we can
>> issue 4.2 million "recycled" numbers a year in perpetuity.
>> 
>> But if it isn't our intention to assure a perpetual funding model for
>> IANA based on artificial scarcity of numeric resources occurring a few
>> hundred years from now, perhaps we'd benefit from a larger address space.
>> 
>> On the other hand, perhaps we're being wildly optimistic about the
>> importance of the SPID and the future demand for them.
>> 
>> One might also note that 32 bits is a nice fixed-length number in binary
>> (32 digits), quaternary (16 digits), or hexadecimal (8 digits). Why are
>> we restricting ourselves to 10 decimal digits, which doesn't map to
>> anything binary in a very nice way?
>> 
>> --
>> Dean
>> _______________________________________________
>> RAI mailing list
>> RAI@ietf.org
>> https://www.ietf.org/mailman/listinfo/rai
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www.ietf.org/mailman/listinfo/rai