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

[<[e-mail]>]

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:[e-mail]]
Envoyé : mardi 27 septembre 2011 18:11
À : BOUCADAIR Mohamed OLNC/NAD/TIP; 'PFAUTZ, PENN L'; 'Sumanth Channabasappa'; [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Monday, September 26, 2011 10:33 AM
To: PFAUTZ, PENN L; Sumanth Channabasappa; [e-mail]
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:[e-mail]]
Envoyé : lundi 26 septembre 2011 15:56
À : Sumanth Channabasappa; BOUCADAIR Mohamed OLNC/NAD/TIP; [e-mail]
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
[phone]
From: [e-mail] [mailto:[e-mail]] On Behalf Of Sumanth Channabasappa
Sent: Monday, September 26, 2011 9:39 AM
To: [e-mail]
Cc: [e-mail]
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, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> 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 : [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] De la part de PFAUTZ, PENN L
Envoyé : vendredi 23 septembre 2011 21:00
À : Sumanth Channabasappa; [e-mail]<mailto:[e-mail]>
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
[phone]
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Sumanth Channabasappa
Sent: Friday, September 23, 2011 2:58 PM
To: [e-mail]<mailto:[e-mail]>
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: [e-mail]<mailto:[e-mail]> On Behalf Of PFAUTZ, PENN L
To: [e-mail]<mailto:[e-mail]>
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
[phone]