rfc8717xml2.original.xml		rfc8717.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version='1.0' encoding='utf-8'?>
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="bcp" conse
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [		nsus="true" docName="draft-ietf-iasa2-consolidated-upd-07" indexInclude="true" i
	<!-- Getting references from the online citation library.		pr="trust200902" number="8717" prepTime="2020-02-26T17:48:47" scripts="Common,La
	There has to be one entity for each item to be referenced. -->		tin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclud
			e="true" updates="2028, 2418, 3005, 3710, 3929, 4633, 6702" xml:lang="en">
	<!ENTITY rfc2026 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.		<link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-consolidated-upd
	RFC.2026.xml">		-07" rel="prev"/>
	<!ENTITY rfc2028 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.		<link href="https://dx.doi.org/10.17487/rfc8717" rel="alternate"/>
	RFC.2028.xml">		<link href="urn:issn:2070-1721" rel="alternate"/>
	<!ENTITY rfc2418 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
	RFC.2418.xml">
	<!ENTITY rfc3005 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
	RFC.3005.xml">
	<!ENTITY rfc3710 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
	RFC.3710.xml">
	<!ENTITY rfc3716 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
	RFC.3716.xml">
	<!ENTITY rfc3929 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
	RFC.3929.xml">
	<!ENTITY rfc3979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
	RFC.3979.xml">
	<!ENTITY rfc4633 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
	RFC.4633.xml">
	<!-- <!ENTITY rfc4844 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/refer
	ence.RFC.4844.xml"> -->
	<!ENTITY rfc4879 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
	RFC.4879.xml">
	<!-- <!ENTITY rfc5377 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/refer
	ence.RFC.5377.xml"> -->
	<!ENTITY rfc6702 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
	RFC.6702.xml">
	<!-- <!ENTITY rfc7500 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/refer
	ence.RFC.7500.xml"> -->
	<!ENTITY rfc8179 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.
	RFC.8179.xml">
	<!-- Fudge for XMLmind which doesn't have this built in -->
	<!ENTITY nbsp "&#160;">
	]>
	<!-- Extra statement used by XSLT processors to control the output style. -->
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<!-- Processing Instructions- PIs (for a complete list and description,
	see file http://xml.resource.org/authoring/README.html.
	You may find that some sphisticated editors are not able to edit PIs when p
	alced here.
	An alternative position is just inside the rfc elelment as noted below. -->
	<!-- Some of the more generally applicable PIs that most I-Ds might want to use
	-->
	<!-- Try to enforce the ID-nits conventions and DTD validity -->
	<?rfc strict="yes" ?>
	<!-- Items used when reviewing the document -->
	<!-- Controls display of <cref> elements -->
	<?rfc comments="yes" ?>
	<!-- When no, put comments at end in comments section,
	otherwise, put inline -->
	<?rfc inline="yes" ?>
	<!-- When yes, insert editing marks: editing marks consist of a
	string such as <29> printed in the blank line at the
	beginning of each paragraph of text. -->
	<?rfc editing="no" ?>
	<!-- Create Table of Contents (ToC) and set some options for it.
	Note the ToC may be omitted for very short documents,but idnits insists on
	a ToC
	if the document has more than 15 pages. -->
	<?rfc toc="yes"?>
	<?rfc tocompact="yes"?>
	<!-- If "yes" eliminates blank lines before main section entries. -->
	<?rfc tocdepth="3"?>
	<!-- Sets the number of levels of sections/subsections... in ToC.
	Can be overridden by 'toc="include"/"exclude"' on the section
	element-->
	<!-- Choose the options for the references.
	Some like symbolic tags in the references (and citations) and others prefer
	numbers. The RFC Editor always uses symbolic tags.
	The tags used are the anchor attributes of the references. -->
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes" ?>
	<!-- If "yes", causes the references to be sorted in order of tags.
	This doesn't have any effect unless symrefs is "yes"
	also. -->
	<!-- These two save paper: Just setting compact to "yes" makes savings by not st
	arting each
	main section on a new page but does not omit the blank lines between list i
	tems.
	If subcompact is also "yes" the blank lines between list items are also omi
	tted. -->
	<?rfc compact="yes" ?>
	<?rfc subcompact="no" ?>
	<!-- end of list of popular I-D processing instructions -->
	<!-- This is -07c, the posting version -->
	<rfc docName="draft-ietf-iasa2-consolidated-upd-07"
	ipr="trust200902" category="bcp"
	updates="2028, 2418, 3005, 3710, 3929, 4633, 6702" >
	<!-- JcK 20181203: removed 3979, 4879, 8179 from Obsoletes
	list
	JcK 20190117: removed 4844, 5377
	JcK 20190311, removed 3929, 4633 and moved to updates -->
	<!-- ***** FRONT MATTER ***** -->
	<front>		<front>
			<title abbrev="IASA 2.0 Consolidated Updates">IETF Administrative Support Ac
	<title abbrev="IASA2 Consolidated Updates">		tivity 2.0: Consolidated Updates to IETF Administrative Terminology</title>
	Consolidated IASA 2.0 Updates of IETF Administrative Terminology</tit		<seriesInfo name="RFC" value="8717" stream="IETF"/>
	le>		<seriesInfo name="BCP" value="101" stream="IETF"/>
	<!-- Before -05 was "Consolidated IASA2-Related Document Updates"		<author fullname="John C Klensin" initials="J." surname="Klensin" role="edit
	Change per email from Brian Carpenter, 20180117 -->		or">
			<organization showOnFrontPage="true"/>
	<!-- add 'role="editor"' below for the editors if appropriate -->
	<author fullname="John C Klensin" initials="J.C." surname="Klensin"
	role="editor">
	<organization/>
	<address>		<address>
	<postal>		<postal>
	<street>1770 Massachusetts Ave, Ste 322</street>		<street>1770 Massachusetts Ave, Ste 322</street>
	<city>Cambridge</city> <region>MA</region>		<city>Cambridge</city>
			<region>MA</region>
	<code>02140</code>		<code>02140</code>
	<country>USA</country>		<country>USA</country>
	</postal>		</postal>
	<phone>+1 617 245 1457</phone>		<phone>+1 617 245 1457</phone>
	<email>john-ietf@jck.com</email>		<email>john-ietf@jck.com</email>
	</address>		</address>
	</author>		</author>
			<date month="02" year="2020"/>
	<date month="March" day="11" year="2019" />
	<!-- Meta-data Declarations -->
	<area>General</area>		<area>General</area>
	<!-- WG name at the upper left corner of the doc,
	IETF fine for individual submissions. You can also
	omit this element in which case it defaults to "Network Working Group"
	-
	a hangover from the ancient history of the IETF! -->
	<workgroup>IASA2</workgroup>		<workgroup>IASA2</workgroup>
			<keyword>IASA</keyword>
	<!-- You can add <keyword/> elements here. They will be incorporated int		<abstract pn="section-abstract">
	o HTML output		<t pn="section-abstract-1">In 2018, the IETF began the transition to a new
	files in a meta tag but they have no effect on text or nroff output. --
	>
	<!-- <keyword>Text</keyword> (as many of those elements as needed -->
	<abstract>
	<t>In 2018, the IETF began the transition to a new
	administrative structure and updated its IETF		administrative structure and updated its IETF
	Administrative Support Activity (IASA) to a new "IASA 2.0"		Administrative Support Activity (IASA) to a new "IASA 2.0"
	structure.		structure.
	In addition to more substantive changes that are described in		In addition to more substantive changes that are described in
	other documents, the transition to the 2018 IETF		other documents, the transition to the 2018 IETF
	Administrative Support structure changes several position		Administrative Support structure changes several position
	titles and organizational relationships that are referenced		titles and organizational relationships that are referenced
	elsewhere. Rather than reissue those referencing documents		elsewhere. Rather than reissue those referencing documents
	individually,		individually,
	this specification provides updates to them and deprecates		this specification provides updates to them and deprecates
	some now-obsolete documents to ensure that		some now-obsolete documents to ensure that
	there is no confusion due to these changes.</t>		there is no confusion due to these changes.</t>
	</abstract>		</abstract>
			<boilerplate>
	<!-- Note here if needed		<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
	<note title=""><t> .... </t></note> -->		"exclude" pn="section-boilerplate.1">
			<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
			>
			<t pn="section-boilerplate.1-1">
			This memo documents an Internet Best Current Practice.
			</t>
			<t pn="section-boilerplate.1-2">
			This document is a product of the Internet Engineering Task Force
			(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by
			the Internet Engineering Steering Group (IESG). Further information
			on BCPs is available in 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/rfc8717" 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. Code Components extracted from this
			document must include Simplified BSD License text as described in
			Section 4.e of the Trust Legal Provisions and are provided without
			warranty as described in the Simplified BSD License.
			</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-where-appropriate-replace
			me">Where Appropriate, Replacement of the IETF Executive Director Position with
			the Managing Director, IETF Secretariat</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-removal-of-the-ietf-execu
			ti">Removal of the IETF Executive Director as an Option</xref></t>
			</li>
			<li pn="section-toc.1-1.4">
			<t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent
			="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-deprecated-documents">Dep
			recated Documents</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.4.2">
			<li pn="section-toc.1-1.4.2.1">
			<t keepWithNext="true" pn="section-toc.1-1.4.2.1.1"><xref derive
			dContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-documents-who
			se-context-is-">Documents Whose Context Is Changed by This Specification</xref><
			/t>
			</li>
			<li pn="section-toc.1-1.4.2.2">
			<t keepWithNext="true" pn="section-toc.1-1.4.2.2.1"><xref derive
			dContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-general-descr
			iption-of-the-">General Description of the IETF Administrative Model</xref></t>
			</li>
			</ul>
			</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-security-considerations">
			Security Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.6">
			<t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent
			="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-references">References</x
			ref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.6.2">
			<li pn="section-toc.1-1.6.2.1">
			<t keepWithNext="true" pn="section-toc.1-1.6.2.1.1"><xref derive
			dContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-normative-ref
			erences">Normative References</xref></t>
			</li>
			<li pn="section-toc.1-1.6.2.2">
			<t keepWithNext="true" pn="section-toc.1-1.6.2.2.1"><xref derive
			dContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-informative-r
			eferences">Informative References</xref></t>
			</li>
			</ul>
			</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-acknowledgments">Acknow
			ledgments</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-contributors">Contribut
			ors</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-address">Author
			's Address</xref></t>
			</li>
			</ul>
			</section>
			</toc>
	</front>		</front>
	<middle>		<middle>
	<section title="Introduction" anchor="Intro">		<section anchor="Intro" numbered="true" toc="include" removeInRFC="false" pn
	<t>In 2018, the IETF began the transition to a new		="section-1">
			<name slugifiedName="name-introduction">Introduction</name>
			<t pn="section-1-1">In 2018, the IETF began the transition to a new
	administrative structure, and updated its IETF		administrative structure, and updated its IETF
	Administrative Support Activity (IASA) to a new "IASA 2.0"		Administrative Support Activity (IASA) to a new "IASA 2.0"
	structure <xref target="RFC-Struct"/>. Key IASA 2.0 changes ha		structure <xref target="RFC8711" format="default" sectionFormat=
	ve been		"of" derivedContent="RFC8711"/>. Key
	<!-- The IETF initiated a major revision of its administrative		IASA 2.0 changes have been
	support arrangements and procedures in 2018
	<xref target="RFC-Struct"/>. Those changes have been -->
	specified in a series of documents, including		specified in a series of documents, including
	<!-- notably a description of -->		changes to the IETF Trust <xref target="RFC8714" format="default
	changes to the IETF Trust <xref target="RFC-trust-update"/>,		" sectionFormat="of" derivedContent="RFC8714"/>,
	the rationale for it <xref target="RFC-trust-rationale"/>,		the rationale for it <xref target="RFC8715" format="default" sec
	a new defining document for the IETF Administration LLC		tionFormat="of" derivedContent="RFC8715"/>,
	<xref target="LLC-Agreement"/> (informally called the "IETF		a new defining document for the IETF Administration LLC <xref ta
	LLC" or just "the LLC" in places in this document and elsewhere)		rget="LLC-Agreement" format="default" sectionFormat="of" derivedContent="LLC-Agr
			eement"/> (informally called the "IETF
			LLC" or just "the LLC" in places in this document and elsewhere)
			,
	and adjustments to the procedures for nominations and		and adjustments to the procedures for nominations and
	selections for relevant positions		selections for relevant positions
	<xref target="RFC-7437bis"/>.</t>		<xref target="RFC8713" format="default" sectionFormat="of" deriv
	<t>In addition to more substantive changes that are described in		edContent="RFC8713"/>.</t>
			<t pn="section-1-2">In addition to more substantive changes that are descr
			ibed in
	those and other documents, the IASA 2.0 structure changes		those and other documents, the IASA 2.0 structure changes
	several position titles and organizational relationships that		several position titles and organizational relationships that
	are referenced in other documents. Rather than reissue those		are referenced in other documents. Rather than reissue those
	documents individually, this document provides a unified		documents individually, this document provides a unified
	update to them. </t>		update to them. </t>
	<!-- Among the substantive changes in those documents are changes		<t pn="section-1-3"> This document updates RFCs 2028, 2418, 3005, 3710, 39
	in names of organizations, position titles, and associated		29,
	relationships.		4633, and 6702 (citations in context below)
	Rather than reissue those documents individually,
	address other topics but mention those names, titles, and
	relationships, this specification provides updates to them
	to ensure that there is no confusion due to changes in
	terminology. -->
	<t> This document updates RFCs 2028, 2418, 3005, 3710, 3929,
	4633, and <!-- 5377 removed -->
	6702 (citations in context below)
	to make those terminology and related changes. In addition,		to make those terminology and related changes. In addition,
	with the authorization of the IAB, it requests		with the authorization of the IAB, it requests
	that the Informational RFC 3716 be made		that the Informational RFC 3716 be made
	Historic (see <xref target="MakeHistoric"/>).		Historic (see <xref target="MakeHistoric" format="default" secti onFormat="of" derivedContent="Section 4"/>).
	The sections that follow identify the details of the		The sections that follow identify the details of the
	relevant documents and the required changes. </t>		relevant documents and the required changes. </t>
	<!-- <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in
	<xref target="RFC2119">RFC 2119</xref>.</t> -->
	</section>		</section>
			<section anchor="ExecDir-Managing" numbered="true" toc="include" removeInRFC
	<!-- <section title="Remove Text About the Connection Between the IAOC and IET		="false" pn="section-2">
	F Trust">		<name slugifiedName="name-where-appropriate-replaceme">Where Appropriate,
	<t> Some documents that discuss the IETF Trust or its		Replacement of the IETF Executive Director Position with the Managing Director,
	relationship to the community describe it, or the Trustees,		IETF Secretariat</name>
	in relation to the IAOC. That connection must be eliminated to		<t pn="section-2-1">Under the IASA 2.0 structure, most of the responsibili
	reflect the new IASA 2.0 structure.		ties
	<t> This document applies that change to the following:
	<list style="symbols">
	<t> <xref target="RFC5377">RFC 5377</xref>, Advice to
	the Trustees of the IETF Trust on Rights to Be Gr
	anted in IETF Documents.
	These changes require dropping "made up of the
	members of the IAOC [RFC4371]" after "board of
	trustees" in the first paragraph of Section 1 an
	d
	"which is made up of the members of the IAOC, as
	described in [RFC4071] and [RFC4371]"
	in the first paragraph of Section 3.
	<vspace blankLines="0"/> <cref> RFC Editor pleas
	e
	note that the bracketed strings above are
	quoted
	text, not references. </cref></t>
	</list></t>
	</section> -->
	<!-- <section title="Replacement of IAOC with IETF Administration LLC"
	anchor="LLCRepl">
	<t>All mentions of the IETF Administrative Oversight
	Committee (IAOC) that are not removed by the prior
	section, shall be updated and replaced by the IETF
	Administration LLC (IETF-LLC). This is necessary because
	the IAOC is phased out under the IASA 2.0 structure. </t>
	<t> This document applies that change to the following:
	<list style="symbols">
	<t><xref target="RFC4844">RFC 4844</xref>, the RFC
	Series and RFC Editor Sections 3.3, 3.4, and 4.</
	t>
	<t><xref target="RFC7500">RFC 7500</xref> Principles for
	Operation of Internet Assigned Numbers Authority
	(IANA) Registries, Section 3.4. This means that t
	he
	IETF LLC, the body responsible for IETF
	administrative and financial matters, maintains a
	n
	SLA with the current registry operator, the Inter
	net
	Corporation for Assigned Names and Numbers (ICANN
	).
	It also means that both the Internet Architecture
	Board (IAB) and the IETF LLC are accountable to t
	he
	larger Internet community for the IANA registries
	.</t>
	</list></t>
	</section> -->
	<section title="Where Appropriate, Replacement of the IETF Executive Dire
	ctor position with the Managing Director, IETF Secretariat"
	anchor="ExecDir-Managing">
	<t>Under the IASA 2.0 structure, most of the responsibilities
	of the former position of IETF		of the former position of IETF
	Executive Director been assigned to a new position (or at		Executive Director have been assigned to a new position (or at
	least title) of Managing Director of the IETF Secretariat.		least title) of Managing Director, IETF Secretariat.
	An "Executive Director" title is now associated with		An "Executive Director" title is now associated with
	different, and largely new, responsibilities as an Officer		different, and largely new, responsibilities as an officer
	of the IETF Administration		of the IETF Administration
	LLC. These changes are described in the description of the		LLC. These changes are covered in the description of the
	new structural arrangements <xref target="RFC-Struct"/>.</t>		new structural arrangements <xref target="RFC8711" format="defa
	<t> This document applies that change to the following:		ult" sectionFormat="of" derivedContent="RFC8711"/>.</t>
	<!-- RFC Editor: the inconsistency in the positioning of		<t pn="section-2-2"> This document applies that change to the following:</
	section numbers in citations below is deliberate, to call		t>
	your attention to an issue about this type of reference that		<ul spacing="normal" bare="false" empty="false" pn="section-2-3">
	I've been commenting/ inquiring/ complaining about since		<li pn="section-2-3.1">RFC 2028, "The Organizations Involved in the IETF
	1999. Fix it however you like. -->		Standards Process", <xref target="RFC2028" secti
	<list style="symbols">		onFormat="comma" section="3.3" format="default" derivedLink="https://rfc-editor.
	<t>RFC 2028, The Organizations Involved in the IETF		org/rfc/rfc2028#section-3.3" derivedContent="RFC2028"/>.</li>
	Standards Process <xref target="RFC2028"/>,		<li pn="section-2-3.2">RFC 2418, "IETF Working Group Guidelines and Proc
	Section 3.3.</t>		edures",
			<xref target="RFC2418" sectionFormat="comma" sec
	<t>RFC 2418, IETF Working Group Guidelines and Procedure		tion="1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2418#sectio
	s		n-1" derivedContent="RFC2418"/>.</li>
	<xref target="RFC2418"/>, Section 1.</t>		<li pn="section-2-3.3">RFC 3710, "An IESG Charter",
			<xref target="RFC3710" sectionFormat="comma" sec
	<t>RFC 3710, An IESG Charter, Section 2		tion="2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3710#sectio
	<xref target="RFC3710"/>.</t>		n-2" derivedContent="RFC3710"/>.</li>
			<li pn="section-2-3.4">RFC 3929, "Alternative Decision Making Processes
	<t>RFC 3929, Alternative Decision Making Processes for		for
	Consensus-Blocked Decisions in the IETF		Consensus-Blocked Decisions in the IETF",
	<xref target="RFC3929"/>, Sections 4.1.1 and 4.3		<xref target="RFC3929" format="default" sectionForm
	(twice).</t>		at="of" derivedContent="RFC3929"/>, Sections <xref target="RFC3929" section="4.1
			.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rf
	<t>RFC 4633, Experiment in Long-Term Suspensions From		c/rfc3929#section-4.1.1" derivedContent="RFC3929"/>
			and <xref target="RFC3929" section="4.3" sectionFor
			mat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3929#sect
			ion-4.3" derivedContent="RFC3929"/>
			(twice).</li>
			<li pn="section-2-3.5">RFC 4633, "Experiment in Long-Term Suspensions Fr
			om
	Internet Engineering Task Force (IETF) Mailing		Internet Engineering Task Force (IETF) Mailing
	Lists <xref target="RFC4633"/>, Section 1.</t>		Lists", <xref target="RFC4633" sectionFormat="comma" s
			ection="1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4633#sect
	<t>RFC 6702, Promoting Compliance with Intellectual		ion-1" derivedContent="RFC4633"/>.</li>
	Property Rights (IPR) Disclosure Rules,		<li pn="section-2-3.6">RFC 6702, "Promoting Compliance with Intellectual
	Section 5 <xref target="RFC6702"/>.</t>		Property Rights (IPR) Disclosure Rules",
			<xref target="RFC6702" section="5" sectionFormat="com
	</list></t>		ma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6702#section-5"
	<t> Note that the current description of the Internet		derivedContent="RFC6702"/>.</li>
	Standards Process <xref target="RFC2026"/> does not		</ul>
			<t pn="section-2-4"> Note that the current description of the Internet
			Standards Process <xref target="RFC2026" format="default
			" sectionFormat="of" derivedContent="RFC2026"/> does not
	require an update by this document for this purpose		require an update by this document for this purpose
	because the reference		because the reference
	to the IETF Executive Director in RFC 2026 was replaced		to the IETF Executive Director in RFC 2026 was replaced
	by a document that precedes the current		by a document <xref target="RFC3979" format="default" se
	effort <xref target="RFC3979"/> and that was, in turn,		ctionFormat="of" derivedContent="RFC3979"/> that precedes the current
	obsoleted by <xref target="RFC8179">RFC 8179</xref>.</t>		effort, and that document was, in turn,
	</section>		obsoleted by <xref target="RFC8179" format="default" sec
			tionFormat="of" derivedContent="RFC8179">RFC 8179</xref>.</t>
	<section title="Remove the IETF Executive Director as an Option">		</section>
	<t> In a few cases, it is no longer appropriate for either the		<section numbered="true" toc="include" removeInRFC="false" pn="section-3">
			<name slugifiedName="name-removal-of-the-ietf-executi">Removal of the IETF
			Executive Director as an Option</name>
			<t pn="section-3-1"> In a few cases, it is no longer appropriate for eithe
			r the
	Managing Director, IETF Secretariat (former IETF Executive		Managing Director, IETF Secretariat (former IETF Executive
	Director position) or the new IETF Executive Director (for		Director position) or the new IETF Executive Director (for
	the LLC) to perform a particular historical function.		the LLC) to perform a particular historical function.
	The relevant documents are updated to remove		The relevant documents are updated to remove
	the IETF Executive Director from the list of people with		the IETF Executive Director from the list of people with
	specific responsibilities or authority. Those documents		specific responsibilities or authority. Those documents
	will not be updated to use "Managing Director, IETF		will not be updated to use "Managing Director, IETF
	Secretariat" but, instead, the mention of the position will		Secretariat" but, instead, the mention of the position will
	simply be dropped.</t>		simply be dropped.</t>
	<t> This document applies that change to the following:		<t pn="section-3-2"> This document applies that change to the following:
	<list style="symbols">		</t>
	<t>RFC 3005, IETF Discussion List Charter		<ul spacing="normal" bare="false" empty="false" pn="section-3-3">
	<xref target="RFC3005"/>, section titled "Charter		<li pn="section-3-3.1">RFC 3005, "IETF Discussion List Charter"
	for		<xref target="RFC3005" format="default" sectionFo
			rmat="of" derivedContent="RFC3005"/>, section titled "Charter for
	the IETF Discussion List". This document is modi fied		the IETF Discussion List". This document is modi fied
	to remove the authorization for the IETF Executiv e		to remove the authorization for the IETF Executiv e
	Director to restrict people from posting, etc.</t		Director to restrict people from posting, etc.</l
	>		i>
	<!-- Jason: As a result, only the IETF Chair,		</ul>
	or a sergeant-at-arms appointed by the Chair,		</section>
	are		<section anchor="MakeHistoric" numbered="true" toc="include" removeInRFC="fa
	empowered to do so. -->		lse" pn="section-4">
	</list></t>		<name slugifiedName="name-deprecated-documents">Deprecated Documents</name
	</section>		>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-4.1
	<section title="Deprecated Documents" anchor="MakeHistoric">		">
	<t><cref> Note to the WG, IESG, and RFC Editor: I hope this		<name slugifiedName="name-documents-whose-context-is-">Documents Whose C
	section correctly reflects the conclusions of discussions in		ontext Is Changed by This Specification</name>
	and with the WG. If it does not, the issues should		<t pn="section-4.1-1">Both of the documents that follow were obsoleted i
	certainly be identified and fixed. However, details of		n 2017
	some of the actions are the responsibility of the RFC Editor		by <xref target="RFC8179" format="default" sectionFormat
	and RFC 3716 is an IAB document containing the report of an		="of" derivedContent="RFC8179">RFC 8179</xref>, which changed
	IAB Advisory Committee. If that text, especially the
	phrasing of various actions, is not quite right, I hope
	those involved can sort the language out with the RFC Editor
	rather than requiring that the WG iterate on the
	draft. --JcK, editor. RFC Editor: should this paragraph reach
	you, please remove it.</cref></t>
	<section title="Documents Whose Context is Changed by This Specificati
	on ">
	<t>Both of the documents that follow were obsoleted in 2017
	by <xref target="RFC8179">RFC 8179</xref>, which changed
	mentions of the IETF Executive Director to point to		mentions of the IETF Executive Director to point to
	the IETF Secretariat more generally.</t>		the IETF Secretariat more generally.</t>
	<t><list style="symbols">		<ul spacing="normal" bare="false" empty="false" pn="section-4.1-2">
	<t><xref target="RFC3979">RFC 3979</xref>.</t>		<li pn="section-4.1-2.1">
	<t><xref target="RFC4879">RFC 4879</xref>.</t>		<xref target="RFC3979" format="default" sectionFormat="of" derivedCo
	</list></t>		ntent="RFC3979">RFC 3979</xref></li>
	</section>		<li pn="section-4.1-2.2">
			<xref target="RFC4879" format="default" sectionFormat="of" derivedCo
	<section title="General Description of the IETF Adminstrative Model">		ntent="RFC4879">RFC 4879</xref></li>
	<t><xref target="RFC3716">RFC 3716</xref> is a		</ul>
	report of an IAB Advisory Committee that served a		</section>
	s a		<section numbered="true" toc="include" removeInRFC="false" pn="section-4.2
	starting point for the work that led to the origi		">
	nal		<name slugifiedName="name-general-description-of-the-">General Descripti
	IASA structure. That report is an IAB document		on of the IETF Administrative Model</name>
	rather than an IETF one. The IAB approved a prop		<t pn="section-4.2-1"><xref target="RFC3716" format="default" sectionFor
	osal		mat="of" derivedContent="RFC3716">RFC 3716</xref> was a
	to move RFC 3716 to Historic on March 6, 2019. </		report of an IAB Advisory Committee that served as a
	t>		starting point for the work that led to the original
	</section>		IASA structure. That report was an IAB document
			rather than an IETF one. The IAB approved a proposal
	</section>		to move RFC 3716 to Historic on March 6, 2019
			<xref target="IAB-3716-Historic" format="default" sectionFormat=
	<section anchor="Acknowledgments" title="Acknowledgments">		"of" derivedContent="IAB-3716-Historic"/>. </t>
	<t> Brian Carpenter's careful checking and identification of		</section>
			</section>
			<section anchor="Security" numbered="true" toc="include" removeInRFC="false"
			pn="section-5">
			<name slugifiedName="name-security-considerations">Security Considerations
			</name>
			<t pn="section-5-1">The changes specified in this document are matters of
			terminology and organizational structure derived from
			documents it references. It should have no effect on
			Internet security.</t>
			</section>
			</middle>
			<back>
			<references pn="section-6">
			<name slugifiedName="name-references">References</name>
			<references pn="section-6.1">
			<name slugifiedName="name-normative-references">Normative References</na
			me>
			<reference anchor="LLC-Agreement" target="https://www.ietf.org/documents
			/180/IETF-LLC-Agreement.pdf" quoteTitle="true" derivedAnchor="LLC-Agreement">
			<front>
			<title>Limited Liability Company Agreement of IETF Administration LL
			C</title>
			<author>
			<organization showOnFrontPage="true">IETF Administration LLC</orga
			nization>
			</author>
			<date year="2018" month="August" day="28"/>
			</front>
			</reference>
			<reference anchor="RFC2028" target="https://www.rfc-editor.org/info/rfc2
			028" quoteTitle="true" derivedAnchor="RFC2028">
			<front>
			<title>The Organizations Involved in the IETF Standards Process</tit
			le>
			<author initials="R." surname="Hovey" fullname="R. Hovey">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S." surname="Bradner" fullname="S. Bradner">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="1996" month="October"/>
			<abstract>
			<t>This document describes the individuals and organizations invol
			ved in the IETF. This includes descriptions of the IESG, the IETF Working Group
			s and the relationship between the IETF and the Internet Society. This document
			specifies an Internet Best Current Practices for the Internet Community, and req
			uests discussion and suggestions for improvements.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="11"/>
			<seriesInfo name="RFC" value="2028"/>
			<seriesInfo name="DOI" value="10.17487/RFC2028"/>
			</reference>
			<reference anchor="RFC2418" target="https://www.rfc-editor.org/info/rfc2
			418" quoteTitle="true" derivedAnchor="RFC2418">
			<front>
			<title>IETF Working Group Guidelines and Procedures</title>
			<author initials="S." surname="Bradner" fullname="S. Bradner">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="1998" month="September"/>
			<abstract>
			<t>This document describes the guidelines and procedures for forma
			tion and operation of IETF working groups. This document specifies an Internet
			Best Current Practices for the Internet Community, and requests discussion and s
			uggestions for improvements.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="25"/>
			<seriesInfo name="RFC" value="2418"/>
			<seriesInfo name="DOI" value="10.17487/RFC2418"/>
			</reference>
			<reference anchor="RFC3005" target="https://www.rfc-editor.org/info/rfc3
			005" quoteTitle="true" derivedAnchor="RFC3005">
			<front>
			<title>IETF Discussion List Charter</title>
			<author initials="S." surname="Harris" fullname="S. Harris">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2000" month="November"/>
			<abstract>
			<t>The Internet Engineering Task Force (IETF) discussion mailing l
			ist furthers the development and specification of Internet technology through di
			scussion of technical issues, and hosts discussions of IETF direction, policy, m
			eetings, and procedures. As this is the most general IETF mailing list, conside
			rable latitude is allowed. Advertising, whether to solicit business or promote e
			mployment opportunities, falls well outside the range of acceptable topics, as d
			o discussions of a personal nature. This document specifies an Internet Best Cu
			rrent Practices for the Internet Community, and requests discussion and suggesti
			ons for improvements.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="45"/>
			<seriesInfo name="RFC" value="3005"/>
			<seriesInfo name="DOI" value="10.17487/RFC3005"/>
			</reference>
			<reference anchor="RFC3710" target="https://www.rfc-editor.org/info/rfc3
			710" quoteTitle="true" derivedAnchor="RFC3710">
			<front>
			<title>An IESG charter</title>
			<author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2004" month="February"/>
			<abstract>
			<t>This memo provides a charter for the Internet Engineering Steer
			ing Group (IESG), a management function of the Internet Engineering Task Force (
			IETF). It is meant to document the charter of the IESG as it is presently under
			stood. This memo provides information for the Internet community.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="3710"/>
			<seriesInfo name="DOI" value="10.17487/RFC3710"/>
			</reference>
			<reference anchor="RFC6702" target="https://www.rfc-editor.org/info/rfc6
			702" quoteTitle="true" derivedAnchor="RFC6702">
			<front>
			<title>Promoting Compliance with Intellectual Property Rights (IPR)
			Disclosure Rules</title>
			<author initials="T." surname="Polk" fullname="T. Polk">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre
			">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2012" month="August"/>
			<abstract>
			<t>The disclosure process for intellectual property rights (IPR) i
			n documents produced within the IETF stream is essential to the accurate develop
			ment of community consensus. However, this process is not always followed by IE
			TF participants. Regardless of the cause or motivation, noncompliance with IPR
			disclosure rules can delay or even derail completion of IETF specifications. Th
			is document describes some strategies for promoting compliance with the IPR disc
			losure rules. These strategies are primarily intended for use by area directors
			, working group chairs, and working group secretaries. This document is not an
			Internet Standards Track specification; it is published for informational purpo
			ses.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6702"/>
			<seriesInfo name="DOI" value="10.17487/RFC6702"/>
			</reference>
			<reference anchor="RFC8711" target="https://www.rfc-editor.org/info/rfc8
			711" quoteTitle="true" derivedAnchor="RFC8711">
			<front>
			<title>Structure of the IETF Administrative Support Activity, Versio
			n 2.0</title>
			<author initials="B." surname="Haberman">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Hall">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Livingood">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2020" month="February"/>
			</front>
			<seriesInfo name="BCP" value="101"/>
			<seriesInfo name="RFC" value="8711"/>
			<seriesInfo name="DOI" value="10.17487/RFC8711"/>
			</reference>
			<reference anchor="RFC8713" target="https://www.rfc-editor.org/info/rfc8
			713" quoteTitle="true" derivedAnchor="RFC8713">
			<front>
			<title>IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation,
			and Recall Process: Operation of the IETF Nominating and Recall Committees</titl
			e>
			<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>
			<reference anchor="RFC8714" target="https://www.rfc-editor.org/info/rfc8
			714" quoteTitle="true" derivedAnchor="RFC8714">
			<front>
			<title>Update to the Process for Selection of Trustees for the IETF
			Trust</title>
			<author initials="J." surname="Arkko">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="T." surname="Hardie">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="February" year="2020"/>
			</front>
			<seriesInfo name="BCP" value="101"/>
			<seriesInfo name="RFC" value="8714"/>
			<seriesInfo name="DOI" value="10.17487/RFC8714"/>
			</reference>
			<reference anchor="RFC8715" target="https://www.rfc-editor.org/info/rfc8
			715" quoteTitle="true" derivedAnchor="RFC8715">
			<front>
			<title>IETF Administrative Support Activity 2.0: Update to the Proce
			ss for Selection of Trustees for the IETF Trust</title>
			<author initials="J." surname="Arkko">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="February" year="2020"/>
			</front>
			<seriesInfo name="RFC" value="8715"/>
			<seriesInfo name="DOI" value="10.17487/RFC8715"/>
			</reference>
			</references>
			<references pn="section-6.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<reference anchor="IAB-3716-Historic" target="https://www.iab.org/docume
			nts/minutes/minutes-2019/iab-minutes-2019-03-06/" quoteTitle="true" derivedAncho
			r="IAB-3716-Historic">
			<front>
			<title>IAB Minutes 2019-03-06</title>
			<author>
			<organization showOnFrontPage="true">Internet Architecture Board</
			organization>
			</author>
			<date year="2019" month="March" day="6"/>
			</front>
			</reference>
			<reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2
			026" quoteTitle="true" derivedAnchor="RFC2026">
			<front>
			<title>The Internet Standards Process -- Revision 3</title>
			<author initials="S." surname="Bradner" fullname="S. Bradner">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="1996" month="October"/>
			<abstract>
			<t>This memo documents the process used by the Internet community
			for the standardization of protocols and procedures. It defines the stages in t
			he standardization process, the requirements for moving a document between stage
			s and the types of documents used during this process. This document specifies a
			n Internet Best Current Practices for the Internet Community, and requests discu
			ssion and suggestions for improvements.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="9"/>
			<seriesInfo name="RFC" value="2026"/>
			<seriesInfo name="DOI" value="10.17487/RFC2026"/>
			</reference>
			<reference anchor="RFC3716" target="https://www.rfc-editor.org/info/rfc3
			716" quoteTitle="true" derivedAnchor="RFC3716">
			<front>
			<title>The IETF in the Large: Administration and Execution</title>
			<author>
			<organization showOnFrontPage="true">IAB Advisory Committee</organ
			ization>
			</author>
			<date year="2004" month="March"/>
			<abstract>
			<t>In the fall of 2003, the IETF Chair and the IAB Chair formed an
			IAB Advisory Committee (AdvComm), with a mandate to review the existing IETF ad
			ministrative structure and relationships (RFC Editor, IETF Secretariat, IANA) an
			d to propose changes to the IETF management process or structure to improve the
			overall functioning of the IETF. The AdvComm mandate did not include the standa
			rds process itself. This memo provides information for the Internet community.<
			/t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="3716"/>
			<seriesInfo name="DOI" value="10.17487/RFC3716"/>
			</reference>
			<reference anchor="RFC3929" target="https://www.rfc-editor.org/info/rfc3
			929" quoteTitle="true" derivedAnchor="RFC3929">
			<front>
			<title>Alternative Decision Making Processes for Consensus-Blocked D
			ecisions in the IETF</title>
			<author initials="T." surname="Hardie" fullname="T. Hardie">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2004" month="October"/>
			<abstract>
			<t>This document proposes an experimental set of alternative decis
			ion-making processes for use in IETF working groups. There are a small number o
			f cases in IETF working groups in which the group has come to consensus that a p
			articular decision must be made but cannot agree on the decision itself. This d
			ocument describes alternative mechanisms for reaching a decision in those cases.
			This is not meant to provide an exhaustive list, but to provide a known set of
			tools that can be used when needed. This memo defines an Experimental Protocol
			for the Internet community.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="3929"/>
			<seriesInfo name="DOI" value="10.17487/RFC3929"/>
			</reference>
			<reference anchor="RFC3979" target="https://www.rfc-editor.org/info/rfc3
			979" quoteTitle="true" derivedAnchor="RFC3979">
			<front>
			<title>Intellectual Property Rights in IETF Technology</title>
			<author initials="S." surname="Bradner" fullname="S. Bradner" role="
			editor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2005" month="March"/>
			<abstract>
			<t>The IETF policies about Intellectual Property Rights (IPR), suc
			h as patent rights, relative to technologies developed in the IETF are designed
			to ensure that IETF working groups and participants have as much information abo
			ut any IPR constraints on a technical proposal as possible. The policies are al
			so intended to benefit the Internet community and the public at large, while res
			pecting the legitimate rights of IPR holders. This memo details the IETF polici
			es concerning IPR related to technology worked on within the IETF. It also desc
			ribes the objectives that the policies are designed to meet. This memo updates
			RFC 2026 and, with RFC 3978, replaces Section 10 of RFC 2026. This memo also up
			dates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including refere
			nce [2] in RFC 2418. This document specifies an Internet Best Current Practices
			for the Internet Community, and requests discussion and suggestions for improve
			ments.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="3979"/>
			<seriesInfo name="DOI" value="10.17487/RFC3979"/>
			</reference>
			<reference anchor="RFC4633" target="https://www.rfc-editor.org/info/rfc4
			633" quoteTitle="true" derivedAnchor="RFC4633">
			<front>
			<title>Experiment in Long-Term Suspensions From Internet Engineering
			Task Force (IETF) Mailing Lists</title>
			<author initials="S." surname="Hartman" fullname="S. Hartman">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2006" month="August"/>
			<abstract>
			<t>Discussion in the community has begun to question whether RFC 3
			683 and RFC 3934 provide the appropriate flexibility for managing Internet Engin
			eering Task Force (IETF) mailing lists. This document is an RFC 3933 experiment
			designed to allow the community to experiment with a broader set of tools for m
			ailing list management while trying to determine what the long-term guidelines s
			hould be. This memo defines an Experimental Protocol for the Internet community
			.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4633"/>
			<seriesInfo name="DOI" value="10.17487/RFC4633"/>
			</reference>
			<reference anchor="RFC4879" target="https://www.rfc-editor.org/info/rfc4
			879" quoteTitle="true" derivedAnchor="RFC4879">
			<front>
			<title>Clarification of the Third Party Disclosure Procedure in RFC
			3979</title>
			<author initials="T." surname="Narten" fullname="T. Narten">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2007" month="April"/>
			<abstract>
			<t>This document clarifies and updates a single sentence in RFC 39
			79. Specifically, when third party Intellectual Property Rights (IPR) disclosur
			es are made, the intention is that the IETF Executive Director notify the IPR ho
			lder that a third party disclosure has been filed, and to ask the IPR holder whe
			ther they have any disclosure that needs to be made, per applicable RFC 3979 rul
			es. This document specifies an Internet Best Current Practices for the Internet
			Community, and requests discussion and suggestions for improvements.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4879"/>
			<seriesInfo name="DOI" value="10.17487/RFC4879"/>
			</reference>
			<reference anchor="RFC8179" target="https://www.rfc-editor.org/info/rfc8
			179" quoteTitle="true" derivedAnchor="RFC8179">
			<front>
			<title>Intellectual Property Rights in IETF Technology</title>
			<author initials="S." surname="Bradner" fullname="S. Bradner">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Contreras" fullname="J. Contreras">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="May"/>
			<abstract>
			<t>The IETF policies about Intellectual Property Rights (IPR), suc
			h as patent rights, relative to technologies developed in the IETF are designed
			to ensure that IETF working groups and participants have as much information as
			possible about any IPR constraints on a technical proposal as early as possible
			in the development process. The policies are intended to benefit the Internet c
			ommunity and the public at large, while respecting the legitimate rights of IPR
			holders. This document sets out the IETF policies concerning IPR related to tec
			hnology worked on within the IETF. It also describes the objectives that the po
			licies are designed to meet. This document updates RFC 2026 and, with RFC 5378,
			replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 487
			9.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="79"/>
			<seriesInfo name="RFC" value="8179"/>
			<seriesInfo name="DOI" value="10.17487/RFC8179"/>
			</reference>
			</references>
			</references>
			<section anchor="Acknowledgments" numbered="false" toc="include" removeInRFC
			="false" pn="section-appendix.a">
			<name slugifiedName="name-acknowledgments">Acknowledgments</name>
			<t pn="section-appendix.a-1"> <contact fullname="Brian Carpenter's"/> care
			ful checking and identification of
	documents that did, and did not, require consideration was		documents that did, and did not, require consideration was
	essential to the draft in its current form. He also made		essential to the document in its current form. He also made
	several other significant contributions. Bob Hinden also		several other significant contributions. <contact fullname="Bob
			Hinden"/> also
	gave the document a careful reading and made useful		gave the document a careful reading and made useful
	suggestions. In additional to the above, Alissa Cooper,		suggestions. In additional to the above, <contact fullname="Ali
	Eliot Lear, Heather Flanagan (the RFC Series Editor), and the		ssa Cooper"/>,
			<contact fullname="Eliot Lear"/>, <contact fullname="Heather Fla
			nagan"/> (the RFC Series Editor), and the
	current membership to the IAB helped sort out the handing of		current membership to the IAB helped sort out the handing of
	RFC 3716.</t>		RFC 3716.</t>
	</section>		</section>
			<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
	<section title="Contributors">		ndix.b">
	<t>Jason Livingood did the hard work of identifying the		<name slugifiedName="name-contributors">Contributors</name>
			<t pn="section-appendix.b-1"><contact fullname="Jason Livingood"/> did the
			hard work of identifying the
	documents that required updating and supplied considerable		documents that required updating and supplied considerable
	text used in this document.</t>		text used in this document.</t>
	</section>
	<section anchor="IANA" title="IANA Considerations">
	<t><cref> RFC Editor: Please remove this section before
	publication.</cref></t>
	<t>This memo includes no requests to or actions for IANA.</t>
	</section>		</section>
			<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
	<section anchor="Security" title="Security Considerations">		="include" pn="section-appendix.c">
	<t>The changes specified in this document are matters of		<name slugifiedName="name-authors-address">Author's Address</name>
	terminology and organizational structure derived from		<author fullname="John C Klensin" initials="J." surname="Klensin" role="ed
	documents it references. It should have no effect on		itor">
	Internet security.</t>		<organization showOnFrontPage="true"/>
			<address>
			<postal>
			<street>1770 Massachusetts Ave, Ste 322</street>
			<city>Cambridge</city>
			<region>MA</region>
			<code>02140</code>
			<country>USA</country>
			</postal>
			<phone>+1 617 245 1457</phone>
			<email>john-ietf@jck.com</email>
			</address>
			</author>
	</section>		</section>
	</middle>
	<!-- *****BACK MATTER ***** -->
	<back>
	<references title="Normative References">
	<!-- &rfc2119; -->
	&rfc2028;
	&rfc2418;
	&rfc3005;
	<!-- &rfc4844; -->
	<!-- &rfc5377; -->
	&rfc3710;
	&rfc6702;
	<!-- &rfc7500; -->
	<reference anchor="RFC-Struct"
	target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc4
	071bis/">
	<front>
	<title>Structure of the IETF Administrative Support Activity, Version
	2.0</title>
	<author initials="B." surname="Haberman">
	<organization></organization>
	<address/>
	</author>
	<author initials="J." surname="Hall">
	<organization></organization>
	<address/>
	</author>
	<author initials="J." surname="Livingood">
	<organization></organization>
	<address/>
	</author>
	<date year="2018" month="December" day="5" />
	</front>
	</reference>
	<!--
	<reference anchor="RFC-StructS3"
	target="https://tools.ietf.org/html/draft-ietf-iasa2-struct-06
	#section-3">
	<front>
	<title>Structure of the IETF Administrative Support Activity, Version
	2.0</title>
	<author initials="B." surname="Haberman">
	<organization></organization>
	<address/>
	</author>
	<author initials="J." surname="Hall">
	<organization></organization>
	<address/>
	</author>
	<author initials="J." surname="Livingood">
	<organization></organization>
	<address/>
	</author>
	<date year="2018" month="December" day="5" />
	</front>
	</reference> -->
	<reference anchor="RFC-trust-update"
	target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-u
	pdate/">
	<front>
	<title>Update to the Process for Selection of Trustees for
	the IETF Trust</title>
	<author initials="J." surname="Arkko">
	<organization></organization>
	<address/>
	</author>
	<author initials="T." surname="Hardie">
	<organization></organization>
	<address/>
	</author>
	<date year="2018" />
	</front>
	</reference>
	<reference anchor="RFC-trust-rationale"
	target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-rational
	e/">
	<front>
	<title>Discussion of the IASA 2.0 Changes as They Relate to
	the IETF Trust</title>
	<author initials="J." surname="Arkko">
	<organization></organization>
	<address/>
	</author>
	<date year="2018" />
	</front>
	</reference>
	<reference anchor="LLC-Agreement"
	target="https://www.ietf.org/documents/180/IETF-LLC-Agreement.pdf">
	<front>
	<title>Limited Liability Company Agreement of IETF Administration LLC<
	/title>
	<author >
	<organization>IETF Administration LLC</organization>
	<address/>
	</author>
	<date year="2018" month="August" day="28"/>
	</front>
	</reference>
	<reference anchor="RFC-7437bis"
	target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc7
	437bis/">
	<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></organization>
	<address/> </author>
	<author initials="R." surname="Hinden" role="editor">
	<organization></organization>
	<address/> </author>
	<author initials="J." surname="Livingood" role="editor">
	<organization></organization>
	<address/>
	</author>
	<date year="2018" />
	</front>
	</reference>
	</references>
	<references title="Informative References">
	&rfc2026;
	&rfc3716;
	&rfc3929;
	&rfc3979;
	&rfc4633;
	&rfc4879;
	&rfc8179;
	</references>
	<!-- Sections below here become Appendices. -->
	<section title="Change Log" anchor="ChangeLog">
	<t>RFC Editor: Please remove this appendix before
	publication.</t>
	<section title="Changes from version -00 (2018-11-15) to -01">
	<t><list style="symbols">
	<t> Removed RFCs 3979 and 4879 from the "obsoletes" list
	because they had already been obsoleted (by 8179)
	. It
	also removes RFC 8179 from the "updates" list bec
	ause
	8179 uses "IETF Secretariat" terminology rather t
	han
	"IETF Executive Director".
	<vspace blankLines="1"/> <cref> Note in Draft: That
	suggests an idea which might considerably mitigat
	e the
	name confusion issue: Instead of singling out the
	Managing Director of the Secretariat as a named
	individual, perhaps we should be referring to the
	Secretariat itself, leaving the contact point or
	address up to them as an internal administrative
	matter. Just a thought. --JcK</cref></t>
	<t> Added text to explain why RFC 2026 is not on the hit
	list.</t>
	<t> Added an acknowledgment to Brian Carpenter. If he
	catches another batch of errors and supplies text
	, he
	gets promoted to Contributor.</t>
	<t> Adjusted reference [RFC-Struct] to point to 4071bis.
	</t>
	<t> Minor editorial corrections and changes. </t>
	</list></t>
	</section>
	<section title="Changes from version -01 (dated 2018-12-06 but
	posted 2012-12-07) to -02">
	<t> I accidentally omitted RFC 4844 from the document
	header "updates" list in Version 01 and noticed t
	hat
	in response to an unrelated question almost
	immediately after posting. The correction seeme
	d
	important enough to justify almost immediate
	re-posting. Changes are only that header, the
	document file name, and the date. --JcK </t>
	</section>
	<section title="Changes from version -02 (2018-12-07) to -03">
	<t><list style="symbols">
	<t> Removed discussion and pointers to RFC 7500 - IAB
	will publish separately. </t>
	<t> Added text to describe (very superficially) RFC 3716
	.
	That document was obsoleted in the previous vers
	ion
	but not described.</t>
	<t> Removed rant about titles and responsibilities from
	<xref target="ExecDir-Managing"/> and a subsequen
	t
	editorial note I hope it is no longer needed --Jc
	K.
	In additional, several blocks of text that were
	commented out in earlier versions of the XML have
	been
	removed entirely.</t>
	</list></t>
	</section>
	<section title="Changes from version -03 (2018-12-12) to -04">
	<t><list style="symbols">
	<t> Removed RFC 4844 from the update list and discussion
	because the consensus in the WG seemed to be that
	it
	(and the RFC Editor) should be handled separately
	. </t>
	<t> Removed RFC 5377 from the update list and discussion
	because it involves the Trust. </t>
	<t> Editor's note in draft:
	<list style="empty">
	<t> The above changes and the earlier removal
	of RFC 7500
	so the IAB could publish it own d
	ocument completely
	eliminate the earlier Sections 2
	and 3. That may call
	for a revision of the Introductio
	n and/or Abstract, but I
	have not done a review for this i
	teration of
	whether such changes are needed.<
	/t>
	<t> As documents and references are
	shuffled in and out of this one,
	it occurred to me
	that having a non-normative appen
	dix somewhere that
	would identify all of the documen
	ts containing changes
	to reflect the IASA 1.x to 2.0 tr
	ansition would be of
	great help to any future historia
	n trying to
	understand what we did and probab
	ly helpful to the
	IETF if some of these changes don
	't work out and/or
	require further tuning. After a
	brief discussion,
	Jason and I concluded that append
	ix did not belong in
	this iteration of this document.<
	/t>
	</list></t>
	</list></t>
	</section>
	<section title="Changes from version -04 (2019-01-17) to -05">
	<t><list style="symbols">
	<t> Changed title from "Consolidated IASA2-Related
	Document Updates" to "Consolidated IASA 2.0 Upda
	tes of IETF
	Administrative Terminology" per suggestions from
	Brian
	Carpenter and Bob Hinden and 2019-01-31 WG decis
	ion.</t>
	<t> Removed CREF from <xref target="Intro"/> (should ha
	ve
	been done in -04). The only remaining CREFs are
	the one in
	this section (above) that should probably be
	preserved through IETF Last Call and notes to th
	e RFC Editor. </t>
	<t> Updated acknowledgments.</t>
	</list></t>
	</section>
	<section title="Changes from version -05 (2019-01-31) to -06">
	<t><list style="symbols">
	<t> Changes to text about documents that are updated an
	d
	made historic, per advice from RFC Editor, WG
	Chairs, and IAB. This includes a statement abou
	t IAB
	action of 2019-03-06 that requests that the RFC
	Editor move RFC 3716 to Historic but does not ob
	solete that
	Informational report. When minimal changes were
	attempted, <xref target="MakeHistoric"/> became
	very
	hard to read and hence was restructured and some
	what
	rewritten (and then further modified to work aro
	und
	an xml2rfc glitch). Special attention should be
	paid
	to the note at the beginning of that section.</t
	>
	<t> Updated the Acknowledgments section.</t>
	</list></t>
	</section>
	<section title="Changes from version -06 (2019-03-06) to -07">
	<t><list style="symbols">
	<t> Moved RFCs 3929 and 4633 from "obsoleted" to
	"updated" and stripped text requested that they
	be
	made Historic at the direction of the IETF Chair
	, WG
	Co-chair, and an author. </t>
	<t> Added a section number for a document listed in
	Section 2 that was missing.</t>
	<t> Added some notes to the RFC Editor and others.</t>
	<t> Updated the acknowledgments.</t>
	</list></t>
	</section>
	<!-- <section title="Changes from version -07 (2019-03-11) to
	-08">
	<t><list style="symbols">
	<t> ... </t>
	</list></t>
	</section> -->
	</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 30 change blocks.
	684 lines changed or deleted		729 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/