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

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 1 Oct 2011 21:17:27 +0200

At the moment I don't understand how you protect the new space from the same "pollution" as the ITAD space. I'm also interested in what defines those currently registered values as "pollution".

Additionally I do not see any discussion about how we avoid twice the workload on IANA. Surely you create a new service provider like space, you will get anyone who thinks they might be a service provider asking for a value at the same time as they ask for their ITAD value. So IANA end up doing the work to assign values in two registries rather than a single value in only one registry.

Finally, I find the discussion of size of possible number of values in the registry purely academic when the proposed space apparently has no potential mechanism for devolution to subsidiary bodies even hinted at.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard Shockey
> Sent: 30 September 2011 18:04
> To: [email-masked]
> Subject: Re: [RAI] Global Service Provider ID draft-pfautz-service-
> provider-identifier-urn-01
> 
> 
> >
> > There is a preference here for a new fixed length identifier in a non
> > polluted name space so the counter argument is why is there a problem
> here?
> 
> So far, the definition of 'pollution' doesn't appear to make sense (at
> least to me): the requirements for the new namespace won't do anything
> to stop it becoming as equally 'polluted' as the ITAD namespace is.
> 
> The 'problem' is that the IETF is being asked to do work (drafting and
> publishing documents, and operating an additional registry) without a
> clear differentiation from what is already being done. More work for an
> equivalent result seems wasteful, doesn't it?
> 
> 
> I don't agree obviously. The use case documentation and IETF publication
> effort would be roughly the same given any registry selected.  We would
> have
> had to explain this if the IANA Enterprise numbers were used. It still
> strikes me that a new fixed length registry with a clearer use case than
> the
> ITAD is preferable. And the IETF would not operate the registry IANA
> would.
> I am not convinced that the use of ITAD's would produce the expected
> result.
> 
> 
> The end result is not a wasteful exercise. Its defining clarity of purpose
> for the registry. ITAD's were built for one thing, this is for something
> significantly different.  And I might add the use of this class of
> identifier has a well proven and rock solid use case in North America
> where
> it works and works very very well in carrier networks with billions of
> sessions established.   The internationalization of this concept and its
> extention to enterprises through the adoption of this draft would NOT
> cause
> the IETF a lot of work but would eliminate a significant roadblock to
> global
> SIP adoption and eliminate a lot of grief for SIP service providers.
> 
> If it's not a big deal to establish a new registry, why the objection?
> Let's
> see if it works!
> 
> --
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at www.digium.com & www.asterisk.org
> _______________________________________________
> 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: Dean Willis <[email-masked]>
Date: Sun, 02 Oct 2011 19:22:08 -0500

On 9/29/11 8:26 PM, Richard Shockey wrote:
>
> NO..
>
> So can we just go with the ITAD already and get it done?

Ok, so if we define a new 32-bit namespace, and reserve an entry in it 
for each current ITAD holder (using the same ten decimal digits) then 
everybody's happy?

Seems harmless enough. We can call the new namespace ITOLD, short for "I 
told you so..."

--
Dean

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Mon, 3 Oct 2011 00:50:39 +0000

So a couple of thoughts occasioned by the discussion so far...

If another body would be a more appropriate registrar any thoughts about what one might be? (or not be)
I think the idea of charging a nominal fee may have merit as long as the fee isn't prohibitive and is sufficient to cover the added costs of collecting a fee
Any worthy organizations come to mind?  :-)

Thanks,
Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: Saturday, October 01, 2011 3:17 PM
To: Richard Shockey; [email-masked]
Subject: Re: [RAI] Global Service Provider ID draft-pfautz-service-provider-identifier-urn-01

Regards

Keith

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 3 Oct 2011 03:05:29 +0000

Well, BGP AS numbers are assigned by the RIRs (ARIN, RIPE, APNIC, AfriNIC, LACNIC) on behalf of IANA.  I don't know about the other RIRs, but ARIN charges $500 initial payment per AS number, and $100 per organization total per year after (except for ISPs which don't pay the yearly maintenance fee).  

I don't know if the RIRs would consider assigning SPIDs to be within their charter however.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 3 Oct 2011 19:34:55 -0400

Well like the SIPForum ..? Wonderful idea ..great we'll do it...but I not
immediately convinced it would be appropriate or we'd see adoption like a
IANA registry would be.

