<?xml version='1.0' encoding='utf-8'?><!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?><rfc xmlns:xi="http://www.w3.org/2001/XInclude"ipr="trust200902"version="3" category="info" consensus="true" docName="draft-ietf-iasa2-rfc6220bis-04" indexInclude="true" ipr="trust200902" number="8722" obsoletes="6220"updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true"prepTime="2020-02-26T17:11:27" scripts="Common,Latin" sortRefs="true"version="3">submissionType="IAB" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc6220bis-04" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc8722" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <title abbrev="Role of Registry Operators">Defining the Role and Function of IETF Protocol Parameter Registry Operators</title> <seriesInfoname="Internet-Draft" value="draft-ietf-iasa2-rfc6220bis-04"/>name="RFC" value="8722" stream="IAB"/> <author initials="D." surname="McPherson" fullname="Danny McPherson" role="editor"> <organizationabbrev="ISOC">Verisign,showOnFrontPage="true">Verisign, Inc.</organization> <address> <email>dmcpherson@verisign.com</email> </address> </author> <author initials="O." surname="Kolkman" fullname="Olaf Kolkman" role="editor"> <organizationabbrev="ISOC">Inter netabbrev="ISOC" showOnFrontPage="true">Internet Society</organization> <address> <email>kolkman@isoc.org</email> </address> </author> <authorinitials="J.C."initials="J." surname="Klensin" fullname="John C Klensin" role="editor"> <address><email>john+ietf@jck.com</email><email>john-ietf@jck.com</email> </address> </author> <author initials="G." surname="Huston" fullname="Geoff Huston" role="editor"><organization>APNIC</organization><organization showOnFrontPage="true">APNIC</organization> <address> <email>gih@apnic.net</email> </address> </author><author surname="-"> <organization>Internet Architecture Board</organization> <address> <email>iab@iab.org</email> </address> </author> <date/><date month="02" year="2020"/> <area>General</area> <workgroup>Internet ArchitectureBoard(IAB)</workgroup>Board (IAB)</workgroup> <keyword>IANA</keyword> <keyword>Governance</keyword><abstract> <t><keyword>IASA</keyword> <abstract pn="section-abstract"> <t pn="section-abstract-1"> Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document obsoletes RFC 6220 to replace all references to theIASAIETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model. </t> </abstract><note> <name>[Cover Note]</name> <t> [The IASA2 WG asks<boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t pn="section-boilerplate.1-1"> This document is not an Internet Standards Track specification; it is published for informational purposes. </t> <t pn="section-boilerplate.1-2"> This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable topublish this replacementprovide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC6220.7841. </t> <t pn="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <eref target="https://www.rfc-editor.org/info/rfc8722" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t pn="section-boilerplate.2-1"> Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. </t> <t pn="section-boilerplate.2-2"> This document ischanged for alignmentsubject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. </t> </section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t> </li> <li pn="section-toc.1-1.2"> <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-roles-and-responsibilities-">Roles and Responsibilities Concerning IETF Protocol Parameter Registries</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2"> <li pn="section-toc.1-1.2.2.1"> <t keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-parameter-registry">Protocol Parameter Registry Operator Role</xref></t> </li> <li pn="section-toc.1-1.2.2.2"> <t keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iab-role">IAB Role</xref></t> </li> <li pn="section-toc.1-1.2.2.3"> <t keepWithNext="true" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iesg-role">IESG Role</xref></t> </li> <li pn="section-toc.1-1.2.2.4"> <t keepWithNext="true" pn="section-toc.1-1.2.2.4.1"><xref derivedContent="2.4" format="counter" sectionFormat="of" target="section-2.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-role-of-the-ietf-trust">Role of thenew structure forIETF Trust</xref></t> </li> <li pn="section-toc.1-1.2.2.5"> <t keepWithNext="true" pn="section-toc.1-1.2.2.5.1"><xref derivedContent="2.5" format="counter" sectionFormat="of" target="section-2.5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-role-of-the-ietf-administra">Role of the IETFAdministrative Support Activity (IASA). ] </t> </note>Administration Limited Liability Company</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.3"> <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-miscellaneous-consideration">Miscellaneous Considerations</xref></t> </li> <li pn="section-toc.1-1.4"> <t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> </li> <li pn="section-toc.1-1.5"> <t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> </li> <li pn="section-toc.1-1.6"> <t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> <li pn="section-toc.1-1.7"> <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-iab-members-at-the-time-of-">IAB Members at the Time of Approval</xref></t> </li> <li pn="section-toc.1-1.8"> <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t> </li> <li pn="section-toc.1-1.9"> <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc> </front><!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --><middle> <section numbered="true"toc="default"> <name>Overview</name> <t>toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-overview">Overview</name> <t pn="section-1-1"> Many IETF protocols make use of commonly defined values that are passed within messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registries to record each of the possible values of a protocol parameter and their associated semantic intent. These registries, their registration policy, and the layout of their content are defined in the so-called "IANA Considerations" sections of IETF documents. </t><t><t pn="section-1-2"> The organizational separation between the IETF and its Protocol Parameter Registry Operators parallels ones that are fairly common among standards development organizations (SDOs) although less common among technology consortia and similar bodies. These functions have been separated into different organizations for several reasons. They include dealing with administrative issues, addressing concerns about maintaining an adequate distance between basic policy and specific allocations, and avoiding any potential conflicts of interest that might arise from commercial or organizational relationships. For example, most ISO and ISO/IEC JTC1 standards that require registration activities specify a Registration Authority (RA) or Maintenance Agency (MA) that, in turn, control the actual registration decisions. The databases of what is registered for each standard may then be maintained by a secretariat or database function associated with the RA or MA or, less frequently, by the secretariat of the body that created and maintains the standard itself. </t><t><t pn="section-1-3"> This structural separation of roles exists within several places in the IETF framework (e.g., the RFC Editor function). The Internet Architecture Board (IAB), on behalf of the IETF, has the responsibility to define and manage the relationship with the Protocol Parameter Registry Operator role. This responsibility includes the selection and management of the Protocol Parameter Registry Operator, as well as management of the parameter registration process and the guidelines for parameter allocation. </t><t><t pn="section-1-4"> As with other SDOs, although it may delegate authority for some specific decisions, the IETF asserts authority and responsibility for the management of all of its protocol parameters and their registries, even while it generally remains isolated from the selection of particular values once a registration is approved. This document describes the function of these registries as they apply to individual protocol parameters defined by the IETF Internet Standards Process (see RFC 6410 <xreftarget="RFC6410" format="default"/>target="BCP9" format="default" sectionFormat="of" derivedContent="BCP9"/>) to allow for an orderly implementation by the IETF Administration Limited Liability Company (IETF LLC), and others as needed, under guidance from the IAB. This document obsoletes RFC 6220 to replace all references to the IASA and related structures with those defined by the IASA 2.0 Model <xreftarget="I-D.ietf-iasa2-rfc4071bis" format="default"/>.target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>. </t><t><t pn="section-1-5"> Below we provide a description of the requirements for these delegated functions, which the IETF traditionally refers to as the Internet Assigned Numbers Authority (IANA) function. </t> </section><!-- Introduction --><section numbered="true"toc="default"> <name>Rolestoc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-roles-and-responsibilities-">Roles and Responsibilities Concerning IETF Protocol Parameter Registries</name><t><t pn="section-2-1"> The IETF's longstanding practice is to outsource the management and implementation of some important functions (e.g., <xreftarget="I-D.ietf-iasa2-rfc6635bis" format="default"/>).target="RFC8728" format="default" sectionFormat="of" derivedContent="RFC8728"/>). The protocol parameter registry function falls into this category of outsourced functions, and what follows here is the description of the roles and responsibilities with respect to the registration of IETF protocol parameters. </t><t><t pn="section-2-2"> Specifically, this document describes the operation and role of a delegated IETF Protocol Parameter Registry Operator, to be selected and administered by the IETF Administrative Support Activity (IASA) <xreftarget="I-D.ietf-iasa2-rfc4071bis" format="default"/>.target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>. While there is generally a single Protocol Parameter Registry Operator, additional Operators may be selected to implement specific registries, and that has been done occasionally. Having a single Protocol Parameter Registry Operator facilitates coordination among registries, even those that are not obviously related, and also makes it easier to have consistency of formats and registry structure, which aids users of the registries and assists with quality control. </t><t><t pn="section-2-3"> Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPsec). To ensure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by a delegated Protocol Parameter Registry Operator. For any particular protocol parameter there is a single delegated Registry Operator. </t> <section numbered="true"toc="default" anchor="protocolparamreg"> <name>Protocoltoc="include" anchor="protocolparamreg" removeInRFC="false" pn="section-2.1"> <name slugifiedName="name-protocol-parameter-registry">Protocol Parameter Registry Operator Role</name><t><t pn="section-2.1-1"> The IETF Protocol Parameter Registry function is undertaken under the auspices of the Internet Architecture Board. </t><t><t pn="section-2.1-2"> The roles of the Protocol Parameter Registry Operator (Registry Operator) are as follows: </t> <ulspacing="normal"> <li> <t>Reviewspacing="normal" bare="false" empty="false" pn="section-2.1-3"> <li pn="section-2.1-3.1"> <t pn="section-2.1-3.1.1">Review and Advise </t> <ulspacing="normal"> <li>spacing="normal" bare="false" empty="false" pn="section-2.1-3.1.2"> <li pn="section-2.1-3.1.2.1"> A Registry Operator may be requested to review Internet-Drafts that are being considered by the Internet Engineering Steering Group (IESG), with the objective of offering advice to the IESG regarding the contents of the "IANA Considerations" section, whether such a section, when required, is clear in terms of direction to the Registry Operator, and whether the section is consistent with the current published Registry Operator guidelines. </li> </ul> </li><!-- Review and Advice --> <li> <t>Registry<li pn="section-2.1-3.2"> <t pn="section-2.1-3.2.1">Registry </t> <ulspacing="normal"> <li>spacing="normal" bare="false" empty="false" pn="section-2.1-3.2.2"> <li pn="section-2.1-3.2.2.1"> To operate a registry of protocol parameter assignments. </li><li> <t><li pn="section-2.1-3.2.2.2"> <t pn="section-2.1-3.2.2.2.1"> The delegated Registry Operator registers values for Internet protocol parameters only as directed by the criteria and procedures specified in RFCs, includingStandardStandards TrackDocumentsdocuments <xref target="BCP9"format="default"/>,format="default" sectionFormat="of" derivedContent="BCP9"/>, Best Current Practice documents, and other RFCs that require protocol parameter assignment. </t><t><t pn="section-2.1-3.2.2.2.2"> If values for Internet protocol parameters were not specified, or in case of ambiguity, the Registry Operator will continue to assign and register only those protocol parameters that have already been delegated to the Registry Operator, following past and current practice for such assignments, unless otherwise directed in terms of operating practice by the IESG. In the case of ambiguity, the Registry Operator is expected to identify the ambiguity to the IAB or IESG as appropriate and either suggest better text or ask the appropriate parties for clarification. </t> </li> </ul> <ulspacing="normal"> <li> <t>spacing="normal" bare="false" empty="false" pn="section-2.1-3.2.3"> <li pn="section-2.1-3.2.3.1"> <t pn="section-2.1-3.2.3.1.1"> For each protocol parameter, the associated registry includes: </t> <ulspacing="normal"> <li>spacing="normal" bare="false" empty="false" pn="section-2.1-3.2.3.1.2"> <li pn="section-2.1-3.2.3.1.2.1"> a reference to the RFC document that describes the parameter and the associated "IANA Considerations" concerning the parameter, and </li><li><li pn="section-2.1-3.2.3.1.2.2"> for each registration of a protocol parameter value, the source of the registration and the date of the registration, if the date of registration is known, and </li><li><li pn="section-2.1-3.2.3.1.2.3"> any other information specified as being included in the registration data in the RFC document that describes the parameter. </li><li><li pn="section-2.1-3.2.3.1.2.4"> If in doubt or in case of a technical dispute, the Registry Operator will seek and follow technical guidance exclusively from the IESG. Where appropriate, the IESG will appoint an expert to advise the Registry Operator. </li> </ul> </li><li><li pn="section-2.1-3.2.3.2"> The Registry Operator will work with the IETF to develop any missing criteria and procedures over time, which the Registry Operator will adopt when so instructed by the IESG. </li><li><li pn="section-2.1-3.2.3.3"> Unless special circumstances apply to subsets of the data and specific rules are established by IETF consensus, each protocol parameter registry operates as a public registry, and the contents of the registry are openly available to the public, on-line and free of charge. </li><li><li pn="section-2.1-3.2.3.4"> The Registry Operator assigns protocol parameter values in accordance with the policy associated with the protocol parameter, such as "First Come First Served" or "Expert Review" <xref target="RFC8126"format="default"/>.format="default" sectionFormat="of" derivedContent="RFC8126"/>. </li> </ul> </li><!-- Registry--> <li> <t><li pn="section-2.1-3.3"> <t pn="section-2.1-3.3.1"> Mailing Lists </t> <ulspacing="normal"> <li>spacing="normal" bare="false" empty="false" pn="section-2.1-3.3.2"> <li pn="section-2.1-3.3.2.1"> The Registry Operator maintains public mailing lists as specified in IANA Considerations <xref target="RFC8126"format="default"/>.format="default" sectionFormat="of" derivedContent="RFC8126"/>. Such lists are designated for the purpose of review of assignment proposals in conjunction with a designated expert review function. In addition, eachProtocol ParameterRegistry Operator should maintain a mailing list that enables the registry staff of the Registry Operator to be contacted by email. </li> </ul> </li><!-- Mailing Lists --> <li> <t><li pn="section-2.1-3.4"> <t pn="section-2.1-3.4.1"> Liaison Activity </t> <ulspacing="normal"> <li>spacing="normal" bare="false" empty="false" pn="section-2.1-3.4.2"> <li pn="section-2.1-3.4.2.1"> The Registry Operator will nominate a liaison point of contact. The Registry Operator, through this liaison, may be requested to provide advice to the IESG on IETF protocol parameters as well as the "IANA Considerations" section of each Internet-Draft that is being reviewed for publication as an RFC. Where appropriate the IESG will appoint an expert to advise the Registry Operator. </li> </ul> </li><!--Liason Activity --> <li> <t><li pn="section-2.1-3.5"> <t pn="section-2.1-3.5.1"> Reporting </t> <ulspacing="normal"> <li>spacing="normal" bare="false" empty="false" pn="section-2.1-3.5.2"> <li pn="section-2.1-3.5.2.1"> The Registry Operator will submit periodic reports to the IAB concerning the operational performance of the registry function. As an example of the requirements for such reports, the reader is referred to a supplement <xref target="MoU_SUPP2019"format="default"/>format="default" sectionFormat="of" derivedContent="MoU_SUPP2019"/> to the "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority" <xref target="RFC2860"format="default"/>format="default" sectionFormat="of" derivedContent="RFC2860"/> that provides service level agreement (SLA) guidelines under which ICANN, the current protocol parameter registry, must operate. </li><li><li pn="section-2.1-3.5.2.2"> At the request of the chair of the IETF or IAB, or the IETF Executive Director <xreftarget="I-D.ietf-iasa2-rfc4071bis" format="default"/>,target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>, the Registry Operator will undertake periodic reports to IETF Plenarymeetings,meetings or elsewhere asthey may direct,directed, concerning the status of the registry function. </li><li><li pn="section-2.1-3.5.2.3"> The Registry Operator will publish an annual report describing the status of the function and a summary of performance indicators. </li> </ul> </li><!-- Reporting --> <li> <t><li pn="section-2.1-3.6"> <t pn="section-2.1-3.6.1"> Intellectual Property Rights and the Registry Operator </t><t><t pn="section-2.1-3.6.2"> Unless special circumstances apply (see above): </t> <ulspacing="normal"> <li>Allspacing="normal" bare="false" empty="false" pn="section-2.1-3.6.3"> <li pn="section-2.1-3.6.3.1">All assigned values are to be published and made available free of any charges. </li><li><li pn="section-2.1-3.6.3.2"> The assignment values may be redistributed without modification. </li> </ul><t>In<t pn="section-2.1-3.6.4">In any case,</t><ul> <li><ul bare="false" empty="false" spacing="normal" pn="section-2.1-3.6.5"> <li pn="section-2.1-3.6.5.1"> any intellectual property rights of the IETF protocol parameter assignment information, including the IETF protocol parameter registry and its contents, are to be held by the IETF Trust <xreftarget="BCP101" format="default"/>.target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/> <xref target="RFC8714" format="default" sectionFormat="of" derivedContent="RFC8714"/>. </li> </ul> </li><!-- IPR --></ul> </section><!-- Section 2.1 --><section numbered="true"toc="default" anchor="IABrole"> <name>IABtoc="include" anchor="IABrole" removeInRFC="false" pn="section-2.2"> <name slugifiedName="name-iab-role">IAB Role</name><t><t pn="section-2.2-1"> An Operator of an IETF protocol parameter registry undertakes the role as a delegated function under the authority of the IAB. </t><t><t pn="section-2.2-2"> The IAB has the responsibility to review the current description of the registry function from time to time and direct the Registry Operator to adopt amendments relating to its role and mode of operation according to the best interests of the IETF and the Internet community in general. </t><t><t pn="section-2.2-3"> The IAB has the responsibility to appoint an organization to undertake the delegated functions of theProtocol ParameterRegistry Operator for each IETF protocol parameter. Specifically, the IAB defines the role and requirements for the desired functions. The IETF LLC is responsible for identifying a potential vendor, and once under agreement, managing the various aspects of the relationships with that vendor. To be clear, the IAB is in the deciding role (e.g., for appointment and termination), but must work in close consultation with the IETF LLC. </t><t><t pn="section-2.2-4"> The IAB has the responsibility to determine the terms and conditions of this delegated role. Such terms and conditions should ensure that the registry operates in a manner that is fully conformant to the functions described in this document. In addition, such terms and conditions must not restrict the rights and interests of the IETF with respect to the registry contents and maintenance. </t> </section><!--section 2.2--><section numbered="true"toc="default"> <name>IESGtoc="include" removeInRFC="false" pn="section-2.3"> <name slugifiedName="name-iesg-role">IESG Role</name><t><t pn="section-2.3-1"> The IESG is responsible for the technical direction regarding entries into IETF protocol parameter registries and maintaining the policies by which such technical directions are given. Technical direction itself is provided through the adoption of directives within the "IANA Considerations" section of IETF Stream RFCs or throughstand- alonestand-alone "IANA Considerations" RFCs. </t><t><t pn="section-2.3-2"> The IESG shall verify that Internet-Drafts that are offered for publication as IETF Stream RFCs <xreftarget="RFC4844" format="default"/>target="RFC8729" format="default" sectionFormat="of" derivedContent="RFC8729"/> include "IANA Considerations" sections when needed, and that "IANA Considerations" sections conform to the current published guidelines. </t><t><t pn="section-2.3-3"> Since technical assessment is not generally a responsibility of the Registry Operator, as part of providing the technical direction the IESG is responsible for identifying the technical experts that are required to, where appropriate, review registration requests or resolve open technical questions that relate to the registration of parameters. </t><t><t pn="section-2.3-4"> At its discretion, the IESG will organize the liaison activities with the Registry Operator's liaison point of contact so as to facilitate clear communications and effective operation of the registry function. </t> </section><!--section 2.3--><section numbered="true"toc="default"> <name>Roletoc="include" removeInRFC="false" pn="section-2.4"> <name slugifiedName="name-role-of-the-ietf-trust">Role of the IETF Trust</name><t><t pn="section-2.4-1"> The IETF Trust <xref target="RFC4371"format="default"/>format="default" sectionFormat="of" derivedContent="RFC4371"/> was formed to act as the administrative custodian of all copyrights and other intellectual property rights relating to the IETF Standards Process, a function that had previously been performed by the Internet Society (ISOC) and the Corporation for National Research Initiatives (CNRI). </t><t><t pn="section-2.4-2"> Any intellectual property rights of IETF protocol parameter assignment information, including the registry and its contents, and all registry publications, are to be held by the IETF Trust on behalf of the IETF. </t><t><t pn="section-2.4-3"> The IETF Trust may make such regulations as appropriate for the redistribution of assignment values and registry publications. </t> </section><!--section 2.4--><section numbered="true"toc="default"> <name>Roletoc="include" removeInRFC="false" pn="section-2.5"> <name slugifiedName="name-role-of-the-ietf-administra">Role of the IETF Administration Limited Liability Company</name><t><t pn="section-2.5-1"> The IETF Administration Limited Liability Company (IETF LLC) <xreftarget="I-D.ietf-iasa2-rfc4071bis" format="default"/>target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/> is responsible for identifying a potential vendor in a manner of its choosing, based on IAB consultation, and for managing the various aspects of the relationships with that vendor. </t><t><t pn="section-2.5-2"> In addition, the IETF LLC has the responsibility to ensure long-term access, stability, and uniqueness across all such registries. This responsibility is of particular significance in the event that a relation with a Protocol Parameter Registry Operator is terminated. </t> </section><!--section 2.5--></section><!-- Section 2 --><section numbered="true"toc="default"> <name>Miscellaneoustoc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-miscellaneous-consideration">Miscellaneous Considerations</name><t><t pn="section-3-1"> While this document has focused on the creation of protocols by the IETF, the requirements provided are generically applicable to the extended IETF community as well (e.g., Internet Research Task Force (IRTF)). </t><t><t pn="section-3-2"> The IESG is responsible for the technical direction of the IETFProtocol Parameterprotocol parameter registries and maintaining the policies by which such technical directions are given. The IESG is responsible, as part of the document approval process associated with the IETF Stream RFCs <xreftarget="RFC4844" format="default"/>,target="RFC8729" format="default" sectionFormat="of" derivedContent="RFC8729"/>, for "IANA Considerations" verification. For the other RFC streams, the approval bodies are responsible for verifying that the documents include "IANA Considerations" sections when needed, and that "IANA Considerations" sections conform to the current published guidelines. In the case that IANA considerations in non-IETF document streams lead to a dispute, the IAB makes the final decision. </t><t><t pn="section-3-3"> This document talks about "Registry Operator" (singular), and while there are stability and economy-of-scale advantages for one single Registry Operator, this document does not exclude having different Registry Operators for different protocol registries when justified by the circumstances. </t> </section><!-- Section 3--><section numbered="true"toc="default"> <name>Securitytoc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-security-considerations">Security Considerations</name><t><t pn="section-4-1"> This document does not propose any new protocols and does not introduce any new security considerations. </t> </section> <section numbered="true"toc="default"> <name>IANAtoc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-iana-considerations">IANA Considerations</name><t><t pn="section-5-1"> This document requires no direct IANA actions in terms of the creation or operation of a protocol parameter registry. However, this document does define the roles and responsibilities of various bodies who are responsible for, and associated with, the operation of protocol parameter registration functions for the IETF. </t> </section> </middle> <back><references> <name>Informative<references pn="section-6"> <name slugifiedName="name-informative-references">Informative References</name> <referencegroupanchor="BCP9">anchor="BCP9" target="https://www.rfc-editor.org/info/bcp9" derivedAnchor="BCP9"> <reference anchor="RFC2026"target="https://www.rfc-editor.org/info/rfc2026">target="https://www.rfc-editor.org/info/rfc2026" quoteTitle="true"> <front> <title>The Internet Standards Process -- Revision 3</title> <author initials="S." surname="Bradner" fullname="S. Bradner"><organization/><organization showOnFrontPage="true"/> </author> <date year="1996" month="October"/> <abstract> <t>This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="2026"/> <seriesInfo name="DOI" value="10.17487/RFC2026"/> </reference> <reference anchor="RFC5657"target="https://www.rfc-editor.org/info/rfc5657">target="https://www.rfc-editor.org/info/rfc5657" quoteTitle="true"> <front> <title>Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard</title> <author initials="L." surname="Dusseault" fullname="L. Dusseault"><organization/><organization showOnFrontPage="true"/> </author> <author initials="R." surname="Sparks" fullname="R. Sparks"><organization/><organization showOnFrontPage="true"/> </author> <date year="2009" month="September"/> <abstract> <t>Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="5657"/> <seriesInfo name="DOI" value="10.17487/RFC5657"/> </reference> <reference anchor="RFC6410"target="https://www.rfc-editor.org/info/rfc6410">target="https://www.rfc-editor.org/info/rfc6410" quoteTitle="true"> <front> <title>Reducing the Standards Track to Two Maturity Levels</title> <author initials="R." surname="Housley" fullname="R. Housley"><organization/><organization showOnFrontPage="true"/> </author> <author initials="D." surname="Crocker" fullname="D. Crocker"><organization/><organization showOnFrontPage="true"/> </author> <author initials="E." surname="Burger" fullname="E. Burger"><organization/><organization showOnFrontPage="true"/> </author> <date year="2011" month="October"/> <abstract> <t>This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice.</t> </abstract> </front> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="6410"/> <seriesInfo name="DOI" value="10.17487/RFC6410"/> </reference> <reference anchor="RFC7100"target="https://www.rfc-editor.org/info/rfc7100">target="https://www.rfc-editor.org/info/rfc7100" quoteTitle="true"> <front> <title>Retirement of the "Internet Official Protocol Standards" Summary Document</title> <author initials="P." surname="Resnick" fullname="P. Resnick"><organization/><organization showOnFrontPage="true"/> </author> <date year="2013" month="December"/> <abstract> <t>This document updates RFC 2026 to no longer use STD 1 as a summary of "Internet Official Protocol Standards". It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status.</t> </abstract> </front> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="7100"/> <seriesInfo name="DOI" value="10.17487/RFC7100"/> </reference> <reference anchor="RFC7127"target="https://www.rfc-editor.org/info/rfc7127">target="https://www.rfc-editor.org/info/rfc7127" quoteTitle="true"> <front> <title>Characterization of Proposed Standards</title> <author initials="O." surname="Kolkman" fullname="O. Kolkman"><organization/><organization showOnFrontPage="true"/> </author> <author initials="S." surname="Bradner" fullname="S. Bradner"><organization/><organization showOnFrontPage="true"/> </author> <author initials="S." surname="Turner" fullname="S. Turner"><organization/><organization showOnFrontPage="true"/> </author> <date year="2014" month="January"/> <abstract> <t>RFC 2026 describes the review performed by the Internet Engineering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards.</t> </abstract> </front> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="7127"/> <seriesInfo name="DOI" value="10.17487/RFC7127"/> </reference> <reference anchor="RFC7475"target="https://www.rfc-editor.org/info/rfc7475">target="https://www.rfc-editor.org/info/rfc7475" quoteTitle="true"> <front> <title>Increasing the Number of Area Directors in an IETF Area</title> <author initials="S." surname="Dawkins" fullname="S. Dawkins"><organization/><organization showOnFrontPage="true"/> </author> <date year="2015" month="March"/> <abstract> <t>This document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area". This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).</t> </abstract> </front> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="7475"/> <seriesInfo name="DOI" value="10.17487/RFC7475"/> </reference> </referencegroup> <reference anchor="MoU_SUPP2019" target="https://www.ietf.org/media/documents/FINAL_2019-IETF_MoU_Supplemental_Agreement_Signed_31July19.pdf" quoteTitle="true" derivedAnchor="MoU_SUPP2019"> <front> <title>2019 ICANN-IETF MoU Supplemental Agreement</title> <author> <organization showOnFrontPage="true">IETF Administration LLC</organization> </author> <date year="2019" month="July" day="31"/> </front> </reference> <reference anchor="RFC2860"target="https://www.rfc-editor.org/info/rfc2860">target="https://www.rfc-editor.org/info/rfc2860" quoteTitle="true" derivedAnchor="RFC2860"> <front> <title>Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority</title> <author initials="B." surname="Carpenter" fullname="B. Carpenter"><organization/><organization showOnFrontPage="true"/> </author> <author initials="F." surname="Baker" fullname="F. Baker"><organization/><organization showOnFrontPage="true"/> </author> <author initials="M." surname="Roberts" fullname="M. Roberts"><organization/><organization showOnFrontPage="true"/> </author> <date year="2000" month="June"/> <abstract> <t>This document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="2860"/> <seriesInfo name="DOI" value="10.17487/RFC2860"/> </reference> <referenceanchor="I-D.ietf-iasa2-rfc4071bis"> <front> <title>Structure of the IETF Administrative Support Activity, Version 2.0</title> <author initials="B" surname="Haberman" fullname="Brian Haberman"> <organization/> </author> <author initials="J" surname="Hall" fullname="Joseph Hall"> <organization/> </author> <author initials="J" surname="Livingood" fullname="Jason Livingood"> <organization/> </author> <date month="April" day="12" year="2019"/> <abstract> <t>The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this document is to document and describe the IETF Administrative Support Activity, version 2 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board, the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF Administration LLC Board. This document obsoletes RFC 4071, RFC 4333, and RFC 7691.</t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-iasa2-rfc4071bis-11"/> <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-iasa2-rfc4071bis-11.txt"/> </reference> <referencegroup anchor="BCP101"> <reference anchor="RFC4071" target="https://www.rfc-editor.org/info/rfc4071"> <front> <title>Structure of the IETF Administrative Support Activity (IASA)</title> <author initials="R." surname="Austein" fullname="R. Austein" role="editor"> <organization/> </author> <author initials="B." surname="Wijnen" fullname="B. Wijnen" role="editor"> <organization/> </author> <date year="2005" month="April"/> <abstract> <t>This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC). It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="101"/> <seriesInfo name="RFC" value="4071"/> <seriesInfo name="DOI" value="10.17487/RFC4071"/> </reference> <reference anchor="RFC4371" target="https://www.rfc-editor.org/info/rfc4371">anchor="RFC4371" target="https://www.rfc-editor.org/info/rfc4371" quoteTitle="true" derivedAnchor="RFC4371"> <front> <title>BCP 101 Update for IPR Trust</title> <author initials="B." surname="Carpenter" fullname="B. Carpenter" role="editor"><organization/><organization showOnFrontPage="true"/> </author> <author initials="L." surname="Lynch" fullname="L. Lynch" role="editor"><organization/><organization showOnFrontPage="true"/> </author> <date year="2006" month="January"/> <abstract> <t>This document updates BCP 101 to take account of the new IETF Intellectual Property Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="101"/> <seriesInfo name="RFC" value="4371"/> <seriesInfo name="DOI" value="10.17487/RFC4371"/> </reference></referencegroup><referenceanchor="RFC4844" target="https://www.rfc-editor.org/info/rfc4844">anchor="RFC5226" target="https://www.rfc-editor.org/info/rfc5226" quoteTitle="true" derivedAnchor="RFC5226"> <front><title>The RFC Series and RFC Editor</title><title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <authorinitials="L." surname="Daigle" fullname="L. Daigle" role="editor"> <organization/>initials="T." surname="Narten" fullname="T. Narten"> <organization showOnFrontPage="true"/> </author><author> <organization>Internet Architecture Board</organization><author initials="H." surname="Alvestrand" fullname="H. Alvestrand"> <organization showOnFrontPage="true"/> </author> <dateyear="2007" month="July"/> <abstract> <t>This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="4844"/> <seriesInfo name="DOI" value="10.17487/RFC4844"/> </reference> <reference anchor="RFC5226" target="https://www.rfc-editor.org/info/rfc5226"> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author initials="T." surname="Narten" fullname="T. Narten"> <organization/> </author> <author initials="H." surname="Alvestrand" fullname="H. Alvestrand"> <organization/> </author> <date year="2008" month="May"/>year="2008" month="May"/> <abstract> <t>Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t> <t>In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t> <t>This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="RFC" value="5226"/> <seriesInfo name="DOI" value="10.17487/RFC5226"/> </reference> <reference anchor="RFC8126"target="https://www.rfc-editor.org/info/rfc8126">target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126"> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author initials="M." surname="Cotton" fullname="M. Cotton"><organization/><organization showOnFrontPage="true"/> </author> <author initials="B." surname="Leiba" fullname="B. Leiba"><organization/><organization showOnFrontPage="true"/> </author> <author initials="T." surname="Narten" fullname="T. Narten"><organization/><organization showOnFrontPage="true"/> </author> <date year="2017" month="June"/> <abstract> <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t> <t>This is the third edition of this document; it obsoletes RFC 5226.</t> </abstract> </front> <seriesInfo name="BCP" value="26"/> <seriesInfo name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/> </reference> <referenceanchor="I-D.ietf-iasa2-rfc6635bis">anchor="RFC8711" target="https://www.rfc-editor.org/info/rfc8711" quoteTitle="true" derivedAnchor="RFC8711"> <front> <title>Structure of the IETF Administrative Support Activity, Version 2.0</title> <author initials="B." surname="Haberman"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Hall"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Livingood"> <organization showOnFrontPage="true"/> </author> <date year="2020" month="February"/> </front> <seriesInfo name="BCP" value="101"/> <seriesInfo name="RFC" value="8711"/> <seriesInfo name="DOI" value="10.17487/RFC8711"/> </reference> <reference anchor="RFC8714" target="https://www.rfc-editor.org/info/rfc8714" quoteTitle="true" derivedAnchor="RFC8714"> <front> <title>Update to the Process for Selection of Trustees for the IETF Trust</title> <author initials="J" surname="Arkko" fullname="Jari Arkko"> <organization showOnFrontPage="true"/> </author> <author initials="T" surname="Hardie" fullname="Ted Hardie"> <organization showOnFrontPage="true"/> </author> <date month="February" year="2020"/> </front> <seriesInfo name="BCP" value="101"/> <seriesInfo name="RFC" value="8714"/> <seriesInfo name="DOI" value="10.17487/RFC8714"/> </reference> <reference anchor="RFC8728" target="https://www.rfc-editor.org/info/rfc8729" quoteTitle="true" derivedAnchor="RFC8728"> <front> <title>RFC Editor Model (Version 2)</title> <author initials="O" surname="Kolkman" fullname="OlafKolkman"> <organization/>Kolkman" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="J" surname="Halpern" fullname="JoelHalpern"> <organization/>Halpern" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="R" surname="Hinden" fullname="RobertHinden"> <organization/>Hinden" role="editor"> <organization showOnFrontPage="true"/> </author> <datemonth="October" day="4" year="2019"/> <abstract> <t>The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: themonth="February" year="2020"/> </front> <seriesInfo name="RFC" value="8728"/> <seriesInfo name="DOI" value="10.17487/RFC8728"/> </reference> <reference anchor="RFC8729" target="https://www.rfc-editor.org/info/rfc8729" quoteTitle="true" derivedAnchor="RFC8729"> <front> <title>The RFC SeriesEditor, the RFC Production Center,andtheRFCPublisher.Editor</title> <author initials="R." surname="Housley" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="L." surname="Daigle" role="editor"> <organization showOnFrontPage="true"/> </author> <date month="February" year="2020"/> </front> <seriesInfo name="RFC" value="8729"/> <seriesInfo name="DOI" value="10.17487/RFC8729"/> </reference> </references> <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-iab-members-at-the-time-of-">IAB Members at the Time of Approval</name> <t pn="section-appendix.a-1"> Internet Architecture Board(IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company andMembers at theRSOC.time this document was approved for publication were: </t> <ul empty="true" spacing="compact" bare="false" pn="section-appendix.a-2"> <li pn="section-appendix.a-2.1"> <t pn="section-appendix.a-2.1.1"><contact fullname="Jari Arkko"/></t> </li> <li pn="section-appendix.a-2.2"> <t pn="section-appendix.a-2.2.1"><contact fullname="Alissa Cooper"/></t> </li> <li pn="section-appendix.a-2.3"> <t pn="section-appendix.a-2.3.1"><contact fullname="Stephen Farrell"/></t> </li> <li pn="section-appendix.a-2.4"> <t pn="section-appendix.a-2.4.1"><contact fullname="Wes Hardaker"/></t> </li> <li pn="section-appendix.a-2.5"> <t pn="section-appendix.a-2.5.1"><contact fullname="Ted Hardie"/></t> </li> <li pn="section-appendix.a-2.6"> <t pn="section-appendix.a-2.6.1"><contact fullname="Christian Huitema"/></t> </li> <li pn="section-appendix.a-2.7"> <t pn="section-appendix.a-2.7.1"><contact fullname="Zhenbin Li"/></t> </li> <li pn="section-appendix.a-2.8"> <t pn="section-appendix.a-2.8.1"><contact fullname="Erik Nordmark"/></t> </li> <li pn="section-appendix.a-2.9"> <t pn="section-appendix.a-2.9.1"><contact fullname="Mark Nottingham"/></t> </li> <li pn="section-appendix.a-2.10"> <t pn="section-appendix.a-2.10.1"><contact fullname="Melinda Shore"/></t> </li> <li pn="section-appendix.a-2.11"> <t pn="section-appendix.a-2.11.1"><contact fullname="Jeff Tantsura"/></t> </li> <li pn="section-appendix.a-2.12"> <t pn="section-appendix.a-2.12.1"><contact fullname="Martin Thomson"/></t> </li> <li pn="section-appendix.a-2.13"> <t pn="section-appendix.a-2.13.1"><contact fullname="Brian Trammell"/></t> </li> </ul> </section> <section numbered="false" toc="include" anchor="Acknowledgement" removeInRFC="false" pn="section-appendix.b"> <name slugifiedName="name-acknowledgements">Acknowledgements</name> <t pn="section-appendix.b-1"> This documentreflects the experience gained with "RFC Editor Model (Version 1)", documentedwas originally adapted from "Guidelines for Writing an IANA Considerations Section inRFC 5620;RFCs" <xref target="RFC5226" format="default" sectionFormat="of" derivedContent="RFC5226"/>, andobsoletes RFC 6635has been modified toreplace all references to the IASA and related structures with those defined by the IASA 2.0 Model. [RFC Editor: Please remove the following paragraph prior to publication.] The IASA2 WG requests that the IAB publish this replacement for RFC 6635.</t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-iasa2-rfc6635bis-04"/> <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-iasa2-rfc6635bis-04.txt"/> </reference> <reference anchor="MoU_SUPP2019"> <front> <title> ICANN/IANA-IETF MoU Supplemental Agreement, 2019</title> <author/> <date/> </front> <annotation><eref target="https://www.ietf.org/media/documents/FINAL_2019-IETF_MoU_Supplemental_Agreement_Signed_31July19.pdf"/>. </annotation> </reference> </references> <section numbered="true" toc="default" anchor="Acknowledgement"> <name>Acknowledgements</name> <t> This document was originally adapted from "Guidelines for Writing an IANA Considerations Section in RFCs" <xref target="RFC5226" format="default"/>, and has been modified to include explicit referenceinclude explicit reference to Intellectual Property Rights and the roles of the IAB and IESG in relation to the IETF Protocol Parameter Registry function. </t><t><t pn="section-appendix.b-2"> The document was updated underauspiciesauspices of theIASA2.0IASA2 working group to reflect the reorganization of IETF Administrative Support Activity. </t><t><t pn="section-appendix.b-3"> The Internet Architecture Board acknowledges the assistance provided by reviewers of drafts of this document, includingScott Bradner, Brian Carpenter, Leslie Daigle, Adrian Farrel, Bob Hinden, Alfred Hoenes, Paul Hoffman, Benjamin Kaduk, Alexey Melnikov, Thomas Narten, and Ray Pelletier. </t> </section> <section numbered="true" toc="default"> <name>IAB members</name> <t> Internet Architecture Board Members at the time this document was approved for publication were [To Be Confirmed]: </t> <ul empty="true" spacing="compact"> <li>Jari Arkko,</li> <li>Alissa Cooper,</li> <li>Stephen Farrell</li> <li>Wes Hardaker</li> <li>Ted Hardie,</li> <li>Christian Huitema,</li> <li>Zhenbin Li</li> <li>Erik Nordmark,</li> <li>Mark Nottingham,</li> <li>Jeff Tantsura,</li> <li>Martin Thomson,</li> <li>Brian Trammell, and</li> </ul> </section> <section anchor="DED" numbered="true" toc="default"> <name>Document Editing Details</name> <t> [Text between square brackets starting with initials are editor notes. Any other text between square brackets assumes an action by the RFC editor prior to publication as an RFC. In most cases this will be removal, sometimes a stylistic or editorial choices ore question is indicated] </t> <t> [This section and its subsections should be removed at publication as RFC, so should the Cover Note] </t> <t> Some notes for the RFC Editor. </t> <ul> <li> <t> There are a few places where I've added a reference to <xref target="I-D.ietf-iasa2-rfc4071bis" format="default"/> mainly in places where I am not sure if we should assume prior knowledge from the reader. E.g. whether the Executive Director can be presumed to be a known term in the context of this document. Guidance is accepted. </t> <t> Editorial Issue: By using a referencegroup for BCP9 and BCP101 I seem to have lost to refer to specific RFCs within the reference group i.e. I have references to RFC6410 and RFC4371 specifically that I can't resolve because these are inside a reference group. I would like to retain the specific reference in the places where I use the RFC reference and the generic reference where I use the BCP reference. I presume the RFC editor can and will resolve this. </t> <t> There is a remaining '-' in order to get the organizational name (Internet Architecture Board) printed without any attributes in the author tag.<contact fullname="Scott Bradner"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="Leslie Daigle"/>, <contact fullname="Adrian Farrel"/>, <contact fullname="Bob Hinden"/>, <contact fullname="Alfred Hoenes"/>, <contact fullname="Paul Hoffman"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Alexey Melnikov"/>, <contact fullname="Thomas Narten"/>, and <contact fullname="Ray Pelletier"/>. </t></li> </ul> <section numbered="true" toc="default"> <name>Version Information</name> <section numbered="true" toc="default"> <name>draft-iab-iasa2-rfc6220-00</name> <ul empty="true" spacing="compact"> <li>Original RFC text back ported into XML. With only Editor affiliation changed and IAB members section emptied </li> </ul></section> <sectionnumbered="true" toc="default"> <name>draft-iab-iasa2-rfc6220-01</name> <ul spacing="compact"> <li>Changed references to IAOC to LLC </li> <li>While reviewing the section on the Trust: Modified reference to RFC 4748 to reference to RFC4371, as that document establishes the Trust while 4748 is technically an update of RFC 3978 (now obsoleted). </li> <li>Updated reference to ICANN-IETF MoU to most recent version (2018) <xref target="MoU_SUPP2019" format="default"/> . </li> </ul> </section> <section numbered="true" toc="default"> <name>draft-iab-iasa2-rfc6220-02</name> <ul spacing="compact"> <li> Standardized on "IETF LLC" as the sort version for the entity (per RFC style guide). </li> <li> Changed "At the request of the chair of the IETF, IAB, or LLC," to "At the request of the chair of the IETF or IAB, or the IETF Executive Director", in the same paragraph: The reporting of the registry operator does not necessarily need to take place in IETF Plenary, it may happen elsewhere. Text changed to reflect as much. </li> <li> BCP101 is a better reference than exclusively referring to RFC4371. The way the reference is provided needs RFC Editor attention. </li> <li> IDnits complained about rfc5226 being obsoleted. One of the rfc5226 references is used for historical context in the acknowledgement section, in other places it was replaced by 8126. </li> <li> IDnits complained about rfc5620 being obsoleted. The reference to 5620 is replaced by rfc6635bis-rfc editor model (not including rfc6548bis-independent rfc editor, as it just serves as an example and does not intend to describe the full RFC Editor universe). </li> <li> Updated the Acknowledgement section </li> </ul> </section> <section numbered="true" toc="default"> <name>draft-iab-iasa2-rfc6220-03</name> <ul spacing="compact"> <li> Changed reference for IASA2 structure to <xref target="I-D.ietf-iasa2-rfc4071bis" format="default"/> </li> </ul> </section> <section numbered="true" toc="default"> <name>draft-iab-iasa2-rfc6220-04</name> <ul spacing="compact"> <li> Migrated source from XML2RFC v2 to v3, which caused some changes in layout. </li> <li> Added obsoletion of 6220 sentence to Abstract and Introduction. </li> <li> <t> Changed reference in introduction from <xref target="RFC2026" format="default"/> to <xref target="BCP9" format="default"/>, cleaned up the reference to <xref target="BCP101" format="default"/> </t> </li> <li> In <xref target="protocolparamreg"/> changed: "Proposed, Draft, and full Internet Standards" to "Standard Track Documents <xref target="RFC6410" format="default"/>” </li> <li> upgraded reference to ICANN MOU to the 2019 version <xref target="MoU_SUPP2019" format="default"/>. </li> <li> In the paragraphs on IPR, just before <xref target="IABrole" format="default"/>, I clarifed that there may be circumstances where the vallues are not public. This to make the text consistent. </li> <li> Updated IAB membership. </li> </ul> </section> </section> <section numbered="true" toc="default"> <name>RCS information</name> <t> $Id: rfc6220bis.xml,v 1.10 2019/10/18 13:29:40 olaf Exp $ </t> </section>anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name> <author initials="D." surname="McPherson" fullname="Danny McPherson" role="editor"> <organization showOnFrontPage="true">Verisign, Inc.</organization> <address> <email>dmcpherson@verisign.com</email> </address> </author> <author initials="O." surname="Kolkman" fullname="Olaf Kolkman" role="editor"> <organization abbrev="ISOC" showOnFrontPage="true">Internet Society</organization> <address> <email>kolkman@isoc.org</email> </address> </author> <author initials="J." surname="Klensin" fullname="John C Klensin" role="editor"> <address> <email>john-ietf@jck.com</email> </address> </author> <author initials="G." surname="Huston" fullname="Geoff Huston" role="editor"> <organization showOnFrontPage="true">APNIC</organization> <address> <email>gih@apnic.net</email> </address> </author> </section><!--Version info--></back> </rfc>