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

Hadriel Kaplan <HKaplan@acmepacket.com> Thu, 29 September 2011 16:30 UTC

Return-Path: <HKaplan@acmepacket.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 AA16921F8E50 for <rai@ietfa.amsl.com>; Thu, 29 Sep 2011 09:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.062
X-Spam-Level:
X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, SARE_MILLIONSOF=0.315]
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 Tuw01wh02J6M for <rai@ietfa.amsl.com>; Thu, 29 Sep 2011 09:30:23 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id DDF9621F8E75 for <rai@ietf.org>; Thu, 29 Sep 2011 09:30:22 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep 2011 12:33:13 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 29 Sep 2011 12:33:13 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Michael Hammer <mphmmr@gmail.com>
Thread-Topic: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01
Thread-Index: AQHMfsV7YmwSwqbWIkioN/Wn5PR5ew==
Date: Thu, 29 Sep 2011 16:33:12 +0000
Message-ID: <5B6EA6F1-11F4-4CD2-9F71-A63D415F0CB9@acmepacket.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> <009501cc7e1d$124b0700$36e11500$@us> <4E83BBD9.2070600@softarmor.com> <38726EDA2109264987B45E29E758C4D6023489@MISOUT7MSGUSR9N.ITServices.sbc.com> <CAA3wLqUT8pDABY6gX_WUj1w9ixN-afEzs50Wv8W6WqR9ePF9xA@mail.gmail.com>
In-Reply-To: <CAA3wLqUT8pDABY6gX_WUj1w9ixN-afEzs50Wv8W6WqR9ePF9xA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <A7868119E6216C40AE980653A1338653@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "rai@ietf.org" <rai@ietf.org>, Dean Willis <dean.willis@softarmor.com>
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: Thu, 29 Sep 2011 16:30:23 -0000

This isn't a device identifier, nor a user identifier.  It's not going to be on the scale of IP addresses, MAC Addresses, nor even E.164 numbers.  

This is really like Enterprise Numbers in terms of scope/scale/concept.  Anyone can get an Enterprise Number for free on a FCFS basis from IANA, and a bunch of whacko's like me who don't need them still get them, but even after ~20 years there're still only ~39k numbers allocated.

-hadriel


On Sep 29, 2011, at 11:55 AM, Michael Hammer wrote:

> Penn,
>  
> If the basis of the distrution is owners of E.164 numbers, then that implicitly limits the number of SPs possible (and thus SPIDs needed), since other arrangements limit who may be delegated those numbers.
>  
> If there is no basis and anyone may apply, then the distribution tail could extend to the limits of how many entities are addressable on the Internet, aka the number of IPv6 addresses.
>  
> The question is whether there Should be some threshhold over which the owner of some addresses would be deemed too small to be a "service provider"?  (Cut the tail off at some point.)
>  
> The derivative of that will also determine the likely number of registrations per year and the load on IANA.
>  
> Mike Hammer
> 
>  
> On Thu, Sep 29, 2011 at 9:08 AM, PFAUTZ, PENN L <pp3129@att.com> wrote:
> Dean:
> I see the case as being..." more of a long-tailed distribution where a few SPIDs have
> tens-of-millions of entities and it tapers off to the right" if by entities we mean E.164 numbers or some other form of identifiers.
> 
> That is certainly how it would be the for use cases that the drinks WG, the GSMA, and the i3 Forum are looking at.
> 
> Penn Pfautz
> AT&T Access Management
> +1-732-420-4962
> -----Original Message-----
> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Dean Willis
> Sent: Wednesday, September 28, 2011 8:29 PM
> To: rai@ietf.org
> Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01
> 
> On 9/28/11 3:27 PM, Richard Shockey wrote:
> > 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.
> 
> Nothing says they can't charge for a registration. So Adam's right; if
> business booms, they'll find a way to make an industry out of it. Not
> our worry. (But I do want to see the face of somebody at IANA when we
> tell them we're planning for 1,000,000 registrations a year).
> 
> However, making sure they don't run out of inventory probably IS our
> problem.
> 
> 
> While I agree that 32 bits is PROBABLY enough for the forseeable future,
> if we're going to do something besides ITAD then we might as well go to
> 64. But if we're happy with ITAD structurally, there may not be enough
> justification to do more.
> 
> At 100 entities per SPID, 32 bits gives us some 430 million entities.
> That's rather short of the 20 billion entities we might see in the very
> near term. Even at 1000 entities per SPID, we're still a factor of 5
> short in the near term.
> 
> So what sort of entities-per-SPID ratio are we willing to assume?
> Remember that some entities may have more than one number (I have, at
> last count, 23, including the four companies I currently control).
> 
> Is it more of a long-tailed distribution where a few SPIDs have
> tens-of-millions of entities and it tapers off to the right?
> 
> --
> 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