Liaison to IETF/ISOC on ENUM
A letter from an ITU-T working party on who supplies telephone-number data for DNS-based ENUM.
Blane, R., "Liaison to IETF/ISOC on ENUM", RFC 3026, DOI 10.17487/RFC3026, January 2001, <https://www.rfc-editor.org/info/rfc3026>.
@misc{rfc3026,
series = {Request for Comments},
number = 3026,
howpublished = {RFC 3026},
publisher = {RFC Editor},
doi = {10.17487/RFC3026},
url = {https://www.rfc-editor.org/info/rfc3026},
author = {R. Blane},
title = {{Liaison to IETF/ISOC on ENUM}},
pagetotal = 6,
year = 2001,
month = jan,
} RFC text
Contents
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.
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
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.
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 "1.5.1.5.0.2.0.4.1.3.3.e164.arpa" (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)
1.5.1.5.0.2.0.4.1. - 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
administrators.
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.
* 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
E.164.3.
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
DNS.
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.
2. Additional items below are from Q.10/2 Rapporteur Group (Service
Issues)
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.
5. Author's Address
Roy Blane
ITU
EMail: Roy_Blane@inmarsat.com
URI: http://www.itu.int
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
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.
AI ELI5
On this page
§1A Liaison From ITU-T to the IETF
Working Party 1/2 of the ITU-T held a meeting of its collaborators in Berlin, Germany, on 19-26 October 2000. Several contributions on the agenda concerned RFC 2916, E.164 Number and DNS from the IETF ENUM Working Group, and how E.164-based resources are administered in the DNS. Several IETF members attended to help with the discussion.
This memo is the resulting liaison: a statement from the working party to the IETF and ISOC that records what the collaborators understood after the talks. It covers only the provision and update of E.164 numerical values in the DNS, not policy or operational functions. It notes that most ENUM service and administrative decisions are national issues under the purview of ITU Member States.
A group of phone experts met and talked with some Internet experts. This letter writes down what they all agreed on.
§1Zones of an e164.arpa Name
To talk about responsibility, the memo defines three zones using the example name 1.5.1.5.0.2.0.4.1.3.3.e164.arpa (as in RFC 2916):
- Domain zone:
e164.arpaitself. - Country code zone:
3.3., which is 1, 2 or 3 digits depending on the country code. - National zone:
1.5.1.5.0.2.0.4.1., the rest of the number.
The term administration here means providing and updating the E.164 values that go into the zones of a domain name in the e164.arpa domain.
A phone number is read backwards like an address: country first, then the rest. The letter gives each part a name so everyone can say who looks after it.
- e164.arpa domain zone
- 3.3. country code zone
- 1.5.1.5.0.2.0.4.1. national zone
- 3.3. country code zone
§1Who Administers What
Administration of the domain zone was agreed to be outside the scope of the meeting and the working party. For the rest:
- Country code zone: the ITU provides assignment information to DNS administrators and ensures each Member State has authorized including its country code. Spare or test codes normally get no DNS entry. The entity holding a test code supplies its own assignment information.
- National zone, geographic resources: a national matter, administered by the Member State(s) holding the country code. In an integrated plan such as country code 1, each country may administer its portion differently.
- National zone, codes shared by networks: the entity the resource is assigned to provides the information.
- National zone, codes shared by groups of countries: the administrative entity named by the countries of the group provides it. This category depends on approval of draft Recommendation E.164.3.
Each administrative entity is separately responsible for telling DNS administrators about later changes. Assigned geographic numbers that the right entity has not authorized are never entered into the DNS. For example, if a country has not approved ENUM, its numbers are not entered. All parties are to follow the pertinent ITU Recommendations, for example E.164, E.164.1, E.190 and E.195.
Think of a big phone book with sections. The country's section is filled in by the world phone club, each country fills in its own pages, and nobody writes a page the owner has not approved.
§2Number Portability and Service Issues
On number portability, the working party agreed to study it further in the context of ENUM, and understood that the study would not affect the IETF's work. The study will also try to identify options and guidance for those who supply administrative information to DNS administrators. Portability issues are to be addressed in a draft supplement to Recommendation E.370.
Items from the Q.10/2 Rapporteur Group on service issues cover freephone service, widened to include International Premium Rate Service and International Shared Cost Service. Preliminary findings were that routing such a call depends on learning the geographic point of origination, for example the calling number, and that a proxy server would then redirect or forward the call. Choice of the IP gateway in a PSTN-to-IP call flow may depend on options available to telephony carriers.
There were still open questions, like what happens when you keep your phone number but switch companies. The group said it would keep studying them.
§3Security Considerations Added by the IESG
The IESG added a short security section. ENUM stores its information in the DNS, and delegation and distributed administration follow DNS routines, while E.164 numbers are distributed by a different algorithm than domain names.
If delegation and mapping between E.164 and DNS are not done carefully, there is a risk of napping of E.164 numbers when they are stored in the DNS. It is also important to preserve the strictly hierarchical DNS (see RFC 2826).
If the two phone books are not lined up carefully, someone could grab a number that belongs to someone else. The DNS also has to stay one tidy tree.