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

From: <[email-masked]>
Date: Mon, 3 Oct 2011 15:31:55 +0200

Dear Richard,

I must admit that I didn't found in your answer no valid technical argument why ITADs can not be used.

Perhaps there are some subtleties I missed.

Cheers,
Med

________________________________
De : Richard Shockey [mailto:[email-masked]]
Envoyé : mardi 27 septembre 2011 18:11
À : BOUCADAIR Mohamed OLNC/NAD/TIP; 'PFAUTZ, PENN L'; 'Sumanth Channabasappa'; [email-masked]
Objet : RE: [RAI] [drinks] FW: Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

Because SIP takes care of the rest.

This is about service providers BTW which could be a enterprise and yes one of the use cases involves service providers that use E.164 identifiers.

The proven use case is here in North America. The numbering databases contain service provider and ALT- service provider identification codes that indicate the "carrier of record" or VNO for a particular number.

Routing transactions can occur if the SPID can be indentified at session origination. Once the termination provider of the session can be indentified ( yes a carrier but it could be a enterprise etc)  the First hop proxy ( CSCF ) can make a trunk group decision based on some predetermined policy at session origination.

Remember this?

http://tools.ietf.org/html/draft-malas-enum-trunk-sip-01

The result of this is  <cough cough>  bypass of traditional POTS / SS7 / Class 5 garbage routing mechanisms and the maintance and integrity  of SIP session IP end to end if possible, including advanced service delivery such as HD voice etc.

A Global form of this simple unique identifier does not exist and the IETF is a good place to create a home for it.  Yes there will be some junk here but its better to start fresh with a fixed length identifier.

The "other alternatives" were a non starter.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, September 26, 2011 10:33 AM
To: PFAUTZ, PENN L; Sumanth Channabasappa; [email-masked]
Subject: Re: [RAI] [drinks] FW: Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

Re-,

Thank you for the clarification.

But then what is the value of having a universal service identifier scheme which is agnostic to the service context?

If service identifiers are to be used in signalling protocols or used to invoke services, then the service identifier should be bound to a given service. FWIW, we have studied in the past the information template to be filled in interconnection agreements (horizontal, Network Interconnection Agreements or Service Interconnection Agreements) or in provisioning agreements (vertical; Connectivity Provisioning Agreements or Service Provisioning Agreements) but we didn't found at that time the need for a universal identifier to be used in both vertical and horizontal agreements/invocation protocols/etc (see http://www.ist-agave.org/results/D1.1-final-public.pdf).

Cheers,
Med

