RFC 3026

Liaison to IETF/ISOC on ENUM

📅 published January 2001, from ietf

RFC 3026: Liaison to IETF/ISOC on ENUM 💖

Okay bestie, here's the title block tea ☕ This is RFC 3026, called "Liaison to IETF/ISOC on ENUM." It was written by R. Blane (Roy Blane) from the ITU. The category is Informational, and the date is January 2001 📅 The header doesn't list anything it obsoletes or updates, so there's nothing to flag there 🫶

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 (C) The Internet Society (2001). All Rights Reserved.

Abstract 🌸

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 had several contributions about RFC 2916, "E.164 Number and DNS," from the IETF's ENUM Working Group. The main focus was how to administer and maintain the E.164-based resources in the Domain Name System (DNS) as they relate to the ENUM protocol 🔥 Since the IETF folks were there too, several of them helped talk through the issues in those contributions.

This liaison from WP1/2 to the IETF/ISOC shares what the WP1/2 collaborators agreed on after those discussions 💅

1. Considerations under Question 1/2 (Numbering) 🧚

Throughout this doc, "administration" or "administrative functions" means providing and updating the E.164 numerical values that live in the zones of a domain name in the e164.arpa domain, in the DNS. ✨

It's noted that most ENUM service and administrative decisions are national issues under the purview of ITU Member States, since most E.164 resources get used nationally 🌍

These understandings only cover providing E.164 information for DNS administrative functions. They are not about policy or operational functions 🙈

To keep everyone on the same page, they defined the zones of a domain name like this. Using the example domain name 1.5.1.5.0.2.0.4.1.3.3.e164.arpa (same as RFC 2916), it gets split into zones like so:

   E164.arpa - domain zone

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

   1.5.1.5.0.2.0.4.1. - national zone

The first understandings to share are about who is responsible for administering each zone inside e164.arpa 👑

  • The domain zone administration was agreed to be outside the scope of this meeting and WP1/2.
  • For all E.164 Country Code Zone resources (Country Codes and Identification Codes), the ITU is responsible for giving assignment information to DNS administrators, so they can do the administrative function. The ITU will make sure 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 give spare code lists to DNS administrators for clarification. The entity that was assigned E.164 test codes will be responsible for giving any appropriate assignment information to DNS administrators.
  • The administration of National Zone numbering information depends on what kind of Country Code resource a National Zone sits behind:
    • The national zone, for geographic resources, is a national matter, so it's administered by the ITU Member State(s) the country code is assigned to. In an integrated numbering plan, e.g., CC "1", each Country within the plan may administer its portion of the resource in a different manner.
    • For national zone resources behind Country Codes assigned to and shared by Networks, the entity the resource is assigned to provides the E.164 assignment information to DNS administrators, so they can do the administrative function.
    • For national zone resources behind 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, so they can do the administrative function. Note that the creation of this category is dependent upon the approval of draft Recommendation E.164.3. 🫣
  • Each administrative entity responsible for administering resources within the zones (as identified above) is individually and separately responsible for making sure DNS administrators know about appropriate changes to their resources, once they've agreed to their input into the DNS.
  • Assigned geographic E.164 resources, for all zones, that aren't authorized for input by the appropriate administrative entity will not be entered into the DNS under any circumstance. For example, if the ENUM service isn't approved for use in a country by the appropriate ITU Member States, that country's E.164 numbers will not be input to the DNS. 🚫
  • About Number Portability: WP1/2 agreed to study it further in the context of ENUM. For now, though, it's understood that this study and its result will not impact the IETF and its work. 💜
  • The study happening within WP1/2 (mentioned above) will also try to identify options and give guidance to help the entities doing the task of providing administrative information to DNS administrators. 🧭
  • 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, when including E.164 resource information in the DNS. 📚
  • The ITU, IETF, and IAB will jointly cooperate fully to make sure the agreed administrative procedures for the above understandings, and any other mutually agreed future understandings, are implemented and adhered to on an ongoing basis. The ITU may request consultation with WP1/2 experts as necessary and as prescribed in Resolution 20. 🤝

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

  • The issues surrounding number portability are going to be addressed in the draft supplement to Recommendation E.370.
  • The freephone service issue got expanded to cover other global services (i.e., International Premium Rate Service and International Shared Cost Service). Early findings suggest that routing the call to the right destination depends on successfully receiving information about the geographic point of origination (e.g., calling "telephone Number"). A proxy server would process that information and then either redirect or forward the call (based on the proxy owner's decision) to the right destination. 📞
  • The issue of selecting the IP gateway within a PSTN-to-IP call flow may depend on the options available to telephony carriers for that selection. 🌐

The WP1/2 collaborators thank their IETF counterparts who attended this meeting and helped resolve these issues 🫶

Any questions about this liaison should go 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) to store information. Delegation and distributed administration are done according to DNS routines. The E.164 numbers, though, are 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.

⚠️ Serious moment: if delegation and mapping aren't done carefully between E.164 and DNS, there is a risk of "napping" of E.164 numbers when they're stored in DNS. It's also important that the DNS strictly hierarchal system is preserved (see RFC 2826 [1]). Don't skip this one, bestie! 💀

4. References 📚

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

5. Author's Address 🦋

   Roy Blane
   ITU

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

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 English.

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 "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙏

Acknowledgement 🌈

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

📦 where this page comes from