Internet-Telephony Directory April 2000 Telephone Number Mapping (enum) D. Peek R. Walter D. Ranalli Internet Draft VMA-TWG Document: draft-peek-enum-itd-00.txt> April 2000 Category: Informational Internet-Telephony Directory for Mapping E.164 to Internet Addresses 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 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. 1. Abstract A holistic directory system is described which translates a standard E.164 telephone number into the Internet address information required to support IP-enabled communications applications such as real-time voice, voice-messaging, fax or unified-messaging. The proposed system utilizes two logical control tiers to implement the translation. The first logical control tier is patterned after a Top Level Domain (TLD) of the Internet Domain Name System (DNS). This first-tier provides a mechanism for locating the appropriate directory within the second logical tier of the Internet-Telephony directory system where authoritative Internet address information is stored for a given E.164 number. This first-tier is expected to conform to the regulatory and operational standards defined by the Internet Corporation for the Assignment of Names and Numbers (ICANN) for the operation of top-level domains. The second logical control tier provides a mechanism for accessing and managing authoritative Internet address information associated with an E.164 number. This tier consists of widely distributed DNS servers controlled by service providers, and corporate network operators. Distributed ownership of the second tier directories allows organizations to control the Internet address information associated with the E.164 numbers under their day-to-day control. Peek, Walter, Ranalli Expires - October 2000 1 Internet-Telephony Directory April 2000 Table of Contents 1. Abstract 1 2. Conventions used in this document 3 2.1 Terminology 3 3. Introduction 5 3.1 Overview 5 3.2 Requirements 5 4. System Description 6 4.1 Directory Locator Service (DLS) 6 4.1.1 The E.164 Domain Name Space 7 4.1.2 Multiple Application Support 7 4.1.3 Application Specific E.164 Domain Name Resolution 8 4.2 Authoritative Directory Service (ADS) 9 4.2.1 Resource Record for URI's 9 5. E.164 Domain Name Registration 10 5.1 Background & Scope 10 5.2 List Of Actors 10 5.3 DLS Registration Process 11 6. Application Scenarios 11 6.1 SIP appliction 11 6.2 VPIM application using LDAP 12 6.3 VPIM application without LDAP 12 6.4 Multiple Internet-Telephony service providers 13 7. Security Considerations 13 7.1 DLS Security 13 7.2 ADS Security 13 8. Prevous Work 13 9. References 14 10. Acknowledgments 15 11. Author's Addresses 15 Appendix A. Conflict Resolution Process 16 Full Copyright Statement 17 Peek, Walter, Ranalli Expires - October 2000 2 Internet-Telephony Directory April 2000 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 2.1 Terminology A-record - Address Record; a standard DNS resource record. ADS - Authoritative Directory Service. The second logical control tier of the Internet- Telephony Directory. DLS - Directory Locator Service. The first logical control tier of the Internet-Telephony Directory. DNS - Domain Name System E.164 Number - International telephone number as defined by the ITU E.164/I.331 [13] standard. (e.g. 16033624315) E.164 Subscriber - Corporation or individual that has subscribed to a PSTN service and been assigned one or more associated E.164 numbers. EMA - E-Business Forum (www.ema.org) ENUM - IETF Telephone Number Mapping work group. ITD - Internet-Telephony Directory defined in this Document. ITU - International Telecommunications Union. See www.itu.org. ICANN - Internet Corporation for the Assignment of Names and Numbers (ICANN). IETF - Internet Engineering Task Force(www.ietf.org) Internet Address - General term that provides a simple and extensible means for identifying an Internet resource. Used synonymously with a URI. LDAP - Lightweight Directory Access Protocol; NAPTR-Record - Naming Authority PoinTeR; a standard DNS resource record. NS-record - Name Server record; a standard DNS resource record PSTN Carrier - Telephone company that assigns E.164 numbers to E.164 subscribers. (Corporations or individuals) Peek, Walter, Ranalli Expires - October 2000 3 Internet-Telephony Directory April 2000 Registrant - E.164 subscriber (corporation or individual) that has registered one or more E.164 numbers in the Internet-Telephony directory. SIP _ Session Initiation Protocol; used in establishing a voice over IP call. TXT-Record - Text record; a standard DNS resource record. URI - Uniform Resource Identifier (i.e. sip:joe@acme.com, ldap://server.com) VMA - International Association for Enhanced Voice Services. (www.ivma.ch) VPIM - Voice Profile for Internet Mail Zone - A region of a domain name space that is managed by a DNS name server. Peek, Walter, Ranalli Expires - October 2000 4 Internet-Telephony Directory April 2000 3. Introduction 3.1 Overview This document defines the architecture of an Internet telephony directory system suitable for global deployment. It draws upon information contained in the many previous proposals related to Internet directory services. This document attempts to extract the most useful features of each proposal and meld them into an approach designed to best meet the needs of the entire Internet-Telephony industry. A serious impediment to the development and acceptance of Internet- Telephony services is the different addressing schemes employed by the Public Switched Telephone Network (PSTN) and the Internet. A global directory service that enables the translation of a PSTN telephone number (E.164 number) into a corresponding Internet address eliminates this impediment. The precise nature and structure of such a directory has been the object of considerable speculation, research and discussion. A number of companies and technical groups, including the VMA, EMA, IETF and various organizations within the ITU have made numerous contributions to this effort. Telephone numbers follow a well-defined format governed by the E.164 standard of the International Telecommunications Union (ITU). Therefore, translating a telephone number into an Internet address is a rather straightforward task. However, complexities emerge as the concept is expanded globally and extended to include multiple Internet-Telephony service providers, each providing different services tied to the same E.164 number. Consensus appears to have emerged on at least two key points: - The Internet Domain Name System (DNS) is an excellent technology for the first-tier of the Internet Telephony Directory. - A single-tier system cannot adequately meet the needs of all Internet-Telephony applications. Scalability, operational complexity and information control issues, all mitigate against a single tier model. The system proposed herein utilizes the Internet Domain Name System within a two-tier logical control model to translate an E.164 telephone number into an application specific Internet Address. Please send comments on this document to the ENUM working group or directly to peek@evds.com. Peek, Walter, Ranalli Expires - October 2000 5 Internet-Telephony Directory April 2000 3.2 Requirements The directory solution: 1. MUST be globally accessible. 2. MUST be highly scalable, responsive, and efficient in its use of network resources. 3. MUST be flexible enough to support the addressing requirements of all Internet-Telephony applications. (e.g. Voice messaging, IP-Telephony, Fax, etc.) 4. Must support multiple Internet-Telephony applications per E.164 number that may be provided by different application service providers. (e.g. IP-Centrex from one provider and Unified-Messaging from another application service provider) 4. System Description The system proposed herein utilizes DNS within a two-tier control model to translate an E.164 telephone number into an application specific Internet Address. The first-tier is a "Directory Locator Service" (DLS) that maps an E.164 telephone number into the IP address of a second-tier authoritative directory. The second-tier is an "Authoritative Directory Service" (ADS) that translates an E.164 number into an application specific Internet address. 4.1 Directory Locator Service (DLS) The DLS provides the high-level function of referring a requesting Internet-Telephony application to the Authoritative Directory Service (ADS) containing the desired Internet address information associated with an E.164 number. The DLS is envisioned as a global resource for the entire Internet-Telephony industry and as such, is an ideal candidate for an Internet Domain Name System "Top Level Domain" (TLD). Following conventions observed with all existing top-level domains, (i.e., .com, .net, .org, etc.) the DLS utilizes Name Server (NS) records and associated A records to delegate authority to subordinate Name Servers. This system allows an Internet-Telephony application or platform to iteratively access a hierarchy of DNS name servers until the desired resource record information is found or until the search is exhausted. This process is commonly referred to as "resolution". See RFC1034 [12] for more information. A Directory Locator Service defined as a DNS top-level domain offers several advantages: - A top-level Internet domain is a global resource that operates under a well-defined regulatory and operational structure. - Through the use of standard DNS resolution, a single query is sufficient to locate the desired Internet address information. Peek, Walter, Ranalli Expires - October 2000 6 Internet-Telephony Directory April 2000 4.1.1 The E.164 Domain Name Space The current practice for IETF ENUM working group documents is to use "e164.foo" when referring to top-level domains. This document proposes the creation of a new top-level domain called "tel" as the root domain of the E.164 domain name space. Sub-domains of "tel" may not be arbitrarily defined; rather they are defined in accordance with the ITU E.164/I.331 [14] standard. For simplicity of understanding the context and use of this proposed TLD, the examples in this document utilize the "tel" top-level domain in place of "e164.foo". An E.164 standard [14] telephone number consists of a country code and a nationally specific part. For reasons of scalability, reliability and flexibility, the E.164 domain name space should be partitioned into a number of zones distributed across multiple name servers. The segmentation of an E.164 number into a country code and a nationally specific part, with the latter further segmented by area-code/city-code, presents natural boundaries for such partitioning. 4.1.2 Multiple Application Support One of the key design requirements of the Internet Telephony Directory is the ability to support multiple Internet-Telephony applications using a single E.164 number. For example, a single E.164 number will frequently be used for both real-time voice (SIP/H.323) and voice messaging (VPIM) applications. This multi-application requirement has been addressed in all previous ENUM drafts. The Internet-Telephony Directory system described in this document further advances this concept by enabling various application specific Internet addresses tied to a single E.164 number to be controlled by different service providers. Consider the following scenario: A company wants to use Service Provider-A for an IP-enabled real-time voice service and Service Provider-B for a unified messaging service. Both service providers require control over the Internet address information associated with their respective services. As a result, the requirement exists to distribute control of Internet address information at the application level. Further qualifying a name within the E.164 domain name space through the addition of an application specific prefix or "Service Protocol", fulfills this requirement. The Service Protocol naming conventions associated with various Internet-Telephony applications are subject to standardization. For example, the list of supported Service Protocol names might include: sip or h323 (for voice over IP applications) vpim (for voice messaging service) smtp (for e-mail and unified messaging applications) fax (for IP-fax applications) These example names correspond to several of the service names discussed in the ENUM workgroup. This list will increase as new and different IP-communications services become available. Peek, Walter, Ranalli Expires - October 2000 7 Internet-Telephony Directory April 2000 4.1.3 Application Specific E.164 Domain Name Resolution Internet-Telephony applications query the DLS using a DNS query based on an application specific E.164 domain name. The following steps define its formulation: 1. Start with a complete E.164 telephone number. Example: +1-603-362-4315 2. Remove all characters other than digits. Example: 16033624315 3. Reverse the order of the phone number. Example: 51342633061 4. Insert a "." between each digit and at the end. Example: 5.1.3.4.2.6.3.3.0.6.1. 5. Append, as a suffix, the E.164 top-level domain. Example: 5.1.3.4.2.6.3.3.0.6.1.tel. 6. Append, as a Prefix, a "Service Protocol" name indicative of the desired service. Example: sip.5.1.3.4.2.6.3.3.0.6.1.tel. When a client DNS resolver queries the DLS, the DLS returns the NS- and A-records which define the IP address of the next DNS name server. Upon receipt of the NS and A records from the DLS, the client resolver reissues the query to the newly discovered name server. The following illustrates a sample zone file fragment containing NS and A records: 4.3.2.1.5.9.4.1.6.1.4.4.tel. IN NS ns1.UKSP.tel. IN NS ns2.UKSP.tel. 5.1.3.4.2.6.3.3.0.6.1.tel. IN NS ns1.CompanyA.tel. IN NS ns2.CompanyA.tel. ns1.UKSP.tel. IN A 208.146.45.55 ns2.UKSP.tel. IN A 208.146.45.56 ns1.CompanyA.tel. IN A 208.155.55.55 ns2.CompanyA.tel. IN A 208.155.55.56 Peek, Walter, Ranalli Expires - October 2000 8 Internet-Telephony Directory April 2000 4.2 Authoritative Directory Service (ADS) The ADS provides authoritative Internet address information in support of one or more Internet-Telephony applications associated with a subset of E.164 numbers. The ADS is a delegated DNS name server [12] that must be properly registered with the top-tier DLS. Any E.164 Subscriber (corporation or individual that has been assigned one or more E.164 numbers) may register, deploy and operate an ADS or delegate the function to a third-party service provider. The ADS will return one of the following results based on a query using an application specific E.164 domain name. 1. An end-point address in the form of a URI. For example: Query: sip.5.1.3.4.2.6.3.3.0.6.1.tel Result: sip:user@company.com Query: smtp.5.1.3.4.2.6.3.3.0.6.1.tel Result: mailto:user@company.com 2. A referral to a non-DNS service in the form of a URI. For example, voice messaging applications requiring spoken name will utilize a referral to an LDAP directory: Query: vpim.5.1.3.4.2.6.3.3.0.6.1.tel Result: ldap://ldap.company.com:389/e164=16033624315,dc=tel 3. The NS-records and associated A-records for a delegated ADS that contains the URI for the requested application. This ADS delegation feature enables control over various Internet-Telephony applications tied to the same E.164 number to be delegated out to different service providers. 4. A negative response. Indicates that no Internet address information exists for the specific application queried. 4.2.1 Resource Record for URI's Currently, no standard DNS resource record exists which specifically maps a domain name to a complete URI. However, existing resource records such as the TXT or NAPTR records may be utilized to achieve the desired effect until a new resource record with the specific intent of mapping a domain name to a complete URI is standardized and deployed. The Text (TXT) resource record provides a simple yet effective mechanism for associating an E.164 domain name to a URI. The Domain Implementation and Specification RFC 1035[15] defines TXT records as follows: "TXT RRs are used to hold descriptive text. The semantics of the text depends on the domain where it is found." In the context of the E.164 domain name space, the TXT record is semantically defined as mapping an application specific E.164 domain name to a URI. Both NAPTR and TXT records could be used to implement this solution. Neither is perfect for the task at hand but TXT records have the advantage of being simple, efficient, and Peek, Walter, Ranalli Expires - October 2000 9 Internet-Telephony Directory April 2000 widely supported. The following example zone file fragment demonstrates the utility of TXT resource records. $ORIGIN 2.6.3.3.0.6.1.tel. sip.5.1.3.4 IN TXT sip:dpeek@ServiceProvider2.com smtp.5.1.3.4 IN TXT mailto:dpeek@acme.com vpim.5.1.3.4 IN TXT ldap://ldap.acme.com/e164=16033624315,dc=tel 5. E.164 Domain Name Registration 5.1 Background & Scope The creation and eventual assignment of E.164 numbers to end-user corporations and individuals (E.164 Subscribers) is a well-defined process that exists within the PSTN today. The registration of E.164 numbers in the Internet-Telephony Directory is complimentary to this existing process and takes place only after a number has already been assigned by a PSTN Carrier to an E.164 Subscriber. 5.2 List Of Actors Following the current practice with all Internet top-level domains, the registration of E.164 numbers in the DLS will be managed by a single trusted "Registry". It is assumed that this exclusive Registry function will fall under the regulatory control of ICANN. The actors involved in the registration process are as follows: ICANN: - Internet Corporation for the Assignment of Names and Numbers. - Selects and regulates the exclusive DLS Registry. - Defines pricing for the top-tier regulated DLS service. DLS Registry: - Entity that deploys and operates the globally distributed DLS service under contract from ICANN. - Entity that builds, deploys and maintains a DLS registration service for use by all E.164 Registrants. - Entity that manages the DLS "Conflict Resolution Process". (See Appendix A for Conflict Resolution Process proposal) E.164 Registrant: - E.164 Subscriber or designated representative that registers numbers and an associated ADS in the top-level DLS. - Entity that either operates its own ADS or outsources the function to a third-party provider. (Corporations may choose to operate their own ADS while individuals are likely to outsource the function to a service provider) - Entity that agrees to the terms and conditions of the DLS Registration Agreement as set out by the DLS Registry. Peek, Walter, Ranalli Expires - October 2000 10 Internet-Telephony Directory April 2000 5.3 DLS Registration Process 1. E.164 Registrant deploys an ADS or contracts with a third-party provider of ADS services. 2. Registrant "registers" one or more E.164 numbers and associated ADS via the DLS registration service. 3. Registrant agrees to the terms and conditions of the DLS Registration Agreement as set forth by the Registry under the control of ICANN. 4. DLS Registration service (operated by the Registry) checks the Registrants E.164 numbers against the list of existed registered numbers to determine if a conflict exists. If no conflict exists, the registration is approved. If a conflict exists, the DLS Registry works with the two parties that have both claimed to be the valid E.164 Subscriber for the same number to resolve the conflict. (See Appendix A for a more detailed description of the Conflict Resolution Process) 5. Registrant pays the DLS Registry fees and any associated conflict resolution fees as set forth under the DLS Registration agreement defined by ICANN. 6. DLS Registry makes Registrant name, address, and contact information freely available via an on-line Who-is database. This is a requirement for any top-level domain and an important support feature for the conflict resolution process. 6. Application Scenarios 6.1 SIP Application A SIP application seeking to establish a SIP session formulates an application specific E.164 domain name and issues a single query to the DLS for the associated TXT-record through a standard DNS resolver. Query: sip.5.1.3.4.2.6.3.3.0.6.1.tel. The DLS responds to this query with the NS- and A-records of the appropriate ADS. The DNS resolver, after receiving the NS- and A- records, automatically reissues the identical query to the new name server (ADS). Note that the SIP application is only aware of the first query. The DNS resolver automatically reissues queries through the standard iterative resolution process [12] until the TXT-record information is returned. Result: sip:user@company.com The requesting SIP application now has the Internet-Telephony address information it requires to establish a voice over IP call using the SIP protocol based simply on a telephone number. Peek, Walter, Ranalli Expires - October 2000 11 Internet-Telephony Directory April 2000 6.2 VPIM application using LDAP A VPIM application seeking to send a voicemail message over the Internet formulates an application specific E.164 domain name and issues a single query to the DLS for the associated TXT-record through a standard DNS resolver. Query: vpim.5.1.3.4.2.6.3.3.0.6.1.tel. The DLS responds to this query with the NS- and A-records of the appropriate ADS. The DNS resolver, after receiving the NS- and A- records, automatically reissues the identical query to the new name server (ADS). Note that the VPIM application is only aware of the first query. The DNS resolver automatically reissues queries through the standard iterative resolution process [12] until the TXT-record information is returned. Result: ldap://ldap.acme.com:389/e164=16033624315,dc=tel Using the LDAP URI, the VPIM application queries the LDAP directory to retrieve a VPIM address and "spoken name" via the standard VPIM schema [4]. Note, the LDAP directory is used in this scenario to retrieve an audio representation of the destination party's name that cannot be easily stored in a DNS directory. 6.3 VPIM application without LDAP LDAP is clearly the technology of choice to manage and store complex VPIM user information such as spoken-name, audio encoding types, and other VPIM related address. However, the installed base of LDAP servers is limited at present and their increased operational complexity may inhibit some organizations from deploying enhanced VPIM services. For organizations that are not prepared to operate an LDAP directory, the ADS can be provisioned to return VPIM mailbox addresses in the form of a mailto URI. For example: Query: vpim.5.1.3.4.2.6.3.3.0.6.1.tel. Result: mailto:610002@sprovider.net By returning a mailto URI the organization forfeits the ability to supply spoken-name and other enhanced capabilities to querying VPIM applications. Peek, Walter, Ranalli Expires - October 2000 12 Internet-Telephony Directory April 2000 6.4 Multiple Internet-Telephony service providers A company wants to use Service Provider-1 (SP1) for an IP-enabled real-time voice service and Service Provider-2 (SP2) for a unified messaging service. Both service providers require control over the Internet address information associated with their respective services. As a result, the requirement exists to distribute control of Internet address information at the application level. To achieve this objective the Company utilizes the inherent delegation capabilities of the ADS and provisions its application specific E.164 domain names to reference the appropriate service provider: sip.0.0.0.5.2.6.3.3.0.6.1.tel IN NS ns.SP1.tel vpim.2.0.0.5.2.6.3.3.0.6.1.tel IN NS ns.SP2.tel ns.SP1.tel IN A 208.150.79.113 ns.SP2.tel IN A 78.21.79.114 7. Security Considerations 7.1 DLS Security All data stored in the DLS is considered public Internet-Telephony information and may be retrieved by any requesting Internet- Telephony application. 7.2 ADS Security All data stored in the ADS is considered public Internet-Telephony information that may be retrieved by any requesting Internet- Telephony application. 8. Previous Work Many of the concepts outlined in this document are drawn from two years of direct experience associated with implementing a directory service in support of the voice messaging industry initiative called the "Global Voice Mail Service" or GVMS. The International Association for Enhanced Voice Service (formerly the Voice Mail Association or VMA) created and began funding the GVMS initiative in early 1997. The goal of the GVMS initiative has been to connect service provider and enterprise voicemail platforms on a worldwide basis via the Internet. Key functionality demonstrated through the GVMS initiative included the ability for end-users to send voice messages or reply to voice messages over the Internet without incurring the long distance charges associated with placing a return telephone call. Eight leading voicemail vendors participated in creating the GVMS solution that was demonstrated at VMA conferences in Athens (98), Helsinki (99) and at Telecom 99 in Geneva. The vendors include Comverse, Brite, Glenayre, Lucent, Nortel, Tecnomen, Alcatel, and UNISYS. NetNumber.com, Inc. (formerly EVDS) provided the global directory service supporting the GVMS demonstrations. Peek, Walter, Ranalli Expires - October 2000 13 Internet-Telephony Directory April 2000 9. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14,RFC 2119, March 1997 [3] Faltstrom, P., "E.164 and DNS", Work in progress, ,January 2000 [4] Brown, A., "E.164 Resolution", Work in progress, , October 1999 [5] Brown, A., "Enum Requirements", Work in progress, , NOvember 1999 [6] Vaudreuil, G., "Voice Messaging Directory; Address Resolution Services", Work in progress, , December 1999 [7] Vaudreuil, G., "Address Validation Service", Work in progress, , December 1999 [8] Vaudreuil, G., "Telephone Number Base Directory Service", Work in progress, , March 2000 [9] Shockey, R., "The Use of DNS based E.164 Resolution Services by Internet Fax", Work in progress, , December 1999 [10] Berners-Lee, T., "Uniform Resource Identifiers (URI): Generic Syntax", Standards Track, RFC 2396, August 1998 [11] Daniel, R., Mealing, M, "Resolution of Uniform Resource Identifiers using the Domain Name System", Experimental, RFC 2168, June 1997 [12] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [13] ITU-T Rec, "The International Public Telecommunication Numbering Plan", Recommendation, ITU-T Rec. E.164/I.331 , May 1997. Peek, Walter, Ranalli Expires - October 2000 14 Internet-Telephony Directory April 2000 10. Acknowledgments Our special thanks to Dr. Thomas P. Sosnowski for his help in editing this document. Also thanks to Chuck Santos for providing us with many technical details. We would also like to recognize Anne Brown, Greg Vandreuil, and Patrik Falstrom for their previous work in this area. Thanks also to Michael Mealling for providing us with details on NAPTR records. 11. Author's Addresses David P. Peek VMA, Technical Working Group Chairman 13 Village Drive Atkinson, NH 03811 Phone: 1-603-362-4315 Email: peek@evds.com Robert Walter NetNumber.com, VP Development & Operations Wannilancit Technology Center 650 Suffolk Street, Suite 307 Lowell, MA 01854 rwalter@netnumber.com Douglas Ranalli NetNumber.com, President/CEO Wannilancit Technology Center 650 Suffolk Street, Suite 307 Lowell, MA 01854 dranalli@netnumber.com Peek, Walter, Ranalli Expires - October 2000 15 Internet-Telephony Directory April 2000 Appendix A: Conflict Resolution Process: Conflict over the registration of numbers in the top-level DLS could occur for one of three general reasons: - Data Entry Error: E.164 Registrant makes a data entry error during the DLS registration process and inadvertently registers a wrong number. - Old Data Error: E.164 Registrant returns day-to-day control over one or more numbers to the originating PSTN carrier but fails to update the DLS registration records. Example: A corporation shuts down an office, terminates its phone service but fails to un-register the numbers in the DLS. - Intentional Error: E.164 Registrant intentionally claims to be the E.164 Subscriber that has day to day control over a number when in fact they are not. Conflict occurs when two Registrants both claim to be the valid E.164 Subscriber for the same number. Conflict over ownership of a name or number in the Internet naming space is not a new problem. In the domain name space conflict occurs when one entity registers a name like "McDonalds" in a top-level-domain (mcdonalds.com) and then another entity claims trademark control over the name "McDonalds". In the case of the E.164 domain name space, conflict can be easily resolved because it is clear how the day-to-day control of a number is defined: - PSTN Service Provider Control: A PSTN Service Provider (telephone company) that has registered an E.164 number in the Internet-Telephony directory on behalf of a customer can certainly validate the identity of the E.164 Subscriber. - E.164 Subscriber Control: A corporation or individual that has been assigned a number through the normal PSTN provisioning process is the E.164 Subscriber and is the only valid Registrant for that number. Confirmation of such assignment can be obtained through reviewing PSTN billing records. Conflict is identified when an entity attempts to register a number that has already been registered by another E.164 Registrant. The burden of maintaining a system for resolving conflict in an orderly process falls on the DLS Registry. A process might operate under the following principles: - Cost of resolution should be born by the mistaken party: It seems reasonable to expect E.164 Registrants to take responsibility for their own mistakes. If the DLS Registry is required to take action to correct a registration mistake made by a Registrant then the mistaken party should pay the direct costs associated with the resolution process. The terms of such a process can be outlined in the DLS Registration Agreement signed by each E.164 Registrant. Peek, Walter, Ranalli Expires - October 2000 16 Internet-Telephony Directory April 2000 - Cost of conflict resolution should be zero: In most cases, conflict will be the result of a simple human error. Registrants that make a data entry mistake should be given an opportunity to correct the mistake at zero cost. An on-line system can easily be maintained by the DLS Registry to identify conflicts, notify the appropriate Registrant, and enable on- line corrections. In the event that the entire process can be managed via an automated on-line process and resolved in a reasonable period of time then the cost to all parties should be zero. - Billing records can be used to clarify difficult conflicts: In the most difficult case where two entities claim control over a number and the conflict cannot be resolved through an automated system, billing records can be used to clarify day to day control over a number. Extended conflict like this is likely to be rare, particularly in light of the provision that the mistaken party is required to pay the direct cost of conflict resolution under this model. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Peek, Walter, Ranalli Expires - October 2000 17