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

-----Original Message-----
From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Paul
Kyzivat
Sent: Tuesday, October 04, 2011 9:29 PM
To: rai@ietf.org
Subject: Re: [RAI] [drinks] FW: Global Service Provider ID -
draft-pfautz-service-provider-identifier-urn-01

Richard,

Thank you for finally providing a tangible requirement for a *new* 
registry, functionally distinguished from the ITAD registry. It makes it 
much easier to support you.

How about building the basic data support for the WHOIS mechanism into 
the proposal, along with a revocation process, a suitable barrier to 
entry (e.g. fee)?

[RS> ] I think that would be the next logical step. The marginal barrier to
entry makes sense to me as well. The key will be who can actually collect
the fee.  There may be issues with IANA charging directly. We'll need to
check that out off line. Certainly no one has issues with the way the RIR's
deal with it.  That may be the model to look at.

	Thanks,
	Paul

On 10/4/11 5:43 PM, Richard Shockey wrote:
>> -----Original Message-----
>> From: Dean Willis [mailto:dean.willis@softarmor.com]
>> Sent: Tuesday, October 04, 2011 3:38 PM
>> To: Richard Shockey
>> Cc: 'Hadriel Kaplan'; rai@ietf.org
>> 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:
>>
>>> DNS? I don't get that at all ..except as a ENUM record in a private
> closed
>>> RFC 6116 instantiation.  :-)
>> DNS provides certain things that we might arguably want from a SPID, and
>> the use cases are actually pretty consistent with the DNS usage
> guidelines.
>>
>>
>> Those things are:
>>
>> 1) A registry of information that is long-lived but does occasionally
>> change, where that information is "universally scoped", i.e. applicable
>> Internet-wide.
>>
>> RS>   Yep .. +1
>>
>>
>> 2) A mechanism to query that registry.
>>
>> RS>   Dependant on the size of the registry. No reason you can't
> periodically poll
>> for a flat file. Works for the root!
>>
>>
>> 3) Dynamic propagation of changes to that registry.
>>
>>   RS>    Maybe .. See A.
>>
>>
>> 4) A mechanism by which multiple registrars can populate the registry.
>>
>>
>> Why that level of complexity?  The formal assumption here is self
>> validation. This is useless level of administrative burden. Low cost
>> implementation was the key implementation assumption here.
>>
>> RS>   For instance classic telephony routing registries are WAY WAY WAY
too
>> expensive.
>
>> 6) Whois-like tracking of entities on behalf of whom registrations are
> made.
>>
>>    RS>  +1  I'm pretty much there on this.
>
> I've given this considerable thought and I convinced that some form of
WHOIS
> like mechanism is necessary here for this class of registry that is not
> available in ITAD registrations.   As I pointed out earlier the
> functionality of this in Real-time Communications networks would be
roughly
> equivalent to Administrative Domains or the use of AS numbers in
traditional
> routing. Having administrative and technical contact names associated with
> G-SPID seems essential.  There is another reason.  SPID's in North
American
> numbering databases were developed in part to satisfy the requirements of
> Law Enforcement Administrations that needed a quick method of finding out
> who the "carrier of record" was for a particular TN so they could discover
a
> administrative contact necessary to process lawful intercept orders.  Now
> the proposed registry would not be involved in such orders but if national
> administrations choose to implement G-SPID in their databases then I
suspect
> such WHOIS data would be very useful indeed.
>
>
>
> _______________________________________________
> 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