idnits 2.17.1 draft-iab-iana-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 9, 2011) is 4818 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: 'CORR' is defined on line 462, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 4748 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5620 (Obsoleted by RFC 6548, RFC 6635) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Danny McPherson, Ed. 2 Geoff Huston, Ed. 3 Olaf M. Kolkman, Ed. 4 Internet Architecture Board 5 Expires: August 2011 February 9, 2011 6 Intended Status: Best Current Practice 8 Defining the Role and Function of IETF Protocol 9 Parameter Registry Operators 10 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF). Note that other groups may also distribute 19 working documents as Internet-Drafts. The list of current Internet- 20 Drafts is at http://datatracker.ietf.org/drafts/current/. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 Copyright Notice 29 Copyright (c) 2011 IETF Trust and the persons identified as the 30 document authors. All rights reserved. 32 This document is subject to BCP 78 and the IETF Trust's Legal 33 Provisions Relating to IETF Documents 34 (http://trustee.ietf.org/license-info) in effect on the date of 35 publication of this document. Please review these documents 36 carefully, as they describe your rights and restrictions with respect 37 to this document. Code Components extracted from this document must 38 include Simplified BSD License text as described in Section 4.e of 39 the Trust Legal Provisions and are provided without warranty as 40 described in the Simplified BSD License. 42 Abstract 44 Many IETF protocols make use of commonly-defined values that are 45 passed in messages or packets. To ensure consistent interpretation 46 of these values between independent implementations, there is a need 47 to ensure that the values and associated semantic intent are uniquely 48 defined. The IETF uses registry functions to record assigned 49 protocol parameter values and their associated semantic intent. For 50 each IETF protocol parameter it is current practice for the IETF to 51 delegate the role of protocol parameter registry operator to a 52 nominated entity. This document provides a description of, and the 53 requirements for, these delegated functions. 55 Table of Contents 57 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Roles and Responsibilities Concerning IETF Proto- 59 col Parameter Registries. . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Protocol Parameter Registry Operator Role . . . . . . . . . 5 61 2.2. IAB Role. . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 2.3. IESG Role . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 2.4. Role of the IETF Trust. . . . . . . . . . . . . . . . . . . 9 64 2.5. Role of the IAOC. . . . . . . . . . . . . . . . . . . . . . 10 65 3. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 10 66 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 67 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 11 68 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.1. Normative References. . . . . . . . . . . . . . . . . . . . 11 71 7.2. Informative References. . . . . . . . . . . . . . . . . . . 11 72 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 73 9. Appendix A: Considerations on the term IANA. . . . . . . . . . 13 74 10. Appendix B: IANA registries in context. . . . . . . . . . . . 15 75 10.1. Definition of an IETF Protocol Parameter Reg- 76 istry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 10.2. Publication of Protocol Parameter Registry 78 Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 10.3. Procedures Related to IETF Protocol Parameter 80 Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 10.4. Registries for IETF Protocol Parameters. . . . . . . . . . 17 82 10.5. Current IETF Protocol Parameter Assignments. . . . . . . . 17 83 11. Appendix C: IAB Members . . . . . . . . . . . . . . . . . . . 18 85 1. Overview 87 Many IETF protocols make use of commonly-defined values that are 88 passed within messages or packets. To ensure consistent 89 interpretation of these values between independent implementations, 90 there is a need to ensure that the values and associated semantic 91 intent are uniquely defined. The IETF uses registries to record each 92 of the possible values of a protocol parameter and their associated 93 semantic intent. These registries, their registration policy, and 94 the layout of their content are defined in the so called "IANA 95 Consideration" sections of IETF documents. 97 The organizational separation between the IETF and its registry 98 operators is one that appears to be a relatively unique arrangement 99 in the context of standards development organizations (SDOs), and 100 similar arrangements of structural separation are not generally used 101 by other SDOs. SDOs that undertake a similar protocol parameter 102 registration function generally do so as part of their secretariat 103 service functions or their equivalent, thereby avoiding the overheads 104 of detailed coordination of activity across multiple distinct 105 organizations. However, this structural separation of roles exists 106 within several places in the IETF framework (e.g., the RFC Editor 107 function) and the Internet Architecture Board (IAB), on behalf of the 108 IETF, has the responsibility to define and manage the relationship 109 with the protocol registry operator role. This responsibility 110 includes the selection and management of the protocol parameter 111 registry operator, as well as management of the parameter 112 registration process and the guidelines for parameter allocation. 114 As with other SDOs, the IETF asserts full authority over the 115 management of all its protocol parameters and their registries. This 116 document describes the function of these registries as they apply to 117 individual protocol parameters defined by the IETF Internet Standards 118 Process [RFC2026] as to allow for an orderly implementation by the 119 Internet Administrative Oversight Committee (IAOC) under guidance 120 from the IAB. 122 Below we provide a description of the requirement for these delegated 123 functions, which the IETF traditionally refers to as the Internet 124 Assigned Numbers Authority (IANA) function. 126 2. Roles and Responsibilities Concerning IETF Protocol Parameter 127 Registries 129 The IETF's longstanding practice is to outsource the management and 130 implementation of some important functions (e.g., [RFC5620]). The 131 protocol parameter registry function falls into this category of 132 outsourced functions, and what follows here the comprehensive and 133 normative description of the roles and responsibilities with respect 134 to the registration of IETF protocol parameters. 136 Specifically, this document describes the operation and role of a 137 delegated IETF Protocol Parameter Registry Operator, to be selected 138 and administered by the IETF Administrative Support Activity (IASA) 139 [RFC4071]. While there is generally a single Protocol Parameter 140 Registry Operator, additional Operators may be selected to implement 141 specific registries. This document also includes a description of 142 the roles of other bodies that interact with IETF protocol parameter 143 registry operators. 145 Many protocols make use of identifiers consisting of constants and 146 other well-known values. Even after a protocol has been defined and 147 deployment has begun, new values may need to be assigned (e.g., for a 148 new option type in DHCP, or a new encryption or authentication 149 algorithm for IPsec). To ensure that such quantities have consistent 150 values and interpretations in different implementations, their 151 assignment must be administered by a central authority in a 152 mechanical manner. For IETF protocols, that role is provided by a 153 delegated Protocol Parameter Registry Operator. For any particular 154 protocol parameter there is a single delegated registry operator. In 155 the case of IP addresses and AS numbers, the IANA function resides at 156 the root of the number space, and a subsequent allocation hierarchy 157 exists below IANA. The next step in the hierarchy below IANA is the 158 Regional Internet Registries (RIR), which make further allocations of 159 those resources using policies established through the RIRs' bottom- 160 up policy development process. 162 2.1. Protocol Parameter Registry Operator Role 164 The IETF Protocol Parameter registry function is undertaken under the 165 auspices of the Internet Architecture Board. 167 The roles of a Protocol Parameter registry operator are as follows: 169 o Review and Advise 171 * A registry operator may be requested to review 172 Internet-Drafts that are being considered by the Internet 173 Engineering Steering Group (IESG), with the objective of 174 offering advice to the IESG regarding the contents of the 175 "IANA Considerations" section, whether such a section, 176 when required, is clear in terms of direction to the registry 177 operator, and whether the section is consistent with the 178 current published registry operator guidelines. 180 o Registry 182 * To operate a registry of protocol parameter assignments. 184 * The delegated registry operator registers values for 185 Internet protocol parameters only as directed by the 186 criteria and procedures specified in RFCs, including 187 Proposed, Draft and full Internet Standards, Best Current 188 Practice documents, and other RFCs that require protocol 189 parameter assignment. 191 If values for Internet protocol parameters were not specified, 192 or in case of ambiguity, the registry operator will continue 193 to assign and register only those protocol parameters that 194 have already been delegated to the operator, following past 195 and current practice for such assignments, unless otherwise 196 directed in terms of operating practice by the IESG. In the 197 case of ambiguity, the registry operator is expected to 198 express the ambiguity and either suggest better text or ask 199 the appropriate parties for clarification. 201 * For each protocol parameter, the associated registry 202 includes: 204 + a reference to the RFC document that describes the 205 parameter and the associated "IANA Considerations" 206 concerning the parameter, and 208 + for each registration of a protocol parameter value, 209 the source of the registration and the date of the 210 registration, if the date of registration is known. 212 + If in doubt or in case of a technical dispute, the 213 registry operator will seek and follow technical 214 guidance exclusively from the IESG. Where appropriate 215 the IESG will appoint an expert to advise the registry 216 operator. 218 * The registry operator will work with the IETF to develop any 219 missing criteria and procedures over time, which the registry 220 operator will adopt when so instructed by the IESG. 222 * Each protocol parameter registry operates as a public registry, 223 and the contents of the registry are openly available to the 224 public, on-line and free of charge. 226 * The registry operator assigns protocol parameter values in 227 accordance with the policy associated with the protocol 228 parameter, such as "First Come First Served" or "Expert 229 Review" [RFC5226]. 231 o Mailing Lists 233 * The registry operator maintains public mailing lists as 234 specified in IANA Considerations [RFC5226]. Such lists are 235 designated for the purpose of review of assignment proposals 236 in conjunction with a designated expert review function. In 237 addition, each protocol parameter registry operator should 238 maintain a mailing list that enables the registry staff of 239 the registry operator to be contacted by email. For example, 240 iana@iana.org currently provides this function for IANA. 242 o Liaison Activity 244 * The registry operator will nominate a liaison point of contact. 245 The registry operator, through this liaison, may be requested to 246 provide advice to the IESG on IETF protocol parameters as well 247 as the IANA Considerations section of Internet-Drafts that are 248 being reviewed for publication as an RFC. Where appropriate the 249 IESG will appoint an expert to advise the registry operator. 251 o Reporting 253 * The registry operator will submit periodic reports to the IAB 254 concerning the operational performance of the registry function. 255 As an example of the requirements for such reports the reader is 256 referred to a supplement to the "Memorandum of Understanding 257 Concerning the Technical Work of the Internet Assigned Numbers 258 Authority" [RFC2860] that was established by the IETF 259 Administrative Support Activity (IASA) [RFC4071] and provides 260 service level agreement (SLA) guidelines under which the protocol 261 parameter registry, as implemented by ICANN, must operate. 263 * At the request of the chair of the IETF, IAB, or IAOC the 264 registry operator will undertake periodic reports to the IETF 265 Plenary concerning the status of the registry function. 267 * The registry operator will publish an annual report describing 268 the status of the function and a summary of performance 269 indicators. 271 o Intellectual Property Rights and the Registry Operator 273 * All assigned values are to be published and made available free 274 of any charges. 276 * The assignment values may be redistributed without modification. 278 * Any intellectual property rights of the IETF Protocol Parameter 279 assignment information, including the IETF Protocol Parameter 280 registry and its contents, are to be held by the IETF Trust 281 [RFC4748]. 283 2.2. IAB Role 285 An operator of an IETF Protocol Parameter registry undertakes the 286 role as a delegated function under the authority of the IAB. 288 The IAB has the responsibility to, from time to time, review the 289 current description of the registry function and direct the registry 290 operator to adopt amendments relating to its role and mode of 291 operation of the registry according to the best interests of the 292 IETF, and the Internet community in general. 294 The IAB has the responsibility to appoint an organization to 295 undertake the delegated functions of the Protocol Parameter registry 296 operator for each IETF protocol parameter. Specifically, the IAB 297 defines the role and requirements for the desired functions (e.g., as 298 with the "RFC Editor Model" [RFC5620], and the IAB, the IAOC is 299 responsible for identifying a potential vendor, and once under 300 agreement managing the various aspects of the relationships with that 301 vendor. To be clear, the IAB is in the deciding role (e.g., for 302 appointment and termination), but must work in close consultation 303 with the IAOC. 305 The IAB has the responsibility to determine the terms and conditions 306 of this delegated role. Such terms and conditions should ensure that 307 the registry operates in a manner that is fully conforment to the 308 functions described in this document. In addition, such terms and 309 conditions must not restrict the rights and interests of the IETF 310 with respect to the registry contents and maintenance. 312 2.3. IESG Role 314 The IESG is responsible for the technical direction regarding entries 315 into IETF Protocol Parameter registries and maintaining the policies 316 by which such technical directions are given (e.g., see Appendix B). 317 Technical direction itself is provided through the adoption of 318 directives within the "IANA Considerations" section of IETF RFC 319 documents, or through stand-alone "IANA Considerations" RFC 320 documents. 322 The IESG shall verify that Internet-Drafts that are offered for 323 publication as IETF-stream RFCs [RFC4844] include IANA Considerations 324 sections when needed, and that IANA Considerations sections conform 325 to the current published guidelines. 327 Since technical assessment is not a responsibility of the registry 328 operator the IESG is, as part of providing the technical direction, 329 responsible for identifying the technical experts that are required 330 to, where appropriate, review registration requests or resolve open 331 technical questions that relate to the registration of parameters. 333 The IESG will at its discretion organize the liaison activities with 334 the registry operator's liaison point of contact as to facilitate 335 clear communications and effective operation of the registry 336 function. 338 2.4. Role of the IETF Trust 340 The IETF Trust [RFC4748] was formed to act as the administrative 341 custodian of all copyrights and other intellectual property rights 342 relating to the IETF Standards Process, a function that had 343 previously been performed by ISOC and the Corporation for National 344 Research Initiatives (CNRI). 346 Any intellectual property rights of IETF Protocol Parameter 347 assignment information, including the registry and its contents, and 348 all registry publications, are to be held by the IETF Trust on behalf 349 of the IETF. 351 The IETF Trust may make such regulations as appropriate for the 352 assignment values redistribution and registry publications. 354 2.5. Role of the IAOC 356 The IAOC is responsible for identifying a potential vendor in a 357 manner of their choosing based on IAB consultation, and managing the 358 various aspects of the relationships with that vendor. 360 In addition, the IAOC has the responsibility to ensure long-term 361 access, stability, and uniqueness across all such registries . This 362 responsibility is of particular significance in the event that a 363 relation with a protocol parameter registry operator is terminated. 365 3. Miscellaneous Considerations 367 The IESG is responsible for the technical direction of the IETF 368 Protocol Parameter registries and maintaining the policies by which 369 such technical directions are given. The IESG is responsible, as part 370 of the document approval process for the IETF-stream RFCs [RFC4844], 371 for 'IANA Considerations' verification. For the other RFC streams the 372 approval bodies are responsible for verifying that the documents 373 include IANA Considerations sections when needed, and that IANA 374 Considerations sections conform to the current published guidelines. 375 In the case the that IANA considerations in non-IETF document streams 376 lead to a dispute the IAB has the final word. 378 4. Acknowledgements 380 This document is adapted from "Guidelines for Writing an IANA 381 Considerations Section in RFCs" [RFC5226], and has been modified to 382 include explicit reference to Intellectual Property Rights, and the 383 roles of the IAB and IESG in relation to the IETF Protocol Parameter 384 registry function. 386 The Internet Architecture Board acknowledges the assistance provided 387 by reviewers of earlier drafts of this document, including Scott 388 Bradner, Leslie Daigle, Thomas Narten, Ray Pelletier, and Alfred 389 Hoenes. 391 5. Security Considerations 393 This document does not propose any new protocols, and does not 394 introduce any new security considerations. 396 6. IANA Considerations 398 This document requires no direct IANA actions in terms of the 399 creation or operation of a protocol parameter registry. However, 400 this document does define the roles and responsibilities of various 401 bodies who are responsible for, and associated with, the operation of 402 the protocol parameter registration functions for the IETF. 404 7. References 406 7.1. Normative References 408 7.2. Informative References 410 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 411 STD 2, October 1994. 413 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 414 3", RFC 2026, BCP 9, October 1996. 416 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines 417 For Values In the Internet Protocol and Related Headers", 418 RFC 2780, BCP 37, March 2000. 420 [RFC2850] Carpenter, B., "Charter of the Internet Architecture 421 Board", RFC 2850, BCP 39, May 2000. 423 [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 424 Understanding Concerning the Technical Work of the 425 Internet 426 Assigned Numbers Authority", RFC 2860, June 2000. 428 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 429 of New DHCP Options and Message Types", RFC 2939, BCP 43, 430 September 2000. 432 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 433 Procedures", RFC 2978, BCP 19, October 2000. 435 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 436 an On-line Database", RFC 3232, January 2002. 438 [RFC4071] Austein, R., Wijnen, B., "Structure of the IETF 439 Administrative Support Activity (IASA)", RFC 4071, 440 April 2005. 442 [RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF 443 Trust", RFC 4748, BCP 78, October 2006. 445 [RFC4844] Daigle, L., Ed. and IAB, "The RFC Series and RFC 446 Editor", RFC 4844, July 2007. 448 [RFC5226] Narten, T., Alvestrand, H., "Guidelines for Writing 449 an IANA Considerations Section in RFCs", RFC 5226, 450 May 2008. 452 [RFC5620] Kolkman, O., IAB, "RFC Editor Model (Version 1)", 453 RFC 5620, August 2009. 455 [IANA] Reynolds, J., "IANA Protocol Numbers and Assignment 456 Services", October 1994, . 458 [IAOC_SUPP] ICANN/IANA-IETF MoU Supplemental Agreement 459 462 [CORR] Dyson, E., "Correspondence from Esther Dyson, Interim 463 Chairman, ICANN to Scott Bradner, Brian Carpenter and 464 Fred Baker of the IETF", February 1999, 466 . 468 [ENUM_INSTR] IAB, "ENUM LIAISON ON IAB INSTRUCTIONS TO RIPE-NCC", 469 September 2002, 470 . 472 [RIPE_ENUM] RIPE NCC, "ENUM Registry", September 2002, 473 . 475 8. Authors' Addresses 477 Danny McPherson, Editor 478 Verisign, Inc. 479 Email: dmcpherson@verisign.com 481 Geoff Huston, Editor 482 APNIC 483 Email: gih@apnic.net 485 Olaf M. Kolkman, Editor 486 NLnet Labs 487 Email: olaf@NLnetLabs.nl 489 Internet Architecture Board 490 Email: iab@iab.org 492 9. Appendix A: Considerations on the term IANA 494 The term "Internet Assigned Numbers Authority (IANA)" has been used 495 historically in different contexts. Specifically: 497 1) "IANA" has commonly referred to the set of protocol, DNS, 498 and Address registry functions currently operated by ICANN: 500 It is noted that there is current general use of the term 501 "IANA" or "IANA function" to refer specifically to the set of 502 registries currently operated by ICANN funded through a 503 contract [DoC_IANA] between ICANN and the U.S. Government's 504 National Telecommunications and Information Administration 505 (NTIA). 507 2) Within the IETF context "IANA" has been referred to as the set 508 of registry operators of the IETF protocol parameters: 510 At the time of writing this document (February 2011) the 511 operation of the majority of the protocol parameter registries 512 are delegated to the Internet Corporation for Assigned Names 513 and Numbers (ICANN). Not all IETF protocol parameter 514 registries are delegated to ICANN, and at present the 515 operation of the 'e164.arpa' registry has been delegated to 516 the RIPE Network Coordination Center (RIPE NCC) [ENUM_INSTR]. 518 3) Additionally, and also within IETF context, "IANA" has been 519 referred to as the entire set of IETF protocol parameter 520 registries: 522 IETF specifications continue to use the term "IANA 523 Considerations" when referring to specific functions to be 524 performed with respect to a protocol parameter registry, as 525 provided in "Guidelines for Writing an IANA Considerations 526 Section in RFCs" [RFC5226]. It is noted that the use of 527 the term 'IANA' in this context does not necessarily imply 528 the delegation of the parameter registry operation to the 529 functions operated by ICANN. 531 In addition to the multiple contexts of the use of the term "IANA", 532 the structure and association of the U.S. Government's contractual 533 relationship with ICANN over the performance of a protocol parameter 534 registry operation that is commonly known as the "IANA" role, is a 535 source of some common confusion regarding the question as to who 536 maintains ultimate authority over the protocol parameter registries 537 themselves. ICANN undertakes these "mechanical" tasks on behalf of 538 the IETF at the discretion of the IAB, as defined in the Memorandum 539 of Understanding [RFC2860] between the IETF Administrative Support 540 Activity (IASA) and ICANN, and in supplements [IAOC_SUPP] provided 541 thereafter. 543 10. Appendix B: IANA registries in context 545 10.1. Definition of an IETF Protocol Parameter Registry 547 Using the term 'IANA' in the sense of the entire set of IETF protocol 548 parameter registries, the Internet Standards document, STD 2 549 [RFC1700], published in October 1994, defined the role of the IANA as 550 follows: 552 The Internet Assigned Numbers Authority (IANA) is the central 553 coordinator for the assignment of unique parameter values for 554 Internet protocols. The IANA is chartered by the Internet 555 Society (ISOC) and the Federal Network Council (FNC) to act as 556 the clearinghouse to assign and coordinate the use of numerous 557 Internet protocol parameters. 559 The Internet protocol suite, as defined by the Internet 560 Engineering Task Force (IETF) and its steering group (the IESG), 561 contains numerous parameters, such as Internet protocol addresses, 562 domain names, autonomous system numbers (used in some routing 563 protocols), protocol numbers, port numbers, management information 564 base object identifiers, including private enterprise numbers, and 565 many others. 567 The common use of the Internet protocols by the Internet 568 community requires that the particular values used in these 569 parameter fields be assigned uniquely. It is the task of the 570 IANA to make those unique assignments as requested and to maintain 571 a registry of the currently assigned values [RFC1700]. 573 Again using the term 'IANA' in the sense of the entire set of IETF 574 protocol parameter registries, the definition of the protocol 575 parameter registry role is provided in "Guidelines for Writing an 576 IANA Considerations Section in RFCs" [RFC5226]: 578 Many protocols make use of identifiers consisting of constants 579 and other well-known values. Even after a protocol has been 580 defined and deployment has begun, new values may need to be 581 assigned (e.g., for a new option type in DHCP, or a new encryption 582 or authentication transform for IPsec). To ensure that such 583 quantities have consistent values and interpretations across all 584 implementations, their assignment must be administered by a 585 central authority. For IETF protocols, that role is provided by 586 the Internet Assigned Numbers Authority (IANA). 588 This text appears to confuse two of the three (1 and 3) contexts 589 presented in Appendix A with which the "IANA" term is used. 591 10.2. Publication of Protocol Parameter Registry Assignments 593 Currently there are two registry operators that publicize protocol 594 parameter registry assignments: the IANA registry as operated by 595 ICANN, and the RIPE NCC. 597 The current mode of publication of protocol parameter registry 598 assignments undertaken within registries whose operation is currently 599 delegated to ICANN is described in the Informational Document 600 "Assigned Numbers: RFC 1700 is Replaced by an On-line Database" 601 [RFC3232], published in January 2002: 603 From November 1977 through October 1994, the Internet 604 Assigned Numbers Authority (IANA) periodically published 605 tables of the Internet protocol parameter assignments in 606 RFCs entitled, "Assigned Numbers". The most current of these 607 Assigned Numbers RFCs had Standard status and carried the 608 designation: STD 2. At this time, the latest STD 2 is 609 RFC 1700. 611 Since 1994, this sequence of RFCs have been replaced 612 by an online database accessible through a web page 613 (currently, www.iana.org). The purpose of the present RFC 614 is to note this fact and to officially obsolete RFC 1700, 615 whose status changes to Historic. RFC 1700 is obsolete, and 616 its values are incomplete and in some cases may be wrong 617 [RFC3232]. 619 The mode of publication of the e164.arpa protocol parameter registry 620 operated by the RIPE NCC is documented in the ENUM Registry 621 [RIPE_ENUM]. 623 10.3. Procedures Related to IETF Protocol Parameter Management 625 IETF Protocol Parameter registry actions are defined through the 626 inclusion of an "IANA Considerations" section in IESG-approved RFC 627 documents [RFC5226]. Within these considerations the IETF defines 628 the policies through which a registry operator manages assignments 629 within the registry. There are also RFCs that specifically address 630 IETF protocol parameter considerations for particular protocols 631 [RFC2780][RFC2939] [RFC2978]. 633 10.4. Registries for IETF Protocol Parameters 635 As documented in the IAB Charter [RFC2850], the role of the IAB 636 includes responsibility for the IETF Protocol Parameter registration 637 function (referred to in the charter as 'IANA'). The IAB, acting on 638 behalf of the IETF, approves the appointment of an organization to 639 act as a protocol parameter registry operator on behalf of the IETF, 640 and also approves the terms and conditions of this delegation of this 641 function. 643 The technical direction of the IETF Protocol Parameter registry 644 function is provided by the Internet Engineering Steering Group 645 (IESG) [RFC2850]. 647 10.5. Current IETF Protocol Parameter Assignments 649 The list of current IETF protocol parameters for which parameter 650 value assignments are registered within registries whose operation is 651 currently delegated to ICANN appears on the IANA web site [IANA]. In 652 addition there is the e164.arpa registry function [RIPE_ENUM]. 654 Those protocol parameter registries that refer to registrations 655 related to the allocation of public unicast IPv4 addresses, public 656 unicast IPv6 addresses, public use Autonomous System Numbers (ASNs) 657 and the top level delegations within the Domain Name System, have 658 associated registration mechanisms that have been delegated to the 659 IANA function currently operated under the auspices of ICANN 660 [RFC2860]. In these cases other bodies are responsible for the 661 development of policies to manage the registrations of allocations 662 performed as part of this aspect of the registration function. 663 Registrations that refer to reservations (e.g., IP address blocks for 664 documentation purposes or ASNs defined for documentation purposes) 665 and all other use cases within those registries must be performed 666 under the exclusive direction of the IETF. 668 11. Appendix C: IAB Members 670 Internet Architecture Board Members at the time this document was 671 published were: 673 Marcelo Bagnulo 674 Gonzalo Camarillo 675 Stuart Cheshire 676 Vijay Gill 677 Russ Housley 678 John Klensin 679 Olaf Kolkman 680 Gregory Lebovitz 681 Andrew Malis 682 Danny McPherson 683 David Oran 684 Jon Peterson 685 Dave Thaler