US Study Group A Ad-Hoc

ENUM Questions

Contribution of NeuStar, Inc.

Friday, March 23, 2001

Executive Summary

A number of questions regarding the implementation of ENUM services in the United States were raised during the meeting of the ENUM Study Group A Ad-Hoc, which took place on February 12-13, 2001, in McLean, Virginia. NeuStar submits this document in order to answer the questions raised during that meeting.

NeuStar believes that the United States Government needs to act quickly to create a process for establishing a single Tier 1 registry for ENUM services in the United States and to support the ENUM technical solution described in IETF RFC2916.  Because the Domain Name System (DNS) protocol requires that there be only one authoritative root for each node in the DNS tree, establishing a single registry for the United States portions of the NANP is of utmost importance for efficient administration of ENUM in the United States.  The technical principles for the importance of a single authoritative root are well understood within the Internet Community and have been described by the Internet Architecture Board in IETF RFC 2826.  NeuStar does not believe that it would prove technically and administratively workable to implement ENUM in multiple domains.

In implementing ENUM in the United States, NeuStar believes that the US should adopt a global approach, coordinating with industry representatives, the International Telecommunication Union (ITU), the Internet Engineering Task Force (IETF), and other standards and regulatory bodies in its implementation of ENUM.  The ITU and the IETF have taken a number of positive steps to coordinate their work in ENUM as outlined in IETF RFC 3026.  The United States should encourage these efforts on an ongoing basis.  ENUM in the United States must be compatible with ENUM globally in order for the protocol to perform as intended and to ensure maximum opportunity for industry to compete globally.

For the promise of ENUM to be fully recognized, it must be carefully and thoughtfully implemented to ensure the integrity, reliability, and stability not only of the developing ENUM infrastructure, but also the existing global telephone numbering system.  Moreover, there remain significant potential policy concerns relating to the provision of ENUM services.  Therefore, ENUM cannot be allowed to develop entirely on its own.  Because of the mission critical nature of both these infrastructures, the United States Government must work closely with industry and the international community to get ENUM properly underway.

Question Responses

1          US/International/Global ENUM Implementation

1.1  Should the US participate in a common global approach with the implementation of ENUM in the US.?

Yes.  The US should work with the ITU, the ITEF, and other standards and regulatory bodies in the development of coordinated Internet telephony–related protocols.  In order to operate as intended, ENUM must work within existing telephone numbering administrative contexts to facilitate a wide range of applications using phone numbers as Internet addresses.  ENUM must be coordinated with rules and provisions set forth internationally and nationally for number administration to ensure that the integrity of both ENUM and the E.164 numbering plan is maintained.  Absent such international coordination, there will be no assurance that a US implementation of ENUM would be compatible with other international implementations, nor could an end user of ENUM services be assured that a number used corresponded with an existing E.164 number or was simply a telephone number knock off.  Moreover, a coordinated international implementation will ensure that US companies are able to develop global market strategies for ENUM on the global Internet.

1.2  If not, what are the other options?

NeuStar believes that a coordinated implementation of ENUM is the most responsible manner in which to proceed.  Therefore, if at all possible, the US should participate in a global approach.  If, however, a global approach is unreasonably delayed, the US could move forward with a controlled, measured implementation of ENUM designed to remain compatible with any international coordinated effort.  The ability to migrate into a future global implementation must be maintained.

1.3  Will the US populate some of its NANP resources into e164.arpa?  Are there any anti-trust issues?

In the event that e164.arpa is selected as the international ENUM root, the US should populate the root with its designated numbering resources.  NANP resources populated into the e164.arpa root will be appropriate fully qualified domain names for assigned E.164 numbers.

There are no anti-trust issues introduced by the implementation of ENUM itself.

1.4  Should the US industry work at developing implementation procedures for other zones, e.g., .com?

As noted above, NeuStar submits that there should not be alternate implementations of a public ENUM resource on the Internet.  To the extent, however, that private (enterprise) ENUM implementations make sense within industry and could be implemented in a manner that does not conflict with a coordinated international ENUM implementation, development of procedures for ENUM implementations in other zones would be reasonable.

1.5  What are the implications for other countries in the NANP?

Because of potentially complex issues related to coordination of NANP resources in ENUM, joint understandings between the members of the NANP would lead to improved efficiencies and lower costs while preserving both the basis of the NANP and the relevant aspects of national sovereignty in telecommunications.

1.6  Is there an ongoing role for ITU bodies in the manner in which the US implements ENUM?

