RFC 2860
Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority
RFC 2860: Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority π
Written by Brian Carpenter (IAB), Fred Baker (IETF), and Michael M. Roberts (ICANN) π. It's an Informational doc from the Network Working Group, dated June 2000 π¦. Its header doesn't list anything it obsoletes or updates.
Status of this Memo β¨
This memo gives information to the Internet community. It doesn't specify an Internet standard of any kind π. Distribution is unlimited π.
Copyright Notice π
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract π§
This doc puts the MoU text on record. It's the agreement about the IANA's technical work that the IETF and ICANN signed on March 1, 2000, and the ICANN Board ratified on March 10, 2000 π₯.
MoU text as signed π
MEMORANDUM OF UNDERSTANDING CONCERNING THE TECHNICAL WORK OF THE INTERNET ASSIGNED NUMBERS AUTHORITY
- This Memorandum of Understanding ("MOU") is an agreement between the Internet Engineering Task Force and the Internet Corporation for Assigned Names and Numbers. Its only purpose is to define the technical work the Internet Assigned Numbers Authority does on behalf of the Internet Engineering Task Force and the Internet Research Task Force. ICANN may, through the IANA, offer similar services to other organisations for protocols outside IETF's scope (that is, registries not created by IETF or IRTF action). Nothing in this MOU limits ICANN's ability to do that π.
- This MOU stays in effect until it's modified or cancelled by mutual consent of the Internet Engineering Task Force and the Internet Corporation for Assigned Names and Numbers. It can also be cancelled by either party with at least six (6) months notice β³.
- 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 for the technical team that makes and publishes 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 that name, which 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.
- 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. ICANN and IETF acknowledge that these 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. That includes Proposed, Draft and full Internet Standards, Best Current Practice documents, and any other RFC that calls for IANA assignment. If those criteria aren't specified, or if there's ambiguity, IANA will keep assigning and registering the Internet protocol parameters it has traditionally registered. It follows past and current practice for those assignments, unless the IESG directs otherwise π.
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. IANA will adopt them when the IESG instructs it to πΈ.
4.2. If there's a technical dispute between the IANA and the IESG, both will seek guidance from the IAB, whose decision shall be final. That's the end of the discussion π.
4.3. Two particular assigned spaces raise policy issues on top of the technical considerations the IETF specifies: 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. They shall remain subject to the provisions of this Section 4. (For purposes of this MOU, the term "assignments" includes allocations.) If ICANN adopts a policy that stops it from complying with the provisions of this Section 4 for the assignments described in (a) - (c) above, ICANN will notify the IETF. The IETF may then exercise its ability to cancel this MOU under Section 2 above π¨.
4.4. The IANA shall make information about each current assignment available to the public, online and free of charge. That includes 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 online facilities for the public to request Internet protocol parameter assignments. It shall either execute those 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 π .
For protocols within the IETF scope (that is, registries created by IETF action), appeals against such denials may be made to the IESG, and then to the IAB as provided in 4.2 above βοΈ.
4.6. The IANA shall have non-voting liaison seats on appropriate IETF committees, as the IETF determines. It may take part in all IETF discussions about technical requirements for protocol parameter assignment through those liaisons π¦.
4.7. The IANA shall review all documents in IETF Last Call to find any issues of concern to the IANA. It shall raise those issues with the IESG π.
- Application to IRTF/IRSG. The parties understand that some of the protocol parameters IANA assigns will be relevant to the IRTF rather than the IETF. For those parameters, IANA will follow the procedures in Section 4, with IRTF and IRSG substituted for IETF and IESG, respectively, in those procedures. If there's any question about whether a particular protocol parameter relates principally to the IETF or the IRTF, the IAB has the authority to answer it at its discretion π.
- General. This MOU doesn't make any of the parties a partner, joint venturer, agent, principal or franchisee of another party. Waiving any provision of this MOU on one occasion doesn't count as a waiver for 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 π.
- Effectiveness of MOU. This Agreement needs the approval or ratification of the ICANN Board of Directors. The ICANN signatory shall use his best efforts to secure and deliver that approval or ratification to the IETF within two months of signing β°.
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. Phew, we're all good on this one π.
Acknowledgements π«Ά
The technical heart of this doc was discussed in the IETF POISSON working group in 1998 and 1999, and the IESG and IAB reviewed it. Jorge Contreras, Joyce K. Reynolds, and Louis Touton helped finish it π.
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
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. 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. This is 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. The exceptions are needed for 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 β¨.
π¦ where this page comes from
- ietf: rfc2860 2000-06
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms