doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc3026.txt b/doc/rfc/rfc3026.txt
new file mode 100644
index 0000000..55f7f8b
--- /dev/null
+++ b/doc/rfc/rfc3026.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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.
+
+
+
+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 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.
+
+
+
+
+Blane                        Informational                      [Page 2]
+
+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
+         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.
+
+
+
+
+
+
+
+
+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 (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.
+
+
+
+
+Blane                        Informational                      [Page 4]
+
+RFC 3026              Liaison to IETF/ISOC on ENUM          January 2001
+
+
+5. Author's Address
+
+   Roy Blane
+   ITU
+
+   EMail: Roy_Blane@inmarsat.com
+   URI:   http://www.itu.int
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blane                        Informational                      [Page 5]
+
+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
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blane                        Informational                      [Page 6]
+