Diff: rfc8715xml2.original.xml

	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/