rfc8714xml2.original.xml		rfc8714.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-trust-update-03" indexInclude="true" ipr="
	<!ENTITY RFC7437 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		trust200902" number="8714" obsoletes="4371" prepTime="2020-02-26T17:17:28" scrip
	.7437.xml">		ts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth=
	<!ENTITY RFC4071 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		"4" tocInclude="true" xml:lang="en">
	.4071.xml">		<link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-update-03"
	<!ENTITY RFC4371 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		rel="prev"/>
	.4371.xml">		<link href="https://dx.doi.org/10.17487/rfc8714" rel="alternate"/>
			<link href="urn:issn:2070-1721" rel="alternate"/>
	]>
	<?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="bcp" docName="draft-ietf-iasa2-trust-update-02" ipr="trust200902"
	updates="4071,4371">
	<front>		<front>
	<title abbrev="Trustees for the IETF Trust">Update to the Process for Select ion of Trustees for the IETF Trust</title>		<title abbrev="Trustees for the IETF Trust">Update to the Process for Select ion of Trustees for the IETF Trust</title>
			<seriesInfo name="RFC" value="8714" stream="IETF"/>
	<author fullname="Jari Arkko" initials="J."		<seriesInfo name="BCP" value="101" stream="IETF"/>
	surname="Arkko">		<author fullname="Jari Arkko" initials="J." surname="Arkko">
	<organization>Ericsson</organization>		<organization showOnFrontPage="true">Ericsson</organization>
	<address>		<address>
	<postal>		<postal>
	<street></street>		<street/>
	<city>Kauniainen</city>		<city>Kauniainen</city>
			<region/>
	<region></region>
	<code>02700</code>		<code>02700</code>
	<country>Finland</country>		<country>Finland</country>
	</postal>		</postal>
	<email>jari.arkko@piuha.net</email>		<email>jari.arkko@piuha.net</email>
	</address>		</address>
	</author>		</author>
			<author fullname="Ted Hardie" initials="T." surname="Hardie">
	<author fullname="Ted Hardie" initials="T."
	surname="Hardie">
	<address>		<address>
	<email>ted.ietf@gmail.com</email>		<email>ted.ietf@gmail.com</email>
	</address>		</address>
	</author>		</author>
			<date month="02" year="2020"/>
	<date month="October" year="2018" />
	<area>General</area>		<area>General</area>
			<workgroup>IASA2</workgroup>
	<workgroup>Internet Engineering Task Force</workgroup>		<keyword>IETF administration</keyword>
			<keyword>intellectual property</keyword>
	<abstract>		<keyword>leadership selection</keyword>
			<keyword>IASA</keyword>
	<t>This memo updates the process for selection of trustees for the IETF		<abstract pn="section-abstract">
	Trust. Previously, the Internet Administrative Oversight		<t pn="section-abstract-1">This memo updates the process for selection of
	Committee (IAOC) members also acted as trustees, but the IAOC		Trustees for the IETF
	has been eliminated as part of an update of the structure of		Trust. Previously, the IETF Administrative Oversight Committee (IAOC)
	the Internet Administrative Support Activity (IASA). This memo		members also acted as Trustees, but the IAOC
	specifies that the trustees shall be selected separately.</t>		has been eliminated as part of an update to the structure of
			the IETF Administrative Support Activity (IASA). This memo
	<t>This memo updates RFCs 4071 and 4371 with regards to the		specifies that the Trustees shall be selected separately.</t>
	selection of trustees. All other aspects of the IETF Trust		<t pn="section-abstract-2">This memo obsoletes RFC 4371. The changes rela
	remain as they are today.</t>		te only
			to the selection of Trustees. All other aspects of the IETF Trust
			remain as they are today.
			</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/rfc8714" 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-ietf-trust">IETF Trust</x
			ref></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-selection-of-trustees">Se
			lection of Trustees</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-iana-considerations">IANA
			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-acknowledgements">Ackno
			wledgements</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-authors-addresses">Auth
			ors' Addresses</xref></t>
			</li>
			</ul>
			</section>
			</toc>
	</front>		</front>
	<middle>		<middle>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
	<section title="Introduction">		<name slugifiedName="name-introduction">Introduction</name>
			<t pn="section-1-1">This memo updates the process for selection of Trustee
	<t>This memo updates the process for selection of trustees for the IETF		s for the IETF
	Trust. Previously, the Internet Administrative Oversight		Trust. Previously, the IETF Administrative Oversight Committee (IAOC)
	Committee (IAOC) members also acted as trustees, but the IAOC		members also acted as Trustees, but the IAOC has been eliminated as part
	has been eliminated as part of an update of the structure of		of an update to the structure of the IETF Administrative Support
	the Internet Administrative Support Activity (IASA). This memo		Activity (IASA). This memo specifies that the Trustees shall be selected
	specifies that the trustees shall be selected separately.</t>		separately. See <xref target="selection" format="default" sectionFormat="o
			f" derivedContent="Section 3"/>.</t>
	<t>This memo updates RFCs 4071 and 4371 with regards to the		<t pn="section-1-2">This memo obsoletes <xref target="RFC4371" format="def
	selection of trustees. All other aspects of the IETF Trust		ault" sectionFormat="of" derivedContent="RFC4371"/>. The changes relate only to
	remain as they are today.</t>		the
			selection of Trustees. All other aspects of the IETF Trust remain as
	<t>For a discussion of why this change is needed and a rationale		they are today. <xref target="ietf-trust" format="default" sectionFormat="
	for these specific changes, see <xref		of" derivedContent="Section 2"/> copies the
	target="I-D.ietf-iasa2-trust-rationale"/>.</t>		definition as it was in <xref target="RFC4371" format="default" sectionFor
			mat="of" derivedContent="RFC4371"/>,
			only leaving out the part about Trustee selection and adding a reference
			to the IETF Trust website.
			</t>
			<t pn="section-1-3">For a discussion of why this change is needed and a ra
			tionale
			for these specific changes, see <xref target="RFC8715" format="default" se
			ctionFormat="of" derivedContent="RFC8715"/>.</t>
	</section>		</section>
			<section anchor="ietf-trust" numbered="true" toc="include" removeInRFC="fals
	<section anchor="selection" title="Selection of Trustees">		e" pn="section-2">
			<name slugifiedName="name-ietf-trust">IETF Trust</name>
	<t>This document revises the original Trustee selection procedures		<t pn="section-2-1">A Trust ("the IETF Trust") has been formed for the pur
	defined in <xref target="RFC4071"/> and <xref target="RFC4371"/>,		pose of
	to eliminate the requirement that trustees be drawn from the		acquiring, holding, maintaining, and licensing certain existing and
			future intellectual property and other property used in connection
			with the administration of the IETF. The Trust was formed by the
			signatures of its Settlors and initial Trustees. The Settlors, who
			contributed initial intellectual property to the Trust, were ISOC and
			the Corporation for National Research Initiatives. The Beneficiary
			of the IETF Trust is the IETF as a whole.</t>
			<t pn="section-2-2">Further details of the IETF Trust may be found at the
			IETF Trust's
			website, &lt;<eref target="https://trustee.ietf.org/" brackets="none"/>&gt;.<
			/t>
			</section>
			<section anchor="selection" numbered="true" toc="include" removeInRFC="false
			" pn="section-3">
			<name slugifiedName="name-selection-of-trustees">Selection of Trustees</na
			me>
			<t pn="section-3-1">This document revises the original Trustee selection p
			rocedures
			defined in <xref target="RFC4071" format="default" sectionFormat="of" deri
			vedContent="RFC4071"/> and <xref target="RFC4371" format="default" sectionFormat
			="of" derivedContent="RFC4371"/>
			to eliminate the requirement that Trustees be drawn from the
	members of the IAOC.</t>		members of the IAOC.</t>
			<t pn="section-3-2">In this newly revised IETF Trust structure, there will
	<t>In this newly revised IETF Trust structure, there will be		be
	five Trustees. Three shall be appointed by the IETF Nominating		five Trustees. Three shall be appointed by the IETF Nominating
	Committee (NomCom) and confirmed by the Internet Engineering		Committee (NomCom) and confirmed by the Internet Engineering
	Steering Group (IESG), one shall be appointed by the IESG, and		Steering Group (IESG), one shall be appointed by the IESG, and
	one shall be appointed by the Internet Society (ISOC) Board of		one shall be appointed by the Internet Society (ISOC) Board of
	Trustees. The appointments by the IESG and ISOC Board of		Trustees. The appointments by the IESG and the ISOC Board of
	Trustees do not require confirmation.</t>		Trustees do not require confirmation.</t>
			<t pn="section-3-3">The IETF Trust Chair informs the nominating committee
	<t>The IETF Trust Chair informs the nominating committee
	of the Trustee positions to be reviewed. The IETF Trust will		of the Trustee positions to be reviewed. The IETF Trust will
	provide a summary of the expertise desired of the Trustee		provide a summary of the expertise desired of the Trustee
	candidates to each appointing body.</t>		candidates to each appointing body.</t>
			<t pn="section-3-4">A change to the Trust Agreement is required to put thi
	<t>A change to the Trust Agreement is required to put this		s
	change into effect, and this document requests that the current		change into effect, and this document requests that the current
	Trustees make this change at the earliest convenient time and no		Trustees make this change at the earliest convenient time and no
	later than the end of the 104th IETF meeting in March 2019.</t>		later than the end of the 104th IETF meeting in March 2019.</t>
			<t pn="section-3-5">The terms of the appointed Trustees from the IETF NomC
	<t>The terms of the appointed trustees from IETF NomCom shall be		om shall be
	three years. The initial selection shall be one, two, and three		three years. The initial selection shall be one, two, and three
	year terms in order to initially stagger the terms. The other		year terms in order to initially stagger the terms. The other
	appointments by the IESG and the ISOC Board of Trustees shall be		appointments by the IESG and the ISOC Board of Trustees shall be
	two year terms, with the initial terms being one and two years,		two year terms, with the initial terms being one and two years,
	respectively.		respectively.
	The goal of the staggered initial terms is to minimize potential		The goal of the staggered initial terms is to minimize potential
	Trustee turnover in any single year. To maintain the		Trustee turnover in any single year. To maintain the
	staggered terms, each appointing body may at its discretion		staggered terms, each appointing body may, at its discretion,
	appoint Trustees for shorter terms as needed in exceptional		appoint Trustees for shorter terms as needed in exceptional
	situations, e.g., for mid-term vacancies or when an appointment		situations, e.g., for mid-term vacancies or when an appointment
	is not ready by the time of the first IETF of the year.</t>		is not ready by the time of the first IETF meeting of the year.</t>
			<t pn="section-3-6">Once the initial Trustee selections according to the
	<t>Once the initial trustee selections according to the
	procedures in this document are complete, and at each subsequent		procedures in this document are complete, and at each subsequent
	annual meeting of the IETF Trust once new trustees are seated,		annual meeting of the IETF Trust (once new Trustees are seated),
	the trustees shall elect by a majority vote of the IETF Trust		the Trustees shall elect one Trustee to serve as IETF Trust Chair by a
	one trustee to serve as IETF Trust Chair.</t>		majority vote of the IETF Trust.</t>
			<t pn="section-3-7">Trustees appointed by the IETF NomCom may be recalled
	<t>The processes regarding NomCom appointments and recalls of		according to
	Trustees for the IETF Trust follow those described in <xref		the recall process described in <xref target="BCP10" format="default" sect
	target="RFC7437"/>. For the appointments by the IESG, the		ionFormat="of" derivedContent="BCP10"/>.
	IESG is expected to run an open selection process and to consider		Trustees appointed by the IESG or by the ISOC Board of Directors may be
	the necessary skill set and conflicts of interest as part of		recalled by the appointing body. For appointments made by the IESG, the
	that process.</t>		IESG is expected to run an open selection process and to consider the
			necessary skill set and conflicts of interest as part of that process.</t
	</section>		>
	<section title="Security Considerations">
	<t>This memo has no security implications for the Internet.</t>
	</section>		</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-4">
	<section title="IANA Considerations">		<name slugifiedName="name-security-considerations">Security Considerations
			</name>
	<t>This memo requests no action from IANA.</t>		<t pn="section-4-1">This memo has no security implications for the Interne
			t.</t>
	</section>		</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-5">
	<section anchor="ack" title="Acknowledgements">		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
			<t pn="section-5-1">This document has no IANA actions.</t>
	<t>The authors would like to thank members of the earlier IASA
	2.0 design team who were Brian Haberman, Eric Rescorla, Jari
	Arkko, Jason Livingood, Joe Hall, and Leslie Daigle. The authors
	would also like to thank Alissa Cooper, Andrew Sullivan, Brian
	Carpenter, Lucy Lynch, and John Levine for interesting
	discussions in this problem space. The authors would also like
	to thank Russ Housley, Bob Hinden, Scott Mansfield, Alexey
	Melnikov, Suresh Krishnan, Mirja Kuhlewind, Ben Campbell,
	Spencer Dawkins, Martin Vigoreux, Benjamin Kaduk, and Adrian
	Farrel for careful review.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<references pn="section-6">
	<references title="Normative References">		<name slugifiedName="name-references">References</name>
	&RFC4071;		<references pn="section-6.1">
	&RFC4371;		<name slugifiedName="name-normative-references">Normative References</na
	&RFC7437;		me>
	</references>		<reference anchor="BCP10" target="https://www.rfc-editor.org/info/bcp10"
			quoteTitle="true" derivedAnchor="BCP10">
	<references title="Informative References">		<front>
			<title>IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation,
	<reference anchor='I-D.ietf-iasa2-trust-rationale'>		and Recall Process: Operation of the IETF Nominating and Recall Committees</titl
	<front>		e>
	<title>Discussion of the Effects of IASA 2.0 Changes as They Relate to		<author initials="M." surname="Kucherawy" role="editor">
	the IETF		<organization showOnFrontPage="true"/>
	Trust</title>		</author>
			<author initials="R." surname="Hinden" role="editor">
	<author initials='J' surname='Arkko' fullname='Jari Arkko'>		<organization showOnFrontPage="true"/>
	<organization />		</author>
	</author>		<author initials="J." surname="Livingood" role="editor">
			<organization showOnFrontPage="true"/>
	<date month='September' year='2018' />		</author>
			<date month="February" year="2020"/>
	</front>		</front>
	<seriesInfo name='Internet-Draft' value='draft-ietf-iasa2-trust-rationale		<seriesInfo name="BCP" value="10"/>
	-00' />		<seriesInfo name="RFC" value="8713"/>
	<format type='TXT'		</reference>
	target='http://www.ietf.org/internet-drafts/draft-ietf-iasa2-trus		<reference anchor="RFC4071" target="https://www.rfc-editor.org/info/rfc4
	t-rationale-00.txt' />		071" quoteTitle="true" derivedAnchor="RFC4071">
	</reference>		<front>
			<title>Structure of the IETF Administrative Support Activity (IASA)<
			/title>
			<author initials="R." surname="Austein" fullname="R. Austein" role="
			editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="B." surname="Wijnen" fullname="B. Wijnen" role="ed
			itor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2005" month="April"/>
			<abstract>
			<t>This document describes the structure of the IETF Administrativ
			e Support Activity (IASA) as an activity housed within the Internet Society (ISO
			C). It defines the roles and responsibilities of the IETF Administrative Oversi
			ght Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fi
			scal and administrative support of the IETF standards process. It also defines
			the membership and selection rules for the IAOC. This document specifies an Int
			ernet Best Current Practices for the Internet Community, and requests discussion
			and suggestions for improvements.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="101"/>
			<seriesInfo name="RFC" value="4071"/>
			<seriesInfo name="DOI" value="10.17487/RFC4071"/>
			</reference>
			<reference anchor="RFC4371" target="https://www.rfc-editor.org/info/rfc4
			371" quoteTitle="true" derivedAnchor="RFC4371">
			<front>
			<title>BCP 101 Update for IPR Trust</title>
			<author initials="B." surname="Carpenter" fullname="B. Carpenter" ro
			le="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="L." surname="Lynch" fullname="L. Lynch" role="edit
			or">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2006" month="January"/>
			<abstract>
			<t>This document updates BCP 101 to take account of the new IETF I
			ntellectual Property Trust. This document specifies an Internet Best Current Pr
			actices for the Internet Community, and requests discussion and suggestions for
			improvements.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="101"/>
			<seriesInfo name="RFC" value="4371"/>
			<seriesInfo name="DOI" value="10.17487/RFC4371"/>
			</reference>
			</references>
			<references pn="section-6.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<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>		</references>
			<section anchor="ack" numbered="false" toc="include" removeInRFC="false" pn=
	<section anchor="changes" title="Changes from Previous Versions">		"section-appendix.a">
			<name slugifiedName="name-acknowledgements">Acknowledgements</name>
	<t>RFC Editor: Please remove this section upon publication.</t>		<t pn="section-appendix.a-1">The authors would like to thank members of th
			e earlier IASA
	<t>The version draft-itef-iasa2-trust-update-02.txt made some		2.0 design team: <contact fullname="Brian Haberman"/>, <contact fullname="
	editorial corrections, as well as clarifying that no		Eric Rescorla"/>, <contact fullname="Jari Arkko"/>, <contact fullname="Jas
	confirmation is needed in the cases other than the nomcom		on Livingood"/>, <contact fullname="Joe Hall"/>,
	appointment, specified how IETF Trust chair is chosen, and		and <contact fullname="Leslie Daigle"/>. The authors
	required that an open process be used by the IESG for the		would also like to thank <contact fullname="Alissa Cooper"/>, <contact ful
	selections.</t>		lname="Andrew Sullivan"/>, <contact fullname="Brian Carpenter"/>, <contact
			fullname="Lucy Lynch"/>, and <contact fullname="John Levine"/> for interesting
	<t>The version draft-ietf-iasa2-trust-update-01.txt has taken		discussions in this problem space. The authors would also like
	into account last call comments. The changes are: 1)		to thank <contact fullname="Russ Housley"/>, <contact fullname="Bob Hinden
	Clarification of the role of the IETF Trust Chair to		"/>,
	indicate which trustee positions are up for selection, similar to how RFC		<contact fullname="Scott Mansfield"/>, <contact fullname="Alexey Mel
	7437 requires the IETF Executive Director to do it. 2)		nikov"/>, <contact fullname="Suresh Krishnan"/>, <contact fullname="Mirja
	The addition of empty security and IANA consideration		Kühlewind"/>, <contact fullname="Ben Campbell"/>,
	sections. 3) The clarification of the staggering rules for		<contact fullname="Spencer Dawkins"/>, <contact fullname="Martin Vigoreux"
	NomCom selections. 4) Updated text regarding the application of		/>,
	rules from RFC 7437. 5) Update draft title to be correct in		<contact fullname="Benjamin Kaduk"/>, and <contact fullname="Adrian
	terms of specifying a process rather than the actual persons.		Farrel"/> for careful review. Finally, the authors would like to thank the
	6) Update the text regarding desirable expertise to use the		authors of <xref target="RFC4371" format="default" sectionFormat="of" deri
	same language as in RFC 7437 instead of the "list of desired		vedContent="RFC4371"/>, as the text from that RFC remains in this document.
	qualifications".</t>		</t>
			</section>
	<t>The version draft-ietf-iasa2-trust-update-00.txt corrected		<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
	the desired document status to BCP, and made several editorial		="include" pn="section-appendix.b">
	and language updates. This version also updated the wording for		<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
	the request for the current trustees to adopt this change, from		<author fullname="Jari Arkko" initials="J." surname="Arkko">
	"earliest convenience" to "earliest convenient time".</t>		<organization showOnFrontPage="true">Ericsson</organization>
			<address>
	<t>The version draft-arkko-iasa2-trust-update-00.txt was the		<postal>
	initial version.</t>		<street/>
			<city>Kauniainen</city>
			<region/>
			<code>02700</code>
			<country>Finland</country>
			</postal>
			<email>jari.arkko@piuha.net</email>
			</address>
			</author>
			<author fullname="Ted Hardie" initials="T." surname="Hardie">
			<address>
			<email>ted.ietf@gmail.com</email>
			</address>
			</author>
	</section>		</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 31 change blocks.
	201 lines changed or deleted		377 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/