2.7.5 Telephone Number Mapping (enum)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-05-20

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-msg-05.txt
  • draft-ietf-enum-experiences-02.txt
  • draft-ietf-enum-void-01.txt
  • draft-ietf-enum-iris-ereg-01.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
    RFC3953 Standard Enumservice Registration for Presence Services
    RFC4002 Standard IANA Registration for ENUMservices web and ft
    RFC4114 Standard E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)

    Current Meeting Report

    IETF 63 Telephone Number Mapping (ENUM) WG Meeting Minutes

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

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

    Friday, August 6 2005 9:AM to 12:30 PM

    AGENDA BASHING (5 min)

    1. Review of the existing drafts - Ready to go top Last call ( 5-10 M ? )
    	Title		: ENUM Implementation Issues and Experiences
    	Author(s)	: L. Conroy, K. Fujiwara
    	Filename	: draft-ietf-enum-experiences-02.txt
    	Pages		: 29	
    	Date		: 2005-7-1
    
    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-02.txt

    WG ACTION : After some minor discussion agreement that the document should go through one more iteratina and then take directly to WGLC.

    2. Final disposition of IRIS EREG, hopefully to last call. ( 5 Min? )

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

    WG ACTION : Put this document into WGLC after one more revision by author.

    DISCUSSION Some concerns whether this document is mature enough for even WG last call, response is that the document will see another revision and pushing towards last call is only meant to spur document forward.

    3. New/old work on enumservice registrations ( 20 M )

    3.1
    	Title		: IANA Registration for Enumservice Voice
    	Author(s)	: R. Brandner, et al.
    	Filename	: draft-brandner-enum-voice-00.txt
    	Pages		: 12
    	Date		: 2005-7-7
    
    This document registers the ENUMservice ^voice^ (which has a defined sub-type ^tel^), as per the IANA registration process defined in the ENUM specification RFC3761. This service indicates that the contact held in the generated URI can be used to initiate an interactive voice (audio) call.

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

    WG ACTION : WG humm agrees to draft as ENUM WG work item. Given the straightforward nature of this draft it is probable that it can go to WGLC after one iteration.

    DISCUSSION: Document is a simplification of a larger ENUM service registration document on voice services. The document only specifies the concept of voice:tel.

    3.2
    	Title		: IANA Registration for an Enumservice Containing 
    			  Number Portability and PSTN Signaling Information
    	Author(s)	: J. Livingood, R. Shockey
    	Filename	: draft-livingood-shockey-enum-npd-00.txt
    	Pages 		: 8
    	Date		: 2005-7-8
    
    This document registers the Enumservice "npd" and subtype "tel" using the URI scheme 'tel:' as per the IANA registration process defined in the ENUM specification, RFC 3761. This data is used to facilitate the routing of telephone calls in those countries where Number Portability exists.

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

    WG ACTION : WG humm agrees to draft as ENUM WG work item.

    DISCUSSION :

    Comments include:
    • Doc needs to clarify "which" ENUM this is Public, vs Private vs Carrier
    • Global Spin Std.
    • Are there size problems? Referring to SS7 size of databases can the DNS actually handle this class of queries even if privately cached.
    • TEL URI scope problem : examples should include both TEL and SIP URI examples
    • For IMS, limited usefulness
    • RFC 3671 db? 1 or collection? (Latter)

    • Document should discuss sage of portability data as it relates national policy


    3.3
    	Title		: IANA Registration for ENUMservice Mobile Webpage
    	Author(s)	: J. Ra, et al.
    	Filename	: draft-ra-shin-enum-mobileweb-00.txt
    	Pages		:
    	Date		: 2005-7-7
    
    This document registers the ENUMservice "mobweb" using the URI schemes 'http:' and 'https:' 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-ra-shin-enum-mobileweb-00.txt

    WG ACTION: Considerable disagreement on the nature and scope that this document ultimately has. WG decision NOT to make WG item at this time.

    DISCUSSION:
    Discussion dove into issue of DNS vs. Application layer indication of protocol stack capabilities.
    • Meta question, what are the criteria for an ENUMSERVICE registration? There was a general discussion of what those possible criterion are.
    • In the classic registration cases, want to know if there's common protocol before setting up a transport arrangement (connection)
    • HTTP negotiation accomplishes the same once connection is in place
    • This draft introduces "Complexity" in placing possible application negotiation in two places (DNS and HTTP)
    • RFC 3824, guidelines on SIP and ENUM as reference

    • Consensus in discussion that ENUMSERVICE registrations should NOT be used to negotiate capabilities that could be handled within the underlying protocol. Registrations are useful to discover hints as to the underlying service or protocol if no other method is available.

    4. ENUM Validation Issues. 3 Drafts 15 -20

    4.1 ENUM Validation Architecture draft-mayrhofer-enum-validation-arch-00
    	Title		: ENUM Validation Architecture
    	Author(s)	: A. Mayrhofer, B. Hoeneisen
    	Filename	: draft-mayrhofer-enum-validation-arch-00.txt
    	Pages		: 16
    	Date		: 2005-7-11
    
    An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called ^validation^. This document describes validation requirements and a high level architecture for an ENUM validation infrastructure.

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

    WG ACTION : WG humm agrees to draft as ENUM WG work item.

    4.2 "ENUM Validation Token Format Definition" - draft-lendl-enum-validation-token-00.txt
    	Title		: ENUM Validation Token Format Definition
    	Author(s)	: O. Lendl
    	Filename	: draft-lendl-enum-validation-token-00.txt
    	Pages		: 16
    	Date		: 2005-7-11
    
    An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called ^validation^. This document describes an signed XML data format -- the Validation Token -- with which
    Validation Entities can convey successful completion of a validation procedure in a secure fashion.

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

    WG ACTION : WG humm agrees to draft as ENUM WG work item.

    4.3 Bernie Hoeneisen

    http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.txt
    http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.html

    WG ACTION : WG humm agrees to draft as ENUM WG work item.

    DISCUSSION: Very little technical discussion of the above 3 documents.


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

    5. PART 2 1/2 hours. 3 Items

    WG AGENDA: Terms and Conditions of discussion.

    The first order of business is to attempt to create some very basic common ground on what is the problem Carrier/Infrastructure/Private ENUM is trying to solve based on what we generally understand are the orthogonal interests of A. the E.164 number holder vs B. the carrier of record for that number. In addition try to place this problem statement in the over all context of converged carrier networks and the desire for interconnection and peering.

    We are NOT going to solve the Carrier ENUM definition and problem statement in Paris but there needs to be some baseline before we can generally review the drafts at hand.

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

    5.1 Discussion of drafts on Carrier ENUM - Requirements ?
    	 Title		: Infrastructure ENUM Requirements
    	 Author(s)	: S. Lind
    	 Filename	: draft-lind-infrastructure-enum-reqs-00.txt
    	 Pages		: 8
    	 Date		: 2005-7-15
    
    There has been much discussion in various industries about the concept of infrastructure (or carrier) ENUM. Some of this discussion has been has been reflected within the ENUM WG mailing list and some within other organizations, including ETSI, the US ENUM Forum and the Country Code 1 ENUM LLC. While there has been consensus within some pockets of individual efforts, there has been little consensus industry-wide on even what infrastructure ENUM is, why it seems to be important, or what the requirements for implementing it are.

    At the request of the WG co-chairs, this document attempts to gather together the bits and pieces from those discussions (i.e., I stole the words shamelessly from the various sources) and, with an absolute minimum of editing, present them in some sort of cohesive manner that will enable enlightened discussion and hopefully achieve consensus. Some items listed below may be duplicative and suggest alternative wordings for similar and other contradictory issues. As such, this list is very raw and should not be viewed as complete, cohesive or correct.

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

    WG ACTION: This document is now a WG item and is a requirement for any other protocol drafts concerning carrier/infrastructure ENUM. Steve Lind thanked for putting such a document together on such short notice.

    Penn Pfautz agrees to collaborate with Steve Lind on future drafts.

    5.2
    	Title		: IANA Carrier/User enumservice Registration
    	Author(s)	: P. Pfautz, et al.
    	Filename	: draft-pfautz-lind-enum-carrier-user-00.txt
    	Pages		: 10
    	Date		: 2005-6-6
    
    This document registers, pursuant to the guidelines in RFC 3761, tElephone NUmber Mapping (ENUM) services to allow a single registry to support end user and carrier services with independent name servers holding the terminal NAPTR (Naming Authority Pointer) records identifying the communication services for each. The to-be- registered enumservices make use of non-terminal NAPTR records and DDDS (Dynamic Delegation Discovery System) replacement to achieve this end.

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


    5.3
    	Title 		: Combined User and Carrier ENUM in the e164.arpa tree
    	Author(s)	: M. Haberler, R. Stastny
    	Filename	: draft-haberler-carrier-enum-00.txt
    	Pages		: 10
    	Date		: 2005-7-11
    
    
    ENUM as defined now in RFC3761 is not well suited for the purpose of interconnection by carriers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms. A combined end- user and carrier ENUM tree solution would leverage the ENUM infrastructure in e164.arpa, increase resolution rates, and decrease the cost per registered telephone number. This document describes aminimally invasive scheme to provide both end-user and carrier data in ENUM.

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

    DISCUSSION: Pfautz and Haberler Carrier ENUM drafts were discussed together.

    As opposed to end user, opt-in ENUM, this is registration of information in DNS for carriers. Service provider of record as opposed to the number holder is considered the effective registrant. Three approaches were mentioned but only two seem "obvious".

    Non-terminal NAPTR records

    Records are placed in e164.arpa domain, at the tel number. One record for end user other for carrier. Differentiation is inside NAPTR record with the use of the NAPTR substititution field to indicate different re-write rules to generate the next lookup.

    Separated branches of the DNS tree
    1. For e164.arpa, there would be a [CC]. c.e164.arpa shadowing the main tree where [CC ] is the relevant Country code or

    2. For e164.arpa, there would be a c. [CC].e164.arpa shadowing the main tree where [CC ] is the relevant Country code. Difference being authority delegated pre or post RIPE/ITU.
    End users (number holders) remain in <telnumber>.e164.arpa. carriers in <telnumber>.c.e164.arpa.

    Requirements/Desired results
    1. Minimize number of lookups
    2. Retain flexibility
    3. Consistency from CC to CC for predictability

    DISCUSSION:
    • Data in DNS does not guarantee reachability ("deny's" allowed)

    • DNS MUST answer.
    • Uniformity in "c" label, name and where, is important
    • Non-terminal NAPTRs are untried
    • Questions on whether DNS wildcards are pertinent to the issue
    • Three questions - what's better for 1) DNS, 2) Application, and 3) "life"
    • Should not preclude private carrier-carrier traffic control

    WG ACTION : Chair asks for a show of hands whether the WG should accept the general concept of Carrier ENUM as a WG item. There was a large show of hands that Carrier ENUM is of interest as a work topic no dissentions.

    Further Discussion on Next Steps
    • Needs requirements and especially use cases to indicate what it is about

    WG ACTION: Requirements document added as WG item.
    • RFC 3761 should remain untouched
    • Scope needs definition (stop at re-write rules?)
    • Use cases, use cases, use cases
    • Terminology and definitions needed

    The Chair also asked for a non binding "straw poll" based on the three approaches on which is preferred "at this time".

    3 Options

    1. Pfautz approach of use of non-terminal NAPTR's
    2. Haberler/Stastny approach with delegation at RIPE/ITU aka [CC]. c.e164.arpa or with delegation after RIPE/ITU c. [CC].e164.arpa
    3. Using a different (non-e164.arpa) domain
    Hum indicates strong preference for B with further discussion the WG necessary.

    Further Discussion:

    Division of labor with VOIPEER BoF effort required
    	6.0 Title	: Non-Terminal NAPTR Processing: A Modest Proposal
    	Author(s)	: L. Conroy
    	Filename	: draft-conroy-enum-modestproposal-00.txt
    	Pages		: 12
    	Date		: 2005-7-6
    

    Recent Discussions within the IETF and in other fora have highlighted differences in interpretation of the set of standards associated with ENUM and DDDS, on which it relies. Specifically, the operation and semantics surrounding support for non-terminal NAPTRs has led to some confusion. This document is n attempt to add clarification to non- terminal NAPTR processing. In this, it clarifies RFC3403. A subsequent document will build on this one to extend FC3761 further, permitting registration of non-terminal Enumservices.

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

    WG ACTION : No action taken. Document may be incorporated into revision of RFC 3761 since it is clear there are a number of changes that have to be made before it could become Draft Standard.

    Meeting Concludes.

    Slides

    Combined User and Carrier ENUM in e164.arpa
    IANA Carrier/User enumservice Registration
    IANA Registration for an Enumservice Containing Number Portability and PSTN Signaling Information
    ENUM validation architecture & friends
    IANA Registration for ENUMservice Mobile Web