________________________________
De : PFAUTZ, PENN L [mailto:[email-masked]]
Envoyé : lundi 26 septembre 2011 15:56
À : Sumanth Channabasappa; BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Objet : RE: [drinks] FW: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01
Dear Med,
The exception is that ITADs are not fixed length (see http://www.iana.org/assignments/trip-parameters/trip-parameters.xml) though I agree they could be made so via a urn definition that formats the ITAD integer. Given the 4B space fixed length would be 9 digits. The policy w/r/t multiple assignments for an entity   is not explicitly stated as far as I can tell.

Another issue that has been raised is whether, as applications may go beyond telephony, we should be comfortable using something labeled as telephony.

Regards,

Penn Pfautz
AT&T Access Management
+1-732-420-4962
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sumanth Channabasappa
Sent: Monday, September 26, 2011 9:39 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [drinks] FW: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

Folks,

The fwd was meant as an FYI, please provide comments on the RAI reflector where this discussion is happening.

Sumanth -- as co-chair

On Sep 26, 2011, at 7:36 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:
Dear Penn,

Apologies if this is already raised but  having a quick review of your draft, it seems to me all the requirements you listed are met by the ITAD number for VoIP service providers:

   o  They SHOULD be globally unique

   o  They SHOULD be numeric, at least 8 digits long

   o  They SHOULD be fixed length

   o  they SHOULD be available to any type of entity

   o  Entities SHOULD be able to obtain mulitple identifiers.

   o  Some range of identifiers SHOULD be reserved for internal entity

      usage.
Did I missed something?

Thanks.

Cheers,
Med

________________________________
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de PFAUTZ, PENN L
Envoyé : vendredi 23 septembre 2011 21:00
À : Sumanth Channabasappa; [email-masked]<mailto:[email-masked]>
Objet : Re: [drinks] FW: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01
Thanks Sumanth.  And if folks think this SPID would be a useful thing to have, please weigh in accordingly.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Sumanth Channabasappa
Sent: Friday, September 23, 2011 2:58 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [drinks] FW: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

I am forwarding this as an FYI. If you are interested in this discussion, please check the rai discussion list. See: https://www.ietf.org/mailman/listinfo/rai for archives and subscription.

- S

From: [email-masked]<mailto:[email-masked]> On Behalf Of PFAUTZ, PENN L
To: [email-masked]<mailto:[email-masked]>
Subject: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

Following up on the discussion in dispatch at IETF 81 (www.ietf.org/proceedings/81/minutes/dispatch.txt<http://www.ietf.org/proceedings/81/minutes/dispatch.txt>) I'd like to get some discussion of   draft-pfautz-service-provider-identifier-urn-01 going.
The draft proposed IANA registration of a service provider ID (SPID) which would have the following characteristics:
-      Numeric ID, at least 8 digits long
-      Fixed length
-      Available to any type of entity
-      Entities able to obtain multiple identifiers.
-       Some range of identifiers reserved for internal usage
-      Open registration by IANA

The minutes concluded:

-      WG is in support of creating a URN for this.
-      Document(s) likely to be AD sponsored.
-      Discussion should move to RAI area list (as opposed to DRINKS or DISPATCH).

The outstanding issues seemed to be
1. Is a new resource assignment necessary for the URN or could an existing one, Private Enterprise Numbers or ITADs be used with a URN defined to provide a fixed length parameter as requested in the I-D?

2. Assuming a fixed length parameter will be used, what's the right length?

The I-D proposed a new resource, partly because the existing ones were intended for other purposes and already had many registrations. I'd also note that PENs suggest a sub-delegation approach to assigning multiple SPIDs to an entity (an entity gets one PEN assignment and can assign values hierarchically below that (e.g. AT&T has PEN 74, and would assign 74.1, 74.2, etc). Because at least some of the service providers wanted to use SPID to prefix E.164 numbers and others want to incorporate SPID in a domain name, this would present issues.

Penn Pfautz
AT&T Access Management
+1-732-420-4962

---

From: Dean Willis <[email-masked]>
Date: Mon, 03 Oct 2011 15:13:06 -0500

> Perhaps there are some subtleties I missed.

Richard makes no technical arguments here. Rather, his arguments are 
political; some of the people driving the need for SPID do not think 
their problem space is them same as ITAD and want a separate number 
space. As there is little cost in adding a distinct registry, it might 
be reasonable to honor their desires by making one.

WHY they want a separate number space is unclear to me, and should, I 
think, be examined.

One answer is that they see ITAD as being "internet telephony" specific, 
and have a broader service definition in mind.

An alternate is that they see ITAD as being "too Internet", and that it 
shouldn't be mingled with their lofty carrier status. They may fear that 
having a pool of existing ITADs will increase the pressure on them to 
peer at the egalitarian ITAD level, which might impact their business 
models. Perhaps, then, they really want a "private club" identifier. Why 
then would they require action from the IETF, unless they want free 
administrative support for their private club? It seems like that line 
of argument makes little sense; they could easily have their own ITU 
"private club" without having to twiddle with the IETF.

Perhaps we're really talking about is an identifier that has the 
potential to be used in egalitarian peering, but the fact that "It's not 
an ITAD" makes it easier to sell to carriers (because it doesn't come 
with the expectations of an ITAD and an existing pool of users), so the 
operators can hope to use it to protect or extend their private-club 
model at the same time as activist thinkers are expecting that the SPID 
will eventually have the same sort of egalitarian pressure on it as ITAD.

In other words, using a new SPID registry instead of an existing ITAD 
registry might be just a sleight-of-hand mechanism to get it adopted, 
and I'm probably OKAY with that. The actual operation role of such an 
identifier will continue to evolve once it gets deployed.

This leads me to suggest an alternative acronym: the "Generic Operation 
Numerical Administrative Domain", or GONAD. Think of it as a generative 
organ for future internet services that need numerically scoped 
identifiers. Besides, I've often thought that gonads should be 
registered; they cause a lot more damage than personal firearms.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 4 Oct 2011 14:49:22 +0000

I don't think they want a "private-club" identifier.  For example I'd expect they'd be perfectly happy with Facebook, Harvard, and Jabber.org getting SPIDs.  This is really something we should all want.

When I think of what one would do with these SPIDs, though, they feel a lot like BGP AS numbers to me.  I would want to have the list of SPIDs be kept up-to-date, with dead numbers reclaimed, with recent contact information, and without random people like me just getting one on a whim. [note: these are my desires, I have no idea if the people asking for SPIDs agree]

So it's not so much a "private-club" as a club with a cover charge, to make sure people entering it are serious.  

-hadriel

On Oct 3, 2011, at 4:13 PM, Dean Willis wrote:

> Richard makes no technical arguments here. Rather, his arguments are political; some of the people driving the need for SPID do not think their problem space is them same as ITAD and want a separate number space. As there is little cost in adding a distinct registry, it might be reasonable to honor their desires by making one.
> 
> WHY they want a separate number space is unclear to me, and should, I think, be examined.
> 
> One answer is that they see ITAD as being "internet telephony" specific, and have a broader service definition in mind.
> 
> An alternate is that they see ITAD as being "too Internet", and that it shouldn't be mingled with their lofty carrier status. They may fear that having a pool of existing ITADs will increase the pressure on them to peer at the egalitarian ITAD level, which might impact their business models. Perhaps, then, they really want a "private club" identifier. Why then would they require action from the IETF, unless they want free administrative support for their private club? It seems like that line of argument makes little sense; they could easily have their own ITU "private club" without having to twiddle with the IETF.
> 
> Perhaps we're really talking about is an identifier that has the potential to be used in egalitarian peering, but the fact that "It's not an ITAD" makes it easier to sell to carriers (because it doesn't come with the expectations of an ITAD and an existing pool of users), so the operators can hope to use it to protect or extend their private-club model at the same time as activist thinkers are expecting that the SPID will eventually have the same sort of egalitarian pressure on it as ITAD.
> 
> In other words, using a new SPID registry instead of an existing ITAD registry might be just a sleight-of-hand mechanism to get it adopted, and I'm probably OKAY with that. The actual operation role of such an identifier will continue to evolve once it gets deployed.
> 
> This leads me to suggest an alternative acronym: the "Generic Operation Numerical Administrative Domain", or GONAD. Think of it as a generative organ for future internet services that need numerically scoped identifiers. Besides, I've often thought that gonads should be registered; they cause a lot more damage than personal firearms.
> 
> --
> Dean
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 4 Oct 2011 11:15:59 -0400

> From: Dean Willis [[email-masked]]
> 
> [...] but the fact that "It's not an ITAD" makes it easier to sell
> to carriers (because it doesn't come with the expectations of an
> ITAD and an existing pool of users), [...]

I think this shouldn't be underestimated.  My experience is that
people in the telco world (even very smart people) are much slower to
change things than people in the Internet world, both due to their
organizational history (many companies have been in business since the
nineteenth century) and their operational realities (having your
network failures reported on the front page of all the newspapers in
the nation tends to make one cautious).

It's quite possible that even if the service providers intend to open
the system to all competitors, they still feel a visceral resistance
to an identifier that was not originally purposed for identifying
service providers like themselves.

> This leads me to suggest an alternative acronym: the "Generic
> Operation Numerical Administrative Domain", or GONAD. Think of it as
> a generative organ for future internet services that need
> numerically scoped identifiers. Besides, I've often thought that
> gonads should be registered; they cause a lot more damage than
> personal firearms.

And what if one cannot get a "concealed carry" permit for one's
GONADs?

Dale

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Oct 2011 11:56:29 -0400

Ask the electric utilities. It's much worse for them. PSTN network failures
must by US law and several others reported. Yes they teleco's are
conservative but positively liberal compared to the electric utilities. 

In part yes, you are correct but no in the general proposition. The desire
to use a IANA registry was precisely to avoid a formal ITU like definition
of what is and what is not a service provider. In fact the desire for an
IANA registry was to avoid the very strong objections to using a ITU
registry. 

Myself and none of the i3Forum global wholesale carriers have suggested a
closed system here. How the identifier is used, of course, is a private
business matter between carriers or how this identifier may show up in
national numbering databases.  

Remember this is a IANA registry and no one has suggested or proposed a
restriction on what entities can use the identifier. It is presumed that the
registry has a purpose defined in a RFC and compliance to that purpose would
be voluntary as it is with ITAD's etc.

Again its not a big deal to create another registry ..so why not try. Why
this insistence on ITADs? 

Dale

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Oct 2011 12:04:58 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Tuesday, October 04, 2011 10:49 AM
To: Dean Willis
Cc: <[email-masked]>
Subject: Re: [RAI] [drinks] FW: Global Service Provider ID -
draft-pfautz-service-provider-identifier-urn-01

I don't think they want a "private-club" identifier.  For example I'd expect
they'd be perfectly happy with Facebook, Harvard, and Jabber.org getting
SPIDs.  This is really something we should all want.

Yes .. exactly. Harvard, T A&M or IBM are exactly the kind of "service
providers" that would be logically included in this registry. 

When I think of what one would do with these SPIDs, though, they feel a lot
like BGP AS numbers to me.  I would want to have the list of SPIDs be kept
up-to-date, with dead numbers reclaimed, with recent contact information,
and without random people like me just getting one on a whim. [note: these
are my desires, I have no idea if the people asking for SPIDs agree]

Excellent analogy. In practical application its function is very much like a
AS. As for a WHOIS here for the SPID's .. I've frankly thought that someone
is going to want one eventually, just like we have for domain names and the
AS numbers.  You want some contact data for resolving network problems.  I
don't think the idea has progressed that far. I think most of us hoped we
could agree to the structure of the identifier first then look at the more
practical details. But Hadriel your point is well taken. Its actually
another reason to start clean. If folks think a SIPD WHOIS is necessary then
its really better to start clean. 

So it's not so much a "private-club" as a club with a cover charge, to make
sure people entering it are serious.  

-hadriel

> Richard makes no technical arguments here. Rather, his arguments are
political; some of the people driving the need for SPID do not think their
problem space is them same as ITAD and want a separate number space. As
there is little cost in adding a distinct registry, it might be reasonable
to honor their desires by making one.
think, be examined.
shouldn't be mingled with their lofty carrier status. They may fear that
having a pool of existing ITADs will increase the pressure on them to peer
at the egalitarian ITAD level, which might impact their business models.
Perhaps, then, they really want a "private club" identifier. Why then would
they require action from the IETF, unless they want free administrative
support for their private club? It seems like that line of argument makes
little sense; they could easily have their own ITU "private club" without
having to twiddle with the IETF.
> 
> Perhaps we're really talking about is an identifier that has the potential
to be used in egalitarian peering, but the fact that "It's not an ITAD"
makes it easier to sell to carriers (because it doesn't come with the
expectations of an ITAD and an existing pool of users), so the operators can
hope to use it to protect or extend their private-club model at the same
time as activist thinkers are expecting that the SPID will eventually have
the same sort of egalitarian pressure on it as ITAD.
> In other words, using a new SPID registry instead of an existing ITAD
registry might be just a sleight-of-hand mechanism to get it adopted, and
I'm probably OKAY with that. The actual operation role of such an identifier
will continue to evolve once it gets deployed.
Numerical Administrative Domain", or GONAD. Think of it as a generative
organ for future internet services that need numerically scoped identifiers.
Besides, I've often thought that gonads should be registered; they cause a
lot more damage than personal firearms.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 4 Oct 2011 18:08:19 +0200

A couple of people have mentioned reclamation, almost in passing, without further detail of what and why and how.

At least people I have talked to in terms of other identifiers have said reclamation is hard, and involves a lot of work, and that is for an identifier with a smaller set of potential customers, although with a larger number of allocated values. How many of the contact details in the ITAD registry are still valid, and how many of those registered entities have now changed name to something else.

As far as I am aware, reclamation is also something that IANA have not been tasked to do in the past.

If you want reclamation, then you will need to describe how this is done, and the criteria for reclaiming, in any RFC setting up the registry.

Keith

> -----Original Message-----
> Sent: 04 October 2011 15:49
> To: Dean Willis
> Cc: <[email-masked]>
> I don't think they want a "private-club" identifier.  For example I'd
> expect they'd be perfectly happy with Facebook, Harvard, and Jabber.org
> getting SPIDs.  This is really something we should all want.
> 
> When I think of what one would do with these SPIDs, though, they feel a
> lot like BGP AS numbers to me.  I would want to have the list of SPIDs be
> kept up-to-date, with dead numbers reclaimed, with recent contact
> information, and without random people like me just getting one on a whim.
> [note: these are my desires, I have no idea if the people asking for SPIDs
> agree]
> 
> So it's not so much a "private-club" as a club with a cover charge, to
> make sure people entering it are serious.
> 
> -hadriel
> 
> 
> Perhaps, then, they really want a "private club" identifier. Why then
> would they require action from the IETF, unless they want free
> administrative support for their private club? It seems like that line of
> argument makes little sense; they could easily have their own ITU "private
> club" without having to twiddle with the IETF.
> >
> an ITAD" makes it easier to sell to carriers (because it doesn't come with
> the expectations of an ITAD and an existing pool of users), so the
> operators can hope to use it to protect or extend their private-club model
> at the same time as activist thinkers are expecting that the SPID will
> eventually have the same sort of egalitarian pressure on it as ITAD.
> >
> I'm probably OKAY with that. The actual operation role of such an
> identifiers. Besides, I've often thought that gonads should be registered;
> they cause a lot more damage than personal firearms.
> >
> > --
> > Dean

