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

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Fri, 23 Sep 2011 15:02:04 +0000

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: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 23 Sep 2011 11:13:40 -0400

> From: PFAUTZ, PENN L [[email-masked]]
> 
> 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).

Subdelegation would present a problem relative to the desire for
fixed-length identifiers, as the subordinate number would have to be
fixed-length also.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 23 Sep 2011 11:26:37 -0400

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

I am in favor of using one of the existing identifiers so as to avoid
the proliferation of registries.

Regarding the number of digits, I would suggest at least 10, to allow
the number of identifiable entities to exceed the population of the
earth.  This sounds amusing, but not too many years ago, the number of
possible IP addresses was less than the number of people on earth, and
that turned out to be insufficient.  (See RFC 814 for an early
discussion.)

In regard to current registration, about 1,500 ITADs and 40,000
private enterprise numbers have been assigned, which would not
seriously deplete either number space for these purposes.  A more
serious question is whether the administrative procedures of the IANA
are sufficient for the envisioned business purposes -- are there legal
requirements that would make it preferable to have assignment
implemented by another organization?

Dale

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Fri, 23 Sep 2011 15:37:54 +0000

Dale:
I believe open registration as in IANA is important. When SPID was discussed in the i3 Forum most folks came to the
conclusion that traffic exchanges (and support for such exchanges is a major driver for SPID) would occur between many
different types of entities, certainly beyond those recognized as "carriers" or "recognized operating authorities" under various
national and international regimes. So the idea is any entity ought to be able to get a SPID, even though the focus was on service providers
rather than individuals. Having a SPID just means having an identifier to use in enabling exchanges but the terms of any restrictions
would be a matter between the entities involved.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: Worley, Dale R (Dale) [mailto:[email-masked]]
Sent: Friday, September 23, 2011 11:27 AM
To: PFAUTZ, PENN L; [email-masked]
Subject: RE: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

Dale

---

From: Adam Roach <[email-masked]>
Date: Fri, 23 Sep 2011 17:25:20 -0500

> the proliferation of registries.

I think Dale is 100% correct here. We already have a couple of candidate 
registries, one of which has exactly and precisely the properties 
required. At least, for the properties that have been expressed so far 
(except possibly a hierarchical system; which, as Dale pointed out, is 
fully at odds with the requirement for a fixed-length identifier).

http://www.iana.org/assignments/trip-parameters/trip-parameters.xml#trip-parameters-5

These numbers are 32 bits long, which you can model syntactically as a 
fixed-length ten-digit number by zero-padding anything shorter than ten 
digits. For example, ITAD 1020 would be represented as "0000001020".

I don't think it makes even a little bit of sense talking about setting 
up another registry until someone can lucidly explain what properties 
the ITAD registry has that diverge from the properties being proposed 
for the new registry.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Sep 2011 22:54:41 +0000

On Sep 23, 2011, at 11:02 AM, PFAUTZ, PENN L wrote:
> 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.

I don't personally care whether a new registry space is created for SPID or not - it's not like IANA is running out of numbering spaces. :)  And although it takes IANA a bit of work to create a new one, I don't believe it's hard.

The thing that confuses me, though, is every characteristic described in the draft is exactly provided by ITADs, and although the ITAD space was created from RFC 3219 (the TRIP protocol spec), its semantic meaning was a Service Provider ID.  So when the draft says this in section 1:
   Although preference was also expressed for
   reuse of some existing identifier, if possible, as requirements have
   been elaborated no current identifier seems appropriate.

... it's befuddling.

So I asked some people about why ITAD wasn't what they wanted to use for SPIDs, and they said exactly what you said above:
> because the existing ones were intended for other purposes and already had many registrations

The former part isn't really important - PENs for example were created by SNMP but are now used in RADIUS VSAs, DIAMETER AVPs, IPFIX IEs, and others.  It's the number's semantics that matter, not what protocols encode it.  

It's the latter part (that they already have many registrations) that I think is really why people don't want to use ITADs, and that's what worries me in a weird way... because it implies they think some new SPID registry won't be populated with junk.  It will be.  Random people register for these things, because it's free and simple to do so.  Some people will get them for labs or test equipment, some for start-ups which go belly-up, some people get them just because.  For example there's a PEN for an enterprise called KRAP (Kaplan Research and Application Prototyping).  I registered it so I could use a PEN for some prototype code I wrote.  It will never be seen in SNMP, RADIUS, etc.  That's the kind of junk that will appear even if we start a new registry.  So my concern is that people *want* a clean registry, but don't realize that making it free+open virtually guarantees it won't be.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Sep 2011 23:11:27 +0000

On Sep 23, 2011, at 11:02 AM, PFAUTZ, PENN L wrote:

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

I would say 8 digits (which gives 100 million numbers), but in practical terms there's no real savings if computer systems end up storing them as unsigned 32-bit integers/longs, so you might as well go to 10 digits.  

BUT, the question is if the number space should only go up to 4,294,967,295 so that it can in fact be stored efficiently and parsed/printed by common programming functions.

-hadriel

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Mon, 26 Sep 2011 13:56:05 +0000

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

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 26 Sep 2011 17:38:38 +0200

One distinction between IANA tables is the level of review of qualification required before a new entry is made in the table.

Which does raise the question of why the new proposal is FCFS. It is expert review that prevents registries being populated with junk. (It becomes expertly reviewed junk instead :-))

