doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc2860.txt b/doc/rfc/rfc2860.txt
new file mode 100644
index 0000000..27fb697
--- /dev/null
+++ b/doc/rfc/rfc2860.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                       B. Carpenter
+Request for Comments: 2860                                           IAB
+Category: Informational                                         F. Baker
+                                                                    IETF
+                                                              M. Roberts
+                                                                   ICANN
+                                                               June 2000
+
+
+          Memorandum of Understanding Concerning the Technical
+            Work of the Internet Assigned Numbers Authority
+
+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 (2000).  All Rights Reserved.
+
+Abstract
+
+   This document places on record the text of the Memorandum of
+   Understanding concerning the technical work of the IANA that was
+   signed on March 1, 2000 between the IETF and ICANN, and ratified by
+   the ICANN Board on March 10, 2000.
+
+MoU text as signed
+
+   MEMORANDUM OF UNDERSTANDING CONCERNING THE TECHNICAL WORK OF THE
+   INTERNET ASSIGNED NUMBERS AUTHORITY
+
+   1. This Memorandum of Understanding ("MOU") defines an agreement
+   between the Internet Engineering Task Force and the Internet
+   Corporation for Assigned Names and Numbers. Its intent is exclusively
+   to define the technical work to be carried out by the Internet
+   Assigned Numbers Authority on behalf of the Internet Engineering Task
+   Force and the Internet Research Task Force.  It is recognized that
+   ICANN may, through the IANA, provide similar services to other
+   organisations with respect to protocols not within IETF's scope (i.e.
+   registries not created by IETF or IRTF action); nothing in this MOU
+   limits ICANN's ability to do so.
+
+
+
+
+
+
+
+Carpenter, et al.            Informational                      [Page 1]
+
+RFC 2860       MoU Between IETF and ICANN concerning IANA      June 2000
+
+
+   2. This MOU will remain in effect until either modified or cancelled
+   by mutual consent of the Internet Engineering Task Force and the
+   Internet Corporation for Assigned Names and Numbers, or cancelled by
+   either party with at least six (6) months notice.
+
+   3. Definition of terms and abbreviations used in this document.
+
+   ICANN - Internet Corporation for Assigned Names and Numbers, a
+   California non-profit corporation.
+
+   IANA - Internet Assigned Numbers Authority (a traditional name, used
+   here to refer to the technical team making and publishing the
+   assignments of Internet protocol technical parameters). The IANA
+   technical team is now part of ICANN.
+
+   IETF - the Internet Engineering Task Force, the unincorporated
+   association operating under such name that creates Internet Standards
+   and related documents.
+
+   IAB -  the Internet Architecture Board, an oversight committee of the
+   IETF. The IAB is chartered to designate the IANA on behalf of the
+   IETF.
+
+   IESG - the Internet Engineering Steering Group, a management
+   committee of the IETF.
+
+   IRTF - the Internet Research Task Force, an unincorporated
+   association also overseen by the IAB.
+
+   IRSG - the Internet Research Steering group, a management committee
+   of the IRTF.
+
+   RFC -  "Request For Comments", the archival document series of the
+   IETF, also used by the IRTF and by third parties.
+
+   ISOC - the Internet Society, a not-for-profit corporation that
+   supports the IETF.
+
+   4. Agreed technical work items.  ICANN agrees that during the term of
+   this MOU it shall cause IANA to comply,  for protocols within IETF's
+   scope, with the following requirements, which ICANN and IETF
+   acknowledge reflect the existing arrangements under which the IANA is
+   operated:
+
+   4.1. The IANA will assign and register Internet protocol parameters
+   only as directed by the criteria and procedures specified in RFCs,
+   including Proposed, Draft and full Internet Standards and Best
+   Current Practice documents, and any other RFC that calls for IANA
+
+
+
+Carpenter, et al.            Informational                      [Page 2]
+
+RFC 2860       MoU Between IETF and ICANN concerning IANA      June 2000
+
+
+   assignment. If they are not so specified, or in case of ambiguity,
+   IANA will continue to assign and register Internet protocol
+   parameters that have traditionally been registered by IANA, following
+   past and current practice for such assignments, unless otherwise
+   directed by the IESG.
+
+   If in doubt or in case of a technical dispute, IANA will seek and
+   follow technical guidance exclusively from the IESG. Where
+   appropriate the IESG will appoint an expert to advise IANA.
+
+   The IANA will work with the IETF to develop any missing criteria and
+   procedures over time, which the IANA will adopt when so instructed by
+   the IESG.
+
+   4.2. In the event of technical dispute between the IANA and the IESG,
+   both will seek guidance from the IAB whose decision shall be final.
+
+   4.3. Two particular assigned spaces present policy issues in addition
+   to the technical considerations specified by the IETF: the assignment
+   of domain names, and the assignment of IP address blocks. These
+   policy issues are outside the scope of this MOU.
+
+   Note that (a) assignments of domain names for technical uses (such as
+   domain names for inverse DNS lookup), (b) assignments of specialised
+   address blocks (such as multicast or anycast blocks), and (c)
+   experimental assignments are not considered to be policy issues, and
+   shall remain subject to the provisions of this Section 4.  (For
+   purposes of this MOU, the term "assignments" includes allocations.)
+   In the event ICANN adopts a policy that prevents it from complying
+   with the provisions of this Section 4 with respect to the assignments
+   described in (a) - (c) above, ICANN will notify the IETF, which may
+   then exercise its ability to cancel this MOU under Section 2 above.
+
+   4.4. The IANA shall make available to the public, on-line and free of
+   charge, information about each current assignment, including contact
+   details for the assignee.  Assignments published in RFCs by the RFC
+   Editor and available publicly will be deemed to meet the requirements
+   of this Section 4.4.
+
+   4.5. The IANA shall provide on-line facilities for the public to
+   request Internet protocol parameter assignments and shall either
+   execute such assignments, or deny them for non- conformance with
+   applicable technical requirements, in a timely manner. There shall be
+   no charge for assignments without the consent of the IAB. Requests
+   shall only be denied on legitimate technical grounds.
+
+
+
+
+
+
+Carpenter, et al.            Informational                      [Page 3]
+
+RFC 2860       MoU Between IETF and ICANN concerning IANA      June 2000
+
+
+   For protocols within the IETF scope (i.e., registries created by IETF
+   action), appeals against such denials may be made to the IESG and
+   subsequently to the IAB as provided in 4.2 above.
+
+   4.6. The IANA shall have non-voting liaison seats on appropriate IETF
+   committees as determined by the IETF, and may participate in all IETF
+   discussions concerning technical requirements for protocol parameter
+   assignment through such liaisons.
+
+   4.7. The IANA shall review all documents in IETF Last Call to
+   identify any issues of concern to the IANA, and shall raise these
+   issues with the IESG.
+
+   5.  Application to IRTF/IRSG.  The parties understand that certain of
+   the protocol parameters to be assigned by IANA will be relevant to
+   IRTF, rather than IETF. With respect to these protocol parameters,
+   IANA will comply with the procedures set forth in Section 4, with the
+   understanding that IRTF and IRSG shall be substituted for IETF and
+   IESG, respectively, in such procedures. In the event of any question
+   as to whether a particular protocol parameter relates principally to
+   IETF or IRTF, the IAB shall have the authority to answer such
+   question in its discretion.
+
+   6.  General.  This MOU does not constitute any of the parties as a
+   partner, joint venturer, agent, principal or franchisee of any other
+   party. The waiver of any provision of this MOU on any occasion shall
+   not constitute a waiver for purposes of any other occasion.  No party
+   may transfer or assign any interest, right or obligation arising
+   under this MOU without the prior written consent of each other party
+   to this MOU.
+
+   7.  Effectiveness of MOU.  This Agreement requires the approval or
+   ratification of the ICANN Board of Directors.  The signatory for
+   ICANN shall use his best efforts to secure and deliver to IETF such
+   approval or ratification within two months of signing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter, et al.            Informational                      [Page 4]
+
+RFC 2860       MoU Between IETF and ICANN concerning IANA      June 2000
+
+
+   IN WITNESS WHEREOF, this Memorandum of Understanding is executed as
+   of this first day of March 2000 by the undersigned, acting through
+   their duly authorized representatives:
+
+   INTERNET ENGINEERING TASK FORCE
+
+
+   By: __________________________ Fred Baker, IETF Chair
+
+   Approved by:
+
+   INTERNET ARCHITECTURE BOARD
+
+
+   By: __________________________ Brian Carpenter, IAB Chair
+
+   INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS
+
+
+   By:___________________________ Mike Roberts, President
+
+
+Security considerations
+
+   This document does not directly impact the security of the Internet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter, et al.            Informational                      [Page 5]
+
+RFC 2860       MoU Between IETF and ICANN concerning IANA      June 2000
+
+
+Acknowledgements
+
+   The technical heart of this document was discussed in the IETF
+   POISSON working group in 1998 and 1999 and reviewed by the IESG and
+   IAB. Jorge Contreras, Joyce K. Reynolds, and Louis Touton assisted in
+   its finalisation.
+
+Authors' Addresses
+
+   Brian E. Carpenter
+   iCAIR
+   Suite 150
+   1890 Maple Avenue
+   Evanston IL 60201
+   USA
+
+   EMail: brian@icair.org
+
+
+   Fred Baker
+   519 Lado Drive
+   Santa Barbara, CA 93111
+   USA
+
+   EMail: fred@cisco.com
+
+
+   Michael M. Roberts
+   Internet Corporation for Assigned Names and Numbers (ICANN)
+   4676 Admiralty Way, Suite 330
+   Marina del Rey, CA 90292
+   USA
+
+   EMail: roberts@icann.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter, et al.            Informational                      [Page 6]
+
+RFC 2860       MoU Between IETF and ICANN concerning IANA      June 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter, et al.            Informational                      [Page 7]
+