idnits 2.17.1 draft-iab-iana-07.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 (March 24, 2011) is 4779 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1700' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'RFC2780' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'RFC2850' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC2939' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC2978' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC3232' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'IANA' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'CORR' is defined on line 466, 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 (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Danny McPherson, Ed. 2 Olaf M. Kolkman, Ed. 3 John Klensin, Ed. 4 Geoff Huston, Ed. 5 Internet Architecture Board 6 Expires: September 2011 March 24, 2011 7 Intended Status: Informational 9 Defining the Role and Function of IETF Protocol 10 Parameter Registry Operators 11 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF). Note that other groups may also distribute 20 working documents as Internet-Drafts. The list of current Internet- 21 Drafts is at http://datatracker.ietf.org/drafts/current/. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 Copyright Notice 30 Copyright (c) 2011 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 45 Many IETF protocols make use of commonly-defined values that are 46 passed in messages or packets. To ensure consistent interpretation 47 of these values between independent implementations, there is a need 48 to ensure that the values and associated semantic intent are uniquely 49 defined. The IETF uses registry functions to record assigned 50 protocol parameter values and their associated semantic intent. For 51 each IETF protocol parameter it is current practice for the IETF to 52 delegate the role of protocol parameter registry operator to a 53 nominated entity. This document provides a description of, and the 54 requirements for, these delegated functions. 56 Table of Contents 58 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Roles and Responsibilities Concerning IETF Proto- 60 col Parameter Registries. . . . . . . . . . . . . . . . . . . . . 5 61 2.1. Protocol Parameter Registry Operator Role . . . . . . . . . 6 62 2.2. IAB Role. . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.3. IESG Role . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 2.4. Role of the IETF Trust. . . . . . . . . . . . . . . . . . . 10 65 2.5. Role of the IAOC. . . . . . . . . . . . . . . . . . . . . . 10 66 3. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 10 67 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 68 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 11 69 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 7.1. Normative References. . . . . . . . . . . . . . . . . . . . 11 72 7.2. Informative References. . . . . . . . . . . . . . . . . . . 12 73 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 74 9. Appendix A: IAB Members. . . . . . . . . . . . . . . . . . . . 14 76 1. Overview 78 Many IETF protocols make use of commonly-defined values that are 79 passed within messages or packets. To ensure consistent 80 interpretation of these values between independent implementations, 81 there is a need to ensure that the values and associated semantic 82 intent are uniquely defined. The IETF uses registries to record each 83 of the possible values of a protocol parameter and their associated 84 semantic intent. These registries, their registration policy, and 85 the layout of their content are defined in the so called "IANA 86 Consideration" sections of IETF documents. 88 The organizational separation between the IETF and its registry 89 operators parallels ones that are fairly common among standards 90 development organizations (SDOs) although less common among 91 technology consortia and similar bodies. This organizational 92 separation has been done for a number of reasons, ranging from the 93 need to deal with administrative issus and concerns about maintaining 94 arms-length separation of basic policy and specific allocations, to 95 avoiding any potential conflicts of interest for commercial or 96 organizational reasons. For example, most ISO and ISO/IEC JTC1 97 standards that require registration activities specify Registration 98 Authorities (RA) or Maintenance Agencies (MA) that, in turn, control 99 the actual registration decisions. The databases of what is 100 registered for each standard may then be maintained by a secretariat 101 or database function associated with the RA or MA or, less 102 frequently, by the secretariat of the body that created and maintains 103 the standard itself. 105 However, this structural separation of roles exists within several 106 places in the IETF framework (e.g., the RFC Editor function). The 107 Internet Architecture Board (IAB), on behalf of the IETF, has the 108 responsibility to define and manage the relationship with the 109 protocol registry operator role. This responsibility includes the 110 selection and management of the protocol parameter registry operator, 111 as well as management of the parameter registration process and the 112 guidelines for parameter allocation. 114 As with other SDOs, although it may delegate authority for some 115 specific decisions, the IETF asserts authority and responsibility for 116 the management of all of its protocol parameters and their registries 117 even while it generally remains isolated from the selection of 118 particular values once a registration is approved. This document 119 describes the function of these registries as they apply to 120 individual protocol parameters defined by the IETF Internet Standards 121 Process [RFC2026] to allow for an orderly implementation by the 122 Internet Administrative Oversight Committee (IAOC), and others as 123 needed, under guidance from the IAB. 125 Below we provide a description of the requirement for these delegated 126 functions, which the IETF traditionally refers to as the Internet 127 Assigned Numbers Authority (IANA) function. 129 2. Roles and Responsibilities Concerning IETF Protocol Parameter 130 Registries 132 The IETF's longstanding practice is to outsource the management and 133 implementation of some important functions (e.g., [RFC5620]). The 134 protocol parameter registry function falls into this category of 135 outsourced functions, and what follows here is the comprehensive and 136 normative description of the roles and responsibilities with respect 137 to the registration of IETF protocol parameters. 139 Specifically, this document describes the operation and role of a 140 delegated IETF Protocol Parameter Registry Operator, to be selected 141 and administered by the IETF Administrative Support Activity (IASA) 142 [RFC4071]. While there is generally a single Protocol Parameter 143 Registry Operator, additional Operators may be selected to implement 144 specific registries and that has been done occasionally. Having a 145 single operator facilitates coordination among registries, even those 146 that are not obviously related. It also makes it easier to have 147 consistency of formats and registry structure, which aids users of 148 the registries and assists with quality control. 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. For IETF 157 protocols, that role is provided by a delegated Protocol Parameter 158 Registry Operator. For any particular protocol parameter there is a 159 single delegated registry operator. 161 2.1. Protocol Parameter Registry Operator Role 163 The IETF Protocol Parameter registry function is undertaken under the 164 auspices of the Internet Architecture Board. 166 The roles of a Protocol Parameter registry operator are as follows: 168 o Review and Advise 170 * A registry operator may be requested to review 171 Internet-Drafts that are being considered by the Internet 172 Engineering Steering Group (IESG), with the objective of 173 offering advice to the IESG regarding the contents of the 174 "IANA Considerations" section, whether such a section, 175 when required, is clear in terms of direction to the registry 176 operator, and whether the section is consistent with the 177 current published registry operator guidelines. 179 o Registry 181 * To operate a registry of protocol parameter assignments. 183 * The delegated registry operator registers values for 184 Internet protocol parameters only as directed by the 185 criteria and procedures specified in RFCs, including 186 Proposed, Draft and full Internet Standards, Best Current 187 Practice documents, and other RFCs that require protocol 188 parameter assignment. 190 If values for Internet protocol parameters were not specified, 191 or in case of ambiguity, the registry operator will continue 192 to assign and register only those protocol parameters that 193 have already been delegated to the operator, following past 194 and current practice for such assignments, unless otherwise 195 directed in terms of operating practice by the IESG. In the 196 case of ambiguity, the registry operator is expected to 197 identify the ambiguity to the IAB or IESG as appropriate and 198 either suggest better text or ask the appropriate parties for 199 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, and 212 + any other information specified for being included in 213 the registration data in the RFC document that 214 describes the parameter. 216 + If in doubt or in case of a technical dispute, the 217 registry operator will seek and follow technical 218 guidance exclusively from the IESG. Where appropriate 219 the IESG will appoint an expert to advise the registry 220 operator. 222 * The registry operator will work with the IETF to develop any 223 missing criteria and procedures over time, which the registry 224 operator will adopt when so instructed by the IESG. 226 * Unless special circumstances apply to subsets of the data and 227 specific rules are established by IETF consensus, each protocol 228 parameter registry operates as a public registry, and the 229 contents of the registry are openly available to the public, 230 on-line and free of charge. 232 * The registry operator assigns protocol parameter values in 233 accordance with the policy associated with the protocol 234 parameter, such as "First Come First Served" or "Expert 235 Review" [RFC5226]. 237 o Mailing Lists 239 * The registry operator maintains public mailing lists as 240 specified in IANA Considerations [RFC5226]. Such lists are 241 designated for the purpose of review of assignment proposals 242 in conjunction with a designated expert review function. In 243 addition, each protocol parameter registry operator should 244 maintain a mailing list that enables the registry staff of 245 the registry operator to be contacted by email. For example, 246 iana@iana.org currently provides this function for IANA. 248 o Liaison Activity 250 * The registry operator will nominate a liaison point of contact. 251 The registry operator, through this liaison, may be requested to 252 provide advice to the IESG on IETF protocol parameters as well 253 as the IANA Considerations section of Internet-Drafts that are 254 being reviewed for publication as an RFC. Where appropriate the 255 IESG will appoint an expert to advise the registry operator. 257 o Reporting 259 * The registry operator will submit periodic reports to the IAB 260 concerning the operational performance of the registry function. 261 As an example of the requirements for such reports the reader is 262 referred to a supplement [IAOC_SUPP] to the "Memorandum of 263 Understanding Concerning the Technical Work of the Internet 264 Assigned Numbers Authority" [RFC2860] that was established by 265 the IAB and provides service level agreement (SLA) guidelines 266 under which the protocol parameter registry, as implemented by 267 ICANN, must operate. 269 * At the request of the chair of the IETF, IAB, or IAOC, the 270 registry operator will undertake periodic reports to IETF 271 Plenary meetings concerning the status of the registry function. 273 * The registry operator will publish an annual report describing 274 the status of the function and a summary of performance 275 indicators. 277 o Intellectual Property Rights and the Registry Operator 279 * All assigned values are to be published and made available free 280 of any charges. 282 * The assignment values may be redistributed without modification. 284 * Any intellectual property rights of the IETF Protocol Parameter 285 assignment information, including the IETF Protocol Parameter 286 registry and its contents, are to be held by the IETF Trust 287 [RFC4748]. 289 2.2. IAB Role 291 An operator of an IETF Protocol Parameter registry undertakes the 292 role as a delegated function under the authority of the IAB. 294 The IAB has the responsibility to review the current description of 295 the registry function from time to time and direct the registry 296 operator to adopt amendments relating to its role and mode of 297 operation according to the best interests of the IETF, and the 298 Internet community in general. 300 The IAB has the responsibility to appoint an organization to 301 undertake the delegated functions of the Protocol Parameter registry 302 operator for each IETF protocol parameter. Specifically, the IAB 303 defines the role and requirements for the desired functions. The 304 IAOC is responsible for identifying a potential vendor, and once 305 under agreement, managing the various aspects of the relationships 306 with that vendor. To be clear, the IAB is in the deciding role 307 (e.g., for appointment and termination), but must work in close 308 consultation with the IAOC. 310 The IAB has the responsibility to determine the terms and conditions 311 of this delegated role. Such terms and conditions should ensure that 312 the registry operates in a manner that is fully conformant to the 313 functions described in this document. In addition, such terms and 314 conditions must not restrict the rights and interests of the IETF 315 with respect to the registry contents and maintenance. 317 2.3. IESG Role 319 The IESG is responsible for the technical direction regarding entries 320 into IETF Protocol Parameter registries and maintaining the policies 321 by which such technical directions are given. Technical direction 322 itself is provided through the adoption of directives within the 323 "IANA Considerations" section of IETF RFC documents, or through 324 stand-alone "IANA Considerations" RFC documents. 326 The IESG shall verify that Internet-Drafts that are offered for 327 publication as IETF Stream RFCs [RFC4844] include IANA Considerations 328 sections when needed, and that IANA Considerations sections conform 329 to the current published guidelines. 331 Since technical assessment is not generally a responsibility of the 332 registry operator, as part of providing the technical direction, the 333 IESG is responsible for identifying the technical experts that are 334 required to, where appropriate, review registration requests or 335 resolve open technical questions that relate to the registration of 336 parameters. 338 The IESG will at its discretion organize the liaison activities with 339 the registry operator's liaison point of contact as to facilitate 340 clear communications and effective operation of the registry 341 function. 343 2.4. Role of the IETF Trust 345 The IETF Trust [RFC4748] was formed to act as the administrative 346 custodian of all copyrights and other intellectual property rights 347 relating to the IETF Standards Process, a function that had 348 previously been performed by ISOC and the Corporation for National 349 Research Initiatives (CNRI). 351 Any intellectual property rights of IETF Protocol Parameter 352 assignment information, including the registry and its contents, and 353 all registry publications, are to be held by the IETF Trust on behalf 354 of the IETF. 356 The IETF Trust may make such regulations as appropriate for the 357 redistribution of assignment values and registry publications. 359 2.5. Role of the IAOC 361 The IAOC is responsible for identifying a potential vendor in a 362 manner of their choosing based on IAB consultation, and managing the 363 various aspects of the relationships with that vendor. 365 In addition, the IAOC has the responsibility to ensure long-term 366 access, stability, and uniqueness across all such registries . This 367 responsibility is of particular significance in the event that a 368 relation with a protocol parameter registry operator is terminated. 370 3. Miscellaneous Considerations 372 The IESG is responsible for the technical direction of the IETF 373 Protocol Parameter registries and maintaining the policies by which 374 such technical directions are given. The IESG is responsible, as part 375 of the document approval process for the IETF-stream RFCs [RFC4844], 376 for 'IANA Considerations' verification. For the other RFC streams the 377 approval bodies are responsible for verifying that the documents 378 include IANA Considerations sections when needed, and that IANA 379 Considerations sections conform to the current published guidelines. 380 In the case the that IANA considerations in non-IETF document streams 381 lead to a dispute the IAB has the final word. 383 4. Acknowledgements 385 This document is adapted from "Guidelines for Writing an IANA 386 Considerations Section in RFCs" [RFC5226], and has been modified to 387 include explicit reference to Intellectual Property Rights, and the 388 roles of the IAB and IESG in relation to the IETF Protocol Parameter 389 registry function. 391 The Internet Architecture Board acknowledges the assistance provided 392 by reviewers of earlier drafts of this document, including Scott 393 Bradner, Leslie Daigle, Alfred Hoenes, Thomas Narten, and Ray 394 Pelletier. 396 5. Security Considerations 398 This document does not propose any new protocols, and does not 399 introduce any new security considerations. 401 6. IANA Considerations 403 This document requires no direct IANA actions in terms of the 404 creation or operation of a protocol parameter registry. However, 405 this document does define the roles and responsibilities of various 406 bodies who are responsible for, and associated with, the operation of 407 the protocol parameter registration functions for the IETF. 409 7. References 411 7.1. Normative References 412 7.2. Informative References 414 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 415 STD 2, October 1994. 417 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 418 3", RFC 2026, BCP 9, October 1996. 420 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines 421 For Values In the Internet Protocol and Related Headers", 422 RFC 2780, BCP 37, March 2000. 424 [RFC2850] Carpenter, B., "Charter of the Internet Architecture 425 Board", RFC 2850, BCP 39, May 2000. 427 [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 428 Understanding Concerning the Technical Work of the 429 Internet 430 Assigned Numbers Authority", RFC 2860, June 2000. 432 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 433 of New DHCP Options and Message Types", RFC 2939, BCP 43, 434 September 2000. 436 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 437 Procedures", RFC 2978, BCP 19, October 2000. 439 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 440 an On-line Database", RFC 3232, January 2002. 442 [RFC4071] Austein, R., Wijnen, B., "Structure of the IETF 443 Administrative Support Activity (IASA)", RFC 4071, 444 April 2005. 446 [RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF 447 Trust", RFC 4748, BCP 78, October 2006. 449 [RFC4844] Daigle, L., Ed. and IAB, "The RFC Series and RFC 450 Editor", RFC 4844, July 2007. 452 [RFC5226] Narten, T., Alvestrand, H., "Guidelines for Writing 453 an IANA Considerations Section in RFCs", RFC 5226, 454 May 2008. 456 [RFC5620] Kolkman, O., IAB, "RFC Editor Model (Version 1)", 457 RFC 5620, August 2009. 459 [IANA] Reynolds, J., "IANA Protocol Numbers and Assignment 460 Services", October 1994, . 462 [IAOC_SUPP] ICANN/IANA-IETF MoU Supplemental Agreement 463 466 [CORR] Dyson, E., "Correspondence from Esther Dyson, Interim 467 Chairman, ICANN to Scott Bradner, Brian Carpenter and 468 Fred Baker of the IETF", February 1999, 469 . 471 [ENUM_INSTR] IAB, "ENUM LIAISON ON IAB INSTRUCTIONS TO RIPE-NCC", 472 September 2002, 473 . 475 [RIPE_ENUM] RIPE NCC, "ENUM Registry", September 2002, 476 . 478 8. Authors' Addresses 480 Danny McPherson, Editor 481 Verisign, Inc. 482 Email: dmcpherson@verisign.com 484 Olaf M. Kolkman, Editor 485 NLnet Labs 486 Email: olaf@NLnetLabs.nl 488 John C Klensin 489 Email: john+ietf@jck.com 491 Geoff Huston, Editor 492 APNIC 493 Email: gih@apnic.net 495 Internet Architecture Board 496 Email: iab@iab.org 498 9. Appendix A: IAB Members 500 Internet Architecture Board Members at the time this document was 501 published were: 503 Marcelo Bagnulo 504 Gonzalo Camarillo 505 Stuart Cheshire 506 Russ Housley 507 John Klensin 508 Olaf Kolkman 509 Gregory Lebovitz 510 Andrew Malis 511 Danny McPherson 512 David Oran 513 Jon Peterson 514 Dave Thaler