2.8.5 Telephone Number Mapping (enum)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-10

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>

Secretary(ies):

Alex Mayrhofer <axelm@nic.at>

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:

The ENUM working group has defined a DNS-based architecture and protocol
[RFC 3761] 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).

Background:

E.164 numbers are globally unique, language independent identifiers for
resources on Public Telecommunication Networks that can support many
different services and protocols. There is an emerging desire for
network operators to utilize aspects of RFC 3761 to discover points of
interconnection necessary to terminate communications sessions
identified by a E164 number,in addition to identifying end point
protocols and services.

Working Group Revised Goals and Scope:

1. The working group will update RFC 3761 and advance to Draft Standard.

2. The working group will examine and document the use of RFC 3761 to
facilitate network interconnection for services using E.164 addressing.
The working group will coordinate its activities with other IETF working
groups, existing or to be chartered, that are investigating elements of
peering and or interconnection for VoIP or other services that typically
use E.164 addressing.

3. The working group will continue examine and document various aspects
of ENUM administrative and /or operational procedures irrespective of
whether e164.arpa domain is used.

4. The working group will also examine the use of RFC 3761 technology
for storing and delivering other information about services addressed by
E.164 numbers, for example PSTN call routing and signaling data.

5. The Working Group will continue to maintain appropriate contact and
liaison with other standards bodies and groups, specifically ITU-T SG2,
to provide technical or educational information and address, as needed,
issues related to the use of the E.164 numbering plan for services on IP
networks. In addition the Working Group will continue to encourage the
exchange of technical information within the emerging global ENUM
community as well as documentation on practical experiences with
implementations, alternate technology uses and the administration and
provisioning of RFC 3761.

6. As described in RFC 3761, the IETF documents and registers the
Enumservices. While extant, it is the ENUM working group that performs
the technical review and development of the Enumservices for the
Internet community. The working group determines whether to advance them
and how to progress them technically. Coordination with other WGs will
be taken into account on these.

Other than Enumservices, all proposed deliverables of the working group
will be discussed with and approved by the Area Directors, who may
require wider review due to the broad impact of the subject.

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 2003  Document appropriate ENUM Security and Privacy Issues (Informational)
Nov 2003  Document appropriate ENUM Registration and Provisioning Procedures (Informational)