So ITAD is FCFS and the new proposed registry is FCFS.

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hadriel Kaplan
> Sent: 23 September 2011 23:55
> To: PFAUTZ, PENN L
> Cc: [email-masked]
> Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-
> provider-identifier-urn-01
> 
> 
> > 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.
> 
> I don't personally care whether a new registry space is created for SPID
> or not - it's not like IANA is running out of numbering spaces. :)  And
> although it takes IANA a bit of work to create a new one, I don't believe
> it's hard.
> 
> The thing that confuses me, though, is every characteristic described in
> the draft is exactly provided by ITADs, and although the ITAD space was
> created from RFC 3219 (the TRIP protocol spec), its semantic meaning was a
> Service Provider ID.  So when the draft says this in section 1:
> So I asked some people about why ITAD wasn't what they wanted to use for
> SPIDs, and they said exactly what you said above:
> The former part isn't really important - PENs for example were created by
> SNMP but are now used in RADIUS VSAs, DIAMETER AVPs, IPFIX IEs, and
> others.  It's the number's semantics that matter, not what protocols
> encode it.
> 
> It's the latter part (that they already have many registrations) that I
> think is really why people don't want to use ITADs, and that's what
> worries me in a weird way... because it implies they think some new SPID
> registry won't be populated with junk.  It will be.  Random people
> register for these things, because it's free and simple to do so.  Some
> people will get them for labs or test equipment, some for start-ups which
> go belly-up, some people get them just because.  For example there's a PEN
> for an enterprise called KRAP (Kaplan Research and Application
> Prototyping).  I registered it so I could use a PEN for some prototype
> code I wrote.  It will never be seen in SNMP, RADIUS, etc.  That's the
> kind of junk that will appear even if we start a new registry.  So my
> concern is that people *want* a clean registry, but don't realize that
> making it free+open virtually guarantees it won't be.
> 
> -hadriel
> 
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 26 Sep 2011 11:41:04 -0400

> From: Hadriel Kaplan [[email-masked]]
> 
> So I asked some people about why ITAD wasn't what they wanted to use
> for SPIDs, and they said exactly what you said above:
> 
> It's the latter part (that they already have many registrations) that
> I think is really why people don't want to use ITADs, and that's what
> worries me in a weird way... because it implies they think some new
> SPID registry won't be populated with junk.  It will be.

I think there are two overlapping flavors of this distaste.  One is
the symbolism of membership in a registry.  There is going to be a
visceral desire that the registry is "for service providers, but not
limited to traditional telephony".  However, if there are enough
identifiers that we don't risk running out, it really doesn't matter
who or what is allowed into the registry.

The other flavor is what Hadriel says, "we don't want the registry
filled with junk".  But the reality, the *meta-design principle*, is
that if you have a system that can actually keep the junk out, you
will also be keeping out something you want to let in.

Dale

---

From: <[email-masked]>
Date: Mon, 26 Sep 2011 15:43:35 +0200

(Re-sent to RAI).

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 26 septembre 2011 15:37
À : PFAUTZ, PENN L; Sumanth Channabasappa; [email-masked]
Objet : Re: [drinks] FW: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

Dear Penn,

Did I missed something?

Thanks.

Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de PFAUTZ, PENN L
Envoyé : vendredi 23 septembre 2011 21:00
À : Sumanth Channabasappa; [email-masked]
Objet : Re: [drinks] FW: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

Penn Pfautz
AT&T Access Management
+1-732-420-4962
To: [email-masked]

- S

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

The minutes concluded:

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

---

From: <[email-masked]>
Date: Mon, 26 Sep 2011 16:33:19 +0200

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,

Regards,

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

Folks,

Sumanth -- as co-chair

      usage.
Did I missed something?

Thanks.

Cheers,
Med

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

- S

The minutes concluded:

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

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 26 Sep 2011 17:31:48 +0000

Along these lines, who qualifies for a SPID? Could it be a small business
with their own SIP proxy / softswitch? If so, a 10-digit-length registry
will be wholly insufficient.

Jason

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Mon, 26 Sep 2011 17:53:43 +0000

Jason:
Because of the issues alluded to, of finding you've locked someone out you'd like to be in, we were inclined *not* to set up specific qualifications.
So although the focus was service providers, it clearly went beyond ITU recognized operating authorities or even US OCN-eligible parties.
I understand the concern about being too short but not the basis for 10 digits (10 billion) not being enough as the thinking was entities, not end points or individuals in general. ITADs at 2**32-1 will top out below 10B. I'm not sure there's a direct limit on PENs in terms of OID syntax but I'm guessing SNMP implementations might constrain it to the same range as ITADs.

I remain concerned about being too big because of the desire of some parties to do prefixing with them or to incorporate into domain name frames.

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

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]]
Sent: Monday, September 26, 2011 1:32 PM
To: Worley, Dale R (Dale); Hadriel Kaplan; PFAUTZ, PENN L
Cc: [email-masked]
Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

Jason

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 26 Sep 2011 14:31:46 -0400

> I remain concerned about being too big because of the desire of some
> parties to do prefixing with them or to incorporate into domain name
> frames.

I would think through very carefully the consequences of prefixing or
block allocation in any form.  The general rule (apparently) of
allocation systems that respect prefixing is that you get about 2/3
the value out of each digit.  E.g., if you have 9-digit numbers, you
start running out of numbers once you've got around 10^6 endpoints.

Dale

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 27 Sep 2011 12:11:23 -0400

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

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]"
<[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:

Did I missed something?

Thanks.

Cheers,

Med

  _____  

De : [email-masked] [mailto:[email-masked]] De la part de
PFAUTZ, PENN L
Envoyé : vendredi 23 septembre 2011 21:00
À : Sumanth Channabasappa; [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]] On Behalf Of
Sumanth Channabasappa
Sent: Friday, September 23, 2011 2:58 PM
To: [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] On Behalf Of PFAUTZ, PENN L
To: [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) 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:

