ENUM Working Group
   Internet Draft                                               S. Lind
   Document: draft-lind-infrastructure-enum-reqs-                  AT&T
   Expires: January 2006                                      July 2005

                     Infrastructure ENUM Requirements

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [i].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79."

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   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

Lind                    Expires - January 2006                [Page 1]

                   Infrastructure ENUM Requirements          July 2005

   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

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [ii].

Table of Contents

   1. Infrastructure ENUM............................................3
      1.1 Definition.................................................3
      1.2 Importance.................................................3
   2. Requirements of Infrastructure ENUM............................4
      2.1 Provisioning Requirements..................................4
      2.2 Architecture Requirements..................................5
      2.3 Application Behavior Requirements..........................5
   3. Security Considerations........................................6
   4. References.....................................................6
   5. Author's Addresses.............................................7
   6. Intellectual Property Statement................................7
   7. Disclaimer of Validity.........................................8
   8. Copyright Statement............................................8

Lind                    Expires - January 2006                [Page 2]

                   Infrastructure ENUM Requirements          July 2005

1.   Infrastructure ENUM

1.1    Definition

     a. Infrastructure ENUM is defined as the use of RFC 3761 [iii] by
        the carrier-of-record for a specific E.164 number [iv] to
        translate into a URI that specifies a specific point of
        interconnection to that service providerÆs network that could
        enable the originating party to establish communication with
        associated terminating party. It is separate from any URIs that
        the end-user, who registers their E.164 number, may wish to
        associate with that E.164 number.

     b. Carriers use E.164 numbers currently as their main naming and
        routing vehicle. Carrier ENUM in e164.arpa or another public
        available tree allows Carriers to link Internet based resources
        such as URIs to E.164 numbers (Note: this is the other way round
        then User ENUM). This allows Carrier in addition to
        interconnecting via the PSTN (or exclusively) to peer via IP-
        based protocols. Carriers may announce all E.164 numbers or
        number ranges they host, regardless if the final end-user device
        is on the Internet, on IP-based closed NGNs or on the PSTN,
        provided an access (e.g. SBC or gateway) to the destination
        carriers network is available on the Internet. There is also no
        guarantee that the originating carrier querying Carrier ENUM
        that is able to access the ingress network element of the
        destination carriers network. Additional peering and accounting
        agreements requiring authentication may be necessary. The access
        provided may also be to a shared network of a group of carriers,
        resolving the final destination network within the shared

1.2    Importance

   User ENUM in many countries requires end user opt-in and may give the
   end user the right to select the Tier 2 that hosts the terminal NAPTR
   records. These constraints are problematic for interconnection which
   requires registration for all served numbers and carrier control of
   Tier 2 to ensure reliability.

   With the move towards all IP networks applications, interworking must
   be addressed in order to facilitate global interoperability.
   Different networks should interwork with each other through secure
   interfaces that provide a high level of trust, particularly with
   regard to any routing information obtained from an ENUM database.
   Consideration must be given to how each network will interwork with
   other networks.

Lind                    Expires - January 2006                [Page 3]

                   Infrastructure ENUM Requirements          July 2005

   Until now ENUM according to RFC3761 in e164.arpa (User ENUM) has not
   been seen as useful to an NGN/Telco/VoIP provider as it is reliant on
   user action in terms of registration, insertion of data and
   management of that data. Additionally, there is also controversy
   regarding the inclusion of data within the NAPTR records which may be
   publicly exposed in User ENUM.

2.   Requirements of Infrastructure ENUM

   For ease in thinking about these requirements and how any proposed
   implementation might address them, they have been divided into three
   categories: provisioning, architecture, and application behavior.

2.1    Provisioning Requirements

     a. It should not require the introduction of new constructs within
        existing standards, such as new types or changed semantics of
        NAPTR records.

     b. The impact on existing implementations of User ENUM should be
        kept to a minimum. This implies that modifications to existing
        RFCs e.g. 3761, 3401-4 should be avoided.

     c. It should keep the option open for other types of closed-user-
        group type applications, which might not naturally fit into the
        predominantly voice-oriented - carrier ENUM scenario, like SMS
        or MMS POI resolution.

     d. Infrastructure ENUM should not remove the need for
        authentication that the party inserting, modifying or removing
        data in NAPTR records has a right to the corresponding number.
        Authentication is still required and an appropriate
        authentication procedure needs to be in place between the ENUM
        Tier 1 Registry and the carrier serving the number.

     e. Implementation of Infrastructure ENUM should not impact the
        ability of an end-user, in a competitive environment, to choose
        a Registrar and/or Tier 2 name server provider for end-user ENUM

     f. Designated DNS infrastructure for housing Infrastructure ENUM-
        related NAPTR records should have ôcarrier-classö reliability
        and performance.