Yes.  There is a clear need to establish and maintain an effective working relationship between the ITU, the IETF and US agencies and entities responsible for ENUM implementation.  At the very least, the US will continue to work with the ITU and the IETF regarding issues related to the ongoing maintenance of the international ENUM root and the relationship between ENUM and E.164.  Moreover, though not directly related to a US implementation of ENUM, the ITU has a valuable role in educating its Member States on technical and policy related issues regarding ENUM and assisting all nations in understanding its implications.  The United States should continue to encourage such activities.

2                    Tier One Registries

2.1  Should there be competitive Tier One Registries?

No.  NeuStar advocates that both technical administrative and policy concerns require the competitive selection of a single Tier 1 Registry for US NANP resources.

The DNS protocol fundamentally requires that there be one and only one authoritative root for each node in the DNS tree, see IETF RFC 2826.  Thus, there should only be one Tier 1 Registry for the NANP, i.e., a single registry authoritative for country code 1 itself.  Moreover, ENUM clients and the E.164 numbers they attempt to resolve have no geographic significance in the DNS.  The reason Tier 1 is sub-divided from the global to the national level reflects the inherent hierarchy of administrative policy areas, not geographic areas.  It is incidental to DNS and ENUM that these national policy areas map to national boundaries.  There is no way to further sub-divide the ENUM root for US NANP resources based on geography (e.g., region) in a way that would allow the core administrative functions of the Tier 1 registry to retain their integrity and to be performed uniformly and consistently across all users.  Registries inherently require uniqueness relative to their respective administrative policy areas, hence there is a single .com registry from which to obtain a new .com domain name, and there is a single NANPA from which to obtain new NANP resources.  Likewise, there should be one and only one Tier 1 registry for each national regulatory authority (NRA) area in E.164, sub-divided where necessary to address NRA boundaries below the country code level.

2.2  If so, how many?

As discussed above, one single Tier 1 Registry is appropriate for the ENUM “root” of E.164 country code 1.

2.3  Joint Collaborative effort?

To the extent that a joint-collaborative effort is consistent with the requirements discussed in the answers above, such efforts may be considered.

2.4  What is the selection process?

A selection process for the Tier 1 ENUM registry should be a competitive procurement for a single Tier 1 operator handled by the US government agency identified to implement ENUM in the United States.  The request for proposals for ENUM must address both technical and policy concerns and likely will require input from both agencies interested in the Internet and agencies with responsibility for the NANP.

2.5  Sole industry responsibility or what amount of Regulatory involvement?

The resources to be registered in the Tier 1 registry (i.e., E.164 telephone numbers) are subject to inherit requirements stemming from both E.164/PSTN and IP-based/Internet infrastructures.  Regulatory involvement in US Tier 1 is appropriate to the degree that it is necessary to shape the appropriate uses and policies of the ENUM service with respect to current regulatory treatments of telephone numbers and domain names.  Such regulatory efforts will not constitute regulation of the Internet as a whole, but rather appropriate streamlined safeguards to ensure the continued integrity of the NANP and the DNS.

3          Overall Architecture

3.1  What is the overall architecture/hierarchy?

The overall architecture of ENUM consists of functions grouped into several major categories.  This categorization is useful in describing the service hierarchies within an ENUM implementation.

The major groups of functions for ENUM are:

      IP-based application services,

      DNS-based services, and

      PSTN-based services.

Grouping functions by these categories renders certain terms more clear in meaning and scope, and provides a framework for underlying assumptions regarding ENUM implementation.  Moreover, discussion of ENUM in terms of service categories rather than operational entities avoids potential confusion when a single entity performs multiple different functions.

3.1.1    IP-based Application Services are the ENUM functions related to IP services that allow end users to, for example, send and receive email, view web pages, send and receive faxes over the Internet, and use voice over IP.

A specific service may be provided by one or more Application Service Providers (ASPs) chosen by the user.  Associated with that service will typically be a service-specific address.

ENUM itself is not an IP-based Application Service given that it does not carry any user traffic.  Service-specific addresses reside in the Tier 2 level of ENUM DNS-based functions.

3.1.2    DNS-based services are the functions related to the maintenance and provision of information about domain names and associated information such as service-specific addresses.

ENUM is a DNS-based service.  The domain names are “ENUM names” for telephone numbers.  The “ENUM Service” itself is the ability for an ENUM subscriber (known as the “End User” of the ENUM Service) to make certain information available for retrieval through DNS queries.  The information retrieved based on the End User’s telephone number is one or more service‑specific addresses.

The DNS provisioning of telephone numbers for ENUM is divided into two primary sets of functions (Tier 1 and Tier 2).  Country codes reside at the “Tier 0” level.  An additional level of service-specific information (Tier 3) may be provisioned depending on the specific service.

