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

"Richard Shockey" <richard@shockey.us> Wed, 28 September 2011 20:24 UTC

Return-Path: <richard@shockey.us>
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 6A4471F0D03 for <rai@ietfa.amsl.com>; Wed, 28 Sep 2011 13:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.588
X-Spam-Level:
X-Spam-Status: No, score=-98.588 tagged_above=-999 required=5 tests=[AWL=-1.216, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 AF022-Q18enh for <rai@ietfa.amsl.com>; Wed, 28 Sep 2011 13:24:55 -0700 (PDT)
Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 6BD711F0D02 for <rai@ietf.org>; Wed, 28 Sep 2011 13:24:55 -0700 (PDT)
Received: (qmail 23255 invoked by uid 0); 28 Sep 2011 20:27:42 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 28 Sep 2011 20:27:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=EIH503Wo9F76gWhZ7wbpBWMvLoamPbvBeZu4gvVi6fM=; b=F/6UoFpLaXKdxZ85hMFYpjnz3fan8MKvP537VjRUqBNaYxClZisYFnk4Dzd22zwZCCjngL/1MAda7AurebahU1v2/Fpoi6y6352coMysU5DcJfYAUrYwKR30ImXb/cr/;
Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from <richard@shockey.us>) id 1R90jG-0000wP-8u; Wed, 28 Sep 2011 14:27:42 -0600
From: Richard Shockey <richard@shockey.us>
To: 'Adam Roach' <adam@nostrum.com>, "'Richard L. Barnes'" <rbarnes@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> <D74629EC-D802-4A33-82AE-DA2A76EA5996@bbn.com> <4E82832E.3090600@nostrum.com>
In-Reply-To: <4E82832E.3090600@nostrum.com>
Date: Wed, 28 Sep 2011 16:27:39 -0400
Message-ID: <009501cc7e1d$124b0700$36e11500$@us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
thread-index: Acx9hH1nzAx7g2e8TleJ8cXEfzR7MwAmFXmg
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us}
Cc: 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 20:24:56 -0000

Yea .. 4.3 million "possible" registrations and what is in the registry 1482
registrations.

Plus ICANN certainly has the money ..too much money if you ask me. 

-----Original Message-----
From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Adam
Roach
Sent: Tuesday, September 27, 2011 10:15 PM
To: Richard L. Barnes
Cc: rai@ietf.org
Subject: Re: [RAI] Global Service Provider ID -
draft-pfautz-service-provider-identifier-urn-01

We have dealt with unexpected success in the past, and I'm sure we can 
deal with it in the future. Jon Postel used to hand out IP address all 
by himself. Allocation progressed through IANA to ICANN, into a complex 
delegated system involving regional registries and an insane number of 
registrars under those registries.

I really don't think this is the greatest part of our concern. Figuring 
out whether 4.3 million or 10 million or 18.6 quintillion or 100 
quintillion is the correct maximum number of entries is probably relevant.

Personally, I don't think there's any good reason to second-guess the 
analysis that TRIP made on this point (they concluded 4.3 million), but 
I'd love to hear arguments to the contrary.

/a

On 9/27/11 20:57, Sep 27, Richard L. Barnes wrote:
> 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
> _______________________________________________
> 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