idnits 2.17.1 draft-iab-iana-02.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 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == 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 == Line 236 has weird spacing: '...er only those...' -- 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 (June 24, 2003) is 7611 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) == Unused Reference: '11' is defined on line 409, 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' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board G. Huston, Ed. 3 Internet-Draft IAB 4 Expires: December 23, 2003 June 24, 2003 6 Defining the Role and Function of IETF Protocol Parameter Registry 7 Operators 8 draft-iab-iana-02 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 other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 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 This Internet-Draft will expire on December 23, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 Many IETF protocols make use of commonly defined values that are 39 passed within protocol objects. To ensure consistent interpretation 40 of these values between independent implementations, there is a need 41 to ensure that the values and associated semantic intent are uniquely 42 defined. The IETF uses a registry function to record assigned 43 protocol parameter values and their associated semantic intent. For 44 each IETF protocol parameter It is current practice for the IETF to 45 delegate the role of protocol parameter registry operator to a 46 nominated entity. This document describes a description of this 47 delegated 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 registry to register each of the possible 56 values of a protocol parameter and their associated semantic intent. 57 The document describes this registry function as it applies to 58 individual protocol parameters defined by the IETF Internet Standards 59 Process [1]. 61 At the time of writing this document (June 2003) the operation of the 62 majority of the protocol parameter registries is delegated to the 63 Internet Corporation for Assigned Names and Numbers (ICANN) according 64 to the terms and conditions described in RFC 2860 [2]. Not all IETF 65 protocol parameter registries are delegated to ICANN, and at present 66 the operation of the 'e164.arpa' registry has been delegated to the 67 RIPE Network Coordination Center (RIPE NCC) [12]. 69 The term "Internet Assigned Numbers Authority" (IANA), has been used 70 historically to refer to the entire collection of protocol parameter 71 registries. It is noted that there is current general use of this 72 term to refer specifically to the set of registries operated by ICANN 73 under terms of this delegation of function. While IETF documents 74 continue to use the term "IANA Considerations" when referring to 75 specific functions to be performed with respect to a protocol 76 parameter registry [4], it is noted that the use of the term 'IANA' 77 in this context does not necessarily imply the delegation to ICANN of 78 the associated role of operation of the protocol parameter registry 79 for the particular protocol parameter so described. 81 2. Definition of an IETF Protocol Parameter Registry 83 Using the term 'IANA' in the sense of the entire set of IETF protocol 84 parameter registries, the Internet Standards document, STD 2, 85 published in October 1994, defined the role of the IANA as follows: 87 The Internet Assigned Numbers Authority (IANA) is the central 88 coordinator for the assignment of unique parameter values for 89 Internet protocols. The IANA is chartered by the Internet Society 90 (ISOC) and the Federal Network Council (FNC) to act as the 91 clearinghouse to assign and coordinate the use of numerous 92 Internet protocol parameters. 94 The Internet protocol suite, as defined by the Internet 95 Engineering Task Force (IETF) and its steering group (the IESG), 96 contains numerous parameters, such as Internet protocol addresses, 97 domain names, autonomous system numbers (used in some routing 98 protocols), protocol numbers, port numbers, management information 99 base object identifiers, including private enterprise numbers, and 100 many others. 102 The common use of the Internet protocols by the Internet community 103 requires that the particular values used in these parameter fields 104 be assigned uniquely. It is the task of the IANA to make those 105 unique assignments as requested and to maintain a registry of the 106 currently assigned values. [3] 108 Again using the term 'IANA' in the sense of the entire set of IETF 109 protocol parameter registries, the definition of the protocol 110 parameter registry role is provided in BCP 26: 112 Many protocols make use of identifiers consisting of constants and 113 other well-known values. Even after a protocol has been defined 114 and deployment has begun, new values may need to be assigned 115 (e.g., for a new option type in DHCP, or a new encryption or 116 authentication algorithm for IPSec). To insure that such 117 quantities have consistent values and interpretations in different 118 implementations, their assignment must be administered by a 119 central authority. For IETF protocols, that role is provided by 120 the Internet Assigned Numbers Authority (IANA). [4] 122 3. Publication of Protocol Parameter Registry Assignments 124 The current mode of publication of protocol parameter registry 125 assignments undertaken within registries whose operation is currently 126 delegated to ICANN is described in the Informational Document RFC 127 3232 [5], published in January 2002: 129 From November 1977 through October 1994, the Internet Assigned 130 Numbers Authority (IANA) periodically published tables of the 131 Internet protocol parameter assignments in RFCs entitled, 132 "Assigned Numbers". The most current of these Assigned Numbers 133 RFCs had Standard status and carried the designation: STD 2. At 134 this time, the latest STD 2 is RFC 1700. 136 Since 1994, this sequence of RFCs have been replaced by an online 137 database accessible through a web page (currently, www.iana.org). 138 The purpose of the present RFC is to note this fact and to 139 officially obsolete RFC 1700, whose status changes to Historic. 140 RFC 1700 is obsolete, and its values are incomplete and in some 141 cases may be wrong. [5] 143 The mode of publication of the e164.arpa protocol parameter registry 144 operated by the RIPE NCC is documented in reference [13]. 146 4. The Procedures related to IETF Protocol Parameter Management 148 IETF Protocol Parameter registry actions are defined through the 149 inclusion of an "IANA Considerations" section in Internet Standards 150 documents, as described in RFC 2434 [4]. There are also RFCs that 151 specifically address IETF protocol parameter considerations for 152 particular protocols, such as RFC 2780 [6], RFC 2939 [7], and RFC 153 2978 [8]. 155 5. The Operation of IETF Protocol Parameter Registries 157 As documented in the IAB Charter [9], the role of the Internet 158 Architecture Board includes responsibility for the IETF Protocol 159 Parameter registration function (referred to in the charter as 160 'IANA'). The IAB, acting on behalf of the IETF, approves the 161 appointment of an organization to act as a protocol parameter 162 registry operator on behalf of the IETF, and also approves the terms 163 and conditions of this delegation of this function. 165 The technical direction of the IETF Protocol Parameter registry 166 function is provided by the Internet Engineering Steering Group 167 (IESG) [9]. 169 6. Current IETF Protocol Parameter Assignments 171 The list of current IETF protocol parameters for which parameter 172 value assignments are registered within registries whose operation is 173 currently delegated to ICANN is listed in reference [10]. In addition 174 there is the e164.arpa registry function, which is listed in 175 reference [13]. 177 With reference to the list contained in reference [10], protocol 178 parameter registries that refer to the unicast IPv4 address space, 179 unicast IPv6 address space, Autonomous System Numbers and the top 180 level delegations within the Domain Name System all use allocation 181 mechanisms that have been delegated to the IANA function operated 182 under the auspices of ICANN. Other bodies are responsible for the 183 development of policies to manage this allocation function. 185 7. A Description of the Role and Responsibilities of an IETF Protocol 186 Parameter Registry Operator 188 This section describes the operation and role of a delegated IETF 189 Protocol Parameter Registry Operator. This section also includes a 190 description of the roles of related bodies with reference to this 191 function. 193 7.1 Introduction 195 Many protocols make use of identifiers consisting of constants and 196 other well-known values. Even after a protocol has been defined and 197 deployment has begun, new values may need to be assigned (e.g., for a 198 new option type in DHCP, or a new encryption or authentication 199 algorithm for IPSec). To insure that such quantities have consistent 200 values and interpretations in different implementations, their 201 assignment must be administered by a central authority. For IETF 202 protocols, that role is provided by a delegated Protocol Parameter 203 Registry operator. For any particular protocol parameter there is a 204 single delegated registry operator. 206 7.2 Protocol Parameter Registry Operator Role 208 A IETF Protocol Parameter registry function is undertaken under the 209 auspices of the Internet Architecture Board (IAB). 211 The roles of the Protocol Parameter registry operator are as follows: 213 o Review and Advise 215 * The registry operator may be requested to review 216 Internet-Drafts that are being considered by the Internet 217 Engineering Task Force Steering Group (IESG), with the 218 objective of offering advice to the IESG regarding the need for 219 an "IANA Considerations" section, whether such a section, when 220 required, is clear in terms of direction to the registry 221 operator and whether the section is consistent with the current 222 published registry operator guidelines. 224 o Registry 226 * To operate a registry of protocol parameter assignments. 228 * The delegated registry operator registers values for the 229 protocol parameter Internet protocol parameters only as 230 directed by the criteria and procedures specified in RFCs, 231 including Proposed, Draft and full Internet Standards and Best 232 Current Practice documents, and any other RFC that calls for 233 protocol parameter assignment, and only for those protocol 234 parameters specified by the IAB. If they are not so specified, 235 or in case of ambiguity, the registry operator will continue to 236 assign and register only those protocol parameters that have 237 already been delegated to the operator, following past and 238 current practice for such assignments, unless otherwise 239 directed in terms of operating practice by the IESG. 241 * For each protocol parameter, the associated registry includes: 243 + a reference to the RFC document that describes the parameter 244 and the associated "IANA Considerations" concerning the 245 parameter, and 247 + for each registration of a protocol parameter value, the 248 source of the registration and the date of the registration. 250 * If in doubt or in case of a technical dispute, the registry 251 operator will seek and follow technical guidance exclusively 252 from the IESG. Where appropriate the IESG will appoint an 253 expert to advise the registry operator. 255 * The registry operator will work with the IETF to develop any 256 missing criteria and procedures over time, which the registry 257 operator will adopt when so instructed by the IESG. 259 * Each protocol parameter registry operates as a public registry, 260 and the contents of the registry are openly available to the 261 public, on-line and free of charge. 263 * The registry operator assigns protocol parameter values in 264 accordance with the policy associated with the protocol 265 parameter. (Some policies are listed in RFC2434 [4]). 267 o Mailing Lists 269 * The registry operator maintains public mailing lists as 270 specified in IANA Considerations. Such lists are designated for 271 the purpose of review of assignment proposals in conjunction 272 with a designated expert review function. 274 o Review and Advise 276 * The registry operator will nominate a liaison point of contact. 277 The registry operator, though this liaison, may be requested to 278 provide advice to the IESG on IETF protocol parameters as well 279 as the IANA Considerations section of Internet-drafts that are 280 being reviewed for publication as an RFC. 282 o Reporting 284 * The registry operator will submit periodic reports to the IAB 285 concerning the operational performance of the registry 286 function. 288 * At the request of the chair of the IETF, the registry operator 289 will undertake periodic reports to the IETF Plenary concerning 290 the status of the registry function. 292 * The registry operator will publish an annual report describing 293 the status of the function and a summary of performance 294 indicators. 296 o Intellectual Property Rights and the Registry Operator 298 * All assigned values are to be published and made available free 299 of any charges and free of any constraints relating to further 300 redistribution, with the caveat that the assignment information 301 may not be modified in any redistributed copy. 303 * Any intellectual property rights of the IETF Protocol Parameter 304 assignment information, including the IETF Protocol Parameter 305 registry and its contents, are to be held by the IETF and ISOC, 306 and all IETF Protocol Parameter registry publications relating 307 to assignment information are to be published under the terms 308 of Section 10 of RFC2026, and are to include the copyright 309 notice as documented in Section 10.4 (C) of RFC2026 [1]. 311 7.3 IAB role 313 An operator of an IETF Protocol Parameter registry undertakes the 314 role as a delegated function under the auspices of the Internet 315 Architecture Board (IAB). 317 The IAB has the responsibility to, from time to time, review the 318 current description of the registry function and direct the registry 319 operator to adopt amendments relating to its role and mode of 320 operation of the registry according to the best interests of the 321 IETF. 323 The IAB has the responsibility to select an organization to undertake 324 the delegated functions of the Protocol Parameter registry for each 325 IETF protocol parameter. 327 The IAB has the responsibility to determine the terms and conditions 328 of this delegated role. Such terms and conditions should ensure that 329 the registry operates in a manner that is fully conformant to the 330 functions described in this document. In addition, such terms and 331 conditions must not restrict the rights and interests of the IETF 332 with respect to the registry function. 334 7.4 IESG Role 335 The IESG is responsible for the technical direction of the IETF 336 Protocol Parameter registries. Such technical direction is provided 337 through the adoption of IETF RFC documents within the "IANA 338 Considerations" section of such documents, or as stand-alone "IANA 339 Considerations" RFC documents. 341 The IESG shall ensure that the review of Internet-Drafts that are 342 offered for publications as RFCs ensures that IANA Considerations 343 sections are present when needed, and that IANA Considerations 344 sections conform to the current published guidelines. 346 At the discretion of the IESG, the registry operator may be required 347 to designate a non-voting liaison to the IESG to facilitate clear 348 communications and effective operation of the registry function. 350 7.5 Internet Society Role 352 Any intellectual property rights of IETF Protocol Parameter 353 assignment information, including the registry and its contents, and 354 all registry publications, are to be held by the Internet Society on 355 behalf of the IETF. 357 8. Acknowledgement 359 This document is adapted from RFC2434 [4], and has been modified to 360 include explicit reference to Intellectual Property Rights, and the 361 roles of the IAB and IESG in relation to the IETF Protocol Parameter 362 registry function. 364 The Internet Architecture Board acknowledges the assistance provided 365 by reviewers of earlier drafts of this document, including Scott 366 Bradner. 368 9. Security Considerations 370 This document does not propose any new protocols, and therefore does 371 not involve any security considerations in that sense. 373 References 375 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 376 RFC 2026, BCP 9, October 1996. 378 [2] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 379 Understanding Concerning the Technical Work of the Internet 380 Assigned Numbers Authority", RFC 2860, June 2000. 382 [3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, STD 383 2, October 1994. 385 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 386 Considerations Section in RFCs", RFC 2434, BCP 26, October 387 1998. 389 [5] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an 390 On-line Database", RFC 3232, January 2002. 392 [6] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 393 Values In the Internet Protocol and Related Headers", RFC 2780, 394 BCP 37, March 2000. 396 [7] Droms, R., "Procedures and IANA Guidelines for Definition of 397 New DHCP Options and Message Types", RFC 2939, BCP 43, 398 September 2000. 400 [8] Freed, N. and J. Postel, "IANA Charset Registration 401 Procedures", RFC 2978, BCP 19, October 2000. 403 [9] Carpenter, B., "Charter of the Internet Architecture Board", 404 RFC 2850, BCP 39, May 2000. 406 [10] Reynolds, J., "IANA Protocol Numbers and Assignment Services", 407 October 1994, . 409 [11] Dyson, E., "Correspondence from Esther Dyson, Interim Chairman, 410 ICANN to Scott Bradner, Brian Carpenter and Fred Baker of the 411 IETF", February 1999, . 414 [12] IAB, "ENUM LIAISON ON IAB INSTRUCTIONS TO RIPE-NCC", September 415 2002, . 418 [13] RIPE NCC, "ENUM Registry", September 2002, . 421 Author's Address 423 Geoff Huston, Editor. 424 Internet Architecture Board 426 Appendix A. IAB Members 428 Internet Architecture Board Members at the time this document was 429 published were: 431 Bernard Aboba 432 Harald Alvestrand 433 Rob Austein 434 Leslie Daigle, Chair 435 Patrik Faltstrom 436 Sally Floyd 437 Jun-ichiro Itojun Hagino 438 Mark Handley 439 Geoff Huston 440 Charlie Kaufman 441 James Kempf 442 Eric Rescorla 443 Michael StJohns 445 Intellectual Property Statement 447 The IETF takes no position regarding the validity or scope of any 448 intellectual property or other rights that might be claimed to 449 pertain to the implementation or use of the technology described in 450 this document or the extent to which any license under such rights 451 might or might not be available; neither does it represent that it 452 has made any effort to identify any such rights. Information on the 453 IETF's procedures with respect to rights in standards-track and 454 standards-related documentation can be found in BCP-11. Copies of 455 claims of rights made available for publication and any assurances of 456 licenses to be made available, or the result of an attempt made to 457 obtain a general license or permission for the use of such 458 proprietary rights by implementors or users of this specification can 459 be obtained from the IETF Secretariat. 461 The IETF invites any interested party to bring to its attention any 462 copyrights, patents or patent applications, or other proprietary 463 rights which may cover technology that may be required to practice 464 this standard. Please address the information to the IETF Executive 465 Director. 467 Full Copyright Statement 469 Copyright (C) The Internet Society (2003). All Rights Reserved. 471 This document and translations of it may be copied and furnished to 472 others, and derivative works that comment on or otherwise explain it 473 or assist in its implementation may be prepared, copied, published 474 and distributed, in whole or in part, without restriction of any 475 kind, provided that the above copyright notice and this paragraph are 476 included on all such copies and derivative works. However, this 477 document itself may not be modified in any way, such as by removing 478 the copyright notice or references to the Internet Society or other 479 Internet organizations, except as needed for the purpose of 480 developing Internet standards in which case the procedures for 481 copyrights defined in the Internet Standards process must be 482 followed, or as required to translate it into languages other than 483 English. 485 The limited permissions granted above are perpetual and will not be 486 revoked by the Internet Society or its successors or assignees. 488 This document and the information contained herein is provided on an 489 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 490 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 491 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 492 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 493 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 495 Acknowledgement 497 Funding for the RFC Editor function is currently provided by the 498 Internet Society.