<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-deen-ietf-ipmc-update-02" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title abbrev="IETFIPMC">Update to Recognize the IETF IPMC as the IETF Trust Successor</title>
    <seriesInfo name="Internet-Draft" value="draft-deen-ietf-ipmc-update-02"/>
    <author fullname="Glenn Deen">
      <organization>Comcast-NBCUniversal</organization>
      <address>
        <email>rgd.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2026" month="February" day="27"/>
    <area>General Area</area>
    <workgroup>gen</workgroup>
    <keyword>IETF IPR</keyword>
    <keyword>IETF Trust</keyword>
    <keyword>IETF IPMC</keyword>
    <abstract>
      <?line 51?>

<t>This document updates IETF documents that reference the IETF Trust to include the Trust's successor, the IETF Intellectual Property Management Corporation.</t>
      <t>Discussion of this draft is on the ipr-wg@ietf.org mailing list.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://gitnnelg.github.io/draft-deen-ietf-ipmc-update/draft-deen-ietf-ipmc-update.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-deen-ietf-ipmc-update/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        genarea Working Group mailing list (<eref target="mailto:ipr-wg@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ipr-wg"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ipr-wg/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/gitnnelg/draft-deen-ietf-ipmc-update"/>.</t>
    </note>
  </front>
  <middle>
    <?line 57?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The IETF Trust, a Virginia trust, was established in 2005 as the intellectual property rights (IPR) manager for the IETF. The IETF Trust has held and managed IPR, including those granted by authors of IETF Contributions and IETF Documents following the terms of BCP78, currently specified in <xref target="RFC5378"/> and its predecessors.</t>
      <t>The IETF Intellectual Property Management Corporation (IPMC), a Delaware not-for-profit corporation was established in December 2022 with the intention of being the successor to the IETF Trust, replacing it and assuming all of its roles and responsibilities. Since its establishment the IETF IPMC has been undertaking the necessary steps to establish itself as a 501c3 non-profit, to prepare for and execute the transfer of all assets held by the IETF Trust, and to update where necessary agreements and IETF documents to complete the task of assuming the role as the replacement of the IETF Trust.</t>
      <t>The IETF Trust has never held or been involved in patents and likewise, the IETF IPMC will continue not being involved with any patent related activity.</t>
      <t>This document updates RFC 5378, RFC8714, RFC8721 and other IETF documents to recognize that the IETF IPMC is now the proper custodian of all IETF-related intellectual property rights and successor in interest to the IETF Trust.</t>
    </section>
    <section anchor="updates">
      <name>Updates</name>
      <section anchor="references-to-the-ietf-trust-in-ietf-rfcs-and-bcps">
        <name>References to the IETF Trust in IETF RFCs and BCPs</name>
        <t>All references to “IETF Trust” in any IETF document, including RFCs, BCPs, Internet-Drafts, and other IETF publications, shall be read and interpreted as referring to the IETF Intellectual Property Management Corporation (IETF IPMC) as the successor entity.</t>
        <t>The IETF IPMC has assumed all rights, responsibilities, and obligations previously held by or attributed to the IETF Trust in such documents.</t>
      </section>
      <section anchor="websites-and-urls">
        <name>Websites and URLs</name>
        <section anchor="ietf-ipr-ietforgipr-and-ietforgprocessipr">
          <name>IETF IPR: ietf.org/ipr and ietf.org/process/ipr</name>
          <t>The IETF publishes information on intellectual property rights (IPR) at <eref target="https://ietf.org/ipr">IETF IPR</eref> and more general information at <eref target="https://ietf.org/process/ipr">ietf IPR process</eref> dealing with IETF IPR topics in general and including patents.</t>
        </section>
        <section anchor="ietf-trust-trusteeietforg">
          <name>IETF Trust: trustee.ietf.org</name>
          <t>The IETF Trust, historically has published information related to licensing, assets, finances and notices of actions and changes on it's web site <eref target="https://trustees.ietf.org">https://trustee.ietf.org</eref>.  This web site shall be maintained in perpetuity as URLs to it appear in published documents and the Trust Legal Provisions (TLP) version 1.0-5.0 that were active at the time of an I-D submission and the date of a RFC publication will continue to apply to those works even after subsequent transfer of those IPR assets to the IETF IPMC.   The existing URLs in the required copyright boilerplate and other sections of I-Ds and RFCs will continue to work correctly for users of those documents.</t>
        </section>
        <section anchor="ietf-ipmc-wwwietf-ipmorg">
          <name>IETF IPMC: www.ietf-ipm.org</name>
          <t>The IETF IPMC, has established <eref target="https://www.ietf-ipm.org">https://www.ietf-ipm.org</eref> as its official corporate website which it will use to publish governance and operational information including bylaws and financial statements and legal notices, along with the updated IETF IPMC published Technical Legal Provisions (TLP 6.0) which provide licensing terms for I-Ds and RFCs.</t>
          <t>Cross reference navigation links on the old IETF Trust and the new IETF IPMC websites shall be established to provide easy navigation between them to users.</t>
        </section>
      </section>
      <section anchor="updates-to-rfc5378">
        <name>Updates to RFC5378</name>
        <t>RFC5378 has a number of cited URLs directing readers to the locations of various IPR related information.   The IETF Trust web site URLs shall be maintained to preserve the URLs to it found in RFC5378.  There is no need to update or modify existing references in I-Ds or RFCs.</t>
        <t>Additionally, RFC5378 is hence updated to include the IPMC web site as the location for the IETF IPMC's licensing information for the assets help by the IETF IPMC, inclunding required notices.</t>
        <section anchor="ietf-ipmc-technical-legal-provisions-relating-to-ietf-documents-tlp">
          <name>IETF IPMC Technical Legal Provisions Relating to IETF Documents (TLP)</name>
          <t>The IETF Trust publised a series of documents commonly known as the "TLP" versions 1.0-5.0 containing basic common licensing declarations and required boilerplates and notices in I-Ds and RFCs.  The formal name for these documents was "IETF Trust Legal Provisions Relating to IETF Documents", hence the easier "TLP" common name.  To maintain this common terminology, while recongizing that the IETF IPMC is not a trust, the next version shall be also known as the TLP 6.0, with the new formal name being the "IETF IPMC Technical Legal Provisions Relating to IETF Documents" which shall be published starting as IETF IPMC TLP version 6.0 to maintain version consistency with the IETF Trust's TLP 1.0-5.0.</t>
          <t>TLP 6.0 is publised by the IETF IPMC on its website.</t>
        </section>
      </section>
      <section anchor="use-of-ietf-trust-and-ietf-ipmc-in-other-ietf-ipr-framework-documents">
        <name>Use of IETF Trust and IETF IPMC in other IETF IPR Framework Documents</name>
        <t>All references to the IETF Trust in <xref target="RFC5378"/> (BCP78) and related operational documents shall be read as referring to the IETF IPMC effective upon the transition.</t>
        <t>Updated versions of required copyright notices in I-Ds and RFCs reflecting this change can be found in Section 6 of the TLP 6.0.</t>
        <t>Note that no required retroactive changes of copyright notices in prior IETF documents are to be made.</t>
        <t>While it is not necssary to update pre-IPMC copyright notices, it is correct and accurate to refer to the IETF IPMC as the holder of all the intellectual property rights and assets previously held by the IETF Trust, since these have all been moved to the IETF IPMC.</t>
      </section>
      <section anchor="rfc8721-advice-to-the-ipmc-directors-on-the-ietf-ipmc-on-rights-to-be-granted-in-ietf-documents">
        <name>RFC8721 Advice to the IPMC Directors on the IETF IPMC on Rights to be Granted in IETF Documents</name>
        <t><xref target="RFC8721"/> provides advice to the IETF Trustees of the IETF Trust on rights to be granted in IETF documents.  This advice is updated to be directed at the IETF IPMC Board of Directors in the same capacity as it was for the IETF Trustees.</t>
      </section>
      <section anchor="intellectual-property-rights-held-by-ietf-trust">
        <name>Intellectual Property Rights Held by IETF Trust</name>
        <t>The intellectual property rights held by the IETF Trust have been transferred to the IETF IPMC, as the successor the IETF Trust.  Inquiries regarding licenses and other IPR topics should now be made to the IETF IPMC.</t>
      </section>
      <section anchor="rfc-streams">
        <name>RFC Streams</name>
        <t><xref target="RFC8729"/> defines a series of RFC Streams - IETF, IAB, IRTF and Independent Stream and <xref target="RFC9920"/> adds the Editorial Stream as the different distinct publication streams under the RFC Series.    Mentions of the IETF Trust and intellectual property rights management in RFC8729, RFC9920 and their related RFCs are updated to recognize the IETF IPMC as the successor and replacement to the IETF Trust as the party responsible for providing the same role of copyright holder and adminstrator for those RFC Streams.</t>
        <t>Specifics for each RFC Series Stream were described the IETF Trust's TLP 5.0 section 8, with the exception of the Editorial Stream which was not mentioned explicity in TLP 5.0 due to its creation after the publication of TLP 5.0. The IETF IPMC is assuming the role of the IETF Trust as described in TLP 5.0 and additionally it is formally adding the Editorial Stream into TLP 6.0.</t>
        <t>Additional details on the RFC Series Streams can be found in the IETF IPMC TLP version 6.0 published on the IPMC website.</t>
      </section>
      <section anchor="ietf-trustees-and-ipmc-directors">
        <name>IETF Trustees and IPMC Directors</name>
        <t><xref target="RFC8714"/> defines the selection and recall processes for IETF Trustees, under which Trustees are directly selected by the designated selecting organizations (the IETF NomCom, the IESG, and the ISOC Board of Trustees) to serve as Trustees of the IETF Trust.</t>
        <t>The process for selecting IETF IPMC Directors is structurally different but functionally equivalent. While IPMC Directors are not appointed directly by the selecting organizations, the outcome is the same: director selection authority is effectively exercised by the same RFC 8714-designated bodies, and director terms track the same durations specified in RFC 8714 for IETF Trustees.</t>
        <section anchor="corporate-governance-context">
          <name>Corporate Governance Context</name>
          <t>The IETF IPMC is a Delaware nonstock corporation with no members. Because Delaware General Corporation Law (DGCL) does not provide for the appointment of directors by third-parties, such corporations typically operate with self‑perpetuating boards, meaning that directors are elected by the sitting board rather than by members or shareholders or third-parties. This governance model is expressly reflected in the IPMC bylaws.</t>
        </section>
        <section anchor="ipmc-director-selection-mechanism">
          <name>IPMC Director Selection Mechanism</name>
          <t>The process for IPMC board composition is defined in IPMC Bylaws § 3.3, and operates as follows:</t>
          <ul spacing="normal">
            <li>
              <t>Initial Board Formation (§ 3.3(a))</t>
            </li>
          </ul>
          <t>The initial directors of the IPMC were the IETF Trustees serving at the time of the IPMC’s incorporation. This ensured continuity of fiduciary responsibility and alignment between the Trust and the newly formed IPMC.</t>
          <ul spacing="normal">
            <li>
              <t>Subsequent Director Selection (§ 3.3(b))</t>
            </li>
          </ul>
          <t>Upon expiration of an IPMC director’s term or their resignation, the sitting IPMC Board elects a successor director. However, the pool of eligible candidates is constrained:</t>
          <ul spacing="normal">
            <li>
              <t>Each director seat is associated with a specific nominating organization (IETF NomCom, IESG, or ISOC Board of Trustees), consistent with RFC 8714.</t>
            </li>
            <li>
              <t>When a term expires or a director resigns, the relevant nominating organization selects the individual to be nominated.</t>
            </li>
            <li>
              <t>That individual is then submitted to the IPMC Board, which is then required under the bylaws to formally elect the nominee as a director.</t>
            </li>
          </ul>
          <t>In practice, this means that while the legal act of election is performed by the IPMC Board (as required by Delaware law), the substantive selection authority rests with the RFC 8714-designated nominating organizations.</t>
        </section>
        <section anchor="protection-of-nominating-organization-rights">
          <name>Protection of Nominating Organization Rights</name>
          <t>The rights of the nominating organizations are protected by IPMC Bylaws § 3.6. That provision restricts the Board’s ability to:</t>
          <ul spacing="normal">
            <li>
              <t>Modify eligibility requirements for directors, or</t>
            </li>
            <li>
              <t>Alter or eliminate the rights of nominating organizations to nominate directors</t>
            </li>
          </ul>
          <t>unless such changes are approved by:</t>
          <ul spacing="normal">
            <li>
              <t>A two‑thirds vote of all then‑serving directors, and the affirmative vote of any director representing a nominating organization that would be adversely affected by the change.</t>
            </li>
          </ul>
          <t>The practical effect of this safeguard is that no nominating organization can be disenfranchised or have its representation diluted without its own consent, expressed through its representative director’s affirmative vote. This creates a strong governance lock‑in consistent with both Delaware law and the community‑driven structure envisioned by RFC 8714 and is in fact a more stringent control than exists under the Trust Agreement, where the consent of an affected organization is not required.</t>
        </section>
        <section anchor="ipmc-director-recall">
          <name>IPMC Director Recall</name>
          <t>RFC 8714 also defines recall mechanisms for IETF Trustees appointed by each of the selecting organizations.</t>
          <t>Within the IPMC governance framework, these RFC 8714 recall authorities are implemented through IPMC Bylaws § 3.3(c). Under that provision:</t>
          <ul spacing="normal">
            <li>
              <t>Each nominating organization retains the authority to replace its designated representative on the IPMC Board of Directors.</t>
            </li>
            <li>
              <t>When a nominating organization exercises its recall or replacement authority, the IPMC Board is required under the bylaws to elect the replacement nominee.</t>
            </li>
          </ul>
          <t>As with director selection, the Board’s role is ministerial and legally required under Delaware corporate law, while the decision to recall or replace a director remains entirely with the relevant nominating organization, consistent with RFC 8714.</t>
        </section>
      </section>
      <section anchor="ietf-ipmc-recognition-of-ietf-bcps">
        <name>IETF IPMC recognition of IETF BCPs</name>
        <t>The IETF IPMC bylaws obligate the IETF IPMC to manage IETF assets for the benefit of the IETF. Therefore, the IETF IPMC looks to comply with IETF BCPs, as far as legally possible to guide its directors in carrying out that obligation.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document has no security considerations.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC4748">
        <front>
          <title>RFC 3978 Update to Recognize the IETF Trust</title>
          <author fullname="S. Bradner" initials="S." role="editor" surname="Bradner"/>
          <date month="October" year="2006"/>
          <abstract>
            <t>This document updates RFC 3978 "IETF Rights in Contributions" to recognize that the IETF Trust is now the proper custodian of all IETF-related intellectual property rights.</t>
            <t>This document does not constrain how the IETF Trust exercises those rights. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4748"/>
        <seriesInfo name="DOI" value="10.17487/RFC4748"/>
      </reference>
      <reference anchor="RFC5378">
        <front>
          <title>Rights Contributors Provide to the IETF Trust</title>
          <author fullname="S. Bradner" initials="S." role="editor" surname="Bradner"/>
          <author fullname="J. Contreras" initials="J." role="editor" surname="Contreras"/>
          <date month="November" year="2008"/>
          <abstract>
            <t>The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. 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="78"/>
        <seriesInfo name="RFC" value="5378"/>
        <seriesInfo name="DOI" value="10.17487/RFC5378"/>
      </reference>
      <reference anchor="RFC8714">
        <front>
          <title>Update to the Process for Selection of Trustees for the IETF Trust</title>
          <author fullname="J. Arkko" initials="J." surname="Arkko"/>
          <author fullname="T. Hardie" initials="T." surname="Hardie"/>
          <date month="February" year="2020"/>
          <abstract>
            <t>This memo updates the process for selection of Trustees for the IETF Trust. Previously, the IETF Administrative Oversight Committee (IAOC) members also acted as Trustees, but the IAOC has been eliminated as part of an update to the structure of the IETF Administrative Support Activity (IASA). This memo specifies that the Trustees shall be selected separately.</t>
            <t>This memo obsoletes RFC 4371. The changes relate only to the selection of Trustees. All other aspects of the IETF Trust remain as they are today.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="101"/>
        <seriesInfo name="RFC" value="8714"/>
        <seriesInfo name="DOI" value="10.17487/RFC8714"/>
      </reference>
      <reference anchor="RFC8721">
        <front>
          <title>Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents</title>
          <author fullname="J. Halpern" initials="J." role="editor" surname="Halpern"/>
          <date month="February" year="2020"/>
          <abstract>
            <t>Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accept direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions. This document obsoletes RFC 5377 solely for the purpose of removing references to the IETF Administrative Oversight Committee (IAOC), which was part of the IETF Administrative Support Activity (IASA).</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8721"/>
        <seriesInfo name="DOI" value="10.17487/RFC8721"/>
      </reference>
      <reference anchor="RFC8729">
        <front>
          <title>The RFC Series and RFC Editor</title>
          <author fullname="R. Housley" initials="R." role="editor" surname="Housley"/>
          <author fullname="L. Daigle" initials="L." role="editor" surname="Daigle"/>
          <date month="February" year="2020"/>
          <abstract>
            <t>This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This document obsoletes RFC 4844.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8729"/>
        <seriesInfo name="DOI" value="10.17487/RFC8729"/>
      </reference>
      <reference anchor="RFC9730">
        <front>
          <title>Interworking of GMPLS Control and Centralized Controller Systems</title>
          <author fullname="H. Zheng" initials="H." surname="Zheng"/>
          <author fullname="Y. Lin" initials="Y." surname="Lin"/>
          <author fullname="Y. Zhao" initials="Y." surname="Zhao"/>
          <author fullname="Y. Xu" initials="Y." surname="Xu"/>
          <author fullname="D. Beller" initials="D." surname="Beller"/>
          <date month="March" year="2025"/>
          <abstract>
            <t>Generalized Multiprotocol Label Switching (GMPLS) control allows each network element (NE) to perform local resource discovery, routing, and signaling in a distributed manner.</t>
            <t>The advancement of software-defined transport networking technology enables a group of NEs to be managed through centralized controller hierarchies. This helps to tackle challenges arising from multiple domains, vendors, and technologies. An example of such a centralized architecture is the Abstraction and Control of Traffic-Engineered Networks (ACTN) controller hierarchy, as described in RFC 8453.</t>
            <t>Both the distributed and centralized control planes have their respective advantages and should complement each other in the system, rather than compete. This document outlines how the GMPLS distributed control plane can work together with a centralized controller system in a transport network.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9730"/>
        <seriesInfo name="DOI" value="10.17487/RFC9730"/>
      </reference>
      <reference anchor="RFC9280">
        <front>
          <title>RFC Editor Model (Version 3)</title>
          <author fullname="P. Saint-Andre" initials="P." role="editor" surname="Saint-Andre"/>
          <date month="June" year="2022"/>
          <abstract>
            <t>This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document establishes the Editorial Stream for publication of future policy definition documents produced through the processes defined herein.</t>
            <t>This document obsoletes RFC 8728. This document updates RFCs 7841, 8729, and 8730.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9280"/>
        <seriesInfo name="DOI" value="10.17487/RFC9280"/>
      </reference>
      <reference anchor="RFC9920">
        <front>
          <title>RFC Editor Model (Version 3)</title>
          <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
          <author fullname="A. Rossi" initials="A." surname="Rossi"/>
          <date month="February" year="2026"/>
          <abstract>
            <t>This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document specifies the Editorial Stream for publication of future policy definition documents produced through the processes defined herein.</t>
            <t>Since the publication of RFC 9280, lessons have been learned about implementing this model. This document lists some of those lessons learned and updates RFC 9280 based on that experience. This document obsoletes RFC 9280.</t>
            <t>This document updates RFCs 7841, 7991, 7992, 7993, 7994, 7995, 7996, 7997, 8729, 8730, and 9720.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9920"/>
        <seriesInfo name="DOI" value="10.17487/RFC9920"/>
      </reference>
    </references>
    <?line 195?>

