ENUM

1. EXECUTIVE SUMMARY

Observation of discussions of ENUM in various forums and contexts has convinced the IAB that there is considerable confusion about the underlying technology and the reasons for, and implications of, some of the decisions that have been made. At the same time, we have observed two things happening: (i) the confusion, and delays caused by it, are creating a fertile environment for those who are anxious to deploy products and who would prefer to do so with few, or no, controls to ensure that the circumstances of ENUM deployment within, or corresponding to, a country’s components of the E.164 numbering system are consistent with that country’s policy decisions. And (ii) some countries, who are anxious to move forward, at least with pre-commercial trials, have begun to become frustrated that it is proving difficult to do so. This liaison statement reviews several of the points of confusion and puts them in context. It also proposes a set of procedures that should permit those countries who wish to begin ENUM development an opportunity to do so while providing protections for countries that wish to move at a more deliberate pace.

2.INTRODUCTION AND BACKGROUND

The proposal to develop and deploy ENUM originated within the IETF process, with significant input from active participants in the SG 2 process. The mechanisms for mapping telephone numbers, derived from the E.164 system in form and content, is just part of an integrated collection of protocols to provide for so-called “Internet telephony”. ENUM itself is, from a narrow technical point of view, just a set of conventions for representing these numbers as identifiers in the Internet’s standard, and widely-deployed, Domain Name System (DNS). That collection of protocols, and its possible applications, is very broad: the potential use of a reference to a Uniform Resource Identifier (URI, essentially, a generalization of what is popularly called a “web address”) as the target of a registered name creates the opportunity for a very broad range of applications, not just internet telephony. Characteristically with the Internet and its “innovation at the edges” character (Note 2), we would expect that, over time, many of these applications (most of which cannot be anticipated today) will be developed and tried. Some will find favor with users and the marketplace, succeed, and survive for the long term; others will fail and disappear. While other applications are possible, ENUM was, and remains, basically an Internet protocol. It is needed when connections are originated on the Internet that are intended to terminate on resources people perceive as “telephone numbers”, a perception that some of its authors and advocates believe will broaden over time. It is not required –although it might be useful given some applications ideas as mentioned above– for connections originating on the Internet and terminating on the Internet. For those purposes, domain names that have no mappings into the E.164 space are quite adequate technically. At the same time, if something is perceived of as a “telephone number”, it has always seemed obvious to us that the set of DNS records associated with that number should be under the control –to the extent that each of them think wise– of national Administrations and their departments and agencies responsible for national and regional E.164 number spaces. To have an ENUM identifier resolve to resources completely independent of the resolution of the corresponding E.164 number strikes us as an opportunity for vast mischief. Again, we have always believed that how (or if) that principle should be implemented is a National Matter on which the IETF should not attempt to take a position. Traditionally, a domain name tree of this type would have been handled entirely within the Internet infrastructure and administrative arrangements. But domains that appear to match E.164 numbers deserve extraordinary treatment, especially when they are expected to be used for telephony-like purposes. >From previous experience, we understood there was a risk of unauthorized parties claiming to be national Administrations with the intent of obtaining authority over subdomains corresponding to the associated country codes. Our desire to involve ITU in this matter was precisely to insert an authoritative mechanism to verify that registration requests, at the level corresponding to country codes, came from authorized parties. Because of this combination of factors, the IAB, and the relevant [working] groups within the IETF, concluded that the needs of all of the communities involved would be best served if, at least until the operational details were worked out in practice, the technical and operational domain name system infrastructure aspects of ENUM were operated by a trusted party under the general supervision of the IAB and that questions of authority, authorization, and authentication of requests that could have impact on national decisions and the use of ENUM within specific countries should be referred to the relevant National Administrations through the ITU. In the subsequent months, two things have happened, the combination of which has largely prevented ENUM trials and deployment from occurring in those countries who believe that they are ready to move forward with it. First, considerable confusion and doubt has arisen about the proposed initial operational procedures and their implications, causing delays for those who want to move ahead and increasing concerns for those who want to take a more carefully managed approach. Second, there has been an unanticipated level of interest from those who want to use ENUM to mount non-conventional services in non-conventional ways, typically without any restrictions or coordination with existing E.164 systems or infrastructure. The IAB wishes to offer its perspective to SG2 on these sets of events and to propose a procedure for removing one of them as a roadblock for those countries who wish to move forward while preserving the rights and perogatives of those who do not.

3. THE ISSUE AREAS

In the ENUM area, there has been a great deal of confusion and misunderstanding: of what has been proposed, of what its implications might be, of the intended boundary between National Matters and decisions and the procedures laid out in the protocols and previously agreed to, in principle, by SG2. There has been an almost equal level of misunderstanding about the range of possible alternatives and their implications. Unfortunately, it appears that some small fraction of these misunderstandings have been deliberately spread by parties whom, we surmise, have concluded that they are unlikely to be able to accomplish their narrow goals by more reasoned and open forms of argument. This type of approach is well-enough known in parts of the Internet and software marketing communities to have been given a name: it is known as the creation of “fear, uncertainty, and doubt”, or FUD. The FUD in the ENUM area has been considerable; we hope to dispel some of it with this liaison statement.

