As per Relevance of the word copyright, we have this rfc below:
Network Working Group R.
Request for Comments: 3026
Category: Informational January 2001
Liaison to IETF/ISOC on
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
Working Party 1/2, of the International Telecommunication
Telecommunication Standardization Sector (ITU-T) held a meeting
its collaborators in Berlin Germany 19-26 October 2000. The
of the meeting contained several contributions regarding RFC 2916:
"E.164 Number and DNS" from the Internet Engineering Task Force'
(IETF) ENUM Working Group - more specifically, the method
administering and maintaining the E.164-based resources in the
Name System (DNS) as related to the ENUM protocol. Consequently,
addition to the WP1/2 collaborators, there were several members
the IETF present to assist with the discussion of issues contained
the aforementioned contributions
This liaison from WP1/2 to the IETF/ISOC conveys the
of the WP1/2 collaborators resulting from the discussions
1. Considerations under Question 1/2 (Numbering
Throughout this document, the terms "administration"
"administrative functions" refer to the provision and update of
E.164 numerical values, to be contained in the zones of a domain
in the "e164.arpa" domain, in the DNS
It is noted that most ENUM service and administrative decisions
national issues under the purview of ITU Member States, since most
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
operational functions
Blane Informational [Page 1]
RFC 3026 Liaison to IETF/ISOC on ENUM January 2001
In order to advance a common terminology for the purpose of
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" (
in RFC 2916) is segmented into zones as follow
E164.arpa - domain
3.3. - country code zone (1, 2, or 3 digits dependent on CC
1.5.1.5.0.2.0.4.1. - national
The first understandings to be conveyed are those regarding
responsibilities for administration of the various zones within
"e164.arpa" domain
o The domain zone administration was agreed to be outside the
of this meeting and WP1/2.
o For all E.164 Country Code Zone resources (Country Codes
Identification Codes), the ITU has the responsibility to
assignment information to DNS administrators, for performing
administrative function. The ITU will ensure that each
State has authorized the inclusion of their Country
information for input to the DNS. For resources that are spare
designated as test codes there will normally be no entry in
DNS. However, the ITU will provide spare code lists to
administrators for purposes of clarification. The entity to
E.164 test codes have been assigned will be responsible
providing any appropriate assignment information to
administrators
o The administration of National Zone numbering information
determined by the type of Country Code resource that a
Zone is behind
* The national zone, for geographic resources, is a
matter and is, therefore, administered by the ITU
State(s) to which the country code is assigned. In
integrated numbering plan, e.g., CC "1", each Country
the plan may administer their portion of the resource in
different manner
* For national zone resources behind the Country Codes
to and shared by Networks, the entity to which the resource
assigned provides the E.164 assignment information, to
administrators for performing the administrative function
Blane Informational [Page 2]
RFC 3026 Liaison to IETF/ISOC on ENUM January 2001
* For national zone resources behind the Country Codes
to and shared by Groups of Countries, the administrative
identified by the Countries of the Group provides the E.164
assignment information, to DNS administrators, for
the administrative function. Note that the creation of
category is dependent upon the approval of draft
E.164.3.
o Each of the administrative entities responsible for
administration of resources within the zones (as identified above
is individually and separately responsible for ensuring that
administrators are aware of appropriate changes to their
once they have agreed to their input into the DNS
o Assigned geographic E.164 resources, for all zones, not
for input by the appropriate administrative entity will not
entered into the DNS under any circumstance. For example, if
ENUM service is not approved for use in a country, by
appropriate ITU Member States, the E.164 numbers of that
will not be input to the DNS
o With regard to Number Portability, it was agreed that WP1/2
further study this issue, in the context of ENUM. However, it
currently understood that this study and its result will
impact the IETF and its work
o The study being undertaken within WP1/2 (referred to above)
also attempt to identify options and provide guidance to
those entities charged with the task of providing
administrative information to DNS administrators
o All administrative entities, including DNS administrators,
adhere to all the applicable tenets of all pertinent
Recommendations, e.g., E.164, E.164.1, E.190, and E.195,
regard to the inclusion of the E.164 resource information in
DNS
o The ITU, IETF, and IAB will jointly cooperate fully to ensure
the agreed administrative procedures to accommodate the
understandings, and any other mutually agreed appropriate
understandings, will be implemented and adhered to on an
basis. The ITU may request the consultation of the WP1/2
as necessary and as prescribed in Resolution 20.
Blane Informational [Page 3]
RFC 3026 Liaison to IETF/ISOC on ENUM January 2001
2. Additional items below are from Q.10/2 Rapporteur Group (
Issues
o The issues surrounding number portability are to be addressed
the draft supplement to Recommendation E.370
o This issue surrounding freephone service was expanded to
other global services (i.e., International Premium Rate
and International Shared Cost Service). Preliminary
would indicate that routing the call to the
destination will depend on successfully receiving
about the geographic point of origination (e.g.,
"telephone Number"). A proxy server would process
information and either redirect or forward the call (based on
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
telephony carriers in such selection
The WP1/2 collaborators thank their IETF counterparts who
this meeting and assisted in the resolution of these issues
Any questions regarding the contents of this liaison should
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
information. Delegation and distributed administration is
according to DNS routines. The E.164 numbers are though
according to a different algorithm than domain names
This Liaison Statement describes how mapping E.164
administration and DNS administration can work together, and
further discussions are delegated to each administrative body for
country codes in E.164 space
If delegation and mapping is not done carefully between E.164 and
there is a risk of "napping" of E.164 numbers when they are stored
DNS. It is also important that the DNS strictly hierarchal system
preserved (see RFC 2826 [1]).
4.
[1] IAB, "IAB Technical Comment on the Unique DNS Root", RFC 2826,
May 2000.
Blane Informational [Page 4]
RFC 3026 Liaison to IETF/ISOC on ENUM January 2001
5. Author's
Roy
EMail: Roy_Blane@inmarsat.
URI: http://www.itu.
Blane Informational [Page 5]
RFC 3026 Liaison to IETF/ISOC on ENUM January 2001
6. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Blane Informational [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