Tier 0 is sometimes used to refer to DNS functions that manage ENUM root-level information and the ENUM names for E.164 country codes.

Tier 1 refers to DNS functions that manage the ENUM name for an E.164 country code and to the DNS functions that manage the ENUM names for telephone numbers within that country code.

Tier 2 refers to DNS functions that manage the ENUM name for a telephone number and the End User’s choices of NAPTR records for service-specific addresses, which would all be returned in the response to any DNS queries about the End User’s telephone number.  The End User can choose a Tier 2 entity by subscribing to its ENUM service offering.

3.1.3    PSTN-based services are functions for non-IP based telephony services, telephone numbers for those services, and non-telephony services necessary to support such non-IP based telephony services.  A telephone number is assigned in conjunction with a telephony service.  Telephone numbers in ENUM are E.164 numbers assigned for telephony services.  ENUM names for telephone numbers reside in the Tier 1 level of ENUM’s DNS-based functions.  ENUM names for country codes are located in the Tier 0 level.

3.2  With multiple providers what are the functions, definitions, relationships, and flows between the various service entities?

In order to ensure the integrity of E.164 and ENUM, the ITU and the IETF have established agreements that address the administrative aspects of ENUM, see IETF RFC 3026.  It has been agreed that all administrative entities, including the DNS administrators of ENUM resources, will adhere to pertinent ITU Recommendations, e.g., E.164, E.164.1, and E.190, as well as applicable ITU principles and procedures.

For all E.164 Country Codes, the ITU will provide assignment information to the DNS administrator of the E.164/ENUM root domain.

Thus, whenever an NRA, such as the United States government, determines that E.164 numbers under its jurisdiction should be placed in the DNS, it will inform the ITU.  The ITU will then authorize the inclusion of the appropriate specific country code as a Country Code zone of DNS authority.  This action includes the delegation of authority for DNS administration of that Country Code zone to the NRA(s) to whom the E.164 country code is assigned.

The following tables describe the relationships and roles of the various ENUM functions and the entities providing those functions.  The first table illustrates some basic attributes of the DNS Tiers for E.164 numbering in ENUM, and is based on an example taken from RFC 3026, which contains the Liaison Statement on ENUM from the October 2000 meeting of ITU-T Working Party 1 of Study Group 2 in Berlin.

Table 1:          DNS Tiers for E.164 Numbering in ENUM

The next three tables describe the roles of functional entities involved in ENUM services, and contain additional information on relationships between these entities.  Table 2 looks at the four levels of ENUM Tiers.  Users and Service Providers are described in Tables 3 and 4 respectively.  These groupings help clarify how the different roles need to interact in order to provide ENUM services.

Table 2:          Functional Entities - DNS Tiers for ENUM

Table 3:          Functional Entities - End Users and Calling Users for ENUM

Table 4:          Functional Entities - Service Providers for ENUM

3.3  How can interconnection between multiple entities be efficiently accomplished?

The structure described above is essentially one of a Registry handling Tier 1 functions and a Registrar responsible for Tier 2.  This model is well known in the Internet Community.  It is clear that policy relating to the appropriate roles and responsibilities of the various entities described above need to be developed and documented.

3.4  What kinds of tools and mechanisms are necessary?

With the proper documentation of appropriate roles and responsibilities of the various entities involved in the ENUM process, functional and secure software can be developed that can facilitate these transactions. NeuStar believes that the development of such software should follow well-established principles of open protocol development by the technical community.  Because ENUM is a DNS-based service, many of the appropriate tools already exist or are being developed for other DNS operations.

4          Tier 2 Service Providers

4.1  What are the criteria for Tier 2 service providers?

Tier 2 service providers must be technically capable of interconnecting with the Tier 1 service provider for the purpose of registration of E.164-based “ENUM Names.”  Providers must be prepared to verify this capability through testing procedures established by the Tier 1 operator.

In addition, a Tier 2 service provider must be prepared and capable of adhering to specific policies and requirements established by the Tier 1 operator and the National Administration responsible for telephone numbers within a given country code.  The requirements and policies will be designed to protect the integrity of both the national telephone numbering plan (the NANP in the case of country code 1) and the DNS.  These requirements and policies will be established in the future, but include such concerns as line status and assignment verification, number slamming and hijacking, privacy, and DNS security protocols.

This model presumes multiple competitive Tier 2 entities much like in the existing DNS industry.

4.2  What is the definition and scope of Tier 2?