---

From: Michael Hammer <[email-masked]>
Date: Tue, 4 Oct 2011 12:20:17 -0400

Ummm.  How about first things first.

Before defining how to reclaim, how about defining how to claim to begin
with?

Mike

On Tue, Oct 4, 2011 at 12:08 PM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> At least people I have talked to in terms of other identifiers have said
> reclamation is hard, and involves a lot of work, and that is for an
> identifier with a smaller set of potential customers, although with a larger
> number of allocated values. How many of the contact details in the ITAD
> registry are still valid, and how many of those registered entities have now
> changed name to something else.
>
> If you want reclamation, then you will need to describe how this is done,
> and the criteria for reclaiming, in any RFC setting up the registry.
>
> Keith
>
> their
> peer
> with
> model
> registered;

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 4 Oct 2011 18:24:07 +0200

Well I thought I'd already asked a couple of questions around that point, without in my view getting an adequate response, so I thought I'd ask a question about another aspect where I also presumably will not get an adequate response.

Keith

________________________________
From: Michael Hammer [mailto:[email-masked]]
Sent: 04 October 2011 17:20
To: DRAGE, Keith (Keith)
Cc: Hadriel Kaplan; Dean Willis; <[email-masked]>
Subject: Re: [RAI] [drinks] FW: Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