–      Fixed length 

The minutes concluded:

–      Discussion should move to RAI area list (as opposed to DRINKS or
DISPATCH). 

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?

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: "Richard Shockey" <[email-masked]>
Date: Tue, 27 Sep 2011 12:19:02 -0400

+1

Of all the things to worry about here I doubt this is one of them. 

Personally I think folks and enterprises small or large prefer buy services
from service providers even if the service provider is internal to the
enterprise or cloud. Life is too short. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
PFAUTZ, PENN L
Sent: Monday, September 26, 2011 1:54 PM
To: Livingood, Jason; Worley, Dale R (Dale); Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [RAI] Global Service Provider ID -
draft-pfautz-service-provider-identifier-urn-01

Jason:
Because of the issues alluded to, of finding you've locked someone out you'd
like to be in, we were inclined *not* to set up specific qualifications.
So although the focus was service providers, it clearly went beyond ITU
recognized operating authorities or even US OCN-eligible parties.
I understand the concern about being too short but not the basis for 10
digits (10 billion) not being enough as the thinking was entities, not end
points or individuals in general. ITADs at 2**32-1 will top out below 10B.
I'm not sure there's a direct limit on PENs in terms of OID syntax but I'm
guessing SNMP implementations might constrain it to the same range as ITADs.

I remain concerned about being too big because of the desire of some parties
to do prefixing with them or to incorporate into domain name frames.

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

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]]
Sent: Monday, September 26, 2011 1:32 PM
To: Worley, Dale R (Dale); Hadriel Kaplan; PFAUTZ, PENN L
Cc: [email-masked]
Subject: Re: [RAI] Global Service Provider ID -

Jason

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 27 Sep 2011 13:15:54 -0400

Yes its FCFS. 

There may be junk in the new proposed registry but so what. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE,
Keith (Keith)
Sent: Monday, September 26, 2011 11:39 AM
To: Hadriel Kaplan; PFAUTZ, PENN L
Cc: [email-masked]
Subject: Re: [RAI] Global Service Provider ID -
draft-pfautz-service-provider-identifier-urn-01

One distinction between IANA tables is the level of review of qualification
required before a new entry is made in the table.

Which does raise the question of why the new proposal is FCFS. It is expert
review that prevents registries being populated with junk. (It becomes
expertly reviewed junk instead :-))

Keith

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Sep 2011 12:27:20 -0500

> enterprise or cloud. Life is too short.

Having once been in the business of setting up internet connections for 
small technology companies all the way up to big retail/industrial 
firms, I can say that most of them really WANTED to own their IP address 
space so that they could, if they wanted to, dual-home it via two 
connections and advertise the routes via BGP routing adverts. I 
therefore suspect that more of them want to have SPIDs than you might 
expect.

So while I think that SPID is a Very Important Thing and I'm strongly 
sympathetic to the "just reuse ITAD" argument (and no, the reference to 
"telephone" in ITAD doesn't bother me; all of telephony and all of the 
Internet are semantically merging anyhow), it does seem that we might 
want to think about address space concerns.

We're at about ten billion entities today -- some "natural persons", 
others "legal persons" like corporations, co-ops, government branches, 
independent business units of a larger entity, ships, factories, 
warehouses, office buildings, and so on.

With any luck, the population will merely double over the next 
generation. It could be worse. Also with any luck, we're going to need 
comms identifiers for interplanetary and perhaps extrasolar resources. 
Not to mention the "internet of things". How many SPIDs does a swarm of 
von Neumann probes 
(http://en.wikipedia.org/wiki/Self-replicating_machine) require so that 
all of those little ETs can phone home? Just one, or are they going to 
subdomain by stellar cluster?

While I don't expect every entity to require a SPID, there's an argument 
to be made that the number needed might well exceed 32-bits worth at 
some point in time.

Consider also the model of "permanent allocation". We don't currently 
reclaim ITAD numbers from failed entities or those who no longer need 
them. Given churn and time, that will eventually eat up a lot of 
numbers. If we only issue a million a year, we burn through 
4,294,967,296 in a mere 4,294 years. But if we're issuing a hundred 
million a year, we've only got a 42 year window.

Of course, one could do "reclamation" within a number space. For 
example, the PEN registered to KRAP might, on Hadriel's expiry, be sold 
with his effects. This artificial scarcity potentially creates a 
lucrative market. Consider that New York City taxicab medallions have 
historically been a safer investment than gold; supposedly they have 
never declined in value, and currently sell for somewhere north of 
$600,000 each. I believe that New Mexico state liquor licenses have 
similar properties. If we have a 10% annual reclamation cycle, we can 
issue 4.2 million "recycled" numbers a year in perpetuity.

But if it isn't our intention to assure a perpetual funding model for 
IANA based on artificial scarcity of numeric resources occurring a few 
hundred years from now, perhaps we'd benefit from a larger address space.

On the other hand, perhaps we're being wildly optimistic about the 
importance of the SPID and the future demand for them.

One might also note that 32 bits is a nice fixed-length number in binary 
(32 digits), quaternary (16 digits), or hexadecimal (8 digits). Why are 
we restricting ourselves to 10 decimal digits, which doesn't map to 
anything binary in a very nice way?

--
Dean

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 27 Sep 2011 17:38:06 +0000

>anything binary in a very nice way?

+1
Machines are going to process this stuff in practice anyway, so we needn't
worry that these #s are too long to remember or whatever. Also, now that I
am in the midst of IPv6 deployment I tend to be of the opinion that a
bigger initial address space is better. This is especially the case as
we're not exactly storage or processing constrained in key systems that
would be used.

Feel free to override this one opinion. I just don't want to be on a panel
discussion in 10+ years talking about why we choose such a small SPID
length. ;-)

