Source:
ITU-T Working Party 1/2, Berlin, 19-26 October 2000
Title:
Liaison to IETF/ISOC on ENUM
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
function” 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:
·
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 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.
·
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.
·
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.
·
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.
·
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.
·
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.
·
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.
·
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)
·
The issues surrounding number portability are to be addressed in
the draft supplement to Recommendation E.370
·
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.
·
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.