rfc8720xml2.original.xml		rfc8720.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" cons
	<!ENTITY RFC7437 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF		ensus="true" docName="draft-iab-rfc7500-bis-00" indexInclude="true" ipr="trust20
	C.7437.xml">		0902" number="8720" obsoletes="7500" prepTime="2020-02-26T17:10:42" scripts="Com
	<!ENTITY I-D.ietf-iasa2-rfc4071bis SYSTEM "https://xml2rfc.ietf.org/public/rfc/b		mon,Latin" sortRefs="true" submissionType="IAB" symRefs="true" tocDepth="3" tocI
	ibxml3/reference.I-D.draft-ietf-iasa2-rfc4071bis-00.xml">		nclude="true" xml:lang="en">
	<!ENTITY RFC2850 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF		<link href="https://dx.doi.org/10.17487/rfc8720" rel="alternate"/>
	C.2850.xml">		<link href="urn:issn:2070-1721" rel="alternate"/>
	<!ENTITY RFC2860 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF		<link href="https://datatracker.ietf.org/doc/draft-iab-rfc7500-bis-00" rel="pr
	C.2860.xml">		ev"/>
	<!ENTITY RFC5226 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF		<front>
	C.5226.xml">		<title abbrev="Principles for Operation of IANA Registries">Principles for O
	<!ENTITY RFC6220 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF		peration of Internet Assigned Numbers Authority (IANA) Registries</title>
	C.6220.xml">		<seriesInfo name="RFC" value="8720" stream="IAB"/>
	<!ENTITY RFC7020 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF		<author fullname="Russ Housley" initials="R." role="editor" surname="Housley
	C.7020.xml">		">
	<!ENTITY RFC7249 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF		<organization showOnFrontPage="false" abbrev="Vigil Security">Vigil Securi
	C.7249.xml">		ty, LLC</organization>
	]>		<address>
	<rfc submissionType="IAB" category="info" consensus="yes" number="0000" docName=		<postal>
	"draft-iab-rfc7500-bis-00" obsoletes="7500" ipr="trust200902">		<street>918 Spring Knoll Drive</street>
	<!-- Generated by id2xml 1.5.0 on 2019-10-03T18:02:21Z -->		<city>Herndon</city>
	<?rfc compact="yes"?>		<region>VA</region>
	<?rfc text-list-symbols="o*+-"?>		<code>20170</code>
	<?rfc subcompact="no"?>		<country>United States of America</country>
	<?rfc sortrefs="yes"?>		</postal>
	<?rfc symrefs="yes"?>		<email>housley@vigilsec.com</email>
	<?rfc strict="yes"?>		</address>
	<!--		</author>
	draft-iab-rfc7500-bis-00-manual.txt(2): Warning: The input document is named		<author fullname="Olaf Kolkman" initials="O." role="editor" surname="Kolkman
	'draft-iab-rfc7500-bis-00-manual.txt' but has an RFC stream type:		">
	'Internet Architecture Board (IAB)'		<organization showOnFrontPage="false">Internet Society</organization>
	--><!--		<address>
	draft-iab-rfc7500-bis-00-manual.txt(10): Warning: Expected an expires indicat		<postal>
	ion		<street>Science Park 400</street>
	top left, found none		<city>Amsterdam</city>
	--><?rfc toc="yes"?>		<code>1098 XH</code>
	<front>		<country>NL</country>
	<title abbrev="Principles for Operation of Internet Ass">Principles for O		</postal>
	peration of Internet Assigned Numbers Authority (IANA) Registries</title>		<email>kolkman@isoc.org</email>
	<author fullname="Russ Housley" initials="R." role="editor" surname="Hous		</address>
	ley">		</author>
	<organization abbrev="Vigil Security">Vigil Security, LLC</organization>		<date month="02" year="2020"/>
	<address><postal><street>918 Spring Knoll Drive</street>		<keyword>IASA</keyword>
	<street>Herndon, VA 20170</street>		<abstract pn="section-abstract">
	<street>USA</street>		<t pn="section-abstract-1">
	</postal>
	<email>housley@vigilsec.com</email>
	</address>
	</author>
	<author fullname="Olaf Kolkman" initials="O." role="editor" surname="Kolk
	man">
	<organization>Internet Society</organization>
	<address><postal><street>Science Park 400</street>
	<street>Amsterdam 1098 XH</street>
	<street>The Netherlands</street>
	</postal>
	<email>kolkman@isoc.org</email>
	</address>
	</author>
	<date month="October" year="2019"/>
	<abstract><t>
	This document provides principles for the operation of Internet		This document provides principles for the operation of Internet
	Assigned Numbers Authority (IANA) registries.</t>		Assigned Numbers Authority (IANA) registries.</t>
			</abstract>
	</abstract>		<boilerplate>
	</front>		<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
			"exclude" pn="section-boilerplate.1">
	<middle>		<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
	<section title="Introduction" anchor="sect-1"><t>		>
			<t pn="section-boilerplate.1-1">
			This document is not an Internet Standards Track specification; it i
			s
			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; se
			e
			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="non
			e"/>.
			</t>
			</section>
			<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
			ude" 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" p
			n="section-toc.1">
			<name slugifiedName="name-table-of-contents">Table of Contents</name>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
			c.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 derivedCon
			tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
			n</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 derivedCon
			tent="" format="title" sectionFormat="of" target="name-principles-for-the-operat
			io">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 derivedCon
			tent="" format="title" sectionFormat="of" target="name-discussion">Discussion</x
			ref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-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 derive
			dContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-ensuring-uniq
			ueness-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 derive
			dContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-public">Publi
			c</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 derive
			dContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-open-and-tran
			sparent">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 derive
			dContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xre
			f 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 derivedCon
			tent="" 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 derivedCon
			tent="" format="title" sectionFormat="of" target="name-changes-since-rfc-7500">C
			hanges 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 derivedCon
			tent="" format="title" sectionFormat="of" target="name-informative-references">I
			nformative 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 derivedC
			ontent="" 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 derivedC
			ontent="" format="title" sectionFormat="of" target="name-acknowledgements">Ackno
			wledgements</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 derivedC
			ontent="" format="title" sectionFormat="of" target="name-authors-addresses">Auth
			ors' Addresses</xref></t>
			</li>
			</ul>
			</section>
			</toc>
			</front>
			<middle>
			<section anchor="sect-1" numbered="true" toc="include" removeInRFC="false" p
			n="section-1">
			<name slugifiedName="name-introduction">Introduction</name>
			<t pn="section-1-1">
	The Internet Engineering Task Force (IETF) and its predecessors have		The Internet Engineering Task Force (IETF) and its predecessors have
	traditionally separated the publication of protocol specifications in		traditionally separated the publication of protocol specifications in
	immutable Request for Comments (RFCs) and the registries containing		immutable Request for Comments (RFCs) and the registries containing
	protocol parameters. Traditionally, the registries are maintained by		protocol parameters. Traditionally, the registries are maintained by
	a set of functions known collectively as the Internet Assigned		a set of functions known collectively as the Internet Assigned
	Numbers Authority (IANA). Dating back to the earliest days of the		Numbers Authority (IANA). Dating back to the earliest days of the
	Internet, specification publication and the registry operations were		Internet, specification publication and the registry operations were
	tightly coupled: Jon Postel of the Information Sciences Institute		tightly coupled: Jon Postel of the Information Sciences Institute
	(ISI) of the University of Southern California (USC) was responsible		(ISI) of the University of Southern California (USC) was responsible
	for both RFC publication and IANA registry operation. This tight		for both RFC publication and IANA registry operation. This tight
	coupling had advantages, but it was never a requirement. Indeed,		coupling had advantages, but it was never a requirement. Indeed,
	today the RFC Editor and IANA registry operation are provided by		today, the RFC Editor and IANA registry operation are provided by
	different entities.</t>		different entities.</t>
			<t pn="section-1-2">
	<t>		Internet registries are critical to the operation of the Internet
	Internet registries are critical to the operation of the Internet,
	because they provide a definitive record of the value and meaning of		because they provide a definitive record of the value and meaning of
	identifiers that protocols use when communicating with each other.		identifiers that protocols use when communicating with each other.
	Almost every Internet protocol makes use of registries in some form.		Almost every Internet protocol makes use of registries in some form.
	At the time of writing, the IANA maintains more than two thousand		At the time of writing, the IANA maintains more than two thousand
	protocol parameter registries.</t>		protocol parameter registries.</t>
			<t pn="section-1-3">
	<t>
	Internet registries hold protocol identifiers consisting of constants		Internet registries hold protocol identifiers consisting of constants
	and other well-known values used by Internet protocols. These values		and other well-known values used by Internet protocols. These values
	can be numbers, strings, addresses, and so on. They are uniquely		can be numbers, strings, addresses, and so on. They are uniquely
	assigned for one particular purpose or use. Identifiers can be		assigned for one particular purpose or use. Identifiers can be
	maintained in a central list (such as a list of cryptographic		maintained in a central list (such as a list of cryptographic
	algorithms) or they can be hierarchically allocated and assigned by		algorithms), or they can be hierarchically allocated and assigned by
	separate entities at different points in the hierarchy (such as IP		separate entities at different points in the hierarchy (such as IP
	addresses and domain names). To maximize trust and usefulness of the		addresses and domain names). To maximize trust and usefulness of the
	IANA registries, the principles in this document should be taken into		IANA registries, the principles in this document should be taken into
	consideration for centralized registries as well as hierarchically		consideration for centralized registries as well as hierarchically
	delegated registries. In hierarchically delegated registries,		delegated registries. In hierarchically delegated registries,
	entries nearest to top level have broad scope, but lower-level		entries nearest to top level have broad scope, but lower-level
	entries have narrow scope. The Internet Architecture Board (IAB)		entries have narrow scope. The Internet Architecture Board (IAB)
	will encourage support for these principles in all delegations of		will encourage support for these principles in all delegations of
	Internet identifiers.</t>		Internet identifiers.</t>
			<t pn="section-1-4">
	<t>
	The registry system is built on trust and mutual cooperation. The		The registry system is built on trust and mutual cooperation. The
	use of the registries is voluntary and is not enforced by mandates or		use of the registries is voluntary and is not enforced by mandates or
	certification policies. While the use of registries is voluntary, it		certification policies. While the use of registries is voluntary, it
	is noted that the success of the Internet creates enormous pressure		is noted that the success of the Internet creates enormous pressure
	to use Internet protocols and the identifier registries associated		to use Internet protocols and the identifier registries associated
	with them.</t>		with them.</t>
			<t pn="section-1-5">
	<t>
	This document provides principles for the operation of IANA		This document provides principles for the operation of IANA
	registries, ensuring that protocol identifiers have consistent		registries, ensuring that protocol identifiers have consistent
	meanings and interpretations across all implementations and		meanings and interpretations across all implementations and
	deployments, and thus providing the necessary trust in the IANA		deployments, thus providing the necessary trust in the IANA
	registries.</t>		registries.</t>
			</section>
	</section>		<section anchor="sect-2" numbered="true" toc="include" removeInRFC="false" p
			n="section-2">
	<section title="Principles for the Operation of IANA Registries" anchor="		<name slugifiedName="name-principles-for-the-operatio">Principles for the
	sect-2"><t>		Operation of IANA Registries</name>
			<t pn="section-2-1">
	The following key principles underscore the successful functioning of		The following key principles underscore the successful functioning of
	the IANA registries, and they provide a foundation for trust in those		the IANA registries, and they provide a foundation for trust in those
	registries:</t>		registries:</t>
			<dl newline="true" spacing="normal" pn="section-2-2">
	<t><list style="hanging" hangIndent="6">		<dt pn="section-2-2.1">Ensure Uniqueness:</dt>
	<t hangText="Ensure Uniqueness:"> The same protocol identifier must not be		<dd pn="section-2-2.2"> The same protocol identifier must not be
	used for more than one purpose.</t>		used for more than one purpose.</dd>
			<dt pn="section-2-2.3">Stable:</dt>
	<t hangText="Stable:">Protocol identifier assignment must be lasting.</t>		<dd pn="section-2-2.4">Protocol identifier assignment must be lasting.</
			dd>
	<t hangText="Predictable:">The process for making assignments must not		<dt pn="section-2-2.5">Predictable:</dt>
	include unexpected steps. </t>		<dd pn="section-2-2.6">The process for making assignments must not
			include unexpected steps. </dd>
	<t hangText="Public:"> The protocol identifiers must be made available		<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		in well-known locations in a manner that makes them freely available
	to everyone. </t>		to everyone. </dd>
			<dt pn="section-2-2.9">Open:</dt>
	<t hangText="Open:">The process that sets the policy for protocol		<dd pn="section-2-2.10">The process that sets the policy for protocol
	identifier assignment and registration must be open to all interested		identifier assignment and registration must be open to all interested
	parties.</t>		parties.</dd>
			<dt pn="section-2-2.11">Transparent:</dt>
	<t hangText="Transparent:">The protocol registries and their		<dd pn="section-2-2.12">The protocol registries and their
	associated policies should be developed in a transparent manner.</t>		associated policies should be developed in a transparent manner.</dd>
			<dt pn="section-2-2.13">Accountable:</dt>
	<t hangText="Accountable:">Registry policy development and registry		<dd pn="section-2-2.14">Registry policy development and registry
	operations need to be accountable to the affected community.</t>		operations need to be accountable to the affected community.</dd>
			</dl>
	</list>		</section>
	</t>		<section anchor="sect-3" numbered="true" toc="include" removeInRFC="false" p
			n="section-3">
	</section>		<name slugifiedName="name-discussion">Discussion</name>
			<t pn="section-3-1">
	<section title="Discussion" anchor="sect-3"><t>		The principles discussed in <xref target="sect-2" format="default" sectionFor
	The principles discussed in <xref target="sect-2"/> provide trust and confide		mat="of" derivedContent="Section 2"/> provide trust and confidence in
	nce in
	the IANA registries. This section expands on these principles.</t>		the IANA registries. This section expands on these principles.</t>
			<section anchor="sect-3.1" numbered="true" toc="include" removeInRFC="fals
	<section title="Ensuring Uniqueness, Stability, and Predictability" ancho		e" pn="section-3.1">
	r="sect-3.1"><t>		<name slugifiedName="name-ensuring-uniqueness-stabili">Ensuring Uniquene
			ss, Stability, and Predictability</name>
			<t pn="section-3.1-1">
	Protocol identifier assignment and registration must be unique,		Protocol identifier assignment and registration must be unique,
	stable, and predictable. Developers, vendors, customers, and users		stable, and predictable. Developers, vendors, customers, and users
	depend on the registries for unique protocol identifiers that are		depend on the registries for unique protocol identifiers that are
	assigned in a stable and predictable manner.</t>		assigned in a stable and predictable manner.</t>
			<t pn="section-3.1-2">
	<t>
	A protocol identifier may only be reassigned for a different purpose		A protocol identifier may only be reassigned for a different purpose
	after due consideration of the impact of such a reassignment, and if		after due consideration of the impact of such a reassignment and, if
	possible, with the consent of the original assignee.</t>		possible, with the consent of the original assignee.</t>
			<t pn="section-3.1-3">
	<t>
	Recognizing that some assignments involve judgment, such as those		Recognizing that some assignments involve judgment, such as those
	involving a designated expert <xref target="RFC5226"/>, a predictable process does		involving a designated expert <xref target="RFC8126" format="default" section Format="of" derivedContent="RFC8126"/>, a predictable process does
	not require completion in a predetermined number of days. Rather, it		not require completion in a predetermined number of days. Rather, it
	means that no unexpected steps are introduced in the process of		means that no unexpected steps are introduced in the process of
	making an assignment.</t>		making an assignment.</t>
			</section>
	</section>		<section anchor="sect-3.2" numbered="true" toc="include" removeInRFC="fals
			e" pn="section-3.2">
	<section title="Public" anchor="sect-3.2"><t>		<name slugifiedName="name-public">Public</name>
			<t pn="section-3.2-1">
	Once assigned, the protocol identifiers must be made available in a		Once assigned, the protocol identifiers must be made available in a
	manner that makes them freely available to everyone without		manner that makes them freely available to everyone without
	restrictions. The use of a consistent publication location builds		restrictions. The use of a consistent publication location builds
	confidence in the registry. This does not mean that the publication		confidence in the registry. This does not mean that the publication
	location can never change, but it does mean that it must change		location can never change, but it does mean that it must change
	infrequently and only after adequate prior notice.</t>		infrequently and only after adequate prior notice.</t>
			</section>
	</section>		<section anchor="sect-3.3" numbered="true" toc="include" removeInRFC="fals
			e" pn="section-3.3">
	<section title="Open and Transparent" anchor="sect-3.3"><t>		<name slugifiedName="name-open-and-transparent">Open and Transparent</na
			me>
			<t pn="section-3.3-1">
	The process that sets the policy for protocol identifier assignment		The process that sets the policy for protocol identifier assignment
	and registration must be open to all interested parties and operate		and registration must be open to all interested parties and must operate
	in a transparent manner.</t>		in a transparent manner.</t>
			<t pn="section-3.3-2">
	<t>
	When a registry is established, a policy is set for the addition of		When a registry is established, a policy is set for the addition of
	new entries and the updating of existing entries. While making		new entries and the updating of existing entries. While making
	additions and modifications, the registry operator may expose		additions and modifications, the registry operator may expose
	instances where policies lack clarity. When this occurs, the		instances where policies lack clarity. When this occurs, the
	registry operator should provide helpful feedback to allow those		registry operator should provide helpful feedback to allow those
	policies to be improved. In addition, the registry operator not		policies to be improved. In addition, the registry operator not
	being involved in establishing registry policy avoids the risks		being involved in establishing registry policy avoids the risks
	associated with (perceptions of) favoritism and unfairness.</t>		associated with (perceptions of) favoritism and unfairness.</t>
			<t pn="section-3.3-3">
	<t>
	Recognizing that some assignments involve judgment, such as those		Recognizing that some assignments involve judgment, such as those
	involving a designated expert <xref target="RFC5226"/>, the recommendations b y		involving a designated expert <xref target="RFC8126" format="default" section Format="of" derivedContent="RFC8126"/>, the recommendations by
	designated experts must be visible to the public to the maximum		designated experts must be visible to the public to the maximum
	extent possible and subject to challenge or appeal.</t>		extent possible and subject to challenge or appeal.</t>
			</section>
	</section>		<section anchor="sect-3.4" numbered="true" toc="include" removeInRFC="fals
			e" pn="section-3.4">
	<section title="Accountable" anchor="sect-3.4"><t>		<name slugifiedName="name-accountable">Accountable</name>
			<t pn="section-3.4-1">
	The process that sets the policy for IANA registries and the		The process that sets the policy for IANA registries and the
	operation of the registries must be accountable to the parties that		operation of the registries must be accountable to the parties that
	rely on the protocol identifiers. Oversight is needed to ensure		rely on the protocol identifiers. Oversight is needed to ensure
	these are properly serving the affected community.</t>		these are properly serving the affected community.</t>
			<t pn="section-3.4-2">
	<t>
	In practice, accountability mechanisms for the registry operator may		In practice, accountability mechanisms for the registry operator may
	be defined by contract, memoranda of understanding, or service level		be defined by a contract, memoranda of understanding, or service level
	agreements (SLAs). An oversight body uses these mechanisms to ensure		agreements (SLAs). An oversight body uses these mechanisms to ensure
	that the registry operator is meeting the needs of the affected		that the registry operator is meeting the needs of the affected
	community. The oversight body is held accountable to the affected		community. The oversight body is held accountable to the affected
	community by vastly different mechanisms, for instance recall and		community by vastly different mechanisms -- for instance, recall and
	appeal processes.</t>		appeal processes.</t>
			<t pn="section-3.4-3">
	<t>		For protocol parameters <xref target="RFC6220" format="default" sectionFormat
	For protocol parameters <xref target="RFC6220"/>, the general oversight of th		="of" derivedContent="RFC6220"/>, the general oversight of the IANA
	e IANA
	function is performed by the IAB as a chartered responsibility from		function is performed by the IAB as a chartered responsibility from
	<xref target="RFC2850"/>. In addition, the IETF Administration Limited Liabi lity		<xref target="RFC2850" format="default" sectionFormat="of" derivedContent="RF C2850"/>. In addition, the IETF Administration Limited Liability
	Company (IETF LLC), as part of the IETF Administrative Support		Company (IETF LLC), as part of the IETF Administrative Support
	Activity (IASA), is responsible for IETF administrative and financial		Activity (IASA), is responsible for IETF administrative and financial
	matters <xref target="I-D.ietf-iasa2-rfc4071bis"/>, and in that role, the IET		matters <xref target="RFC8711" format="default" sectionFormat="of" derivedCon
	F LLC		tent="RFC8711"/>. In that role, the IETF LLC
	maintains a SLA with the current registry operator, the Internet		maintains an SLA with the current registry operator, the Internet
	Corporation for Assigned names and Numbers (ICANN), thereby		Corporation for Assigned Names and Numbers (ICANN), thereby
	specifying the operational requirements with respect to the		specifying the operational requirements with respect to the
	coordination, maintenance, and publication of the protocol parameter		coordination, maintenance, and publication of the protocol parameter
	registries. Both the IAB and the Board of the IETF LLC are		registries. Both the IAB and the Board of the IETF LLC are
	accountable to the larger Internet community and are being held		accountable to the larger Internet community and are being held
	accountable through the IETF NomCom process <xref target="BCP10"/>.</t>		accountable through the IETF NomCom process <xref target="RFC8713" format="de
			fault" sectionFormat="of" derivedContent="RFC8713"/>.</t>
	<t>		<t pn="section-3.4-4">
	For the Internet Number Registries <xref target="RFC7249"/>, oversight is per		For the Internet Number Registries <xref target="RFC7249" format="default" se
	formed		ctionFormat="of" derivedContent="RFC7249"/>, oversight is performed
	by the Regional Internet Registries (RIRs) as described RFC 7020		by the Regional Internet Registries (RIRs) as described RFC 7020
	<xref target="RFC7020"/>. The RIRs are member-based organizations, and they are		<xref target="RFC7020" format="default" sectionFormat="of" derivedContent="RF C7020"/>. The RIRs are member-based organizations, and they are
	accountable to the affected community by elected governance boards.		accountable to the affected community by elected governance boards.
	Furthermore, per agreement between the RIRs and ICANN, the policy		Furthermore, per agreement between the RIRs and ICANN, the policy
	development for the global IANA number registries is coordinated by a		development for the global IANA number registries is coordinated by a
	community-elected number council and subject to process review before		community-elected number council and subject to process review before
	ratification by the ICANN Board of Trustees <xref target="ASOMOU"/>.</t>		ratification by the ICANN Board of Trustees <xref target="ASOMOU" format="def
			ault" sectionFormat="of" derivedContent="ASOMOU"/>.</t>
	</section>		</section>
			</section>
	</section>		<section anchor="sect-4" numbered="true" toc="include" removeInRFC="false" p
			n="section-4">
	<section title="Security Considerations" anchor="sect-4"><t>		<name slugifiedName="name-security-considerations">Security Considerations
	Internet Registries are critical to elements of Internet security.		</name>
			<t pn="section-4-1">
			Internet registries are critical to elements of Internet security.
	The principles described in this document are necessary for the		The principles described in this document are necessary for the
	Internet community to place trust in the IANA registries.</t>		Internet community to place trust in the IANA registries.</t>
			</section>
	</section>		<section anchor="sect-5" numbered="true" toc="include" removeInRFC="false" p
			n="section-5">
	<section title="Changes Since RFC 7500" anchor="sect-5"><t>		<name slugifiedName="name-changes-since-rfc-7500">Changes since RFC 7500</
	<xref target="sect-3.4"/> has been updated to align with the restructuring of		name>
	the		<t pn="section-5-1">
			<xref target="sect-3.4" format="default" sectionFormat="of" derivedContent="S
			ection 3.4"/> has been updated to align with the restructuring of the
	IETF Administrative Support Activity (IASA). Under the new		IETF Administrative Support Activity (IASA). Under the new
	structure, the IETF LLC maintains a SLA with the protocol parameter		structure, the IETF LLC maintains an SLA with the protocol parameter
	registry operator. Under the old structure, the SLA was maintained		registry operator. Under the old structure, the SLA was maintained
	by the IETF Administrative Oversight Committee (IAOC).</t>		by the IETF Administrative Oversight Committee (IAOC).</t>
			</section>
	</section>		</middle>
			<back>
	</middle>		<references pn="section-6">
			<name slugifiedName="name-informative-references">Informative References</
	<back>		name>
	<references title="Informative References">		<reference anchor="ASOMOU" target="https://archive.icann.org/en/aso/aso-mo
	<reference anchor="ASOMOU" target="http://archive.icann.org/en/aso/aso-mo		u-29oct04.htm" quoteTitle="true" derivedAnchor="ASOMOU">
	u-29oct04.htm"><front>		<front>
	<title>ICANN Address Supporting Organization (ASO) MoU</title>		<title>Address Supporting Organization (ASO) MoU</title>
	<author>		<author>
	<organization>ICANN</organization>		<organization showOnFrontPage="true">ICANN</organization>
	</author>		</author>
			<date month="October" year="2004"/>
	<date month="October" year="2004"/>		</front>
	</front>		</reference>
			<reference anchor="RFC2850" target="https://www.rfc-editor.org/info/rfc285
	</reference>		0" quoteTitle="true" derivedAnchor="RFC2850">
	<reference anchor="BCP10" target="http://www.rfc-editor.org/info/bcp10"><		<front>
	front>		<title>Charter of the Internet Architecture Board (IAB)</title>
	<title>IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: O		<author>
	peration of the Nominating and Recall Committees</title>		<organization showOnFrontPage="true">Internet Architecture Board</or
	<author fullname="M. Kucherawy" initials="M." surname="Kucherawy" role="e		ganization>
	ditor">		</author>
	</author>		<author initials="B." surname="Carpenter" fullname="B. Carpenter" role
			="editor">
	<date month="January" year="2015"/>		<organization showOnFrontPage="true"/>
	</front>		</author>
			<date year="2000" month="May"/>
	<seriesInfo name="BCP" value="10"/>		<abstract>
	<seriesInfo name="RFC" value="7437"/>		<t>This memo documents the composition, selection, roles, and organi
	</reference>		zation of the Internet Architecture Board. It replaces RFC 1601. This document
	&I-D.ietf-iasa2-rfc4071bis;		specifies an Internet Best Current Practices for the Internet Community, and re
	&RFC2850;		quests discussion and suggestions for improvements.</t>
	&RFC2860;		</abstract>
	&RFC5226;		</front>
	&RFC6220;		<seriesInfo name="BCP" value="39"/>
	&RFC7020;		<seriesInfo name="RFC" value="2850"/>
	&RFC7249;		<seriesInfo name="DOI" value="10.17487/RFC2850"/>
	</references>		</reference>
	<section title="Members at the Time of Approval" anchor="sect-iab"><figur		<reference anchor="RFC6220" target="https://www.rfc-editor.org/info/rfc622
	e><artwork><![CDATA[		0" quoteTitle="true" derivedAnchor="RFC6220">
	{{ RFC Editor: Fill in the current membership. }}		<front>
	]]></artwork>		<title>Defining the Role and Function of IETF Protocol Parameter Regis
	</figure>		try Operators</title>
	</section>		<author initials="D." surname="McPherson" fullname="D. McPherson" role
			="editor">
	<section title="Contributors and Acknowledgements" numbered="no" anchor="		<organization showOnFrontPage="true"/>
	contributors-and-acknowledgements"><t>		</author>
			<author initials="O." surname="Kolkman" fullname="O. Kolkman" role="ed
			itor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Klensin" fullname="J. Klensin" role="ed
			itor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="G." surname="Huston" fullname="G. Huston" role="edit
			or">
			<organization showOnFrontPage="true"/>
			</author>
			<author>
			<organization showOnFrontPage="true">Internet Architecture Board</or
			ganization>
			</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 cons
			istent 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 paramete
			r values and their associated semantic intentions. For each IETF protocol param
			eter, it is current practice for the IETF to delegate the role of Protocol Param
			eter Registry Operator to a nominated entity. This document provides a descript
			ion of, and the requirements for, these delegated functions. This document is n
			ot 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/rfc702
			0" 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 Num
			bers Registry System used in the distribution of globally unique Internet Protoc
			ol (IP) address space and autonomous system (AS) numbers.</t>
			<t>This document also provides information about the processes for f
			urther 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 Interne
			t Numbers Registry System. Rather, it documents the Internet Numbers Registry S
			ystem 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/rfc724
			9" 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 p
			art 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/rfc812
			6" 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 const
			ants to identify various protocol parameters. To ensure that the values in thes
			e fields do not have conflicting uses and to promote interoperability, their all
			ocations 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 descr
			ibing 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 a
			uthors, in order to assure that the provided guidance for the IANA Consideration
			s 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/rfc871
			1" 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/rfc871
			3" quoteTitle="true" derivedAnchor="RFC8713">
			<front>
			<title>IAB, IESG, and IETF LLC Selection, Confirmation, and Recall Pro
			cess: 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>
			<section numbered="false" anchor="acknowledgements" toc="include" removeInRF
			C="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.		This text has been developed within the IAB IANA Evolution Program.
	The ideas and many text fragments, and corrections came from or were		The ideas and many text fragments and corrections came from or were
	inspired on comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko,		inspired by comments from:
	Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Steve		<contact fullname="Bernard Aboba"/>,
	Crocker, John Curran, Alissa Cooper, Leslie Daigle, Elise Gerich,		<contact fullname="Jaap Akkerhuis"/>,
	John Klensin, Bertrand de La Chapelle, Eliot Lear, Danny McPherson,		<contact fullname="Jari Arkko"/>,
	George Michaelson, Thomas Narten, Andrei Robachevsky, Andrew		<contact fullname="Marcelo Bagnulo"/>,
	Sullivan, Dave Thaler, Brian Trammell, and Greg Wood. Further		<contact fullname="Mark Blanchet"/>,
	inspiration and input was drawn from various meetings with IETF and		<contact fullname="Brian Carpenter"/>,
	other Internet community (RIRs, ISOC, W3C, IETF, and IAB) leadership.</t>		<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 La 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"/>.
	<t>		Further inspiration and input
			was drawn from various meetings with the leadership of the Internet
			community, i.e., from the RIRs, ISOC, W3C, IETF, and IAB.
			</t>
			<t pn="section-appendix.b-2">
	Please do not assume those acknowledged endorse the resulting text.</t>		Please do not assume those acknowledged endorse the resulting text.</t>
			</section>
	</section>		<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
			="include" pn="section-appendix.c">
	</back>		<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
			<author fullname="Russ Housley" initials="R." role="editor" surname="Housl
	</rfc>		ey">
			<organization showOnFrontPage="false" abbrev="Vigil Security">Vigil Secu
			rity, 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="Kolkm
			an">
			<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>
End of changes. 40 change blocks.
	236 lines changed or deleted		597 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/