rfc8716xml2.original.xml		rfc8716.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="bcp" conse
			nsus="true" docName="draft-ietf-iasa2-rfc7776bis-03" indexInclude="true" ipr="tr
	<!ENTITY RFC4071 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		ust200902" number="8716" prepTime="2020-02-26T17:07:15" scripts="Common,Latin" s
	.4071.xml">		ortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="tru
	<!ENTITY RFC4371 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		e" updates="7776" xml:lang="en">
	.4371.xml">		<link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc7776bis-03" r
	<!ENTITY RFC7979 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		el="prev"/>
	.7979.xml">		<link href="https://dx.doi.org/10.17487/rfc8716" rel="alternate"/>
	<!ENTITY I-D.ietf-iasa2-struct SYSTEM "http://xml.resource.org/public/rfc/bibxml		<link href="urn:issn:2070-1721" rel="alternate"/>
	3/reference.I-D.ietf-iasa2-struct.xml">
	]>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc strict="yes" ?>
	<?rfc toc="yes"?>
	<?rfc tocdepth="4"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes" ?>
	<?rfc compact="yes" ?>
	<?rfc subcompact="no" ?>
	<rfc category="info" docName="draft-ietf-iasa2-trust-rationale-03" ipr="trust200
	902">
	<front>		<front>
			<title abbrev="Anti-Harassment LLC Update">Update to the IETF Anti-Harassmen
	<title abbrev="IASA 2.0 and IETF Trust">		t Procedures for the Replacement of the IETF Administrative Oversight Committee
	Discussion of the IASA 2.0 Changes as They Relate to the IETF		(IAOC) with the IETF Administration LLC</title>
	Trust</title>		<seriesInfo name="RFC" value="8716" stream="IETF"/>
			<seriesInfo name="BCP" value="25" stream="IETF"/>
	<author fullname="Jari Arkko" initials="J."		<author fullname="Pete Resnick" initials="P." surname="Resnick">
	surname="Arkko">		<organization showOnFrontPage="true">Episteme Technology Consulting LLC</o
	<organization>Ericsson</organization>		rganization>
	<address>		<address>
	<postal>		<postal>
	<street></street>		<street>503 West Indiana Avenue</street>
			<city>Urbana</city>
	<city>Kauniainen</city>		<region>Illinois</region>
			<country>United States of America</country>
	<region></region>		<code>61801-4941</code>
	<code>02700</code>
	<country>Finland</country>
	</postal>		</postal>
			<phone>+1 217 337 1905</phone>
	<email>jari.arkko@piuha.net</email>		<email>resnick@episteme.net</email>
	</address>		</address>
	</author>		</author>
			<author fullname="Adrian Farrel" initials="A." surname="Farrel">
	<date month="October" year="2018" />		<organization showOnFrontPage="true">Old Dog Consulting</organization>
			<address>
			<email>adrian@olddog.co.uk</email>
			</address>
			</author>
			<date month="02" year="2020"/>
	<area>General</area>		<area>General</area>
			<workgroup>IASA 2.0</workgroup>
	<workgroup>Internet Engineering Task Force</workgroup>		<keyword>Harassment</keyword>
			<keyword>Ombudsteam</keyword>
	<abstract>		<keyword>IAOC</keyword>
			<keyword>IETF Administration LLC</keyword>
	<t>This document is published to capture the rationale for the		<keyword>IASA</keyword>
	changes introduced in RFC NNNN (RFC Editor: please replace NNNN		<abstract pn="section-abstract">
	with the RFC number of <xref		<t pn="section-abstract-1">The IETF Anti-Harassment Procedures are describ
	target="I-D.ietf-iasa2-trust-update"/>), Update to the Process for Selecti		ed in RFC 7776.</t>
	on		<t pn="section-abstract-2">The IETF Administrative Oversight Committee (IA
	of Trustees for the IETF Trust.</t>		OC) has been replaced by the IETF Administration LLC, and the IETF Administrativ
			e Director has been replaced by the IETF LLC Executive Director. This document
	<t>At the time RFC NNNN was published, IETF administrative		updates RFC 7776 to amend these terms.</t>
	structure changes ("IASA 2.0") had an impact on the IETF		<t pn="section-abstract-3">RFC 7776 contained updates to RFC 7437. RFC 87
	Trust because members of the IETF Administrative Oversight		13 has incorporated those updates, so this document also updates RFC 7776 to rem
	Committee (IAOC), which was being phased out, had served as		ove those updates.</t>
	Trustees of the IETF Trust. This document provides
	background on the past IETF Trust arrangements, explains the
	effect of the rules in the founding documents during the
	transition to the new arrangement, and provides a rationale for
	the update.</t>
	</abstract>		</abstract>
			<boilerplate>
			<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
			"exclude" pn="section-boilerplate.1">
			<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
			>
			<t pn="section-boilerplate.1-1">
			This 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/rfc8716" 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-changes-to-rfc-7776">Chan
			ges to RFC 7776</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.2.2">
			<li pn="section-toc.1-1.2.2.1">
			<t keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derive
			dContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-changes-to-se
			ction-34">Changes to Section 3.4</xref></t>
			</li>
			<li pn="section-toc.1-1.2.2.2">
			<t keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derive
			dContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-changes-to-se
			ction-5">Changes to Section 5</xref></t>
			</li>
			<li pn="section-toc.1-1.2.2.3">
			<t keepWithNext="true" pn="section-toc.1-1.2.2.3.1"><xref derive
			dContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-changes-to-re
			ferences-to-rf">Changes to References to RFC 7437</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
			ction-toc.1-1.2.2.3.2">
			<li pn="section-toc.1-1.2.2.3.2.1">
			<t keepWithNext="true" pn="section-toc.1-1.2.2.3.2.1.1"><xre
			f derivedContent="2.3.1" format="counter" sectionFormat="of" target="section-2.3
			.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-c
			hanges-to-metadata">Changes to Metadata</xref></t>
			</li>
			<li pn="section-toc.1-1.2.2.3.2.2">
			<t keepWithNext="true" pn="section-toc.1-1.2.2.3.2.2.1"><xre
			f derivedContent="2.3.2" format="counter" sectionFormat="of" target="section-2.3
			.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-c
			hanges-to-the-abstract">Changes to the Abstract</xref></t>
			</li>
			<li pn="section-toc.1-1.2.2.3.2.3">
			<t keepWithNext="true" pn="section-toc.1-1.2.2.3.2.3.1"><xre
			f derivedContent="2.3.3" format="counter" sectionFormat="of" target="section-2.3
			.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-c
			hanges-to-section-51">Changes to Section 5.1</xref></t>
			</li>
			</ul>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.3">
			<t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent
			="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA
			Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.4">
			<t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent
			="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-security-considerations">
			Security Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.5">
			<t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent
			="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-references">References</x
			ref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.5.2">
			<li pn="section-toc.1-1.5.2.1">
			<t keepWithNext="true" pn="section-toc.1-1.5.2.1.1"><xref derive
			dContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-normative-ref
			erences">Normative References</xref></t>
			</li>
			<li pn="section-toc.1-1.5.2.2">
			<t keepWithNext="true" pn="section-toc.1-1.5.2.2.1"><xref derive
			dContent="5.2" format="counter" sectionFormat="of" target="section-5.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.6">
			<t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent
			="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedC
			ontent="" format="title" sectionFormat="of" target="name-acknowledgements">Ackno
			wledgements</xref></t>
			</li>
			<li pn="section-toc.1-1.7">
			<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
			="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedC
			ontent="" format="title" sectionFormat="of" target="name-authors-addresses">Auth
			ors' Addresses</xref></t>
			</li>
			</ul>
			</section>
			</toc>
	</front>		</front>
	<middle>		<middle>
			<section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn
	<section title="Introduction">		="section-1">
			<name slugifiedName="name-introduction">Introduction</name>
	<t>This document is published to capture the rationale for the		<t pn="section-1-1">The IETF Anti-Harassment Procedures are described in R
	changes introduced in <xref		FC 7776 <xref target="RFC7776" format="default" sectionFormat="of" derivedConten
	target="I-D.ietf-iasa2-trust-update"/>.</t>		t="RFC7776"/>. Those procedures include direction for the IETF Chair and Ombuds
			team to take advice from the IETF Administrative Oversight Committee (IAOC) with
	<t>At the time <xref target="I-D.ietf-iasa2-trust-update"/> was		respect to the budget available for training.</t>
	published, IETF administrative structure changes ("IASA 2.0")		<t pn="section-1-2">The IAOC has been replaced by the IETF Administration
	had an impact on the IETF Trust <xref target="RFC4071"/> <xref		LLC, and the IETF Administrative Director has been replaced by the IETF LLC Exec
	target="RFC4371"/> <xref target="I-D.ietf-iasa2-struct"/>. This		utive Director. This document updates RFC 7776 to amend these terms and to upda
	is because members of the IETF Administrative		te a reference.</t>
	Oversight Committee (IAOC), which was being phased out, had		<t pn="section-1-3">RFC 7776 contained updates to <xref target="RFC7437" f
	served as Trustees of the IETF Trust. A minimal change		ormat="default" sectionFormat="of" derivedContent="RFC7437"/>. <xref target="RF
	regarding the selection of the trustees is implemented by <xref		C8713" format="default" sectionFormat="of" derivedContent="RFC8713"/> has incorp
	target="I-D.ietf-iasa2-trust-update"/>.</t>		orated those updates, so this document also updates RFC 7776 to remove those upd
			ates.</t>
	<t>This companion memo provides some background on the details		<t pn="section-1-4">This document makes no other changes to the procedures
	of the past IETF Trust arrangements, explains the effect of		described in RFC 7776.</t>
	the rules in the founding documents during the transition to the new
	arrangement, and provides a rationale for the update.</t>
	</section>
	<section anchor="background" title="Background">
	<t>The purpose of the IETF Trust is to acquire, hold, maintain,
	and license certain existing and future intellectual property
	and other property used in connection with the administration of
	the IETF <xref target="RFC4371"/>. The intellectual property is,
	for instance, rights that the IETF contributors grant for text
	in RFCs and Internet-Drafts. The IETF Trust also manages
	trademarks such as "IETF" and domain names such as
	"ietf.org". The IETF Trust is also serving the broader Internet
	community by holding domains and trademarks associated with
	Internet Assigned Numbers Authority (IANA) <xref
	target="RFC7979"/>.</t>
	<t>The IETF Trust is a legal entity, registered in the
	Commonwealth of Virginia <xref target="Trust-FD"/>.</t>
	<t>Previously, the members of the IAOC also served as ex officio
	Trustees of the IETF Trust. The founding documents specify
	persons eligible to become trustees as having to be then-current
	members of the IAOC <xref target="Trust-FD"/>. The documents
	also specify that if for any reason there are fewer than three
	individuals serving as Trustees, then the Internet Engineering
	Steering Group (IESG), or the IESG's successor as the leadership
	of the IETF, shall appoint one or more individuals to serve in a
	temporary capacity as Trustee(s) until eligible persons can be found.</t>
	<t>In the previous system there were eight IAOC members. Two were
	named by the IETF Nominating Committee (NomCom), one by the
	IESG, one by the Internet Architecture Board (IAB), and one by
	the Internet Society (ISOC) Board of Trustees. In addition, there
	were three ex officio members via their roles as IETF Chair, ISOC CEO,
	and IAB Chair. In addition, the IETF Administrative Director (IAD)
	served also as one of the trustees.</t>
	</section>
	<section anchor="approach" title="General Approach">
	<t>There were two basic approaches to resolving the issue with
	the trustees, when the IAOC ceased to exist. One could have imagined
	merging all IETF Trust functions in the new IASA structure and
	under the new legal entity. This memo advocated a second
	approach where the IETF Trust is kept independent.</t>
	<t>The rationale for advocating the second approach is in part
	to minimize changes to the IETF Trust while the IETF's
	administrative structure is undergoing major change. In
	addition, the IETF Trust and other administrative IETF processes
	are quite different. While very important, the IETF Trust is a
	low-activity entity where changes are minimal and gradual, and
	there are no pressing issues.</t>
	</section>
	<section anchor="selection" title="Changing the Way Trustees Are Selected">
	<t>At the time when the trustees served on both the IETF Trust and the
	IAOC, many of the requirements for naming a particular group of
	people were driven by the IAOC's requirements. For the IETF
	Trust in the new model, some of those arrangements were able to be
	rethought, both in terms of the number and source of the
	trustees, as well as the desired qualifications and length of
	terms.</t>
	<t>Several options were possible, of course. A newly designed
	naming process could have been devised. The argument here is for a relativ
	ely
	limited change, however, largely on the basis of the IETF Trust
	arrangements generally working well, and on the relatively modest
	expected time commitments combined with the need for very careful
	management of the assets.</t>
	<t>As a result, a smaller group of trustees appeared sufficient.</t>
	<t>In addition, the terms for the
	trustees selected from the IETF community could be set to longer than
	the two year period typical of other IETF bodies.</t>
	<t>One could have continued the practice of having the chairs and CEOs
	from IETF, IAB, and Internet Society be trustees as well, but
	this may not be necessary. In general, the tasks of the IETF
	Trust are well defined, and while there is a need for
	coordination, it does not need to be at the level of chairs or
	CEOs.</t>
	<t>Given all this, one approach was to have trustees appointed
	by the NomCom, IESG, and ISOC Board of Trustees. (One might also
	have considered the IETF Administration LLC legal entity instead
	of the Internet Society for this role. But the Internet Society
	is perhaps more suitable for the role, given their focus on the
	broad use of the IETF Trust assets and not merely administrative
	aspects).</t>
	<t>If the same principles would continue to be used as were used
	in previous appointments, then appointments performed by the
	NomCom would need to be confirmed by another entity, which could
	be, for instance, either the IESG or the IAB. The IESG had
	previously been the confirming body for the IAOC, so it has been
	retained in that role for the trustees.</t>
	</section>
	<section anchor="transition" title="Transition">
	<t>When the new entity for IETF Administration LLC was set up,
	the IAOC was expected to be discontinued soon
	thereafter. Fortunately, there was no pressing need to change
	all the components of the IAOC and its dependent organizations
	at the same time. As discussed above (<xref
	target="background"/>), the IESG holds the ability to continue
	to name trustees. And once the updated procedures were in place,
	the IETF Trust had its management nominated in the usual manner,
	and the exceptional IESG process was no longer needed.</t>
	</section>		</section>
			<section anchor="changes" numbered="true" toc="include" removeInRFC="false"
	<section title="Security Considerations">		pn="section-2">
			<name slugifiedName="name-changes-to-rfc-7776">Changes to RFC 7776</name>
	<t>This memo has no security implications for the Internet.</t>		<section anchor="changes3" numbered="true" toc="include" removeInRFC="fals
			e" pn="section-2.1">
			<name slugifiedName="name-changes-to-section-34">Changes to Section 3.4<
			/name>
			<t pn="section-2.1-1"><xref target="RFC7776" section="3.4" sectionFormat
			="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7776#section-3
			.4" derivedContent="RFC7776"/> is about the qualifications and training of the O
			mbudsteam. The last paragraph of that section is replaced as follows:</t>
			<t pn="section-2.1-2">OLD
			</t>
			<blockquote pn="section-2.1-3">In determining the appropriate training,
			the IETF Chair and Ombudsteam shall take professional advice and will consult wi
			th the IETF Administrative Oversight Committee (IAOC) with respect to the overal
			l IETF budget.</blockquote>
			<t pn="section-2.1-4">NEW
			</t>
			<blockquote pn="section-2.1-5">In determining the appropriate training,
			the IETF Chair and Ombudsteam shall take professional advice and will consult wi
			th the IETF Administration LLC with respect to the overall IETF budget.</blockqu
			ote>
			<t pn="section-2.1-6">END</t>
			</section>
			<section anchor="changes5" numbered="true" toc="include" removeInRFC="fals
			e" pn="section-2.2">
			<name slugifiedName="name-changes-to-section-5">Changes to Section 5</na
			me>
			<t pn="section-2.2-1"><xref target="RFC7776" section="5" sectionFormat="
			of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7776#section-5"
			derivedContent="RFC7776"/> is about remedies available to the Ombudsteam. The l
			ast paragraph of that section is replaced as follows:</t>
			<t pn="section-2.2-2">OLD
			</t>
			<blockquote pn="section-2.2-3">Where specific action is required to ensu
			re that a remedy is realized or enforced, the Ombudsteam will make a request in
			writing to the IETF Secretariat and/or IETF Administrative Director (IAD) to tak
			e action as appropriate.</blockquote>
			<t pn="section-2.2-4">NEW
			</t>
			<blockquote pn="section-2.2-5">Where specific action is required to ensu
			re that a remedy is realized or enforced, the Ombudsteam will make a request in
			writing to the IETF Secretariat and/or IETF LLC Executive Director to take actio
			n as appropriate.</blockquote>
			<t pn="section-2.2-6">END</t>
			</section>
			<section anchor="changesref" numbered="true" toc="include" removeInRFC="fa
			lse" pn="section-2.3">
			<name slugifiedName="name-changes-to-references-to-rf">Changes to Refere
			nces to RFC 7437</name>
			<t pn="section-2.3-1">RFC 7776 updated RFC 7437 <xref target="RFC7437" f
			ormat="default" sectionFormat="of" derivedContent="RFC7437"/> by allowing the Om
			budsteam to form a recall petition. This document does not change any of the as
			sociated processes. However,
			during the process of documenting the replacement of the IAOC by
			the IETF Administration LLC, RFC 7437 has been obsoleted by <xref target="RFC871
			3" format="default" sectionFormat="of" derivedContent="RFC8713"/>, and as part
			of that work, <xref target="RFC8713" format="default" sectionForm
			at="of" derivedContent="RFC8713"/> has included the update from RFC 7776.</t>
			<t pn="section-2.3-2">This document updates RFC 7776 to remove the updat
			e of RFC 7437.</t>
			<section anchor="changemeta" numbered="true" toc="include" removeInRFC="
			false" pn="section-2.3.1">
			<name slugifiedName="name-changes-to-metadata">Changes to Metadata</na
			me>
			<t pn="section-2.3.1-1">The following change is made to the metadata a
			t the head of <xref target="RFC7776" format="default" sectionFormat="of" derived
			Content="RFC7776"/>:</t>
			<t pn="section-2.3.1-2">OLD
			</t>
			<blockquote pn="section-2.3.1-3">Updates: 2418, 7437</blockquote>
			<t pn="section-2.3.1-4">NEW
			</t>
			<blockquote pn="section-2.3.1-5">Updates: 2418</blockquote>
			<t pn="section-2.3.1-6">END</t>
			</section>
			<section anchor="changeab" numbered="true" toc="include" removeInRFC="fa
			lse" pn="section-2.3.2">
			<name slugifiedName="name-changes-to-the-abstract">Changes to the Abst
			ract</name>
			<t pn="section-2.3.2-1">The following change is made to text in the Ab
			stract of <xref target="RFC7776" format="default" sectionFormat="of" derivedCont
			ent="RFC7776"/>:</t>
			<t pn="section-2.3.2-2">DELETE
			</t>
			<blockquote pn="section-2.3.2-3">This document updates RFC 7437 by all
			owing the Ombudsteam to form a recall petition without further signatories.</blo
			ckquote>
			<t pn="section-2.3.2-4">END</t>
			</section>
			<section anchor="change5-1" numbered="true" toc="include" removeInRFC="f
			alse" pn="section-2.3.3">
			<name slugifiedName="name-changes-to-section-51">Changes to Section 5.
			1</name>
			<t pn="section-2.3.3-1">The following change is made to text in <xref
			target="RFC7776" section="5.1" sectionFormat="of" format="default" derivedLink="
			https://rfc-editor.org/rfc/rfc7776#section-5.1" derivedContent="RFC7776"/>:</t>
			<t pn="section-2.3.3-2">OLD
			</t>
			<blockquote pn="section-2.3.3-3">
			<ul spacing="normal" bare="false" empty="false" pn="section-2.3.3-3.
			1">
			<li pn="section-2.3.3-3.1.1">Many IETF management positions are ap
			pointed by the NomCom with confirmation from the IESG, IAB, or ISOC. <xref targ
			et="RFC7437" format="default" sectionFormat="of" derivedContent="RFC7437"/> desc
			ribes the
			recall procedure for such appointments. This document upd
			ates <xref target="RFC7437" format="default" sectionFormat="of" derivedContent="
			RFC7437"/> by allowing the Ombudsteam to form a recall petition on
			its own and without requiring 20 signatories from the comm
			unity. Such a petition shall be treated in all ways like any other recall petit
			ion as
			described in <xref target="RFC7437" format="default" secti
			onFormat="of" derivedContent="RFC7437"/>: that is, the fact of the petition and
			its signatories (the Ombudsteam) shall be announced to the IETF
			community, and a Recall Committee Chair shall be appointed
			to complete the Recall Committee process. It is expected that the Recall Commi
			ttee will
			receive a briefing from the Ombudsteam explaining why reca
			ll is considered an appropriate remedy.</li>
			</ul>
			</blockquote>
			<t pn="section-2.3.3-4">NEW
			</t>
			<blockquote pn="section-2.3.3-5">
			<ul spacing="normal" bare="false" empty="false" pn="section-2.3.3-5.
			1">
			<li pn="section-2.3.3-5.1.1">The Ombudsteam may form a recall peti
			tion on its own without requiring signatures from the community as described in
			<xref target="RFC8713" format="default" sectionFormat="of" derivedContent="RFC87
			13"/>.</li>
			</ul>
			</blockquote>
			<t pn="section-2.3.3-6">END</t>
			</section>
			</section>
	</section>		</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-3">
	<section title="IANA Considerations">		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
			<t pn="section-3-1">This document has no IANA actions.</t>
	<t>This memo requests no action from IANA.</t>
	</section>		</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-4">
	<section anchor="ack" title="Acknowledgements">		<name slugifiedName="name-security-considerations">Security Considerations
			</name>
	<t>The author would like to thank other members of the earlier		<t pn="section-4-1">This document has no implications for Internet securit
	IASA 2.0 design team who were Brian Haberman, Eric Rescorla,		y.</t>
	Jason Livingood, Joe Hall, and Leslie Daigle. The authors would
	also like to thank Alissa Cooper, Ted Hardie, Andrew Sullivan,
	Brian Carpenter, Lucy Lynch, and John Levine for interesting
	discussions in this problem space, and Adrian Farrel, Tero
	Kivinen, Russ Housley, Benjamin Kaduk, Adam Roach and Meral
	Shirazipour for careful review.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<references pn="section-5">
	<references title="Normative References">		<name slugifiedName="name-references">References</name>
	&RFC4071;		<references pn="section-5.1">
	&RFC4371;		<name slugifiedName="name-normative-references">Normative References</na
	</references>		me>
			<reference anchor="RFC7776" target="https://www.rfc-editor.org/info/rfc7
	<references title="Informative References">		776" quoteTitle="true" derivedAnchor="RFC7776">
			<front>
	&RFC7979;		<title>IETF Anti-Harassment Procedures</title>
	&I-D.ietf-iasa2-struct;		<author initials="P." surname="Resnick" fullname="P. Resnick">
			<organization showOnFrontPage="true"/>
	<reference anchor='I-D.ietf-iasa2-trust-update'>		</author>
	<front>		<author initials="A." surname="Farrel" fullname="A. Farrel">
	<title>Update to the Selection of Trustees for the IETF Trust</title>		<organization showOnFrontPage="true"/>
			</author>
	<author initials='J' surname='Arkko' fullname='Jari Arkko'>		<date year="2016" month="March"/>
	<organization />		<abstract>
	</author>		<t>IETF Participants must not engage in harassment while at IETF m
			eetings, virtual meetings, or social events or while participating in mailing li
	<author initials='T' surname='Hardie' fullname='Ted Hardie'>		sts. This document lays out procedures for managing and enforcing this policy.<
	<organization />		/t>
	</author>		<t>This document updates RFC 2418 by defining new working group gu
			idelines and procedures. This document updates RFC 7437 by allowing the Ombudst
	<date month='September' year='2018' />		eam to form a recall petition without further signatories.</t>
			</abstract>
	</front>		</front>
	<seriesInfo name='Internet-Draft' value='draft-ietf-iasa2-trust-update-00		<seriesInfo name="BCP" value="25"/>
	' />		<seriesInfo name="RFC" value="7776"/>
	<format type='TXT'		<seriesInfo name="DOI" value="10.17487/RFC7776"/>
	target='http://www.ietf.org/internet-drafts/draft-ietf-iasa2-trus		</reference>
	t-update-00.txt' />		<reference anchor="RFC8713" target="https://www.rfc-editor.org/info/rfc8
	</reference>		713" quoteTitle="true" derivedAnchor="RFC8713">
			<front>
	<reference anchor="Trust-FD">		<title>IAB, IESG, and IETF LLC Selection, Confirmation, and Recall P
	<front>		rocess: Operation of the IETF Nominating and Recall Committees</title>
	<title>Founding Documents</title>		<author initials="M." surname="Kucherawy" role="editor">
	<author surname="IETF Trust"></author>		<organization showOnFrontPage="true"/>
	<date month='February' year='2014 (https://trustee.ietf.org/founding-do		</author>
	cuments.html)'/>		<author initials="R." surname="Hinden" role="editor">
	</front>		<organization showOnFrontPage="true"/>
	<format type='HTML'		</author>
	target='https://trustee.ietf.org/founding-documents.html'/>		<author initials="J." surname="Livingood" role="editor">
	</reference>		<organization showOnFrontPage="true"/>
			</author>
			<date month="February" year="2020"/>
			</front>
			<seriesInfo name="BCP" value="10"/>
			<seriesInfo name="RFC" value="8713"/>
			<seriesInfo name="DOI" value="10.17487/RFC8713"/>
			</reference>
			</references>
			<references pn="section-5.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<reference anchor="RFC7437" target="https://www.rfc-editor.org/info/rfc7
			437" quoteTitle="true" derivedAnchor="RFC7437">
			<front>
			<title>IAB, IESG, and IAOC Selection, Confirmation, and Recall Proce
			ss: Operation of the Nominating and Recall Committees</title>
			<author initials="M." surname="Kucherawy" fullname="M. Kucherawy" ro
			le="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2015" month="January"/>
			<abstract>
			<t>The process by which the members of the IAB and IESG, and some
			members of the IAOC, are selected, confirmed, and recalled is specified in this
			document. This document is a self-consistent, organized compilation of the proc
			ess as it was known at the time of publication of RFC 3777, with various updates
			since that version was published.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="10"/>
			<seriesInfo name="RFC" value="7437"/>
			<seriesInfo name="DOI" value="10.17487/RFC7437"/>
			</reference>
			</references>
	</references>		</references>
			<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
	<section anchor="changes" title="Changes from Previous Versions">		ndix.a">
			<name slugifiedName="name-acknowledgements">Acknowledgements</name>
	<t>RFC Editor: Please remove this section upon publication.</t>		<t pn="section-appendix.a-1">Thanks to <contact fullname="Jason Livingood"
			/> for suggesting the need for this document.</t>
	<t>The version draft-ietf-iasa2-trust-rationale-03.txt made		<t pn="section-appendix.a-2"><contact fullname="Subramanian Moonesamy"/>,
	some editorial corrections.</t>		<contact fullname="Sean Turner"/>, <contact fullname="Jon Peterson"/>, <co
			ntact fullname="Roman Danyliw"/>, and <contact fullname="Barry Leiba"/> ra
	<t>The version draft-ietf-iasa2-trust-rationale-02.txt made		ised useful points
	some editorial corrections.</t>		during their reviews of this work.</t>
			</section>
	<t>The version draft-ietf-iasa2-trust-rationale-01.txt includes		<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
	changes relating to last call comments. The changes are 1)		="include" pn="section-appendix.b">
	indication of why this document is being published 2) updates to		<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
	references, 3) the addition of empty security and IANA		<author fullname="Pete Resnick" initials="P." surname="Resnick">
	consideration sections, 4) editorial changes necessary for a		<organization showOnFrontPage="true">Episteme Technology Consulting LLC<
	document that is also read later, and not just used in		/organization>
	discussions at this time.</t>		<address>
			<postal>
	<t>The version draft-ietf-iasa2-trust-rationale-00.txt includes		<street>503 West Indiana Avenue</street>
	only editorial and language updates.</t>		<city>Urbana</city>
			<region>Illinois</region>
	<t>The version draft-arkko-iasa2-trust-rationale-00.txt was the		<country>United States of America</country>
	initial version.</t>		<code>61801-4941</code>
			</postal>
			<phone>+1 217 337 1905</phone>
			<email>resnick@episteme.net</email>
			</address>
			</author>
			<author fullname="Adrian Farrel" initials="A." surname="Farrel">
			<organization showOnFrontPage="true">Old Dog Consulting</organization>
			<address>
			<email>adrian@olddog.co.uk</email>
			</address>
			</author>
	</section>		</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 17 change blocks.
	305 lines changed or deleted		475 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/