Subject: [dispatch] Request for input. FW: I-D Action: draft-pfautz-service-provider-identifier-urn-00.txt

From: "Richard Shockey" <[email-masked]>
Date: Thu, 9 Jun 2011 10:10:25 -0400

As some of you may have seen from the proposed DISPATCH agenda, this
document is proposed for discussion. It is in a early draft stage and needs
comment and community input.

That said I want to strongly support both the concept and the direction this
draft is taking. It highlights and proposes a solution to an extremely
important problem in SIP interconnection among global SIP service providers.
The problem is who do you send the session to if, typically, all you have is
a E.164 number. 

OK some of you would say ..that is what ENUM was supposed to do and
certainly no one wants listen to me rant on about ENUM anymore, but the
problem of number translation in SIP service provider networks remains and
is a serious impediment to global deployments. 

There is substantial technical precedent for this type of solution. In the
North American Numbering Databases there is a Service Provider
Identification Code (SPID) that has proved very useful for SIP service
providers in deploying Network to Network Interconnection interfaces. The
very existence of this identifier has permitted interconnected SIP to expand
to nearly 30% of the US voice market according to 2010 data from US Federal
Communications Commission Statistics. This draft proposes to extend this
technique.

The elegance of this solution is that it does not propose any new protocols,
nor does it define what type of databases or class of users can use the URN.

As the draft points out, this concept has been discussed for some time in
various industry groups and has been discussed as part of the overall DRINKS
architecture. It is, IMHO, a "good thing". 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Thursday, June 02, 2011 9:34 AM
To: [email-masked]
Subject: I-D Action: draft-pfautz-service-provider-identifier-urn-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : SP URN
	Author(s)       : Penn Pfautz
	Filename        :
draft-pfautz-service-provider-identifier-urn-00.txt
	Pages           : 5
	Date            : 2011-06-02

   This document requests a service provider identifier URN namespace.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identifier
-urn-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-pfautz-service-provider-identifier-
urn-00.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 9 Jun 2011 11:36:34 -0400

The syntax of the proposed URNs is odd.  As far as I can tell from your text, you want "urn:12345678".  What is the URN scheme?

But I see no strong need to introduce a new scheme, as organizations can get identifiers in an existing scheme:  Get a "private enterprise number" assignment, which gives you ownership of the 1.3.6.1.4.1.xxx Object Identifier tree.  Then you can use all "oid" URNs under that tree.

E.g., my consulting company is identified by <urn:oid:1.3.6.1.4.1.14490>.

That has more overhead, but it also allows infinite sub-delegation, and it's already standardized (RFC 3061).

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Jun 2011 15:18:53 -0400

I have no agenda wrt this - just questions.

1) why numeric?
2) why fixed length?

I'll observe that fixed-length-numeric + open assignment is asking for 
trouble. Though perhaps it can be mitigated if the numbers must be 
individually assigned through some cumbersome process that can't be 
automated on the requesting end, and if the fixed length is "long enough".

(That doesn't mean I'm opposed to open assignment. I'd be opposed to 
anything more restrictive.)

	Thanks,
	Paul

On 6/9/2011 10:10 AM, Richard Shockey wrote:
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Thu, 9 Jun 2011 16:22:06 -0400

Responding to Dale and Paul...

Some of the drivers for numeric and fixed length are potential uses in
legacy applications that only use numeric and may want to do things like
(God forbid) prefixing where fixed length would be important.

As to why not oid PENs, the above is part of that but not all. It's not
clear to me what the acceptability of entities obtaining multiple oids
(other than through sub-delegation) although in practice this has
occurred.

That said, I'm not ruling out using oid potentially formatted as a fixed
length string and without the hierarchical appendages.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Thursday, June 09, 2011 3:19 PM
To: [email-masked]
Subject: Re: [dispatch] Request for input. FW: I-DAction:
draft-pfautz-service-provider-identifier-urn-00.txt

1) why numeric?
2) why fixed length?

I'll observe that fixed-length-numeric + open assignment is asking for 
trouble. Though perhaps it can be mitigated if the numbers must be 
individually assigned through some cumbersome process that can't be 
automated on the requesting end, and if the fixed length is "long
enough".

	Thanks,
	Paul

On 6/9/2011 10:10 AM, Richard Shockey wrote:
> Subject: I-D Action:
> A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identi
fier
> This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-pfautz-service-provider-identif
ier-

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 9 Jun 2011 17:45:21 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]

1) why numeric?
2) why fixed length?

I assume we're going to use Private Enterprise Numbers (http://www.iana.org/assignments/enterprise-numbers), since we've already got a registry for that.

Dale