Internet Draft Penn Pfautz Document: AT&T Category: Informational James Yu NeuStar, Inc. March 2001 ENUM Administrative Process 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). Informational- Expires Sept. 2001 1 ENUM Administrative Process March 2001 Abstract This document considers administrative processes for ENUM and offers a general administrative model for an environment where number portability has been implemented. The ENUM administrative process is a critical piece in making ENUM operational. The administrative process involves several entities. A telephony user's identity and his/her assignment of a telephone number must be validated before ENUM service can be granted. Therefore, the entity that assigns telephone numbers (often but not always telephony user's telephony service provider) plays an important and sometimes necessary role in making the ENUM administrative process successful. The information flows associated with the reference model proposed in this document 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 whether this reference models or some alternative is to be used. 1. Introduction Provisioning of ENUM [2,3,4] 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 (because particular providers are being selected to provide services to the holder of the domain name identified by the telephone number). ENUM provisioning also is tied to number administration because of the need to verify a user's rights to have ENUM records for a particular telephone number and to terminate those rights when service on the number is disconnected. It is essential to develop an administrative process that is operationally efficient, provides adequate authentication of requests and at the same time is not burdensome for the end user of the telephone number. Informational - Expires Sept. 2001 2 ENUM Administrative Process March 2001 The ENUM Operations document [4] and RFC 3026 [5] suppose ENUM implementation in a tiered Architecture. In the Operations document, the first tier is described as directing queries to the entity that holds the actual Naming Authority Pointer (NAPTR) records for an individual telephone number. Discussions between the International Telecommunication Union (ITU) and Internet Engineering Task Force (IETF) (RFC 3026) suggest that this tier will actually be composed of two distinct sub-tiers: one which directs queries to the administrative entity that an ITU member state has designated to provide the Tier 1 function for the telephone number in question and that Tier 1 entity itself. This document will refer to the first entity as Tier 0, and the second as Tier 1. Tier 0 is the Reseaux IP Europeens Network Control Center (RIPE NCC) that maintains the e164.arpa zone. Entries in the RIPE NCC name server correspond to country codes (CCs) or portions of country codes and point to the Tier 1 or Registry that is the authoritative name server for that country code or portion of country code1. At Tier 1, the Registry maintains records that indicate the authoritative name server(s) for individual E.164 numbers or blocks of numbers in the country code or portion thereof.2 At Tier 2, the Service Registrar for an E.164 number maintains the actual NAPTR records that contain information for specific communication services. These NAPTR records in turn either point to Application Service Providers (ASPs) that provide these services or contain the Uniform Resource Locators (URLs) for contacting the user's end points directly. This document discusses the ENUM administrative process in an environment in which number portability [6,7] has been implemented such that the telephony user controls the assigned telephone number so long as it maintains the telephony service. In such environments, the donor telephony service provider (i.e., the telephony service provider that is assigned a block of telephony 1 In the actual Recommendation E.164, a 'country' in this sense means 'a specific country, a group of countries in an integrated numbering plan or a specific geographical area.' 2 Although the focus of this document is on geographic country codes assigned to a single state or group of states as an integrated numbering plan, much of what is proposed would be applicable to telephone numbers in country codes that are shared by regional or international communities such as the +881 and +878 numbers as well as to numbers in geographic country codes. Informational - Expires Sept. 2001 3 ENUM Administrative Process March 2001 numbers before any number porting event happens from that number block) is not to be relied on for maintaining the delegation information for a TN (i.e., the Tier 1 function in the ENUM process). The reference model presented here assumes that a "Tier 1 Entity (T1E)" has been chartered by national (or, potentially multi- national in the case of an integrated numbering plan such as the North American Numbering Plan (NANP)[8]) authorities to provide the Domain Name System (DNS) service for the .e164.arpa domain (e.g., 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 NAPTR[9] records for the TN. Note that in some cases the separation (DNS delegation) at the national Tier 1 level may occur below the country code level when countries share a common country code (or integrated numbering plan.) For example, if there were to be separate Tier 1s for the US and Canada, two of the countries in the integrated numbering plan for country code 1, then the delegations would have to be appropriately divided at the area code level. However, such policy-area divisions would still have to ensure that there is only one Tier 1 registry for any given telephone number, and that these subdivisions are static, limited, and delegated in a way that does not burden Tier 0. 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. CC Country Code DNS Domain Name System ENUM Telephone Number to 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 Informational - Expires Sept. 2001 4 ENUM Administrative Process March 2001 ID Identity or Identification ISP Internet Service Provider ITU International Telecommunication Union LERG Local Exchange Routing Guide NANP North American Numbering Plan NAPTR Naming Authority Pointer NCC Network Control Center NPA Numbering Plan Area NPAC Number Portability Administration Center PA Portability Administrator PIC Preferred Inter-exchange Carrier Registry The entity whose name server identifies the Service Registrar for a given telephone number RFC Request For Comment RR Resource Record RIPE Reseaux IP Europeens Service Registrar the entity that hosts the NAPTR records for a given telephone number 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 is the Registry, similar to the registry in the general domain name registration process. T2E Tier 2 Entity, the entity that has all the NAPTR RRs associated with each served TN. The T2E plays the role of the service registrar, which is similar to that of the registrar in the general domain name registration process. Informational - Expires Sept. 2001 5 ENUM Administrative Process March 2001 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. TNAA Telephone Number Assignment Authority, the entity that holds information about the current assignment of a telephone number to an end user. This is often, but not always the current TSP for a number. 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 Model This section discusses a reference model that shows the entities that are involved in the ENUM administrative process and the interfaces among them. The assumptions are first described below before the discussion of the reference model. 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. - One Tier 1 Entity (T1E) handles the subdomain of e164.arpa corresponding to a particular country code or portion thereof and points each served Telephone Number (TN) for which an ENUM record exists to the proper 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. Informational - Expires Sept. 2001 6 ENUM Administrative Process March 2001 - 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 [10]. 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 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. - 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. The T2E must control the access rights to the NAPTR RRs 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. Informational - Expires Sept. 2001 7 ENUM Administrative Process March 2001 - 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 if such a default T2E exists. - The T1E knows the Telephone Number Assignment Authority (TNAA) and TSP for each TN and knows when a number porting takes place through information from the Portability Administrator (PA) that administers the number porting process (e.g., the Number Portability Administration Center (NPAC) in the U.S.A. [11]). - 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 in the U. S. A. and the change of registrar through the registry for existing domain name registration. - The TNAA may need to confirm the TN assignment to an EU when requested by the T1E and/or T2E. The need for this action from the TNAA 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 and no longer owns/controls the TN. - The TNAA is aware when rights to a TN are relinquished, e.g. through service disconnection - The TNAA informs the T1E in a timely manner when the EU relinquishes a TN. - 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. Informational - Expires Sept. 2001 8 ENUM Administrative Process March 2001 3.1. Reference Model Architecture Figure 1 shows the reference model. All the entities involved are shown as logically distinct but in some cases a single individual or corporation may perform the roles of multiple entities. In particular the TSP may be the TNAA. 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 meet criteria to be defined by the appropriate national authorities. These may or may not be the same criteria applied to domain name registrars in general. +-----+ +--------------| PA | | +-----+ | | | |M | +-----------+-----+ +-----+ | | +--------| T1E | +------| T2E | | | | +-----+ | +-----+ | | | | | | | | A+ +-------+I | | | | | | | | +-----+ B +----+ | | | +-----| T2E |------+------| EU |---+ N+ | | | +-+-----+ +---------+----+ | | | | | | | | | | | | F+ C+ | | +G | | H +E | | | | + L | | +---|--+-----+ | | | | | | | | | | | +J | | | | +-+-----+ +D +-----+ | | | +--------|TNAA |---+ | ASP | | | | | +--+--+ +-----+ | | | | |K | | | +-----+--+--+ | | +-----------| TSP |----------------------+ +--------------+-----+ Figure 1. Reference Model 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 name Informational - Expires Sept. 2001 9 ENUM Administrative Process March 2001 server 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 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 TNAA to inform the T1E about termination of TN assignment. It may be used by the T1E to verify the assignment of a TN and whether a TN is a working TN assigned to an EU, or to the TSP. Interface D is used by the EU to request a TN assignment, or to terminate the assignment, or by the TNAA to assign a TN to the EU or to terminate the assignment. 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 inform the T1E about 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. Interface G may be used by the T2E to verify the assignment of a TN and by the TNAA to inform the T2E about the telephony service disconnection for a TN. Interface H 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 I is used between the old T2E and the new T2E to resolve disputes about the T2E change and for the new T2E to retrieve the NAPTR RRs at the old T2E. Interface J is used between the EU and TSP to request or terminate telephony service. Interface K is used between the TNAA and TSP as needed to verify or update number/service status. Informational - Expires Sept. 2001 10 ENUM Administrative Process March 2001 Interface L is used by the TSP to provision/access/change the NAPTR RRs associated with the network-related services for a TN at the T2E. Interface M is used by the Portability Administrator (PA) to inform the T1E about the number porting events for a TN that is managed by the PA. There can be multiple PAs with each one handling different number ranges/blocks (e.g., one for geographic number and one for freephone numbers). Interface N is used between the TSP and the Portability Administrator (PA) about number porting events. It is defined by each of the number portability administration process for a specific number ranges/blocks and is outside the scope of this document. 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, and the T2Es can define interface I to standardize the communication among themselves. Where the TSP rather than an independent TNAA is responsible for number assignments, interfaces D and J collapse, as do interfaces G and L, and Interfaces C and F. Where the TSP serves as the T2E interface L becomes internal, interfaces A and F collapse, and interfaces B and J collapse. Where the EU plays the T2E's role for its own TN or TNs, interfaces E and H collapse, interfaces J and L collapse, and interface B becomes internal. 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. 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. The processes of verifying the EU's identity and EU's assignment 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. Informational - Expires Sept. 2001 11 ENUM Administrative Process March 2001 Case A. 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 assignment 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 Informational - Expires Sept. 2001 12 ENUM Administrative Process March 2001 the EU-selected T2E and informs the EU-selected T2E about the TSP's default T2E. The EU-selected T2E then retrieves the 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 just 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 B. 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. Recall that the T1E can verify that the TSP currently serves the TN in question. 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 Informational - Expires Sept. 2001 13 ENUM Administrative Process March 2001 EU-selected T2E allows the T1E to quickly point to the TSP's default T2E when the EU stops using the ENUM service. Case C. 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. 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 assignment 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 old T2E fails to respond to the T1E within a specified time period. Case D. End User relinquishes 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 relinquishes the TN, e.g. disconnects service. 2. The TNAA 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 Informational - Expires Sept. 2001 14 ENUM Administrative Process March 2001 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 E. 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 F. 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 by the PA and must synchronize the TSP change with the portability process. The exact time to remove the old serving TSP's NAPTR RRs and/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 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 informs the T1E about its default T2E information as described in Case B. 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 stops 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 or can retrieve the NAPTR RRs from the new TSP's default T2E. The T2E will swap the NAPTR RRs from the new TSP when it is informed by the T1E to make that switch. The process stops 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 portability process, instructs the EU-selected T2E to remove all the NAPTR RRs associated with the old serving TSP's network-related services and removes the stored default T2E information provided by the old serving TSP for the TN. The process stops here. Informational - Expires Sept. 2001 15 ENUM Administrative Process March 2001 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. The process stops here. 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 regardless whether the EU has selected a T2E, the T1E takes no action. Cases G to K. 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 a 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 application 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 rights 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 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 G. 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. Informational - Expires Sept. 2001 16 ENUM Administrative Process March 2001 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 H. 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 I. 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 Informational - Expires Sept. 2001 17 ENUM Administrative Process March 2001 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 addition or removal of the authorization for a specific service or set of services. Case J. 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 K. 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 L. 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 contact information may help the TSP or an ASP to determine who to contact to submit EU authorization for an application or network-related service. Informational - Expires Sept. 2001 18 ENUM Administrative Process March 2001 5. Security Considerations 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 assignment of the TN. The EU could be asked to provide a recent phone bill and other information (e.g., pictured ID), or the TNAA 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, 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 must be secure to prevent eavesdropping of the exchanged data and to ensure the data integrity. 6. Discussions/Issues The reference model and associated information flows raise a number of issues. As the responsible entities take up the work of instantiating ENUM service, these issues will need to be addressed. - 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. Informational - Expires Sept. 2001 19 ENUM Administrative Process March 2001 - If the EU changes the TSP, the time that the T2E replaces the NAPTR RRs associated with the new TSP's network-related services must be synchronized with the number portability process (e.g., when receiving notification that the TSP has changed). - 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? - Where the TSP has the TNAA function, what arrangements are required for the TSP to inform the T1E about telephony service disconnection for a TN in a timely manner? - What should constitute sufficient authentication in terms of validating among the EU, TNAA, T2E, TSP, ASP and T1E? - 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 from 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 Informational - Expires Sept. 2001 20 ENUM Administrative Process March 2001 may need to ensure that the ASPs cannot modify the order and preference fields of their NAPTR RRs. Another issue that has arisen in ENUM discussions is the potential for the use of the ENUM protocol to query domains other than e164.arpa. Although RFC 2916 is focused on the use of a single tree (i.e., e164.arpa) for all E.164 numbers, nothing prevents the protocol from being used to query other domains providing private directory services. It is anticipated that in such services Tiers 0-2 may be collapsed with the same entity acting as both registry and service registrar. Accordingly, this document does not discuss administrative arrangements for such services, though clearly, many of the same concerns about number assignment validation, telephone service disconnect notification, and service registrar _ ASP interactions apply. REFERENCES [1] S. Bradner, "The Internet Standards Process -- Revision 3, BCP9," RFC 2026, October 1996. [2] A. Brown, "Telephone Number Mapping", draft-enum-rqmts-01- txt, June 2000. [3] P. Faltstrom, "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-02.txt, February 23, 2001. [5] R. Blane, _Liaison to IETF/ISOC on ENUM,_ RFC 3026, January 2001. [6] M. Foster, T. McGarry & J. Yu, "Number Portability in the GSTN: An Overview," draft-ietf-enum-e164-gstn-np-02.txt, February 2001. [7] A. Gallant, " The Number Portability Supplement to ITU-T Recommendation E.164,"draft-ietf-enum-e164s2-np-00.txt, July 7, 2000. [8] North American Numbering Plan Administration (NANPA), [9] M. Mealing & R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record," RFC 2915, September 2000. [10] J. Loughney & J. Yu, " Roaming Support with DNS," draft- loughney-enum-roaming-00.txt, July 14, 2000. [11] Number Portability Administration Center (NPAC), [12] Local Exchange Routing Guide (LERG), Informational - Expires Sept. 2001 21 ENUM Administrative Process March 2001 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 400 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 Sept. 2001 22