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

["Richard Shockey" <[e-mail]>]

Cc: 'Hadriel Kaplan'; [e-mail]
Subject: Re: [RAI] [drinks] FW: Global Service Provider ID -
draft-pfautz-service-provider-identifier-urn-01

On 10/4/11 1:34 PM, Richard Shockey wrote:
> Reclamation is hard ..been there done that with phone numbers.
>
> I haven't seen any use case other than a casual suggestion from Hadriel
that
> one may be necessary.
>
> Contact data ..maybe but in any event I don't see the immediate need for a
> cost recovery mechanism.

Okay, if you don't NEED reclamation, and you don't NEED a contact 
mechanism, and you don't NEED a cost-recovery mechanism to pay for the 
administration, then you don't appear to NEED anything other than an ITAD.

My view is the size of this thing beyond the fixed 8 10 digit boundary will
never need reclamation. You think it does but you have not provided any
evidence that it will size that large, given that ITAD's are minimal.

IMHO it will probably need a WHOIS or contact data at some point there are
aspects of this similar to the concept of administrative domains that could
use such data. The scope of that could be intelligently discussed.


You might WANT something that walks like an ITAD, talks like an ITAD, 
and quacks like an ITAD, but that "just isn't an ITAD". As many people 
have pointed out, that's not a strong justification for doing anything 
other than ITAD, because we already have ITAD.



So, why should the IETF satisfy that which you WANT but do not NEED, 
when we've already satisfied that which you NEED? We like you, Rich, but 
we're really lazy. We REQUIRE a stronger reason.

<whine>  Yea I know.  

If, on the other hand, there were some sort of operational requirement 
or behavior that makes SPID different from ITAD, or that makes the 
administration of SPID different from the administration of ITAD, then 
we might have a justification for doing it.

--
Dean