Before defining how to reclaim, how about defining how to claim to begin with?

Mike
On Tue, Oct 4, 2011 at 12:08 PM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
A couple of people have mentioned reclamation, almost in passing, without further detail of what and why and how.

Keith

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Hadriel Kaplan
> Cc: <[email-masked]<mailto:[email-masked]>>
> > On 10/3/11 8:31 AM, [email-masked]<mailto:[email-masked]> wrote:
> >> Dear Richard,
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
RAI mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rai

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 4 Oct 2011 16:40:00 +0000

Sorry I should have been clearer.

I didn't mention reclamation in passing - I mentioned it on purpose, because it's what makes a FCFS IANA model similar to ITAD *not* the right model. (along with having recent contact info and such)

BGP AS numbers have exactly these properties, because IANA handed out the assignment of AS numbers to the RIRs, and they manage it and charge an initial and yearly fee.  The initial fee is higher so it keeps random folks out and pays for the admin overhead, and the yearly fee is dirt cheap but having it keeps the AS numbers and contacts fresh.[1]

-hadriel
[1] There's also a non-trivial request process involving proving you need a BGP AS number, but that's because there originally too few of them available, and also because it complicates routing for everyone.

---

From: Dean Willis <[email-masked]>
Date: Tue, 04 Oct 2011 12:43:53 -0500