Consistent with the discussion above, a Tier 2 provider provides the DNS functions that manage the ENUM name for a telephone number and the End User’s choices of NAPTR records for service-specific addresses, which would all be returned in the response to any DNS queries about the End User’s telephone number.  The End User can choose a Tier 2 entity by subscribing to its ENUM service offering.

4.3  Should there be a qualification process?

Yes, there must be a process to ensure that a Tier 2 entity meets the criteria discussed above.  Moreover, in order to address concerns over implementation of policy matters and service restrictions, the National Administration may seek to establish a separate or additional process for determining the suitability of a Tier 2 provider.

5          General Issues

5.1  What is the appropriate role of US government agencies, and/or industry self-regulating bodies?

An effective implementation of ENUM will require that both sets of bodies work together to address the issues and challenges related to ENUM services.  Industry self-regulating bodies must work to establish appropriate standards and policies to effectively govern certain aspects of the ENUM industry.  Likewise, US agencies will monitor ENUM implementation with the sphere of their respective jurisdictions and take any action deemed necessary and appropriate.  In the final analysis, a properly structured ENUM implementation can minimize necessary government involvement.

5.2  Industry testing of ENUM?

Testing of ENUM is critical.  Visible aspects to be tested are operational issues including performance (e.g., response time and variance, volume and distribution of queries), protocol correctness (values in queries and responses, values in DNS records), and DNS structure.  Other aspects such as zone administration, subscriber information handling, and privacy also require testing.

Industry must be able to perform testing at the earliest possible stages so that experience and results can guide further development and operable implementation.  Industry also must begin to define testing procedures that would be appropriate for maintenance and fault resolution when ENUM is operational.

5.3  How is authentication and validation of subscriber choice and right to use an E.164 number achieved?

It is essential that authentication and validation of a subscriber’s right to populate their ENUM resources as well as authentication and validation of their choice of services be a paramount consideration of ENUM operators.  ENUM cannot and will not succeed if consumer confidence in the integrity of the system, end to end, is not maintained.  On the question of validating the subscribers right to populate their ENUM resources in the ENUM system, NeuStar submits that there are sufficient authoritative databases within the United States telecommunications industry to support the development of an effective mechanism for validation of subscribers seeking registration of a given telephone number.  In addition those databases can facilitate the verification of the line status (whether a particular number has been disconnected from the PSTN) to determine when ENUM resources associated with a number should be disconnected.  It is critical that ENUM in the United States be implemented in a manner that prevents, from the outset, number hijacking, slamming and cramming.

5.4  How are NAPTR records zones administered and discovered?

There are significant policy considerations in the administration of Tier 2 entities, especially if those Tier 2 entities are service providers acting on behalf of consumers.  The purpose of ENUM is to create not only competition in the creation of new services but to permit multiple service providers to compete through equal access to NAPTR records for the purpose of service creation. Considerable care and consideration will have to be given to the roles and responsibilities of Tier 2 providers.  As for the actual method by which NAPTR records are Added, Modified or Deleted, a variety of tools exist or can be created and implemented by Tier 2 providers that permit authentication and validation of NAPTR record change requests.

5.5  What is the disconnect notification process between TSPs and the Registry/Registrar?

As noted above, sufficient authoritative database resources exist within the United States to provide timely notification of telephone number disconnection.  Access to these database resources can be legally acquired in order to assist ENUM service providers in properly disconnecting ENUM resources at the time PSTN service is disconnected.

5.6  What types of NANP resources should not be populated in ENUM, e.g., 700 numbers?

In general, NANP Resources that are not both assigned and in service should not be populated in ENUM.  Certain other specific non-geographic NPAs and US‑assigned N11 NPAs should not be populated without further study to determine their feasibility and suitability with respect to ENUM implementation.  NPAs requiring additional consideration include:

·         Non-Geo   456      Inbound International

·         Non-Geo   500      Personal Communication Service

·         Non-Geo   600      Canadian Services

·         Non-Geo   700      Interexchange Carrier Services

·         Non-Geo   710      US Government

·         N11 - abbr            211      US - Community Information and Referral Services (US)

·        N11 - abbr 311      US - Non-Emergency Police and Other Governmental Services (US)

·         N11 - abbr            511      US - Traffic and Transportation Information (US); Reserved (Canada)

·         N11 - abbr            711      US - Telecommunications Relay Service (TRS)

The unassigned N11 NPAs should not be populated in any case since they are not assigned. 
These include:

·         N11 - abbr            411      Unassigned - Local Directory Assistance

·         N11 - abbr            611      Unassigned - Repair Service

·         N11 - abbr            811      Unassigned - Business Office

