idnits 2.17.1 draft-pfautz-service-provider-identifier-urn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 17, 2012) is 4453 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH P. Pfautz 3 Internet-Draft AT&T 4 Intended status: Standards Track February 17, 2012 5 Expires: August 20, 2012 7 SP URN 8 draft-pfautz-service-provider-identifier-urn-02 10 Abstract 12 This document requests a service provider identifier URN namespace. 14 Conventions used in this document 16 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 17 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 18 document are to be interpreted as described in RFC2119 [RFC2119]. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 20, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Background 54 A number of industry bodies have identified the need for a common 55 global service provider identifier. In the IETF the DRINKS working 56 group has sought an identifier for the owner of objects to be 57 provisioned in registries for the exchange of Session Establishment 58 Data and the ENUM WG and E2MD BOF discussed the need for a service 59 provider identifier to associate with E.164 numbers. Outside of the 60 IETF, the need for a service provider identifier has been discussed 61 in ITU-T Study Group 2, in the i3 Forum, the GSMA, and ATIS. In most 62 of these discussions a preference has been expressed for a numeric 63 identifier that might be obtained by any type of entity as opposed to 64 only certain types of entities, e.g., carriers with a particular 65 national legal status. Although preference was also expressed for 66 reuse of some existing identifier, if possible, as requirements have 67 been elaborated no current identifier seems appropriate. Thus, this 68 document requests registration of a service provider identifier URN 69 namespace. 71 2. Requirements for Service Provider identifier 73 It is suggested that Service Provider Identifiers have the following 74 characteristics: 75 o They SHOULD be globally unique 76 o They SHOULD be numeric, at least 8 digits long 77 o They SHOULD be fixed length 78 o they SHOULD be available to any type of entity 79 o Entities SHOULD be able to obtain mulitple identifiers. 80 o Some range of identifiers SHOULD be reserved for internal entity 81 usage. 83 3. Namespace Considerations 85 URN values are to be assigned by RIRs on a first come first served 86 basis. The resources to be identified are service providers, e.g., 87 (but not limited to) SIP service providers. Entities may obtain 88 multiple assignments. A variety of services might be supported 89 including exchange VoIP and other traffic types. 91 4. Community Considerations 93 Open assignment will allow all types of entities to exchange traffic 94 as opposed to limiting the entities that may be represented as is the 95 case with some other identifies (e.g., ITU-T M.1400 Carrier Codes). 96 A fixed length digit string will be more easily processed by 97 implementations that make use of prefixing as compared to Private 98 Enterprise Numbers or ITADs, which are integer values. The Private 99 Enterprise Number approach of supporting multiple identifiers through 100 subdelegation is also less suitable for use in prefixing contexts or 101 where the SP identifier makes up part of a domain name, e.g., 102 spn{SPID}.ipxsp.org. [GSMAPRDIR67] As the identifiers are intended 103 for service providers rather than end users, it is proposed that 104 registration be handled by the Regional Internet Registries though a 105 process similar to that for Autonomous System Numbers. The RIRs 106 would charge a modest yearly fee that would discourage "junk" 107 registrations while not raising a barrier to legitimate ones by even 108 small entities. The annual fee would also allow the RIRs to identify 109 registrations no longer in use. The RIRs would maintain a whois 110 service for registrations. 112 5. URN Namespace Definition Template 114 Namespace ID: 116 to be assigned 118 Registration Information: 120 Version 1 122 Date: 2012-01-11 124 Declared registrant of the namespace: 126 Name: IETF 128 Contact: P. Pfautz 130 E-mail: ppfautz@att.com 132 Declaration of structure: 134 The identifier structure is as follows: 136 URN:SPID:<8>DIGIT 137 DIGIT=%x30-39 139 Relevant ancillary documentation: 141 Identifier uniqueness considerations: 143 Uniqueness is guaranteed as long as the assigned number is never 144 reassigned. 146 Identifier persistence considerations: 148 TBD 150 Process of identifier assignment: 152 First come first served by Regional Internet Registries. 154 Process for identifier resolution: 156 None at this time. 158 Rules for Lexical Equivalence: 160 exact digit string match 162 Conformance with URN Syntax: 164 No special considerations. 166 Validation mechanism: 168 None specified. 170 Scope: 172 Global. 174 6. Security Considerations 176 Any security considerations would be a product of the applications 177 making use of the new service provider identifiers. 179 7. IANA Considerations 181 TBD 183 8. References 185 8.1. Normative References 187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 188 Requirement Levels", BCP 14, RFC 2119, March 1997. 190 8.2. Informative References 192 [GSMAPRDIR67] 193 GMSA, "PRD IR.67 DNS/ENUM Guidelines for Service Providers 194 & GRX/IPX PRoviders 5.1", August 2010. 196 Author's Address 198 Penn Pfautz 199 AT&T 200 200 S. Laurel Ave 201 Middletown, NJ 07748 202 USA 204 Email: ppfautz@att.com