On 10/4/11 9:49 AM, Hadriel Kaplan wrote:

> When I think of what one would do with these SPIDs, though, they feel
> a lot like BGP AS numbers to me.  I would want to have the list of
> SPIDs be kept up-to-date, with dead numbers reclaimed, with recent
> contact information, and without random people like me just getting
> one on a whim. [note: these are my desires, I have no idea if the
> people asking for SPIDs agree]

AFAIK, the ITAD registry has no "reclamation" policy. One might argue 
that it would be difficult to graft a reclamation policy onto that 
registry, and it's certain that IANA isn't well-positioned to manage 
reclamation within a registry or maintain verified contact-addresses for 
registry items.

So I'd say that the need to have a managed registry with reclamation and 
verified contacts is a strong argument for a new registry with a 
different initial policy from ITAD.

Whether IANA can handle fee-based registration, contact verification, 
and reclamation is another problem. We'd have to ask IANA. It could 
certainly provide a modest funding flow to help offset IANA costs. Or 
like AS numbers, it could be farmed out.

As an alternative, ICANN springs to mind as an organization with the 
wherewithal and standing to manage a registry with periodic fees, 
reclamation, and contact verification. They currently oversee something 
similar, called the DNS.

This raises the ugly elephantine question: Should SPID (or GONAD, if you 
like) be a DNS record? It seems to have some very similar properties. in 
fact, it's a lot like an NS record -- it maps an  identifier to a 
contact-URL in a persistent but not permanent fashion. Allocation of an 
NS record is already controlled through registrar business arrangements 
and has regulations about contact-ability.

