idnits 2.17.1 draft-ietf-iasa2-rfc6220bis-03.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC6220, but the abstract doesn't seem to directly say this. It does mention RFC6220 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 10, 2018) is 1963 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-iasa2-rfc4071bis-00 == Outdated reference: A later version (-04) exists of draft-ietf-iasa2-rfc6635bis-01 -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 4371 (Obsoleted by RFC 8714) -- 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: 0 errors (**), 0 flaws (~~), 3 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 Obsoletes: 6220 (if approved) ISOC 5 Intended status: Informational J. Klensin, Ed. 6 Expires: June 13, 2019 7 G. Huston, Ed. 8 APNIC 9 IAB 10 December 10, 2018 12 Defining the Role and Function of IETF Protocol Parameter Registry 13 Operators 14 draft-ietf-iasa2-rfc6220bis-03 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 [Cover Note] 32 [The IASA2 WG asks the IAB to publish this replacement for RFC 6220. 33 This document is changed for alignment with the new structure for the 34 IETF Administrative Support Activity (IASA). ] 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on June 13, 2019. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Roles and Responsibilities Concerning IETF Protocol Parameter 72 Registries . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. Protocol Parameter Registry Operator Role . . . . . . . . 4 74 2.2. IAB Role . . . . . . . . . . . . . . . . . . . . . . . . 7 75 2.3. IESG Role . . . . . . . . . . . . . . . . . . . . . . . . 8 76 2.4. Role of the IETF Trust . . . . . . . . . . . . . . . . . 8 77 2.5. Role of the IETF Administration Limited Liability 78 Company . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 3. Miscellaneous Considerations . . . . . . . . . . . . . . . . 9 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 6. Informative References . . . . . . . . . . . . . . . . . . . 10 83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 84 Appendix B. IAB members . . . . . . . . . . . . . . . . . . . . 11 85 Appendix C. Document Editing Details . . . . . . . . . . . . . . 11 86 C.1. Version Information . . . . . . . . . . . . . . . . . . . 12 87 C.1.1. draft-iab-iasa2-rfc6220-00 . . . . . . . . . . . . . 12 88 C.1.2. draft-iab-iasa2-rfc6220-01 . . . . . . . . . . . . . 12 89 C.1.3. draft-iab-iasa2-rfc6220-02 . . . . . . . . . . . . . 12 90 C.1.4. draft-iab-iasa2-rfc6220-03 . . . . . . . . . . . . . 12 91 C.2. RCS information . . . . . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 94 1. Overview 96 Many IETF protocols make use of commonly defined values that are 97 passed within messages or packets. To ensure consistent 98 interpretation of these values between independent implementations, 99 there is a need to ensure that the values and associated semantic 100 intent are uniquely defined. The IETF uses registries to record each 101 of the possible values of a protocol parameter and their associated 102 semantic intent. These registries, their registration policy, and 103 the layout of their content are defined in the so-called "IANA 104 Considerations" sections of IETF documents. 106 The organizational separation between the IETF and its Registry 107 Operators parallels ones that are fairly common among standards 108 development organizations (SDOs) although less common among 109 technology consortia and similar bodies. These functions have been 110 separated into different organizations for several reasons. They 111 include dealing with administrative issues, addressing concerns about 112 maintaining an adequate distance between basic policy and specific 113 allocations, and avoiding any potential conflicts of interest that 114 might arise from commercial or organizational relationships. For 115 example, most ISO and ISO/IEC JTC1 standards that require 116 registration activities specify a Registration Authority (RA) or 117 Maintenance Agency (MA) that, in turn, control the actual 118 registration decisions. The databases of what is registered for each 119 standard may then be maintained by a secretariat or database function 120 associated with the RA or MA or, less frequently, by the secretariat 121 of the body that created and maintains the standard itself. 123 This structural separation of roles exists within several places in 124 the IETF framework (e.g., the RFC Editor function). The Internet 125 Architecture Board (IAB), on behalf of the IETF, has the 126 responsibility to define and manage the relationship with the 127 Protocol Registry Operator role. This responsibility includes the 128 selection and management of the Protocol Parameter Registry Operator, 129 as well as management of the parameter registration process and the 130 guidelines for parameter allocation. 132 As with other SDOs, although it may delegate authority for some 133 specific decisions, the IETF asserts authority and responsibility for 134 the management of all of its protocol parameters and their 135 registries, even while it generally remains isolated from the 136 selection of particular values once a registration is approved. This 137 document describes the function of these registries as they apply to 138 individual protocol parameters defined by the IETF Internet Standards 139 Process [RFC2026] to allow for an orderly implementation by the IETF 140 Administration Limited Liability Company (IETF LLC), and others as 141 needed, under guidance from the IAB. 143 Below we provide a description of the requirements for these 144 delegated functions, which the IETF traditionally refers to as the 145 Internet Assigned Numbers Authority (IANA) function. 147 2. Roles and Responsibilities Concerning IETF Protocol Parameter 148 Registries 150 The IETF's longstanding practice is to outsource the management and 151 implementation of some important functions (e.g., 152 [I-D.ietf-iasa2-rfc6635bis]). The protocol parameter registry 153 function falls into this category of outsourced functions, and what 154 follows here is the description of the roles and responsibilities 155 with respect to the registration of IETF protocol parameters. 157 Specifically, this document describes the operation and role of a 158 delegated IETF Protocol Parameter Registry Operator, to be selected 159 and administered by the IETF Administrative Support Activity (IASA) 160 [I-D.ietf-iasa2-rfc4071bis]. While there is generally a single 161 Protocol Parameter Registry Operator, additional Operators may be 162 selected to implement specific registries, and that has been done 163 occasionally. Having a single Operator facilitates coordination 164 among registries, even those that are not obviously related, and also 165 makes it easier to have consistency of formats and registry 166 structure, which aids users of the registries and assists with 167 quality control. 169 Many protocols make use of identifiers consisting of constants and 170 other well-known values. Even after a protocol has been defined and 171 deployment has begun, new values may need to be assigned (e.g., for a 172 new option type in DHCP, or a new encryption or authentication 173 algorithm for IPsec). To ensure that such quantities have consistent 174 values and interpretations in different implementations, their 175 assignment must be administered by a central authority. For IETF 176 protocols, that role is provided by a delegated Protocol Parameter 177 Registry Operator. For any particular protocol parameter there is a 178 single delegated Registry Operator. 180 2.1. Protocol Parameter Registry Operator Role 182 The IETF Protocol Parameter Registry function is undertaken under the 183 auspices of the Internet Architecture Board. 185 The roles of the Protocol Parameter Registry Operator are as follows: 187 o Review and Advise 189 * A Registry Operator may be requested to review Internet-Drafts 190 that are being considered by the Internet Engineering Steering 191 Group (IESG), with the objective of offering advice to the IESG 192 regarding the contents of the "IANA Considerations" section, 193 whether such a section, when required, is clear in terms of 194 direction to the Registry Operator, and whether the section is 195 consistent with the current published Registry Operator 196 guidelines. 198 o Registry 200 * To operate a registry of protocol parameter assignments. 202 * The delegated Registry Operator registers values for Internet 203 protocol parameters only as directed by the criteria and 204 procedures specified in RFCs, including Proposed, Draft, and 205 full Internet Standards, Best Current Practice documents, and 206 other RFCs that require protocol parameter assignment. 208 If values for Internet protocol parameters were not specified, 209 or in case of ambiguity, the Registry Operator will continue to 210 assign and register only those protocol parameters that have 211 already been delegated to the Operator, following past and 212 current practice for such assignments, unless otherwise 213 directed in terms of operating practice by the IESG. In the 214 case of ambiguity, the Registry Operator is expected to 215 identify the ambiguity to the IAB or IESG as appropriate and 216 either suggest better text or ask the appropriate parties for 217 clarification. 219 * For each protocol parameter, the associated registry includes: 221 + a reference to the RFC document that describes the parameter 222 and the associated "IANA Considerations" concerning the 223 parameter, and 225 + for each registration of a protocol parameter value, the 226 source of the registration and the date of the registration, 227 if the date of registration is known, and 229 + any other information specified as being included in the 230 registration data in the RFC document that describes the 231 parameter. 233 + If in doubt or in case of a technical dispute, the Registry 234 Operator will seek and follow technical guidance exclusively 235 from the IESG. Where appropriate, the IESG will appoint an 236 expert to advise the Registry Operator. 238 * The Registry Operator will work with the IETF to develop any 239 missing criteria and procedures over time, which the Registry 240 Operator will adopt when so instructed by the IESG. 242 * Unless special circumstances apply to subsets of the data and 243 specific rules are established by IETF consensus, each protocol 244 parameter registry operates as a public registry, and the 245 contents of the registry are openly available to the public, 246 on-line and free of charge. 248 * The Registry Operator assigns protocol parameter values in 249 accordance with the policy associated with the protocol 250 parameter, such as "First Come First Served" or "Expert Review" 251 [RFC8126]. 253 o Mailing Lists 255 * The Registry Operator maintains public mailing lists as 256 specified in IANA Considerations [RFC8126]. Such lists are 257 designated for the purpose of review of assignment proposals in 258 conjunction with a designated expert review function. In 259 addition, each Protocol Parameter Registry Operator should 260 maintain a mailing list that enables the registry staff of the 261 Registry Operator to be contacted by email. 263 o Liaison Activity 265 * The Registry Operator will nominate a liaison point of contact. 266 The Registry Operator, through this liaison, may be requested 267 to provide advice to the IESG on IETF protocol parameters as 268 well as the "IANA Considerations" section of each Internet- 269 Draft that is being reviewed for publication as an RFC. Where 270 appropriate the IESG will appoint an expert to advise the 271 Registry Operator. 273 o Reporting 275 * The Registry Operator will submit periodic reports to the IAB 276 concerning the operational performance of the registry 277 function. As an example of the requirements for such reports, 278 the reader is referred to a supplement [MoU_SUPP2018] to the 279 "Memorandum of Understanding Concerning the Technical Work of 280 the Internet Assigned Numbers Authority" [RFC2860] that 281 provides service level agreement (SLA) guidelines under which 282 ICANN, the current protocol parameter registry, must operate. 284 * At the request of the chair of the IETF or IAB, or the IETF 285 Executive Director [I-D.ietf-iasa2-rfc4071bis], the Registry 286 Operator will undertake periodic reports to IETF Plenary 287 meetings, or elsewhere as they may direct, concerning the 288 status of the registry function. 290 * The Registry Operator will publish an annual report describing 291 the status of the function and a summary of performance 292 indicators. 294 o Intellectual Property Rights and the Registry Operator 296 * All assigned values are to be published and made available free 297 of any charges. 299 * The assignment values may be redistributed without 300 modification. 302 * Any intellectual property rights of the IETF protocol parameter 303 assignment information, including the IETF protocol parameter 304 registry and its contents, are to be held by the IETF Trust 305 (BCP 101, currently [RFC4071] [RFC4371]). 307 2.2. IAB Role 309 An Operator of an IETF protocol parameter registry undertakes the 310 role as a delegated function under the authority of the IAB. 312 The IAB has the responsibility to review the current description of 313 the registry function from time to time and direct the Registry 314 Operator to adopt amendments relating to its role and mode of 315 operation according to the best interests of the IETF and the 316 Internet community in general. 318 The IAB has the responsibility to appoint an organization to 319 undertake the delegated functions of the Protocol Parameter Registry 320 Operator for each IETF protocol parameter. Specifically, the IAB 321 defines the role and requirements for the desired functions. The 322 IETF LLC is responsible for identifying a potential vendor, and once 323 under agreement, managing the various aspects of the relationships 324 with that vendor. To be clear, the IAB is in the deciding role 325 (e.g., for appointment and termination), but must work in close 326 consultation with the IETF LLC. 328 The IAB has the responsibility to determine the terms and conditions 329 of this delegated role. Such terms and conditions should ensure that 330 the registry operates in a manner that is fully conformant to the 331 functions described in this document. In addition, such terms and 332 conditions must not restrict the rights and interests of the IETF 333 with respect to the registry contents and maintenance. 335 2.3. IESG Role 337 The IESG is responsible for the technical direction regarding entries 338 into IETF protocol parameter registries and maintaining the policies 339 by which such technical directions are given. Technical direction 340 itself is provided through the adoption of directives within the 341 "IANA Considerations" section of IETF Stream RFCs or through stand- 342 alone "IANA Considerations" RFCs. 344 The IESG shall verify that Internet-Drafts that are offered for 345 publication as IETF Stream RFCs [RFC4844] include "IANA 346 Considerations" sections when needed, and that "IANA Considerations" 347 sections conform to the current published guidelines. 349 Since technical assessment is not generally a responsibility of the 350 Registry Operator, as part of providing the technical direction the 351 IESG is responsible for identifying the technical experts that are 352 required to, where appropriate, review registration requests or 353 resolve open technical questions that relate to the registration of 354 parameters. 356 At its discretion, the IESG will organize the liaison activities with 357 the Registry Operator's liaison point of contact so as to facilitate 358 clear communications and effective operation of the registry 359 function. 361 2.4. Role of the IETF Trust 363 The IETF Trust [RFC4371] was formed to act as the administrative 364 custodian of all copyrights and other intellectual property rights 365 relating to the IETF Standards Process, a function that had 366 previously been performed by the Internet Society (ISOC) and the 367 Corporation for National Research Initiatives (CNRI). 369 Any intellectual property rights of IETF protocol parameter 370 assignment information, including the registry and its contents, and 371 all registry publications, are to be held by the IETF Trust on behalf 372 of the IETF. 374 The IETF Trust may make such regulations as appropriate for the 375 redistribution of assignment values and registry publications. 377 2.5. Role of the IETF Administration Limited Liability Company 379 The IETF Administration Limited Liability Company (IETF LLC) 380 [I-D.ietf-iasa2-rfc4071bis] is responsible for identifying a 381 potential vendor in a manner of its choosing, based on IAB 382 consultation, and for managing the various aspects of the 383 relationships with that vendor. 385 In addition, the IETF LLC has the responsibility to ensure long-term 386 access, stability, and uniqueness across all such registries. This 387 responsibility is of particular significance in the event that a 388 relation with a Protocol Parameter Registry Operator is terminated. 390 3. Miscellaneous Considerations 392 While this document has focused on the creation of protocols by the 393 IETF, the requirements provided are generically applicable to the 394 extended IETF community as well (e.g., Internet Research Task Force 395 (IRTF)). 397 The IESG is responsible for the technical direction of the IETF 398 Protocol Parameter registries and maintaining the policies by which 399 such technical directions are given. The IESG is responsible, as 400 part of the document approval process associated with the IETF Stream 401 RFCs [RFC4844], for "IANA Considerations" verification. For the 402 other RFC streams, the approval bodies are responsible for verifying 403 that the documents include "IANA Considerations" sections when 404 needed, and that "IANA Considerations" sections conform to the 405 current published guidelines. In the case that IANA considerations 406 in non-IETF document streams lead to a dispute, the IAB makes the 407 final decision. 409 This document talks about "Registry Operator" (singular), and while 410 there are stability and economy-of-scale advantages for one single 411 Operator, this document does not exclude having different Operators 412 for different protocol registries when justified by the 413 circumstances. 415 4. Security Considerations 417 This document does not propose any new protocols and does not 418 introduce any new security considerations. 420 5. IANA Considerations 422 This document requires no direct IANA actions in terms of the 423 creation or operation of a protocol parameter registry. However, 424 this document does define the roles and responsibilities of various 425 bodies who are responsible for, and associated with, the operation of 426 protocol parameter registration functions for the IETF. 428 6. Informative References 430 [I-D.ietf-iasa2-rfc4071bis] 431 Haberman, B., Hall, J., and J. Livingood, "Structure of 432 the IETF Administrative Support Activity, Version 2.0", 433 draft-ietf-iasa2-rfc4071bis-00 (work in progress), 434 December 2018. 436 [I-D.ietf-iasa2-rfc6635bis] 437 Kolkman, O., Halpern, J., and R. Hinden, "RFC Editor Model 438 (Version 2)", draft-ietf-iasa2-rfc6635bis-01 (work in 439 progress), August 2018. 441 [MoU_SUPP2018] 442 "ICANN/IANA-IETF MoU Supplemental Agreement, 2018". 444 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 445 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 446 . 448 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 449 Understanding Concerning the Technical Work of the 450 Internet Assigned Numbers Authority", RFC 2860, 451 DOI 10.17487/RFC2860, June 2000, 452 . 454 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 455 IETF Administrative Support Activity (IASA)", BCP 101, 456 RFC 4071, DOI 10.17487/RFC4071, April 2005, 457 . 459 [RFC4371] Carpenter, B., Ed. and L. Lynch, Ed., "BCP 101 Update for 460 IPR Trust", BCP 101, RFC 4371, DOI 10.17487/RFC4371, 461 January 2006, . 463 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 464 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 465 July 2007, . 467 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 468 IANA Considerations Section in RFCs", RFC 5226, 469 DOI 10.17487/RFC5226, May 2008, 470 . 472 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 473 Writing an IANA Considerations Section in RFCs", BCP 26, 474 RFC 8126, DOI 10.17487/RFC8126, June 2017, 475 . 477 Appendix A. Acknowledgements 479 This document was originally adapted from "Guidelines for Writing an 480 IANA Considerations Section in RFCs" [RFC5226], and has been modified 481 to include explicit reference to Intellectual Property Rights and the 482 roles of the IAB and IESG in relation to the IETF Protocol Parameter 483 Registry function. 485 In 2018 the document was updated under auspicies of the IASA2.0 486 working group to reflect the reorganization of IETF Administrative 487 Support Activity. 489 The Internet Architecture Board acknowledges the assistance provided 490 by reviewers of drafts of this document, including Scott Bradner, 491 Brian Carpenter, Leslie Daigle, Adrian Farrel, Alfred Hoenes, Paul 492 Hoffman, Alexey Melnikov, Thomas Narten, and Ray Pelletier. 494 Appendix B. IAB members 496 Internet Architecture Board Members at the time this document was 497 approved for publication were [To Be Confirmed]: 499 Jari Arkko, 500 Alissa Cooper, 501 Ted Hardie, 502 Christian Huitema, 503 Gabriel Montenegro, 504 Erik Nordmark, 505 Mark Nottingham, 506 Melinda Shore, 507 Robert Sparks, 508 Jeff Tantsura, 509 Martin Thomson, 510 Brian Trammell, and 511 Suzanne Woolf. 513 Appendix C. Document Editing Details 515 [Text between square brackets starting with initials are editor 516 notes. Any other text between square brackets assumes an action by 517 the RFC editor prior to publication as an RFC. In most cases this 518 will be removal, sometimes a stylistic or editorial choices ore 519 question is indicated] 521 [This section and its subsections should be removed at publication as 522 RFC, so should the Cover Note] 524 [RFC Editor: in the XML version of this document there are a few 525 cref-comments with editorial questions] 527 C.1. Version Information 529 C.1.1. draft-iab-iasa2-rfc6220-00 531 Original RFC text back ported into XML. With only Editor 532 affiliation changed and IAB members section emptied 534 C.1.2. draft-iab-iasa2-rfc6220-01 536 o Changed references to IAOC to LLC 537 o While reviewing the section on the Trust: Modified reference to 538 RFC 4748 to reference to RFC4371, as that document establishes the 539 Trust while 4748 is technically an update of RFC 3978 (now 540 obsoleted). 541 o Updated reference to ICANN-IETF MoU to most recent version (2018) 542 [MoU_SUPP2018] . 544 C.1.3. draft-iab-iasa2-rfc6220-02 546 o Standardized on "IETF LLC" as the sort version for the entity (per 547 RFC style guide). 548 o Changed "At the request of the chair of the IETF, IAB, or LLC," to 549 "At the request of the chair of the IETF or IAB, or the IETF 550 Executive Director", in the same paragraph: The reporting of the 551 registry operator does not necessarily need to take place in IETF 552 Plenary, it may happen elsewhere. Text changed to reflect as 553 much. 554 o BCP101 is a better reference than exclusively referring to 555 RFC4371. The way the reference is provided needs RFC Editor 556 attention. 557 o IDnits complained about rfc5226 being obsoleted. One of the 558 rfc5226 references is used for historical context in the 559 acknowledgement section, in other places it was replaced by 8126. 560 o IDnits complained about rfc5620 being obsoleted. The reference to 561 5620 is replaced by rfc6635bis-rfc editor model (not including 562 rfc6548bis-independent rfc editor, as it just serves as an example 563 and does not intend to describe the full RFC Editor universe). 564 o Updated the Acknowledgement section 566 C.1.4. draft-iab-iasa2-rfc6220-03 568 o Changed reference for IASA2 structure to 569 [I-D.ietf-iasa2-rfc4071bis] 571 C.2. RCS information 573 $Id: rfc6220bis.xml,v 1.8 2018/12/10 19:42:34 olaf Exp $ 575 Authors' Addresses 577 Danny McPherson (editor) 578 Verisign, Inc. 580 EMail: dmcpherson@verisign.com 582 Olaf Kolkman (editor) 583 Internet Society 585 EMail: kolkman@isoc.org 587 John C Klensin (editor) 589 EMail: john+ietf@jck.com 591 Geoff Huston (editor) 592 APNIC 594 EMail: gih@apnic.net 596 Internet Architecture Board 598 EMail: iab@iab.org