ENUM S. Lind Internet-Draft AT&T Labs Intended status: Informational P. Pfautz Expires: February 9, 2007 AT&T August 8, 2006 Infrastrucure ENUM Requirements draft-ietf-enum-infrastructure-enum-reqs-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 9, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) Lind & Pfautz Expires February 9, 2007 [Page 1] Internet-Draft Infrastructure ENUM Requirements August 2006 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Infrastructure ENUM . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements for Infrastructure ENUM . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Lind & Pfautz Expires February 9, 2007 [Page 2] Internet-Draft Infrastructure ENUM Requirements August 2006 1. Terminology 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 BCP 14, RFC2119 [1]. 2. Infrastructure ENUM 2.1. Definition Infrastructure ENUM is defined as the use of the technology in RFC3761 [2] by the carrier-of-record for a specific E.164 number [3] to map a telephone number into a URI [4] that identifies a specific point of interconnection to that service provider's network that could enable the originating party to establish communication with the associated terminating party. It is separate from any URIs that the end-user, who registers their E.164 number, may wish to associate with that E.164 number. Infrastructure ENUM is distinguished from user ENUM, defined in RFC3761 [2], in which the entity or person having the right-to-use a number has the sole discretion about the content of the associated domain and thus the zone content. From a domain registration perspective, the end user number assignee is thus the registrant. Within the infrastructure ENUM namespace, we use the term "carrier- of-record" for the entity having discretion over the domain and zone content and acting as the registrant. The "carrier-of-record" is: o The Service Provider to which the E.164 number was allocated for end user assignment, whether by the National Regulatory Authority (NRA) or the International Telecommunication Union (ITU), for instance a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878) or, o if the number is ported, the service provider to which the number was ported, or o where numbers are assigned directly to end users, the service provider that the end user number assignee has chosen to provide a Public Switched Telephone Network/Public Land Mobile Network (PSTN/ PLMN) point-of-interconnect for the number It is understood that the definition of carrier-of-record within a given jurisdiction is subject to modification by national authorities. Lind & Pfautz Expires February 9, 2007 [Page 3] Internet-Draft Infrastructure ENUM Requirements August 2006 2.2. Background Voice service providers use E.164 numbers currently as their main naming and routing vehicle. Infrastructure ENUM in e164.arpa or another publicly available tree allows service providers to link Internet based resources such as URIs to E.164 numbers. This allows service providers in addition to interconnecting via the PSTN/PLMN (or exclusively) to peer via IP-based protocols. Service providers may announce all E.164 numbers or number ranges they host, regardless of whether the final end-user device is on the Internet, on IP-based open or closed Next Generation Networks (NGNs) or on the PSTN or PLMN, provided an access point of some type to the destination service provider's network is available on the Internet. There is also no guarantee that the originating service provider querying infrastructure ENUM is able to access the ingress network element of the destination provider's network. Additional peering and accounting agreements requiring authentication may be necessary. The access provided may also be to a shared network of a group of providers, resolving the final destination network within the shared network. 3. Requirements for Infrastructure ENUM 1. Infrastructure ENUM SHALL provide a means for a provider to populate DNS resource records (RRs) for the E.164 numbering resources for which it is the carrier-of-record in a single common publicly accessible namespace. The single common namespace ultimately designated may or may not be the same as that designated for user ENUM (e164.arpa.) The FQDN in the resulting resource records will not necessarily belong to or identify the carrier-of-record. 2. Queries of infrastructure ENUM fully qualified domain names MUST return a result, even if the result is a Name Error (RCODE = 3). Queries must not be rejected, e.g., based on access control lists. 3. Infrastructure ENUM SHALL support RRs providing a URI that can identify a point of interconnection for delivery to the carrier- of-record of communications addressed to the E.164 number. 4. Infrastructure ENUM SHOULD be able to support an IRIS [5] capability that allows qualified parties to obtain information regarding the E.164 numbering resources and the corresponding carrier-of-record. Determination of what information, if any, shall be available to which parties for geographic numbers is a national matter. 5. Implementation of Infrastructure ENUM MUST NOT restrict the ability of an end-user, in a competitive environment, to choose a Registrar and/or Tier 2 name server provider for end-user ENUM Lind & Pfautz Expires February 9, 2007 [Page 4] Internet-Draft Infrastructure ENUM Requirements August 2006 registrations. 6. Infrastructure ENUM SHALL be implemented under a top level domain that can support reliability and performance suitable for PSTN/ PLMN applications. 7. Infrastructure ENUM MUST meet all reasonable privacy concerns about visibility of information an end user has no control over. It should, for example, support mechanisms to prevent discovery of unlisted numbers by comparison of ENUM registrations against directory listings, or inadvertent disclosure of user identity. 8. Proposed implementations of Infrastructure ENUM SHOULD: A. Minimize changes required to existing requirements that are part of RFC 3761 B. Work with open as well as closed numbering plans C. Restrict the need for any additional resolver functionality to service provider resolvers. D. Minimize the number of lookups required to obtain as many NAPTR (Naming Authority Pointer) records (end-user and infrastructure) as possible. E. Minimize the client knowledge of the numbering plan required. F. Maximize synergies with end-user ENUM G. Support interworking with private ENUM trees.(In this context a private ENUM tree is one that is not under e164.arpa or whatever namespace is chosen for infrastructure ENUM but uses instead a privately held domain.) 4. Security Considerations Existing security considerations for ENUM detailed in [2] still apply. Note that some registration validation issues concerning end user ENUM may not apply to infrastructure ENUM. Where the Tier 1 registry is able to identify the provider serving a number e.g., based on industry data for number block assignments and number portability, registration might be more easily automated and a separate registrar not required. Some parties have expressed concern that an infrastructure ENUM could compromise end user privacy by making it possible for others to identify unlisted or unpublished numbers based on their registration in ENUM. This can be avoided if providers register all of the their allocated (as opposed to assigned) numbers. Unassigned numbers should be provisioned to route to the provider's network in the same fashion as assigned numbers and only then provide an indication that they are unassigned. In that way, provider registration of a number in ENUM provides no more information about status of a number than could be obtained by dialing it. Lind & Pfautz Expires February 9, 2007 [Page 5] Internet-Draft Infrastructure ENUM Requirements August 2006 5. IANA Considerations This document includes no actions to be taken by IANA. The architecture ultimately chosen to meet the requirements may require IANA actions. 6. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [3] International Telecommunication Union-Telecommunication Standardization Sector, "The International Public Telecommunication Numbering Plan", Recommendation E.164", February 2005. [4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [5] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005. Authors' Addresses Steven Lind AT&T Labs 180 Park Ave Florham Park, NJ 07932-0971 USA Email: sdlind@att.com Penn Pfautz AT&T 200 S. Laurel Ave Middletown, NJ 07748 USA Email: ppfautz@att.com Lind & Pfautz Expires February 9, 2007 [Page 6] Internet-Draft Infrastructure ENUM Requirements August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lind & Pfautz Expires February 9, 2007 [Page 7]