Instead of:

example.com.        IN      NS      ns1.example.com.

we might see something like

0123456789ABCDEF    IN      SPID     mailto:[email-masked].

although I confess, I go pale at thoughts of interaction with the DNS 
directorate. Or ICANN, for that matter.

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Oct 2011 14:34:21 -0400

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.

DNS? I don't get that at all ..except as a ENUM record in a private closed
RFC 6116 instantiation.  :-) 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Tuesday, October 04, 2011 1:44 PM
To: Hadriel Kaplan
Cc: <[email-masked]>
Subject: Re: [RAI] [drinks] FW: Global Service Provider ID -
draft-pfautz-service-provider-identifier-urn-01

Instead of:

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 04 Oct 2011 14:24:29 -0500

> Contact data ..maybe but in any event I don't see the immediate need for a

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.

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.

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

---

From: Dean Willis <[email-masked]>
Date: Tue, 04 Oct 2011 14:37:42 -0500

> 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.

2) A mechanism to query that registry.

3) Dynamic propagation of changes to that registry.

4) A mechanism by which multiple registrars can populate the registry.

5) Reclamation of unused names within the registry.

6) Whois-like tracking of entities on behalf of whom registrations are made.

7) Possibly, hierarchical suballocation within the namespace (we've had 
proposals either way on this one).

Thought-provoking question:

How is this whole thing different from Bango Numbers?

http://www.theregister.co.uk/2000/07/20/numeric_domain_name_system_launched/

http://bango.custhelp.com/app/answers/detail/a_id/115/~/bango-numbers

And, since, I consort with evil daily:

http://www.freepatentsonline.com/y2003/0065818.html

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Oct 2011 16:55:08 -0400

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

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.

<whine>  Yea I know.  

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Oct 2011 17:05:39 -0400

-----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 -

Those things are:

Yep .. +1 

