TitleLiaison to IETF/ISOC on ENUM
AuthorR. Blane
DateJanuary 2001
Format:TXT, HTML

Network Working Group                                           R. Blane
Request for Comments: 3026                                           ITU
Category: Informational                                     January 2001

                      Liaison to IETF/ISOC on ENUM

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.


   Working Party 1/2, of the International Telecommunication Union
   Telecommunication Standardization Sector (ITU-T) held a meeting of
   its collaborators in Berlin Germany 19-26 October 2000.  The agenda
   of the meeting contained several contributions regarding RFC 2916:
   "E.164 Number and DNS" from the Internet Engineering Task Force's
   (IETF) ENUM Working Group - more specifically, the method for
   administering and maintaining the E.164-based resources in the Domain
   Name System (DNS) as related to the ENUM protocol.  Consequently, in
   addition to the WP1/2 collaborators, there were several members of
   the IETF present to assist with the discussion of issues contained in
   the aforementioned contributions.

   This liaison from WP1/2 to the IETF/ISOC conveys the understandings
   of the WP1/2 collaborators resulting from the discussions.

1. Considerations under Question 1/2 (Numbering)

   Throughout this document, the terms "administration" or
   "administrative functions" refer to the provision and update of the
   E.164 numerical values, to be contained in the zones of a domain name
   in the "e164.arpa" domain, in the DNS.

   It is noted that most ENUM service and administrative decisions are
   national issues under the purview of ITU Member States, since most of
   the E.164 resources are utilized nationally.

   These understandings are relative only to the provision of E.164
   information for DNS administrative functions, not policy or
   operational functions.

RFC 3026              Liaison to IETF/ISOC on ENUM          January 2001

   In order to advance a common terminology for the purpose of this
   liaison, we have defined the zones of a domain name as follows.

   Using an example, domain name "" (as
   in RFC 2916) is segmented into zones as follow:

      E164.arpa - domain zone

      3.3. - country code zone (1, 2, or 3 digits dependent on CC) - national zone

   The first understandings to be conveyed are those regarding the
   responsibilities for administration of the various zones within the
   "e164.arpa" domain:

   o  The domain zone administration was agreed to be outside the scope
      of this meeting and WP1/2.

   o  For all E.164 Country Code Zone resources (Country Codes and
      Identification Codes), the ITU has the responsibility to provide
      assignment information to DNS administrators, for performing the
      administrative function.  The ITU will ensure that each Member
      State has authorized the inclusion of their Country Code
      information for input to the DNS.  For resources that are spare or
      designated as test codes there will normally be no entry in the
      DNS.  However, the ITU will provide spare code lists to DNS
      administrators for purposes of clarification.  The entity to which
      E.164 test codes have been assigned will be responsible for
      providing any appropriate assignment information to DNS

   o  The administration of National Zone numbering information is
      determined by the type of Country Code resource that a National
      Zone is behind:

      *  The national zone, for geographic resources, is a national
         matter and is, therefore, administered by the ITU Member
         State(s) to which the country code is assigned.  In an
         integrated numbering plan, e.g., CC "1", each Country within
         the plan may administer their portion of the resource in a
         different manner.

      *  For national zone resources behind the Country Codes assigned
         to and shared by Networks, the entity to which the resource is
         assigned provides the E.164 assignment information, to DNS
         administrators for performing the administrative function.

RFC 3026              Liaison to IETF/ISOC on ENUM          January 2001

      *  For national zone resources behind the Country Codes assigned
         to and shared by Groups of Countries, the administrative entity
         identified by the Countries of the Group provides the E.164
         assignment information, to DNS administrators, for performing
         the administrative function.  Note that the creation of this
         category is dependent upon the approval of draft Recommendation

   o  Each of the administrative entities responsible for the
      administration of resources within the zones (as identified above)
      is individually and separately responsible for ensuring that DNS
      administrators are aware of appropriate changes to their resources
      once they have agreed to their input into the DNS.

   o  Assigned geographic E.164 resources, for all zones, not authorized
      for input by the appropriate administrative entity will not be
      entered into the DNS under any circumstance.  For example, if the
      ENUM service is not approved for use in a country, by the
      appropriate ITU Member States, the E.164 numbers of that country
      will not be input to the DNS.

   o  With regard to Number Portability, it was agreed that WP1/2 would
      further study this issue, in the context of ENUM.  However, it is
      currently understood that this study and its result will not
      impact the IETF and its work.

   o  The study being undertaken within WP1/2 (referred to above) will
      also attempt to identify options and provide guidance to assist
      those entities charged with the task of providing the
      administrative information to DNS administrators.

   o  All administrative entities, including DNS administrators, will
      adhere to all the applicable tenets of all pertinent ITU
      Recommendations, e.g., E.164, E.164.1, E.190, and E.195, with
      regard to the inclusion of the E.164 resource information in the

   o  The ITU, IETF, and IAB will jointly cooperate fully to ensure that
      the agreed administrative procedures to accommodate the above
      understandings, and any other mutually agreed appropriate future
      understandings, will be implemented and adhered to on an ongoing
      basis.  The ITU may request the consultation of the WP1/2 experts
      as necessary and as prescribed in Resolution 20.

RFC 3026              Liaison to IETF/ISOC on ENUM          January 2001

2. Additional items below are from Q.10/2 Rapporteur Group (Service

   o  The issues surrounding number portability are to be addressed in
      the draft supplement to Recommendation E.370

   o  This issue surrounding freephone service was expanded to include
      other global services (i.e., International Premium Rate Service
      and International Shared Cost Service).  Preliminary findings
      would indicate that routing the call to the appropriate
      destination will depend on successfully receiving information
      about the geographic point of origination (e.g., calling
      "telephone Number").  A proxy server would process such
      information and either redirect or forward the call (based on the
      proxy owner's decision) on to the appropriate destination.

   o  The issue surrounding selection of the IP gateway within a PSTN-
      to-IP call flow may depend on options that may be available to
      telephony carriers in such selection.

   The WP1/2 collaborators thank their IETF counterparts who attended
   this meeting and assisted in the resolution of these issues.

   Any questions regarding the contents of this liaison should be
   referred to the WP1/2 Chairman Roy Blane at Roy_Blane@inmarsat.com.

3. Security Considerations (added by the IESG)

   The ENUM solution uses the Domain Name System (DNS) for storage of
   information.  Delegation and distributed administration is done
   according to DNS routines.  The E.164 numbers are though distributed
   according to a different algorithm than domain names.

   This Liaison Statement describes how mapping E.164 number
   administration and DNS administration can work together, and how
   further discussions are delegated to each administrative body for the
   country codes in E.164 space.

   If delegation and mapping is not done carefully between E.164 and DNS
   there is a risk of "napping" of E.164 numbers when they are stored in
   DNS.  It is also important that the DNS strictly hierarchal system is
   preserved (see RFC 2826 [1]).

4. References

   [1] IAB, "IAB Technical Comment on the Unique DNS Root", RFC 2826,
       May 2000.

RFC 3026              Liaison to IETF/ISOC on ENUM          January 2001

5. Author's Address

   Roy Blane

   EMail: Roy_Blane@inmarsat.com
   URI:   http://www.itu.int

RFC 3026              Liaison to IETF/ISOC on ENUM          January 2001

6. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an


   Funding for the RFC Editor function is currently provided by the
   Internet Society.