ENUM S. Lind Internet-Draft AT&T Labs Expires: April 22, 2006 P. Pfautz AT&T October 18, 2005 Carrier/Infrastrucure ENUM Requirements draft-lind-infrastructure-enum-reqs-01 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 April 22, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document provides requirements for "infrastructure" or "carrier" ENUM, 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. Lind & Pfautz Expires April 22, 2006 [Page 1] Internet-Draft Carrier ENUM Requirements October 2005 Conventions used in this document RFC2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. 1. Infrastructure ENUM 1.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 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. For purposes of this document, "Carrier of Record" refers to the entity that provides PSTN service for an E.164 number with the understanding that this definition is ultimately a matter for national authorities to determine. 1.2. Background Carriers use E.164 numbers currently as their main naming and routing vehicle. Carrier ENUM in e164.arpa or another publicly available tree allows Carriers to link Internet based resources such as URIs to E.164 numbers (Note: this is the other way round then User ENUM). This allows Carrier in addition to interconnecting via the PSTN (or exclusively) to peer via IP-based protocols. Carriers may announce all E.164 numbers or number ranges they host, regardless if the final end-user device is on the Internet, on IP-based closed NGNs or on the PSTN, provided an access (e.g. SBC or gateway) to the destination carriers network is available on the Internet. There is also no guarantee that the originating carrier querying Carrier ENUM is able to access the ingress network element of the destination carriers 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 carriers, resolving the final destination network within the shared network. 2. Requirements for Infrastructure ENUM Lind & Pfautz Expires April 22, 2006 [Page 2] Internet-Draft Carrier ENUM Requirements October 2005 2.1. Infrastructure ENUM SHALL provide a means for a carrier to populate DNS RRs in a common publicly accessible namespace for the E.164 numbering resources for which it is the carrier-of-record. 2.2. Queries of infrastructure ENUM FQDNs MUST return a result, even if the result is NXDOMAIN. Queries must not be rejected, e.g. based on ACLs. 2.3. Infrastructure ENUM SHALL support RRs providing a URI that can identify a point of interconnection for delivery of communications addressed to the E.164 number. 2.4. Infrastructure ENUM SHALL support an IRIS capability that allows qualified parties to obtain information regarding the E.164 numbering resources and the corresponding carrier-of-record. 2.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 registrations. 2.6. Infrastructure ENUM SHALL be implemented under a TLD that can support reliability and performance suitable for PSTN applications. 2.7. Infrastructure ENUM MUST meet all reasonable privacy concerns about visibility of information an end user has no control over, for example discovery of unlisted numbers, or inadvertent disclosure of user identity. 2.8. Proposed implementations of Infrastructure ENUM SHOULD a. Minimize changes required to existing requirements that are part of RFC 3761 Lind & Pfautz Expires April 22, 2006 [Page 3] Internet-Draft Carrier ENUM Requirements October 2005 b. Work with open numbering plans c. Restrict additional functionality to carrier resolvers. d. Minimize the number of lookups required to obtain as many NAPTR records (end-user and carrier) 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. 3. 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 carrier ENUM. Where the Tier 1 registry is able to identify the carrier 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 a carrier 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 carriers register all of the their allocated (as opposed to assigned) numbers. Unassigned numbers should be provisioned to route to the carrier's network in the same fashion as assigned numbers and only then provide an indication that they are unassigned. In that way, carrier registration of a number in ENUM provides no more information about status of a number than could be obtained by dialing it. 4. IANA Considerations IANA considerations will depend on the architecture ultimately chosen to meet the requirements. 5. 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) Lind & Pfautz Expires April 22, 2006 [Page 4] Internet-Draft Carrier ENUM Requirements October 2005 Application (ENUM)", RFC 3761, April 2004. [3] International Telecommunications Union-T, "The International Public Telecommunication Number Plan", Recommendation E.164", May 1997. Lind & Pfautz Expires April 22, 2006 [Page 5] Internet-Draft Carrier ENUM Requirements October 2005 Authors' Addresses Steven Lind AT&T Labs 180 Park Ave Florham Park, NJ 07932-0971 USA Email: slind@att.com Penn Pfautz AT&T 200 S. Laurel Ave Middletown, NJ 07748 USA Email: ppfautz@att.com Lind & Pfautz Expires April 22, 2006 [Page 6] Internet-Draft Carrier ENUM Requirements October 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lind & Pfautz Expires April 22, 2006 [Page 7]