Internet-Drafts:

  • draft-ietf-enum-msg-05.txt
  • draft-ietf-enum-experiences-03.txt
  • draft-ietf-enum-void-02.txt
  • draft-ietf-enum-iris-ereg-02.txt
  • draft-ietf-enum-validation-epp-01.txt
  • draft-ietf-enum-voice-01.txt
  • draft-ietf-enum-validation-arch-00.txt
  • draft-ietf-enum-validation-token-00.txt
  • draft-ietf-enum-pstn-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
    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-64 Vancouver ENUM WG meeting minutes
    ===============================
    
    Chair(s):
    Patrik Faltstrom  
    Richard Shockey 
    
    
    WG Secretary:
    Alex Mayrhofer 
    
    
    Transport Area Director(s):
    Allison Mankin 
    Jon Peterson 
    
    Transport Area Advisor:
    Allison Mankin   
    
    TUESDAY, November 8, 2005
    
    AGENDA BASHING (5 min)
    ----------------------
    
    
    The chairs open the meeting. Agenda as well as the location of presentations were posted to list. The proposed agenda is accepted without comments by the WG.
    
    
    RECHARTER DISCUSSION (CURRENT PROPOSAL)  (15 MIN )
    ==================================================
    
    The ENUM working group has defined a DNS-based architecture and protocol [RFC 3761] 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).
    
    Background:
    
    E.164 numbers are globally unique, language independent identifiers for resources on Public Telecommunication Networks that can support many different services and protocols. There is an emerging desire for network operators to utilize aspects of RFC 3761 to discover points of interconnection necessary to terminate communications sessions identified by a E164 number, in addition to identifying end point protocols and services.
    
    Working Group Revised Goals and Scope:
    
    1. The working group will update RFC 3761 and advance to Draft Standard.
    
    2.  The working group will examine and document the use of RFC 3761 to
    facilitate network interconnection for services using E.164 addressing.
    The working group will coordinate its activities with other IETF working groups, existing or to be chartered, that are investigating elements of peering and or interconnection for VoIP or other services that typically use E.164 addressing.
    
    3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used.
    
    4. The working group will also examine the use of RFC 3761 technology for storing and delivering other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data.
    
    5. The Working Group will continue to maintain appropriate contact and liaison with other standards bodies and groups, specifically ITU-T G2,to provide technical or educational information and address, as needed, issues related to the use of the E.164 numbering plan for services on IP networks.  In addition the Working Group will continue to encourage the exchange of technical information within the emerging global ENUM community as well as documentation on practical experiences with implementations, alternate technology uses and the administration and provisioning of RFC 3761.
    
    6. As described in RFC 3761, the IETF documents and registers the
    ENUMservices.  While extant, it is the ENUM working group that performs
    the technical review and development of the ENUMservices for the Internet community.  The working group determines whether to advance them and how to progress them technically.  Coordination with other WGs will be taken into account on these.
    
    Other than ENUMservices, all proposed deliverables of the working group will be discussed with and approved by the Area Directors, who may  require wider review due to the broad impact of the subject.
    
    Goals and Milestones
    
    March 06  ENUMservice Registration for Local Number Portability          and Related Data as a Proposed Standard
    
    April 06  Requirements for Carrier Interconnection using ENUM           as an Informational 
    
    June 06   Carrier Interconnection using ENUM as a Proposed Standard
    
    July 06   ENUM Privacy and Security Considerations as an          Informational Standard
    
    August 06 Advancement of RFC 3761 to Draft Standard
    
    ----
    
    DISCUSSION:
    
    Most of the issues of the recharter have been discussed on the list already. Includes moving RFC3761 up to draft standard, which needs interoperable implementations. Documentation on this will be first step towards draft standard.
    
    Scope now includes investigating possible carrier ENUM implementations, 
    and continues registration of ENUMservices.
    
    Milestones: Draft on number portability to be completed this fall, carrier enum requirements in spring. Shockey will probably work on a privacy and security draft to be submitted soon, and finally asks for comments of objections to the charter.
    
    There are neither questions nor objections.
    ----
    
    ENUM Implementers Draft: (Final Version) 5 MIN 
    ==============================================
    
    	Title		: ENUM Implementation Issues and Experiences
    	Author(s)	: L. Conroy, K. Fujiwara
    	Filename	: draft-ietf-enum-experiences-03.txt
    	Pages		: 33
    	Date		: 2005-10-18
    	
    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 advisory, 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-03.txt
    
    ----
    
    DISCUSSION: 
    
    Shockey explains the roadmap of the document - this could go to last
    call fairly shortly. Only few comments have been posted to the list
    so that seems ready to go. When further experiences are to be added,
    a new version of the document could be done.
    
    Ken Cartwright: This could probably have an impact on RFC3761 and the
    DDDS documents - it's unclear who owns the DDDS documents. 
    Faltstrom: No one owns the DDDS RFCs - revising them would probably 
    require to reopen the WG.
    
    Updates to RFC3761 will be baked into the next version experiences document.
    ----
    
    DNS issues 10-M 
    ===============
    
    B. Title		: ENUM Requirement for EDNS0 Support  
    	Author(s)	: L. Conroy, J. Reid
    	Filename	: draft-conroy-enum-edns0-01.txt
    	Pages		: 16
    	Date		: 2005-10-25
    	
    This document mandates support for EDNS0 (Extension Mechanisms for   DNS) in DNS entities claiming to support ENUM query resolution (as  defined in RFC3761).  This requirement is needed as DNS responses to   ENUM-related questions return larger sets of Resource Records than   typical DNS messages.  Without EDNS0 support in all the involved   entities, a fallback to TCP transport for ENUM queries and responses   would typically occur.  That has a severe impact on DNS Server load,   and on latency of ENUM queries.
    
       This document updates RFC3761 only in adding this requirement.
    
    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-conroy-enum-edns0-01.txt
    
    ----
    
    DISCUSSION: 
    
    
    The draft was discussed in the DNSOP WG just before the ENUM wg meeting.
    
    Wimmreuter presents the draft as a proxy:
    
    - ENUM features large responses
    - could lead to lots of TCP queries if EDNS0 size option not used
    - draft mandates EDNS0 size support on all entities involved in 
      ENUM DNS lookups.
    - middleboxes could additionally mess up with fragmentation & truncation  of responses
    
    The document does mandate EDNS0 size option, but does not recommend a certain size (1200 bytes could be a good value, however).
    
    Wimmreuter asks to make this draft a WG item, and let the DNSOP WG have a look at it. He points out that a generic document about how DNS should be operated could be much bigger, and would probably be too late for many implementers.
    
    If this draft is accepted, the corresponding section could be removed from the experiences draft discussed before.
    
    Faltstrom: Question was proposed to DNSOP if they could write a Document on how to run DNS - they were very interested. However, they were nervous about writing a doc about how to run DNS, because that could be 400 pages. One suggestion was to just have a very brief document with normative references (MUSTs SHOULDs etc.) that they are going to review. Suggestion is to not decide now about the EDNS0 draft, but instead take EDNS0 and the relevant part from experiences together, with brief references 
    
    WG ACTION : Shockey comments that such a document should be made WG item.
    
    Jean Francois: There are strong reasons to allow corner cases where 
    EDNS0 support should NOT be a requirement. Is 3761 the right place for
    DNS requirements?
    
    Faltstrom: Suggests to discuss the list document once available with 
    dnsops, and not mess with 3761 for now.
    
    Shockey: Should not stop RFC3671 from progressing 
    
    Koch: There's a difference between "protocol" and "operations". "Operations" cannot be regulated by RFCs. Depends on who reads 
    this document: implementers or eg. firewall operators.
    
    Stastny:  asks if experiences draft goes to last call under the light of this. 
    
    Faltstrom suggests another quick round, and then to publish what we have there, because this is a live document.
    ----
    
    IANA Registration for ENUMservice vCard  10-Min 
    ===============================================
    
    	Author(s)	: A. Mayrhofer, D. Lindner
    	Filename	: draft-mayrhofer-enum-vcard-00.txt
    	Pages		: 7
    	Date		: 2005-10-5
    	
     This memo registers the ENUMservice "vCard" using the URI schemes http" and "https" according to the IANA ENUMservice registration process described in RFC3671.  This ENUMservice is to be used to refer from an ENUM domain name to the vCard of the entity using the  corresponding E.164 number.
    
      Clients may use information gathered from those vCards before, during or after inbound or outbound communication takes place.  For example, a callee might be presented with the name and association of the caller before he picks up the call.
    
    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-vcard-00.txt
    
    
    
    DISCUSSION: 
    
    ENUMservice for refering from phone numbers to URIs containing vCard.
    Came from questions from service providers which wanted to publish.
    Usage scenario: query for number, receive vCard URI, fetch vCard.
    
    No subtypes defined right now, two URI schemes (http and https) proposed now.
    
    Feedback received about subtypes: Should subtypes reflect protocol? 
    
    Faltstrom (as WG member): Privacy constriants, and granularity 
    limits of HTTP. vCards could be synthesized based on authentication. 
    HTTP not optimal for detailed access constraints. A bit nervous that usage of http is too quick. Recommend at least subtyping because good WP systems should not use http, but could be started 
    with http now. Suggestion is to check HTTP, LDAP, IRIS
    
    Shockey: Want to see granularity on access control as well. 
    
    Schiefner: Would like to see this a WG item, looking at moving that forward.
    
    Levi ??: vCards heavily used in XMPP. Should look at this. Not sure if 
    granularity is what people expect from publishing a vCard.
    
    Jimmy ??: Suggestions to granularity on access controls could be out of
    scope of the ENUM WG?
    
    Mayrhofer: Could simply say "we make the reference, what behind this is
    out of scope for ENUM". 
    
    Faltstrom: Clarification on privacy needed.
    
    Baskin: Privacy needs to be highlighted each time. However, "ENUM" does 
    not the vCard, ENUM just returns a reference. It's done after the lookup.
    
    Faltstrom: Agreed, need to be subtyped to differentiated.
    
    ??: There is a draft about vCard over WebDAV in the calendaring for 
    WebDAV. draft-debut-carddav?
    
    Schwartz: Issues on identifying when using HTTP.
    
    WG ACTION: Based on a hum of the WG, consensus for adopting this as WG item.
    ----
    
    IANA Registration for IAX ENUMservice ( 10-Min )
    ================================================
    
        Author(s)    : E. Guy 
        Filename    : draft-guy-enumiax-00.txt 
        Pages        : 11 
        Date        : 2005-10-20 
         
       This document registers the IAX2 ENUMservice using the URI scheme    'iax2:' 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-guy-enumiax-00.txt
    
    ----
    Ed Guy presents the document: registers IAX ENUMservice with iax2 URI.
    The URI definition itself is in the protocol spec itself (aims at Informational). Some feedback on formatting was received. 
    
    Rosenberg: Passwords in URI are bad.
    
    Guy: addressed in doc as "bad thing".
    Peterson: There is a list on reviewing URI, comments expected from there
    
    Faltstrom: Peer review between W3C and IETF exists
    .
    Cartwright: empty subtype causes headache for implementors, URI scheme 
    Recommended
    
    Shockey: Underlying protocol informational, going for proposed standard?
    
    Stastny: same with h323. Was that an informational?
    
    Cartwright: Uncertainty about subtype - what is it supposed to contain?
    Clarification desired.
    
    Faltstrom: Subtypes were actually requested. Anyway, Subtype is not equal to URI scheme, must look up IANA registration for relation between subtype and protocol URI.
    
    WG ACTION : The WG hums in favor of accepting this draft as a WG item.
    
    
    An ENUM Library API    ( 5 Min WG Chairs will lead discussion )
    ===============================================================
    
    	Author(s)	: T. Sajitha
    	Filename	: draft-sajitha-enum-api-00.txt
    	Pages		: 7
    	Date		: 2005-10-21
    	
    This draft defines a library API for ENUM. The API takes telephone 
    number as input and returns the URI associated with that telephone number.
    
    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-sajitha-enum-api-00.txt
    
    ----
    WG Chairs have made the decision that API is out of scope, and will not be discussed here.
    ----
    
    Carrier ENUM Requirements?   ( 15 - M ) 
    =======================================
    
    Title	: Carrier/Infrastructure ENUM Requirements
    	Author(s)	: S. Lind, et al.
    	Filename	: draft-lind-infrastructure-enum-reqs-01.txt
    	Pages		: 7
    	Date		: 2005-10-21
    	
    This document provides requirements for "infrastructure" or "carrier"   ENUM, 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
    
    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-01.txt
    
    ----
    
    DISCUSSION: ( Shockey for Pfautz, Lind) 
    
    This document will be core requirements document for of carrier enum moving forward. 
    
    "Carrier enum is usage of ENUM technology by carrier of record, carrier of record is the carrier providing PSTN service to a number, definition ultimately national matter". DNS must return a result, and can identify a point of interconnection. User ENUM and carrier ENUM must coexist.
    
    Document a WG item since Paris, because requirements are first step.
    
    Schiefner: Common terminology? "Infrastructure" vs "carrier" 
    
    Baskin: no preference on terminology, but political burden on the word 
    "carrier" to be considered. 
    
    Shockey: voipeer was unable to define what a "carrier" is.
    
    Baskin: Requirements as they are?
    
    Shockey: No, continue to work on this, guidance on next steps.
    ??: "provides PSTN service" too restrictive - excludes IMS users.
    ??: Requirements doc without statements on problems to be solved?
    
    Schaefer: ETSI doc on "infrastructure ENUM". choice of "infrastructure"
    could be interpreted as association to this doc.
     
    WG ACTION: Humm taken on "carrier" vs "infrastructure" usage in future discussion and documents. Chairs consensus that "infrastructure" is preferred to "carrier"
    
    Peterson: Stronger hum on "infrastructure", should be taken to list.
    
    Shockey: Next revision of document should refer to "infrastructure".
    ----
    
    Combined User and Carrier ENUM in the e164.arpa tree  ( 15 - M )
    ================================================================
    
    	Author(s)	: M. Haberler, R. Stastny
    	Filename	: draft-haberler-carrier-enum-01.txt
    	Pages		: 15
    	Date		: 2005-10-21
    	
    ENUM as defined now in RFC3761 [1] 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 a   minimally 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-01.txt
    
    ----
    
    
    
    Haberler presents the draft:
    
    Use of a single tree for infrastructure purposes has economic advantages, draft introduces resolution on texts, tried to generalize that to possible other trees. Draft does not imply that actual data is in e164.arpa (can be decided at country level).
    
    Indication where branch goes off is indicated by "branch location record", which is put into the DNS itself at the cc level. Assumption left is knowledge about country codes (back-off algorithm described in draft). This is a change from -00 (dropped the table about branch location).
    
    Not documented in the current draft: Make label configurable, or insert
    a zero length label. Could also refer other apexes (generalization).
    open issue: Feedback required on branch location record, currently using TXT record in prototypes. Assumption is that a NAPTR service would be the most flexeble.
    
    Peterson: Might an appropriate case for TXT record. Is just additional
    information that has no programmatic function for limited audience, so
    that might be OK. However, should be discussed in the WG.
    
    ??: TXT bad idea because of overloading, and multiple records with 
    multiple semantics.
    
    Koch: Make a problem statement, and take it to appropriate DNS WG. Asking early might save you problems.
    
    There are already prototypes for Asterisk and SER,they are using TXT 
    records for now. Roadmap: integrate suggestions received here, add 
    detailed resolver behavior by copying and modifying from RFC3761. Will
    make a problem statement about branch location record.
    
    Shockey: need finish requirements draft before this is promoted to WG
    item status - but expects work to continued on this doc, and reconsider
    it once requirements are stable.
    
    Cartwright: Doc has overlapping with Lind doc - requirements should be copied over. Would like to see guidance on conflicts between infrastructure and user contexts (SIP records in both)
    
    Haberler: Precedence will be given to one tree depending on contexts (carriers only looking at carrier part, user only in users), but probably resorting to other tree will happen. However, might be local policy.
    
    Cartwright: concerns about conflicting data
    
    Shockey: Important: There is no _conflicting_ data. It's up to policy 
    to define precedence, if one uses both. Various national policies and 
    best current practices will probably exist.
    
    Stastny: Carriers will probably look up carrier enum, but user might 
    ask carrier to use look up user enum first for his calls.
    ----
    
    IANA Registration for an ENUMservice Containing PSTN Signaling Information
    
    draft-ietf-enum-pstn-01    ( 10 Min )
    =====================================
    
    ----
    Livingood presents draft: History: Was submitted as non-wg item in 
    Paris, where it was formally adopted - renaming etc. IPTEL WG is 
    doing registration for tel-URI parameters, might need updating this 
    doc. Service type was changed from "npd" to "pstn". 
    
    Suggestions on CNAM received. Document added SIP URI as well as examples. We added section about distribution of data (data to be distributed privately) and section about record conflict resolution. Section 7 talks now about implementation suggestions (from feedback about implementation questions), additional section talks about call flows would work in practice. Update references to reflect tel-URI registration and SIP adoption. Will work with various vendors to test this out with practical data.
    
    DISCUSSION:
    
    Shockey: Draft currently focused on number portability, will look into
    other things (CNAM, probably global title translation). Feedback from 
    WG desired on other forms of PSTN SS7 data to be incorporated.
    
    Schiefner: Why data private?
    
    Shockey: Restrictions on npd in various jurisdictions, so service cannot happen in a public visible domain (IPsec or caching DNS structures)
    
    McCandless: Why registration if it happens in private space? People might starting use that in public space.
    
    Faltstrom: Private stuff always leaks into public space - registration prevents clashes, and should be performed in any case.
    ----
    
    ENUM validation drafts
    ======================
    
    draft-ietf-enum-validation-arch-00.txt,
    draft-ietf-enum-validation-token-00.txt
    draft-ietf-enum-validation-epp-01.txt)
    
    ----
    Bernie Hoeneisen & Alex Mayrhofer present updates to the three document.
    
    ENUM validation is checking that only the one who owns the number gets
    the ENUM registration. Three drafts: Architecture, transport of validation data via EPP, and validation data format.
    
    Changes to architecture: Name change to reflect WG acceptance, minor 
    cleanups. Changes to EPP draft: Aligned with other two drafts, input 
    on ID attribute baked in document. Changes to validation token: 
    added number range option (input from Sweden), synchronize tag names 
    with IRIS EREG and other drafts, cleanup. Will probably look at SAML,
    which was not considered yet. Requesting input from GEOPRIV because 
    of civic address format. 
    
    No comments.
    Next steps?
    
    Meeting is concluded.
    ----
    
    Issues posted to the list after the meeting
    ===========================================
    
    IANA Registration for an ENUMservice Containing PSTN Signaling Information
    
    Livingood noted: that during my presentation on "draft-ietf-enum-pstn-00" the following issues were discussed and decided upon:
    
    1.  Minor nits with the draft will be resolved and I will re-submit to
    up-rev to -01.
    
    2.  Must revisit the section on Distribution of Data to note that it may or may not be done on a private basis.  This will be primarily determined based on regulatory requirements in a particular country.  I
    have not determined the exact wording of this yet.
    
    3.  After fixing the nits and word-smithing #2 above (resulting in -01),we will work on -02 with new suggested data types.  These include CNAM and 800 number data, per feedback from Kevin McCandless.  (This would not include Global Title Translation - which was a question raised by the co-chair.)  The co-authors are open to any other suggestions.
    
    Separately, the need was again confirmed for a guide to creating an
    ENUMservice I-D.  This work will be undertaken by members of the WG in
    the near future.
    
    Regards
    Jason Livingood
    ----
    
    One issue raised during the discussion on Ed Guys IAX was to finally
    clarify the rules for subtyping of ENUMservices.
     
    1. should there be subtypes or not
    2. what should be used at subtypes (e.g. the URI)
     
    This discussion is not new, some years? ago it was discussed
    if you need subtypes indication the URI on the right side at all,
    because you just have to look at the right side of the NAPTR to see it
     
    So basically the registration template is indicating which URI are
    valid to be used with this ENUMservice type
     
    This was rejected because then a client is required to evaluate
    ALL NAPTRs for this ENUMservice type (including regexp) to find
    out the URI and then decide which object to take
     
    As stated by Patrik this must not be the case, it must
    be possible by the client to select the NAPTR only by the information
    in the ENUMservice field, taking stupid clients into account.
     
    Therefore the praxis was established to use subtypes indication the
    URI on the right side, and also to use the URI name itself, to avoid confusion, although this is not necessary. If only one URI is possible, no subtype is used (e.g. ENUMservice sip or H323).
     
    The only problem here exists when an ENUMservice is defined which
    contains at the moment only one URI, but MAY be expanded later
    with an additional URI.
     
    We (e.g. Lawrence, Rudi and I) prefer in this also to use a subtype
    (the URI), even if it seems not necessary, just to be on the save side
    for future extensions.
     
    My proposal is that in future all new ENUMservice registration SHOULD
    contain the URI as subtype
     
    regards
    Richard Stastny
    ----
    
    This was not brought up by me, but concerns our draft:
     
    The definitions and terminology used in 
    draft-haberler-carrier-enum-01 
    
    should be moved over and aligned with the definitions and terminology in
    
    draft-lind-infrastructure-enum-reqs-01
     
    Richard Stastny
    ----
    
    I think it's a vital point that Patrik and Richard schooled me on:  The fact that the IETF will make *no* judgments or statements about the appropriateness, precedence, or "conflict" resolution of NAPTRs in the User ENUM tree and the Carrier ENUM tree for the same TN.  The Carrier ENUM tree may very well have NAPTRs for any ENUM service type for a given TN, while NAPTRs for the same TN and the same ENUM service types, but with perhaps different URIs, may also reside in the User ENUM tree at the same time.  The decision on which tree to query, and perhaps in what order to query them, and perhaps how to resolve "conflicts" (I don't use the term "conflict" in a negative sense) is entirely up to the ENUM client application.   I had not heard this said before or seen it written, but it certainly simplifies the problem of having two trees.
     
    Kenneth Cartwright
    
    

    Slides

    Carrier ENUM Requirements
    ENUM PSTN Enumservice IANA Registration 00
    ENUM Experiences Plus
    Enumservice for VCard
    Enumservice Registration for IAX
    ENUM Validation 00
    User and Carrier ENUM in e164.arpa