Lind                    Expires - January 2006                [Page 4]

                   Infrastructure ENUM Requirements          July 2005

2.2    Architecture Requirements

     a. It should meet all reasonable privacy concerns about visibility
        of information an end user has no control over, for example
        discovery of unlisted numbers, or inadvertent disclosure of user

     b. provide information on how to route a service to a point of
        carrier interconnection or ALG as expressed as a URI. For
        privacy and or network security reasons this information may_
        need to be restricted to service providers and not generally
        available to end users. [editorÆs note: some have argued that
        they might provide a carrier record that generally points to a
        public interconnection point, but would provide pointers to
        specific interconnection points for specific interconnecting
        network providers.]

     c. It should be possible to introduce the scheme in a timely
        manner, supporting current carrier needs.  Consequently, it is
        desirable to deploy the scheme without re-opening already
        settled questions of roles, responsibilities and international

     d. It should leave tree shape intact, i.e. requiring no wholesale
        changes to existing tree layout.

     e. It should be applicable for use with all national numbering
        plans; particular challenges may be to ensure that a global
        implementation is compatible with the use of variable length
        numbering (e.g. as used in Germany and Austria) and DDI blocks.

     f. It should work with both closed and open number plans without
        resorting to wildcard records in the non-user controlled part of
        the DNS, both to avoid associated semantic problems as well as
        keeping the route to DNSSEC deployment open.

     g. Some other groups, such as the GSM-A, have already decided to
        use a separate domain of their own for infrastructure ENUM
        purposes; e.g. "e164enum.net". The envisaged solution should
        also include these ENUM domains within a global ENUM
        infrastructure or at least to allow and facilitate interworking
        between these different domains.

2.3    Application Behavior Requirements

Lind                    Expires - January 2006                [Page 5]

                   Infrastructure ENUM Requirements          July 2005

     a. A dialed E.164 number using ENUM should enable a call to go

     b. A single DNS lookup should suffice to resolve any given number.

     c. A minimum number (ideally one) of independent lookups should be
        required to obtain as many NAPTR records (end-user and carrier)
        as possible.

     d. A minimum number (ideally zero) of dependent lookups should be
        required to obtain as many NAPTR records (end-user and carrier)
        as possible.

     e. Additional functionality should only be imposed on carrier

     f. It should leave user ENUM resolution semantics intact, i.e.
        requiring no wholesale changes to existing user ENUM resolvers.

     g. Pre-existing knowledge of the numbering format should be kept to
        a minimum.

3.   Security Considerations

   Existing security considerations for ENUM detailed in RFC 3761 still
   apply.  Note that some registration validation issues concerning end
   user ENUM may not apply to carrier ENUM.  Where the Tier 1 registry
   is able to identify the carrier serving a number (e.g., based on
   industry data for number block assignments and number portability),
   registration might be more easily automated and a separate registrar
   not required.

4.   References

   i  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   ii  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   iii Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
      Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
      Application (ENUM)", RFC 3761, April 2004.

Lind                    Expires - January 2006                [Page 6]

                   Infrastructure ENUM Requirements          July 2005

   iv ITU-T, "The International Public Telecommunication Number Plan",
      Recommendation E.164, May 1997.

5.   Author's Addresses

   Steven D. Lind
   Room A201
   180 Park Avenue
   Florham Park, NJ 07932
   Phone: +1-973-236-6787
   Email: sdlind@att.com

6.   Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed

Lind                    Expires - January 2006                [Page 7]

                   Infrastructure ENUM Requirements          July 2005

7.   Disclaimer of Validity

   This document and the information contained herein are provided on an

8.   Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Lind                    Expires - January 2006                [Page 8]