Diff: rfc8720xml2.original.xml

	rfc8720xml2.original.xml	rfc8720.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC7437 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7437.xml">
	<!ENTITY I-D.ietf-iasa2-rfc4071bis SYSTEM "https://xml2rfc.ietf.org/public/rfc/b
	ibxml3/reference.I-D.draft-ietf-iasa2-rfc4071bis-00.xml">
	<!ENTITY RFC2850 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.2850.xml">
	<!ENTITY RFC2860 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.2860.xml">
	<!ENTITY RFC5226 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5226.xml">
	<!ENTITY RFC6220 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.6220.xml">
	<!ENTITY RFC7020 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7020.xml">
	<!ENTITY RFC7249 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7249.xml">
	]>
	<rfc submissionType="IAB" category="info" consensus="yes" number="0000" docName=
	"draft-iab-rfc7500-bis-00" 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 indicat
	ion
	top left, found none
	--><?rfc toc="yes"?>
	<front>
	<title abbrev="Principles for Operation of Internet Ass">Principles for O
	peration of Internet Assigned Numbers Authority (IANA) Registries</title>
	<author fullname="Russ Housley" initials="R." role="editor" surname="Hous
	ley">
	<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
	<address><postal><street>918 Spring Knoll Drive</street>
	<street>Herndon, VA 20170</street>
	<street>USA</street>
	</postal>
	<email>housley@vigilsec.com</email>
	</address>
	</author>


	<author fullname="Olaf Kolkman" initials="O." role="editor" surname="Kolk	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	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"/>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IAB" category="i
	<abstract><t>	nfo" consensus="yes" number="8720" docName="draft-iab-rfc7500-bis-00" obsoletes=
	This document provides principles for the operation of Internet	"7500" ipr="trust200902" updates="" xml:lang="en" sortRefs="true" symRefs="true"
	Assigned Numbers Authority (IANA) registries.</t>	tocInclude="true" version="3">


	</abstract>	<!-- xml2rfc v2v3 conversion 2.32.0 -->
	</front>	<link href="https://datatracker.ietf.org/doc/draft-iab-rfc7500-bis-00" rel="pr
		ev"/>
		<!-- Generated by id2xml 1.5.0 on 2019-10-03T18:02:21Z -->


	<middle>	<front>
	<section title="Introduction" anchor="sect-1"><t>	<title abbrev="Principles for Operation of IANA Registries">Principles for O
		peration of Internet Assigned Numbers Authority (IANA) Registries</title>
		<seriesInfo name="RFC" value="8720"/>
		<author fullname="Russ Housley" initials="R." role="editor"
		surname="Housley">
		<organization 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>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>
		<date month="January" year="2020"/>

		<!-- [rfced] Please insert any keywords (beyond those that appear in
		the title) for use on https://www.rfc-editor.org/search. -->

		<keyword>example</keyword>

		<abstract>
		<t>
		This document provides principles for the operation of Internet
		Assigned Numbers Authority (IANA) registries.</t>
		</abstract>
		</front>
		<middle>
		<section anchor="sect-1" numbered="true" toc="default">
		<name>Introduction</name>
		<t>
	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>
	<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>
	<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>
	<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>
	<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="default">
		<name>Principles for the Operation of IANA Registries</name>
	<section title="Principles for the Operation of IANA Registries" anchor="	<t>
	sect-2"><t>
	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">
	<t><list style="hanging" hangIndent="6">	<dt>Ensure Uniqueness:</dt>
	<t hangText="Ensure Uniqueness:"> The same protocol identifier must not be	<dd> The same protocol identifier must not be
	used for more than one purpose.</t>	used for more than one purpose.</dd>
		<dt>Stable:</dt>
	<t hangText="Stable:">Protocol identifier assignment must be lasting.</t>	<dd>Protocol identifier assignment must be lasting.</dd>
		<dt>Predictable:</dt>
	<t hangText="Predictable:">The process for making assignments must not	<dd>The process for making assignments must not
	include unexpected steps. </t>	include unexpected steps. </dd>
		<dt>Public:</dt>
	<t hangText="Public:"> The protocol identifiers must be made available	<dd> 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>Open:</dt>
	<t hangText="Open:">The process that sets the policy for protocol	<dd>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>Transparent:</dt>
	<t hangText="Transparent:">The protocol registries and their	<dd>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>Accountable:</dt>
	<t hangText="Accountable:">Registry policy development and registry	<dd>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="default">
		<name>Discussion</name>
	</section>	<t>
		The principles discussed in <xref target="sect-2" format="default"/> provide
	<section title="Discussion" anchor="sect-3"><t>	trust and confidence in
	The principles discussed in <xref target="sect-2"/> provide trust and confide
	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="default">
	<section title="Ensuring Uniqueness, Stability, and Predictability" ancho	<name>Ensuring Uniqueness, Stability, and Predictability</name>
	r="sect-3.1"><t>	<t>
	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>
	<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>
	<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"/>, a pr edictable 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="default">
		<name>Public</name>
	<section title="Public" anchor="sect-3.2"><t>	<t>
	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="default">
		<name>Open and Transparent</name>
	<section title="Open and Transparent" anchor="sect-3.3"><t>	<t>
	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>
	<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>
	<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"/>, 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="default">
		<name>Accountable</name>
	<section title="Accountable" anchor="sect-3.4"><t>	<t>
	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>
	<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>
	<t>	For protocol parameters <xref target="RFC6220" format="default"/>, the genera
	For protocol parameters <xref target="RFC6220"/>, the general oversight of th	l 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"/>. In addition, the IETF Administrat ion 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"/>. In that role, the IETF LLC
	F LLC	maintains an SLA with the current registry operator, the Internet
	maintains a 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="default"/>.</t>


	<t>	<t>
	For the Internet Number Registries <xref target="RFC7249"/>, oversight is per	For the Internet Number Registries <xref target="RFC7249" format="default"/>,
	formed	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"/>. The RIRs are member-based organiz ations, 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"/>.</t>
	</section>	</section>
		</section>
	</section>	<section anchor="sect-4" numbered="true" toc="default">
		<name>Security Considerations</name>
	<section title="Security Considerations" anchor="sect-4"><t>	<t>
	Internet Registries are critical to elements of Internet security.	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="default">
		<name>Changes since RFC 7500</name>
	<section title="Changes Since RFC 7500" anchor="sect-5"><t>	<t>
	<xref target="sect-3.4"/> has been updated to align with the restructuring of	<xref target="sect-3.4" format="default"/> has been updated to align with the
	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>
		</middle>
		<back>


	</section>	<references>
		<name>Informative References</name>


	</middle>	<reference anchor="ASOMOU" target="https://archive.icann.org/en/aso/aso-mo
		u-29oct04.htm">
		<front>
		<title>Address Supporting Organization (ASO) MoU</title>
		<author>
		<organization>ICANN</organization>
		</author>
		<date month="October" year="2004"/>
		</front>
		</reference>


	<back>	<!-- I-D.draft-ietf-iasa2-rfc4071bis-00.xml; companion document RFC 8711 -->
	<references title="Informative References">
	<reference anchor="ASOMOU" target="http://archive.icann.org/en/aso/aso-mo
	u-29oct04.htm"><front>
	<title>ICANN Address Supporting Organization (ASO) MoU</title>
	<author>
	<organization>ICANN</organization>
	</author>


	<date month="October" year="2004"/>	<reference anchor='RFC8711'>
	</front>	<front>
		<title>Structure of the IETF Administrative Support Activity, Version 2.0</title
		>


	</reference>	<author initials='B' surname='Haberman' fullname='Brian Haberman'>
	<reference anchor="BCP10" target="http://www.rfc-editor.org/info/bcp10"><	<organization />
	front>	</author>
	<title>IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: O
	peration of the Nominating and Recall Committees</title>
	<author fullname="M. Kucherawy" initials="M." surname="Kucherawy" role="e
	ditor">
	</author>


	<date month="January" year="2015"/>	<author initials='J' surname='Hall' fullname='Joseph Hall'>
	</front>	<organization />
		</author>


	<seriesInfo name="BCP" value="10"/>	<author initials='J' surname='Livingood' fullname='Jason Livingood'>
	<seriesInfo name="RFC" value="7437"/>	<organization />
	</reference>	</author>
	&I-D.ietf-iasa2-rfc4071bis;
	&RFC2850;
	&RFC2860;
	&RFC5226;
	&RFC6220;
	&RFC7020;
	&RFC7249;
	</references>
	<section title="Members at the Time of Approval" anchor="sect-iab"><figur
	e><artwork><![CDATA[
	{{ RFC Editor: Fill in the current membership. }}
	]]></artwork>
	</figure>
	</section>


	<section title="Contributors and Acknowledgements" numbered="no" anchor="	<date month='January' year='2020' />
	contributors-and-acknowledgements"><t>
	This text has been developed within the IAB IANA Evolution Program.
	The ideas and many text fragments, and corrections came from or were
	inspired on 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 de La Chapelle, Eliot Lear, Danny McPherson,
	George Michaelson, Thomas Narten, Andrei Robachevsky, Andrew
	Sullivan, Dave Thaler, Brian Trammell, and Greg Wood. Further
	inspiration and input was drawn from various meetings with IETF and
	other Internet community (RIRs, ISOC, W3C, IETF, and IAB) leadership.</t>


	<t>	</front>
	Please do not assume those acknowledged endorse the resulting text.</t>	<seriesInfo name="BCP" value="101"/>
		<seriesInfo name="RFC" value="8711"/>
		<seriesInfo name="DOI" value="10.17487/RFC8711"/>
		</reference>


	</section>	<!-- draft-ietf-iasa2-rfc7437bis [RFC8713] -->
		<reference anchor="RFC8713" target="https://rfc-editor.org/info/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/>
		</author>
		<author initials="R." surname="Hinden" role="editor">
		<organization/>
		</author>
		<author initials="J." surname="Livingood" role="editor">
		<organization/>
		</author>
		<date month="January" year="2020"/>
		</front>
		<seriesInfo name="BCP" value="10"/>
		<seriesInfo name="RFC" value="8713"/>
		<seriesInfo name="DOI" value="10.17487/RFC8713"/>
		</reference>


	</back>	<xi:include
		href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2850.xml
		"/>


	</rfc>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.8126.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.6220.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.7020.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.7249.xml"/>
		</references>
		<section anchor="sect-iab" numbered="false" toc="default">
		<name>IAB Members at the Time of Approval</name>
		<ul spacing="compact" empty="true">
		<li><t><contact fullname="Jari Arkko"/></t></li>
		<li><t><contact fullname="Alissa Cooper"/></t></li>
		<li><t><contact fullname="Stephen Farrell"/></t></li>
		<li><t><contact fullname="Wes Hardaker"/></t></li>
		<li><t><contact fullname="Ted Hardie"/></t></li>
		<li><t><contact fullname="Christian Huitema"/></t></li>
		<li><t><contact fullname="Zhenbin Li"/></t></li>
		<li><t><contact fullname="Erik Nordmark"/></t></li>
		<li><t><contact fullname="Mark Nottingham"/></t></li>
		<li><t><contact fullname="Melinda Shore"/></t></li>
		<li><t><contact fullname="Jeff Tantsura"/></t></li>
		<li><t><contact fullname="Martin Thomson"/></t></li>
		<li><t><contact fullname="Brian Trammell"/></t></li>
		</ul>
		</section>
		<section numbered="false" anchor="acknowledgements"
		toc="default">
		<name>Acknowledgements</name>
		<t>
		This text has been developed within the IAB IANA Evolution Program.
		The ideas and many text fragments and corrections came from or were
		inspired by comments from:
		<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 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" />.

		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>
		Please do not assume those acknowledged endorse the resulting text.</t>
		</section>
		</back>
		</rfc>

End of changes. 53 change blocks.
	230 lines changed or deleted	211 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/