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

From: Cullen Jennings <[email-masked]>
Date: Thu, 24 Nov 2011 06:30:05 -0700

Just to point out the obvious on this ... if what comes back is you need a verified address attached to the identifier, you will probably get told to go use a CA or something else instead of IANA - IANA is not exactly in the business of verifying address.

And on a note in the other direction - if what they want is exactly like ITAD in every way but they want a new IANA registry called NEW_ITAD, does it really matter if there are two registries? I'm having a hard time figuring out why I would care if there was one or two registries of FCFS numbers ...

On Oct 31, 2011, at 12:34 PM, Richard Shockey wrote:

> FYI .. we are still working this. 
> 
> Its taking a bit more coordination among the affected parties etc. 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Kyzivat
> Sent: Tuesday, October 04, 2011 9:29 PM
> To: [email-masked]
> 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:[email-masked]]
>>> Sent: Tuesday, October 04, 2011 3:38 PM
>>> To: Richard Shockey
>>> Cc: 'Hadriel Kaplan'; [email-masked]
>>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rai
>> 
> 
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai
> 
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai
> 
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 24 Nov 2011 12:27:28 -0500

But RIR's are in the business of verifying addresses and that is the
probable path this will take. You also now have the WHOIS like requirements
etc that argue that you need a clean namespace.

There has been a fair amount of coordination among possible affected
parties. There should be a new draft forth coming.

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Thursday, November 24, 2011 8:30 AM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [RAI] [drinks] FW: Global Service Provider ID

Just to point out the obvious on this ... if what comes back is you need a
verified address attached to the identifier, you will probably get told to
go use a CA or something else instead of IANA - IANA is not exactly in the
business of verifying address.

And on a note in the other direction - if what they want is exactly like
ITAD in every way but they want a new IANA registry called NEW_ITAD, does it
really matter if there are two registries? I'm having a hard time figuring
out why I would care if there was one or two registries of FCFS numbers ...