[Enum] MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTURE ENUM IN THE ENUM WORKING GROUP
"Richard Shockey" <richard@shockey.us> Fri, 16 February 2007 21:13 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAOl-0006SX-Bs; Fri, 16 Feb 2007 16:13:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAOk-0006Rq-12 for enum@ietf.org; Fri, 16 Feb 2007 16:13:42 -0500
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIAOg-0006SQ-Vt for enum@ietf.org; Fri, 16 Feb 2007 16:13:42 -0500
Received: from RSHOCKEYLTXP (h-68-165-240-34.mclnva23.covad.net [68.165.240.34]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1GLDLXW014141 for <enum@ietf.org>; Fri, 16 Feb 2007 13:13:33 -0800
From: Richard Shockey <richard@shockey.us>
To: enum@ietf.org
Date: Fri, 16 Feb 2007 16:13:15 -0500
Message-ID: <022701c7520f$46e8d6c0$22f0a544@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AcdSBYtx8RFIfinqSQe2qYCz4B8DzQ==
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 1.4 (+)
X-Scan-Signature: 441f623df000f14368137198649cb083
Subject: [Enum] MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTURE ENUM IN THE ENUM WORKING GROUP
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org
FYI this was just sent to the IAB/IESG. MEMORANDUM RELATING TO ISSUES SURROUNDING INFRASTRUCTURE ENUM IN THE ENUM WORKING GROUP Dear Colleagues, We, the ENUM Working Group chairs want to alert the IESG as well as the IAB to some unusual and significant considerations involving several documents the ENUM WG has recently approved and submitted to the IESG for approval as Informational or Proposed Standards. The documents listed below [Appendix A] deal with issues involving what has been referred to as Infrastructure ENUM. We believe it is necessary to alert the larger IETF Management community to their significance before IESG action is taken on them and we believe the documents also point to actions that should be taken by the IAB as well. This memorandum outlines the issues involved with these documents, a general back ground of their historical context and some specific recommendations that the IESG/IAB should undertake in its relationship with ITU-T and ITU Study Group 2. To understand why these documents are particularly significant, it is worth pointing out a little history about the development and deployment of RFC 2916 and its successor RFC 3761. When RFC 2916/3761 was approved there was a highly significant IANA instruction included in the RFC. {Quote from RFC 3761} "4. IANA Considerations This memo requests that the IANA delegate the E164.ARPA domain following instructions to be provided by the IAB. Names within this zone are to be delegated to parties according to the ITU recommendation E.164. The names allocated should be hierarchic in accordance with ITU Recommendation E.164, and the codes should assigned in accordance with that Recommendation. Delegations in the zone e164.arpa (not delegations in delegated domains of e164.arpa) should be done after Expert Review, and the IESG will appoint a designated expert." This clause triggered a long and complicated process of negotiations with the ITU-T Study Group 2 that resulted in a series of agreements between the IETF and the ITU regarding how delegations within e164.arpa were to be accomplished. These negotiations were documented in the following: The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2) ftp://ftp.rfc-editor.org/in-notes/rfc3245.txt Liaison to IETF/ISOC on ENUM ftp://ftp.rfc-editor.org/in-notes/rfc3026.txt The negotiation process was extremely difficult and resulted is several compromises that continue to complicate the global deployment of RFC 3761, such as the processes by which zone administrators are selected. The ITU has never fully reconciled itself with the e164.arpa zone administration system though, in practice, there have been few disputes. Of particular concern is that the IAB/ITU agreements on the administration of e164.arpa are still considered "Interim Procedures" and consequently subject to cancellation at any time. This, in our opinion, continues to have a negative effect on ENUM global deployments and zone delegations. [ITU ENUM procedures] http://www.itu.int/ITU-T/inr/enum/procedures.html ENUM was envisioned as a global public service where the customer or the telephone number holder would have to "opt-in" before their information would be listed within the public DNS zone that other users would access. This mode of operation was supported by many government regulators as a natural extension of policy on Number Portability. The deployment of RFC 3761 under these principals is generally referred to as "Public ENUM". [Historical over view of Number Portability] Number Portability in the Global Switched Telephone Network (GSTN): An Overview http://www.ietf.org/rfc/rfc3482.txt In the intervening years since RFC 3761 was approved in 2004 there has been a considerable shift in the development and deployment of SIP based VoIP in general and the emerging concept of Next Generation Networks [NGN]. Many national communications carriers and new incumbent carriers are redesigning their voice networks to use TCP/IP and SIP. Some global carriers have announced plans to "shut off" the PSTN completely. This has created a new set of requirements for number translation resolution and signaling in emerging NGN networks to support "All Call Query" on call or session origination. This created the requirements for what is commonly referred to as "Infrastructure ENUM". The central premise behind Infrastructure ENUM is that it is the carrier of record that issues the phone number vs the consumer or number holder that would be authoritative for writing the zone files with NAPTR records that designate "points of network interconnection" between real time communications service providers. Many global carriers have come to look on the technology of RFC 3761 as central to internally resolving phone numbers to URI's in order to facilitate internal network routing between network soft switches as well as facilitate network to network service interconnection. An added benefit has been to replace protocol functions now exclusively associated with SS7/C7 signaling. ENUM related work is currently under active discussion in such fora as 3GPP, CableLabs, ETSI, ITU and ATIS. The IETF ENUM WG continues to make significant contributions to that effort. ENUM related issues have also spawned the SPEERMINT WG in the IETF RAI Area. SPEERMINT is specifically chartered to assist in developing tools and best current practices to assist in carrier to carrier peering and interconnection when ENUM is used to resolve the telephone number to a URI. Global service providers looked at the administrative procedures surrounding the various zones of e164.arpa and correctly concluded that RFC 3761 could not be relied upon to provide a truly authoritative database of E.164 named end points since the data relied upon the explicit "opt-in" by the user as opposed to the carrier of record for a particular telephone number. Should significant numbers of consumers "opt-out" of a Public ENUM system, it would be impossible for service providers to route sessions in an accurate manner and would therefore require the use of SS7/C7 signaling mechanisms indefinitely. The ENUM Working group has been discussing for several years now what is necessary to actually implement an Infrastructure ENUM system. The logical place to start was to adapt the e164.arpa domain for that purpose but for countless technical reasons that has proved to be a challenge. There is consensus within the ENUM community and ENUM WG that the requirements for User and Infrastructure ENUM are orthogonal to each other and the one approach would be to designate an entirely separate domain [ie164.arpa] for Infrastructure ENUM purposes only. This approach is outlined in: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-04.txt. This approach represented a WG consensus after the ENUM WG meeting at IETF 65 in Dallas in early 2006 as outlined in the following ENUM message. http://www1.ietf.org/mail-archive/web/enum/current/msg04848.html Another school of thought believes that the use of the global DNS for discovery of carrier to carrier points of interconnection is a misuse of the DNS and that various "Private ENUM" approaches are the ultimate solution. Many carriers are deeply concerned that exposure of points of interconnection in the global DNS could expose their networks to various forms of attacks that would compromise the quality and reliability of real time voice communications. Private ENUM is generally regarded as one or more technologies that permit service providers to exchange phone number to URI data to find points of interconnection in private secure manner. Any mutually agreed to domain could be used and access control to the data would be strictly enforced. Private ENUM could take several forms including maintaining a full and complete cache of an authoritative telephone number database within the service providers network boundaries or permitting queries via SIP Redirect or RFC 3761 to a centralized registry or database so long at the data was not visible or accessible by the general public. All of the various approaches however stress that there is a strict division between the concept of a "Public ENUM" where the end user is in control of the zone files and Infrastructure ENUM or Private ENUM, where the service provider of record is in control. There is also near universal agreement that both concepts need to exist in parallel with each other. The larger issue these documents [Appendix A] raise is what is the appropriate role the IETF can and should play in defining relationships between real time application service providers? The IESG and IAB should be aware that by approving the documents listed below may mean that the IETF is endorsing the idea that a new domain or sub domain under .arpa will be required for Infrastructure ENUM. This domain would be under the control of carriers only and the zone delegations would likely be handled in a similar manner to that of e164.arpa. There is some question about the viability of Infrastructure ENUM concept in general, not only for security reasons previously stated, but in light of many Private ENUM initiatives sponsored by 3GPP, CableLabs and commercial firms. We do not advocate any particular approach for service providers to take Infrastructure or Private. Ultimately that is not the concern of the IETF. Such issues will be properly resolved in the market place. The issues IAB and IESG should consider as to what are the appropriate roles of the IETF and the ITU in developing standards appropriate to governing relationships between service providers. IETF can and must define protocols that a carrier can use to create real time communication and facilitate interconnection over IP networks but it does not seem appropriate for the IETF to define a specific Carrier Infrastructure ENUM domain, carrier business rules or carrier to carrier business structures. We believe this crosses the boundary of what is and is not appropriate work for the IETF to undertake. This seems a perfectly reasonable conclusion in light of the IETF recognizing the role that ICANN plays in defining the business rules the domain name business while the IETF defines the actual DNS protocols and DNS provisioning tools. We, the ENUM WG chairs believe we have preformed our task in managing the documents listed below to WG consensus, though we both believe there are significant architectural issues with the combined use of e164.arpa for both User and Infrastructure purposes and in particular the use of the so called Branch Location Record within e164.arpa. [http://www.ietf.org/internet-drafts/draft-ietf-enum-branch-location-record- 02.txt ] We strongly recommend expert DNS review of this document and the associated draft-ietf-enum-combined-03.txt. The chairs do not recommend either of these documents should Standards Track RFC's but adopted as Experimental only. Over the years the ENUM WG has looked at several other technical solutions that were ultimately rejected, such as a branch "below" the full E.164 number in the DNS tree using either non-terminal NAPTR Resource Records or new suggested resource record types, such as the one discussed in draft-ietf-enum-uri-00.txt. These mechanisms were rejected due to the requirement that a carrier of record would have to rely on DNS hosting by some external party for any intermediary zone between the Country Code zone [cc.e164.arpa] and the location of the NAPTR record that referred to the service they run. At IETF 67 in San Diego, the ENUM WG chairs held discussions with Lesile Daigle, Olaf Kolkman, John Klensin, and Scott Bradner (in his capacity as IETF - ITU liaison) and many others voicing our concerns about these documents. We also kept our RAI Area Directors Jon Peterson and Cullen Jennings appraised of these discussions. In these discussions, a general set of ideas emerged which we, the ENUM WG chairs completely support. The consensus is that the IETF should not attempt to define a specific domain for Infrastructure ENUM purposes. If such a domain should be defined at all it should be a result of discussions by ITU Study Group 2 which is authoritative for the E.164 plan. In addition there was a consensus that a mutual understanding of what are the appropriate roles and responsibilities between IETF and ITU-T needs to be developed as it may relate to these emerging carrier to carrier business models. A potential set of guidelines might include: 1. The IETF continue to be responsible for the DNS, including definition of Resource Records, and the base ENUM specification as defined for "Public ENUM" (or just "ENUM") in RFC 3761 and its successors where the E.164 number holder is in control over the information in global DNS, and that information is made available through the DNS, to anyone on the Internet. 2. The IAB continues to be responsible to decisions related to the namespace in the DNS according to the existing exchange of letters between IAB, ITU-T, ITU-T TSB and the registry for ENUM (as appointed by the IAB, currently RIPE NCC). 3. The IETF will continue to develop standards and profiles that facilitate the exchange of real time SIP sessions including applications that assist in the provisioning of telephone number to URI data to various network elements. 4. The ITU-T should take responsibility for "Infrastructure ENUM" where goals are resolve the issues described in draft-ietf-enum-infrastructure-04.txt. ITU-T should be responsible for business relationships that involve bi-lateral or multilateral agreements between service providers. 5. The IAB should strongly suggest that the ITU-T SG2 Interim Agreements on the delegation of the zones for e164.apra be made permanent. In conclusion, should the management of the IETF decide that this consensus is appropriate then we recommend an appropriate Liaison Letter should be sent to ITU SG2 outlining these views as soon as practically possible. Though these documents raise some unique issues for our community, the working group chairs are immensely proud of the overall accomplishments of the ENUM WG in general. We both have confidence that the RFC's currently delivered by the ENUM WG now and in the future will be deployed by service provider networks world wide. Sincerely, Richard Shockey Patrik Faltstrom Appendix A: INFRASTRUCTURE ENUM DOCUMENTS UNDER DISCUSSION Title : Infrastructure ENUM Requirements Author(s) : S. Lind, P. Pfautz Filename : draft-ietf-enum-infrastructure-enum-reqs-03.txt Pages : 7 Date : 2006-8-8 This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum-reqs -03.txt Title : The ENUM Branch Location Record Author(s) : O. Lendl Filename : draft-ietf-enum-branch-location-record-02.txt Pages : 9 Date : 2006-12-12 This documents defines the ENUM Branch Location record (EBL) which is used to indicate where the ENUM tree for special ENUM application is located. The primary application for the EBL record is to provide a temporary solution for the Infrastructure ENUM tree location. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-branch-location-record-0 2.txt Title : Combined User and Infrastructure ENUM in the e164.arpa tree Author(s) : M. Haberler, R. Stastny Filename : draft-ietf-enum-combined-04.txt Pages : 12 Date : 2007-1-24 This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice until the long-term solution is approved. This interim solution will be deprecated after approval of the long-term solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-combined-04.txt Title : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-infrastructure-05.txt Pages : 6 Date : 2007-1-24 This document defines a use case as well as a proposal for a parallel namespace to "e164.arpa" as defined in RFC3761, to be used for Infrastructure ENUM purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-05.txt Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org Skype:"rshockey101" PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 <mailto:richard(at)shockey.us> <mailto:richard.shockey(at)neustar.biz> _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum
- [Enum] MEMORANDUM RELATING TO ISSUES SURROUNDING … Richard Shockey
- Re: [Enum] MEMORANDUM RELATING TO ISSUES SURROUND… Stastny Richard
- RE: [Enum] MEMORANDUM RELATING TO ISSUES SURROUND… Richard Shockey