P. Pfautz Internet Draft AT&T Document: draft-pfautz-na-enum-01.txt September 2000 Category: Informational Expires: March 11, 2001 Administrative Requirements for Deployment of ENUM in North America Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 made obsolete 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document discusses a number of the administrative issues that must be resolved before effective deployment of ENUM[2,3] services in complex environments with number portability and multiple providers for using DNS for translation of E.164 (telephone) numbers. North America is examined critically because its environment may be more complex than most and because current deregulation trends may drive other countries/regions in similar directions. In particular the current mechanisms for number administration and number portability in North America will require establishment of a new administrative function for managing the domain name entries for ported numbers. An important conclusion of this analysis is that it is unlikely that production use of the ENUM mechanisms is feasible in North America (at least) until administrative agreements are reached and that Pfautz Informational - Expires March 2001 1 Administrative Requirements to Deploy ENUM in North America Sept 2000 these agreements are normally outside the scope of IETF and within the scope of regulatory bodies dealing with telephony. Overview While the basic protocols and principles for the ENUM service [2,3]are simple, some administrative operations associated with number portability (moving telephone numbers from one service provider to another) must be handled carefully for the service to work properly. In North America, this will require the introduction of some new administrative functions. It is likely that similar problems will arise in any other administrative domain with similar portability constraints. 1. ENUM Number Delegation and North America The ENUM specification [3, section 4] indicates that the IANA should delegate the E164.ARPA domain so that names within this zone are delegated to parties according to the ITU recommendation E.164. The names allocated are to be hierarchic in accordance with ITU Recommendation E.164, and the codes assigned in accordance with that Recommendation. Following this instruction, subdomains corresponding to Country Codes will be delegated to the corresponding national authorities; for example, the domain "4.4.e164.arpa" would be administered by the national authority for the United Kingdom, which has country code "44". In North America, several sovereign states share the country code "1". Administration of the numbering plan rests with an organization known as the North American Numbering Plan Administrator (NANPA)[5]. Determining the authority for a number is made much more complicated by Service Provider Number Portability. As part of a mandate to provide for competition in the telephone service marketplace, customers may retain their telephone numbers, even when switching to another provider of local telephone service. That is, customers may port their telephone number from the provider to which it was originally assigned (as part of a Central Office code) to a different provider. For this reason, there is, within a country code, ultimately no hierarchical correspondence between the telephone number and the service provider or the administrative authority for a number. Although the NANPA is responsible for number assignments, a different entity, The Number Portability Administration Center (NPAC) provides the industry database of record for ported geographic telephone numbers. Pfautz Informational - Expires March 2001 2 Administrative Requirements to Deploy ENUM in North America Sept 2000 Access to NPAC data is not free and comes with a set of usage restrictions and interface requirements. Toll-Free (e.g., 800, 888) numbers are individually assigned to end users who may port service on the number from one provider to another. PSTN originating local service providers must query a copy of the industry toll-free database for each toll-free call to determine the proper carrier to which the call should be delivered for processing. The data in the Service Control Points (SCPs) queried by the PSTN are populated under tariff by the 800 SMS (Service Management System). The 800 SMS is owned by the Bell Operating Companies, but data center, software support, and help desk functions have been contracted out to other parties. Each number in the 800 SMS is associated with a RESPORG (Responsible Organization), generally the toll-free service provider but sometimes the end user or another designated party, that has control over the record. 2. Previously proposed schemes for ENUM delegation Delegation of authority for domain names below the "1.E164.ARPA" level has been discussed widely. For example, there have been suggestions that such delegations might follow the delegation of blocks of numbers (Central Office codes) to service providers for assignments to customers. For example, a telephone service provider serving phone numbers of the form "650-555-xxxx" could be given administrative control of "5.5.5.0.5.6.1.E164.ARPA". The service providers could then provide the service registrar[4] function or delegate it to some other party designated by the customer. This would have made for a fairly compact set of zones of authority at the 1.e164.arpa level. Unfortunately, number portability means that this scheme cannot be used simply. To further complicate matters, the US FCC has ordered the implementation of thousands block number pooling to allow carriers to share NPA-NXX codes, with blocks being allocated to carriers at the 7-digit or NPA-NXX-X level. Another proposal for dealing with portability had been to delegate authority for NPA-NXXs containing ported numbers to the number portability authority. This two-level process does not simplify matters when most numbers are or will be in portable NPA-NXXs. 3. Implications for Delegation of Authority for Numbers Establishment of a practical ENUM service for numbers in the North American Numbering Plan will require some entity, whether new or existing, to be chartered to perform the administrative function of Pfautz Informational - Expires March 2001 3 Administrative Requirements to Deploy ENUM in North America Sept 2000 maintaining DNS records. There will also have to be an arrangement for this entity to recover its costs. The ENUM portability entity will need to maintain records for individual customer numbers or number blocks; because of number portability, it cannot simply delegate following the patterns of number block (NPA-NXX or NPA-NXX-X) delegation for number assignment. The entity will have to establish relationships and interfaces with NPAC and 800 SMS to obtain information on ported numbers. It is anticipated that the records maintained by this entity will be pointers to the service registrar for a particular number rather than containing the URLs required for actual services. The service registrar might be either the number user's current telephony provider (whether original or ported-to) or some other party designated by the number holder. The service registrar's DNS contains the actual NAPTR records that point to URLs for particular services. There will need to be some specification of the operational procedures for carriers and number users to specify or change the record containing their service registrar. As with selection of local exchange and interexchange (long distance) carriers in the PSTN, these procedures will require adequate authentication or verification mechanisms to prevent unauthorized changes. 4. Example The following example illustrates how ENUM might be implemented for North American numbers: Say that the content of the e164.arpa zone includes the following: $ORIGIN e164.arpa. 1 IN NS ns.nanp_enum.com. Where ns.nanp_enum.com is the name server maintained by the contractor that the regulatory authorities for the NANP have selected to provide DNS service for 1.e164.arpa domain The contractor provisions their DNS with records that point to the service registrar for each number or number block. The service registrar may default to the end customer's current service provider (as reflected in the NPAC if ported or 800 SMS if the number is a toll free number) or may be another entity designated by the customer. Pfautz Informational - Expires March 2001 4 Administrative Requirements to Deploy ENUM in North America Sept 2000 A user named Jenny Jones obtained the phone number +1-792-867-5309 from Telco A (domain name telco-a.example) and ported it to Telco B (domain name telco-b.example) . She gets the service of running DNS from the Example Redirection Service (domain name ers.example). Her neighbor Tommy simply has plain telephony with Telco A for the number +1-792-867-5310. So ns.nanp_enum shows $ORIGIN 7.6.8.2.9.7.1.e164.arpa. 9.0.3.5 IN NS ns.ers.example. 0.1.3.5 IN NS ns.telco-a.example. Jenny not only has plain telephony from Telco B, but also a SIP service from the company ESS (Example SIP Service) which provides Jenny with the SIP URI "sip:jenny@ess.example". The DNS for the redirection service because of this contains the following: $ORIGIN 9.0.3.5.7.6.8.2.9.7.1.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:jenny@ess.example!" . IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+1-792-867-5309!" If Tommy were to port his number to another Telco, he or his agent (e.g., the company to which he ported) would have to update the 1.e164.arpa DNS service to show a new service registrar, whether the new telco or, as in Jenny's case, a third party. 8. Conclusion In order for ENUM to be implemented in North America some entity, whether new or existing, must be empowered by the competent regulatory authorities to run the DNS for the 1.e164.arpa zone. This entity would, in the default case, maintain NS records delegating authority for numbers or number blocks to the service provider to which the numbering plan administrator delegated the numbers for assignment to customers. If a number was ported to a different service provider, the 1.e164 level entity's NS records would change to show delegation to the new service provider. In either case, the end users to which numbers were assigned would have the option of designating a third party to be the service registrar for their numbers and that party would then be the one shown in the 1.e164 level DNS NS records. Portable toll-free numbers would be delegated to their RESPORG in the absence of an alternative request on the part of the end user. 9. References Pfautz Informational - Expires March 2001 5 Administrative Requirements to Deploy ENUM in North America Sept 2000 [1] Bradner, S., "The Internet Standards Process -- Revision 3, BCP9, RFC 2026, October, 1996. [2] Brown, A. "Telephone Number Mapping", draft-enum-rqmts-01-txt. June 2000 [3] Faltstrom, P. "E.164 number and DNS." draft-ietf-enum-e164-dns- 03-txt. August 2000. [4] Brown, A., & Vaudreuil, G. ENUM Service Specific Provisioning: Principles of Operation. Draft-ietf-enum-operation-00.txt. July 13, 2000. [5] North American Numbering Plan Administration (NANPA) 10. Author's Addresses Penn Pfautz AT&T Room E4-3A01 200 South Laurel Avenue Middletown, NJ 07748 U.S.A. Phone: +1 732-420-4962 Email: ppfautz@att.com Pfautz Informational - Expires March 2001 6 Administrative Requirements to Deploy ENUM in North America Sept 2000 Full Copyright Statement This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Pfautz Informational - Expires March 2001 7