Jason

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Tue, 27 Sep 2011 17:55:18 +0000

These are certainly good points and other things being equal I'd say better safe than sorry. It comes down to a balancing act. There are contemplated applications where 64 bits/20 digits might be too big or seen as too big: digit prefixing in a telephony scenario (this also drives the fixed decimal length requirement) and using SPID as part of a domain name per GSMA IR.67, SPN[SPID].ipxsp.org
My object is to meet the needs of a variety of stakeholders, some as yet unidentified, and avoid having multiple identifiers.
My own guess is 32 bits/10 decimal digits will be OK as I don't see this as a device or even person level resource although some persons will style themselves as SPs and that's OK. [but I've been wrong and I could be wrong again]
What I can do is go back to some of the stakeholders and see how they'd feel about going larger.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Livingood, Jason
Sent: Tuesday, September 27, 2011 1:38 PM
To: Dean Willis; [email-masked]
Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

+1

Jason

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 27 Sep 2011 17:49:03 -0400

Well OK.  At least there is some consensus that the concept of a global SPID
is "a good thing" tm or "Very Important Thing" tm as Dean points out. The
issue then is the name space and the size of the name space.  ?????

Hopefully we can dismiss this idea of reusing ITAD and focus on what is the
best way forward since it is manifestly self evident that a correctly
designed solution WILL get used and we have evidence that national specific
instances ( North American SPID's) have and do work successfully. 

The point of this exercise is to internationalize a successful and well
observed innovation in the network. 

I'll be even clearer here. This issue of a global SPID came up in the ITU
and there were very very specific objections by certain ( to remain
nameless) governments that the ITU should not define what is and what is not
a service provider. I personally think those objections were correct and
proper. The end result of that effort was this draft and IMHO the IETF and
the RAI community needs to give this discussion careful consideration and
chart a consensus path forward.   

-----Original Message-----
Livingood, Jason

+1

Jason

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 28 Sep 2011 01:39:18 +0200

Just to note that issuing 1,000,000 registrations in one year would require IANA to handle something like 10 registrations a minute for every working hour of every working day of the year. 

That would mean increasing the current staff at least 10 fold, just to handle this load, and require a substantially different financing and operating model.

If you think we are ever going to get anything like these numbers, then the IANA registration route is not the way to go. You need a space where you can devolve the allocation to subsidiary parties and so on.

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
> Sent: 27 September 2011 18:27
> To: [email-masked]

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 27 Sep 2011 21:57:03 -0400

If you've got someone to delegate it to, it's not unheard of for URN namespaces to get delegated to other organizations.
<http://tools.ietf.org/html/rfc5165>

Depending on who it gets assigned to, though, that may change its utility for a general Internet protocol.

--Richard

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Sep 2011 21:15:10 -0500

We have dealt with unexpected success in the past, and I'm sure we can 
deal with it in the future. Jon Postel used to hand out IP address all 
by himself. Allocation progressed through IANA to ICANN, into a complex 
delegated system involving regional registries and an insane number of 
registrars under those registries.

I really don't think this is the greatest part of our concern. Figuring 
out whether 4.3 million or 10 million or 18.6 quintillion or 100 
quintillion is the correct maximum number of entries is probably relevant.

Personally, I don't think there's any good reason to second-guess the 
analysis that TRIP made on this point (they concluded 4.3 million), but 
I'd love to hear arguments to the contrary.

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 28 Sep 2011 16:27:39 -0400

Yea .. 4.3 million "possible" registrations and what is in the registry 1482
registrations.

Plus ICANN certainly has the money ..too much money if you ask me. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
Roach
Sent: Tuesday, September 27, 2011 10:15 PM
To: Richard L. Barnes
Cc: [email-masked]
Subject: Re: [RAI] Global Service Provider ID -
draft-pfautz-service-provider-identifier-urn-01

/a

On 9/27/11 20:57, Sep 27, Richard L. Barnes wrote:
> If you've got someone to delegate it to, it's not unheard of for URN
namespaces to get delegated to other organizations.
>> Just to note that issuing 1,000,000 registrations in one year would
require IANA to handle something like 10 registrations a minute for every
working hour of every working day of the year.
>>
>> That would mean increasing the current staff at least 10 fold, just to
handle this load, and require a substantially different financing and
operating model.
>>
>> If you think we are ever going to get anything like these numbers, then
the IANA registration route is not the way to go. You need a space where you
can devolve the allocation to subsidiary parties and so on.
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Sep 2011 19:29:13 -0500

> Plus ICANN certainly has the money ..too much money if you ask me.

Nothing says they can't charge for a registration. So Adam's right; if 
business booms, they'll find a way to make an industry out of it. Not 
our worry. (But I do want to see the face of somebody at IANA when we 
tell them we're planning for 1,000,000 registrations a year).

However, making sure they don't run out of inventory probably IS our 
problem.

While I agree that 32 bits is PROBABLY enough for the forseeable future, 
if we're going to do something besides ITAD then we might as well go to 
64. But if we're happy with ITAD structurally, there may not be enough 
justification to do more.

At 100 entities per SPID, 32 bits gives us some 430 million entities. 
That's rather short of the 20 billion entities we might see in the very 
near term. Even at 1000 entities per SPID, we're still a factor of 5 
short in the near term.

So what sort of entities-per-SPID ratio are we willing to assume? 
Remember that some entities may have more than one number (I have, at 
last count, 23, including the four companies I currently control).

Is it more of a long-tailed distribution where a few SPIDs have 
tens-of-millions of entities and it tapers off to the right?

--
Dean

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Thu, 29 Sep 2011 13:08:17 +0000

Dean:
I see the case as being..." more of a long-tailed distribution where a few SPIDs have
tens-of-millions of entities and it tapers off to the right" if by entities we mean E.164 numbers or some other form of identifiers.

That is certainly how it would be the for use cases that the drinks WG, the GSMA, and the i3 Forum are looking at.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Wednesday, September 28, 2011 8:29 PM
To: [email-masked]
Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

--
Dean

---

From: Michael Hammer <[email-masked]>
Date: Thu, 29 Sep 2011 11:55:38 -0400

Penn,

If the basis of the distrution is owners of E.164 numbers, then that
implicitly limits the number of SPs possible (and thus SPIDs needed), since
other arrangements limit who may be delegated those numbers.

If there is no basis and anyone may apply, then the distribution tail could
extend to the limits of how many entities are addressable on the Internet,
aka the number of IPv6 addresses.

The question is whether there Should be some threshhold over which the owner
of some addresses would be deemed too small to be a "service provider"?
(Cut the tail off at some point.)

The derivative of that will also determine the likely number of
registrations per year and the load on IANA.

Mike Hammer

On Thu, Sep 29, 2011 at 9:08 AM, PFAUTZ, PENN L <[email-masked]> wrote:

> tens-of-millions of entities and it tapers off to the right" if by entities
> we mean E.164 numbers or some other form of identifiers.
>

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Thu, 29 Sep 2011 16:14:50 +0000

Mike:
E.164 number serving carriers is but one application but even there we are not talking about limiting to carriers-of-record as defined in RFC5067. On the other hand I don't see SPID as the kind of thing every Internet addressable entity would have (i.e., IPv6 addresses). I don't even see the number of SPIDs approaching the order of magnitude number of people on the planet based on existing use cases.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, September 29, 2011 11:56 AM
To: PFAUTZ, PENN L
Cc: Dean Willis; [email-masked]
Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

Penn,

If the basis of the distrution is owners of E.164 numbers, then that implicitly limits the number of SPs possible (and thus SPIDs needed), since other arrangements limit who may be delegated those numbers.

If there is no basis and anyone may apply, then the distribution tail could extend to the limits of how many entities are addressable on the Internet, aka the number of IPv6 addresses.

The question is whether there Should be some threshhold over which the owner of some addresses would be deemed too small to be a "service provider"?  (Cut the tail off at some point.)

The derivative of that will also determine the likely number of registrations per year and the load on IANA.

Mike Hammer

On Thu, Sep 29, 2011 at 9:08 AM, PFAUTZ, PENN L <[email-masked]<mailto:[email-masked]>> wrote:
Dean:
I see the case as being..." more of a long-tailed distribution where a few SPIDs have
tens-of-millions of entities and it tapers off to the right" if by entities we mean E.164 numbers or some other form of identifiers.

Penn Pfautz
AT&T Access Management
+1-732-420-4962<tel:%2B1-732-420-4962>
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dean Willis
Sent: Wednesday, September 28, 2011 8:29 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

--
Dean

_______________________________________________
RAI mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rai
_______________________________________________
RAI mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rai

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Sep 2011 16:16:01 +0000

You kept saying "Million", but I think you mean "Billion". :)

ITADs handle 4.3 _Billion_ numbers.

While there are more than 4.3 Billion E.164 numbers in use, it's in the same ballpark... and it's also the same ballpark for number of devices on the Internet.  

In short: it's a crap-load.  

And this really does make a difference for machines still today - there're still 32-bit CPU's/OS's out there. (and for some reason compilers/libraries still don't seem to handle 64-bit long longs very well)

-hadriel

On Sep 27, 2011, at 10:15 PM, Adam Roach wrote:

> We have dealt with unexpected success in the past, and I'm sure we can deal with it in the future. Jon Postel used to hand out IP address all by himself. Allocation progressed through IANA to ICANN, into a complex delegated system involving regional registries and an insane number of registrars under those registries.
> 
> I really don't think this is the greatest part of our concern. Figuring out whether 4.3 million or 10 million or 18.6 quintillion or 100 quintillion is the correct maximum number of entries is probably relevant.
> 
> Personally, I don't think there's any good reason to second-guess the analysis that TRIP made on this point (they concluded 4.3 million), but I'd love to hear arguments to the contrary.
> 
> /a
>

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 29 Sep 2011 12:17:18 -0400

No not owners. No owns phone numbers sorry but it's a subtle point. 

The proposal would treat the service provider of record for a E.164 and the
holder (customer) of the E.164 number as equal.  Each could use the G-SPID
for its own purposes.  I don't think it's a good idea to set arbitrary
limits here. That is precisely what some of us wanted to avoid with the ITU
proposal to manage this registry concept. 

This idea that the name space could ramp exponentially IMHO is a Red
Herring. There is no technical model assumption that indicates that would be
the likely result either with a fixed 8 or 10 digit length. 

Michael Hammer
Cc: [email-masked]; Dean Willis

Penn,

Mike Hammer

Dean:
I see the case as being..." more of a long-tailed distribution where a few
SPIDs have
tens-of-millions of entities and it tapers off to the right" if by entities
we mean E.164 numbers or some other form of identifiers.

That is certainly how it would be the for use cases that the drinks WG, the
GSMA, and the i3 Forum are looking at.

Penn Pfautz
AT&T Access Management
+1-732-420-4962 <tel:%2B1-732-420-4962> 
-----Original Message-----

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Sep 2011 16:33:12 +0000

This isn't a device identifier, nor a user identifier.  It's not going to be on the scale of IP addresses, MAC Addresses, nor even E.164 numbers.  

This is really like Enterprise Numbers in terms of scope/scale/concept.  Anyone can get an Enterprise Number for free on a FCFS basis from IANA, and a bunch of whacko's like me who don't need them still get them, but even after ~20 years there're still only ~39k numbers allocated.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Thu, 29 Sep 2011 13:32:50 -0400

Penn,
If economics and regulation conspire to make it valuable to do so, then
what stops someone from writing an iPhone app that makes everyone a service
provider?
I try to see what unintended consequences may result if not managed in
advance.
Mike

On Thu, Sep 29, 2011 at 12:14 PM, PFAUTZ, PENN L <[email-masked]> wrote:

>  Mike:****
>
> E.164 number serving carriers is but one application but even there we are
> not talking about limiting to carriers-of-record as defined in RFC5067. On
> the other hand I don’t see SPID as the kind of thing every Internet
> addressable entity would have (i.e., IPv6 addresses). I don’t even see the
> number of SPIDs approaching the order of magnitude number of people on the
> planet based on existing use cases.****
>
> ** **
>
> Penn Pfautz****
>
> AT&T Access Management****
>
> +1-732-420-4962****
>
> *From:* Michael Hammer [mailto:[email-masked]]
> *Sent:* Thursday, September 29, 2011 11:56 AM
> *To:* PFAUTZ, PENN L
> *Cc:* Dean Willis; [email-masked]
>
> *Subject:* Re: [RAI] Global Service Provider ID -
> draft-pfautz-service-provider-identifier-urn-01****
>
>  ** **
>
> Penn,****
>
>  ****
>
> other arrangements limit who may be delegated those numbers.****
>
>  ****
>
> aka the number of IPv6 addresses.****
>
>  ****
>
> The question is whether there Should be some threshhold over which the
> owner of some addresses would be deemed too small to be a "service
> provider"?  (Cut the tail off at some point.)****
>
>  ****
>
> registrations per year and the load on IANA.****
>
>  ****
>
> Mike Hammer****
>
>
>  ****
>
> On Thu, Sep 29, 2011 at 9:08 AM, PFAUTZ, PENN L <[email-masked]> wrote:***
> *
>
> Dean:
> https://www.ietf.org/mailman/listinfo/rai****
>
> ** **
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Sep 2011 18:51:47 +0000

Nothing stops anyone from asking for a SPID and claiming to be one.
It's just useless to them in practice.  The iPhone app won't be able to force AT&T nor anyone else to treat them as a service provider, so AT&T will just overwrite whatever SPID value the iPhone app inserts in SIP signaling sent to AT&T, not use it for anything in AT&T databases, etc.

Obviously the iPhone app could use the number space for its own private uses, or could use them with others in some federation of its own, but I think even they would recognize a 32-bit number isn't big enough for such purposes, and registering every number through IANA is painful for something like that anyway.

The most likely "unexpected" thing to happen is something like freenum.org<http://freenum.org>, which re-used the ITAD number space for their own ENUM service lookup.  They, or some service like them, could arguably switch to using SPIDs instead… but even then they've only used ~1500 ITAD numbers so far, and arguably they've kept to the basic concept of ITADs/SPIDs whereby each number represents a VoIP provider not a device.

-hadriel

On Sep 29, 2011, at 1:32 PM, Michael Hammer wrote:

Penn,
If economics and regulation conspire to make it valuable to do so, then
what stops someone from writing an iPhone app that makes everyone a service provider?
I try to see what unintended consequences may result if not managed in advance.
Mike

On Thu, Sep 29, 2011 at 12:14 PM, PFAUTZ, PENN L <[email-masked]<mailto:[email-masked]>> wrote:
Mike:
E.164 number serving carriers is but one application but even there we are not talking about limiting to carriers-of-record as defined in RFC5067. On the other hand I don’t see SPID as the kind of thing every Internet addressable entity would have (i.e., IPv6 addresses). I don’t even see the number of SPIDs approaching the order of magnitude number of people on the planet based on existing use cases.

Penn Pfautz
AT&T Access Management
+1-732-420-4962<tel:%2B1-732-420-4962>
From: Michael Hammer [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, September 29, 2011 11:56 AM
To: PFAUTZ, PENN L
Cc: Dean Willis; [email-masked]<mailto:[email-masked]>

Penn,

Mike Hammer

Penn Pfautz
AT&T Access Management
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dean Willis
Sent: Wednesday, September 28, 2011 8:29 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Sep 2011 16:28:08 -0500

> ITADs handle 4.3 _Billion_ numbers.

Yeah, my bad, probably, but the math was mostly right in my post on 9/27 
at 11:27PM. I did miscount the reclamation rate; at a 10% annaual 
reclamation rate, we could recycle 430 million addresses a year, not 4.2 
million.

4,294,967,296 ITADs if we count 0.

As I said, "But if we're issuing a hundred million a year, we've only 
got a 42 year window."

> While there are more than 4.3 Billion E.164 numbers in use, it's in
> the same ballpark... and it's also the same ballpark for number of
> devices on the Internet.
>

But we live in a world with many, many loads of crap. Or KRAP, as the 
case may be...

The question: Is our KRAP-loader big enough? Inasmuch as I'm trying to 
sell my dump-truck because my front-end-loader isn't big enough to load 
it, it's the kind of thing I worry about.

Probably the worst-case scenario is that every single business in the 
world, living or dead, from now on will want an ITAD. The closest 
estimates I can find are that the world has between 200 million and one 
billion extant businesses (The US supposedly has 22 million). Let's call 
it 500M for giggles. Assume a churn of 10% a year, that's 50M new 
obsolete ITADs each year (and assuming no growth in the number of 
businesses). The 4.3B address space would be filled in something like 76 
years.

But if we recycle obsolete entries, we never run out (unless there is 
unforeseen growth and every new doghouse needs a SPID).

>
> And this really does make a difference for machines still today -
> there're still 32-bit CPU's/OS's out there. (and for some reason
> compilers/libraries still don't seem to handle 64-bit long longs very
> well)

This makes routing software for IPv6 very hard to write. We really need 
128-bit CPUs to become universal in order to assure the universal 
deployment of IPv6.

So, it looks like the ITAD space, with a policy of reclamation, will 
outlast both the 32-bit CPU and the technology-enhanced lifespans of 
those of us currently discussing it.

And it's pretty easy to add another 32 bits to the front of it later, 
since it's not sub-addressed. I'm guessing we'll have 64 bit CPUs in 
less than 76 years.

Or we could just remove the arbitrary bit-limit from the current 
registry, pad left with zeroes, and warn implementers that if they're 
using binary-integer representation on ITADs (instead of  string 
representation) that, somewhere in 50 years or so, they're going to need 
to use 64-bit long ints?

So can we just go with the ITAD already and get it done?

--
Dean

---

From: Michael Hammer <[email-masked]>
Date: Thu, 29 Sep 2011 17:32:20 -0400

Hadriel,

Right, and no one would ever need more than 4 billion IP addresses.
The first issue is possible run on addresses.
The second, is Never underestimate what a regulator might require an SP to
do in the future.
My thought is to design the convention in advance that is so reasonable it
pre-empts those black swans.

Mike

On Thu, Sep 29, 2011 at 2:51 PM, Hadriel Kaplan <[email-masked]>wrote:

> It's just useless to them in practice.  The iPhone app won't be able to
> force AT&T nor anyone else to treat them as a service provider, so AT&T will
> just overwrite whatever SPID value the iPhone app inserts in SIP signaling
> sent to AT&T, not use it for anything in AT&T databases, etc.
>
>  Obviously the iPhone app could use the number space for its own private
> uses, or could use them with others in some federation of its own, but I
> think even they would recognize a 32-bit number isn't big enough for such
> purposes, and registering every number through IANA is painful for something
> like that anyway.
>
>  The most likely "unexpected" thing to happen is something like
> freenum.org, which re-used the ITAD number space for their own ENUM
> service lookup.  They, or some service like them, could arguably switch to
> using SPIDs instead… but even then they've only used ~1500 ITAD numbers so
> far, and arguably they've kept to the basic concept of ITADs/SPIDs whereby
> each number represents a VoIP provider not a device.
>
>  -hadriel
>
>
>> If there is no basis and anyone may apply, then the distribution tail
>> could extend to the limits of how many entities are addressable on the
>> Internet, aka the number of IPv6 addresses.****
>>
>>  ****
>>
>> On Thu, Sep 29, 2011 at 9:08 AM, PFAUTZ, PENN L <[email-masked]> wrote:**
>> **
>>
>> Dean:
>> tens-of-millions of entities and it tapers off to the right" if by
>> entities we mean E.164 numbers or some other form of identifiers.
>>
>> That is certainly how it would be the for use cases that the drinks WG,
>> the GSMA, and the i3 Forum are looking at.
>>
>> Penn Pfautz
>> AT&T Access Management
>> +1-732-420-4962
>> Dean Willis

---

From: Michael Hammer <[email-masked]>
Date: Thu, 29 Sep 2011 17:35:35 -0400

Correction:  s/addresses/SPID  if that intent was not clear.

Mike

On Thu, Sep 29, 2011 at 5:32 PM, Michael Hammer <[email-masked]> wrote:

>>> E.164 number serving carriers is but one application but even there we
>>> are not talking about limiting to carriers-of-record as defined in RFC5067.
>>> On the other hand I don’t see SPID as the kind of thing every Internet
>>> On Thu, Sep 29, 2011 at 9:08 AM, PFAUTZ, PENN L <[email-masked]> wrote:*
>>> ***
>>>
>>> Dean:

---

From: Adam Roach <[email-masked]>
Date: Thu, 29 Sep 2011 16:59:00 -0500

> Right, and no one would ever need more than 4 billion IP addresses.

FWIW, we're using nowhere near that many. The current exhaustion is due 
to the issuing of IP addresses in blocks. That doesn't happen with ITADs.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Sep 2011 23:30:23 +0000

Except IP addresses were meant to be device identifiers; SPIDs are not.  An IANA registry isn't a good means of providing device identifiers to begin with, because registering each and every one of them through a central registry doesn't scale, for neither the registry nor the device.

Imagine if you had to register every hostname to the DNS registries, as opposed to just domain level; even if it were free to do so, the operational burden would have driven people to find an alternative mechanism.  And even if we think this thing could someday become akin to domain names, there are only a few hundred million of them.

-hadriel

On Sep 29, 2011, at 5:32 PM, Michael Hammer wrote:

Right, and no one would ever need more than 4 billion IP addresses.
The first issue is possible run on addresses.
The second, is Never underestimate what a regulator might require an SP to do in the future.
My thought is to design the convention in advance that is so reasonable it pre-empts those black swans.

Mike

On Thu, Sep 29, 2011 at 2:51 PM, Hadriel Kaplan <[email-masked]<mailto:[email-masked]>> wrote:

The most likely "unexpected" thing to happen is something like freenum.org<http://freenum.org/>, which re-used the ITAD number space for their own ENUM service lookup.  They, or some service like them, could arguably switch to using SPIDs instead… but even then they've only used ~1500 ITAD numbers so far, and arguably they've kept to the basic concept of ITADs/SPIDs whereby each number represents a VoIP provider not a device.

-hadriel

Penn,

Penn Pfautz
AT&T Access Management

Penn,

Mike Hammer

Penn Pfautz
AT&T Access Management
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dean Willis
Sent: Wednesday, September 28, 2011 8:29 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 29 Sep 2011 21:26:03 -0400

NO..

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 30 Sep 2011 07:32:10 -0500

> So can we just go with the ITAD already and get it done?

What a well reasoned and thoughtful response :-)

