Internet Draft Penn Pfautz Document: AT&T Category: Informational James Yu NeuStar, Inc. October 2000 ENUM Administrative Process in the U.S.A. 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. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Expires March 2001 1 ENUM Administrative Process in the U.S.A. October 2000 Abstract This document considers administrative processes for ENUM in the U.S.A. and offers two "strawman" proposals in the spirit of moving forward the work that must be done to implement a useful ENUM capability. The U.S.A. has implemented number portability; therefore, it is the telephony user that controls the assigned telephone number so long as it maintains the telephony service. While the proposed processes are tailored for the U.S.A. they may be appropriate for use by other countries that implement number portability so that the donor telephony service provider (e.g., the telephony service provider that is assigned a block of telephony numbers before any number porting event happens from that number block) is not relied on for maintaining the delegation information for a telephone number (e.g., the Tier 1 function in the ENUM process). The ENUM administrative process is a critical piece in making the ENUM process operational. The administrative process involves several entities. A telephony user's identity and his/her ownership of a telephone number must be validated before ENUM service can be granted. Therefore, the telephony user's telephony service provider plays an important and sometimes necessary role in making the ENUM administrative process successful. This document discusses two reference models. The telephony service provider is the Tier 2 Entity or Service Registrar in Reference Model II but is not necessarily the Tier 2 Entity in Reference Model I. The information flows associated with these two reference models are described to show the interactions among the involved entities and the functions to be performed by each involved entity. The industry and regulators will decide which reference model is to be used and the future revisions of this document will reflect that decision along with any enhancement to the information flows. 1. Introduction This document discusses the ENUM [2,3,4] administrative process in the U.S.A. The U.S.A. has implemented number portability [5,6]; therefore, it is the telephony user that controls the assigned telephone number so long as it maintains the telephony service. The proposed process is tailored for the U.S.A. so that the donor telephony service provider (i.e., the telephony service provider that is assigned a block of telephony numbers before any number porting event happens from that number block) is not relied on for maintaining the delegation information for a TN (i.e., the Tier 1 function in the ENUM process). Much of what is proposed would be applicable to other areas and for telephone numbers that are shared by regional or international community such as the +881 and +878 numbers. Provisioning of ENUM is complex because it combines elements of the domain name registration process (after all it is a domain name that is being registered) and the preferred carrier selection process (Preferred Inter-exchange Carrier or PIC in the U.S.A.) because particular providers are being selected to provide services to the holder of the domain name identified by the telephone number. It is essential to develop an administrative process that is operationally efficient, provides adequate Informational - Expires March 2001 2 ENUM Administrative Process in the U.S.A. October 2000 authentication of requests and at the same time is not burdensome for the end user of the telephone number. Two reference models for ENUM administration are considered: one in which the end user can select which Tier 2 Entity (T2E) to use for its assigned TN (Reference Model I) and another in which the EU's Telephony Service Provider (TSP) is the T2E (Reference Model II). Both models assume that a "Tier 1 Entity (T1E)" has been chartered by national (or, multi-national in the case of the North American Numbering Plan (NANP)[7]) authorities to provide the Domain Name System (DNS) service for the .e164.arpa domain (1.e164.arpa for NANP) and that this entity provisions zones of authority for each telephone number (TN) that point to the correct service registrar for the telephone number. The service registrar's DNS in turn holds the Naming Authority Pointer (NAPTR)[8] records for the TN. 2. Terminology and Abbreviations ASP Application Service Provider, a service provider that provides applications such as e-mail, or voice messaging to an EU that is assigned with a TN. DNS Domain Name System ENUM Telephone Number URI mapping EU End User, a person or entity that is assigned a telephone number. The EU plays the role similar to the "registrant." HLR Home Location Register ICANN Internet Corporation for Assigned Names and Numbers ID Identity or Identification ISP Internet Service Provider LERG Local Exchange Routing Guide NANP North American Numbering Plan NAPTR Naming Authority Pointer NPAC Number Portability Administration Center PIC Preferred Inter-exchange Carrier RR Resource Record SIP Session Initiation Protocol SMS Service Management System SMS-MC Short Message Service Message Center T1E Tier 1 Entity, the entity that has a pointer to the Tier 2 Entity for each served TN. The T1E plays a role similar to Informational - Expires March 2001 3 ENUM Administrative Process in the U.S.A. October 2000 the "registry." [do we need a citation about registry - registrar?] T2E Tier 2 Entity, the entity that has all the NAPTR RRs associated with each served TN. The T2E plays the role similar to the "registrar." T3E Tier 3 Entity, the entity that provides the service- specific directory services for retrieving additional information for services related to a TN. TN Telephone number, an E.164 number in the national or international numbering plan. TSP Telephony Service Provider, the telephony service provider that provides telephony and related services to a TN. VLR Visitor Location Register URI Uniform Resource Identifier URL Uniform Resource Locator 3. Reference Models This section discusses two reference models that show the entities and the interfaces among them that are involved in the ENUM administrative process. The assumptions are first described below before the discussion of the reference models. 3.1. Assumptions Some assumptions are made so as to describe the proposed ENUM administrative process in a controlled manner. Those assumptions are made based on the objectives to have an efficient and effective and a user-friendly administrative process. They are shown below. The assumptions apply to both Reference Models I and II unless specifically indicated. - One Tier 1 Entity (T1E) handles 1.enum.arpa. and points each served Telephone Number (TN) to a T2E. - All NAPTR records for a given TN must be stored in a single Tier 2 entity's name server. - Not every TN has a record or records at the T1E. - The EU can use the ENUM service as a personal number service and can subscribe to many application services (e.g., e-mail and voice mail) from various ASPs including his/her TSP. - The TSP of an EU may use the ENUM service for network-related services. Some of those network-related services use TNs that are not assigned to the EUs. For example, the ENUM process can be used to identify the wireless network element such as the Home Location Register (HLR) or Visitor Location Register (VLR) by using TNs not assigned to the EUs[9]. Other network-related services may use TNs that are assigned to the EUs. For example, ENUM process can be used to identify the wireless Short Message Informational - Expires March 2001 4 ENUM Administrative Process in the U.S.A. October 2000 Service Message Center (SMS-MC) when a short message is addressed to a wireless subscriber's TN. - The TSP may offer application services to the EUs. For those application services, the TSP is no different from the ASPs that can offer the same applications services to the EUs. The TSP will be treated as the ASPs for those EUs' application services. - The EU decides which Tier 2 Entity (T2E) to use for its assigned TN (Reference Model I) or the EU's Telephony Service Provider (TSP) is the T2E (Reference Model II). - The mention of the entity such as T1E or T2E in this document sometimes means the entity that offers a specific functionality (e.g., T1E) and other times refers to the domain name servers (e.g., can be two or more) operated by that particular entity. - The EU has authority over provisioning of the Naming Authority Pointer (NAPTR) Resource Records (RRs) at the T2E for his/her application services, but in most instances may not provide the NAPTR RRs to the T2E directly, but rather authorize the T2E and various ASPs to provision the records. The TSP has authority over provisioning of the NAPTR RRs at the T2E for the network- related services in Reference Model I. The T2E must control the access right to the NAPTRs so that the TSP and ASPs can only provision/access/change their own NAPTR RRs. - The NAPTR RRs for the EU's application services and the TSP's network-related services can be easily differentiated (e.g., via the "service" field of the NAPTR RR). - For a TN that is not assigned to any EU, the TSP that controls that TN can be viewed as the EU for that TN. - In Reference Model I, if the TSP uses ENUM for network-related services, the TSP may designate a T2E, called "TSP's default T2E," to hold these network-related NAPTR RRs if the EU has not opted to make use of ENUM services. When an EU does decide to make use of ENUM services and chooses a T2E different than the TSP's default T2E, the EU's chosen T2E will become the new T2E and will retrieve the TSP's NAPTR RRs from the TSP's default T2E. When the EU stops using the ENUM service and the T2E informs the T1E to remove the pointer to it for that TN, the T1E will point to the TSP's default T2E for that TN. - The T1E knows the TSP for each TN and knows when a number porting takes place through information from the Number Portability Administration Center (NPAC)[10]. - In reference model 1, the EU can change the T2E without informing the current serving T2E (the old T2E). The new T2E may inform the old T2E and will inform the T1E about the T2E change for the TN. The T1E will confirm the change with the old T2E and inform the new T2E about the confirmation. After retrieving the NAPTR RRs for the TN from the old T2E, the new T2E informs the T1E to make the T2E change in effect. This process is similar to the change of the TSP through the NPAC and the change of registrar through the registry. - The TSP may need to confirm the TN assignment to an EU when requested by the T1E and/or T2E. The need for this action from Informational - Expires March 2001 5 ENUM Administrative Process in the U.S.A. October 2000 the TSP depends on whether the T1E or T2E can get the information from other sources. - The EU loses his/her right to the assigned TN and ENUM services when he/she disconnects the telephony service. - The TSP informs the T1E when the EU disconnects the telephony service in a timely manner. - An EU can be assigned one TN or a set of TNs. The administrative process will be designed to handle individual TN or set of TNs for an EU. In the discussion of information flows, only single TN is addressed. Two reference models are discussed next. Reference Model I assumes that the T2E is not necessarily the TSP. Reference Model II assumes that the TSP must be the T2E. The former gives the EU more control of who the service registrar (T2E) is. The latter is a subset of the former, and it simplifies the process because the TSP's necessary role (e.g., verifying the ownership of a TN) in certain situations and because fewer entities are involved in the process. 3.1. Reference Model I (TSP =/= T2E) Figure 1 shows Reference Model I where all the entities involved can be logically different. The EU decides which T2E to be his/her service registrar. The T2E can be physically operated by the EU itself, its TSP, its Internet Service Provider (ISP), or a third-party entity designated by the EU. The T2E may need to be a certified entity (e.g., by a trusted certificate authority or by Internet Corporation for Assigned Names and Numbers (ICANN)) to play the T2E role. +-----+ H +-----+ +-----| T1E | +------| T2E | | +-----+ | +-----+ | | | | A+ +-------+ | | | | +-----+ B +----+ | | T2E |------+------| EU | | +-----+ +---------+----+ | | | | | C+ F+ | | G +E | | +----|--+-----+ | | | | | | | +-----+ +D +-----+ +-----| TSP |---+ | ASP | +-----+ +-----+ Figure 1. Reference Model I Interface A is used by the new T2E to indicate the T2E change to the T1E or by the T2E to provision its RRs (e.g., change the DNS RRs) at the T1E for a TN, and by the T1E to inform the old T2E when the EU changes to a new T2E, and the new T2E about the old Informational - Expires March 2001 6 ENUM Administrative Process in the U.S.A. October 2000 T2E, and to acknowledge the new T2E request for a T2E change for a TN. Interface B is used by the EU to request ENUM service from a T2E, provision/access/change information in his/her NAPTR RRs at the T2E, and authorize his/her ASPs for the access right to their respective NAPTR RRs at the T2E for a specific TN that is assigned to the EU. Interface C is used by the TSP to inform the T1E about termination of the telephony service and its default T2E for the network- related services for a TN and by the T1E to inform the TSP about the change of the T2E. It may be used by the T1E to verify the ownership of a TN and whether a TN is a working TN assigned to an EU, or by the TSP. Interface D is used (since TSP acts as the ASP for EU's application services, that part is covered by interface E) by the EU to request a TN assignment for the telephony service, to terminate the telephony service, to subscribe, change or terminate application services from the TSP. Interface E is used by the ASP to provide its NAPTR RRs or the application service related information (e.g., e-mail or SIP address) to the EU or to request the EU to authorize it to provision/access/change its NAPTR RRs at the T2E, and by the EU to subscribe, change or terminate application services from the ASP or discuss matters related to the EU's account. Interface F is used by the TSP to provision/access/change the NAPTR RRs associated with the network-related services for a TN at the T2E. It may be used by the T2E to verify the ownership of a TN and by the TSP to inform the T2E about the telephony service disconnection for a TN. Interface G may be used by the ASP to provision/access/change the NAPTR RRs associated with the application services for a TN at the T2E if the EU gives it the authorization to do so. This includes the termination of a specific application service for a TN. Interface H is used between the old T2E and the new T2E to resolve disputes about the T2E change. Interfaces A, B and C are to be defined and supported. The other interfaces are subject to the entities that are involved. For example, a T2E can provide a web based graphic user interface for the EU and possibly the TSP or ASP to interact with it. 3.2. Reference Model II (TSP = T2E) Figure 2 shows Reference Model II that is a special case of Reference Model I where TSP and T2E are one entity. It can be clearly seen that Interfaces A and C in Reference Model I are combined into Interface A', Interfaces B and D in Reference Model I are combined into Interface B', Interface E in Reference Model I becomes Interface C', Interface G in Reference Model I becomes Interface D', Interface F in Reference Model I becomes an internal interface within TSP/T2E, and Interface H in Reference Model becomes Interface E'. Informational - Expires March 2001 7 ENUM Administrative Process in the U.S.A. October 2000 +-----+ | T1E | +-----+ | +A' | +---------+ B' +----+ | TSP/T2E |------+------| EU | +---------+ +----+ | | +E' +C' | | | | +---------+ D' +-----+ | TSP/T2E |-------+-----| ASP | +---------+ +-----+ Figure 2. Reference Model II Under this model the T2E for a TN must be the TSP that currently provides the telephony service to the TN. The EU's current serving TSP certainly is not required to offer T2E functionality and, if it does not, the TN cannot have ENUM-based services. The EU can, of course, port his/her TN to another TSP if his/her current serving TSP does not provide T2E services or does so in a manner or for a price the EU judges unsatisfactory. The TSP may charge the EU for being a T2E. Because the TSP already has a service relationship with the EU, it should be easier for the TSP to verify both the EU's identity and the ownership of the TN to authenticate the provisioning request. The TSP is also presumed to have a trusted relationship to the T1E that can verify the TSP's control of the TN through the Local Exchange Routing Guide (LERG)[11] and NPAC. Although the T2E must be the current TSP for a TN, the EU can authorize any ASP to provide an ENUM-based application service for the TN. The ASP obtains authorization to provide a specific service for the EU's TN and submits this authorization to the TSP/T2E. The ASP can then work directly with the TSP/T2E to provision the NAPTR records at the TSP/T2E. 4. Information Flows This section describes the information flows for several scenarios to show how the entities in the reference model interact during the ENUM administration process. Section 4.1 covers those scenarios based on Reference Model I, and Section 4.2 covers those scenarios based on Reference Model II. Those cases based on Reference Model I begin with Case Ix, and those based on Reference Model II begin with Case IIx. Only the successful scenarios are discussed for the proposed administrative process. After the reference model and basic concept of operation are agreed, the failure scenarios then can be identified and discussed. Informational - Expires March 2001 8 ENUM Administrative Process in the U.S.A. October 2000 The processes of verifying the EU's identity and EU's ownership of the TN by the T2E, verifying the TSP's or ASP's identity and rights of provisioning/accessing/ changing the NAPTR RRs at the T2E by the T2E, or verifying the T2E's identity by the T1E, are not detailed or not shown in this section to simplify the explanation. The authentication aspect is discussed in Section 5. 4.1. Reference Model I (TSP =/= T2E) Case IA. Initial ENUM service request by the End User This case happens when the EU approaches a T2E for ENUM service. The EU may initiate the service request due to his/her need for ENUM service, or at the request of his/her TSP or ASP for some application services. 1. The EU requests a T2E to host the NAPTR RRs for his/her TN. 2. The T2E verifies the EU's identity and the ownership of the TN, accepts the service request and collects information from the EU. 3. There are several ways of provisioning the NAPTR RRs associated with the EU's application services at the T2E. 3a. The EU provides all the necessary information to the T2E based on the information (e.g., voice-mail address and e-mail address) received from its TSP and ASPs. The EU can provide the exact NAPTR RRs or some application address information that is converted by the T2E to the NAPTR RRs. This case, where the ASP must go through the EU to make changes to the NAPTR RRs at the T2E for the EU's TN, may be burdensome and error prone for many EUs. 3b. The EU gives the authorization to the T2E for his/her ASPs to provision/access/change the RRs at the T2E. The ASP then provisions the NAPTR RRs at the T2E for a TN. The TSP is authorized to provision the NAPTR RRs associated with network-related services. The T2E will verify and allow the TSP or ASP to provision only those NAPTR RRs it is authorized. The EU may pass the information that is unique to the TSP or ASP so that the T2E can authenticate the TSP or ASP when it interacts with the T2E, or the T2E can provide some information (e.g., user ID and password) to be passed to the TSP or ASP by the EU. 3c. The EU provides all the necessary information to the T2E based on the information received from its ASPs and gives the authorization to the T2E for his/her ASPs and TSP to provision/access/change the RRs at the T2E. 3d. The EU may give the authorization to the T2E for some of his/her ASPs to provision NAPTR records for the applications services they provide. In that case, information at the T2E for those services without the EU's authorization must go through the EU to make changes. 4. Since the T2E has not already provisioned this TN at the T1E, it requests that the T1E provision the TN with proper DNS RRs pointing to the T2E. 5a. If the EU's TSP has provided the default T2E information to the T1E (e.g., for using the ENUM services for the TSP's network-related services), the T1E informs the TSP about the new EU-selected T2E, confirms the provisioning request with the EU-selected T2E and informs the EU-selected T2E about the TSP's default T2E. The EU-selected T2E then retrieves the Informational - Expires March 2001 9 ENUM Administrative Process in the U.S.A. October 2000 NAPTR RRs that are associated with the TN from the TSP's default T2E. 5b. If the T1E does not have information about the TSP's default T2E (e.g., the TSP has no use of the ENUM services for its network-related services), it sends an acknowledgement to the new EU selected T2E. 6. The T1E creates the proper DNS RRs for the TN to point to the new EU selected T2E. The TSP may have a need to use the ENUM service for some application services for TNs not assigned to the EUs. In that case, the TSP acts as the EU in terms of selecting the T2E for that TN and giving the authorization to itself to provision/access/change the NAPTR RRs at the T2E. The TSP can be the T2E in this case or can use a third party as the T2E. No ASP will be involved in this case for those TNs. Case IB. Initial ENUM service request by the Telephony Service Provider for the network-related services This case happens when the TSP wants to use the ENUM services for network-related services for a TN. 1. The TSP contacts the T1E requesting ENUM for network-related services for a TN. 2. The T1E accepts and stores the default T2E provided by the TSP. 3. There are two possibilities depending on whether the EU has been using the ENUM services or not. 3a. If the T1E has no pointer to an EU-selected T2E for that TN, it adds proper DNS RRs to point to the TSP's default T2E for that TN. 3b. If the T1E has a pointer to an EU-selected T2E for that TN, it informs the TSP about the EU-selected T2E. The TSP then interacts with the EU-selected T2E to provision those NAPTR RRs associated with the TSP's network-related services. Or the T1E can inform the EU-selected T2E about the TSP's default T2E so that the EU-selected T2E can retrieve the NAPTR RRs from the TSP's default T2E. The TSP can interact with the T1E later to change the default T2E information. It is expected that the TSP will store the NAPTR RRs associated with its network-related services for a TN on a T2E so that the same T2E can host the NAPTR RRs for the EU's application services for the same TN when the EU selects the TSP for the T2E service. Having the NAPTR RRs associated with the network-related services for a TN stored on a default T2E even when there is an EU-selected T2E allows the T1E to quickly point to the TSP's default T2E when the EU stops using the ENUM service. Case IC. End User changes Tier 2 Entity This case happens when the EU decides to use another T2E for the ENUM service. There may or may not be any changes in the TSP or any of the ASPs. To simplify the scenario, it is assumed that no NAPTR RR is changed due to this move. If there are changes, the new T2E needs to work with the EU and EU's ASPs to create the correct NAPTR RRs. Informational - Expires March 2001 10 ENUM Administrative Process in the U.S.A. October 2000 1. The EU requests a T2E (the new T2E) to host the NAPTR RRs for his/her TN and indicates that all the NAPTR RRs stored at the old T2E (the old T2E) are still valid. 2. The T2E verifies the EU's identity and the ownership of the TN, accepts the service request and collects information from the EU. The new T2E may notify the old T2E of the EU's request. 3. The new T2E requests that the T1E provision the TN with proper DNS RRs pointing to it. 4. The T1E informs the old T2E about the T2E change for that TN. 5. The old T2E confirms the T2E change. 6. The T1E acknowledges the change with the new T2E and informs the new T2E about the old T2E. 7. The new T2E retrieves the NAPTR RRs (related to EU's application services and TSP's network-related services) from the old T2E. 8. The new T2E informs the T1E to make the T2E change in effect. 9. The T1E creates the proper DNS RRs for the TN to point to the new T2E. It is possible that the old T2E can dispute the T2E change for a TN. The T1E will not change the pointer to the new T2E unless the dispute is resolved or if the T2E fails to respond to the T1E within a specified time period. Case ID. End User disconnects telephony service on a telephone number This case happens when the EU decides to disconnect his/her telephony service (e.g., move to a new city) or his/her TSP disconnects his/her telephony service due to reasons such as non- payment. 1. The EU's telephony service is disconnected. 2. The TSP informs the T1E about the telephony service disconnection for a TN. The T1E relays that information to the EU-selected T2E if applicable. 3a. If the EU's TSP has provided the default T2E information to the T1E, the T1E changes the DNS RRs for that TN to point to the TSP's default T2E and informs the TSP about the T2E switch for that TN. 3b. If the T1E does not have information about the TSP's default T2E, it removes the DNS RRs for that TN. Case IE. Tier 2 Entity changes information at Tier 1 Entity This case happens when the T2E needs to change the information such as the DNS RRs or contact person information at the T1E. The T2E interacts with the T1E to make the necessary changes. Case IF. End User changes Telephony Service Provider This case happens when the EU changes from one TSP to another. The processes vary depending on whether the old serving TSP or new serving TSP uses the ENUM services for network-related services or whether the EU uses the ENUM services. The T1E will be informed of such a TSP change via the NPAC and must synchronize the TSP change with the NPAC process. The exact time to remove the old serving TSP's NAPTR RRs or to add the new serving TSP's NAPTR RRs at the T2E or to point to the new serving TSP's default T2E are not specifically addressed to simplify the description. The change of the TSP does not impact the pointer to the current Informational - Expires March 2001 11 ENUM Administrative Process in the U.S.A. October 2000 serving T2E for a TN at the T1E if the old TSP is not the T2E for that IN. This scenario assumes that is the case. 1. If the new serving TSP has the use of the ENUM services for the network-related services, it follows the process described in Case IB to inform the T1E about its default T2E information and to provision its NAPTR RRs at the T2E. The T2E will swap the NAPTR RRs from the new TSP when it is informed by the T1E to make that switch. 2a. If the EU has no use of ENUM services, the T1E creates the DNS RRs for the TN pointing to the new serving TSP's default T2E. If the old serving TSP has provided the default T2E information, that information at the T1E would be replaced by the new serving TSP's default T2E. The process ends here. 2b. If the EU has selected a T2E, the T1E informs the EU- selected T2E about the TSP change so that the T2E can allow the new TSP to provision its NAPTR RRs. The T2E will swap the NAPTR RRs from the new TSP when it is informed by the T1E to make that switch. The process ends here. 3. If the new serving TSP has no use of the ENUM services for the network-related services for the TN, the old serving TSP has the use of the ENUM services, and the EU has selected a T2E, the T1E, synchronized with the NPAC process, instructs the EU-selected T2E to remove all the NAPTR RRs associated with the network-related services and removes the stored default T2E information provided by the old serving TSP for the TN. 4. If the new serving TSP has no use of the ENUM services for the network-related services, the old serving TSP has the use of the ENUM services, and the EU has no use of the ENUM services, the T1E, synchronized with the NPAC process, removes the stored default T2E information provided by the old serving TSP for the TN. 5. If both the old and new serving TSPs have no use of the ENUM services for the network-related services for the TN and the EU has selected a T2E, the T1E takes no action. Cases IG to IK. Changing information at Tier 2 Entity In many cases the information at the T2E such as the NAPTR RRs or the TSP or ASP that has the authorization to provision/access/ change the information for specific service or services needs to be changed. Each distinct occasion is separately described below although some or all of them may be completed in one session. Since the T2E may store the NAPTR RRs associated with EU's applications services and/or TSP's network-related services for a TN and the TSP can act as an ASP for some application services provided to that TN, the T2E must control the access right to a particular NAPTR RR that is stored at the T2E. The EU should be authorized to provision/access/change all the NAPTR RRs associated with the application services for a TN assigned to him/her. The TSP or ASP, if authorized by the EU, should be able to provision/ access/change all the NAPTR RRs associated with the application services it offers to the EU's TN. The ASPs may not be allowed to change the "order" and "preference" fields of the NAPTR RRs. The EU may need to change personal information (e.g., address) that does not impact the NAPTR RRs or the authorization of the TSP or ASPs at the T2E. If authorized by the EU, the TSP or ASPs also may need to change the private information (e.g., contact Informational - Expires March 2001 12 ENUM Administrative Process in the U.S.A. October 2000 person's phone number) at the T2E. Those cases are obvious and are not included here. But the protocols should be designed to allow those cases to proceed properly. Case IG. End User changes Application Service Provider This case happens when the EU decides to change his/her ASP for an application service. If the EU authorizes the TSP or ASP to interact with the T2E, that authorization needs to be transferred to the new ASP for the associated application service. 1a. If the EU performs the provisioning/modification for that particular service or set of services, he/she first gets the information from the new ASP and interacts with the T2E to provide the changes to the NAPTR RRs related to that particular service or set of services for his/her TN. 1b. If the EU authorizes the ASP for provisioning/ accessing/changing the information for his/her TN, he/she informs the T2E about the change of authorization from the old ASP to the new ASP for a specific service or set of services for his/her TN. 1c. If the EU has the information from his/her new ASP, he/she can make the necessary changes to the NAPTR RRs related to the specific service or set of services during the same session with the T2E. 2. The T2E makes the necessary changes to the information related to the TN. 3. The TSP or ASP, if authorized by the EU, can interact with the T2E to provision/access/change the information related to application service or services for the TN. Case IH. End User terminates an application service This case happens when the EU terminates an application service (i.e., not a telephony service) that is provided by an ASP. 1. The EU informs the ASP to terminate an application service. 2. There are several possible ways that the T2E can be informed about such a service termination. 2a. If the EU does not authorize the ASP to interact with the T2E for his/her TN, the EU must interact with the T2E to remove the NAPTR RRs associated with that particular application service. 2b. If the EU does authorize the ASP to interact with the T2E for his/her TN or set of TNs for the terminated application service, either the EU or ASP can interact with the T2E to remove the NAPTR RRs associated with that particular application service. If the ASP interacts with the T2E after the EU has interacted with the T2E, its authorization for that service for the TN would have been revoked. If the EU interacts with the T2E after the ASP has interacted with the T2E, he/she will find that the NAPTR RR(s) associated with the application service for his/her TN has/have been removed. Case II. End User adds or removes authorization This case happens when the EU wants to add or remove the authorization of an ASP for a particular application service or set of services. This case can be triggered at the request from the ASP to the EU or simply an EU decision to do so. After the interaction, the EU may inform or confirm with the ASP about the Informational - Expires March 2001 13 ENUM Administrative Process in the U.S.A. October 2000 addition or removal of the authorization for a specific service or set of services. Case IJ. End User/Telephony Service Provider/Application Service Provider changes information at Tier 2 Entity This case happens when the information at the T2E needs to be changed. The EU can change any NAPTR RR that is related to the application services. There are many possible ways. The ASP can only change the NAPTR RRs associated with the application services that it is authorized to access. The TSP may interact with the T2E to change those NAPTR RRs associated with the network-related services. Case IK. End User adds a new application service This case happens when the EU subscribes to a new application service from an ASP that currently offers some application services to the EU or from a new ASP. The EU can receive the information from the ASP that provides the new application service and interact with the T2E to add the new NAPTR RRs associated with the new application, or it can give the authorization to the T2E for the new ASP to provision/access/change the data at the T2E. Case IL. Requesting Tier 2 Entity information for a telephone number Any entity can obtain this information by launching an ENUM query to determine the entity that provides the T2E service for a TN. The T2E information would be limited to the information in the DNS RRs for a TN at the T1E. For example, there will not be any contact information. The information may help the TSP or an ASP to determine who to contact to submit EU authorization for an application or network-related service. 4.2. Reference Model II (TSP = T2E) Case IIA. Initial provisioning Initial provisioning occurs when either the EU elects to take an ENUM-based service or, in this reference model, when the TSP decides to provision a record in the T1E. (A TSP might elect to have records provisioned for the all the numbers that it serves or has assignment control of.) If the EU elects to take a service the following steps are required: 1. The ASP obtains appropriate authorization from the EU for a specific service or services for a TN or set of TNs. 2. The ASP provides or arranges for the EU to provide the above authorization to the TSP. 3. The TSP verifies the authorization, at least as it would for a preferred carrier (PIC in the USA) change. 4. If the TN is not already provisioned in the T1E DNS, the TSP requests that the T1E provision the TN with a record pointing to the TSP as T2E. The TSP and T1E interact through a protocol to be defined. 5. The ASP provides the TSP with the information to be provisioned in the T2E name server. The TSP verifies that Informational - Expires March 2001 14 ENUM Administrative Process in the U.S.A. October 2000 what is to be provisioned corresponds only to the services authorized. In the case of where the TSP elects to provision a record for the number on its own initiative only step (4) applies. If the TSP wishes to provision NAPTR RRs for specific service capabilities, it may, like other ASPs be required to obtain authorization from the EU. TSP needs not obtain the authorization from the EU for provisioning the NAPTR RRs for network-related services. Case IIB. End User changes Tier 2 Entity Under this model, the EU can only change T2E by changing TSPs, i.e., by porting the TN. 1. When porting a number the new TSP must determine if the EU wishes to retain existing ENUM services and obtain authorization for any changes other than for services deemed to be TSP-specific and not requiring EU authorization. 2. The new TSP must provision the appropriate entries in its DNS and notify any 3rd party ASPs of the pending port. 3. The EU ports the number to the new TSP by normal procedures. 4. The T1E detects the port via its feed from the NPAC and changes its entry for the TN to point to the new TSP. Case IIC. End User disconnects service on a telephone number 1. EU notifies TSP to disconnect. 2. At time of disconnect TSP removes entry in its T2E DNS. (Since TSP retains delegation for the number, changes in T1E are not strictly necessary especially when the TSP uses ENUM for network-related services.) Case IIDa. Add/modify/delete of NAPTR records The EU may authorize additions, changes, or deletions to services that lead to changes in NAPTR records. The process will depend on the specific changes. If changes are to the specifics of records for a service that the EU has already authorized an ASP to provide, the ASP may interact directly with the TSP/T2E without further authorization. Case IIDb. End User terminates an application service 1. The EU notifies the TSP or ASP they wish to terminate a service. 2. If the EU notifies the ASP, the ASP requests the TSP delete the corresponding NAPTR record. Alternatively, if the EU notifies the TSP directly, the TSP shall remove the corresponding record and notify the ASP. Case IIDc. End User changes Application Service Provider 1. The new ASP obtains appropriate authorization from the EU for a specific service or services for a TN. 2. The new ASP provides or arranges for the EU to provide the above authorization to the TSP. 3. The TSP verifies the authorization, at least as it would for a preferred carrier (PIC in the USA) change. Informational - Expires March 2001 15 ENUM Administrative Process in the U.S.A. October 2000 4. The ASP provides the TSP with the new information to be provisioned at the T2E. The TSP verifies that what is to be provisioned corresponds only to the services authorized. Case IIDd. End User adds a new application service 1. The ASP obtains appropriate authorization from the EU for a specific service or services for a TN or set of TNs. 2. The ASP provides or arranges for the EU to provide the above authorization to the TSP. 3. The TSP verifies the authorization, at least as it would for a preferred carrier (PIC in the USA) change. 4. The ASP provides the TSP with the information to be provisioned in the T2E name server. The TSP verifies that what is to be provisioned corresponds only to the services authorized. Case IIDe. Tier 2 Entity changes information at Tier 1 Entity The proper T2E is known by the T1E based on information about number assignment as discussed above. The T2E interacts with the T1E to make the necessary changes. Case IIE. Application Service Provider requests Tier 2 Entity information for a telephone number The ASP can obtain this information by an ENUM query to determine the entity to which to submit EU authorization for a service. The T2E information would be limited to the information in the DNS RRs for a TN at the T1E. For example, there may not be any contact information. 5. Security Consideration 5.1. Authentication Since the correctness of the NAPTR RRs stored at the T2E and the DNS RRs stored at the T1E for a TN may impact whether an EU can receive incoming calls or messages when the ENUM process is invoked, it is essential to ensure that provisioning requests are adequately authenticated. The T2E needs to authenticate the EU when an EU approaches it to be the T2E for his/her TN. The T2E is responsible for validating the EU's identity and his/her ownership of the TN. The EU could be asked to provide a recent phone bill and other information (e.g., pictured ID), or the EU's serving TSP may need to be involved. The T1E needs to authenticate the TSP and T2E before accepting information from them. If the EU gives the authorization for the ASP to provision/access/change the data for a TN at the T2E, the T2E must authenticate the TSP or ASP and ensure that it can only touch the information related to its application or network- related service or services. The T2E may need to be a trusted/certified entity to play the T2E role. If an EU wants to play the T2E role for his/her own TN, Informational - Expires March 2001 16 ENUM Administrative Process in the U.S.A. October 2000 there must exist a way to certify that this particular EU or entity does control/own that TN. 5.2. Secure Communication Communication over Interfaces A, B and C in the Reference Model I and over Interface A' and possibly Interface E' in the Reference Model II must be secure to prevent eavesdropping of the exchanged data and to ensure the data integrity. 6. Discussions/Issues The two strawman models and associated information flows raise a number of issues. It is hoped that further ENUM working group discussion will help resolve these. The following discussions and issues are specific to Reference Model I: - How can we make it easy so that the EU can be the T2E for its TN or set of TNs? The requirement to be a certified service registrar may not apply in this case unless this EN or entity wants to provide the T2E functionality for other EUs' TNs. - If the EU changes the TSP, the time that the T2E replaces with the NAPTR RRs associated with the new TSP's network-related services must be synchronized with the NPAC (e.g., when receiving notification from the NAPC about the change of TSP). The following discussions and issues are specific to Reference Model II: - What if there is only one TSP in a market and that TSP does not want to support the T2E functionality? The EUs in that market will not be able to get the ENUM services. - If the EU changes the TSP, the time that the T1E points to the new TSP/T2E must be synchronized with the NPAC. The following discussions and issues apply to both Reference Model I and II: - Many EUs will not be sophisticated enough to create the NAPTR RRs themselves. The T2E may need to convert the application address information received from the EU to the proper NAPTR RRs, or the ASP may need to be authorized to provision/access/ change the information for a TN. For the former case, can the T2E do it for all kinds of the NAPTR RRs? For the latter case, the T2E must authenticate the ASP and ensure that it can only access those NAPTR RRs it is authorized to access. - If the EU changes the ASP for an application service and the T2E is not informed about the change (e.g., the EU forgets to inform the T2E), there may be a need for the ASP to interact with the T2E so that its NAPTR RRs for a specific service for a TN can be removed. - Is there a need to define the interfaces between the EU or the ASP/TSP and the T2E for provisioning/accessing/changing the NAPTR RRs and between the two T2Es or should those interfaces be left to those entities to decide? - Will and can the TSP inform the T1E about telephony service disconnection for a TN in a timely manner? Informational - Expires March 2001 17 ENUM Administrative Process in the U.S.A. October 2000 - The Tier 1 entity is likely to be regulated. Should the T2E be regulated also? Must an entity register as the ENUM service registrar to perform the T2E functionality? Who regulates them or handles the registration from them? What are the qualifications? Is ICANN Domain Name Registrar certification necessary? Is it sufficient? - What should constitute sufficient authentication in terms of validating among the EU, T2E, TSP, ASP and T1E? - In each reference model, what, if any, services does the TSP have the right to provision without explicit EU consent? There must be a clear definition and distinction on what belong to the EUs' application services and what belong to the TSPs' network-related services. If an EU can receive a particular service multiple service providers, that service may be considered as the EUs' application service. If an EU can only receive a service from the TSP or a service is offered only by the TSP, that service may be considered as the network-related service. - The NAPTR RRs associated with the TSP's network-related services must be distinct from those associated with the EU's application services. Some fields (e.g., the service field) in the NAPTR RR must clearly indicate whether it is an application service or network-related service. - It is likely that an EU may want to have multiple NAPTR RRs for the same application service (e.g., e-mail) from many ASPs. The T2E must ensure that a particular ASP can only provision/ access/change a particular NAPTR RR for a specific application service. If the ASP is authorized to provision/access/change the information at the T2E, how can the EU control the orders and preferences of multiple NAPTR RRs related to the same application service that are offered by several ASPs? The T2E may need to ensure that the ASPs cannot modify the order and preference fields of their NAPTR RRs. 7. Conclusion This document discusses two reference models that can be used for the ENUM administrative process in the U.S.A. There are pros and cons with each of the two reference models. Both reference models assume that there will be only one entity that provides the T1E functionality. The authors believe that this not only make the allocation of the delegation authority for a TN much quicker and hold only one entity to be accountable for providing that particular service. The industry needs to discuss the two reference models and the issues surrounding them and move toward adopting a reference model (one of those proposed or perhaps some other model) for defining the protocols and procedures. The information in this document will be enhanced to reflect the discussions, comments, suggestions and agreements generated through the discussion list and based on further investigations by the authors. REFERENCES [1] S. Bradner, "The Internet Standards Process -- Revision 3, BCP9," RFC 2026, October 1996. Informational - Expires March 2001 18 ENUM Administrative Process in the U.S.A. October 2000 [2] A. Brown, "Telephone Number Mapping", draft-enum-rqmts-01- txt, June 2000. [3] P. F„ltstr÷m, "E.164 number and DNS," RFC 2916, September 2000. [4] A. Brown & G. Vaudreuil, "ENUM Service Specific Provisioning: Principles of Operation," draft-ietf-enum-operation-00.txt, July 13, 2000. [5] M. Foster, T. McGarry & J. Yu, "Number Portability in the GSTN: An Overview," draft-ietf-enum-e164-gstn-np-00.txt, July 2000. [6] A. Gallant, " The Number Portability Supplement to ITU-T Recommendation E.164,"draft-ietf-enum-e164s2-np-00.txt, July 7, 2000. [7] North American Numbering Plan Administration (NANPA), [8] M. Mealing & R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record," RFC 2915, September 2000. [9] J. Loughney & J. Yu, " Roaming Support with DNS," draft- loughney-enum-roaming-00.txt, July 14, 2000. [10] Number Portability Administration Center (NPAC), [11] Local Exchange Routing Guide (LERG), Authors' 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 James Yu NeuStar, Inc. 1120 Vermont Avenue, NW, Suite 550 Washington, D.C., 20005 U.S.A. Phone: +1-202-533-2814 Email: james.yu@neustar.com 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. Informational - Expires March 2001 19