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

[Michael Hammer <[e-mail]>]

Hadriel,

Right, and no one would ever need more than 4 billion IP addresses.
The first issue is possible run on addresses.
The second, is Never underestimate what a regulator might require an SP to
do in the future.
My thought is to design the convention in advance that is so reasonable it
pre-empts those black swans.

Mike

On Thu, Sep 29, 2011 at 2:51 PM, Hadriel Kaplan <[e-mail]>wrote:

>
>  Nothing stops anyone from asking for a SPID and claiming to be one.
> It's just useless to them in practice.  The iPhone app won't be able to
> force AT&T nor anyone else to treat them as a service provider, so AT&T will
> just overwrite whatever SPID value the iPhone app inserts in SIP signaling
> sent to AT&T, not use it for anything in AT&T databases, etc.
>
>  Obviously the iPhone app could use the number space for its own private
> uses, or could use them with others in some federation of its own, but I
> think even they would recognize a 32-bit number isn't big enough for such
> purposes, and registering every number through IANA is painful for something
> like that anyway.
>
>  The most likely "unexpected" thing to happen is something like
> freenum.org, which re-used the ITAD number space for their own ENUM
> service lookup.  They, or some service like them, could arguably switch to
> using SPIDs instead… but even then they've only used ~1500 ITAD numbers so
> far, and arguably they've kept to the basic concept of ITADs/SPIDs whereby
> each number represents a VoIP provider not a device.
>
>  -hadriel
>
>
>  On Sep 29, 2011, at 1:32 PM, Michael Hammer wrote:
>
>  Penn,
>  If economics and regulation conspire to make it valuable to do so, then
> what stops someone from writing an iPhone app that makes everyone a service
> provider?
>  I try to see what unintended consequences may result if not managed in
> advance.
>  Mike
>
> On Thu, Sep 29, 2011 at 12:14 PM, PFAUTZ, PENN L <[e-mail]> wrote:
>
>>  Mike:****
>>
>> E.164 number serving carriers is but one application but even there we are
>> not talking about limiting to carriers-of-record as defined in RFC5067. On
>> the other hand I don’t see SPID as the kind of thing every Internet
>> addressable entity would have (i.e., IPv6 addresses). I don’t even see the
>> number of SPIDs approaching the order of magnitude number of people on the
>> planet based on existing use cases.****
>>
>> ** **
>>
>> Penn Pfautz****
>>
>> AT&T Access Management****
>>
>> [phone]****
>>
>> *From:* Michael Hammer [mailto:[e-mail]]
>> *Sent:* Thursday, September 29, 2011 11:56 AM
>> *To:* PFAUTZ, PENN L
>> *Cc:* Dean Willis; [e-mail]
>>
>> *Subject:* Re: [RAI] Global Service Provider ID -
>> draft-pfautz-service-provider-identifier-urn-01****
>>
>>
>>    ** **
>>
>> 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 <[e-mail]> 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
>> [phone]
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Dean Willis
>> Sent: Wednesday, September 28, 2011 8:29 PM
>> To: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rai
>> _______________________________________________
>> RAI mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rai****
>>
>> ** **
>>
>
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai
>
>
>