So far I haven't seen any technical reason why ITAD wouldn't fit the 
requirements, other than the requirement of "the people asking for this 
have to like it".

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

---

From: Michael Hammer <[email-masked]>
Date: Fri, 30 Sep 2011 11:01:11 -0400

Actually supposed to be network endpoint identifiers aka hosts, but not for
every terrminal device attached to a (what used to be IBM or Unix) host.
Now it is every end-user terminal device, and soon with smart grid and IoT
just about anything that can have an antenna, protocol stack, and uses
electricity.  I'll bet the Internet fore-fathers never saw that coming.

My point is not to just consider what your intent is right now, but what is
possible in the future.  As Dean noted, every business could potentially be
an SP.

I agree with your arguments that hierarchy enables scalability.  I am just
suggesting that whatever scheme is chosen, that the ability to aggregate
into a hierarchy is not lost.  That way the global SPs can continue to
operate by inspection of only the "higher order bits/bytes" of the hierarchy
or some other means of not having to search a long-tail, avoid routing
delays, and avoid management nightmares.

Mike

On Thu, Sep 29, 2011 at 7:30 PM, Hadriel Kaplan <[email-masked]>wrote:

>
>  Except IP addresses were meant to be device identifiers; SPIDs are not.
>  An IANA registry isn't a good means of providing device identifiers to
> begin with, because registering each and every one of them through a central
> registry doesn't scale, for neither the registry nor the device.
>
>  Imagine if you had to register every hostname to the DNS registries, as
> opposed to just domain level; even if it were free to do so, the operational
> burden would have driven people to find an alternative mechanism.  And even
> if we think this thing could someday become akin to domain names, there are
> only a few hundred million of them.
>
>  -hadriel
>

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 30 Sep 2011 11:41:13 -0400

