idnits 2.17.1 draft-iab-iana-05.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 4, 2010) is 5195 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 455, 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: 1 error (**), 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 2010 February 4, 2010 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 to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Copyright (c) 2010 IETF Trust and the persons identified as the document 18 authors. All rights reserved. 20 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 21 Relating to IETF Documents (http://trustee.ietf.org/license-info) 22 in effect on the date of publication of this document. Please 23 review these documents carefully, as they describe your rights and 24 restrictions with respect to this document. Code Components 25 extracted from this document must include Simplified BSD License 26 text as described in Section 4.e of the Trust Legal Provisions and 27 are provided without warranty as described in the Simplified BSD 28 License. 30 Internet-Drafts are working documents of the Internet Engineering Task 31 Force (IETF), its areas, and its working groups. Note that other groups 32 may also distribute working documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference material 37 or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright Notice 46 Copyright (C) (2010) The IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 Abstract 51 Many IETF protocols make use of commonly defined values that are 52 passed within protocols. To ensure consistent interpretation of 53 these values by independent implementations, the values and 54 associated semantic intent must be uniquely defined. The IETF uses 55 registry functions to record assigned protocol parameter values and 56 their associated semantic intent. For each IETF protocol parameter it 57 is current practice for the IETF to delegate the role of protocol 58 parameter registry operator to a nominated entity. This document 59 provides a description of and the requirements for these delegated 60 functions. 62 Table of Contents 64 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Roles and Responsibilities concerning IETF Proto- 66 col Registries. . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Protocol Parameter Registry Operator Role . . . . . . . . . 5 68 2.2. IAB Role. . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 2.3. IESG Role . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 2.4. Role of the IETF Trust. . . . . . . . . . . . . . . . . . . 9 71 2.5. Role of the IAOC. . . . . . . . . . . . . . . . . . . . . . 9 72 3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 74 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 10 75 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. Normative References. . . . . . . . . . . . . . . . . . . . 11 78 7.2. Informative References. . . . . . . . . . . . . . . . . . . 11 79 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 80 9. Appendix A: Considerations on the term IANA. . . . . . . . . . 13 81 10. Appendix B: IANA registries in context. . . . . . . . . . . . 14 82 10.1. IETF Protocol Parameter Registry Definition. . . . . . . . 14 83 10.2. Publication of Protocol Parameter Registry 84 Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 10.3. The Procedures related to IETF Protocol 86 Parameter Management . . . . . . . . . . . . . . . . . . . . . . 16 87 10.4. Registries for IETF Protocol Parameters. . . . . . . . . . 16 88 10.5. Current IETF Protocol Parameter 89 Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 11. Appendix C: IAB Members . . . . . . . . . . . . . . . . . . . 17 92 1. Overview 94 Many IETF protocols make use of commonly defined values that are 95 exchanged within protocols. To ensure consistent interpretation of 96 these values by independent implementations, the values and their 97 semantic intent must be uniquely defined. The IETF uses registries 98 to record each of the possible values of a protocol parameter and 99 their associated semantic intent. These registries, their 100 registration policy, and the layout of their content are defined in 101 the "IANA Considerations" sections of IETF documents. 103 The organizational separation between the IETF and its registry 104 operator(s) is one that appears to be a relatively unique arrangement 105 in the context of standards development organizations (SDOs), and 106 similar arrangements of structural separation are not generally used 107 by SDOs. Other SDOs that undertake a similar protocol parameter 108 registration function generally do so as part of their secretariat 109 service functions or their equivalent, thereby avoiding the overhead 110 of detailed coordination of activity across multiple distinct 111 organizations. However, this structural separation of roles exists 112 within several places in the IETF framework (e.g., to include the RFC 113 Editor function). The IAB, on behalf of the IETF, has the 114 responsibility to define and manage the relationship with the 115 protocol registry operator. This responsibility includes the 116 selection and management of the protocol parameter registry 117 operator(s), as well as management of the parameter registration 118 process and the guidelines for parameter allocation. 120 As with other SDO's, the IETF asserts full authority over the 121 management of all the IETF protocol parameters. This document 122 describes the function of these registries as they apply to 123 individual protocol parameters defined by the IETF Internet Standards 124 Process [RFC 2026] as to allow for an orderly implementation by the 125 IAOC under guidance from the IAB. 127 Below we provide a description of the requirement for these delegated 128 functions which the IETF has historically referred to as the IANA 129 function. 131 2. Roles and Responsibilities concerning IETF Protocol Registries 133 It has been the longstanding practice of the IETF to outsource the 134 management and implementation of some important functions (e.g., [RFC 135 5620]). The protocol parameter registry function falls into this 136 category of outsourced function, and what follows here is a 137 comprehensive and normative description of the roles and 138 responsibility with respect to the registration of IETF protocol 139 parameters. 141 Specifically, this document describes the operation and role of a 142 delegated IETF Protocol Parameter Registry Operator, to be selected 143 and administered by the IETF Administrative Support Activity (IASA) 144 [RFC 4071]. While there is generally a single Protocol Parameter 145 Registry Operator, additional Operators may be selected to implement 146 specific registries. This document also describes the roles of other 147 bodies that interact with related bodies with IETF protocol parameter 148 registry operators. 150 Many protocols make use of identifiers consisting of constants and 151 other well-known values. Even after a protocol has been defined and 152 deployment has begun, new values may need to be assigned (e.g., for a 153 new option type in DHCP, or a new encryption or authentication 154 algorithm for IPSec). To ensure that such quantities have consistent 155 values and interpretations in different implementations, their 156 assignment must be administered by a central authority in a 157 coordinated and mechanical manner. For IETF protocols, that role is 158 provided by a delegated Protocol Parameter Registry operator. For 159 any particular protocol parameter there is a single delegated 160 registry operator. In the case of IP addresses and AS numbers, the 161 IANA function resides at the root of the number space, while a 162 subsequent allocation hierarchy exists below IANA, and the Regional 163 Internet Registries (RIR) make further allocations of those resources 164 using policies established through the RIRs' bottom-up policy 165 development process. 167 2.1. Protocol Parameter Registry Operator Role 169 The IETF Protocol Parameter registry function is undertaken under the 170 auspices of the Internet Architecture Board. 172 The roles of a Protocol Parameter registry operator are as follows: 174 o Review and Advise 176 * A registry operator may be requested to review 177 Internet-Drafts that are being considered by the Internet 178 Engineering Steering Group (IESG), with the objective of 179 offering advice to the IESG regarding the need for an 180 "IANA Considerations" section, whether such a section, 181 when required, is clear in terms of direction to the registry 182 operator, and whether the section is consistent with the 183 current published registry operator guidelines. 185 o Registry 187 * To operate a registry of protocol parameter assignments. 189 * The delegated registry operator registers values for 190 Internet protocol parameters only as directed by the 191 criteria and procedures specified in RFCs, including 192 Proposed, Draft and full Internet Standards, Best Current 193 Practice documents, and other RFCs that require protocol 194 parameter assignment. If they are not so specified, or in 195 case of ambiguity, the registry operator will continue to 196 assign and register only those protocol parameters that have 197 already been delegated to the operator, following past and 198 current practice for such assignments, unless otherwise 199 directed in terms of operating practice by the IESG. 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 registry 213 operator will seek and follow technical guidance exclusively from 214 the IESG. Where appropriate the IESG will appoint an expert to 215 advise the registry operator. 217 * The registry operator will work with the IETF to develop any 218 missing criteria and procedures over time, which the registry 219 operator will adopt when so instructed by the IESG. 221 * Each protocol parameter registry operates as a public registry, 222 and the contents of the registry are openly available to the 223 public, on-line and free of charge. 225 * The registry operator assigns protocol parameter values in 226 accordance with the policy associated with the protocol 227 parameter. Some policies are listed in [RFC 5226]. 229 o Mailing Lists 231 * The registry operator maintains public mailing lists as 232 specified in IANA Considerations [RFC 5226]. Such lists are 233 designated for the purpose of review of assignment proposals 234 in conjunction with a designated expert review function. In 235 addition, each protocol parameter registry operator should 236 maintain a mailing list that enables the registry staff of 237 the registry operator to be contacted by email. For example, 238 iana@iana.org currently provides this function for IANA. 240 o Liaison Activity 242 * The registry operator will nominate a liaison point of contact. 243 The registry operator, though this liaison, may be requested to 244 provide advice to the IESG on IETF protocol parameters as well 245 as the IANA Considerations section of Internet-Drafts that are 246 being reviewed for publication as an RFC. Where appropriate the 247 IESG will appoint an expert to advise the registry operator. 249 o Reporting 251 * The registry operator will submit periodic reports to the IAB 252 concerning the operational performance of the registry function. 253 As an example of the requirements for such reports the reader is 254 referred to a supplement to the MoU outlined in [RFC 2860] that 255 was established by the IASA [RFC 4071] and provides service level 256 agreement (SLA) guidelines under which the protocol parameter 257 registry, as implemented by ICANN, must operate. 259 * At the request of the chair of the IETF, IAB, or IAOC the 260 registry operator will undertake periodic reports to the IETF 261 Plenary concerning the status of the registry function. 263 * The registry operator will publish an annual report describing 264 the status of the function and a summary of performance 265 indicators. 267 o Intellectual Property Rights and the Registry Operator 269 * All assigned values are to be published and made available free 270 of any charges and free of any constraints relating to further 271 redistribution, with the caveat that the assignment information 272 may not be modified in any redistributed copy. 274 * Any intellectual property rights of the IETF Protocol Parameter 275 assignment information, including the IETF Protocol Parameter 276 registry and its contents, are to be held by the IETF Trust 277 [RFC 4748], and all IETF Protocol Parameter registry publications 278 relating to assignment information are to be published under the 279 terms of Section 10 of [RFC 2026], and are to include the 280 copyright notice as documented in Section 10.4 (C) of [RFC 2026]. 282 2.2. IAB Role 284 An operator of an IETF Protocol Parameter registry undertakes the 285 role as a delegated function under the authority of the Internet 286 Architecture Board (IAB). 288 The IAB has the responsibility to review the current description of 289 the registry function on a schedule of its own choosing. The IAB 290 shall direct the registry operator to adopt amendments relating to 291 its role and mode of operation of the registry according to the best 292 interests of the IETF. 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 [RFC 5620]), and in consultation with the IAB, the IAOC is 299 responsible for identifying potential vendors and managing aspects of 300 the relationships with that vendor. To be clear, the IAB is in the 301 deciding role (e.g., for appointment and termination), but must work 302 in close consultation with the IAOC. 304 The IAB has the responsibility to determine the terms and conditions 305 of this delegated role. Such terms and conditions should ensure that 306 the registry operates in a manner that fully conforms to the 307 functions described in this document. In addition, such terms and 308 conditions must not restrict the rights and interests of the IETF 309 with respect to the registry content and maintenance. 311 2.3. IESG Role 313 The IESG is responsible for the technical direction of the IETF 314 Protocol Parameter registries and maintaining the policies by which 315 such technical directions are given (e.g., see Appendix B). 316 Technical direction itself is provided through the adoption of IETF 317 RFC documents within the "IANA Considerations" section of such 318 documents, or as stand-alone "IANA Considerations" RFC documents. 320 The IESG shall verify that Internet-Drafts that are offered for 321 publication as IETF-stream RFCs [RFC 4844] include IANA 322 Considerations sections when needed, and that IANA Considerations 323 sections conform to the current published guidelines. For other RFC 324 streams, the respective approval bodies for those streams are 325 responsible for verifying tha the documents include IANA 326 consideration when necessary, and that those IANA considerations 327 conform to the current published guidelines. 329 Since technical assessment is not a responsibility of the registry 330 operator, the IESG, as part of providing the technical direction, is 331 responsible for identifying the technical experts that are required 332 to, where appropriate, review registration requests or resolve open 333 technical questions that relate to the registration of parameters. 335 The IESG will at its discretion organize the liaison activities with 336 the registry operator's liaison point of contact; as to facilitate 337 clear communications and effective operation of the registry 338 function. 340 2.4. Role of the IETF Trust 342 Any intellectual property rights of IETF Protocol Parameter 343 assignment information, including the registry and its contents, and 344 all registry publications, are to be held by the IETF Trust on behalf 345 of the IETF. 347 The IETF Trust [RFC 4748] was formed to act as the administrative 348 custodian of all copyrights and other intellectual property rights 349 relating to the IETF Standards Process, a function that had 350 previously been performed by ISOC and the Corporation for National 351 Research Initiatives (CNRI). 353 2.5. Role of the IAOC 355 In consultation with the IAB, the IAOC is responsible for identifying 356 a potential vendor based on IAB consultation, and managing the 357 various aspects of the relationships with that vendor. 359 In addition, the IAOC has the responsibility to ensure long-term 360 availability and stability across all such registries and their 361 contents. This responsibility is of particular significance in the 362 event that a relation with a protocol parameter registry operator is 363 terminated. 365 3. Miscellaneous 367 In it's current incarnation, the IANA function operator also 368 maintains registries from other SDOs that are of interest to the IETF 369 community, or add new codepoints to IETF protocols. Some registries 370 are also specified and used by ICANN itself. Some example registries 371 include "NLPIDs of Interest", "IEEE 802 Numbers", "Address Family 372 Numbers", and "Repository of IDN Practices". While these registries 373 are not specified or expressly requested on behalf of the IETF, and 374 their contents are not captive to express oversight by the IETF, they 375 are relevant to IETF work. 377 4. Acknowledgements 379 This document is adapted from [RFC 5226], and has been modified to 380 include explicit reference to Intellectual Property Rights, and the 381 roles of the IAB and IESG in relation to the IETF Protocol Parameter 382 registry function. 384 The Internet Architecture Board acknowledges the assistance provided 385 by reviewers of earlier drafts of this document, including Scott 386 Bradner, Leslie Daigle and Thomas Narten. 388 5. Security Considerations 390 This document does not propose any new protocols, and does not 391 involve any security considerations. 393 6. IANA Considerations 395 This document requires no direct IANA actions. 397 7. References 399 7.1. Normative References 401 7.2. Informative References 403 [RFC 1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 404 STD 2, October 1994. 406 [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 407 3", RFC 2026, BCP 9, October 1996. 409 [RFC 2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines 410 For Values In the Internet Protocol and Related Headers", 411 RFC 2780, BCP 37, March 2000. 413 [RFC 2850] Carpenter, B., "Charter of the Internet Architecture 414 Board", RFC 2850, BCP 39, May 2000. 416 [RFC 2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 417 Understanding Concerning the Technical Work of the 418 Internet Assigned Numbers Authority", RFC 2860, June 419 2000. 421 [RFC 2939] Droms, R., "Procedures and IANA Guidelines for Definition 422 of New DHCP Options and Message Types", RFC 2939, BCP 43, 423 September 2000. 425 [RFC 2978] Freed, N. and J. Postel, "IANA Charset Registration 426 Procedures", RFC 2978, BCP 19, October 2000. 428 [RFC 3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 429 an On-line Database", RFC 3232, January 2002. 431 [RFC 4071] Austein, R., Wijnen, B., "Structure of the IETF 432 Administrative Support Activity (IASA)", RFC 4071, 433 April 2005. 435 [RFC 4748] Bradner, S., "RFC 3978 Update to Recognize the IETF 436 Trust", RFC 4748, BCP 78, October 2006. 438 [RFC 4844] Daigle, L., Ed. and IAB, "The RFC Series and RFC 439 Editor", RFC 4844, July 2007. 441 [RFC 5226] Narten, T., Alvestrand, H., "Guidelines for Writing 442 an IANA Considerations Section in RFCs", RFC 5226, 443 May 2008. 445 [RFC 5620] Kolkman, O., IAB, "RFC Editor Model (Version 1)", 446 RFC 5620, August 2009. 448 [IANA] Reynolds, J., "IANA Protocol Numbers and Assignment 449 Services", October 1994, . 451 [IAOC_SUPP] ICANN/IANA-IETF MoU Supplemental Agreement 452 455 [CORR] Dyson, E., "Correspondence from Esther Dyson, Interim 456 Chairman, ICANN to Scott Bradner, Brian Carpenter and 457 Fred Baker of the IETF", February 1999, 458 . 460 [ENUM_INSTR] IAB, "ENUM LIAISON ON IAB INSTRUCTIONS TO RIPE-NCC", 461 September 2002, 462 . 464 [RIPE ENUM] RIPE NCC, "ENUM Registry", September 2002, 465 . 467 8. Authors' Addresses 468 Danny McPherson, Editor 469 Arbor Networks, Inc. 470 Email: danny@arbor.net 472 Geoff Huston, Editor 473 APNIC 474 Email: gih@apnic.net 476 Olaf M. Kolkman, Editor 477 NLnet Labs 478 Email: olaf@NLnetLabs.nl 480 Internet Architecture Board 481 Email: iab@iab.org 483 9. Appendix A: Considerations on the term IANA 485 The term "Internet Assigned Numbers Authority (IANA)" has been used 486 historically in different contexts. Specifically: 488 1) "IANA" has is commonly referred to as the set of protocol, DNS, 489 and Address registry functions operated by ICANN: 491 It is noted that there is current general use of the term 492 "IANA" or "IANA function" to refer specifically to the set of 493 registries operated by ICANN funded through a contract 494 [DoC_IANA] between ICANN and the U.S. Government's National 495 Telecommunications and Information Administration (NTIA). 497 2) Within the IETF context "IANA" has been referred to as the set 498 of registry operators of the IETF protocol parameters: 500 At the time of the writing this document (December 2009) the 501 operation of the majority of the protocol parameter registries 502 are delegated to the Internet Corporation for Assigned Names 503 and Numbers (ICANN). Not all IETF protocol parameter 504 registries are delegated to ICANN, and at present the 505 operation of the 'e164.arpa' registry has been delegated to 506 the RIPE Network Coordination Center (RIPE NCC) [ENUM_INSTR]. 508 3) Additionally, and also within IETF context, "IANA" has been 509 referred to as the entire set of IETF protocol parameter 510 registries: 512 The IETF documents continue to use the term "IANA 513 Considerations" when referring to specific functions to be 514 performed with respect to a protocol parameter registry [RFC 515 5226], it is noted that the use of the term 'IANA' in this 516 context does not necessarily imply the delegation of the 517 parameter registry operation to the function operated by ICANN. 519 In addition to the multiple contexts of the use of the term "IANA", 520 the structure and association of the U.S. Government's contractual 521 relationship with ICANN over the performance of a protocol parameter 522 registry operation that is commonly known as the "IANA" role, is a 523 source of some common confusion regarding the question as to who 524 maintains ultimate authority over the protocol parameter registries 525 themselves. ICANN undertakes these "mechanical" tasks on behalf of 526 the IETF at the discretion of the IAB, as defined in the Memorandum 527 of Understanding [RFC 2860] between the IETF Administrative Support 528 Activity (IASA) and ICANN, and in supplements [IAOC_SUPP] provided 529 thereafter. 531 10. Appendix B: IANA registries in context 533 10.1. IETF Protocol Parameter Registry Definition 535 Using the term 'IANA' in the sense of the entire set of IETF protocol 536 parameter registries, the Internet Standards document, STD 2 [RFC 537 1700], published in October 1994, defined the role of the IANA as 538 follows: 540 The Internet Assigned Numbers Authority (IANA) is the central 541 coordinator for the assignment of unique parameter values for 542 Internet protocols. The IANA is chartered by the Internet 543 Society (ISOC) and the Federal Network Council (FNC) to act as 544 the clearinghouse to assign and coordinate the use of numerous 545 Internet protocol parameters. 547 The Internet protocol suite, as defined by the Internet 548 Engineering Task Force (IETF) and its steering group (the IESG), 549 contains numerous parameters, such as Internet protocol addresses, 550 domain names, autonomous system numbers (used in some routing 551 protocols), protocol numbers, port numbers, management information 552 base object identifiers, including private enterprise numbers, and 553 many others. 555 The common use of the Internet protocols by the Internet 556 community requires that the particular values used in these 557 parameter fields be assigned uniquely. It is the task of the 558 IANA to make those unique assignments as requested and to maintain 559 a registry of the currently assigned values [RFC 1700]. 561 Again using the term 'IANA' in the sense of the entire set of IETF 562 protocol parameter registries, the definition of the protocol 563 parameter registry role is provided in [RFC 5226]: 565 Many protocols make use of identifiers consisting of constants 566 and other well-known values. Even after a protocol has been 567 defined and deployment has begun, new values may need to be 568 assigned (e.g., for a new option type in DHCP, or a new encryption 569 or authentication transform for IPsec). To ensure that such 570 quantities have consistent values and interpretations across all 571 implementations, their assignment must be administered by a 572 central authority. For IETF protocols, that role is provided by 573 the Internet Assigned Numbers Authority (IANA). 575 This text appears to confuse two of the three (1 and 3) contexts 576 presented in Appendix A with which the "IANA" term is used. 578 10.2. Publication of Protocol Parameter Registry Assignments 580 Currently there are two registry operators that publicize protocol 581 parameter registry assignments: the IANA registry as operated by 582 ICANN, and the RIPE NCC. 584 The current mode of publication of protocol parameter registry 585 assignments undertaken within registries whose operation is currently 586 delegated to ICANN is described in the Informational Document [RFC 587 3232], published in January 2002: 589 From November 1977 through October 1994, the Internet 590 Assigned Numbers Authority (IANA) periodically published 591 tables of the Internet protocol parameter assignments in 592 RFCs entitled, "Assigned Numbers". The most current of these 593 Assigned Numbers RFCs had Standard status and carried the 594 designation: STD 2. At this time, the latest STD 2 is 595 RFC 1700. 597 Since 1994, this sequence of RFCs have been replaced 598 by an online database accessible through a web page 599 (currently, www.iana.org). The purpose of the present RFC 600 is to note this fact and to officially obsolete RFC 1700, 601 whose status changes to Historic. RFC 1700 is obsolete, and 602 its values are incomplete and in some cases may be wrong 603 [RFC 3232]. 605 The mode of publication of the e164.arpa protocol parameter registry 606 operated by the RIPE NCC is documented in reference [RIPE ENUM]. 608 10.3. The Procedures related to IETF Protocol Parameter Management 610 IETF Protocol Parameter registry actions are defined through the 611 inclusion of an "IANA Considerations" section in IESG-approved RFC 612 documents, as described in [RFC 5226]. Within these considerations 613 the IETF defines the policies through which a registry operator 614 manages assignments within the registry. There are also RFCs that 615 specifically address IETF protocol parameter considerations for 616 particular protocols, such as [RFC 2780], [RFC 2939], and [RFC 2978]. 618 10.4. Registries for IETF Protocol Parameters 620 As documented in the IAB Charter [RFC 2850], the role of the IAB 621 includes responsibility for the IETF Protocol Parameter registration 622 function (referred to in the charter as 'IANA'). The IAB, acting on 623 behalf of the IETF, approves the appointment of an organization to 624 act as a protocol parameter registry operator on behalf of the IETF, 625 and also approves the terms and conditions of this delegation of this 626 function. 628 The technical direction of the IETF Protocol Parameter registry 629 function is provided by the Internet Engineering Steering Group 630 (IESG) [RFC 2850]. 632 10.5. Current IETF Protocol Parameter Assignments 634 The list of current IETF protocol parameters for which parameter 635 value assignments are registered within registries whose operation is 636 currently delegated to ICANN is listed in reference [IANA]. In 637 addition there is the e164.arpa registry function, which is listed in 638 reference [RIPE ENUM]. 640 As provided in the list contained in [IANA], those protocol parameter 641 registries that refer to registrations related to the allocation of 642 public unicast IPv4 addresses, public unicast IPv6 addresses, public 643 use Autonomous System Numbers (ASNs) and the top level delegations 644 within the Domain Name System, have associated registration 645 mechanisms that have been delegated to the IANA function operated 646 under the auspices of ICANN, as defined in [RFC 2860]. In these cases 647 other bodies are responsible for the development of policies to 648 manage the registrations of allocations performed as part of this 649 aspect of the registration function. Registrations that refer to 650 reservations (e.g., IP address blocks for documentation purposes or 651 ASNs defined for documentation purposes) and all other use cases 652 within those registries must be performed under the exclusive 653 direction of the IETF. 655 11. Appendix C: IAB Members 657 Internet Architecture Board Members at the time this document was 658 published were: 660 Marcelo Bagnulo 661 Gonzalo Camarillo 662 Stuart Cheshire 663 Vijay Gill 664 Russ Housley 665 John Klensin 666 Olaf Kolkman 667 Gregory Lebovitz 668 Andrew Malis 669 Danny McPherson 670 David Oran 671 Jon Peterson 672 Dave Thaler 674 Copyright Statement 676 Copyright (C) (2010) The IETF Trust and the persons 677 identified as the document authors. All rights reserved. 679 This document is subject to BCP 78 and the IETF Trust's Legal 680 Provisions Relating to IETF Documents 681 (http://trustee.ietf.org/license-info) in effect on the date of 682 publication of this document. Please review these documents 683 carefully, as they describe your rights and restrictions with 684 respect to this document.