Contribution #______

U.S. Study Group A Ad Hoc on ENUM

CONTACT:         Steven D. Lind

Bldg. 2, Room 2G25

180 Park Avenue
            Florham Park, NJ 07932

973-236-6787

TITLE:       US Implementation of ENUM

US Implementation of ENUM

Steven D. Lind
AT&T

1.    Authoritative Public Root

Telecommunication service providers need a verifiable root for ENUM translations in order to offer carrier-class services. While other roots are being offered within several test-bed environments, AT&T continues to have concerns, as discussed below, about the viability of multiple roots within a commercial-service environment. AT&T believes that the Study Group A Ad Hoc should concentrate its activities on issues that result in the rapid implementation of an authoritative public root (or “golden tree”). AT&T also believes that the United States should also adopt this position within the ITU.

A major concern centers around the possibility that different customer data may be stored in each of several different roots for the same E.164 telephone number. The results of such a situation may prove chaotic and yield unpredictable results.  It is not clear that proposed ENUM-specific DNS resolver software could handle multiple roots to extract correct, unambiguous customer records.  The problem is akin to today’s directory assistance services provided by multiple suppliers, in which a number of databases contain records for the same customer, however in many cases the records are wrong and inconsistent between databases.

2.    Top Level Domain

AT&T prefers the use of “.arpa” as the top-level domain (TLD) for ENUM implementation. While other TLDs have been discussed for an authoritative public root, none of them, including “.int,” satisfy any of the issues raised by the French at the last meeting of Study Group 2 (see Delayed Contribution 15).  The “.arpa” TLD is best suited for the implementation of ENUM because:

q       “.arpa” is an infrastructure domain.

q       “.arpa” is furthest from ICANN involvement. “.int” is currently controlled by ICANN, a situation that is unlikely to change in the near future, if ever.

q       The ITU will be in control over what data goes into the “e164.arpa” domain. While this would also be true for most alternative TLDs (obviously not for private commercial trees such as “e164.com”), it negates the argument that a different TLD is needed to place the ITU in control of the domain.

q       “.arpa” provides additional operational and security capabilities that are not accommodated by other TLDs. For example, multiple highly distributed servers that do not fate share are deployed around the world for the ".arpa" TLD, which ensures better performance and reliability than for other TLDs, such as ".int".  The redundancy of this TLD is just one such feature from which ENUM would benefit.

3.    Tier 1

It is possible for multiple parties to participate within a US authoritative tree, yielding some level of “competition.” At the extreme, a separate Tier 1 Registry could be established for each existing NPA. This  approach would allow easy separation of US ENUM implementation from other North American countries. The Study Group A Ad Hoc Group on ENUM should establish and recommend eligibility criteria that interested parties would need to meet in order to participate as a Tier 1 Registry.  With such criteria established, a bid and award process should be established through the US Government (or by some designated organization) for each segment of the US authoritative tree at Tier 1.

Alternately, parties interested in having U.S. ENUM service could form a Limited Liability Corporation (as was done for the implementation of Local Number Portability) to contract for the Tier 1 functionality. In this case, the U.S. government should certify this entity as the U.S. "e164.arpa" Tier 1 to the ITU.

4.    Tier 2

All interested and qualified parties should be able to provide Tier 2 services to end-users. Many telephony, internet and application service providers will be interested in providing ENUM services. Many of these providers will be interested in providing services through the use of their own name servers to minimize the cost of maintaining the end-users’ data within the NAPTR records. For this reason, AT&T does not  support the use of a Registry/Registrar model[1] in use today for other internet domains. The Study Group A Ad Hoc Group should establish and recommend eligibility criteria for the provision of services using these Tier 2 name servers.

In addition, there are many issues, such as validating the end users’ intentions in establishing ENUM services for a specific E.164 telephone number, and tracking of the disconnect of an active E.164 number that require specification.  AT&T believes that for validations and disconnection of E.164 numbers, the parties that have information on number assignments, usually the telephone service providers, should be involved. Methods for inter-entity exchange of information, including transfer of service provider and notification of termination of service were developed for the implementation of local number portability, and some of these techniques may be applicable to ENUM administration as well. Some of the processes used for Local Number Portability along with domain registration should be examined to develop ENUM administration procedures. Part of this process should include the telephony service provider for an E.164 number notifying the Tier 1entity when the user relinquishes service on the number.

AT&T feels that specific criteria should be established for reliability, security and performance of the ENUM services.  In particular, minimum acceptable performance requirements, such as, “the ENUM service should perform, in all respects, at least as well as DNS performs today,” should be established.  Guidance should also be provided as to how the reliability, security, and performance objectives will be monitored and enforced.

With wide availability of a number of Tier 2 entities, competition at the Tier 2 level will ensure responsiveness to the needs of end users.

Appendix

Registry/Registrar Model

The registry/registrar model is used for some domains within the Internet, particularly ".com." In this model, a single primary name server exists at the top-level domain that is managed by a single entity. Other entities act as registrars by interfacing with end-users, collecting desired domain names from the end users and updating the registry on the end user's behalf.

For example, if I wanted to register the domain name "sdlind.com" I could use Yahoo as a registrar. They would collect the necessary information to register the desired domain name and a fee, taking care of all the necessary work interfacing with the domain name server. Yahoo has no name server itself, but has satisfied all the criteria imposed by the registry operator to have update permission.