I always prefer clarity in my responses. :-) 

I rather dislike the argument that ..well the ITAD's are there,  they might
work,  so go use them and go away now. 

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?

We rejected btw the IANA Enterprise namespace as well for similar reasons.

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 30 Sep 2011 11:03:35 -0500

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

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 30 Sep 2011 13:04:10 -0400

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!

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Sep 2011 14:10:10 -0400

On 9/28/11 8:29 PM, Dean Willis wrote:
[snip]
> justification to do more.

I agree with Dean here:

*If* you think 32 bits is enough, then there has been no *justification* 
for inventing something new rather than using ITADs.

And I'm inclined to think that 32 bits is enough, because the intended 
use will probably mutate into something different before the 32 bits are 
exhausted.

But, if you think 32 is not enough, then 64 is an obvious number to 
choose. An argument was raised against 64 bits because of the encoded 
size (20 bits). But this is only if encoded in decimal.

Why not encode in hex, or radix 64? Here are the number of characters 
required to encode 32 or 64 bits in decimal, hex, and radix64:

            size(bits)
Encoding |  32 | 64
---------+-----+-----
  decimal |  10 | 20
---------+-----+-----
  hex     |   8 | 16
---------+-----+-----
  radix64 |   6 | 11

If 10 decimal bytes were ok, wouldn't 11 radix64 bytes be?

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 30 Sep 2011 14:50:17 -0400

