<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC4071 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4071.xml">
<!ENTITY RFC4371 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4371.xml">
<!ENTITY RFC7979 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7979.xml">
<!ENTITY I-D.ietf-iasa2-struct SYSTEM "http://xml.resource.org/public/rfc/bibxml3/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" ?> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-ietf-iasa2-trust-rationale-03" ipr="trust200902"> indexInclude="true" ipr="trust200902" number="8715" prepTime="2020-02-26T17:41:36" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-rationale-03" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8715" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="IASA 2.0 and IETF Trust">
      Discussion of the IASA 2.0 Changes as They Relate Trust">IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust</title>
    <seriesInfo name="RFC" value="8715" stream="IETF"/>
    <author fullname="Jari Arkko" initials="J." surname="Arkko">
      <organization>Ericsson</organization>
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Kauniainen</city>

          <region></region>
          <region/>
          <code>02700</code>
          <country>Finland</country>
        </postal>
        <email>jari.arkko@piuha.net</email>
      </address>
    </author>
    <date month="October" year="2018" /> month="02" year="2020"/>
    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <abstract>

      <t>This
    <workgroup>IASA2</workgroup>
    <keyword>IETF administration</keyword>
    <keyword>intellectual property</keyword>
    <keyword>leadership selection</keyword>
    <keyword>IASA</keyword>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1">This document is published to capture captures the rationale for the
      changes introduced in RFC NNNN (RFC Editor: please replace NNNN
      with the RFC number of <xref
      target="I-D.ietf-iasa2-trust-update"/>), Update 8714, "Update to the Process for Selection of
      Trustees for the IETF Trust.</t>

      <t>At Trust".</t>
      <t pn="section-abstract-2">At the time RFC NNNN 8714 was published, IETF administrative
      structure the changes ("IASA 2.0") to the IETF
      Administrative Support Activity, Version 2.0 (IASA 2.0) had an impact on the IETF
      Trust because members of the IETF Administrative Oversight
      Committee (IAOC), which was being phased out, had served as
      Trustees of the IETF Trust. This document provides
      background on the past IETF Trust arrangements, explains the
      effect of the rules in the founding documents during the
      transition to the new arrangement, and provides a rationale for
      the update.</t>
    </abstract>
  </front>

  <middle>
    <boilerplate>
      <section title="Introduction">

      <t>This 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 is
            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="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" 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 capture 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" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.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 derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</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 derivedContent="" format="title" sectionFormat="of" target="name-background">Background</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" 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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-transition">Transition</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 derivedContent="" 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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">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 derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">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 derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t pn="section-1-1">This document captures the rationale for the
      changes introduced in <xref
      target="I-D.ietf-iasa2-trust-update"/>.</t>

      <t>At target="RFC8714" format="default" sectionFormat="of" derivedContent="RFC8714"/>.</t>
      <t pn="section-1-2">At the time <xref target="I-D.ietf-iasa2-trust-update"/> target="RFC8714" format="default" sectionFormat="of" derivedContent="RFC8714"/> was
      published, IETF administrative structure the changes ("IASA 2.0") to the IETF Administrative Support Activity,
      Version 2.0 (IASA 2.0) had an impact on the IETF Trust <xref target="RFC4071"/> target="RFC4071" format="default" sectionFormat="of" derivedContent="RFC4071"/> <xref
      target="RFC4371"/> target="RFC4371" format="default" sectionFormat="of" derivedContent="RFC4371"/> <xref target="I-D.ietf-iasa2-struct"/>. target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>. This
      is because members of the IETF Administrative
      Oversight Committee (IAOC), which was being phased out, had
      served as Trustees of the IETF Trust.  A minimal change
      regarding the selection of the trustees Trustees is implemented by <xref
      target="I-D.ietf-iasa2-trust-update"/>.</t>

      <t>This target="RFC8714" format="default" sectionFormat="of" derivedContent="RFC8714"/>.</t>
      <t pn="section-1-3">This companion memo provides some background on the details
      of the past IETF Trust arrangements, explains the effect of
      the rules in the founding documents during the transition to the new
      arrangement, and provides a rationale for the update.</t>
    </section>
    <section anchor="background" title="Background">

      <t>The numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-background">Background</name>
      <t pn="section-2-1">The purpose of the IETF Trust is to acquire, hold, maintain,
      and license certain existing and future intellectual property
      and other property used in connection with the administration of
      the IETF <xref target="RFC4371"/>. target="RFC8714" format="default" sectionFormat="of" derivedContent="RFC8714"/>. The intellectual property is,
      for instance, rights that the IETF contributors grant for text
      in RFCs and Internet-Drafts. The IETF Trust also manages
      trademarks such as "IETF" and domain names such as
      "ietf.org". The IETF Trust is also serving the broader Internet
      community by holding domains and trademarks associated with the Internet Assigned Numbers Authority (IANA) <xref
      target="RFC7979"/>.</t>

      <t>The target="RFC7979" format="default" sectionFormat="of" derivedContent="RFC7979"/>.</t>
      <t pn="section-2-2">The IETF Trust is a legal entity, registered in the
      Commonwealth of Virginia <xref target="Trust-FD"/>.</t>

      <t>Previously, target="Trust-FD" format="default" sectionFormat="of" derivedContent="Trust-FD"/>.</t>
      <t pn="section-2-3">Previously, the members of the IAOC also served as ex officio
      Trustees of the IETF Trust. The founding documents specify
      persons eligible to become trustees Trustees as having to be then-current
      members of the IAOC <xref target="Trust-FD"/>. target="Trust-FD" format="default" sectionFormat="of" derivedContent="Trust-FD"/>.  The documents
      also specify that if for any reason there are fewer than three
      individuals serving as Trustees, then the Internet Engineering
      Steering Group (IESG), or the IESG's successor as the leadership
      of the IETF, shall appoint one or more individuals to serve in a
      temporary capacity as Trustee(s) until eligible persons can be found.</t>

      <t>In
      <t pn="section-2-4">In the previous system system, there were eight IAOC members. voting members of the IAOC. Two were
      named by the IETF Nominating Committee (NomCom), one by the
      IESG, Internet
      Engineering Steering Group (IESG), one by the Internet Architecture Board
      (IAB), and one by the Internet Society (ISOC) Board of Trustees. In addition, there There were
      three ex officio members via their roles as IETF Chair, ISOC CEO, and IAB
      Chair. In addition, the IETF Administrative Director (IAD)
      served was a non-voting
      IAOC member who also served as one of the trustees.</t> Trustees.</t>
    </section>
    <section anchor="approach" title="General Approach">

      <t>There numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-general-approach">General Approach</name>
      <t pn="section-3-1">There were two basic approaches to resolving the issue with
      the trustees, when Trustees once the IAOC ceased to exist.  One could have imagined
      merging approach would be to
      merge all IETF Trust functions in the new IASA structure and
      under the new legal entity. This However, this memo advocated advocates a second
      approach where the IETF Trust is kept independent.</t>

      <t>The
      <t pn="section-3-2">The rationale for advocating the second approach is is, in part part,
      to minimize changes to the IETF Trust while the IETF's
      administrative structure is undergoing major change.  In
      addition, the IETF Trust and other administrative IETF processes
      are quite different. While very important, the IETF Trust is a
      low-activity entity where changes are minimal and gradual, and
      there are no pressing issues.</t>
    </section>
    <section anchor="selection" title="Changing numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-changing-the-way-trustees-a">Changing the Way Trustees Are Selected">

      <t>At the time when Selected</name>
      <t pn="section-4-1">When the trustees served Trustees were serving on both the IETF Trust and the
      IAOC, many of the requirements for naming a particular group of
      people were driven by the IAOC's requirements.  For the IETF
      Trust in the new model, some of those arrangements were able to be
      rethought, both in terms of the number and source of the
      trustees,
      Trustees, as well as the desired qualifications and length of
      terms.</t>

      <t>Several
      <t pn="section-4-2">Several options were possible, of course.
   A newly designed
      naming selection process could have been devised. The argument here is devised, but in this
   document we argue for a relatively limited change, however, change based largely on the basis of fact that a) the IETF
   Trust arrangements worked generally working well, and on b) the relatively modest expected time commitments combined with commitment
   is expected to be modest, and c) the assets need for very careful
      management of the assets.</t>

      <t>As management.</t>
      <t pn="section-4-3">As a result, a smaller group of trustees Trustees appeared sufficient.</t>

      <t>In
      <t pn="section-4-4">In addition, the terms set for the
      trustees
      Trustees selected from the IETF community could be set to longer than
      the two year two-year period typical of other IETF bodies.</t>

      <t>One
      <t pn="section-4-5">One could have continued the practice of having the chairs and CEOs
      from the IETF, IAB, and Internet Society be trustees Trustees as well, but
      this may not be necessary. In general, the tasks of the IETF
      Trust are well defined, and while there is a need for
      coordination, it does not need to be at the level of chairs or
      CEOs.</t>

      <t>Given
      <t pn="section-4-6">Given all this, one approach was to have trustees Trustees appointed
      by the NomCom, the IESG, and the ISOC Board of Trustees. (One might also
      have considered the IETF Administration LLC legal entity instead
      of the Internet Society for this role. But role, but the Internet Society
      is perhaps more suitable for the role, role given their focus on the
      broad use of the IETF Trust assets and not merely administrative
      aspects).</t>

      <t>If
      aspects.)</t>
      <t pn="section-4-7">If the same principles would continue to be used as were used
      in for previous appointments, appointments continued to be
      used, then appointments performed by the NomCom would need to be
      confirmed by another entity, which entity. This could be, for instance, either the
      IESG or the IAB. The IESG had previously been the confirming body for
      the IAOC, so it has been retained in that role for the trustees.</t> Trustees.</t>
    </section>
    <section anchor="transition" title="Transition">

      <t>When numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-transition">Transition</name>
      <t pn="section-5-1">When the new entity for the IETF Administration LLC was set up,
      the IAOC was expected to be discontinued soon
      thereafter. Fortunately, there was no pressing need to change
      all the components of the IAOC and its dependent organizations
      at the same time. As discussed above (<xref
      target="background"/>), in <xref target="background" format="default" sectionFormat="of" derivedContent="Section 2"/>, the IESG holds the ability to continue
      to name trustees. And once Trustees. Once the updated procedures were in place,
      the IETF Trust had its management nominated in the usual manner,
      and the exceptional IESG IESG's exception process was no longer needed.</t>
    </section>
    <section title="Security Considerations">

      <t>This numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t pn="section-6-1">This memo has no security implications for the Internet.</t>
    </section>
    <section title="IANA Considerations">

      <t>This memo requests numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t pn="section-7-1">This document has no action from IANA.</t> IANA actions.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">

      <t>The author would like to thank other members
  </middle>
  <back>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC4071" target="https://www.rfc-editor.org/info/rfc4071" quoteTitle="true" derivedAnchor="RFC4071">
          <front>
            <title>Structure of the earlier
      IASA 2.0 design team who were Brian Haberman, Eric Rescorla,
      Jason Livingood, Joe Hall, 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="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="April"/>
            <abstract>
              <t>This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC).  It defines the roles and Leslie Daigle. The authors would responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process.  It also like to thank Alissa Cooper, Ted Hardie, Andrew Sullivan,
      Brian Carpenter, Lucy Lynch, defines the membership and John Levine selection rules for interesting
      discussions in this problem space, the IAOC.  This document specifies an Internet Best Current Practices for the Internet Community, and Adrian Farrel, Tero
      Kivinen, Russ Housley, Benjamin Kaduk, Adam Roach requests discussion and Meral
      Shirazipour suggestions for careful review.</t>

    </section>

  </middle>

  <back>

    <references title="Normative References">
      &RFC4071;
      &RFC4371; 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/rfc4371" quoteTitle="true" derivedAnchor="RFC4371">
          <front>
            <title>BCP 101 Update for IPR Trust</title>
            <author initials="B." surname="Carpenter" fullname="B. Carpenter" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Lynch" fullname="L. Lynch" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="January"/>
            <abstract>
              <t>This document updates BCP 101 to take account of the new IETF Intellectual Property Trust.  This document specifies an Internet 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="4371"/>
          <seriesInfo name="DOI" value="10.17487/RFC4371"/>
        </reference>
      </references>
      <references title="Informative References">

      &RFC7979;
      &I-D.ietf-iasa2-struct; pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC7979" target="https://www.rfc-editor.org/info/rfc7979" quoteTitle="true" derivedAnchor="RFC7979">
          <front>
            <title>Response to the IANA Stewardship Transition Coordination Group (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 Administration (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 Internet Assigned Numbers Authority (IANA) functions.  After broad consultations, ICANN in turn created the IANA Stewardship Transition Coordination Group.  That group solicited proposals for the three major IANA functions: names, numbers, and protocol parameters.  This document contains the IETF response to that solicitation for protocol parameters.  It was included in an aggregate response to the NTIA alongside those for names and numbering resources that are being developed by their respective operational communities.  A reference to that response may be found in the introduction, and additional correspondence is included in the Appendix.</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/rfc8711" quoteTitle="true" derivedAnchor="RFC8711">
          <front>
            <title>Structure of the IETF Administrative Support Activity, Version 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='I-D.ietf-iasa2-trust-update'> anchor="RFC8714" target="https://www.rfc-editor.org/info/rfc8714" quoteTitle="true" derivedAnchor="RFC8714">
          <front>
            <title>Update to the Process for Selection of Trustees for the IETF Trust</title>
            <author initials='J' surname='Arkko' fullname='Jari Arkko'> initials="J." surname="Arkko">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='T' surname='Hardie' fullname='Ted Hardie'> initials="T." surname="Hardie">
              <organization /> showOnFrontPage="true"/>
            </author>
            <date month='September' year='2018' /> month="February" year="2020"/>
          </front>
          <seriesInfo name='Internet-Draft' value='draft-ietf-iasa2-trust-update-00' />
	<format type='TXT'
		target='http://www.ietf.org/internet-drafts/draft-ietf-iasa2-trust-update-00.txt' /> name="BCP" value="101"/>
          <seriesInfo name="RFC" value="8714"/>
          <seriesInfo name="DOI" value="10.17487/RFC8714"/>
        </reference>
        <reference anchor="Trust-FD"> anchor="Trust-FD" target="https://trustee.ietf.org/founding-documents.html" quoteTitle="true" derivedAnchor="Trust-FD">
          <front>
            <title>Founding Documents</title>
          <author surname="IETF Trust"></author>
	  <date month='February' year='2014 (https://trustee.ietf.org/founding-documents.html)'/>
            <author>
              <organization showOnFrontPage="true">IETF Trust</organization>
            </author>
          </front>
        <format type='HTML'
		target='https://trustee.ietf.org/founding-documents.html'/>
        </reference>
      </references>
    </references>
    <section anchor="changes" title="Changes from Previous Versions">

      <t>RFC Editor: Please remove this section upon publication.</t>

      <t>The version draft-ietf-iasa2-trust-rationale-03.txt made
      some editorial corrections.</t>

      <t>The version draft-ietf-iasa2-trust-rationale-02.txt made
      some editorial corrections.</t>

      <t>The version draft-ietf-iasa2-trust-rationale-01.txt includes
      changes relating anchor="ack" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t pn="section-appendix.a-1">The author would like to last call comments. The changes are 1)
      indication thank other members of why this document is being published 2) updates to
      references, 3) the addition of empty security and IANA
      consideration sections, 4) editorial changes necessary for a
      document that is earlier
      IASA 2.0 design team: <contact fullname="Brian Haberman"/>, <contact fullname="Eric Rescorla"/>,
      <contact fullname="Jason Livingood"/>, <contact fullname="Joe Hall"/>, and
	<contact fullname="Leslie Daigle"/>. The author would
      also read later, and not just used in like to thank <contact fullname="Alissa Cooper"/>, <contact fullname="Ted Hardie"/>, <contact fullname="Andrew Sullivan"/>,
      <contact fullname="Brian Carpenter"/>, <contact fullname="Lucy Lynch"/>, and
	<contact fullname="John Levine"/> for interesting
      discussions at in this time.</t>

      <t>The version draft-ietf-iasa2-trust-rationale-00.txt includes
      only editorial problem space, and language updates.</t>

      <t>The version draft-arkko-iasa2-trust-rationale-00.txt was the
      initial version.</t> <contact fullname="Adrian Farrel"/>,
      <contact fullname="Tero Kivinen"/>, <contact fullname="Russ Housley"/>,
      <contact fullname="Benjamin Kaduk"/>, <contact fullname="Adam Roach"/>,
      and <contact fullname="Meral Shirazipour"/> for careful review.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <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>
  </back>
</rfc>