DISPATCH P. Pfautz Internet-Draft AT&T Intended status: Standards Track July 11, 2011 Expires: January 12, 2012 SP URN draft-pfautz-service-provider-identifier-urn-01 Abstract This document requests a service provider identifier URN namespace. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 12, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Pfautz Expires January 12, 2012 [Page 1] Internet-Draft SP URN July 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Background A number of industry bodies have identified the need for a common global service provider identifier. In the IETF the DRINKS working group has sought an identifier for the owner of objects to be provisioned in registries for the exchange of Session Establishment Data and the ENUM WG and E2MD BOF discussed the need for a service provider identifier to associate with E.164 numbers. Outside of the IETF, the need for a service provider identifier has been discussed in ITU-T Study Group 2, in the i3 Forum, the GSMA, and ATIS. In most of these discussions a preference has been expressed for a numeric identifier that might be obtained by any type of entity as opposed to only certain types of entities, e.g., carriers with a particular national legal status. Although preference was also expressed for reuse of some existing identifier, if possible, as requirements have been elaborated no current identifier seems appropriate. Thus, this document requests registration of a service provider identifier URN namespace. 2. Requirements for Service Provider identifier It is suggested that Service Provider Identifiers have the following characteristics: 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. 3. Namespace Considerations URN values are to be assigned by IANA on a first come first served basis. The resources to be identified are service providers, e.g., (but not limited to) SIP service providers. Entities may obtain multiple assignments. A variety of services might be supported including exchange VoIP and other traffic types. Pfautz Expires January 12, 2012 [Page 2] Internet-Draft SP URN July 2011 4. Community Considerations Open assignment will allow all types of entities to exchange traffic as opposed to limiting the entities that may be represented as is the case with some other identifies (e.g., ITU-T M.1400 Carrier Codes). A fixed length digit string will be more easily processed by implementations that make use of prefixing as compared to Private Enterprise Numbers or ITADs, which are integer values. The Private Enterprise Number approach of supporting multiple identifiers through subdelegation is also less suitable for use in prefixing contexts or where the SP identifier makes up part of a domain name, e.g., spn{SPID}.ipxsp.org. [GSMAPRDIR67] 5. URN Namespace Definition Template Namespace ID: to be assigned Registration Information: Version 1 Date: 2011-06-04 Declared registrant of the namespace: Name: IETF Contact: P. Pfautz E-mail: ppfautz@att.com Declaration of structure: The identifier structure is as follows: URN:SPID:<8>DIGIT DIGIT=%x30-39 Relevant ancillary documentation: Identifier uniqueness considerations: Uniqueness is guaranteed as long as the assigned number is never reassigned. Pfautz Expires January 12, 2012 [Page 3] Internet-Draft SP URN July 2011 Identifier persistence considerations: TBD Process of identifier assignment: First come first served by IANA. Process for identifier resolution: None at this time. Rules for Lexical Equivalence: exact digit string match Conformance with URN Syntax: No special considerations. Validation mechanism: None specified. Scope: Global. 6. Security Considerations Any security considerations would be a product of the applications making use of the new service provider identifiers. 7. IANA Considerations TBD 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Pfautz Expires January 12, 2012 [Page 4] Internet-Draft SP URN July 2011 8.2. Informative References [GSMAPRDIR67] GMSA, "PRD IR.67 DNS/ENUM Guidelines for Service Providers & GRX/IPX PRoviders 5.1", August 2010. Author's Address Penn Pfautz AT&T 200 S. Laurel Ave Middletown, NJ 07748 USA Email: ppfautz@att.com Pfautz Expires January 12, 2012 [Page 5]