Unless the entry requirements (fees, qualification checking) are indeed substantially higher for the new space, I don't see the advantage of creating another flat registry that at least overlaps, even if they are not exactly the same. (By overlap I mean that a significant fraction of ITAD entries would also need to get the "new" license plates.)

Henning

On Sep 30, 2011, at 12:03 PM, Kevin P. Fleming wrote:

> 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?
> 
> -- 
> Kevin P. Fleming

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Sep 2011 19:17:32 +0000

I think we all agree this is important - no one's trying to say "go away".  And you're right it will probably require an informational RFC no matter what. 
Other comments inline...

> polluted name space so the counter argument is why is there a problem here?

As I said at the Quebec meeting, as far as I can tell the "fixed-length" aspect is the encoding model of the number on-the-wire, not the namespace value.  I.e., IANA assigns AT&T the number 1234, and it just happens that we decide to encode the number in SIP/ENUM/DRINKS message fields padded out to be the string "0000001234", if that's what's needed.  Whereas if this SPID value ends up in a new AVP in DIAMETER (and I'm pretty sure it will), it could be encoded as a 4-byte Unsigned32 data type rather than a 10-byte OctetString or UTF8String.

Is that correct?

We need to understand whether that's correct or not, or if the IANA registry literally needs to be a registry of fixed-length digit-strings instead.

> We rejected btw the IANA Enterprise namespace as well for similar reasons.

Enterprise numbers wouldn't be right for other reasons anyway.  For example, although SNMP never really spelled out what a PEN means, IANA usually only likes to give one PEN per company; whereas ITADs were never meant to have that restriction or meaning.  They're an administrative domain, so one company can have many. 

-hadriel