idnits 2.17.1 draft-huston-iana-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: ---------------------------------------------------------------------------- ** 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? == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2434], [DYSON], [RFC2939]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (October 2002) is 7864 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) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2860 ** Downref: Normative reference to an Informational RFC: RFC 3232 -- Possible downref: Non-RFC (?) normative reference: ref. 'DYSON' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission G. Huston, 3 Internet Draft S. Bradner 4 Document: draft-huston-iana-00.txt October 2002 5 Category: BCP 6 Expires: April 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. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Comments on this draft should be directed to gih@telstra.net. 32 Abstract 34 This memo describes the role and function of the IETF-IANA. 36 Many IETF protocols make use of commonly defined values that are 37 passed within protocol objects. To ensure consistent interpretation 38 of these values between independent implementations, there is a need 39 to ensure that the values and associated semantic intent are 40 uniquely defined. 42 The IETF uses a single registry to register these protocol values 43 and their associated semantic intent. In this memo the registry 44 function is referred to as the IETF Internet Assigned Numbers 45 Authority (IETF-IANA). 47 This document provides a description of this function and proposes 48 that this description be adopted by the Internet Architecture Board 49 (IAB). 51 1. Introduction 53 Many IETF protocols make use of commonly defined values that are 54 passed within protocol objects. To ensure consistent interpretation 55 of these values between independent implementations, there is a need 56 to ensure that the values and associated semantic intent are 57 uniquely defined. 59 The IETF uses a single registry to register these protocol values 60 and their associated semantic intent. 62 Historically, this registry is referred to as the Internet Assigned 63 Numbers Authority (IANA). In this context the IANA function has 64 included both the registration of protocol-specific identifier 65 values (e.g. TCP parameters) as well as the registration of various 66 numbering and name resources that are used within public Internet 67 networks (e.g. IPv4 address allocations). 69 In this document a distinction is drawn between the registration of 70 protocol parameters for protocols defined in IETF RFCs, and other 71 IANA functions. The new term to describe the IETF-related activity 72 is the "IETF-IANA". 74 The document describes this IETF-IANA function as it applies to the 75 IETF Internet Standards Process. [RFC1700] 77 2. Definition of IETF-IANA 79 The Internet Standards document STD-2 [RFC1700], published in 80 October 1994, defined the role of the IANA as follows: 82 The Internet Assigned Numbers Authority (IANA) is the central 83 coordinator for the assignment of unique parameter values for 84 Internet protocols. The IANA is chartered by the Internet 85 Society (ISOC) and the Federal Network Council (FNC) to act as 86 the clearinghouse to assign and coordinate the use of numerous 87 Internet protocol parameters. 89 The Internet protocol suite, as defined by the Internet 90 Engineering Task Force (IETF) and its steering group (the IESG), 91 contains numerous parameters, such as internet protocol 92 addresses, domain names, autonomous system numbers (used in some 93 routing protocols), protocol numbers, port numbers, management 94 information base object identifiers, including private 95 enterprise numbers, and many others. 97 The common use of the Internet protocols by the Internet 98 community requires that the particular values used in these 99 parameter fields be assigned uniquely. It is the task of the 100 IANA to make those unique assignments as requested and to 101 maintain a registry of the currently assigned values. [RFC1700] 103 The definition of the IETF-IANA role is provided in BCP 26 104 [RFC2434]: 106 Many protocols make use of identifiers consisting of constants 107 and other well-known values. Even after a protocol has been 108 defined and deployment has begun, new values may need to be 109 assigned (e.g., for a new option type in DHCP, or a new 110 encryption or authentication algorithm for IPSec). To insure 111 that such quantities have consistent values and interpretations 112 in different implementations, their assignment must be 113 administered by a central authority. For IETF protocols, that 114 role is provided by the Internet Assigned Numbers Authority 115 (IANA). [RFC2434] 117 The operation of the IETF-IANA role is described in the MoU Between 118 IETF and the Internet Corporation for Assigned Names and Numbers 119 (ICANN) concerning IANA [RFC2860] 121 4.1. The IANA will assign and register Internet protocol 122 parameters only as directed by the criteria and procedures 123 specified in RFCs, including Proposed, Draft and full Internet 124 Standards and Best Current Practice documents, and any other RFC 125 that calls for IANA assignment. If they are not so specified, or 126 in case of ambiguity, IANA will continue to assign and register 127 Internet protocol parameters that have traditionally been 128 registered by IANA, following past and current practice for such 129 assignments, unless otherwise directed by the IESG. 131 If in doubt or in case of a technical dispute, IANA will seek 132 and follow technical guidance exclusively from the IESG. Where 133 appropriate the IESG will appoint an expert to advise IANA. 135 The IANA will work with the IETF to develop any missing criteria 136 and procedures over time, which the IANA will adopt when so 137 instructed by the IESG.[RFC2860] 139 3. Publication of IETF-IANA Assignments 141 The current mode of publication of IETF-IANA assignments is 142 described in the Informational Document RFC 3232 [RFC3232], 143 published in January 2002: 145 From November 1977 through October 1994, the Internet Assigned 146 Numbers Authority (IANA) periodically published tables of the 147 Internet protocol parameter assignments in RFCs entitled, 148 "Assigned Numbers". The most current of these Assigned Numbers 149 RFCs had Standard status and carried the designation: STD 2. At 150 this time, the latest STD 2 is RFC 1700. 152 Since 1994, this sequence of RFCs have been replaced by an 153 online database accessible through a web page (currently, 154 www.iana.org). The purpose of the present RFC is to note this 155 fact and to officially obsolete RFC 1700, whose status changes 156 to Historic. RFC 1700 is obsolete, and its values are 157 incomplete and in some cases may be wrong. [RFC3232] 159 4. The Procedures related to IETF-IANA Parameter Management 161 IETF-IANA actions are defined through the inclusion of an "IANA 162 Considerations" section in Internet Standards documents, as 163 described in RFC 2434 [RFC1700]. There are also RFCs that 164 specifically address IANA considerations for particular protocols, 165 such as RFC 2780, [RFC2870], RFC 2939 [RFC2939], and RFC 2978 166 [RFC2978]. 168 5. The Operation of the IETF-IANA 170 As documented in the IAB Charter [RFC2850], the role of the Internet 171 Architecture Board includes responsibility for the IANA function. 172 Specifically, the IAB, acting on behalf of the IETF, approves the 173 appointment of an organization to act as IANA on behalf of the IETF, 174 and also approves the terms and conditions of this delegation of the 175 IANA function. 177 The IANA has a non-voting liaison with the IAB to facilitate clear 178 communications and effective operation of the IETF-IANA function. 180 The technical direction of the IANA with respect to IETF-IANA is 181 provided by the Internet Engineering Steering Group (IESG). 182 [RFC2850] The IANA has a non-voting liaison with the IESG to 183 facilitate clear communications and effective operation of the IETF- 184 IANA function. 186 6. Current IETF-IANA Protocol Parameter Assignments 188 The list of current IETF-IANA protocols for which parameter 189 assignments are registered by IANA is listed in reference 190 [IANA.ORG]. 192 With reference to the IETF-IANA, the protocol parameters that are 193 excluded from the scope of the IETF-IANA role are the registration 194 of unicast IPv4 address blocks, unicast IPv6 address blocks, 195 Autonomous System blocks, and top level delegations within the 196 Domain Name System, as they are considered to be outside the scope 197 of the IETF-IANA as defined in Section 2 of this document. 199 7. A Description of the Operation and Responsibilities of the IETF-IANA 201 A description of the operation and responsibilities of the IETF-IANA 202 is proposed for consideration by the Internet Architecture Board. 203 This document is intended to clearly describe and define the role of 204 the IETF-IANA and the related roles of the IAB, the IESG, and the 205 Internet Society. A draft of such a description is contained in 206 Attachment A. 208 8. Acknowledgements 210 The authors acknowledge the assistance provided by reviewers of 211 earlier drafts of this document, including James Kempf, Ran 212 Atkinson, Sally Floyd, Harald Alvestrand and Leslie Daigle. 214 9. References 216 [RFC1700] Reynolds, J., Postel, J., "ASSIGNED NUMBERS", STD2, 217 RFC1700, October 1994. 219 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an 220 IANA Considerations Section in RFCs", BCP26, RFC2434, October 221 1998. 223 [RFC2860] Carpenter, B., Baker, F., Roberts, M., "Memorandum of 224 Understanding Concerning the Technical Work of the Internet 225 Assigned Numbers Authority", RFC2860, June 2000. 227 [RFC3232] Reynolds, J. ed., "Assigned Numbers: RFC 1700 is Replaced 228 by an On-line Database", RFC3232, January 2002. 230 [RFC2870] Bradner, S., Paxson, V., "IANA Allocation Guidelines For 231 Values In the Internet Protocol and Related Headers", BCP37, RFC 232 2780, March 2000. 234 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 235 of New DHCP Options and Message Types.", BCP43, RFC 2939, 236 September 2000. 238 [RFC2978] Freed, N., Postel, J., "IANA Charset Registration 239 Procedures", BCP19, RFC 2978, October 2000. 241 [RFC2850] Carpenter, B., ed., "Charter of the Internet Architecture 242 Board (IAB)" BCP39, RFC 2850, May 2000. 244 [IANA.ORG] "IANA Protocol Numbers and Assignment Services" available 245 online as http://www.iana.org/numbers.htm 247 [DYSON] Correspondence from Esther Dyson, Interim Chairman, 248 ICANN to Scott Bradner, Brian Carpenter and Fred Baker of the 249 IETF, Feb 25 1999, http://www.icann.org/correspondence/bradner- 250 dyson-25feb99.htm 252 10. Authors 254 Geoff Huston 255 Telstra 256 242 Exhibition St, Melbourne 257 AUSTRALIA 259 EMail: gih@telstra.net 261 Scott Bradner 262 Harvard University 263 29 Oxford St 264 CAmbridge MA 02138 265 USA 267 EMail: sob@harvard.edu 269 Attachment A 271 The Operation and Responsibilities of the IETF-IANA 273 Abstract 275 This memo describes the operation and role of the IETF-IANA, and the 276 roles of related bodies with reference to the IETF-IANA function. 278 Introduction 280 Many protocols make use of identifiers consisting of constants and 281 other well-known values. Even after a protocol has been defined and 282 deployment has begun, new values may need to be assigned (e.g., for 283 a new option type in DHCP, or a new encryption or authentication 284 algorithm for IPSec). To insure that such quantities have 285 consistent values and interpretations in different implementations, 286 their assignment must be administered by a central authority. For 287 IETF protocols, that role is provided by the IETF Internet Assigned 288 Numbers Authority (IETF-IANA). 290 IETF-IANA Role 292 The IETF-IANA is a function undertaken under the auspices of the 293 Internet Architecture Board (IAB). 295 The roles of the IETF-IANA are as follows: 297 - Review and Advise 299 The IETF-IANA reviews Internet-Drafts that are being considered by 300 the IESG, with the objective of offering advice to the IESG 301 regarding the need for an IANA Considerations section, whether 302 such a section, when required, is clear in terms of direction to 303 IETF-IANA and whether the section is consistent with the current 304 published IETF- IANA Guidelines. 306 - Registry 308 The IETF-IANA operates a registry of protocol parameter 309 assignments. 311 This registry includes: 313 * all protocol parameters that are managed by IETF-IANA, 315 * for each protocol parameter, a reference to the RFC document 316 that describes the parameter and the associated IANA 317 Considerations concerning the parameter, and 319 * for each registration of a protocol parameter, the source of the 320 registration and the date of the registration. 322 The registry operates as a public registry, and the contents of 323 the registry are openly available to the public, on-line and free 324 of charge. 326 The IETF-IANA assigns protocol parameter values in accordance with 327 the policy associated with the protocol parameter. (Some policies 328 are listed in RFC 2434. [RFC2434]) 330 - Mailing Lists 332 The IETF-IANA operates public mailing lists as specified in IANA 333 Considerations. Such lists are designated for the purpose of 334 review of assignment proposals in conjunction with a designated 335 expert review function. 337 - Liaison 339 The IETF-IANA designates an individual to act as a non-voting 340 liaison to the IAB. 342 The IETF-IANA designates an individual to act as a non-voting 343 liaison to the IESG. The IETF-IANA liases with the IESG regarding 344 the provision of advice to the IESG on IETF protocol parameters as 345 well as the IANA Considerations section of Internet-drafts that 346 are being reviewed for publication as an RFC. 348 - Reporting 350 The IETF-IANA will submit periodic reports to the IAB concerning 351 IETF-IANA operational performance of the registry function. 353 The IETF-IANA will undertake periodic reports to the IETF Plenary 354 concerning the status of the IETF-IANA role. 356 The IETF-IANA will publish an annual report describing the status 357 of the IETF-IANA function and a summary of performance indicators. 359 - Intellectual Property Rights and the IETF-IANA 361 IETF-IANA assigned values are published and made available free of 362 any charges and free of any constraints relating to further 363 redistribution, with the caveat that the IETF-IANA assignment 364 information may not be modified in any redistributed copy. 366 Any intellectual property rights of IETF-IANA assignment 367 information, including the IETF-IANA registry and its contents, 368 are to be held by the IETF and ISOC, and all IETF-IANA 369 publications relating to assignment information are to be 370 published under the terms of Section 10 of RFC2026, and are to 371 include the copyright notice as documented in Section 10.4 (C) of 372 RFC2026. [RFC2939] [DYSON] 374 IAB role 376 The IETF-IANA is a function undertaken under the auspices of the 377 Internet Architecture Board (IAB). 379 The IAB has the responsibility to, from time to time, review the 380 current description of the IETF-IANA function and to adopt 381 amendments relating to its role and mode of operation of the IETF- 382 IANA according to the best interests of the IETF. 384 The IAB has the responsibility to select an organization to 385 undertake the delegated functions of the IETF-IANA. 387 The IAB has the responsibility to determine the terms and conditions 388 of this delegated role. Such terms and conditions should ensure that 389 the IETF-IANA operates in a manner that is fully conformant to the 390 functions described in this document. In addition, such terms and 391 conditions must not restrict the rights and interests of the IETF 392 with respect to the IETF-IANA function. 394 The IETF-IANA designates a non-voting liaison to the IAB to 395 facilitate clear communications and effective operation of the IETF- 396 IANA function. 398 IESG Role 400 The IESG is responsible for the technical direction of the IETF- 401 IANA. Such technical direction is provided through the adoption of 402 IETF RFC documents within the "IANA Considerations" section of such 403 documents, or as stand-alone "IANA Considerations" RFC documents. 405 The IESG shall ensure that the review of Internet-Drafts that are 406 offered for publications as RFCs ensures that IANA Considerations 407 sections are present when needed, and that IANA Considerations 408 sections conform to the current published guidelines. 410 The IETF-IANA designates a non-voting liaison to the IESG to 411 facilitate clear communications and effective operation of the IETF- 412 IANA function. 414 Internet Society Role 416 Any intellectual property rights of IETF-IANA assignment 417 information, including the IETF-IANA registry and its contents, and 418 all IETF-IANA publications, are to be held by the Internet Society 419 on behalf of the IETF. 421 Acknowledgement 423 This document is adapted from RFC2434 [RFC2434], and has been 424 modified to include explicit reference to Intellectual Property 425 Rights, and the roles of the IAB and IESG in relation to the IETF- 426 IANA function.