idnits 2.17.1 draft-iab-iana-mou-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 1) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 1, 2000) is 8816 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IAB B. Carpenter 2 Internet Draft F. Baker 3 March 2000 M. Roberts 5 Memorandum of Understanding Concerning the Technical 6 Work of the Internet Assigned Numbers Authority 8 Copyright Notice 10 If published as an RFC this document will become 11 Copyright (C) The Internet Society (2000). All Rights Reserved. 13 Abstract 15 draft-iab-iana-mou-00.txt 17 This document places on record the text of the Memorandum of Understanding 18 concerning the technical work of the IANA that was signed on March 1, 2000 19 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 20 2000. 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet- Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 1. MoU text as signed 45 MEMORANDUM OF UNDERSTANDING CONCERNING THE TECHNICAL WORK OF THE 46 INTERNET ASSIGNED NUMBERS AUTHORITY 48 1. This Memorandum of Understanding ("MOU") defines an agreement between 49 the Internet Engineering Task Force and the Internet Corporation for 50 Assigned Names and Numbers. Its intent is exclusively to define the 51 technical work to be carried out by the Internet Assigned Numbers 52 Authority on behalf of the Internet Engineering Task Force and the 53 Internet Research Task Force. It is recognized that ICANN may, 54 through the IANA, provide similar services to other organisations 55 with respect to protocols not within IETF's scope (i.e. registries 56 not created by IETF or IRTF action); nothing in this MOU limits 57 ICANN's ability to do so. 59 2. This MOU will remain in effect until either modified or cancelled 60 by mutual consent of the Internet Engineering Task Force and the 61 Internet Corporation for Assigned Names and Numbers, or cancelled by 62 either party with at least six (6) months notice. 64 3. Definition of terms and abbreviations used in this document. 66 ICANN- Internet Corporation for Assigned Names and Numbers, a 67 California non-profit corporation. 69 IANA - Internet Assigned Numbers Authority (a traditional name, used 70 here to refer to the technical team making and publishing the 71 assignments of Internet protocol technical parameters). The IANA 72 technical team is now part of ICANN. 74 IETF - the Internet Engineering Task Force, the unincorporated 75 association operating under such name that creates Internet Standards 76 and related documents. 78 IAB - the Internet Architecture Board, an oversight committee of the 79 IETF. The IAB is chartered to designate the IANA on behalf of the 80 IETF. 82 IESG - the Internet Engineering Steering Group, a management 83 committee of the IETF. 85 IRTF - the Internet Research Task Force, an unincorporated 86 association also overseen by the IAB. 88 IRSG - the Internet Research Steering group, a management committee 89 of the IRTF. 91 RFC - "Request For Comments", the archival document series of the 92 IETF, also used by the IRTF and by third parties. 94 ISOC - the Internet Society, a not-for-profit corporation that 95 supports the IETF. 97 4. Agreed technical work items. ICANN agrees that during the term of 98 this MOU it shall cause IANA to comply, for protocols within IETF's 99 scope, with the following requirements, which ICANN and IETF 100 acknowledge reflect the existing arrangements under which the IANA is 101 operated: 103 4.1. The IANA will assign and register Internet protocol parameters 104 only as directed by the criteria and procedures specified in RFCs, 105 including Proposed, Draft and full Internet Standards and Best 106 Current Practice documents, and any other RFC that calls for IANA 107 assignment. If they are not so specified, or in case of ambiguity, 108 IANA will continue to assign and register Internet protocol 109 parameters that have traditionally been registered by IANA, following 110 past and current practice for such assignments, unless otherwise 111 directed by the IESG. 113 If in doubt or in case of a technical dispute, IANA will seek and 114 follow technical guidance exclusively from the IESG. Where 115 appropriate the IESG will appoint an expert to advise IANA. 117 The IANA will work with the IETF to develop any missing criteria and 118 procedures over time, which the IANA will adopt when so instructed by 119 the IESG. 121 4.2. In the event of technical dispute between the IANA and the IESG, 122 both will seek guidance from the IAB whose decision shall be final. 124 4.3. Two particular assigned spaces present policy issues in addition 125 to the technical considerations specified by the IETF: the assignment 126 of domain names, and the assignment of IP address blocks. These 127 policy issues are outside the scope of this MOU. 129 Note that (a) assignments of domain names for technical uses (such as 130 domain names for inverse DNS lookup), (b) assignments of specialised 131 address blocks (such as multicast or anycast blocks), and (c) 132 experimental assignments are not considered to be policy issues, and 133 shall remain subject to the provisions of this Section 4. (For 134 purposes of this MOU, the term "assignments" includes allocations.) 135 In the event ICANN adopts a policy that prevents it from complying 136 with the provisions of this Section 4 with respect to the assignments 137 described in (a) - (c) above, ICANN will notify the IETF, which may 138 then exercise its ability to cancel this MOU under Section 2 above. 140 4.4. The IANA shall make available to the public, on-line and free of 141 charge, information about each current assignment, including contact 142 details for the assignee. Assignments published in RFCs by the RFC 143 Editor and available publicly will be deemed to meet the requirements 144 of this Section 4.4. 146 4.5. The IANA shall provide on-line facilities for the public to 147 request Internet protocol parameter assignments and shall either 148 execute such assignments, or deny them for non- conformance with 149 applicable technical requirements, in a timely manner. There shall be 150 no charge for assignments without the consent of the IAB. Requests 151 shall only be denied on legitimate technical grounds. 153 For protocols within the IETF scope (i.e., registries created by IETF 154 action), appeals against such denials may be made to the IESG and 155 subsequently to the IAB as provided in 4.2 above. 157 4.6. The IANA shall have non-voting liaison seats on appropriate IETF 158 committees as determined by the IETF, and may participate in all IETF 159 discussions concerning technical requirements for protocol parameter 160 assignment through such liaisons. 162 4.7. The IANA shall review all documents in IETF Last Call to 163 identify any issues of concern to the IANA, and shall raise these 164 issues with the IESG. 166 5. Application to IRTF/IRSG. The parties understand that certain of 167 the protocol parameters to be assigned by IANA will be relevant to 168 IRTF, rather than IETF. With respect to these protocol parameters, 169 IANA will comply with the procedures set forth in Section 4, with the 170 understanding that IRTF and IRSG shall be substituted for IETF and 171 IESG, respectively, in such procedures. In the event of any question 172 as to whether a particular protocol parameter relates principally to 173 IETF or IRTF, the IAB shall have the authority to answer such 174 question in its discretion. 176 6. General. This MOU does not constitute any of the parties as a 177 partner, joint venturer, agent, principal or franchisee of any other 178 party. The waiver of any provision of this MOU on any occasion shall 179 not constitute a waiver for purposes of any other occasion. No party 180 may transfer or assign any interest, right or obligation arising 181 under this MOU without the prior written consent of each other party 182 to this MOU. 184 7. Effectiveness of MOU. This Agreement requires the approval or 185 ratification of the ICANN Board of Directors. The signatory for 186 ICANN shall use his best efforts to secure and deliver to IETF such 187 approval or ratification within two months of signing. 189 IN WITNESS WHEREOF, this Memorandum of Understanding is executed as 190 of this first day of March 2000 by the undersigned, acting through 191 their duly authorized representatives: 193 INTERNET ENGINEERING TASK FORCE 195 By: __________________________ Fred Baker, IETF Chair 197 Approved by: 199 INTERNET ARCHITECTURE BOARD 201 By: __________________________ Brian Carpenter, IAB Chair 202 INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS 204 By:___________________________ Mike Roberts, President 206 Full Copyright Statement 208 PLACEHOLDER for full ISOC Copyright Statement if needed. 210 Security considerations 212 This document does not directly impact the security of the Internet. 214 Acknowledgements 216 The technical heart of this document was discussed in the IETF 217 POISSON working group in 1998 and 1999 and reviewed by the IESG and 218 IAB. Jorge Contreras, Joyce Reynolds, and Louis Touton assisted in 219 its finalisation. 221 Authors' Addresses 223 Brian E. Carpenter 224 iCAIR 225 Suite 150 226 1890 Maple Avenue 227 Evanston IL 60201 228 USA 230 Email: brian@icair.org 232 Fred Baker 233 519 Lado Drive 234 Santa Barbara, CA 93111 235 USA 237 Email: fred@cisco.com 239 Michael M. Roberts 240 Internet Corporation for Assigned Names and Numbers (ICANN) 241 4676 Admiralty Way, Suite 330 242 Marina del Rey, CA 90292 243 USA 245 Email: roberts@icann.org