I'm sensitive to the comments made so far here..though Dean, as usual, is
pushing it a touch. There is no conspiracy here about what people are trying
to do it's just a general preference for a known new fixed length identifier
vs the variable length in ITAD's. Nothing in the existence of the identifier
itself actually compels anyone to actually engage in peering with anyone.
And the point here is that the existence of this registry does not define
what a service provider is, unlike some other international proposals out
there. 

It is NOT in the interest of the IETF to push this off on someone else
because some people think this is a service provider conspiracy. Its not.
It's a real problem in the network. The solution is understood and proven in
North America. This proposal internationalizes that solution and I thought
we were in the business of solving problems.

At least from the discussion so far there is some consensus that A. There is
a problem in the network. B. An globally unique identifier could be used to
solve that problem. The rest is driving a discussion to consensus.

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

" 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."   Almost certainly ...

-----Original Message-----
From: PFAUTZ, PENN L [mailto:[email-masked]] 
Sent: Sunday, October 02, 2011 8:51 PM
To: DRAGE, Keith (Keith); Richard Shockey; [email-masked]
Subject: RE: [RAI] Global Service Provider ID
draft-pfautz-service-provider-identifier-urn-01

If another body would be a more appropriate registrar any thoughts about
what one might be? (or not be)
I think the idea of charging a nominal fee may have merit as long as the fee
isn't prohibitive and is sufficient to cover the added costs of collecting a
fee
Any worthy organizations come to mind?  :-)

Thanks,
Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE,
Keith (Keith)
Sent: Saturday, October 01, 2011 3:17 PM
To: Richard Shockey; [email-masked]
Subject: Re: [RAI] Global Service Provider ID
draft-pfautz-service-provider-identifier-urn-01

At the moment I don't understand how you protect the new space from the same
"pollution" as the ITAD space. I'm also interested in what defines those
currently registered values as "pollution".

Additionally I do not see any discussion about how we avoid twice the
workload on IANA. Surely you create a new service provider like space, you
will get anyone who thinks they might be a service provider asking for a
value at the same time as they ask for their ITAD value. So IANA end up
doing the work to assign values in two registries rather than a single value
in only one registry.

Finally, I find the discussion of size of possible number of values in the
registry purely academic when the proposed space apparently has no potential
mechanism for devolution to subsidiary bodies even hinted at.

Regards

Keith

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 04 Oct 2011 07:07:56 -0500

> vs the variable length in ITAD's. Nothing in the existence of the identifier

As has been said in this thread before, fixed-length vs. variable-length 
is just an artifact of how the identifier is represented when including 
in a particular protocol message; the identifier itself is just a 
number. Any protocol message that desires to include that number can 
choose how it should be represented, including base, prefix/postfix, 
length and other attributes.

A document that proposed usage of identifiers from the ITAD registry in 
SIP signaling to identify service providers to each other could easily 
mandate that the identifier be formatted as a 10-digit decimal number 
left-padded with zeros... and there you go, a fixed-length service 
provider identifier.

---

From: Adam Roach <[email-masked]>
Date: Tue, 4 Oct 2011 07:27:45 -0500

> we were in the business of solving problems.

The thing is, we've pointed to the sensible solution to this problem, and you don't want to discuss it. The conversation has mostly gone:

"Here's something that solves your problem: the ITAD registry, which is already serving multiple purposes."

"But we want a *new* registry."

"Okay, can you explain why?"

"Because we want a new registry."

"Sure, you've said that, but can you motivate it?"

"Yes. Our motivation is that we want a NEW registry."

"Got it. But can you explain why the existing registry does't work?"

"Because it's not new."

And round and round it goes. It's not that people here aren't trying to solve the problem -- it's that you showed up with a solution that you can't adequately motivate and won't listen to voices telling you that there is a better way. You've worked with the IETF long enough to know: that approach never works well. 

/a

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 4 Oct 2011 10:58:22 -0400

> "Because we want a new registry."

It does sound like having a *new* registry is seen as a fundamental requirement.

Dale

---

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

Re:  "And the point here is that the existence of this registry does not
define
what a service provider is, unlike some other international proposals out
there."

If I apply and get an SPID, then what am I?

You can not create a registry for X without defining what X is and who/what
qualifies or does not.

Mike

On Mon, Oct 3, 2011 at 7:34 PM, Richard Shockey <[email-masked]> wrote:

> DRAGE,