Dependant on the size of the registry. No reason you can't periodically poll
for a flat file. Works for the root! 

Maybe .. See A. 

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. 

For instance classic telephony routing registries are WAY WAY WAY too
expensive. 

Use case not demonstrated or even needed IMHO. But it's a reasonable
question. 

+1  I'm pretty much there on this.

Well. I don't know. 

Oh dear .. next thing you will say it needs to be a sub domain of .TEL

---

From: Adam Roach <[email-masked]>
Date: Tue, 04 Oct 2011 16:09:52 -0500

Richard:

I'm finding your quoting style to be somewhat confusing. Could you take 
steps to differentiate your inline comments from the original email to 
which you are responding?

Thanks.

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Oct 2011 17:43:41 -0400

> RS>  Yep .. +1
> RS>  Dependant on the size of the registry. No reason you can't
periodically poll
>  RS>   Maybe .. See A.
> RS>  For instance classic telephony routing registries are WAY WAY WAY too
> expensive.

>   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.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 4 Oct 2011 21:47:08 +0000

> use such data. The scope of that could be intelligently discussed.

Personally I'm not worried about the size even if we don't do reclamation.  I'm not even concerned about assigning a new IANA namespace identical to ITADs but with a new name - I mean it's not that much work even for IANA I would think.

BUT, the reasons to do reclamation go back to the reasons I'm trying to tease out why the ITAD namespace isn't "right" for SPIDs.  My gut tells me that folks don't want the ITAD namespace because it's "polluted", with entities which aren't going to use SPIDs as SPIDs.  So my gut tells me what people really want is a non-polluted namespace.  I like that idea, so maybe that's why my gut tells me that. :)

So... the only way to make and *keep* a namespace unpolluted is to clean it up now and then, hence reclamation.  If you buy the idea of having recent/real contact information for a SPID, then reclamation is nearly automatic, since if the registry doesn't get a refresh/update of the contact then the entry gets reclaimed. (after some time interval)

And the only way I can think of to really make the namespace unpolluted to begin with is to charge money; i.e., create a barrier-to-entry.  It doesn't have to be much: $500 to $1000 to get a new SPID and $100 a year to keep it doesn't seem unreasonable for an organization to pay, but it would keep the riff-raff like me out.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Oct 2011 21:19:44 -0400

> So... the only way to make and *keep* a namespace unpolluted is to clean it up now and then, hence reclamation.  If you buy the idea of having recent/real contact information for a SPID, then recla…

By reclamation, I presume you mean that the assignment of a number which 
is not rejustified from time to time would be revoked, and the number 
potentially reassigned to another entity.

The revocation is not difficult, if by this we only mean the revocation 
in the registry, without concern for continued use. The hard part comes 
when reassignment is added, since then there can be ambiguity whether 
someone using it intended to refer to the old assignee or the new one.

So how about simply having a means to revoke an assignment, leaving the 
associated value as "revoked", never to be assigned again?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Oct 2011 21:29:18 -0400

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)?

	Thanks,
	Paul

On 10/4/11 5:43 PM, Richard Shockey wrote:
>>    RS>  +1  I'm pretty much there on this.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 5 Oct 2011 04:00:46 +0000

On Oct 4, 2011, at 9:19 PM, Paul Kyzivat wrote:

> So how about simply having a means to revoke an assignment, leaving the associated value as "revoked", never to be assigned again?

Yes sorry I meant unassigned but not to be assigned again (unless we run out of course).  I like the term "revoked" better.
:)

-hadriel

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 5 Oct 2011 10:12:19 -0400

> From: Adam Roach [[email-masked]]
> 
> Richard:
> 

I, too, have been having trouble differentiating Richard's text from
the text he was responding to, but I thought the problem was somewhere
in my (low-quality) mail reader.

Dale

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 5 Oct 2011 12:24:55 -0400

-----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,

[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

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 31 Oct 2011 14:34:31 -0400

FYI .. we are still working this. 

Its taking a bit more coordination among the affected parties etc. 

-----Original Message-----

Richard,

	Thanks,
	Paul