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

[Michael Hammer <[e-mail]>]

Actually supposed to be network endpoint identifiers aka hosts, but not for
every terrminal device attached to a (what used to be IBM or Unix) host.
Now it is every end-user terminal device, and soon with smart grid and IoT
just about anything that can have an antenna, protocol stack, and uses
electricity.  I'll bet the Internet fore-fathers never saw that coming.

My point is not to just consider what your intent is right now, but what is
possible in the future.  As Dean noted, every business could potentially be
an SP.

I agree with your arguments that hierarchy enables scalability.  I am just
suggesting that whatever scheme is chosen, that the ability to aggregate
into a hierarchy is not lost.  That way the global SPs can continue to
operate by inspection of only the "higher order bits/bytes" of the hierarchy
or some other means of not having to search a long-tail, avoid routing
delays, and avoid management nightmares.

Mike

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

>
>  Except IP addresses were meant to be device identifiers; SPIDs are not.
>  An IANA registry isn't a good means of providing device identifiers to
> begin with, because registering each and every one of them through a central
> registry doesn't scale, for neither the registry nor the device.
>
>  Imagine if you had to register every hostname to the DNS registries, as
> opposed to just domain level; even if it were free to do so, the operational
> burden would have driven people to find an alternative mechanism.  And even
> if we think this thing could someday become akin to domain names, there are
> only a few hundred million of them.
>
>  -hadriel
>
>  On Sep 29, 2011, at 5:32 PM, Michael Hammer wrote:
>
>  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
>>
>>
>>
>
>