2.8.5 Telephone Number Mapping (enum)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-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-07.txt
  • draft-ietf-enum-msg-03.txt
  • draft-ietf-enum-webft-01.txt
  • draft-ietf-enum-pres-01.txt
  • draft-ietf-enum-experiences-01.txt
  • draft-ietf-enum-void-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
    RFC3761 Standard The E.164 to URI DDDS Application (ENUM)
    RFC3762 Standard ENUM Service Registration for H.323 URL
    RFC3764 Standard enumservice registration for SIP Addresses-of-Record

    Current Meeting Report

    Telephone Number Mapping WG (enum)

    Monday, November 9 at 1930-2200
    ===============================

    CHAIRS: Patrik Faltstrom <paf@cisco.com>
    Richard Shockey <rich.shockey@neustar.biz>

    Mailing Lists:
    General Discussion:enum@ietf.org
    To Subscribe: enum-request@ietf.org
    In Body: subscribe
    Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/

    Scribe: Spencer Dawkins - spencer@mcsr-labs.org


    AGENDA:

    AGENDA BASHING (5 min)

    Short Presentation on current status of ENUM in CC 1: Special Guest - Karen Mulberry MCI


    <>Karen is senior project manager for Numbering at MCI. She presented a Country Code 1 press release for a not-for-profit LLC (MCI, Sprint, Verizon are members now). $25K/year membership this year, all members equal, no limit on membership from interested parties, except cannot also be a vendor to the LLC. Most of the budget is liability insurance for the membership.
    </>
    1. Problem is that 19 countries share "country code 1". This is the rat in the snake of ENUM deployment. All countries have to support delegation in order to make it happen.
    2. Will write an RFC, will select one or more Tier One operators to operate a +1 ENUM registry.
    3. Vision is that RFC goes to Tier Ones in June 2005, awarded/signed by October 2005, registry operational by January 2006.
    4. http://www.enumllc.com is under construction now.
    5. Are discussing a trial as soon as possible (before award, but after delegation).
    6. Group is not chartered by anyone - US government has encouraged formation of this LLC, but can't be sure there are no alternatives in the woodpile.
    7. IAB/ITU agreement is that ENUM delegation matches normal delegation perfectly. US and Canada can request the delegation, but no opposition is allowed (opposition will roadblock the delegation).
    8. There is only one Tier One "A" vendors, but under that, there could be many Tier Two vendors.


    1. [ 10 min] Shockey-Stastny The ENUM dip indicator. It is a draft that discusses the use of a ENUM dip indicator in the TEL URL that indicates that a ENUM query has been done. This is going to be discussed at IPTEL but we want to make everyone aware of it.

    New parameter for the "tel" URI to support ENUM, defined in http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt.


    * Support handling ENUM queries in SIP proxies, H.323 gatekeepers, other VoIP network elements.
    * Idea is that ENUM operations may result in repeated queries - want to give subsequent ENUM entities a list of queries that have already been performed, so they won't be repeated. This improves performance and reduces load on VoIP network elements.
    * Enumdi parameter isn't mandatory, so a VoIP network element that doesn't understand it will ignore it and still do the lookup.
    * Patrik - this needs to be a SHOULD NOT, not a MUST NOT.
    * Working group hum agrees...


    NEW ITEMS : We need to discuss whether the timing is correct to take on this as a WG item.

    2. [20 M ] Title : An ENUM Registry Type for the Internet Registry Information Service
    Author(s) : A. Newton
    Filename : draft-newton-iris-ereg-02.txt
    Pages : 45
    Date : 2004-9-28

    This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt) registry schema for ENUM administrative information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-02.txt


    * IRIS uses multiple layers, XML, NAPTR records.
    * Want to provide ENUM Registry (EREG) . Similar to DREG registry, with its own identifier namespace.
    * Implementation available at irisverisignlabs.com.
    * Supports both UDP and TCP (using BEEP).
    * Does not require universal adoption

    Working group interest? Seems like enough interest to adopt, no opposition but a lot of "don't cares", too.

    Chairs Conclusion : Adopt as a WG item

    NEW ITEMS : These drafts relate to issues involving Validation of the Number Holder as part of the Provisioning process.

    3. [20 M ] Title : ENUM Validation Information Mapping for the Extensible Provisioning Protocol
    Author(s) : B. Hoeneisen
    Filename : draft-hoeneisen-enum-validation-epp-00.txt
    Pages : 17
    Date : 2004-9-30

    This document describes an EPP extension for mapping information about the validation process the ENUM Registrar has applied for the E.164 number (or number range), which the ENUM domain name is based on. Specified in XML, this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of E.164 numbers.

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


    * The goal here is to know a lot more about who registered an E.164 domain than we know about who registered a plain, vanilla DNS domain.
    * Austria, Switzerland, - who doesn't need something like this? We vote Country Code 1, of course, but no conclusions here (except that we know we have a problem). CC1 has external databases that you may not have in Europe, so not sure if CC1 would use the same approach or not.
    * This has a lot of interactions with number portability (which is done differently in CC1 and in Europe - they call-forward instead of doing a database lookup.
    * If your country code considers ENUM deployment, all these issues pop up instantly.


    4. [ 20 M ] ENUM Validation Architecture and Token Format Definition - Alexander Mayrhofer

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


    * What's the incentive for legacy carriers to contribute to validation for ENUM? We think it's close to zero. Most others (users, porting process/NPAC, etc.) are more likely to participate.
    * We need to accommodate consumer choice, not set up the next monopoly.
    * Centralized validation agents? Multiple validation agents? Number range holder = registrar? No single solution works best, so define Validation Entity as a role, not as an agency.
    * Question - where is the end user in all this? This validation flows one way (registrars validated registrants, not the other way around). What about the danger of slamming as we had in US long distance competition?
    * Question - we are getting from the problem statement to the solution - what are the requirements? Should a validation token be traceable to a verifier?
    * Question - are validation tokens signed, or encrypted and signed? Sweden has a distinction between validation entities and registration entities, and they don't share data, especially about customers.
    * Question - can the ENUM WG clear up the trust model here?
    * Question - what about cancelling tokens? New tokens override old ones, but there's an explicit cancel as well.


    What's still needed here? Definition of terms. Will this be one document or two (a framework and a specific implementation)? Will work on one document (framework, roles, requirements, definitions) during next IETF cycle (confirm this on the mailing list).





    ONGOING WORK:

    Title : IANA Registration for Enumservice VOID
    Author(s) : R. Stastny, L. Conroy
    Filename : draft-ietf-enum-void-00.txt
    Pages : 0
    Date : 2004-10-12

    This document registers the Enumservice 'void' using the URI schemes 'mailto:' and 'http:' as per the IANA registration process defined in the ENUM specification, RFC3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early".

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


    ***

    Older business:

    Title : ENUM Implementation Issues and Experiences
    Author(s) : L. Conroy, K. Fujiwara
    Filename : draft-ietf-enum-experiences-01.txt
    Pages : 26
    Date : 2004-10-25

    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-01.txt


    * Want to get implementers' experience in next 30 days for WGLC by yearend.


    Title : IANA Registration for ENUMservices email, fax, mms, ems and sms
    Author(s) : R. Brandner, et al.
    Filename : draft-ietf-enum-msg-03.txt
    Pages : 20
    Date : 2004-10-21

    This document registers the 'ENUMservices' "email", "fax", "sms", "ems" and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761.

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


    Slides

    Agenda
    CC1 ENUM LLC - The MCI Perspective
    Enum dip indicator
    draft-newton-iris-ereg-02
    EPP Extension Framework for ENUM Validation
    ENUM Validation Architecture & Token Format