Internet Draft Penn Pfautz Document: AT&T Category: Informational Steve Lind AT&T July 7, 2004 A Combined User/Carrier ENUM Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed,and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. This Internet-Draft will expire on January 7, 2005. Abstract This document considers how so-called "carrier" or "infrastructure" ENUM and "end user" or "public" ENUM can share a single Tier 1 registry yet have independent Tier 2 providers. This approach allows the common cooperative infrastructure required by ENUM to be shared by end users and carriers reducing costs and facilitating adoption of ENUM generally. The essence of the proposal is to populate the Tier 1 registry with non-terminal NAPTRs rather than NS records and use different ENUM service fields for carrier and end user records. Expires January 2005 2 User/Carrier ENUM July 2004 3. Proposal We propose that a common ENUM instantiation that meets both carrier and end user needs without duplication of infrastructure or restriction of either party's prerogatives is possible. As commonly discussed today, ENUM implementation is based on a tiered architecture with Tier 1 containing NS records that point to the Tier 2 which contains the actual NATPR records for a given E.164 number. It is here proposed that, instead of NS records, Tier 1 be populated with two non-terminal NAPTR records containing distinct services parameters, one pointing to the end user Tier 2 and the other to the carrier Tier 2. RFC 3761 defines the service field of the ENUM NAPTR record as the string "E2U" (for E.164 to URI) plus some enumservice spec, e.g. "E2U+sip". ENUM NAPTR records also contain the flag "u" to indicate the rule is the last one and that the output is a URI. We propose there be two classes of service "E2U" for end user and, "E2C" for carrier populated in NAPTR records at Tier 1. Note that these would not include the enumservice spec (e.g., "sip") as NAPTR records for specific services would only be provided in the corresponding Tier 2. At Tier 2 the NAPTR records would include the full enumservice spec e.g. ("E2U+sip" or "E2C+sip"). Because the object of the query to Tier 1 is to obtain a domain name to query rather than a URI, it is proposed to use the Replacement field of the NAPTR rather than the Regexp as described in RFC 3403 [4]. Thus records for a number in Tier 1 might look like: $Origin 9.0.3.5.7.6.8.7.9.4.1.e164.arpa. IN NAPTR 100 50 "" "E2U" "" 9.0.3.5.7.6.8.7.9.4.1.joesenum.com IN NAPTR 100 50 "" "E2C" "" 9.0.3.5.7.6.8.7.9.4.1.telco.net 5. Security Considerations Existing security considerations for ENUM detailed in [1] still apply. Note that some registration validation issues concerning end user ENUM may not apply to carrier ENUM. Where the Tier 1 registry is able to identify the carrier serving a number e.g., based on industry data for number block assignments and number portability, registration might be more easily automated and a separate registrar not required. Expires January 2005 3 User/Carrier ENUM July 2004 6. IANA Considerations If the proposal offered is accepted IANA would need to update existing ENUMservices registrations to add corresponding E2C entries to existing E2U entries. 7. Discussion The proposal offered here seeks to preserve and leverage the work done to implement end user ENUM to support carrier ENUM in a way that minimizes duplication of infrastructure, and allow carriers and end users to make use of the technology without foreclosing the options of either. It is recognized that there may be instances where end users and carriers both populate different NAPTR records for the same capabilities (e.g., SIP) in their respective Tier 2s. In such cases the client originating the ENUM query will be responsible for deciding which records to make use of in initiating communication. Another issue which has prompted discussion of carrier ENUM has been concerns from carriers about placing certain network information in the publicly accessible DNS. Although the current proposal does not specifically address this, the separation of Tier 2s may facilitate restrictions on information access. REFERENCES [1] P. Faltstrom & M. Mealing, "The E.164 to Uniform Resource identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)," RFC 3761, April 2004. [2] International Telecommunications Union, _Supplement 3 to Recommendation E.164: Operational and administrative issues associated with national implementations of the ENUM functions._ [3] ENUM Forum, _ENUM Forum Specifications for US Implementation of ENUM, Document 6000_1 0, March 14, 2003. [4] M. Mealing, " Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name system (DNS) Database," RFC 3403, October 2002. Expires January 2005 4 User/Carrier ENUM July 2004 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 Steve Lind AT&T Room A201 180 Park Avenue, P.O. BOX 971 Florham Park, NJ 07932-0971 U.S.A. Phone: +1-973-236-6787 Email: sdlind@att.com Full Copyright Statement "Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." "This document and the information contained herein are provided on an"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expires January 2005 5