2.8.4 Telephone Number Mapping (enum)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-07

Chair(s):
Patrik Faltstrom <paf@cisco.com>
Richard Shockey <rich.shockey@neustar.biz>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: enum@ietf.org
To Subscribe: enum-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/enum/index.html
Description of Working Group:
This working group has defined a DNS-based architecture and protocol [RFC 2916] by which an E.164 number, as defined in ITU Recommendation E.164, can be expressed as a Fully Qualified Domain Name in a specific Internet Infrastructure domain defined for this purpose (e164.arpa). The result of the ENUM query is a series of DNS NAPTR resource records [RFC2915] which can be used to contact a resource (e.g.URI) associated with that number.

The Working Group proposes to advance RFC 2916 from Proposed Standard to Draft Standard.

Background:

E.164 numbers are globally unique, language independent identifiers for resources on Public Telecommunication Networks that can support many different services and protocols. E.164 numbers are used to identify ordinary phones, fax machines, pagers, data modems, email clients, text terminals for the hearing impaired, etc.

A prospective caller may wish to discover which services and protocols are supported by the terminal named by a given telephone number. The caller may also require more information than just the telephone number to communicate with the terminal.

The holder of an E.164 number or device may wish to control what URI's, are associated with that number.

Working Group Revised Goals and Scope:

1. The working group will update RFC 2916 to reference the DDDS system (revision of RFC 2915) and advance RFC 2916 to Draft Standard.

2. The working group will examine and document various aspects of ENUM administrative and/or operational procedures as Informational. Issues to be considered include privacy and security considerations in storing ENUM related data as well as validation and authentication of data, including DDDS NAPTR records in the DNS. The working group will coordinate activities in these areas with the DNSEXT WG and PROVREG WG when appropriate.

3. The Working Group will continue to maintain appropriate contact and liaison with standards bodies and groups, specifically ITU-T SG2, in order to provide technical or educational information as needed, such as the appropriate use of DNS. The Working Group will encourage the exchange of technical information within the emerging global ENUM community as well as documentation on practical experiences with implementations or administration of RFC 2916.

