idnits 2.17.1 draft-ietf-iasa2-rfc6220bis-00.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 date (October 5, 2018) is 2001 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'NULL' is mentioned on line 489, but not defined -- 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 (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board(IAB) D. McPherson, Ed. 3 Internet-Draft O. Kolkman, Ed. 4 Intended status: Informational ISOC 5 Expires: April 8, 2019 J. Klensin, Ed. 7 G. Huston, Ed. 8 APNIC 9 IAB 10 October 5, 2018 12 Defining the Role and Function of IETF Protocol Parameter Registry 13 Operators 14 draft-ietf-iasa2-rfc6220bis-00 16 Abstract 18 Many Internet Engineering Task Force (IETF) protocols make use of 19 commonly defined values that are passed in messages or packets. To 20 ensure consistent interpretation of these values between independent 21 implementations, there is a need to ensure that the values and 22 associated semantic intent are uniquely defined. The IETF uses 23 registry functions to record assigned protocol parameter values and 24 their associated semantic intentions. For each IETF protocol 25 parameter, it is current practice for the IETF to delegate the role 26 of Protocol Parameter Registry Operator to a nominated entity. This 27 document provides a description of, and the requirements for, these 28 delegated functions. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 8, 2019. 47 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Roles and Responsibilities Concerning IETF Protocol 65 Parameter Registries . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Protocol Parameter Registry Operator Role . . . . . . . . 4 67 2.2. IAB Role . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.3. IESG Role . . . . . . . . . . . . . . . . . . . . . . . . 8 69 2.4. Role of the IETF Trust . . . . . . . . . . . . . . . . . . 8 70 2.5. Role of the IAOC . . . . . . . . . . . . . . . . . . . . . 8 71 3. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 9 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 6. Informative References . . . . . . . . . . . . . . . . . . . . 9 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 76 Appendix B. IAB members . . . . . . . . . . . . . . . . . . . . . 11 77 Appendix C. Document Editing Details . . . . . . . . . . . . . . 11 78 C.1. Version Information . . . . . . . . . . . . . . . . . . . 11 79 C.1.1. draft-iab-iasa2-rfc6220-00 . . . . . . . . . . . . . . 11 80 C.1.2. TODO . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 C.2. RCS information . . . . . . . . . . . . . . . . . . . . . 11 83 1. Overview 85 Many IETF protocols make use of commonly defined values that are 86 passed within messages or packets. To ensure consistent 87 interpretation of these values between independent implementations, 88 there is a need to ensure that the values and associated semantic 89 intent are uniquely defined. The IETF uses registries to record each 90 of the possible values of a protocol parameter and their associated 91 semantic intent. These registries, their registration policy, and 92 the layout of their content are defined in the so-called "IANA 93 Considerations" sections of IETF documents. 95 The organizational separation between the IETF and its Registry 96 Operators parallels ones that are fairly common among standards 97 development organizations (SDOs) although less common among 98 technology consortia and similar bodies. These functions have been 99 separated into different organizations for several reasons. They 100 include dealing with administrative issues, addressing concerns about 101 maintaining an adequate distance between basic policy and specific 102 allocations, and avoiding any potential conflicts of interest that 103 might arise from commercial or organizational relationships. For 104 example, most ISO and ISO/IEC JTC1 standards that require 105 registration activities specify a Registration Authority (RA) or 106 Maintenance Agency (MA) that, in turn, control the actual 107 registration decisions. The databases of what is registered for each 108 standard may then be maintained by a secretariat or database function 109 associated with the RA or MA or, less frequently, by the secretariat 110 of the body that created and maintains the standard itself. 112 This structural separation of roles exists within several places in 113 the IETF framework (e.g., the RFC Editor function). The Internet 114 Architecture Board (IAB), on behalf of the IETF, has the 115 responsibility to define and manage the relationship with the 116 Protocol Registry Operator role. This responsibility includes the 117 selection and management of the Protocol Parameter Registry Operator, 118 as well as management of the parameter registration process and the 119 guidelines for parameter allocation. 121 As with other SDOs, although it may delegate authority for some 122 specific decisions, the IETF asserts authority and responsibility for 123 the management of all of its protocol parameters and their 124 registries, even while it generally remains isolated from the 125 selection of particular values once a registration is approved. This 126 document describes the function of these registries as they apply to 127 individual protocol parameters defined by the IETF Internet Standards 128 Process [RFC2026] to allow for an orderly implementation by the 129 Internet Administrative Oversight Committee (IAOC), and others as 130 needed, under guidance from the IAB. 132 Below we provide a description of the requirements for these 133 delegated functions, which the IETF traditionally refers to as the 134 Internet Assigned Numbers Authority (IANA) function. 136 2. Roles and Responsibilities Concerning IETF Protocol Parameter 137 Registries 139 The IETF's longstanding practice is to outsource the management and 140 implementation of some important functions (e.g., [RFC5620]). The 141 protocol parameter registry function falls into this category of 142 outsourced functions, and what follows here is the description of the 143 roles and responsibilities with respect to the registration of IETF 144 protocol parameters. 146 Specifically, this document describes the operation and role of a 147 delegated IETF Protocol Parameter Registry Operator, to be selected 148 and administered by the IETF Administrative Support Activity (IASA) 149 [RFC4071]. While there is generally a single Protocol Parameter 150 Registry Operator, additional Operators may be selected to implement 151 specific registries, and that has been done occasionally. Having a 152 single Operator facilitates coordination among registries, even those 153 that are not obviously related, and also makes it easier to have 154 consistency of formats and registry structure, which aids users of 155 the registries and assists with quality control. 157 Many protocols make use of identifiers consisting of constants and 158 other well-known values. Even after a protocol has been defined and 159 deployment has begun, new values may need to be assigned (e.g., for a 160 new option type in DHCP, or a new encryption or authentication 161 algorithm for IPsec). To ensure that such quantities have consistent 162 values and interpretations in different implementations, their 163 assignment must be administered by a central authority. For IETF 164 protocols, that role is provided by a delegated Protocol Parameter 165 Registry Operator. For any particular protocol parameter there is a 166 single delegated Registry Operator. 168 2.1. Protocol Parameter Registry Operator Role 170 The IETF Protocol Parameter Registry function is undertaken under the 171 auspices of the Internet Architecture Board. 173 The roles of the Protocol Parameter Registry Operator are as follows: 175 o Review and Advise 177 * A Registry Operator may be requested to review Internet-Drafts 178 that are being considered by the Internet Engineering Steering 179 Group (IESG), with the objective of offering advice to the IESG 180 regarding the contents of the "IANA Considerations" section, 181 whether such a section, when required, is clear in terms of 182 direction to the Registry Operator, and whether the section is 183 consistent with the current published Registry Operator 184 guidelines. 186 o Registry 188 * To operate a registry of protocol parameter assignments. 190 * The delegated Registry Operator registers values for Internet 191 protocol parameters only as directed by the criteria and 192 procedures specified in RFCs, including Proposed, Draft, and 193 full Internet Standards, Best Current Practice documents, and 194 other RFCs that require protocol parameter assignment. 196 If values for Internet protocol parameters were not specified, 197 or in case of ambiguity, the Registry Operator will continue to 198 assign and register only those protocol parameters that have 199 already been delegated to the Operator, following past and 200 current practice for such assignments, unless otherwise 201 directed in terms of operating practice by the IESG. In the 202 case of ambiguity, the Registry Operator is expected to 203 identify the ambiguity to the IAB or IESG as appropriate and 204 either suggest better text or ask the appropriate parties for 205 clarification. 207 * For each protocol parameter, the associated registry includes: 209 + a reference to the RFC document that describes the parameter 210 and the associated "IANA Considerations" concerning the 211 parameter, and 213 + for each registration of a protocol parameter value, the 214 source of the registration and the date of the registration, 215 if the date of registration is known, and 217 + any other information specified as being included in the 218 registration data in the RFC document that describes the 219 parameter. 221 + If in doubt or in case of a technical dispute, the Registry 222 Operator will seek and follow technical guidance exclusively 223 from the IESG. Where appropriate, the IESG will appoint an 224 expert to advise the Registry Operator. 226 * The Registry Operator will work with the IETF to develop any 227 missing criteria and procedures over time, which the Registry 228 Operator will adopt when so instructed by the IESG. 230 * Unless special circumstances apply to subsets of the data and 231 specific rules are established by IETF consensus, each protocol 232 parameter registry operates as a public registry, and the 233 contents of the registry are openly available to the public, 234 on-line and free of charge. 236 * The Registry Operator assigns protocol parameter values in 237 accordance with the policy associated with the protocol 238 parameter, such as "First Come First Served" or "Expert Review" 239 [RFC5226]. 241 o Mailing Lists 243 * The Registry Operator maintains public mailing lists as 244 specified in IANA Considerations [RFC5226]. Such lists are 245 designated for the purpose of review of assignment proposals in 246 conjunction with a designated expert review function. In 247 addition, each Protocol Parameter Registry Operator should 248 maintain a mailing list that enables the registry staff of the 249 Registry Operator to be contacted by email. 251 o Liaison Activity 253 * The Registry Operator will nominate a liaison point of contact. 254 The Registry Operator, through this liaison, may be requested 255 to provide advice to the IESG on IETF protocol parameters as 256 well as the "IANA Considerations" section of each Internet- 257 Draft that is being reviewed for publication as an RFC. Where 258 appropriate the IESG will appoint an expert to advise the 259 Registry Operator. 261 o Reporting 263 * The Registry Operator will submit periodic reports to the IAB 264 concerning the operational performance of the registry 265 function. As an example of the requirements for such reports, 266 the reader is referred to a supplement [IAOC_SUPP] to the 267 "Memorandum of Understanding Concerning the Technical Work of 268 the Internet Assigned Numbers Authority" [RFC2860] that 269 provides service level agreement (SLA) guidelines under which 270 ICANN, the current protocol parameter registry, must operate. 272 * At the request of the chair of the IETF, IAB, or IAOC, the 273 Registry Operator will undertake periodic reports to IETF 274 Plenary meetings concerning the status of the registry 275 function. 277 * The Registry Operator will publish an annual report describing 278 the status of the function and a summary of performance 279 indicators. 281 o Intellectual Property Rights and the Registry Operator 283 * All assigned values are to be published and made available free 284 of any charges. 286 * The assignment values may be redistributed without 287 modification. 289 * Any intellectual property rights of the IETF protocol parameter 290 assignment information, including the IETF protocol parameter 291 registry and its contents, are to be held by the IETF Trust 292 [RFC4748]. 294 2.2. IAB Role 296 An Operator of an IETF protocol parameter registry undertakes the 297 role as a delegated function under the authority of the IAB. 299 The IAB has the responsibility to review the current description of 300 the registry function from time to time and direct the Registry 301 Operator to adopt amendments relating to its role and mode of 302 operation according to the best interests of the IETF and the 303 Internet community in general. 305 The IAB has the responsibility to appoint an organization to 306 undertake the delegated functions of the Protocol Parameter Registry 307 Operator for each IETF protocol parameter. Specifically, the IAB 308 defines the role and requirements for the desired functions. The 309 IAOC is responsible for identifying a potential vendor, and once 310 under agreement, managing the various aspects of the relationships 311 with that vendor. To be clear, the IAB is in the deciding role 312 (e.g., for appointment and termination), but must work in close 313 consultation with the IAOC. 315 The IAB has the responsibility to determine the terms and conditions 316 of this delegated role. Such terms and conditions should ensure that 317 the registry operates in a manner that is fully conformant to the 318 functions described in this document. In addition, such terms and 319 conditions must not restrict the rights and interests of the IETF 320 with respect to the registry contents and maintenance. 322 2.3. IESG Role 324 The IESG is responsible for the technical direction regarding entries 325 into IETF protocol parameter registries and maintaining the policies 326 by which such technical directions are given. Technical direction 327 itself is provided through the adoption of directives within the 328 "IANA Considerations" section of IETF Stream RFCs or through stand- 329 alone "IANA Considerations" RFCs. 331 The IESG shall verify that Internet-Drafts that are offered for 332 publication as IETF Stream RFCs [RFC4844] include "IANA 333 Considerations" sections when needed, and that "IANA Considerations" 334 sections conform to the current published guidelines. 336 Since technical assessment is not generally a responsibility of the 337 Registry Operator, as part of providing the technical direction the 338 IESG is responsible for identifying the technical experts that are 339 required to, where appropriate, review registration requests or 340 resolve open technical questions that relate to the registration of 341 parameters. 343 At its discretion, the IESG will organize the liaison activities with 344 the Registry Operator's liaison point of contact so as to facilitate 345 clear communications and effective operation of the registry 346 function. 348 2.4. Role of the IETF Trust 350 The IETF Trust [RFC4748] was formed to act as the administrative 351 custodian of all copyrights and other intellectual property rights 352 relating to the IETF Standards Process, a function that had 353 previously been performed by the Internet Society (ISOC) and the 354 Corporation for National Research Initiatives (CNRI). 356 Any intellectual property rights of IETF protocol parameter 357 assignment information, including the registry and its contents, and 358 all registry publications, are to be held by the IETF Trust on behalf 359 of the IETF. 361 The IETF Trust may make such regulations as appropriate for the 362 redistribution of assignment values and registry publications. 364 2.5. Role of the IAOC 366 The IAOC is responsible for identifying a potential vendor in a 367 manner of their choosing, based on IAB consultation, and for managing 368 the various aspects of the relationships with that vendor. 370 In addition, the IAOC has the responsibility to ensure long-term 371 access, stability, and uniqueness across all such registries. This 372 responsibility is of particular significance in the event that a 373 relation with a Protocol Parameter Registry Operator is terminated. 375 3. Miscellaneous Considerations 377 While this document has focused on the creation of protocols by the 378 IETF, the requirements provided are generically applicable to the 379 extended IETF community as well (e.g., Internet Research Task Force 380 (IRTF)). 382 The IESG is responsible for the technical direction of the IETF 383 Protocol Parameter registries and maintaining the policies by which 384 such technical directions are given. The IESG is responsible, as 385 part of the document approval process associated with the IETF Stream 386 RFCs [RFC4844], for "IANA Considerations" verification. For the 387 other RFC streams, the approval bodies are responsible for verifying 388 that the documents include "IANA Considerations" sections when 389 needed, and that "IANA Considerations" sections conform to the 390 current published guidelines. In the case that IANA considerations 391 in non-IETF document streams lead to a dispute, the IAB makes the 392 final decision. 394 This document talks about "Registry Operator" (singular), and while 395 there are stability and economy-of-scale advantages for one single 396 Operator, this document does not exclude having different Operators 397 for different protocol registries when justified by the 398 circumstances. 400 4. Security Considerations 402 This document does not propose any new protocols and does not 403 introduce any new security considerations. 405 5. IANA Considerations 407 This document requires no direct IANA actions in terms of the 408 creation or operation of a protocol parameter registry. However, 409 this document does define the roles and responsibilities of various 410 bodies who are responsible for, and associated with, the operation of 411 protocol parameter registration functions for the IETF. 413 6. Informative References 415 [IAOC_SUPP] "ICANN/IANA-IETF MoU Supplemental Agreement,". 417 . 420 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 421 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 422 . 424 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 425 Understanding Concerning the Technical Work of the 426 Internet Assigned Numbers Authority", RFC 2860, 427 DOI 10.17487/RFC2860, June 2000, 428 . 430 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 431 IETF Administrative Support Activity (IASA)", BCP 101, 432 RFC 4071, DOI 10.17487/RFC4071, April 2005, 433 . 435 [RFC4748] Bradner, S., Ed., "RFC 3978 Update to Recognize the IETF 436 Trust", RFC 4748, DOI 10.17487/RFC4748, October 2006, 437 . 439 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The 440 RFC Series and RFC Editor", RFC 4844, DOI 10.17487/ 441 RFC4844, July 2007, 442 . 444 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 445 IANA Considerations Section in RFCs", RFC 5226, 446 DOI 10.17487/RFC5226, May 2008, 447 . 449 [RFC5620] Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 450 1)", RFC 5620, DOI 10.17487/RFC5620, August 2009, 451 . 453 Appendix A. Acknowledgements 455 This document is adapted from "Guidelines for Writing an IANA 456 Considerations Section in RFCs" [RFC5226], and has been modified to 457 include explicit reference to Intellectual Property Rights and the 458 roles of the IAB and IESG in relation to the IETF Protocol Parameter 459 Registry function. 461 The Internet Architecture Board acknowledges the assistance provided 462 by reviewers of drafts of this document, including Scott Bradner, 463 Brian Carpenter, Leslie Daigle, Adrian Farrel, Alfred Hoenes, Paul 464 Hoffman, Alexey Melnikov, Thomas Narten, and Ray Pelletier. 466 Appendix B. IAB members 468 Internet Architecture Board Members at the time this document was 469 approved for publication were: [TO BE PROVIDED] 471 Appendix C. Document Editing Details 473 [Text between square brackets starting with initials are editor 474 notes. Any other text between square brackets assumes an action by 475 the RFC editor prior to publication as an RFC. In most cases this 476 will be removal, sometimes a stylistic or editorial choices ore 477 question is indicated] [This section and its subsections should be 478 removed at publication as RFC] 480 C.1. Version Information 482 C.1.1. draft-iab-iasa2-rfc6220-00 484 Original RFC text backported into XML. With only Editor 485 affiliaton changed and IAB members section emptied 487 C.1.2. TODO 489 o [NULL] 491 C.2. RCS information 493 $Id: rfc6220bis.xml,v 1.2 2018/10/01 20:21:32 olaf Exp $ 495 Authors' Addresses 497 Danny McPherson (editor) 498 Verisign, Inc. 500 EMail: dmcpherson@verisign.com 502 Olaf Kolkman (editor) 503 Internet Society 505 EMail: kolkman@isoc.org 507 John C Klensin (editor) 509 EMail: john+ietf@jck.com 510 Geoff Huston (editor) 511 APNIC 513 EMail: gih@apnic.net 515 Internet Architecture Board 517 EMail: iab@iab.org