<?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 category="info" docName="draft-ietf-iasa2-trust-rationale-03" ipr="trust200902"> xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="bcp" consensus="true" docName="draft-ietf-iasa2-rfc7776bis-03" indexInclude="true" ipr="trust200902" number="8716" prepTime="2020-02-26T17:07:15" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" updates="7776" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc7776bis-03" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8716" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="IASA 2.0 and abbrev="Anti-Harassment LLC Update">Update to the IETF Trust">
      Discussion Anti-Harassment Procedures for the Replacement of the IASA 2.0 Changes as They Relate to IETF Administrative Oversight Committee (IAOC) with the IETF
      Trust</title> Administration LLC</title>
    <seriesInfo name="RFC" value="8716" stream="IETF"/>
    <seriesInfo name="BCP" value="25" stream="IETF"/>
    <author fullname="Jari Arkko" initials="J."
            surname="Arkko">
      <organization>Ericsson</organization> fullname="Pete Resnick" initials="P." surname="Resnick">
      <organization showOnFrontPage="true">Episteme Technology Consulting LLC</organization>
      <address>
        <postal>
          <street></street>

          <city>Kauniainen</city>

          <region></region>

          <code>02700</code>

          <country>Finland</country>
          <street>503 West Indiana Avenue</street>
          <city>Urbana</city>
          <region>Illinois</region>
          <country>United States of America</country>
          <code>61801-4941</code>
        </postal>

        <email>jari.arkko@piuha.net</email>
        <phone>+1 217 337 1905</phone>
        <email>resnick@episteme.net</email>
      </address>
    </author>
    <author fullname="Adrian Farrel" initials="A." surname="Farrel">
      <organization showOnFrontPage="true">Old Dog Consulting</organization>
      <address>
        <email>adrian@olddog.co.uk</email>
      </address>
    </author>
    <date month="October" year="2018" /> month="02" year="2020"/>
    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <abstract>

      <t>This document is published to capture the rationale for the
      changes introduced
    <workgroup>IASA 2.0</workgroup>
    <keyword>Harassment</keyword>
    <keyword>Ombudsteam</keyword>
    <keyword>IAOC</keyword>
    <keyword>IETF Administration LLC</keyword>
    <keyword>IASA</keyword>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1">The IETF Anti-Harassment Procedures are described in RFC NNNN (RFC Editor: please replace NNNN
      with 7776.</t>
      <t pn="section-abstract-2">The IETF Administrative Oversight Committee (IAOC) has been replaced by the IETF Administration LLC, and the IETF Administrative Director has been replaced by the IETF LLC Executive Director.  This document updates RFC number of <xref
      target="I-D.ietf-iasa2-trust-update"/>), Update 7776 to amend these terms.</t>
      <t pn="section-abstract-3">RFC 7776 contained updates to RFC 7437.  RFC 8713 has incorporated those updates, so this document also updates RFC 7776 to remove those updates.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t pn="section-boilerplate.1-1">
            This memo documents an Internet Best Current Practice.
        </t>
        <t pn="section-boilerplate.1-2">
            This document is a product of the Process for Selection Internet Engineering Task Force
            (IETF).  It represents the consensus of Trustees for the IETF Trust.</t>

      <t>At community.  It has
            received public review and has been approved for publication by
            the time RFC NNNN was published, IETF administrative
      structure changes ("IASA 2.0") had an impact Internet Engineering Steering Group (IESG).  Further information
            on BCPs is available in Section 2 of RFC 7841.
        </t>
        <t pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8716" brackets="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 because members of and the IETF Administrative Oversight
      Committee (IAOC), which was being phased out, had served persons identified as
      Trustees of the IETF Trust.
            document authors. All rights reserved.
        </t>
        <t pn="section-boilerplate.2-2">
            This document provides
      background on is subject to BCP 78 and the past IETF Trust arrangements, explains the
      effect of the rules Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the founding date of
            publication of this document. Please review these documents during the
      transition
            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 new arrangement, Trust Legal Provisions and provides a rationale for are provided without
            warranty as described in the update.</t>

    </abstract> 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-changes-to-rfc-7776">Changes to RFC 7776</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-to-section-34">Changes to Section 3.4</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-to-section-5">Changes to Section 5</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-to-references-to-rf">Changes to References to RFC 7437</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.3.2">
                  <li pn="section-toc.1-1.2.2.3.2.1">
                    <t keepWithNext="true" pn="section-toc.1-1.2.2.3.2.1.1"><xref derivedContent="2.3.1" format="counter" sectionFormat="of" target="section-2.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-to-metadata">Changes to Metadata</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.3.2.2">
                    <t keepWithNext="true" pn="section-toc.1-1.2.2.3.2.2.1"><xref derivedContent="2.3.2" format="counter" sectionFormat="of" target="section-2.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-to-the-abstract">Changes to the Abstract</xref></t>
                  </li>
                  <li pn="section-toc.1-1.2.2.3.2.3">
                    <t keepWithNext="true" pn="section-toc.1-1.2.2.3.2.3.1"><xref derivedContent="2.3.3" format="counter" sectionFormat="of" target="section-2.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-to-section-51">Changes to Section 5.1</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref 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.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section title="Introduction">

      <t>This document is published to capture the rationale for the
      changes introduced anchor="intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t pn="section-1-1">The IETF Anti-Harassment Procedures are described in RFC 7776 <xref
      target="I-D.ietf-iasa2-trust-update"/>.</t>

      <t>At the time <xref target="I-D.ietf-iasa2-trust-update"/> was
      published, IETF administrative structure changes ("IASA 2.0")
      had an impact on target="RFC7776" format="default" sectionFormat="of" derivedContent="RFC7776"/>.  Those procedures include direction for the IETF Trust <xref target="RFC4071"/> <xref
      target="RFC4371"/> <xref target="I-D.ietf-iasa2-struct"/>. This
      is because members of Chair and Ombudsteam to take advice from the IETF Administrative Oversight Committee (IAOC), which was being phased out, had
      served as Trustees of (IAOC) with respect to the IETF Trust.  A minimal change
      regarding budget available for training.</t>
      <t pn="section-1-2">The IAOC has been replaced by the selection of IETF Administration LLC, and the trustees is implemented IETF Administrative Director has been replaced by <xref
      target="I-D.ietf-iasa2-trust-update"/>.</t>

      <t>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 LLC Executive Director.  This document updates RFC 7776 to the new
      arrangement, amend these terms and provides to update a rationale for the update.</t>

    </section>

    <section anchor="background" title="Background">

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

      <t>The IETF Trust is a legal entity, registered in the
      Commonwealth of Virginia <xref target="Trust-FD"/>.</t>

      <t>Previously, the members of the IAOC target="RFC8713" format="default" sectionFormat="of" derivedContent="RFC8713"/> has incorporated those updates, so this document also served as ex officio
      Trustees of the IETF Trust. The founding documents specify
      persons eligible updates RFC 7776 to become trustees as having remove those updates.</t>
      <t pn="section-1-4">This document makes no other changes to be then-current
      members of the IAOC <xref target="Trust-FD"/>.  The documents
      also specify that if for any reason there are fewer than three
      individuals serving as Trustees, then the Internet Engineering
      Steering Group (IESG), or the IESG's successor as the leadership
      of the IETF, shall appoint one or more individuals to serve procedures described in a
      temporary capacity as Trustee(s) until eligible persons can be found.</t>

      <t>In the previous system there were eight IAOC members. Two were
      named by the IETF Nominating Committee (NomCom), one by the
      IESG, one by the Internet Architecture Board (IAB), and one by
      the Internet Society (ISOC) Board of Trustees. In addition, there
      were three ex officio members via their roles as IETF Chair, ISOC CEO,
      and IAB Chair. In addition, the IETF Administrative Director (IAD)
      served also as one of the trustees.</t> RFC 7776.</t>
    </section>
    <section anchor="approach" title="General Approach">

      <t>There were two basic approaches to resolving the issue with
      the trustees, when the IAOC ceased to exist.  One could have imagined
      merging all IETF Trust functions in the new IASA structure and
      under the new legal entity. This memo advocated a second
      approach where the IETF Trust is kept independent.</t>

      <t>The rationale for advocating the second approach is in part
      to minimize changes anchor="changes" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-changes-to-rfc-7776">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> RFC 7776</name>
      <section anchor="selection" title="Changing the Way Trustees Are Selected">

      <t>At the time when the trustees served on both the IETF Trust and the
      IAOC, many of the requirements for naming a particular group of
      people were driven by the IAOC's requirements.  For the IETF
      Trust in the new model, some of those arrangements were able to be
      rethought, both in terms of the number and source of the
      trustees, as well as anchor="changes3" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-changes-to-section-34">Changes to Section 3.4</name>
        <t pn="section-2.1-1"><xref target="RFC7776" section="3.4" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7776#section-3.4" derivedContent="RFC7776"/> is about the desired qualifications and length training of
      terms.</t>

      <t>Several options were possible, of course. A newly designed
      naming process could have been devised. the Ombudsteam.  The argument here last paragraph of that section is for a relatively
      limited change, however, largely on replaced as follows:</t>
        <t pn="section-2.1-2">OLD
        </t>
        <blockquote pn="section-2.1-3">In determining the basis of appropriate training, the IETF Trust
      arrangements generally working well, Chair and on the relatively modest
      expected time commitments combined Ombudsteam shall take professional advice and will consult with the need for very careful
      management of the assets.</t>

      <t>As a result, a smaller group of trustees appeared sufficient.</t>

      <t>In addition, the terms for the
      trustees selected from the IETF community could be set Administrative Oversight Committee (IAOC) with respect to longer than the two year period typical of other overall IETF bodies.</t>

      <t>One could have continued budget.</blockquote>
        <t pn="section-2.1-4">NEW
        </t>
        <blockquote pn="section-2.1-5">In determining the practice of having appropriate training, the chairs IETF Chair and CEOs
      from IETF, IAB, Ombudsteam shall take professional advice and Internet Society be trustees as well, but
      this may not be necessary. In general, will consult with the tasks of IETF Administration LLC with respect to the overall IETF
      Trust are well defined, and while there budget.</blockquote>
        <t pn="section-2.1-6">END</t>
      </section>
      <section anchor="changes5" numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-changes-to-section-5">Changes to Section 5</name>
        <t pn="section-2.2-1"><xref target="RFC7776" section="5" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7776#section-5" derivedContent="RFC7776"/> is a need for
      coordination, it does not need about remedies available to be at the level Ombudsteam.  The last paragraph of chairs that section is replaced as follows:</t>
        <t pn="section-2.2-2">OLD
        </t>
        <blockquote pn="section-2.2-3">Where specific action is required to ensure that a remedy is realized or
      CEOs.</t>

      <t>Given all this, one approach was enforced, the Ombudsteam will make a request in writing to have trustees appointed
      by the NomCom, IESG, and ISOC Board of Trustees. (One might also
      have considered IETF Secretariat and/or IETF Administrative Director (IAD) to take action as appropriate.</blockquote>
        <t pn="section-2.2-4">NEW
        </t>
        <blockquote pn="section-2.2-5">Where specific action is required to ensure that a remedy is realized or enforced, the Ombudsteam will make a request in writing to the IETF Administration Secretariat and/or IETF LLC legal entity instead
      of Executive Director to take action as appropriate.</blockquote>
        <t pn="section-2.2-6">END</t>
      </section>
      <section anchor="changesref" numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-changes-to-references-to-rf">Changes to References to RFC 7437</name>
        <t pn="section-2.3-1">RFC 7776 updated RFC 7437 <xref target="RFC7437" format="default" sectionFormat="of" derivedContent="RFC7437"/> by allowing the Internet Society for this role. But Ombudsteam to form a recall petition.  This document does not change any of the Internet Society
      is perhaps more suitable for associated processes. However,
               during the role, given their focus on process of documenting the
      broad use replacement of the IAOC by the IETF Trust assets Administration LLC, RFC 7437 has been obsoleted by <xref target="RFC8713" format="default" sectionFormat="of" derivedContent="RFC8713"/>, and not merely administrative
      aspects).</t>

      <t>If the same principles would continue to be used as were used
      in previous appointments, then appointments performed by part
               of that work, <xref target="RFC8713" format="default" sectionFormat="of" derivedContent="RFC8713"/> has included the
      NomCom would need update from RFC 7776.</t>
        <t pn="section-2.3-2">This document updates RFC 7776 to be confirmed by another entity, which could
      be, for instance, either remove the IESG or update of RFC 7437.</t>
        <section anchor="changemeta" numbered="true" toc="include" removeInRFC="false" pn="section-2.3.1">
          <name slugifiedName="name-changes-to-metadata">Changes to Metadata</name>
          <t pn="section-2.3.1-1">The following change is made to the IAB. The IESG had
      previously been metadata at the confirming body for head of <xref target="RFC7776" format="default" sectionFormat="of" derivedContent="RFC7776"/>:</t>
          <t pn="section-2.3.1-2">OLD
          </t>
          <blockquote pn="section-2.3.1-3">Updates: 2418, 7437</blockquote>
          <t pn="section-2.3.1-4">NEW
          </t>
          <blockquote pn="section-2.3.1-5">Updates: 2418</blockquote>
          <t pn="section-2.3.1-6">END</t>
        </section>
        <section anchor="changeab" numbered="true" toc="include" removeInRFC="false" pn="section-2.3.2">
          <name slugifiedName="name-changes-to-the-abstract">Changes to the IAOC, so it has been
      retained Abstract</name>
          <t pn="section-2.3.2-1">The following change is made to text in that role for the trustees.</t> Abstract of <xref target="RFC7776" format="default" sectionFormat="of" derivedContent="RFC7776"/>:</t>
          <t pn="section-2.3.2-2">DELETE
          </t>
          <blockquote pn="section-2.3.2-3">This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories.</blockquote>
          <t pn="section-2.3.2-4">END</t>
        </section>
        <section anchor="transition" title="Transition">

      <t>When anchor="change5-1" numbered="true" toc="include" removeInRFC="false" pn="section-2.3.3">
          <name slugifiedName="name-changes-to-section-51">Changes to Section 5.1</name>
          <t pn="section-2.3.3-1">The following change is made to text in <xref target="RFC7776" section="5.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7776#section-5.1" derivedContent="RFC7776"/>:</t>
          <t pn="section-2.3.3-2">OLD
          </t>
          <blockquote pn="section-2.3.3-3">
            <ul spacing="normal" bare="false" empty="false" pn="section-2.3.3-3.1">
              <li pn="section-2.3.3-3.1.1">Many IETF management positions are appointed by the new entity NomCom with confirmation from the IESG, IAB, or ISOC.  <xref target="RFC7437" format="default" sectionFormat="of" derivedContent="RFC7437"/> describes the
                      recall procedure for IETF Administration LLC was set up, such appointments.  This document updates <xref target="RFC7437" format="default" sectionFormat="of" derivedContent="RFC7437"/> by allowing the IAOC was expected Ombudsteam to form a recall petition on
                      its own and without requiring 20 signatories from the community.  Such a petition shall be discontinued soon
      thereafter. Fortunately, there was no pressing need to change treated in all ways like any other recall petition as
                      described in <xref target="RFC7437" format="default" sectionFormat="of" derivedContent="RFC7437"/>: that is, the components fact of the IAOC petition and its dependent organizations
      at signatories (the Ombudsteam) shall be announced to the IETF
                      community, and a Recall Committee Chair shall be appointed to complete the same time. As discussed above (<xref
      target="background"/>), the IESG holds the ability to continue
      to name trustees. And once Recall Committee process.  It is expected that the updated procedures were in place, Recall Committee will
                      receive a briefing from the IETF Trust had Ombudsteam explaining why recall is considered an appropriate remedy.</li>
            </ul>
          </blockquote>
          <t pn="section-2.3.3-4">NEW
          </t>
          <blockquote pn="section-2.3.3-5">
            <ul spacing="normal" bare="false" empty="false" pn="section-2.3.3-5.1">
              <li pn="section-2.3.3-5.1.1">The Ombudsteam may form a recall petition on its management nominated in the usual manner,
      and own without requiring signatures from the exceptional IESG process was no longer needed.</t> community as described in <xref target="RFC8713" format="default" sectionFormat="of" derivedContent="RFC8713"/>.</li>
            </ul>
          </blockquote>
          <t pn="section-2.3.3-6">END</t>
        </section>
      </section>
    </section>
    <section title="Security Considerations">

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

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

    </section>

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

      <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 implications for careful review.</t> Internet security.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      &RFC4071;
      &RFC4371;
    </references> pn="section-5">
      <name slugifiedName="name-references">References</name>
      <references title="Informative References">

      &RFC7979;
      &I-D.ietf-iasa2-struct; pn="section-5.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor='I-D.ietf-iasa2-trust-update'> anchor="RFC7776" target="https://www.rfc-editor.org/info/rfc7776" quoteTitle="true" derivedAnchor="RFC7776">
          <front>
	  <title>Update to
            <title>IETF Anti-Harassment Procedures</title>
            <author initials="P." surname="Resnick" fullname="P. Resnick">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Farrel" fullname="A. Farrel">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="March"/>
            <abstract>
              <t>IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists.  This document lays out procedures for managing and enforcing this policy.</t>
              <t>This document updates RFC 2418 by defining new working group guidelines and procedures.  This document updates RFC 7437 by allowing the Selection Ombudsteam to form a recall petition without further signatories.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="25"/>
          <seriesInfo name="RFC" value="7776"/>
          <seriesInfo name="DOI" value="10.17487/RFC7776"/>
        </reference>
        <reference anchor="RFC8713" target="https://www.rfc-editor.org/info/rfc8713" quoteTitle="true" derivedAnchor="RFC8713">
          <front>
            <title>IAB, IESG, and IETF LLC Selection, Confirmation, and Recall Process: Operation of Trustees for the IETF Trust</title> Nominating and Recall Committees</title>
            <author initials='J' surname='Arkko' fullname='Jari Arkko'> initials="M." surname="Kucherawy" role="editor">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='T' surname='Hardie' fullname='Ted Hardie'> initials="R." surname="Hinden" role="editor">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Livingood" role="editor">
              <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="10"/>
          <seriesInfo name="RFC" value="8713"/>
          <seriesInfo name="DOI" value="10.17487/RFC8713"/>
        </reference>
      </references>
      <references pn="section-5.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="Trust-FD"> anchor="RFC7437" target="https://www.rfc-editor.org/info/rfc7437" quoteTitle="true" derivedAnchor="RFC7437">
          <front>
          <title>Founding Documents</title>
            <title>IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees</title>
            <author surname="IETF Trust"></author> initials="M." surname="Kucherawy" fullname="M. Kucherawy" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date month='February' year='2014 (https://trustee.ietf.org/founding-documents.html)'/>
        </front>
        <format type='HTML'
		target='https://trustee.ietf.org/founding-documents.html'/>
      </reference>

    </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> year="2015" month="January"/>
            <abstract>
              <t>The version draft-ietf-iasa2-trust-rationale-02.txt made process by which the members of the IAB and IESG, and some editorial corrections.</t>

      <t>The version draft-ietf-iasa2-trust-rationale-01.txt includes
      changes relating to last call comments. The changes are 1)
      indication members of why the IAOC, are selected, confirmed, and recalled is specified in this document.  This document is being published 2) updates to
      references, 3) a self-consistent, organized compilation of the process as it was known at the addition time of empty security and IANA
      consideration sections, 4) editorial changes necessary for a
      document publication of RFC 3777, with various updates since that is also read later, and not just used in
      discussions at this time.</t>

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

      <t>The version draft-arkko-iasa2-trust-rationale-00.txt was published.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="10"/>
          <seriesInfo name="RFC" value="7437"/>
          <seriesInfo name="DOI" value="10.17487/RFC7437"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t pn="section-appendix.a-1">Thanks to <contact fullname="Jason Livingood"/> for suggesting the
      initial version.</t> need for this document.</t>
      <t pn="section-appendix.a-2"><contact fullname="Subramanian Moonesamy"/>, <contact fullname="Sean       Turner"/>, <contact fullname="Jon Peterson"/>, <contact fullname="Roman       Danyliw"/>, and <contact fullname="Barry Leiba"/> raised useful points
      during their reviews of this work.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Pete Resnick" initials="P." surname="Resnick">
        <organization showOnFrontPage="true">Episteme Technology Consulting LLC</organization>
        <address>
          <postal>
            <street>503 West Indiana Avenue</street>
            <city>Urbana</city>
            <region>Illinois</region>
            <country>United States of America</country>
            <code>61801-4941</code>
          </postal>
          <phone>+1 217 337 1905</phone>
          <email>resnick@episteme.net</email>
        </address>
      </author>
      <author fullname="Adrian Farrel" initials="A." surname="Farrel">
        <organization showOnFrontPage="true">Old Dog Consulting</organization>
        <address>
          <email>adrian@olddog.co.uk</email>
        </address>
      </author>
    </section>
  </back>
</rfc>