idnits 2.17.1 draft-iab-iana-01.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: ---------------------------------------------------------------------------- No issues found here. 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' IANA Considerations. Such lists are designated for the purpose' ) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 42 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2003) is 7741 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '11' is defined on line 393, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2860 (ref. '2') ** Obsolete normative reference: RFC 1700 (ref. '3') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board G. IAB 3 Internet-Draft Internet Architecture Board 4 Document: draft-iab-iana-01.txt February 14, 2003 5 Category: BCP 6 Expires: August 15, 2003 8 Defining the Role and Function of the IETF-IANA 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 15, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 Many IETF protocols make use of commonly defined values that are 40 passed within protocol objects. To ensure consistent interpretation 41 of these values between independent implementations, there is a need 42 to ensure that the values and associated semantic intent are uniquely 43 defined. The IETF uses a registry function to record these protocol 44 values and their associated semantic intent. In this memo the 45 registry function is referred to as the IETF Internet Assigned 46 Numbers Authority (IETF-IANA). This document provides a description 47 of this function. 49 1. Introduction 51 Many IETF protocols make use of commonly defined values that are 52 passed within protocol objects. To ensure consistent interpretation 53 of these values between independent implementations, there is a need 54 to ensure that the values and associated semantic intent are uniquely 55 defined. The IETF uses a single registry to register these protocol 56 values and their associated semantic intent. Historically, this 57 registry is referred to as the Internet Assigned Numbers Authority 58 (IANA). In this context the IANA function has included both the 59 registration of protocol-specific identifier values (e.g. TCP 60 parameters) as well as the registration of various numbering and name 61 resources that are used within public Internet networks (e.g. IPv4 62 address allocations). In this document a distinction is drawn 63 between the registration of protocol parameters for protocols defined 64 in IETF RFCs, and other IANA functions. The new term to describe the 65 IETF-related activity is the "IETF-IANA". The document describes 66 this IETF-IANA function as it applies to the IETF Internet Standards 67 Process. [1] 69 At the time of writing this document (February 2003) the IANA-IETF 70 function is delegated to the Internet Corporation for Assigned Names 71 and Numbers (ICANN) according to the terms and conditions described 72 in RFC 2860 [2] 74 2. Definition of IETF-IANA 76 The Internet Standards document, STD 2, published in October 1994, 77 defined the role of the IANA as follows: 79 The Internet Assigned Numbers Authority (IANA) is the central 80 coordinator for the assignment of unique parameter values for 81 Internet protocols. The IANA is chartered by the Internet Society 82 (ISOC) and the Federal Network Council (FNC) to act as the 83 clearinghouse to assign and coordinate the use of numerous 84 Internet protocol parameters. 86 The Internet protocol suite, as defined by the Internet 87 Engineering Task Force (IETF) and its steering group (the IESG), 88 contains numerous parameters, such as internet protocol addresses, 89 domain names, autonomous system numbers (used in some routing 90 protocols), protocol numbers, port numbers, management information 91 base object identifiers, including private enterprise numbers, and 92 many others. 94 The common use of the Internet protocols by the Internet community 95 requires that the particular values used in these parameter fields 96 be assigned uniquely. It is the task of the IANA to make those 97 unique assignments as requested and to maintain a registry of the 98 currently assigned values. [3] 100 The definition of the IETF-IANA role is provided in BCP 26: 102 Many protocols make use of identifiers consisting of constants and 103 other well-known values. Even after a protocol has been defined 104 and deployment has begun, new values may need to be assigned 105 (e.g., for a new option type in DHCP, or a new encryption or 106 authentication algorithm for IPSec). To insure that such 107 quantities have consistent values and interpretations in different 108 implementations, their assignment must be administered by a 109 central authority. For IETF protocols, that role is provided by 110 the Internet Assigned Numbers Authority (IANA). [4] 112 3. Publication of IETF-IANA Assignments 114 The current mode of publication of IETF-IANA assignments is described 115 in the Informational Document RFC 3232 [5], published in January 116 2002: 118 From November 1977 through October 1994, the Internet Assigned 119 Numbers Authority (IANA) periodically published tables of the 120 Internet protocol parameter assignments in RFCs entitled, 121 "Assigned Numbers". The most current of these Assigned Numbers 122 RFCs had Standard status and carried the designation: STD 2. At 123 this time, the latest STD 2 is RFC 1700. 125 Since 1994, this sequence of RFCs have been replaced by an online 126 database accessible through a web page (currently, www.iana.org). 127 The purpose of the present RFC is to note this fact and to 128 officially obsolete RFC 1700, whose status changes to Historic. 129 RFC 1700 is obsolete, and its values are incomplete and in some 130 cases may be wrong. [5] 132 4. The Procedures related to IETF-IANA Parameter Management 134 IETF-IANA actions are defined through the inclusion of an "IANA 135 Considerations" section in Internet Standards documents, as described 136 in RFC 2434 [4]. There are also RFCs that specifically address IANA 137 considerations for particular protocols, such as RFC 2780 [6], RFC 138 2939 [7], and RFC 2978 [8]. 140 5. The Operation of the IETF-IANA 142 As documented in the IAB Charter [9], the role of the Internet 143 Architecture Board includes responsibility for the IANA function. 144 Specifically, the IAB, acting on behalf of the IETF, approves the 145 appointment of an organization to act as IANA on behalf of the IETF, 146 and also approves the terms and conditions of this delegation of the 147 IANA function. 149 The IANA has a non-voting liaison with the IAB to facilitate clear 150 communications and effective operation of the IETF-IANA function. 152 The technical direction of the IANA with respect to IETF-IANA is 153 provided by the Internet Engineering Steering Group (IESG). [9] The 154 IANA has a non-voting liaison with the IESG to facilitate clear 155 communications and effective operation of the IETF-IANA function. 157 6. Current IETF-IANA Protocol Parameter Assignments 159 The list of current IETF-IANA protocols for which parameter 160 assignments are registered by IANA is listed in reference [10]. 162 With reference to the IETF-IANA, the protocol parameters that are 163 excluded from the scope of the IETF-IANA role are the registration of 164 unicast IPv4 address blocks, unicast IPv6 address blocks, Autonomous 165 System blocks, and top level delegations within the Domain Name 166 System, as they are considered to be outside the scope of the IETF- 167 IANA as defined in Section 2 of this document. 169 7. A Description of the Operation and Responsibilities of the IETF-IANA 171 This section describes the operation and role of the Internet 172 Engineering Task Force - Internet Assigned Numbers Authority (IETF- 173 IANA). This section also includes a description of the roles of 174 related bodies with reference to the IETF-IANA function. 176 7.1 Introduction 178 Many protocols make use of identifiers consisting of constants and 179 other well-known values. Even after a protocol has been defined and 180 deployment has begun, new values may need to be assigned (e.g., for a 181 new option type in DHCP, or a new encryption or authentication 182 algorithm for IPSec). To insure that such quantities have consistent 183 values and interpretations in different implementations, their 184 assignment must be administered by a central authority. For IETF 185 protocols, that role is provided by the IETF-IANA. 187 7.2 IETF-IANA Role 189 The IETF-IANA is a function undertaken under the auspices of the 190 Internet Architecture Board (IAB). 192 The roles of the IETF-IANA are as follows: 194 o Review and Advise 196 * The IETF-IANA reviews Internet-Drafts that are being considered 197 by the Internet Engineering Task Force Steering Group (IESG), 198 with the objective of offering advice to the IESG regarding the 199 need for an IANA Considerations section, whether such a 200 section, when required, is clear in terms of direction to IETF- 201 IANA and whether the section is consistent with the current 202 published IETF-IANA Guidelines. 204 o Registry 206 * The IETF-IANA operates a registry of protocol parameter 207 assignments. 209 * The IETF-IANA registers Internet protocol parameters only as 210 directed by the criteria and procedures specified in RFCs, 211 including Proposed, Draft and full Internet Standards and Best 212 Current Practice documents, and any other RFC that calls for 213 IANA assignment. If they are not so specified, or in case of 214 ambiguity, IETF-IANA will continue to assign and register 215 Internet protocol parameters that have traditionally been 216 registered by IANA in the past, following past and current 217 practice for such assignments, unless otherwise directed by the 218 IESG. 220 * This registry includes: 222 + all protocol parameters that are managed by IETF-IANA, 224 + for each protocol parameter, a reference to the RFC document 225 that describes the parameter and the associated IANA 226 Considerations concerning the parameter, and 228 + for each registration of a protocol parameter, the source of 229 the registration and the date of the registration. 231 * If in doubt or in case of a technical dispute, the IETF-IANA 232 will seek and follow technical guidance exclusively from the 233 IESG. Where appropriate the IESG will appoint an expert to 234 advise IANA. 236 * The IETF=IANA will work with the IETF to develop any missing 237 criteria and procedures over time, which the IETF-IANA will 238 adopt when so instructed by the IESG. 240 * The registry operates as a public registry, and the contents of 241 the registry are openly available to the public, on-line and 242 free of charge. 244 * The IETF-IANA assigns protocol parameter values in accordance 245 with the policy associated with the protocol parameter. (Some 246 policies are listed in RFC2434. [4]) 248 o Mailing Lists 250 * The IETF-IANA operates public mailing lists as specified in 251 IANA Considerations. Such lists are designated for the purpose 252 of review of assignment proposals in conjunction with a 253 designated expert review function. 255 o Liaison 257 * The IETF-IANA designates an individual to act as a non-voting 258 liaison to the IAB. 260 * The IETF-IANA designates an individual to act as a non-voting 261 liaison to the IESG. The IETF-IANA liases with the IESG 262 regarding the provision of advice to the IESG on IETF protocol 263 parameters as well as the IANA Considerations section of 264 Internet-drafts that are being reviewed for publication as an 265 RFC. 267 o Reporting 269 * The IETF-IANA will submit periodic reports to the IAB 270 concerning IETF-IANA operational performance of the registry 271 function. 273 * The IETF-IANA will undertake periodic reports to the IETF 274 Plenary concerning the status of the IETF- IANA role. 276 * The IETF-IANA will publish an annual report describing the 277 status of the IETF-IANA function and a summary of performance 278 indicators. 280 o Intellectual Property Rights and the IETF-IANA 282 * IETF-IANA assigned values are published and made available free 283 of any charges and free of any constraints relating to further 284 redistribution, with the caveat that the IETF-IANA assignment 285 information may not be modified in any redistributed copy. 287 * Any intellectual property rights of IETF-IANA assignment 288 information, including the IETF-IANA registry and its contents, 289 are to be held by the IETF and ISOC, and all IETF-IANA 290 publications relating to assignment information are to be 291 published under the terms of Section 10 of RFC2026, and are to 292 include the copyright notice as documented in Section 10.4 (C) 293 of RFC2026. [1] 295 7.3 IAB role 297 The IETF-IANA is a function undertaken under the auspices of the 298 Internet Architecture Board (IAB). 300 The IAB has the responsibility to, from time to time, review the 301 current description of the IETF-IANA function and to adopt amendments 302 relating to its role and mode of operation of the IETF-IANA according 303 to the best interests of the IETF. 305 The IAB has the responsibility to select an organization to undertake 306 the delegated functions of the IETF-IANA. 308 The IAB has the responsibility to determine the terms and conditions 309 of this delegated role. Such terms and conditions should ensure that 310 the IETF-IANA operates in a manner that is fully conformant to the 311 functions described in this document. In addition, such terms and 312 conditions must not restrict the rights and interests of the IETF 313 with respect to the IETF-IANA function. 315 The IETF-IANA designates a non-voting liaison to the IAB to 316 facilitate clear communications and effective operation of the IETF- 317 IANA function. 319 7.4 IESG Role 321 The IESG is responsible for the technical direction of the IETF-IANA. 322 Such technical direction is provided through the adoption of IETF RFC 323 documents within the "IANA Considerations" section of such documents, 324 or as stand-alone "IANA Considerations" RFC documents. 326 The IESG shall ensure that the review of Internet-Drafts that are 327 offered for publications as RFCs ensures that IANA Considerations 328 sections are present when needed, and that IANA Considerations 329 sections conform to the current published guidelines. 331 The IETF-IANA designates a non-voting liaison to the IESG to 332 facilitate clear communications and effective operation of the IETF- 333 IANA function. 335 7.5 Internet Society Role 337 Any intellectual property rights of IETF-IANA assignment information, 338 including the IETF-IANA registry and its contents, and all IETF-IANA 339 publications, are to be held by the Internet Society on behalf of the 340 IETF. 342 8. Acknowledgements 344 This document is adapted from RFC2434 [4], and has been modified to 345 include explicit reference to Intellectual Property Rights, and the 346 roles of the IAB and IESG in relation to the IETF-IANA function. 348 The Internet Architecture Board acknowledges the assistance provided 349 by reviewers of earlier drafts of this document, including Scott 350 Bradner. 352 9. Security Considerations 354 This document does not propose any new protocols, and therefore does 355 not involve any security considerations in that sense. 357 References 359 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 360 RFC 2026, BCP 9, October 1996. 362 [2] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 363 Understanding Concerning the Technical Work of the Internet 364 Assigned Numbers Authority", RFC 2860, June 2000. 366 [3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, STD 367 2, October 1994. 369 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 370 Considerations Section in RFCs", RFC 2434, BCP 26, October 371 1998. 373 [5] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 374 line Database", RFC 3232, January 2002. 376 [6] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 377 Values In the Internet Protocol and Related Headers", RFC 2780, 378 BCP 37, March 2000. 380 [7] Droms, R., "Procedures and IANA Guidelines for Definition of 381 New DHCP Options and Message Types", RFC 2939, BCP 43, 382 September 2000. 384 [8] Freed, N. and J. Postel, "IANA Charset Registration 385 Procedures", RFC 2978, BCP 19, October 2000. 387 [9] Carpenter, B., "Charter of the Internet Architecture Board", 388 RFC 2850, BCP 39, May 2000. 390 [10] Reynolds, J., "IANA Protocol Numbers and Assignment Services", 391 October 1994, . 393 [11] Dyson, E., "Correspondence from Esther Dyson, Interim Chairman, 394 ICANN to Scott Bradner, Brian Carpenter and Fred Baker of the 395 IETF", February 1999, . 398 Author's Address 400 Internet Architecture Board 401 EMail: iab@iab.org 403 IAB Membership at time this document was completed: 404 Harald Alvestrand 405 Ran Atkinson 406 Rob Austein 407 Fred Baker 408 Leslie Daigle 409 Sally Floyd 410 Ted Hardie 411 Geoff Huston 412 Charlie Kaufman 413 James Kempf 414 Eric Rescorla 415 Mike St. Johns 417 Full Copyright Statement 419 Copyright (C) The Internet Society (2003). All Rights Reserved. 421 This document and translations of it may be copied and furnished to 422 others, and derivative works that comment on or otherwise explain it 423 or assist in its implementation may be prepared, copied, published 424 and distributed, in whole or in part, without restriction of any 425 kind, provided that the above copyright notice and this paragraph are 426 included on all such copies and derivative works. However, this 427 document itself may not be modified in any way, such as by removing 428 the copyright notice or references to the Internet Society or other 429 Internet organizations, except as needed for the purpose of 430 developing Internet standards in which case the procedures for 431 copyrights defined in the Internet Standards process must be 432 followed, or as required to translate it into languages other than 433 English. 435 The limited permissions granted above are perpetual and will not be 436 revoked by the Internet Society or its successors or assigns. 438 This document and the information contained herein is provided on an 439 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 440 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 441 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 442 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 443 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 445 Acknowledgement 447 Funding for the RFC Editor function is currently provided by the 448 Internet Society.