<section anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The IETF Trustees and IETF Intellectual Property Management Corporation directors during the restructuring of the IETF Trust to the IETF IPMC were: Glenn Deen, John Levine, Joel Halpern, Kathleen Moriarty, Victor Kuarsingh, Jon Peterson, Kristin Berdan, Wendy Seltzer.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA6Vby3IbyZXd11fkUIshHQD06m5JXJkiW2q5JVlBStbCMYtE
VQLIYCETzqwChHY4Qr/g5USM1176H/wp+pK5j3xVAaTdM4umAFQ+bt7Huefe
rJ5Op1XV6a5V5+Lk06aRnRKdFdeqtkujf4EvKyXe/PjxlXjz4d2lkD7/8NH1
vhM3fV0r7607qeR87tQW1sHHOPykqmG9pXX7c6HNwlZVY2sj17BX4+SimzZK
malW3WKqN+t62tP+0xb++K6qfD9fa++1Nd1+A3NoV/FAyNZb2EWbRm0U/DHd
yUScqEZ31mnZ4pc3Fy/hH+vg0/XHVyeV6ddz5c4rXP+8qq3xyvjen4vO9aoC
mZ9W0ikJq75WRjnZigv4elLtrLtdOttvzsVSmcp30jSytQak2StfVbdqD0Oa
80pMo5au02dSUPHk3WVVbZXpQQIhRFj2BNaVtBf8xuc8+Qy7arMUr3EIPVhL
3YION266W/4WFTazbokPpKtX52LVdRt//vAhDsNf9FbN4qiH+MPDubM7rx7y
CrS97lb9/Bz/NUa1y4f3WATHs1HyVnHejBeaaXvfCvc9m626dVtVsu9W1qEm
cTux6NuWXeV1q4wRVzCVHsCRJHim7MAvzsWlXdfSd9P3Ly8/GTi287KlYYpV
5pYNaeK3S/w+q+26qipj3Rrmb9kQ168uv3v23fP4+funz9Ln588ef5c/P3lc
fH4RP7949vRR+vzkOXyu0NfTDtVsNquq6XQq5Nx3Ttbg2R9X2guIhX4NzitY
DZ7dJP6KgSY74dRCOWVqNY47CFJt6rZv+An9+J9e+BiOkyJyTafaVtVdD379
wdmNct1evJNGLhUJcGndxjrSKIh6pX3dU9gJu4BVUFS0noAP8BsuO3JEck90
2Fb7Lhx2rZumVVX1ALd3tulrXB6PXh5jIqT4g3ZLbbTEWMRfdgAy4GpyDqut
VAPHFE8ePfo+Yo8uT7OJp3F6uQKdnUL8nYE4eDQnwApJCzMx3FmsYL2VahsB
IR1mNBi+k6BXPA94pFcQqRL2bMR8L9hJPSqGlroEbHJ63uPZPK1EP18lIy5s
29odrwWWUm5Nk19efnj2fCLq3oFxu3Yv/EbVeqH5uH/+838ER/zLX2hRDStt
nGoU29bPCj3+Guuift5dnqHWr1QrdwA8wthuCoqagioXuhN1MfqIJa5ABIRS
MMmTJ2IHsZ+MYrrgMnMVz5u8Ed21G1neqU0raxwK2+Ippff9Gr/LtsV18NTO
tooV65TfgJL1HFyt08rPxI3GuMBRSUg68DBloZ3nAB6ih1ThOnkbhTOkTelA
+Z3aeBQxrYOrqnaBPifF948e109BTyboaIJDwRwbVB/6GIqnvqi67zgYIcqN
h7jFQ+BZ4GCqC94GTjRWBE6HFRkGxG6lXCmcXDql2JmSfxUgYcFi602r4tbS
39K2UZf4Iyoxhg9rnT2DwruUZTaOT9KeUYCrLD0clnSpzda2W3aJjeySdK2+
VTvt1WRkhJ0GNUDa7TSkP3S54CRpHfIkafZhNRATEw74BMDGVnf72V2gCYEi
MFImEa8nEaxJIAtyuCNKcwXBkWOXgX2M3dGPDDAQqL6zjZYmmhQHT6OQ90IS
SpHjQBsaDc7cHcbEDOFSMAsDcvHgAfCwAP/+cDSuRd/gvLwNoApMuwDx3GDe
t6//k6d9+/o3nIm6HqilxD1ccULLTQhfnFHd9AqTgJ+M1brpIWJqAgx46Feo
nTn6mWRopeNCtJA1PUvmyDPt/y1FAYhFS51Fr84KRhgK7jJGAYoJlAIVRMaZ
HKBKOB4caclHwkDfatt7AOkYwBjyHeO+ao4bBgRaZY+bkTE/q7nXXYCzT9dv
ycQPEm8EfhcpG+RX1l38AZwKz4cPipOR6gGZvUiMAxHY/Ds5Epz+j3Hn/zqN
rK6U4IwzowU0WgZSXG6DC+BwXEAE+Y4sVEh+JholiSdQtMfdQYEbXeMZ0j7s
N9EbA8DMCnWRns+ZMajMdQ/pBWAGVgU12HxPThB11gwOEyMZbAnODLUB7DsJ
uD0RC20kxRLKBeCl8TMCQZ3zfr2SZqmIIWkkYjs1F2ht8ceokrGwWVnhiU+P
zmZCENylVVJcAdUyHfwXsBdCS3U9eDxGAvoUEUPIp5uNkgQ3+cAZACnjRNYo
3qolR91WezrP6ce3H84EkmnUzePZo+n3s0cMlDtMTgTKSgTc7PRakTYAjqZX
IldtaRvKaziC0LoAjFFeANFBbjAUhRRSL6y/IL1D1SQAfAByYHWv/tRTmi+y
LI9GZwq5dgAuAACgUCKA6gs4BDoV6UqbkBP/1GugVyDJZk9RIuZWt6Bb9IoC
8LwKFkf+N71iRRL8HhwEJUcyBYkG+R3ShN4rpo4s7RAdHmRZz8Vut5vFMmnk
1zhgQp5cMrPkZOOZ2cnGTwg7kTzZxULXUDcn6qfQ7cjrditdIxfi44H8xHzY
ocTSgodQYLCGwBfJqCOcyHE83wPlZJ1xROGmcIiuoDct+WKIMYhAqLWXmWZy
0m8KXM/e/VHVK4OBftyfxQ+zR2fhQBt8BIVTCvVAzNFIA7OCZS6d9b4ow4zc
htQA081tKols25QpILq+UbuSBsUMkMK5NCKxSpZMSb8vt5qrboe8C5ZcE1dE
V+KsEugCdW24aKiq8IGznuDmBzperVF75PqNRs/Es2OmRscMIdPakMxxwlY6
zH0UWZntJOPGqCoOnhCLdjkGW0ye4QBbpqwFai1sT8gfT0IwiIhDjAyUqUqm
DNZaAylb7HNUF7xHG7YljAqmvGgazQ7a7idxC1x6RZaNzjWqrKPh+FSBb0Ql
DUpMGgrQn92qjIM4MhcDm0ExwIFNO5uGzxJQKUTDGCbu8/hrtFUgWaOKlMD9
gOdzHCE5ApBzmvNbThhQY6ytARy7BWJsohZOYKmTmCd8ShQIg2BqCnnpdR1m
F3qBQraVTubsmc5a4O4w3UZzptBkzyP9AmDItYoaLqGVStiT4py/QlMnk+AY
eFQISA0xxCcO58FNUQybvJu7JeExYoo2trVL8DYAnlZR1WGW+hcuzI7XHYAd
sRPCAPKlS6k4hRO2QIe2CBA3yWCJ0FOqJ5flJ/9PHzoJOJrEySgMcOZokvSl
p4Jw8Qw/IJUoVBZ/x6YsRDFofJ/PkC0HcYWrBB9Dfs8HRqUl5x3HE7MxH3E3
AKZXqX+TwbqwginLG0S+Vw70Rwk9qeBYmXVYBQwaOafU9DkL/s5YWibN7LSj
IurOogmlVYuFYjrWb0IqImKkQzfvU0C1FKVw9CN8564ww63bkCjYuYnnilpi
UsqAfcPMSPwQmwrBPCDBe9uFKtvYvDUUhM4GIpm48+K4RBtIQgdFPDZfQBuU
Wxo07WcKMd3FMDKq5g5KzhiQd6aktYNtJmFiYGzcj6rr3oULEbLAofZD8K0g
++d2z7/sUoZml+qOVpfj9pDXAYTAb1cSeTc5B7CBtd2O6k+iutw5CE2Qi2ar
a5UGodBXlPqpjWkO4+WaZWTVvg6tz9hqKPyffRv3AN8OvAWONtwuHUMpf9hu
wu1cud1ytF2myKEeCsvDpyJbw0RmM5i+xpj60krX4Nb51IH1ewTFWm5kHcon
5LnSD1N6FJ6VerxNETT2U7BfcfdDWfZeVzhudLYz2ThWOe6IpSeH7Y9RQ0mA
yBhwmNAdALxruE2PiTgk2IB1uQ73K9u3DXXAQnDd7WLipgOMWpfu8ALcoVFA
8HH9gkwUo8OV2ES8uXgJf65hVYLgfKEXRtLPvPKLF08eYTe8afjIP8brvjSU
fwc+SJjcwSfkhHU3KDh9kICawTSB5CIpkc2Kd9zHPuatsZt1pzHXuV/FHBbV
QUwTpY81gXYJ/rlz5wbc091/9ZpNzXkkd3MPM1CYspEkY+x0tcyUOGRTpx6D
gfrEAxAOwEaA1QCbwQssUHuIEaxiC7OCV9zwNUbNUaQkkISs32gp6iEAWNRO
z1VzPM8jjwzVtnhekBr1pVabeNFw1A+YmmAgYxJYszkVNug34AUY6mCbuEXD
xTpyhBpmc2OLGg2kuMJxYLswqbhJiqztsNt+xHt8ceZCBNZtrkxCImLmBl/x
WVj54KzgjbbItLnAga2AXLUJ4Q+M4A8y+NDbxowtM7yYM4p6luFghPYU0YN0
k0Hi8XcFSJD7qTYYm70a+3WxqahCYV6uPgkBzMbOe7qYCvBKjdbMrBC0r5eG
wixsB2otb5OhNkpKeG/Xl3YdrzFuXk9SRf/m5vdFVolbn6EbcU0Lhr475YXG
dDgaHSwLk9VfJCuPmNUD4Dhyh4xv8x4K5t7UyXGQWm1lC89mgsnQaK1w3YdN
Nqsp0SZlBR3doRjWg+07KG0o+0bIOA8r5GOgCemSlCLNZ36KAn5Rri6JOqEO
eMS3r/9Ap5gWJppDZR/b8WkPbtPgJfptnt/0sZIcXKLmZQ/dJ5TSl6nh9Tr3
svBKF2qu8QUCRnl5aQpQaOvb4XUpghRw3DXdkEI6eQl+jE2zNC2+XFLeZryV
O3F69fry7RnQHcWoFdtAqWfABouXdk2yKOlRu2aKGE/6oouHQiqPL5WE/jdX
G4oFxfvNb1//GjrIXOnN0a1hkbWSJtWozcB/RkEF4Z9nClh9RdiJ2LKPisAW
DJQ0TnE2oe8DqWdM7oqG4to2qiX3+YK9IqTHoRBRGazQLNxTjK2R0t0B76JD
vlNYYWi/Pgw+XoSEx3tUy3UT7szwxFyUiCR3L//5d/Cqp7Onk6LpicgTr/r9
eVX9BqgMrAOGZpx4lZpAp3H6qTw7i/SQh2Y1R9BghHXjVz8QVxBpqMoetuDj
tG9f/xtpbuEGQcX41hMXftSpxhiFaQvd9LXGUmlwHbbn3NRCSJLnFU3Iwy4n
97jXqokE8TfiJvfqjxglq2KOqviE1StYW7uUb2XQfNQMnQohgB2IiRQDBsyY
DPyx4P60I3HRRJ3iijPxk93h7TZP3lhLLx4oODLxJMiRjeb2KtWGxH/QK8jI
PyK9KfBPdoELWFBmly61IyzVENpAEuQBvIYLzZhyON2gbx7PNJPcKul4iwx1
MxDr8wpvS1hRpFBFESezqKy1gOrARdUWyq47pfNBgVzWNhqQCckvF15hkmpw
548IF8UQThSGr4S68q40WWcS7xjC0NQfyAQ9XBvA1MSJSCL2PNxfKX5RI5m1
qt5g1wDbCzW9iwDLI6aFl6q4GUd9XGp6wTg2e3BNbCkpF9w5FmfZoU6pIxMb
lvsM7/DPWXBDcP0OlIrdjWOJEe//fWa1x1PgHQaJaAf1ZxcWBuHf58G/L63H
xSlDTShTAlDctTzB/IYX5wMewb8fZmztTewX0pGcjo5CmqKAlQFLOktB8y50
7CnE+EnQZXxhKoenxzCAORctMnIsKFrN7saem45z51HAaaKH5lWrqjctJgDO
laH5hKeGPOuopzLfk7AXottZSJKUrbzY2nCPyU0eA08iEBciR1CUi4UObwHm
mWZfhiHdgxjul94Zf+yyVJNj57dBWo5sShKzyh7KB0kEk5wfnJsJWHqVz8uF
WvboxtqnrtxdW4caASppZRYOMvOK2BvITg0KekErHoJnNLrtI/QBX+QLxh13
d+klk5DQqe5ztl+uDlbZqiHij/UYUhnVa9xj6BzeEhb0oQVqBsbR5gAq5xb+
lAGbzIVd+x5y8R4mNk7jlXMk3sB6DHs5a7ugltQToJbSAlFE8vsSGAlgC9NR
ooWCkCkRXVOVvQfOohfxDa9JePmLxSGFhTyYbD0wT2h0Riw6yoKuqZaiK8Ek
M14exOor1FrrSJGOFFtFvQCHp6I+QMgd5QI2Y0HZJU8rjLOI3fRJaGoWogVp
IlDqEJca33BDDRVuc4yUndZnM/EpqLdEp5yv73J1hwWzYfDKOE39GGqxkJsW
4Dzy2LIqPmw5Fmn5rv1jbeRDPJAeGCRShyfJNRlvpv39mTMnzHK9kDyxcxCS
0WE1NxnBOXU3MJ0CbwXvoG5Eurhv92MxUqjllwvgh0mRghsgR5RAuPc1PPaQ
tazJQgiYDgEwpc9/RWHuZ0zV4FI1tN9iWqUH/F7dsB4Mug1vio2bdXTBhc1A
/i00+2M5N4cyEN+1LboDM77ohhEH70621t7mFz33xctT/IIelh7S4T/RBlDG
cJ8PJi17LCTJecsGeC2d25Oe+o5jJb/zRq8h3qi6pxC4RNU14ZrKj1/DpPdD
sfMRRteD0bTSm4v3F//eKjQyvFQVXiOfQ6mPi1zUeNvZqmYZrh+G99ep4fSr
XybMWml6l1p4KkI/qeigl3dwD4RlWvl/KkzE7+wKansF5EDhF6hmf5ItSAKP
foYqucVC6h028xyG8x80ufjPkJjxgnyFU4z4oCDAPPrvz46a2eKlco2E75+V
afZYTHW/KKS7/ws9Itd3xzMAAA==

-->

</rfc>