Goals and Milestones:
Done  Initial draft of Service ENUM Requirements
Done  Initial draft of ENUM Protocol
Done  Revised draft of ENUM Protocol
Done  Submit ENUM Protocol document to IESG for publication as Proposed
Done  Revise and update RFC 2916 appropriate to DDDS (revision of 2915)
Done  ENUM service registrations for SIP and H.323
Aug 03  Document appropriate ENUM Security and Privacy Issues (Informational)
Nov 03  Document appropriate ENUM Registration and Provisioning Procedures (Informational)
Internet-Drafts:
  • - draft-ietf-enum-epp-e164-04.txt
  • - draft-ietf-enum-msg-02.txt
  • - draft-ietf-enum-webft-01.txt
  • - draft-ietf-enum-pres-01.txt
  • - draft-ietf-enum-experiences-00.txt
  • Request For Comments:
    RFCStatusTitle
    RFC2916 PS E.164 number and DNS
    RFC3482 I Number Portability in the Global Switched Telephone Network (GSTN): An Overview
    RFC3764Standardenumservice registration for SIP Addresses-of-Record
    RFC3762StandardENUM Service Registration for H.323 URL
    RFC3761StandardThe E.164 to URI DDDS Application (ENUM)

    Current Meeting Report

    Telephone Number Mapping WG (enum)


    IETF 60 San Diego


    Wed August 2, 2004


    1300-1500 Afternoon Sessions


    Chair(s):
    Patrik Faltstrom <paf@cisco.com>
    Richard Shockey <rich.shockey@neustar.biz>


    Transport Area Advisor:
    Allison Mankin <mankin@psg.com>


    ===============================



    SCRIBE: Chris Celeberti - Patrik Faltstrom - Jabber


    AGENDA BASHING (5 min) ( appointment of scribe etc)
    130-1300 Break
    1300-1500 Afternoon Sessions I
    I
    TSV enum Telephone and Number Mapping WG


    AGENDA BASHING (5 min)


    No objections to the Agenda being reordered from that posted.


    # 1 Disposition of [ 10 Min]


    Title : E.164 Number Mapping for the Extensible Provisioning Protocol
    Author(s) : S. Hollenbeck
    Filename : draft-ietf-enum-epp-e164-04.txt
    Pages : 17
    Date : 2004-6-8


    This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers representing domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers.


    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-04.txt



    Scott H: The central question is what will the WG do with the document since it has been lying around for some time.


    Chair. How many people have read the document ( 5-10)


    Chair: Does anyone have issues with document ?( 0 )


    Chair : Scott what do you think ..Experimental or Proposed?


    Scott H. Experimental is generally for documents that have dragons we know of else it can be proposed standard. Other EPP extensions have been proposed if this needs to be revised in the future.


    Chair: So proposed path is to update the document once to reflect current drafts etc and then go to last call. Objections ? None stated.


    Stastny: Allison what is the current state of the service registrations?


    Allison: There have been some well known problems with ID tracker where the documents got lost in cyberspace so those should proceed asap.



    2: Review of the ENUM Operations Document [ 10 Min]


    Title : ENUM Implementation Issues and Experiences
    Author(s) : L. Conroy, K. Fujiwara
    Filename : draft-ietf-enum-experiences-00.txt
    Pages : 0
    Date : 2004-7-12


    This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is informational only, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol.


    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-00.txt



    Fujiwara: Co author of document could not come. General presentation of the document. Issues separated into server side and client side issues. Discussion of issues involving Non-Terminal NAPTR records. Question as to whether there is any need for discussion of non-terminal NAPTR records.


    Chair: Is anyone contemplating using non terminal NAPTR records? (no answer)


    Conclusion - draft enum experiences is close to being finished and ready for submission for last call etc. Further discussion on the list.



    #3 ENUM VOID [ 10 Min]


    Title : IANA Registration for enumservice void
    Author(s) : R. Stastny, L. Conroy
    Filename : draft-stastny-enum-void-00.txt
    Pages : 7
    Date : 2004-7-13


    This document registers the 'ENUMservice' 'void' using the URI scheme 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761 [2]. This 'ENUMservice' SHALL be used to indicate that the E.164 number or E.164 number range connected to the domain used in DNS as described in [2] is not assigned to an end-user in case of an E.164 number or to a communication service provider in case of an E.164 number range.


    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-stastny-enum-void-00.txt


    Stastny: Overall issue is that for ENUM end user is controlling what is registered in the zone ..If no registration is made an NXDOMAIN results from a query in DNS. The result of this is a default condition of passing to the PSTN. Some NRA's now assigning specific E.164 number ranges for ENUM use such as +43780 in Austria. Calls using this range can only be addressed using ENUM. User agents don know the special call is for VoIP.


    It would be better if the origination caller gets a response from the DNS indicating the number is in a "unassigned" state.


    ENUM service called "VOID" should say the number is unused and not assigned to and end user then can then be used by NRA's and carriers for blocks for which they have been allocated but not assigned.


    ENUM service is 'void' subtype mail to URI scheme mailto:


    Shockey: What happens if a user doesnt want any email address published at all?


    From the Room: You have to have some data here?


    Jim Baskin: In some parts of the world, its not the case only the end user can decide the delegation of the ENUM data?


    Shockey: Jim do you think there is a need for this?


    J Baskin: Yes, I just have issues with some of the background.


    Shockey: Allison we have future work in IPTEL that will look into a "ENUM dip indicator" for the TEL URI which is directly related to this work and need.


    Baskin: What happens if a call originates where the user doesn't have ENUM?


    Stastny: If you dial such a number in the US, the call will be routed to Austria and in Austria the number willbe routed to a GW which will tdo the ENUM lookup.


    Baskin: What about the last bullet then when the call originates as VoIP?


    Stastny: The problem is the risk for a loop. A call on Voip in the US will drop to the PSTN, route the call to Austria, where the GW which will then get NSDOMAIN in the GW.


    Baskin. OK then if the call originates on IP then it makes some sense.


    Steve Lind What if the number portability makes the numbers ENUM only?


    Stastny: You dont have to use this.


    Shockey: Should this be a WG document ( hum ) ( yes)


    Allison : Warning because this is a tool which turns ENUM into a routing tool for carriers its opening up the door.


    Carsten: what about other URI schemes such as Mailto?


    Geoff Huston: This is weird, you take a non assigned number and assign a endpoint ( in some URI scheme) to it. Should really non existing things be assigned to existing things? Especially as not all non existing numbers exists and non-exiting ones according to this scheme.


    Chair: moving on ....


    # 4 Overview of the cost optimization of telecommunication connections based on ENUM as described in the ID "draft-bartosiewicz-enterprise-enum-00.txt".[ 10 Min]


    General overview of the document which has its purpose to describe a scheme where ENUM can be used to optimize enterprise call costs. It analizes data stored in a connection and tariff databases.


    Seng: What is the status of this document.?


    Bartosiewicz: Informational.



    #############################################


    Conclusion of regular ENUM WG move to Carrier - Infrastructure ENUM Mini-BOF [ 1 hour ] R. Stastny J. Seng co-chairs.


    Introduction to the problem statement ( R. Shockey)


    Shockey: The chairs wish to remind the list that the discussion of this topic in San Diego should follow the following guidelines.


    1 What is the Problem Statement here


    2. What are the Requirements that address the Problem.


    3. Discussion of specific approaches to a solution are out of scope.


    Public ENUM is 3761 with the use of the DNS in e164.arpa mapping from TN to URI. It assumes all data is available to all users on the internet with out any authentication etc.


    Shockey: Stop calling it carrier "ENUM". What is happening is that the carriers have different needs for getting information about E.164 numbers including mappings for URI's. They can use DNS, LDAP, SIP, whatever. How they do that is not what we should talk about there?


    We will not under any circumstances talk about solutions. The issue is what are the requirements for a solution


    Jim Baskin: I'm concerned you say this is not ENUM.


    Patrik: I thin Richard said we have to talk about requirements first.


    Jim Baskin. But Carrier ENUM is about e164.arpa. and carrier ENUM is how carriers put data in e164.arpa.


    Allison . Different people mean different things so we .have to start with requirements.



    #1 James Seng Overview.


    Use cases
    • Route calls between users on the same "carrier"
    • Route calls between users on different "carriers"
    • Route calls for "carriers" for roaming users
    It is easily confused with User/Public ENUM where we use it to route calls between users regardless of "carriers".


    #2 Steve Lind -


    Title : A Combined User/Carrier ENUM
    Author(s) : P. Pfautz, S. Lind
    Filename : draft-pfautz-lind-enum-carrier-00.txt
    Pages : 5
    Date : 2004-7-8


    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.


    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-00.txt



    •End users want privacy to minimize unwanted communications


    •Service providers want to maximize call completion
    ­To/from their subscribers
    ­Keep communication on the IP-plane
    ­Single tree (or absolute minimal set of trees) to find call completion information
    •Many trees lead to call completion problems
    ­How to maximize chance of success


    #3 Richard Statsny


    ETSI Experiences



    Faltstrom: Shouldn't we see what people what people think?


    Requirements
    • No opt-in or opt-out (it is just there!)? 95% support
    • Private (not globally visible on the Internet)? 60% support
    • Authentication, Authorization needed? 90% support
    • Accounting needed? 10% support
    • Should this be in e164.arpa? 50% support
    • Is this pure DNS? 40%
    • Not DNS at all? 10%
    • Hybrid of DNS and something else? 20%
    • Should we have a break? 78%


    BOF meeting continues.

    Slides

    Agenda
    Carrier ENUM mini-bof
    draft-ietf-enum-experiences
    ENUM WG mini-BOF Setting the Stage
    Enumservice VOID
    PSTN - User ENUM - "Infrastructure ENUM"
    draft-pfautz-lind-enum-carrier-00.txt