<?xml version='1.0' encoding='utf-8'?><!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY RFC7437 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7437.xml"> <!ENTITY I-D.ietf-iasa2-rfc4071bis SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-iasa2-rfc4071bis-00.xml"> <!ENTITY RFC2850 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2850.xml"> <!ENTITY RFC2860 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2860.xml"> <!ENTITY RFC5226 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml"> <!ENTITY RFC6220 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6220.xml"> <!ENTITY RFC7020 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7020.xml"> <!ENTITY RFC7249 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7249.xml"> ]><rfcsubmissionType="IAB"xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info"consensus="yes" number="0000"consensus="true" docName="draft-iab-rfc7500-bis-00" indexInclude="true" ipr="trust200902" number="8720" obsoletes="7500"ipr="trust200902"> <!-- Generated by id2xml 1.5.0 on 2019-10-03T18:02:21Z --> <?rfc compact="yes"?> <?rfc text-list-symbols="o*+-"?> <?rfc subcompact="no"?> <?rfc sortrefs="yes"?> <?rfc symrefs="yes"?> <?rfc strict="yes"?> <!-- draft-iab-rfc7500-bis-00-manual.txt(2): Warning: The input document is named 'draft-iab-rfc7500-bis-00-manual.txt' but has an RFC stream type: 'Internet Architecture Board (IAB)' --><!-- draft-iab-rfc7500-bis-00-manual.txt(10): Warning: Expected an expires indication top left, found none --><?rfc toc="yes"?>prepTime="2020-02-26T17:10:42" scripts="Common,Latin" sortRefs="true" submissionType="IAB" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <link href="https://dx.doi.org/10.17487/rfc8720" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <link href="https://datatracker.ietf.org/doc/draft-iab-rfc7500-bis-00" rel="prev"/> <front> <title abbrev="Principles for Operation ofInternet Ass">PrinciplesIANA Registries">Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries</title> <seriesInfo name="RFC" value="8720" stream="IAB"/> <author fullname="Russ Housley" initials="R." role="editor" surname="Housley"> <organization showOnFrontPage="false" abbrev="Vigil Security">Vigil Security, LLC</organization><address><postal><street>918<address> <postal> <street>918 Spring Knoll Drive</street><street>Herndon, VA 20170</street> <street>USA</street><city>Herndon</city> <region>VA</region> <code>20170</code> <country>United States of America</country> </postal> <email>housley@vigilsec.com</email> </address> </author> <author fullname="Olaf Kolkman" initials="O." role="editor" surname="Kolkman"><organization>Internet<organization showOnFrontPage="false">Internet Society</organization><address><postal><street>Science<address> <postal> <street>Science Park 400</street><street>Amsterdam 1098 XH</street> <street>The Netherlands</street><city>Amsterdam</city> <code>1098 XH</code> <country>NL</country> </postal> <email>kolkman@isoc.org</email> </address> </author> <datemonth="October" year="2019"/> <abstract><t>month="02" year="2020"/> <keyword>IASA</keyword> <abstract pn="section-abstract"> <t pn="section-abstract-1"> This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.</t> </abstract> <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 to provide 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 RFC 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/rfc8720" 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 is subject 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-introduction">Introduction</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-principles-for-the-operatio">Principles for the Operation of IANA Registries</xref></t> </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-discussion">Discussion</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2"> <li pn="section-toc.1-1.3.2.1"> <t keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ensuring-uniqueness-stabili">Ensuring Uniqueness, Stability, and Predictability</xref></t> </li> <li pn="section-toc.1-1.3.2.2"> <t keepWithNext="true" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-public">Public</xref></t> </li> <li pn="section-toc.1-1.3.2.3"> <t keepWithNext="true" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-open-and-transparent">Open and Transparent</xref></t> </li> <li pn="section-toc.1-1.3.2.4"> <t keepWithNext="true" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-accountable">Accountable</xref></t> </li> </ul> </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-changes-since-rfc-7500">Changes since RFC 7500</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> <sectiontitle="Introduction" anchor="sect-1"><t>anchor="sect-1" numbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t pn="section-1-1"> The Internet Engineering Task Force (IETF) and its predecessors have traditionally separated the publication of protocol specifications in immutable Request for Comments (RFCs) and the registries containing protocol parameters. Traditionally, the registries are maintained by a set of functions known collectively as the Internet Assigned Numbers Authority (IANA). Dating back to the earliest days of the Internet, specification publication and the registry operations were tightly coupled: Jon Postel of the Information Sciences Institute (ISI) of the University of Southern California (USC) was responsible for both RFC publication and IANA registry operation. This tight coupling had advantages, but it was never a requirement. Indeed,todaytoday, the RFC Editor and IANA registry operation are provided by different entities.</t><t><t pn="section-1-2"> Internet registries are critical to the operation of theInternet,Internet because they provide a definitive record of the value and meaning of identifiers that protocols use when communicating with each other. Almost every Internet protocol makes use of registries in some form. At the time of writing, the IANA maintains more than two thousand protocol parameter registries.</t><t><t pn="section-1-3"> Internet registries hold protocol identifiers consisting of constants and other well-known values used by Internet protocols. These values can be numbers, strings, addresses, and so on. They are uniquely assigned for one particular purpose or use. Identifiers can be maintained in a central list (such as a list of cryptographicalgorithms)algorithms), or they can be hierarchically allocated and assigned by separate entities at different points in the hierarchy (such as IP addresses and domain names). To maximize trust and usefulness of the IANA registries, the principles in this document should be taken into consideration for centralized registries as well as hierarchically delegated registries. In hierarchically delegated registries, entries nearest to top level have broad scope, but lower-level entries have narrow scope. The Internet Architecture Board (IAB) will encourage support for these principles in all delegations of Internet identifiers.</t><t><t pn="section-1-4"> The registry system is built on trust and mutual cooperation. The use of the registries is voluntary and is not enforced by mandates or certification policies. While the use of registries is voluntary, it is noted that the success of the Internet creates enormous pressure to use Internet protocols and the identifier registries associated with them.</t><t><t pn="section-1-5"> This document provides principles for the operation of IANA registries, ensuring that protocol identifiers have consistent meanings and interpretations across all implementations and deployments,andthus providing the necessary trust in the IANA registries.</t> </section> <sectiontitle="Principlesanchor="sect-2" numbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-principles-for-the-operatio">Principles for the Operation of IANARegistries" anchor="sect-2"><t>Registries</name> <t pn="section-2-1"> The following key principles underscore the successful functioning of the IANA registries, and they provide a foundation for trust in those registries:</t><t><list style="hanging" hangIndent="6"> <t hangText="Ensure Uniqueness:"><dl newline="true" spacing="normal" pn="section-2-2"> <dt pn="section-2-2.1">Ensure Uniqueness:</dt> <dd pn="section-2-2.2"> The same protocol identifier must not be used for more than onepurpose.</t> <t hangText="Stable:">Protocolpurpose.</dd> <dt pn="section-2-2.3">Stable:</dt> <dd pn="section-2-2.4">Protocol identifier assignment must belasting.</t> <t hangText="Predictable:">Thelasting.</dd> <dt pn="section-2-2.5">Predictable:</dt> <dd pn="section-2-2.6">The process for making assignments must not include unexpected steps.</t> <t hangText="Public:"></dd> <dt pn="section-2-2.7">Public:</dt> <dd pn="section-2-2.8"> The protocol identifiers must be made available in well-known locations in a manner that makes them freely available to everyone.</t> <t hangText="Open:">The</dd> <dt pn="section-2-2.9">Open:</dt> <dd pn="section-2-2.10">The process that sets the policy for protocol identifier assignment and registration must be open to all interestedparties.</t> <t hangText="Transparent:">Theparties.</dd> <dt pn="section-2-2.11">Transparent:</dt> <dd pn="section-2-2.12">The protocol registries and their associated policies should be developed in a transparentmanner.</t> <t hangText="Accountable:">Registrymanner.</dd> <dt pn="section-2-2.13">Accountable:</dt> <dd pn="section-2-2.14">Registry policy development and registry operations need to be accountable to the affectedcommunity.</t> </list> </t>community.</dd> </dl> </section> <sectiontitle="Discussion" anchor="sect-3"><t>anchor="sect-3" numbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-discussion">Discussion</name> <t pn="section-3-1"> The principles discussed in <xreftarget="sect-2"/>target="sect-2" format="default" sectionFormat="of" derivedContent="Section 2"/> provide trust and confidence in the IANA registries. This section expands on these principles.</t> <sectiontitle="Ensuringanchor="sect-3.1" numbered="true" toc="include" removeInRFC="false" pn="section-3.1"> <name slugifiedName="name-ensuring-uniqueness-stabili">Ensuring Uniqueness, Stability, andPredictability" anchor="sect-3.1"><t>Predictability</name> <t pn="section-3.1-1"> Protocol identifier assignment and registration must be unique, stable, and predictable. Developers, vendors, customers, and users depend on the registries for unique protocol identifiers that are assigned in a stable and predictable manner.</t><t><t pn="section-3.1-2"> A protocol identifier may only be reassigned for a different purpose after due consideration of the impact of such areassignment, andreassignment and, if possible, with the consent of the original assignee.</t><t><t pn="section-3.1-3"> Recognizing that some assignments involve judgment, such as those involving a designated expert <xreftarget="RFC5226"/>,target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>, a predictable process does not require completion in a predetermined number of days. Rather, it means that no unexpected steps are introduced in the process of making an assignment.</t> </section> <sectiontitle="Public" anchor="sect-3.2"><t>anchor="sect-3.2" numbered="true" toc="include" removeInRFC="false" pn="section-3.2"> <name slugifiedName="name-public">Public</name> <t pn="section-3.2-1"> Once assigned, the protocol identifiers must be made available in a manner that makes them freely available to everyone without restrictions. The use of a consistent publication location builds confidence in the registry. This does not mean that the publication location can never change, but it does mean that it must change infrequently and only after adequate prior notice.</t> </section> <sectiontitle="Openanchor="sect-3.3" numbered="true" toc="include" removeInRFC="false" pn="section-3.3"> <name slugifiedName="name-open-and-transparent">Open andTransparent" anchor="sect-3.3"><t>Transparent</name> <t pn="section-3.3-1"> The process that sets the policy for protocol identifier assignment and registration must be open to all interested parties and must operate in a transparent manner.</t><t><t pn="section-3.3-2"> When a registry is established, a policy is set for the addition of new entries and the updating of existing entries. While making additions and modifications, the registry operator may expose instances where policies lack clarity. When this occurs, the registry operator should provide helpful feedback to allow those policies to be improved. In addition, the registry operator not being involved in establishing registry policy avoids the risks associated with (perceptions of) favoritism and unfairness.</t><t><t pn="section-3.3-3"> Recognizing that some assignments involve judgment, such as those involving a designated expert <xreftarget="RFC5226"/>,target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>, the recommendations by designated experts must be visible to the public to the maximum extent possible and subject to challenge or appeal.</t> </section> <sectiontitle="Accountable" anchor="sect-3.4"><t>anchor="sect-3.4" numbered="true" toc="include" removeInRFC="false" pn="section-3.4"> <name slugifiedName="name-accountable">Accountable</name> <t pn="section-3.4-1"> The process that sets the policy for IANA registries and the operation of the registries must be accountable to the parties that rely on the protocol identifiers. Oversight is needed to ensure these are properly serving the affected community.</t><t><t pn="section-3.4-2"> In practice, accountability mechanisms for the registry operator may be defined by a contract, memoranda of understanding, or service level agreements (SLAs). An oversight body uses these mechanisms to ensure that the registry operator is meeting the needs of the affected community. The oversight body is held accountable to the affected community by vastly differentmechanisms,mechanisms -- forinstanceinstance, recall and appeal processes.</t><t><t pn="section-3.4-3"> For protocol parameters <xreftarget="RFC6220"/>,target="RFC6220" format="default" sectionFormat="of" derivedContent="RFC6220"/>, the general oversight of the IANA function is performed by the IAB as a chartered responsibility from <xreftarget="RFC2850"/>.target="RFC2850" format="default" sectionFormat="of" derivedContent="RFC2850"/>. In addition, the IETF Administration Limited Liability Company (IETF LLC), as part of the IETF Administrative Support Activity (IASA), is responsible for IETF administrative and financial matters <xreftarget="I-D.ietf-iasa2-rfc4071bis"/>, and intarget="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>. In that role, the IETF LLC maintainsaan SLA with the current registry operator, the Internet Corporation for AssignednamesNames and Numbers (ICANN), thereby specifying the operational requirements with respect to the coordination, maintenance, and publication of the protocol parameter registries. Both the IAB and the Board of the IETF LLC are accountable to the larger Internet community and are being held accountable through the IETF NomCom process <xreftarget="BCP10"/>.</t> <t>target="RFC8713" format="default" sectionFormat="of" derivedContent="RFC8713"/>.</t> <t pn="section-3.4-4"> For the Internet Number Registries <xreftarget="RFC7249"/>,target="RFC7249" format="default" sectionFormat="of" derivedContent="RFC7249"/>, oversight is performed by the Regional Internet Registries (RIRs) as described RFC 7020 <xreftarget="RFC7020"/>.target="RFC7020" format="default" sectionFormat="of" derivedContent="RFC7020"/>. The RIRs are member-based organizations, and they are accountable to the affected community by elected governance boards. Furthermore, per agreement between the RIRs and ICANN, the policy development for the global IANA number registries is coordinated by a community-elected number council and subject to process review before ratification by the ICANN Board of Trustees <xreftarget="ASOMOU"/>.</t>target="ASOMOU" format="default" sectionFormat="of" derivedContent="ASOMOU"/>.</t> </section> </section> <sectiontitle="Security Considerations" anchor="sect-4"><t>anchor="sect-4" numbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t pn="section-4-1"> InternetRegistriesregistries are critical to elements of Internet security. The principles described in this document are necessary for the Internet community to place trust in the IANA registries.</t> </section> <sectiontitle="Changes Sinceanchor="sect-5" numbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-changes-since-rfc-7500">Changes since RFC7500" anchor="sect-5"><t>7500</name> <t pn="section-5-1"> <xreftarget="sect-3.4"/>target="sect-3.4" format="default" sectionFormat="of" derivedContent="Section 3.4"/> has been updated to align with the restructuring of the IETF Administrative Support Activity (IASA). Under the new structure, the IETF LLC maintainsaan SLA with the protocol parameter registry operator. Under the old structure, the SLA was maintained by the IETF Administrative Oversight Committee (IAOC).</t> </section> </middle> <back> <referencestitle="Informative References">pn="section-6"> <name slugifiedName="name-informative-references">Informative References</name> <reference anchor="ASOMOU"target="http://archive.icann.org/en/aso/aso-mou-29oct04.htm"><front> <title>ICANN Addresstarget="https://archive.icann.org/en/aso/aso-mou-29oct04.htm" quoteTitle="true" derivedAnchor="ASOMOU"> <front> <title>Address Supporting Organization (ASO) MoU</title> <author><organization>ICANN</organization><organization showOnFrontPage="true">ICANN</organization> </author> <date month="October" year="2004"/> </front> </reference> <referenceanchor="BCP10" target="http://www.rfc-editor.org/info/bcp10"><front> <title>IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operationanchor="RFC2850" target="https://www.rfc-editor.org/info/rfc2850" quoteTitle="true" derivedAnchor="RFC2850"> <front> <title>Charter of theNominating and Recall Committees</title>Internet Architecture Board (IAB)</title> <author> <organization showOnFrontPage="true">Internet Architecture Board</organization> </author> <authorfullname="M. Kucherawy" initials="M." surname="Kucherawy"initials="B." surname="Carpenter" fullname="B. Carpenter" role="editor"> <organization showOnFrontPage="true"/> </author> <datemonth="January" year="2015"/>year="2000" month="May"/> <abstract> <t>This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. 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="10"/>value="39"/> <seriesInfo name="RFC"value="7437"/>value="2850"/> <seriesInfo name="DOI" value="10.17487/RFC2850"/> </reference>&I-D.ietf-iasa2-rfc4071bis; &RFC2850; &RFC2860; &RFC5226; &RFC6220; &RFC7020; &RFC7249; </references> <section title="Members at<reference anchor="RFC6220" target="https://www.rfc-editor.org/info/rfc6220" quoteTitle="true" derivedAnchor="RFC6220"> <front> <title>Defining theTimeRole and Function ofApproval" anchor="sect-iab"><figure><artwork><![CDATA[ {{ RFC Editor: FillIETF Protocol Parameter Registry Operators</title> <author initials="D." surname="McPherson" fullname="D. McPherson" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="O." surname="Kolkman" fullname="O. Kolkman" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Klensin" fullname="J. Klensin" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="G." surname="Huston" fullname="G. Huston" role="editor"> <organization showOnFrontPage="true"/> </author> <author> <organization showOnFrontPage="true">Internet Architecture Board</organization> </author> <date year="2011" month="April"/> <abstract> <t>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 currentmembership. }} ]]></artwork> </figure>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 is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="6220"/> <seriesInfo name="DOI" value="10.17487/RFC6220"/> </reference> <reference anchor="RFC7020" target="https://www.rfc-editor.org/info/rfc7020" quoteTitle="true" derivedAnchor="RFC7020"> <front> <title>The Internet Numbers Registry System</title> <author initials="R." surname="Housley" fullname="R. Housley"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Curran" fullname="J. Curran"> <organization showOnFrontPage="true"/> </author> <author initials="G." surname="Huston" fullname="G. Huston"> <organization showOnFrontPage="true"/> </author> <author initials="D." surname="Conrad" fullname="D. Conrad"> <organization showOnFrontPage="true"/> </author> <date year="2013" month="August"/> <abstract> <t>This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers.</t> <t>This document also provides information about the processes for further evolution of the Internet Numbers Registry System.</t> <t>This document replaces RFC 2050.</t> <t>This document does not propose any changes to the current Internet Numbers Registry System. Rather, it documents the Internet Numbers Registry System as it works today.</t> </abstract> </front> <seriesInfo name="RFC" value="7020"/> <seriesInfo name="DOI" value="10.17487/RFC7020"/> </reference> <reference anchor="RFC7249" target="https://www.rfc-editor.org/info/rfc7249" quoteTitle="true" derivedAnchor="RFC7249"> <front> <title>Internet Numbers Registries</title> <author initials="R." surname="Housley" fullname="R. Housley"> <organization showOnFrontPage="true"/> </author> <date year="2014" month="May"/> <abstract> <t>RFC 7020 provides information about the Internet Numbers Registry System and how it is used in the distribution of autonomous system (AS) numbers and globally unique unicast Internet Protocol (IP) address space.</t> <t>This companion document identifies the IANA registries that are part of the Internet Numbers Registry System at this time.</t> </abstract> </front> <seriesInfo name="RFC" value="7249"/> <seriesInfo name="DOI" value="10.17487/RFC7249"/> </reference> <reference anchor="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 showOnFrontPage="true"/> </author> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization showOnFrontPage="true"/> </author> <author initials="T." surname="Narten" fullname="T. Narten"> <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> <reference 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" fullname="Brian Haberman"> <organization showOnFrontPage="true"/> </author> <author initials="J" surname="Hall" fullname="Joseph Hall"> <organization showOnFrontPage="true"/> </author> <author initials="J" surname="Livingood" fullname="Jason Livingood"> <organization showOnFrontPage="true"/> </author> <date month="February" year="2020"/> </front> <seriesInfo name="BCP" value="101"/> <seriesInfo name="RFC" value="8711"/> <seriesInfo name="DOI" value="10.17487/RFC8711"/> </reference> <reference anchor="RFC8713" target="https://www.rfc-editor.org/info/rfc8713" quoteTitle="true" derivedAnchor="RFC8713"> <front> <title>IAB, IESG, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees</title> <author initials="M." surname="Kucherawy" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Hinden" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Livingood" role="editor"> <organization showOnFrontPage="true"/> </author> <date month="February" year="2020"/> </front> <seriesInfo name="BCP" value="10"/> <seriesInfo name="RFC" value="8713"/> <seriesInfo name="DOI" value="10.17487/RFC8713"/> </reference> </references> <section anchor="sect-iab" 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> <ul spacing="compact" empty="true" bare="false" pn="section-appendix.a-1"> <li pn="section-appendix.a-1.1"> <t pn="section-appendix.a-1.1.1"><contact fullname="Jari Arkko"/></t> </li> <li pn="section-appendix.a-1.2"> <t pn="section-appendix.a-1.2.1"><contact fullname="Alissa Cooper"/></t> </li> <li pn="section-appendix.a-1.3"> <t pn="section-appendix.a-1.3.1"><contact fullname="Stephen Farrell"/></t> </li> <li pn="section-appendix.a-1.4"> <t pn="section-appendix.a-1.4.1"><contact fullname="Wes Hardaker"/></t> </li> <li pn="section-appendix.a-1.5"> <t pn="section-appendix.a-1.5.1"><contact fullname="Ted Hardie"/></t> </li> <li pn="section-appendix.a-1.6"> <t pn="section-appendix.a-1.6.1"><contact fullname="Christian Huitema"/></t> </li> <li pn="section-appendix.a-1.7"> <t pn="section-appendix.a-1.7.1"><contact fullname="Zhenbin Li"/></t> </li> <li pn="section-appendix.a-1.8"> <t pn="section-appendix.a-1.8.1"><contact fullname="Erik Nordmark"/></t> </li> <li pn="section-appendix.a-1.9"> <t pn="section-appendix.a-1.9.1"><contact fullname="Mark Nottingham"/></t> </li> <li pn="section-appendix.a-1.10"> <t pn="section-appendix.a-1.10.1"><contact fullname="Melinda Shore"/></t> </li> <li pn="section-appendix.a-1.11"> <t pn="section-appendix.a-1.11.1"><contact fullname="Jeff Tantsura"/></t> </li> <li pn="section-appendix.a-1.12"> <t pn="section-appendix.a-1.12.1"><contact fullname="Martin Thomson"/></t> </li> <li pn="section-appendix.a-1.13"> <t pn="section-appendix.a-1.13.1"><contact fullname="Brian Trammell"/></t> </li> </ul> </section> <sectiontitle="Contributors and Acknowledgements" numbered="no" anchor="contributors-and-acknowledgements"><t>numbered="false" anchor="acknowledgements" toc="include" removeInRFC="false" pn="section-appendix.b"> <name slugifiedName="name-acknowledgements">Acknowledgements</name> <t pn="section-appendix.b-1"> This text has been developed within the IAB IANA Evolution Program. The ideas and many textfragments,fragments and corrections came from or were inspiredonby comments from:Bernard Aboba, Jaap Akkerhuis, Jari Arkko, Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Steve Crocker, John Curran, Alissa Cooper, Leslie Daigle, Elise Gerich, John Klensin, Bertrand<contact fullname="Bernard Aboba"/>, <contact fullname="Jaap Akkerhuis"/>, <contact fullname="Jari Arkko"/>, <contact fullname="Marcelo Bagnulo"/>, <contact fullname="Mark Blanchet"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="David Conrad"/>, <contact fullname="Alissa Cooper"/>, <contact fullname="Steve Crocker"/>, <contact fullname="John Curran"/>, <contact fullname="Leslie Daigle"/>, <contact fullname="Elise Gerich"/>, <contact fullname="John Klensin"/>, <contact fullname="Bertrand de LaChapelle, Eliot Lear, Danny McPherson, George Michaelson, Thomas Narten, Andrei Robachevsky, Andrew Sullivan, Dave Thaler, Brian Trammell, and Greg Wood.Chapelle"/>, <contact fullname="Eliot Lear"/>, <contact fullname="Danny McPherson"/>, <contact fullname="George Michaelson"/>, <contact fullname="Thomas Narten"/>, <contact fullname="Andrei Robachevsky"/>, <contact fullname="Andrew Sullivan"/>, <contact fullname="Dave Thaler"/>, <contact fullname="Brian Trammell"/>, and <contact fullname="Greg Wood"/>. Further inspiration and input was drawn from various meetings withIETF and otherthe leadership of the Internetcommunity (RIRs,community, i.e., from the RIRs, ISOC, W3C, IETF, andIAB) leadership.</t> <t>IAB. </t> <t pn="section-appendix.b-2"> Please do not assume those acknowledged endorse the resulting text.</t> </section> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name> <author fullname="Russ Housley" initials="R." role="editor" surname="Housley"> <organization showOnFrontPage="false" abbrev="Vigil Security">Vigil Security, LLC</organization> <address> <postal> <street>918 Spring Knoll Drive</street> <city>Herndon</city> <region>VA</region> <code>20170</code> <country>United States of America</country> </postal> <email>housley@vigilsec.com</email> </address> </author> <author fullname="Olaf Kolkman" initials="O." role="editor" surname="Kolkman"> <organization showOnFrontPage="false">Internet Society</organization> <address> <postal> <street>Science Park 400</street> <city>Amsterdam</city> <code>1098 XH</code> <country>NL</country> </postal> <email>kolkman@isoc.org</email> </address> </author> </section> </back> </rfc>