3.1. The Requirement for a Single, Hierarchical System

As with the E.164 system itself (and the DNS more broadly), if users are to have confidence that a particular number will reach the intended party or resource, independent of who is asking the question or where they are asking from, it is necessary to have only one way to access and interpret that number. This does not imply that all E.164 numbers will be accessible from the Internet: the question of whether a given number should be accessible is ultimately a National Matter, as discussed below. While there have been a number of proposals for independent schemes with no central authority or coordination, those schemes either deny the obvious linkage between ENUM identifiers and E.164 numbers (claiming that the former just “look like” telephone numbers and are easy to remember, but that they are completely independent and no one will confuse the two) or assume a different structure in the Domain Name System than it actually uses, based on coordinated national databases, and that would add little or no value for the user of the anticipated services. It is worth noting that ENUM service, and the DNS more generally, only provides a set of mechanisms for translating between an identifier (in the ENUM case, an E.164 number) and Internet address and protocol information. Actual routing of traffic between hosts uses separate mechanisms that are dependent only upon the hosts involved, the ISPs to which they are connected, and the paths and policies available among those ISPs. At the same time, it is important for SG2, and other interested parties, to note that the structure of the Internet provides no practical technical or engineering mechanism that could prevent some company or other entity from creating a domain populated by names formed similarly to ENUM identifiers but in some other part of the DNS tree such as within .com or a specific country code TLD. The references from such names could be set in whatever fashion they find attractive (or profitable). They could create client software that references their piece of the DNS or databases rather than the standardized set of identifiers, and market the whole as an ENUM or “Internet Telephony” system. Any Member State which concludes that such situations would be undesirable should pursue the issue through its own regulatory and legal mechanisms, rather than looking to the IETF, or SG2, for a solution. We note, however, that delays in deployment of ENUM tend to play into the hands of such companies and other entities, since they can promise immediate availability while we deliberate.

3.2. The Boundary Between National Matters and a DNS Top-level Tree.

The intrinsic structure of the DNS provides that an identifier (“DNS name”) consists of a sequence of “labels”, with the top (broadest)-level rightmost. From a technical standpoint, administrative responsibility can be changed at any label boundary (but need not be). In other words, if one has a domain a.b.c.d.e, “e” could be under the direct control of one administrator, “d” under the direct control of another, “b.c” (and hence “c” itself) under the direct control of yet another, and so on. And, of course, other combinations are possible. The administrators in this mechanism are referred to as “registries” in some more recent terminology. And, using that example, the technical DNS term used to describe the boundary between, e.g., “e” and “d” is “delegation from [the administrator of] e to [the administrator of] d”. That terminology is long-entrenched, but has caused additional confusion when people have assumed the term has the same meaning and implications it would in, e.g., an ITU context. This distributed registry system permits the ENUM identifier structure to largely parallel the operational mechanisms associated with E.164. An exact match is not possible without violating the uniqueness principle outlined in section 2.1: in the telephony system, countries can make local decisions about the access and routing codes to be used to reach specific other countries (or numbering plans). Since the DNS can’t tell where, in any geopolitical sense, a query originates from, there is no obvious parallel in ENUM. But the ENUM specfication is organized so that the top-level registry (i.e., the registry for E164.ARPA) will contain _only_ the equivalents of country codes (and only for those countries whose administrations have authorized their inclusion) and the “delegation records” that point to registries designated by those countries and administrations. Under the system as specified, no records that identify either a telephone number, or even a city (area) code, will be held by any entity not under the control of the relevant National Administration. Further, while the IETF has encouraged the development of informational statements about how ENUM might be implemented in the circumstances of different countries, these are not standards or even recommendations. They are merely written demonstrations that there are at least some ways of handling different national arrangements. Whether to select one of those arrangements, or to develop an entirely different one locally, or to decline to participate in ENUM at all, are strictly National Matters.

3.3 The Status of the ARPA Top Level Domain (TLD) and other TLDs

