rfc8715xml2.original.xml		rfc8715.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="info" cons
			ensus="true" docName="draft-ietf-iasa2-trust-rationale-03" indexInclude="true" i
	<!ENTITY RFC4071 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		pr="trust200902" number="8715" prepTime="2020-02-26T17:41:36" scripts="Common,La
	.4071.xml">		tin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclud
	<!ENTITY RFC4371 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		e="true" xml:lang="en">
	.4371.xml">		<link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-rationale-
	<!ENTITY RFC7979 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		03" rel="prev"/>
	.7979.xml">		<link href="https://dx.doi.org/10.17487/rfc8715" 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="IASA 2.0 and IETF Trust">IETF Administrative Support Activity
	<title abbrev="IASA 2.0 and IETF Trust">		2.0: Update to the Process for Selection of Trustees for the IETF Trust</title>
	Discussion of the IASA 2.0 Changes as They Relate to the IETF		<seriesInfo name="RFC" value="8715" stream="IETF"/>
	Trust</title>		<author fullname="Jari Arkko" initials="J." surname="Arkko">
			<organization showOnFrontPage="true">Ericsson</organization>
	<author fullname="Jari Arkko" initials="J."
	surname="Arkko">
	<organization>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>
			<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 document is published to capture the rationale for the		<abstract pn="section-abstract">
	changes introduced in RFC NNNN (RFC Editor: please replace NNNN		<t pn="section-abstract-1">This document captures the rationale for the
	with the RFC number of <xref		changes introduced in RFC 8714, "Update to the Process for Selection of
	target="I-D.ietf-iasa2-trust-update"/>), Update to the Process for Selecti		Trustees for the IETF Trust".</t>
	on		<t pn="section-abstract-2">At the time RFC 8714 was published, the changes
	of Trustees for the IETF Trust.</t>		to the IETF
			Administrative Support Activity, Version 2.0 (IASA 2.0) had an impact on t
	<t>At the time RFC NNNN was published, IETF administrative		he IETF
	structure changes ("IASA 2.0") had an impact on the IETF
	Trust because members of the IETF Administrative Oversight		Trust because members of the IETF Administrative Oversight
	Committee (IAOC), which was being phased out, had served as		Committee (IAOC), which was being phased out, had served as
	Trustees of the IETF Trust. This document provides		Trustees of the IETF Trust. This document provides
	background on the past IETF Trust arrangements, explains the		background on the past IETF Trust arrangements, explains the
	effect of the rules in the founding documents during the		effect of the rules in the founding documents during the
	transition to the new arrangement, and provides a rationale for		transition to the new arrangement, and provides a rationale for
	the update.</t>		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 document is not an Internet Standards Track specification; it i
			s
			published for informational purposes.
			</t>
			<t pn="section-boilerplate.1-2">
			This document is a product of the Internet 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). Not all documents
			approved by the IESG are candidates for any level of Internet
			Standard; see 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/rfc8715" 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-background">Background</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-general-approach">General
			Approach</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-changing-the-way-trustees
			-a">Changing the Way Trustees Are Selected</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-transition">Transition</x
			ref></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-security-considerations">
			Security Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.7">
			<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
			="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA
			Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.8">
			<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent
			="8" format="counter" sectionFormat="of" target="section-8"/>.  <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.8.2">
			<li pn="section-toc.1-1.8.2.1">
			<t keepWithNext="true" pn="section-toc.1-1.8.2.1.1"><xref derive
			dContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-normative-ref
			erences">Normative References</xref></t>
			</li>
			<li pn="section-toc.1-1.8.2.2">
			<t keepWithNext="true" pn="section-toc.1-1.8.2.2.1"><xref derive
			dContent="8.2" format="counter" sectionFormat="of" target="section-8.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.9">
			<t keepWithNext="true" pn="section-toc.1-1.9.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.10">
			<t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedConten
			t="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derived
			Content="" format="title" sectionFormat="of" target="name-authors-address">Autho
			r's Address</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 document captures the rationale for the
	<t>This document is published to capture the rationale for the		changes introduced in <xref target="RFC8714" format="default" sectionForma
	changes introduced in <xref		t="of" derivedContent="RFC8714"/>.</t>
	target="I-D.ietf-iasa2-trust-update"/>.</t>		<t pn="section-1-2">At the time <xref target="RFC8714" format="default" se
			ctionFormat="of" derivedContent="RFC8714"/> was
	<t>At the time <xref target="I-D.ietf-iasa2-trust-update"/> was		published, the changes to the IETF Administrative Support Activity,
	published, IETF administrative structure changes ("IASA 2.0")		Version 2.0 (IASA 2.0) had an impact on the IETF Trust <xref target="RFC40
	had an impact on the IETF Trust <xref target="RFC4071"/> <xref		71" format="default" sectionFormat="of" derivedContent="RFC4071"/> <xref target=
	target="RFC4371"/> <xref target="I-D.ietf-iasa2-struct"/>. This		"RFC4371" format="default" sectionFormat="of" derivedContent="RFC4371"/> <xref t
			arget="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>.
			This
	is because members of the IETF Administrative		is because members of the IETF Administrative
	Oversight Committee (IAOC), which was being phased out, had		Oversight Committee (IAOC), which was being phased out, had
	served as Trustees of the IETF Trust. A minimal change		served as Trustees of the IETF Trust. A minimal change
	regarding the selection of the trustees is implemented by <xref		regarding the selection of the Trustees is implemented by <xref target="RF
	target="I-D.ietf-iasa2-trust-update"/>.</t>		C8714" format="default" sectionFormat="of" derivedContent="RFC8714"/>.</t>
			<t pn="section-1-3">This companion memo provides some background on the de
	<t>This companion memo provides some background on the details		tails
	of the past IETF Trust arrangements, explains the effect of		of the past IETF Trust arrangements, explains the effect of
	the rules in the founding documents during the transition to the new		the rules in the founding documents during the transition to the new
	arrangement, and provides a rationale for the update.</t>		arrangement, and provides a rationale for the update.</t>
	</section>		</section>
			<section anchor="background" numbered="true" toc="include" removeInRFC="fals
	<section anchor="background" title="Background">		e" pn="section-2">
			<name slugifiedName="name-background">Background</name>
	<t>The purpose of the IETF Trust is to acquire, hold, maintain,		<t pn="section-2-1">The purpose of the IETF Trust is to acquire, hold, mai
			ntain,
	and license certain existing and future intellectual property		and license certain existing and future intellectual property
	and other property used in connection with the administration of		and other property used in connection with the administration of
	the IETF <xref target="RFC4371"/>. The intellectual property is,		the IETF <xref target="RFC8714" format="default" sectionFormat="of" derive dContent="RFC8714"/>. The intellectual property is,
	for instance, rights that the IETF contributors grant for text		for instance, rights that the IETF contributors grant for text
	in RFCs and Internet-Drafts. The IETF Trust also manages		in RFCs and Internet-Drafts. The IETF Trust also manages
	trademarks such as "IETF" and domain names such as		trademarks such as "IETF" and domain names such as
	"ietf.org". The IETF Trust is also serving the broader Internet		"ietf.org". The IETF Trust is also serving the broader Internet
	community by holding domains and trademarks associated with		community by holding domains and trademarks associated with the Internet A
	Internet Assigned Numbers Authority (IANA) <xref		ssigned Numbers Authority (IANA) <xref target="RFC7979" format="default" section
	target="RFC7979"/>.</t>		Format="of" derivedContent="RFC7979"/>.</t>
			<t pn="section-2-2">The IETF Trust is a legal entity, registered in the
	<t>The IETF Trust is a legal entity, registered in the		Commonwealth of Virginia <xref target="Trust-FD" format="default" sectionF
	Commonwealth of Virginia <xref target="Trust-FD"/>.</t>		ormat="of" derivedContent="Trust-FD"/>.</t>
			<t pn="section-2-3">Previously, the members of the IAOC also served as ex
	<t>Previously, the members of the IAOC also served as ex officio		officio
	Trustees of the IETF Trust. The founding documents specify		Trustees of the IETF Trust. The founding documents specify
	persons eligible to become trustees as having to be then-current		persons eligible to become Trustees as having to be then-current
	members of the IAOC <xref target="Trust-FD"/>. The documents		members of the IAOC <xref target="Trust-FD" format="default" sectionFormat
			="of" derivedContent="Trust-FD"/>. The documents
	also specify that if for any reason there are fewer than three		also specify that if for any reason there are fewer than three
	individuals serving as Trustees, then the Internet Engineering		individuals serving as Trustees, then the Internet Engineering
	Steering Group (IESG), or the IESG's successor as the leadership		Steering Group (IESG), or the IESG's successor as the leadership
	of the IETF, shall appoint one or more individuals to serve in a		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>		temporary capacity as Trustee(s) until eligible persons can be found.</t>
			<t pn="section-2-4">In the previous system, there were eight voting member
	<t>In the previous system there were eight IAOC members. Two were		s of the IAOC. Two were
	named by the IETF Nominating Committee (NomCom), one by the		named by the IETF Nominating Committee (NomCom), one by the Internet
	IESG, one by the Internet Architecture Board (IAB), and one by		Engineering Steering Group (IESG), one by the Internet Architecture Board
	the Internet Society (ISOC) Board of Trustees. In addition, there		(IAB), and one by the Internet Society (ISOC) Board of Trustees. There wer
	were three ex officio members via their roles as IETF Chair, ISOC CEO,		e
	and IAB Chair. In addition, the IETF Administrative Director (IAD)		three ex officio members via their roles as IETF Chair, ISOC CEO, and IAB
	served also as one of the trustees.</t>		Chair. In addition, the IETF Administrative Director (IAD) was a non-votin
			g
			IAOC member who also served as one of the Trustees.</t>
	</section>		</section>
			<section anchor="approach" numbered="true" toc="include" removeInRFC="false"
	<section anchor="approach" title="General Approach">		pn="section-3">
			<name slugifiedName="name-general-approach">General Approach</name>
	<t>There were two basic approaches to resolving the issue with		<t pn="section-3-1">There were two basic approaches to resolving the issue
	the trustees, when the IAOC ceased to exist. One could have imagined		with
	merging all IETF Trust functions in the new IASA structure and		the Trustees once the IAOC ceased to exist. One approach would be to
	under the new legal entity. This memo advocated a second		merge all IETF Trust functions in the new IASA structure and
			under the new legal entity. However, this memo advocates a second
	approach where the IETF Trust is kept independent.</t>		approach where the IETF Trust is kept independent.</t>
			<t pn="section-3-2">The rationale for advocating the second approach is, i
	<t>The rationale for advocating the second approach is in part		n part,
	to minimize changes to the IETF Trust while the IETF's		to minimize changes to the IETF Trust while the IETF's
	administrative structure is undergoing major change. In		administrative structure is undergoing major change. In
	addition, the IETF Trust and other administrative IETF processes		addition, the IETF Trust and other administrative IETF processes
	are quite different. While very important, the IETF Trust is a		are quite different. While very important, the IETF Trust is a
	low-activity entity where changes are minimal and gradual, and		low-activity entity where changes are minimal and gradual, and
	there are no pressing issues.</t>		there are no pressing issues.</t>
	</section>		</section>
			<section anchor="selection" numbered="true" toc="include" removeInRFC="false
	<section anchor="selection" title="Changing the Way Trustees Are Selected">		" pn="section-4">
			<name slugifiedName="name-changing-the-way-trustees-a">Changing the Way Tr
	<t>At the time when the trustees served on both the IETF Trust and the		ustees Are Selected</name>
			<t pn="section-4-1">When the Trustees were serving on both the IETF Trust
			and the
	IAOC, many of the requirements for naming a particular group of		IAOC, many of the requirements for naming a particular group of
	people were driven by the IAOC's requirements. For the IETF		people were driven by the IAOC's requirements. For the IETF
	Trust in the new model, some of those arrangements were able to be		Trust in the new model, some of those arrangements were
	rethought, both in terms of the number and source of the		rethought, both in terms of the number and source of the
	trustees, as well as the desired qualifications and length of		Trustees, as well as the desired qualifications and length of
	terms.</t>		terms.</t>
			<t pn="section-4-2">Several options were possible, of course.
	<t>Several options were possible, of course. A newly designed		A newly designed selection process could have been devised, but in this
	naming process could have been devised. The argument here is for a relativ		document we argue for limited change based largely on the fact that a) the IE
	ely		TF
	limited change, however, largely on the basis of the IETF Trust		Trust arrangements worked generally well, b) the expected time commitment
	arrangements generally working well, and on the relatively modest		is expected to be modest, and c) the assets need very careful management.</t>
	expected time commitments combined with the need for very careful		<t pn="section-4-3">As a result, a smaller group of Trustees appeared suff
	management of the assets.</t>		icient.</t>
			<t pn="section-4-4">In addition, the terms set for the
	<t>As a result, a smaller group of trustees appeared sufficient.</t>		Trustees selected from the IETF community could be longer than
			the two-year period typical of other IETF bodies.</t>
	<t>In addition, the terms for the		<t pn="section-4-5">One could have continued the practice of having the ch
	trustees selected from the IETF community could be set to longer than		airs and CEOs
	the two year period typical of other IETF bodies.</t>		from the IETF, IAB, and Internet Society be Trustees as well, but
	<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		this may not be necessary. In general, the tasks of the IETF
	Trust are well defined, and while there is a need for		Trust are well defined, and while there is a need for
	coordination, it does not need to be at the level of chairs or		coordination, it does not need to be at the level of chairs or
	CEOs.</t>		CEOs.</t>
			<t pn="section-4-6">Given all this, one approach was to have Trustees appo
	<t>Given all this, one approach was to have trustees appointed		inted
	by the NomCom, IESG, and ISOC Board of Trustees. (One might also		by the NomCom, the IESG, and the ISOC Board of Trustees. (One might also
	have considered the IETF Administration LLC legal entity instead		have considered the IETF Administration LLC legal entity instead
	of the Internet Society for this role. But the Internet Society		of the Internet Society for this role, but the Internet Society
	is perhaps more suitable for the role, given their focus on the		is perhaps more suitable for the role given their focus on the
	broad use of the IETF Trust assets and not merely administrative		broad use of the IETF Trust assets and not merely administrative
	aspects).</t>		aspects.)</t>
			<t pn="section-4-7">If the same principles used for previous appointments
	<t>If the same principles would continue to be used as were used		continued to be
	in previous appointments, then appointments performed by the		used, then appointments performed by the NomCom would need to be
	NomCom would need to be confirmed by another entity, which could		confirmed by another entity. This could be, for instance, either the
	be, for instance, either the IESG or the IAB. The IESG had		IESG or the IAB. The IESG had previously been the confirming body for
	previously been the confirming body for the IAOC, so it has been		the IAOC, so it has been retained in that role for the Trustees.</t>
	retained in that role for the trustees.</t>
	</section>		</section>
			<section anchor="transition" numbered="true" toc="include" removeInRFC="fals
	<section anchor="transition" title="Transition">		e" pn="section-5">
			<name slugifiedName="name-transition">Transition</name>
	<t>When the new entity for IETF Administration LLC was set up,		<t pn="section-5-1">When the new entity for the IETF Administration LLC wa
			s set up,
	the IAOC was expected to be discontinued soon		the IAOC was expected to be discontinued soon
	thereafter. Fortunately, there was no pressing need to change		thereafter. Fortunately, there was no pressing need to change
	all the components of the IAOC and its dependent organizations		all the components of the IAOC and its dependent organizations
	at the same time. As discussed above (<xref		at the same time. As discussed in <xref target="background" format="defaul
	target="background"/>), the IESG holds the ability to continue		t" sectionFormat="of" derivedContent="Section 2"/>, the IESG holds the ability t
	to name trustees. And once the updated procedures were in place,		o continue
			to name Trustees. Once the updated procedures were in place,
	the IETF Trust had its management nominated in the usual manner,		the IETF Trust had its management nominated in the usual manner,
	and the exceptional IESG process was no longer needed.</t>		and the IESG's exception process was no longer needed.</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-6">
	<section title="IANA Considerations">		<name slugifiedName="name-security-considerations">Security Considerations
			</name>
	<t>This memo requests no action from IANA.</t>		<t pn="section-6-1">This memo has no security implications for the Interne
			t.</t>
	</section>		</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-7">
	<section anchor="ack" title="Acknowledgements">		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
			<t pn="section-7-1">This document has no IANA actions.</t>
	<t>The author would like to thank other members of the earlier
	IASA 2.0 design team who were Brian Haberman, Eric Rescorla,
	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-8">
	<references title="Normative References">		<name slugifiedName="name-references">References</name>
	&RFC4071;		<references pn="section-8.1">
	&RFC4371;		<name slugifiedName="name-normative-references">Normative References</na
	</references>		me>
			<reference anchor="RFC4071" target="https://www.rfc-editor.org/info/rfc4
	<references title="Informative References">		071" quoteTitle="true" derivedAnchor="RFC4071">
			<front>
	&RFC7979;		<title>Structure of the IETF Administrative Support Activity (IASA)<
	&I-D.ietf-iasa2-struct;		/title>
			<author initials="R." surname="Austein" fullname="R. Austein" role="
	<reference anchor='I-D.ietf-iasa2-trust-update'>		editor">
	<front>		<organization showOnFrontPage="true"/>
	<title>Update to the Selection of Trustees for the IETF Trust</title>		</author>
			<author initials="B." surname="Wijnen" fullname="B. Wijnen" role="ed
	<author initials='J' surname='Arkko' fullname='Jari Arkko'>		itor">
	<organization />		<organization showOnFrontPage="true"/>
	</author>		</author>
			<date year="2005" month="April"/>
	<author initials='T' surname='Hardie' fullname='Ted Hardie'>		<abstract>
	<organization />		<t>This document describes the structure of the IETF Administrativ
	</author>		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
	<date month='September' year='2018' />		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
	</front>		the membership and selection rules for the IAOC. This document specifies an Int
	<seriesInfo name='Internet-Draft' value='draft-ietf-iasa2-trust-update-00		ernet Best Current Practices for the Internet Community, and requests discussion
	' />		and suggestions for improvements.</t>
	<format type='TXT'		</abstract>
	target='http://www.ietf.org/internet-drafts/draft-ietf-iasa2-trus		</front>
	t-update-00.txt' />		<seriesInfo name="BCP" value="101"/>
	</reference>		<seriesInfo name="RFC" value="4071"/>
			<seriesInfo name="DOI" value="10.17487/RFC4071"/>
	<reference anchor="Trust-FD">		</reference>
	<front>		<reference anchor="RFC4371" target="https://www.rfc-editor.org/info/rfc4
	<title>Founding Documents</title>		371" quoteTitle="true" derivedAnchor="RFC4371">
	<author surname="IETF Trust"></author>		<front>
	<date month='February' year='2014 (https://trustee.ietf.org/founding-do		<title>BCP 101 Update for IPR Trust</title>
	cuments.html)'/>		<author initials="B." surname="Carpenter" fullname="B. Carpenter" ro
	</front>		le="editor">
	<format type='HTML'		<organization showOnFrontPage="true"/>
	target='https://trustee.ietf.org/founding-documents.html'/>		</author>
	</reference>		<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-8.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<reference anchor="RFC7979" target="https://www.rfc-editor.org/info/rfc7
			979" quoteTitle="true" derivedAnchor="RFC7979">
			<front>
			<title>Response to the IANA Stewardship Transition Coordination Grou
			p (ICG) Request for Proposals on the IANA Protocol Parameters Registries</title>
			<author initials="E." surname="Lear" fullname="E. Lear" role="editor
			">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Housley" fullname="R. Housley" role="
			editor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2016" month="August"/>
			<abstract>
			<t>The U.S. National Telecommunications and Information Administra
			tion (NTIA) solicited a request from the Internet Corporation for Assigned Names
			and Numbers (ICANN) to propose how the NTIA should end its oversight of the Int
			ernet Assigned Numbers Authority (IANA) functions. After broad consultations, I
			CANN in turn created the IANA Stewardship Transition Coordination Group. That g
			roup solicited proposals for the three major IANA functions: names, numbers, and
			protocol parameters. This document contains the IETF response to that solicita
			tion for protocol parameters. It was included in an aggregate response to the N
			TIA alongside those for names and numbering resources that are being developed b
			y their respective operational communities. A reference to that response may be
			found in the introduction, and additional correspondence is included in the App
			endix.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="7979"/>
			<seriesInfo name="DOI" value="10.17487/RFC7979"/>
			</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 month="February" year="2020"/>
			</front>
			<seriesInfo name="BCP" value="101"/>
			<seriesInfo name="RFC" value="8711"/>
			<seriesInfo name="DOI" value="10.17487/RFC8711"/>
			</reference>
			<reference anchor="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="Trust-FD" target="https://trustee.ietf.org/founding-d
			ocuments.html" quoteTitle="true" derivedAnchor="Trust-FD">
			<front>
			<title>Founding Documents</title>
			<author>
			<organization showOnFrontPage="true">IETF Trust</organization>
			</author>
			</front>
			</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 author would like to thank other members
			of the earlier
	<t>The version draft-ietf-iasa2-trust-rationale-03.txt made		IASA 2.0 design team: <contact fullname="Brian Haberman"/>, <contact fulln
	some editorial corrections.</t>		ame="Eric Rescorla"/>,
			<contact fullname="Jason Livingood"/>, <contact fullname="Joe Hall"/>, and
	<t>The version draft-ietf-iasa2-trust-rationale-02.txt made		<contact fullname="Leslie Daigle"/>. The author would
	some editorial corrections.</t>		also like to thank <contact fullname="Alissa Cooper"/>, <contact fullname=
			"Ted Hardie"/>, <contact fullname="Andrew Sullivan"/>,
	<t>The version draft-ietf-iasa2-trust-rationale-01.txt includes		<contact fullname="Brian Carpenter"/>, <contact fullname="Lucy Lynch"/>, a
	changes relating to last call comments. The changes are 1)		nd
	indication of why this document is being published 2) updates to		<contact fullname="John Levine"/> for interesting
	references, 3) the addition of empty security and IANA		discussions in this problem space, and <contact fullname="Adrian Farrel"/>
	consideration sections, 4) editorial changes necessary for a		,
	document that is also read later, and not just used in		<contact fullname="Tero Kivinen"/>, <contact fullname="Russ Housley"/>,
	discussions at this time.</t>		<contact fullname="Benjamin Kaduk"/>, <contact fullname="Adam Roach"/>,
			and <contact fullname="Meral Shirazipour"/> for careful review.</t>
	<t>The version draft-ietf-iasa2-trust-rationale-00.txt includes		</section>
	only editorial and language updates.</t>		<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
			="include" pn="section-appendix.b">
	<t>The version draft-arkko-iasa2-trust-rationale-00.txt was the		<name slugifiedName="name-authors-address">Author's Address</name>
	initial version.</t>		<author fullname="Jari Arkko" initials="J." surname="Arkko">
			<organization showOnFrontPage="true">Ericsson</organization>
			<address>
			<postal>
			<street/>
			<city>Kauniainen</city>
			<region/>
			<code>02700</code>
			<country>Finland</country>
			</postal>
			<email>jari.arkko@piuha.net</email>
			</address>
			</author>
	</section>		</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 40 change blocks.
	252 lines changed or deleted		444 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/