idnits 2.17.1 draft-ietf-iasa2-rfc6220bis-04.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 (18 October 2019) is 1652 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6410' is mentioned on line 141, but not defined == Missing Reference: 'RFC4371' is mentioned on line 370, but not defined ** Obsolete undefined reference: RFC 4371 (Obsoleted by RFC 8714) == Missing Reference: 'RFC2026' is mentioned on line 623, but not defined -- Obsolete informational reference (is this intentional?): RFC 4071 (ref. 'BCP101') (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 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 Obsoletes: 6220 (if approved) ISOC 5 Intended status: Informational J.C. Klensin, Ed. 6 Expires: 20 April 2020 G. Huston, Ed. 7 APNIC 8 - 9 Internet Architecture Board 10 18 October 2019 12 Defining the Role and Function of IETF Protocol Parameter Registry 13 Operators 14 draft-ietf-iasa2-rfc6220bis-04 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. This document obsoletes RFC 6220 to replace all 29 references to the IASA and related structures with those defined by 30 the IASA 2.0 Model. 32 [Cover Note] 34 [The IASA2 WG asks the IAB to publish this replacement for RFC 6220. 35 This document is changed for alignment with the new structure for the 36 IETF Administrative Support Activity (IASA). ] 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 20 April 2020. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Simplified BSD License text 66 as described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Roles and Responsibilities Concerning IETF Protocol 73 Parameter Registries . . . . . . . . . . . . . . . . . . 4 74 2.1. Protocol Parameter Registry Operator Role . . . . . . . . 4 75 2.2. IAB Role . . . . . . . . . . . . . . . . . . . . . . . . 7 76 2.3. IESG Role . . . . . . . . . . . . . . . . . . . . . . . . 8 77 2.4. Role of the IETF Trust . . . . . . . . . . . . . . . . . 8 78 2.5. Role of the IETF Administration Limited Liability 79 Company . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 3. Miscellaneous Considerations . . . . . . . . . . . . . . . . 9 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 6. Informative References . . . . . . . . . . . . . . . . . . . 10 84 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 85 Appendix B. IAB members . . . . . . . . . . . . . . . . . . . . 12 86 Appendix C. Document Editing Details . . . . . . . . . . . . . . 12 87 C.1. Version Information . . . . . . . . . . . . . . . . . . . 13 88 C.1.1. draft-iab-iasa2-rfc6220-00 . . . . . . . . . . . . . 13 89 C.1.2. draft-iab-iasa2-rfc6220-01 . . . . . . . . . . . . . 13 90 C.1.3. draft-iab-iasa2-rfc6220-02 . . . . . . . . . . . . . 13 91 C.1.4. draft-iab-iasa2-rfc6220-03 . . . . . . . . . . . . . 13 92 C.1.5. draft-iab-iasa2-rfc6220-04 . . . . . . . . . . . . . 14 93 C.2. RCS information . . . . . . . . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 96 1. Overview 98 Many IETF protocols make use of commonly defined values that are 99 passed within messages or packets. To ensure consistent 100 interpretation of these values between independent implementations, 101 there is a need to ensure that the values and associated semantic 102 intent are uniquely defined. The IETF uses registries to record each 103 of the possible values of a protocol parameter and their associated 104 semantic intent. These registries, their registration policy, and 105 the layout of their content are defined in the so-called "IANA 106 Considerations" sections of IETF documents. 108 The organizational separation between the IETF and its Registry 109 Operators parallels ones that are fairly common among standards 110 development organizations (SDOs) although less common among 111 technology consortia and similar bodies. These functions have been 112 separated into different organizations for several reasons. They 113 include dealing with administrative issues, addressing concerns about 114 maintaining an adequate distance between basic policy and specific 115 allocations, and avoiding any potential conflicts of interest that 116 might arise from commercial or organizational relationships. For 117 example, most ISO and ISO/IEC JTC1 standards that require 118 registration activities specify a Registration Authority (RA) or 119 Maintenance Agency (MA) that, in turn, control the actual 120 registration decisions. The databases of what is registered for each 121 standard may then be maintained by a secretariat or database function 122 associated with the RA or MA or, less frequently, by the secretariat 123 of the body that created and maintains the standard itself. 125 This structural separation of roles exists within several places in 126 the IETF framework (e.g., the RFC Editor function). The Internet 127 Architecture Board (IAB), on behalf of the IETF, has the 128 responsibility to define and manage the relationship with the 129 Protocol Registry Operator role. This responsibility includes the 130 selection and management of the Protocol Parameter Registry Operator, 131 as well as management of the parameter registration process and the 132 guidelines for parameter allocation. 134 As with other SDOs, although it may delegate authority for some 135 specific decisions, the IETF asserts authority and responsibility for 136 the management of all of its protocol parameters and their 137 registries, even while it generally remains isolated from the 138 selection of particular values once a registration is approved. This 139 document describes the function of these registries as they apply to 140 individual protocol parameters defined by the IETF Internet Standards 141 Process [RFC6410] to allow for an orderly implementation by the IETF 142 Administration Limited Liability Company (IETF LLC), and others as 143 needed, under guidance from the IAB. This document obsoletes RFC 144 6220 to replace all references to the IASA and related structures 145 with those defined by the IASA 2.0 Model [I-D.ietf-iasa2-rfc4071bis]. 147 Below we provide a description of the requirements for these 148 delegated functions, which the IETF traditionally refers to as the 149 Internet Assigned Numbers Authority (IANA) function. 151 2. Roles and Responsibilities Concerning IETF Protocol Parameter 152 Registries 154 The IETF's longstanding practice is to outsource the management and 155 implementation of some important functions (e.g., 156 [I-D.ietf-iasa2-rfc6635bis]). The protocol parameter registry 157 function falls into this category of outsourced functions, and what 158 follows here is the description of the roles and responsibilities 159 with respect to the registration of IETF protocol parameters. 161 Specifically, this document describes the operation and role of a 162 delegated IETF Protocol Parameter Registry Operator, to be selected 163 and administered by the IETF Administrative Support Activity (IASA) 164 [I-D.ietf-iasa2-rfc4071bis]. While there is generally a single 165 Protocol Parameter Registry Operator, additional Operators may be 166 selected to implement specific registries, and that has been done 167 occasionally. Having a single Operator facilitates coordination 168 among registries, even those that are not obviously related, and also 169 makes it easier to have consistency of formats and registry 170 structure, which aids users of the registries and assists with 171 quality control. 173 Many protocols make use of identifiers consisting of constants and 174 other well-known values. Even after a protocol has been defined and 175 deployment has begun, new values may need to be assigned (e.g., for a 176 new option type in DHCP, or a new encryption or authentication 177 algorithm for IPsec). To ensure that such quantities have consistent 178 values and interpretations in different implementations, their 179 assignment must be administered by a central authority. For IETF 180 protocols, that role is provided by a delegated Protocol Parameter 181 Registry Operator. For any particular protocol parameter there is a 182 single delegated Registry Operator. 184 2.1. Protocol Parameter Registry Operator Role 186 The IETF Protocol Parameter Registry function is undertaken under the 187 auspices of the Internet Architecture Board. 189 The roles of the Protocol Parameter Registry Operator are as follows: 191 * Review and Advise 192 - A Registry Operator may be requested to review Internet-Drafts 193 that are being considered by the Internet Engineering Steering 194 Group (IESG), with the objective of offering advice to the IESG 195 regarding the contents of the "IANA Considerations" section, 196 whether such a section, when required, is clear in terms of 197 direction to the Registry Operator, and whether the section is 198 consistent with the current published Registry Operator 199 guidelines. 201 * Registry 203 - To operate a registry of protocol parameter assignments. 205 - The delegated Registry Operator registers values for Internet 206 protocol parameters only as directed by the criteria and 207 procedures specified in RFCs, including Standard Track 208 Documents [BCP9], Best Current Practice documents, and other 209 RFCs that require protocol parameter assignment. 211 If values for Internet protocol parameters were not specified, 212 or in case of ambiguity, the Registry Operator will continue to 213 assign and register only those protocol parameters that have 214 already been delegated to the Operator, following past and 215 current practice for such assignments, unless otherwise 216 directed in terms of operating practice by the IESG. In the 217 case of ambiguity, the Registry Operator is expected to 218 identify the ambiguity to the IAB or IESG as appropriate and 219 either suggest better text or ask the appropriate parties for 220 clarification. 222 - For each protocol parameter, the associated registry includes: 224 o a reference to the RFC document that describes the parameter 225 and the associated "IANA Considerations" concerning the 226 parameter, and 228 o for each registration of a protocol parameter value, the 229 source of the registration and the date of the registration, 230 if the date of registration is known, and 232 o any other information specified as being included in the 233 registration data in the RFC document that describes the 234 parameter. 236 o If in doubt or in case of a technical dispute, the Registry 237 Operator will seek and follow technical guidance exclusively 238 from the IESG. Where appropriate, the IESG will appoint an 239 expert to advise the Registry Operator. 241 - The Registry Operator will work with the IETF to develop any 242 missing criteria and procedures over time, which the Registry 243 Operator will adopt when so instructed by the IESG. 245 - Unless special circumstances apply to subsets of the data and 246 specific rules are established by IETF consensus, each protocol 247 parameter registry operates as a public registry, and the 248 contents of the registry are openly available to the public, 249 on-line and free of charge. 251 - The Registry Operator assigns protocol parameter values in 252 accordance with the policy associated with the protocol 253 parameter, such as "First Come First Served" or "Expert Review" 254 [RFC8126]. 256 * Mailing Lists 258 - The Registry Operator maintains public mailing lists as 259 specified in IANA Considerations [RFC8126]. Such lists are 260 designated for the purpose of review of assignment proposals in 261 conjunction with a designated expert review function. In 262 addition, each Protocol Parameter Registry Operator should 263 maintain a mailing list that enables the registry staff of the 264 Registry Operator to be contacted by email. 266 * Liaison Activity 268 - The Registry Operator will nominate a liaison point of contact. 269 The Registry Operator, through this liaison, may be requested 270 to provide advice to the IESG on IETF protocol parameters as 271 well as the "IANA Considerations" section of each Internet- 272 Draft that is being reviewed for publication as an RFC. Where 273 appropriate the IESG will appoint an expert to advise the 274 Registry Operator. 276 * Reporting 278 - The Registry Operator will submit periodic reports to the IAB 279 concerning the operational performance of the registry 280 function. As an example of the requirements for such reports, 281 the reader is referred to a supplement [MoU_SUPP2019] to the 282 "Memorandum of Understanding Concerning the Technical Work of 283 the Internet Assigned Numbers Authority" [RFC2860] that 284 provides service level agreement (SLA) guidelines under which 285 ICANN, the current protocol parameter registry, must operate. 287 - At the request of the chair of the IETF or IAB, or the IETF 288 Executive Director [I-D.ietf-iasa2-rfc4071bis], the Registry 289 Operator will undertake periodic reports to IETF Plenary 290 meetings, or elsewhere as they may direct, concerning the 291 status of the registry function. 293 - The Registry Operator will publish an annual report describing 294 the status of the function and a summary of performance 295 indicators. 297 * Intellectual Property Rights and the Registry Operator 299 Unless special circumstances apply (see above): 301 - All assigned values are to be published and made available free 302 of any charges. 304 - The assignment values may be redistributed without 305 modification. 307 In any case, 309 - any intellectual property rights of the IETF protocol parameter 310 assignment information, including the IETF protocol parameter 311 registry and its contents, are to be held by the IETF Trust 312 [BCP101]. 314 2.2. IAB Role 316 An Operator of an IETF protocol parameter registry undertakes the 317 role as a delegated function under the authority of the IAB. 319 The IAB has the responsibility to review the current description of 320 the registry function from time to time and direct the Registry 321 Operator to adopt amendments relating to its role and mode of 322 operation according to the best interests of the IETF and the 323 Internet community in general. 325 The IAB has the responsibility to appoint an organization to 326 undertake the delegated functions of the Protocol Parameter Registry 327 Operator for each IETF protocol parameter. Specifically, the IAB 328 defines the role and requirements for the desired functions. The 329 IETF LLC is responsible for identifying a potential vendor, and once 330 under agreement, managing the various aspects of the relationships 331 with that vendor. To be clear, the IAB is in the deciding role 332 (e.g., for appointment and termination), but must work in close 333 consultation with the IETF LLC. 335 The IAB has the responsibility to determine the terms and conditions 336 of this delegated role. Such terms and conditions should ensure that 337 the registry operates in a manner that is fully conformant to the 338 functions described in this document. In addition, such terms and 339 conditions must not restrict the rights and interests of the IETF 340 with respect to the registry contents and maintenance. 342 2.3. IESG Role 344 The IESG is responsible for the technical direction regarding entries 345 into IETF protocol parameter registries and maintaining the policies 346 by which such technical directions are given. Technical direction 347 itself is provided through the adoption of directives within the 348 "IANA Considerations" section of IETF Stream RFCs or through stand- 349 alone "IANA Considerations" RFCs. 351 The IESG shall verify that Internet-Drafts that are offered for 352 publication as IETF Stream RFCs [RFC4844] include "IANA 353 Considerations" sections when needed, and that "IANA Considerations" 354 sections conform to the current published guidelines. 356 Since technical assessment is not generally a responsibility of the 357 Registry Operator, as part of providing the technical direction the 358 IESG is responsible for identifying the technical experts that are 359 required to, where appropriate, review registration requests or 360 resolve open technical questions that relate to the registration of 361 parameters. 363 At its discretion, the IESG will organize the liaison activities with 364 the Registry Operator's liaison point of contact so as to facilitate 365 clear communications and effective operation of the registry 366 function. 368 2.4. Role of the IETF Trust 370 The IETF Trust [RFC4371] was formed to act as the administrative 371 custodian of all copyrights and other intellectual property rights 372 relating to the IETF Standards Process, a function that had 373 previously been performed by the Internet Society (ISOC) and the 374 Corporation for National Research Initiatives (CNRI). 376 Any intellectual property rights of IETF protocol parameter 377 assignment information, including the registry and its contents, and 378 all registry publications, are to be held by the IETF Trust on behalf 379 of the IETF. 381 The IETF Trust may make such regulations as appropriate for the 382 redistribution of assignment values and registry publications. 384 2.5. Role of the IETF Administration Limited Liability Company 386 The IETF Administration Limited Liability Company (IETF LLC) 387 [I-D.ietf-iasa2-rfc4071bis] is responsible for identifying a 388 potential vendor in a manner of its choosing, based on IAB 389 consultation, and for managing the various aspects of the 390 relationships with that vendor. 392 In addition, the IETF LLC has the responsibility to ensure long-term 393 access, stability, and uniqueness across all such registries. This 394 responsibility is of particular significance in the event that a 395 relation with a Protocol Parameter Registry Operator is terminated. 397 3. Miscellaneous Considerations 399 While this document has focused on the creation of protocols by the 400 IETF, the requirements provided are generically applicable to the 401 extended IETF community as well (e.g., Internet Research Task Force 402 (IRTF)). 404 The IESG is responsible for the technical direction of the IETF 405 Protocol Parameter registries and maintaining the policies by which 406 such technical directions are given. The IESG is responsible, as 407 part of the document approval process associated with the IETF Stream 408 RFCs [RFC4844], for "IANA Considerations" verification. For the 409 other RFC streams, the approval bodies are responsible for verifying 410 that the documents include "IANA Considerations" sections when 411 needed, and that "IANA Considerations" sections conform to the 412 current published guidelines. In the case that IANA considerations 413 in non-IETF document streams lead to a dispute, the IAB makes the 414 final decision. 416 This document talks about "Registry Operator" (singular), and while 417 there are stability and economy-of-scale advantages for one single 418 Operator, this document does not exclude having different Operators 419 for different protocol registries when justified by the 420 circumstances. 422 4. Security Considerations 424 This document does not propose any new protocols and does not 425 introduce any new security considerations. 427 5. IANA Considerations 429 This document requires no direct IANA actions in terms of the 430 creation or operation of a protocol parameter registry. However, 431 this document does define the roles and responsibilities of various 432 bodies who are responsible for, and associated with, the operation of 433 protocol parameter registration functions for the IETF. 435 6. Informative References 437 [BCP101] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 438 IETF Administrative Support Activity (IASA)", BCP 101, 439 RFC 4071, April 2005. 441 Carpenter, B., Ed. and L. Lynch, Ed., "BCP 101 Update for 442 IPR Trust", BCP 101, RFC 4371, January 2006. 444 [BCP9] Bradner, S., "The Internet Standards Process -- Revision 445 3", BCP 9, RFC 2026, October 1996. 447 Dusseault, L. and R. Sparks, "Guidance on Interoperation 448 and Implementation Reports for Advancement to Draft 449 Standard", BCP 9, RFC 5657, September 2009. 451 Housley, R., Crocker, D., and E. Burger, "Reducing the 452 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 453 October 2011. 455 Resnick, P., "Retirement of the "Internet Official 456 Protocol Standards" Summary Document", BCP 9, RFC 7100, 457 December 2013. 459 Kolkman, O., Bradner, S., and S. Turner, "Characterization 460 of Proposed Standards", BCP 9, RFC 7127, January 2014. 462 Dawkins, S., "Increasing the Number of Area Directors in 463 an IETF Area", BCP 9, RFC 7475, March 2015. 465 [I-D.ietf-iasa2-rfc4071bis] 466 Haberman, B., Hall, J., and J. Livingood, "Structure of 467 the IETF Administrative Support Activity, Version 2.0", 468 Work in Progress, Internet-Draft, draft-ietf-iasa2- 469 rfc4071bis-11, 12 April 2019, 470 . 473 [I-D.ietf-iasa2-rfc6635bis] 474 Kolkman, O., Halpern, J., and R. Hinden, "RFC Editor Model 475 (Version 2)", Work in Progress, Internet-Draft, draft- 476 ietf-iasa2-rfc6635bis-04, 4 October 2019, 477 . 480 [MoU_SUPP2019] 481 "ICANN/IANA-IETF MoU Supplemental Agreement, 2019", 482 October 2019. 483 https://www.ietf.org/media/documents/FINAL_2019-IETF_MoU_S 484 upplemental_Agreement_Signed_31July19.pdf. 486 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 487 Understanding Concerning the Technical Work of the 488 Internet Assigned Numbers Authority", RFC 2860, 489 DOI 10.17487/RFC2860, June 2000, 490 . 492 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 493 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 494 July 2007, . 496 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 497 IANA Considerations Section in RFCs", RFC 5226, 498 DOI 10.17487/RFC5226, May 2008, 499 . 501 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 502 Writing an IANA Considerations Section in RFCs", BCP 26, 503 RFC 8126, DOI 10.17487/RFC8126, June 2017, 504 . 506 Appendix A. Acknowledgements 508 This document was originally adapted from "Guidelines for Writing an 509 IANA Considerations Section in RFCs" [RFC5226], and has been modified 510 to include explicit reference to Intellectual Property Rights and the 511 roles of the IAB and IESG in relation to the IETF Protocol Parameter 512 Registry function. 514 The document was updated under auspicies of the IASA2.0 working group 515 to reflect the reorganization of IETF Administrative Support 516 Activity. 518 The Internet Architecture Board acknowledges the assistance provided 519 by reviewers of drafts of this document, including Scott Bradner, 520 Brian Carpenter, Leslie Daigle, Adrian Farrel, Bob Hinden, Alfred 521 Hoenes, Paul Hoffman, Benjamin Kaduk, Alexey Melnikov, Thomas Narten, 522 and Ray Pelletier. 524 Appendix B. IAB members 526 Internet Architecture Board Members at the time this document was 527 approved for publication were [To Be Confirmed]: 529 Jari Arkko, 530 Alissa Cooper, 531 Stephen Farrell 532 Wes Hardaker 533 Ted Hardie, 534 Christian Huitema, 535 Zhenbin Li 536 Erik Nordmark, 537 Mark Nottingham, 538 Jeff Tantsura, 539 Martin Thomson, 540 Brian Trammell, and 542 Appendix C. Document Editing Details 544 [Text between square brackets starting with initials are editor 545 notes. Any other text between square brackets assumes an action by 546 the RFC editor prior to publication as an RFC. In most cases this 547 will be removal, sometimes a stylistic or editorial choices ore 548 question is indicated] 550 [This section and its subsections should be removed at publication as 551 RFC, so should the Cover Note] 553 Some notes for the RFC Editor. 555 * There are a few places where I've added a reference to 556 [I-D.ietf-iasa2-rfc4071bis] mainly in places where I am not sure 557 if we should assume prior knowledge from the reader. E.g. whether 558 the Executive Director can be presumed to be a known term in the 559 context of this document. Guidance is accepted. 561 Editorial Issue: By using a referencegroup for BCP9 and BCP101 I 562 seem to have lost to refer to specific RFCs within the reference 563 group i.e. I have references to RFC6410 and RFC4371 specifically 564 that I can't resolve because these are inside a reference group. 565 I would like to retain the specific reference in the places where 566 I use the RFC reference and the generic reference where I use the 567 BCP reference. I presume the RFC editor can and will resolve 568 this. 570 There is a remaining '-' in order to get the organizational name 571 (Internet Architecture Board) printed without any attributes in 572 the author tag. 574 C.1. Version Information 576 C.1.1. draft-iab-iasa2-rfc6220-00 578 Original RFC text back ported into XML. With only Editor 579 affiliation changed and IAB members section emptied 581 C.1.2. draft-iab-iasa2-rfc6220-01 583 * Changed references to IAOC to LLC 584 * While reviewing the section on the Trust: Modified reference to 585 RFC 4748 to reference to RFC4371, as that document establishes the 586 Trust while 4748 is technically an update of RFC 3978 (now 587 obsoleted). 588 * Updated reference to ICANN-IETF MoU to most recent version (2018) 589 [MoU_SUPP2019] . 591 C.1.3. draft-iab-iasa2-rfc6220-02 593 * Standardized on "IETF LLC" as the sort version for the entity (per 594 RFC style guide). 595 * Changed "At the request of the chair of the IETF, IAB, or LLC," to 596 "At the request of the chair of the IETF or IAB, or the IETF 597 Executive Director", in the same paragraph: The reporting of the 598 registry operator does not necessarily need to take place in IETF 599 Plenary, it may happen elsewhere. Text changed to reflect as 600 much. 601 * BCP101 is a better reference than exclusively referring to 602 RFC4371. The way the reference is provided needs RFC Editor 603 attention. 604 * IDnits complained about rfc5226 being obsoleted. One of the 605 rfc5226 references is used for historical context in the 606 acknowledgement section, in other places it was replaced by 8126. 607 * IDnits complained about rfc5620 being obsoleted. The reference to 608 5620 is replaced by rfc6635bis-rfc editor model (not including 609 rfc6548bis-independent rfc editor, as it just serves as an example 610 and does not intend to describe the full RFC Editor universe). 611 * Updated the Acknowledgement section 613 C.1.4. draft-iab-iasa2-rfc6220-03 615 * Changed reference for IASA2 structure to 616 [I-D.ietf-iasa2-rfc4071bis] 618 C.1.5. draft-iab-iasa2-rfc6220-04 620 * Migrated source from XML2RFC v2 to v3, which caused some changes 621 in layout. 622 * Added obsoletion of 6220 sentence to Abstract and Introduction. 623 * Changed reference in introduction from [RFC2026] to [BCP9], 624 cleaned up the reference to [BCP101] 625 * In Section 2.1 changed: "Proposed, Draft, and full Internet 626 Standards" to "Standard Track Documents [RFC6410]" 627 * upgraded reference to ICANN MOU to the 2019 version 628 [MoU_SUPP2019]. 629 * In the paragraphs on IPR, just before Section 2.2, I clarifed that 630 there may be circumstances where the vallues are not public. This 631 to make the text consistent. 632 * Updated IAB membership. 634 C.2. RCS information 636 $Id: rfc6220bis.xml,v 1.10 2019/10/18 13:29:40 olaf Exp $ 638 Authors' Addresses 640 Danny McPherson (editor) 641 Verisign, Inc. 643 Email: dmcpherson@verisign.com 645 Olaf Kolkman (editor) 646 Inter 647 net Society 649 Email: kolkman@isoc.org 651 John C Klensin (editor) 653 Email: john+ietf@jck.com 655 Geoff Huston (editor) 656 APNIC 658 Email: gih@apnic.net 660 Internet Architecture Board 661 Email: iab@iab.org