·         N11 - abbr            911      Unassigned - Emergency

5.7  Would there be a need for additional NANP assignments to ENUM?

No.  The current view of ENUM requires that numbers can only be eligible for ENUM if (among other criteria) they are assigned specifically for legitimate telecommunications use via appropriate processes.  In fact, it is quite possible that a well-managed ENUM environment will lessen the pressure on the need for new numbers, and could, as a result, extend the viability of current NANP assignments.

5.8  What are the effects of ENUM on NANP utilization?

ENUM will have no necessary direct effects upon NANP utilization.  ENUM works with numbers that already are assigned to a telephony service subscriber under existing number assignment rules.  Numbers will not be assigned solely for use with ENUM.  As noted above, however, ENUM reduces the number of separate telephone numbers needed for different functions (such as voice, voice-mail, and facsimile).  In this manner, ENUM actually may reduce utilization pressures on the NANP.

5.9  Criteria for transaction security?

Two primary types of transaction security must be considered in an ENUM implementation.  First is the transaction security between the various service entities in the ENUM process, and second is the transaction security between zones within the DNS for the purpose of updating records and zone files.  In both cases, significant work has been done on secure mechanisms for handling secure processing in the DNS.  This work will be applied in the implementation of ENUM.

5.10    How are consumer protection and privacy maintained?

It must be understood from the outset that the global Domain Name System is completely open.  That is why the Internet works.  The information stored in the ENUM should be relevant only to the making of connections between end points and not personal data.  It is therefore useful to view ENUM as a “Service Control Point” within that context.  It is therefore useful to view ENUM as a “Service Control Point” within that context.  Personal data of an End User should not be exposed in the DNS.  Rather, such information should only exist within the service context itself at a Tier 2 or Tier 3 level.  For example, for a SIP or Voice Profile for Internet Mail service offering, the DNS portion of the ENUM implementation only stores the pointer to the proxy or server where actual personal data or service logic exists to support the service.  Therefore, the primary consumer protection and privacy concerns exist at the service provision level.  In many service contexts, existing laws, regulations, and policies serve to protect consumers.  Where such protections do not exist or are not effective, the ENUM industry must work together and with public interest advocates and agencies to address any issues.  As noted above, the necessity to implement sound and sufficient policies and procedures in the ENUM registration process in order to insure consumer protection is of paramount concern.  NeuStar believes that sufficient resources and processes exist to address most consumer concerns.

5.11    What is the Conflict Resolution process?

As with any DNS implementation, potential for disputes exists between the various entities providing the relevant service, as well as between those service providers and the users of the service.  There has been significant work to date in developing dispute resolution mechanisms relating to DNS services in the Internet Community.  ENUM providers must draw on this experience to propose and develop similar mechanisms for ENUM specific disputes.  For example, disputes regarding authority to register a telephone number could be addressed by a process to the Uniform Dispute Resolution Process established by the Internet Corporation for Assigned Names and Numbers (ICANN).  Other mechanisms, no doubt, will have to be considered.

5.12    What are the effects of ENUM on DNS performance?

Some ENUM participants have voiced concern with respect to the possible effects of ENUM on DNS performance.  This concern is particularly strong in relation to the possible need to implement DNS Security (DNSSEC) at some point in time in order to maintain the integrity and authoritative nature of the ENUM zone files.

NeuStar believes that there is no doubt that the ENUM root will be able to scale sufficiently to meet the requirements of handling the resources required by Recommendation E.164.  Each digit in the ENUM Fully Qualified Domain Name represents a discrete and potentially distributed zone in DNS terms.  DNS zone management is a well-understood technical art in the Internet Community.  The highly distributed and global nature of the DNS itself clearly indicates that ENUM will be capable of scaling appropriately.

In addition, NeuStar strongly believes that any potential negative impact, if any, on the DNS can be addressed by technical standards bodies, such as the IETF, through the development of a series of Best Current Practices and other documentation to instruct ENUM zone administrations on proper operation and configuration of their domains.

The Internet Community has spent many years developing a variety of tools and protocols for implementing security within the DNS itself.  NeuStar believes that the emerging United States ENUM community must study the implications of DNSSEC on ENUM operations and be prepared to implement DNSSEC within the United States ENUM implementation once it is clear that these protocols and tools have reached a sufficient level of maturity and stability.  It is hoped that the US government will continue to actively support ongoing research and development in these areas.

Finally, it will be a necessary aspect of the qualifications of all ENUM service providers that they ensure that they provision sufficient scalable capacity within their service systems to handle the level of traffic for the telephone numbers which that they manage.