Internet DRAFT - draft-pfautz-service-provider-identifier-urn
draft-pfautz-service-provider-identifier-urn
DISPATCH P. Pfautz
Internet-Draft AT&T
Intended status: Standards Track February 17, 2012
Expires: August 20, 2012
SP URN
draft-pfautz-service-provider-identifier-urn-02
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 August 20, 2012.
Copyright Notice
Copyright (c) 2012 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 August 20, 2012 [Page 1]
Internet-Draft SP URN February 2012
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 RIRs 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 August 20, 2012 [Page 2]
Internet-Draft SP URN February 2012
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] As the identifiers are intended
for service providers rather than end users, it is proposed that
registration be handled by the Regional Internet Registries though a
process similar to that for Autonomous System Numbers. The RIRs
would charge a modest yearly fee that would discourage "junk"
registrations while not raising a barrier to legitimate ones by even
small entities. The annual fee would also allow the RIRs to identify
registrations no longer in use. The RIRs would maintain a whois
service for registrations.
5. URN Namespace Definition Template
Namespace ID:
to be assigned
Registration Information:
Version 1
Date: 2012-01-11
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
Pfautz Expires August 20, 2012 [Page 3]
Internet-Draft SP URN February 2012
DIGIT=%x30-39
Relevant ancillary documentation:
Identifier uniqueness considerations:
Uniqueness is guaranteed as long as the assigned number is never
reassigned.
Identifier persistence considerations:
TBD
Process of identifier assignment:
First come first served by Regional Internet Registries.
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
Pfautz Expires August 20, 2012 [Page 4]
Internet-Draft SP URN February 2012
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.
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 August 20, 2012 [Page 5]
