IANA MoU: Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority
The written agreement that says how IANA does protocol parameter work for the IETF.
Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, DOI 10.17487/RFC2860, June 2000, <https://www.rfc-editor.org/info/rfc2860>.
@misc{rfc2860,
series = {Request for Comments},
number = 2860,
howpublished = {RFC 2860},
publisher = {RFC Editor},
doi = {10.17487/RFC2860},
url = {https://www.rfc-editor.org/info/rfc2860},
author = {B. Carpenter and F. Baker and M. Roberts},
title = {{Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority}},
pagetotal = 7,
year = 2000,
month = jun,
} RFC text
Contents
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.
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
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.
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.
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.
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
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.
AI ELI5
On this page
§1What the MoU Is and Who Signed It
RFC 2860 is an Informational document that records the text of a Memorandum of Understanding between the IETF and ICANN concerning the technical work of the Internet Assigned Numbers Authority (IANA). It was signed on March 1, 2000 and ratified by the ICANN Board on March 10, 2000.
The MoU's intent is exclusively to define the technical work IANA does on behalf of the IETF and the Internet Research Task Force (IRTF). ICANN may provide similar services to others for protocols outside the IETF's scope, and nothing in the MoU limits that. It stays in effect until changed or cancelled by mutual consent, or cancelled by either party with at least six months notice.
Two groups wrote down their deal about the people who keep the Internet's lists. Either one can end the deal if it gives six months warning.
§2The Parties and Terms
The MoU defines its players. IANA is a traditional name for the technical team that makes and publishes assignments of Internet protocol technical parameters, and that team is now part of ICANN. The IAB is an oversight committee of the IETF and is chartered to designate the IANA on behalf of the IETF. The IESG is a management committee of the IETF. The IRTF is overseen by the IAB, and the IRSG manages it.
It also defines the RFC series as the archival document series of the IETF, also used by the IRTF and by third parties, and ISOC as the not-for-profit corporation that supports the IETF.
Before the rules, the MoU says who everyone is: the team that keeps the lists, the committee that picks them, and the group that manages the rules.
§3How IANA Assigns Parameters
For protocols within the IETF's scope, ICANN agrees to make IANA follow the requirements in Section 4. IANA assigns and registers protocol parameters only as directed by the criteria and procedures in RFCs, including Proposed, Draft and full Internet Standards, Best Current Practice documents and any other RFC that calls for an IANA assignment. Where nothing is specified, or the text is ambiguous, IANA continues past and current practice unless the IESG directs otherwise.
In doubt or in a technical dispute, IANA seeks and follows technical guidance exclusively from the IESG, which may appoint an expert. IANA works with the IETF to develop missing criteria over time and adopts them when the IESG instructs it. If IANA and the IESG disagree technically, both seek guidance from the IAB, whose decision is final.
Domain names and IP address blocks raise policy issues beyond technical ones, and those policy issues are outside the scope of the MoU. Technical uses (such as domain names for inverse DNS lookup), specialised address blocks (such as multicast or anycast) and experimental assignments stay under Section 4.
The rule book says: hand out numbers exactly as the written rules say. If the rules are unclear, ask the IESG. If there is still an argument, the IAB decides.
§4Service Duties and Appeals
IANA must make information about each current assignment, including contact details for the assignee, available to the public on-line and free of charge. Assignments published in RFCs by the RFC Editor count as meeting this requirement.
IANA must provide on-line facilities for requesting assignments and either carry them out or deny them for non-conformance with technical requirements, in a timely manner. There is no charge without the consent of the IAB, and requests may be denied only on legitimate technical grounds. For protocols in the IETF's scope, denials can be appealed to the IESG and then the IAB.
IANA has non-voting liaison seats on appropriate IETF committees and reviews all documents in IETF Last Call, raising any issues of concern with the IESG. For parameters relevant to the IRTF, the IRTF and IRSG take the place of the IETF and IESG, and the IAB decides any question over which applies.
The list keepers must show the lists to everyone for free, answer requests quickly, and only say no for good technical reasons. If someone is told no, they can ask a higher group to look again.
§5Legal Terms and Effect
The general terms say the MoU does not make any party a partner, joint venturer, agent, principal or franchisee of another. No party may transfer its rights or obligations without the written consent of the other parties. The agreement needed approval or ratification by the ICANN Board of Directors, and ICANN's signatory was to use best efforts to deliver it within two months of signing.
If ICANN adopts a policy that prevents it from complying with Section 4 for technical domain names, specialised address blocks or experimental assignments, it must notify the IETF, which may then cancel the MoU. The RFC's security considerations say the document does not directly impact the security of the Internet.
The deal does not make the two groups business partners. If one group starts breaking the rules, the other can walk away.