The ARPA domain has been used exclusively for Internet infrastructure purposes since the transition to the domain name system from the earlier ARPANET “host table” system. At the beginning of that transition, all of the ARPANET host names were transferred into that domain and then gradually removed as the organizations that operated them set up their own domains. It still holds other infrastructure, specifically the subdomain structure that permits mapping Internet addresses back into names. Its special role was noted in the original TLD naming system: all of the generic and US government domain names consist of three letters, all of the country code domains are two letters, and ARPA is unique as a four-letter name. The identifer for the TLD was derived from “ARPANET”, not that of the sponsoring US Department of Defense agency. And neither the Department of Defense, nor any of its agencies, have ever used the domain for their internal purposes, e.g., registration of their hosts. They historically controlled the domain only to the extent that they controlled all other TLDs: as sponsor and operator of the early network, they could, in principle, have removed or redesignated the purpose of any top-level domain. The current relationship with the US Government is much the same: the registry for the domain is the IANA, operating under IAB supervision. The Defense Department has formally relinquished any claims on it that they might have had (and that few, even on their staff, believed that they did have). And the domain itself has the same relationship with the US Department of Commerce that any other TLD, including country code TLDs and TLDs which are not country-specific such as .INT, has: in principle, the US Government could order the root operator to make changes against the will of the users of that domain. In the hope of avoiding future confusion and to further identify the infrastructure purpose of the domain, we have begun to identify the domain name as an acronym for “Address and Routing Parameter Area”. Of course, this does not change any of the underlying relationships, which are described above. Just as the ARPA TLD is expected to be reserved for Internet infrastructure, the INT TLD is expected to be used for International treaty organizations, with names of those organizations comprising the second level of the domain. Historically, some infrastructure and experimental second-level domains have been placed into INT, but that practice has stopped, partially at the urging of the ITU General Secretariat, whose staff have argued for many years that use by treaty organizations should be the exclusive use of INT. INT is managed by the IANA, just as ARPA is. But, unlike ARPA, which is formally under IAB supervision, INT management is under close technical supervision by the US Department of Commerce. Many people do not believe that the situation in which the US Government can, in principle, take control of any TLD is an attractive one. But we would encourage SG 2 to avoid taking actions that block deployment of ENUM until that problem is resolved, just as we would encourage countries not to avoid use of the Internet until there was no risk of the US Government capturing their country code domains. In particular, proposals that ENUM be placed as a second-level domain of a TLD under the control of the ITU are, effectively, proposals to delay ENUM deployment for an indefinite period, as there are no TLDs that meet that criterion. And even such a TLD would be, in principle, subject to US Government intervention, just as all other TLDs are.

4. A PROPOSAL

The next steps with ENUM deployment should facilitate the decisions of those countries who want to move forward, while carefully protecting the interests of those who want to adopt a more conservative approach. The RIPE NCC (the IAB-designated Registry) has received a significant number of registration inquiries, from countries around the world. Action on those inquiries has, of necessity, been deferred because ITU has not designated a procedure for handling them. This has been frustrating for countries who want to launch experimental or production applications (i.e., pre-commercial tests and trials, perhaps rapidly transitioning to commercial efforts). We suggest that SG2 consider the following model as a means of going forward:

(i) For the reasons discussed in 2.3 above, reinforced by the concerns about delays mentioned at the end of 2.1, CONCUR in the decision to use E164.ARPA. (ii) ADOPT a procedure in which requests for entry of a country code, and designation of an appropriate registrar entity for that country code, should go to the designated Registry, from the government or Administration involved, using a form to be specified by the Registry. (iii) SPECIFY that, the under that procedure, the Registry would query the ITU (using a mechanism and to an address specified by the ITU, with the TSB acting in this role until and unless other arrangements are made) as to whether the request in fact came from an appropriate authority and whether any other objections can be determined to exist. (iv) Further SPECIFY that, if objections or alternate directions are received from the ITU, or from the relevant country or Administration via the ITU, the request would be frozen until the Registry is notified by the ITU that any issues had been resolved or specifying the corrected registration request information. (v) If no objections are received within a sixty-day period, or if the relevant country, through the ITU, notifies the Registry that it approved of the registration, DIRECT the Registry to complete the registration as approved.

5. SUMMARY

There has been considerable confusion about the ENUM service and its implications. While the initiation of any new service that might have telephony implications should receive due consideration by potentially-impacted parties, the confusion has been exploited by parties variously opposed to deployment of any internet telephony service, to cooperation between IETF and ITU, or to any involvement in these services by governments, Administrations, or numbering plans. Those actions have, in turn, encouraged those who wish to bypass all of these mechanisms in favor of private arrangements subject only to their own, usually corporate, control. This liaison statement proposes a streamlined procedure to SG 2 that permits countries who want to begin working with ENUM within a unified international context to do so, while providing safeguards for both those countries, and those who prefer to delay or adopt other arrangements, against abusive or preemptive behavior by third parties.

Note 1:
Contact: John C Klensin, Chair iab-chair@ietf.org; +1 617 513 7285.

Note 2:
For a discussion of this principle and its importance, see Committee on the Internet in the Evolving Information Infrastructure, Computer Science and Telecommunications Board, National Research Council. _The Internet’s Coming of Age_, Washington, DC, USA: National Academy Press, 2001. Also available online at http://books.nap.edu/books/0309069920/html/index.html.