Internet-Draft The IETF and the IETF Trust October 2022
Eggert & Housley Expires 22 April 2023 [Page]
Intended Status:
Best Current Practice
L. Eggert
R. Housley
Vigil Security

The Relationship between the IETF and its Trust


This document describes the expectations the IETF community has on the structure and operation of the IETF Trust.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at Status information for this document may be found at

Discussion of this document takes place on the GENDISPATCH Working Group mailing list (, which is archived at Subscribe at

Source for this draft and an issue tracker can be found at

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 22 April 2023.

Table of Contents

1. Introduction

The IETF Trust [TRUST] was created on December 15, 2005. The purposes of the Trust is to acquire, hold, maintain and license existing and future intellectual property (IPR) and other property used in connection with the Internet standards process and the IETF. The Second Amended and Restated Trust Agreement [TAV2] is the revision of the original founding document currently in effect.

Various RFCs, summarized in Appendix A, discuss the relationship of the Trust to different aspects of the IETF standards process. This document intends to complement these existing documents, capturing the expectations the IETF community has about the structure and operation of the Trust. In addition, this document clarifies the relationship between the Trust and the IETF and the applicability of BCPs that cover the IETF as a whole, without specific mention of the Trust.

2. Community Expectations about the IETF Trust

The Trust Agreement [TAV2] is the foundational document of the IETF Trust, and defines the purpose of the Trust as

It also defines the powers, rights and obligations of the Trustees and the Trust.

At a minimum, the IETF community expects the Trust to comply with the requirements placed upon it by its foundational document [TAV2].

In addition, the IETF community expects the Trust to operate transparently whenever possible, similar to how the IETF itself operates. It is also in the interest of the IETF and the Trust is a diverse set of IETF participants is able to volunteer to serve as Trustees. Transparency helps understand IETF participants the Trust, and allows them to decide whether they can volunteer.

2.1. Relationship of the IETF Trust to the IETF

The IETF community considers the Trust to be a core part of the IETF that is critical to the ongoing function of the IETF.

Consequently, the IETF community expects all RFCs that apply to the IETF to apply to the Trust, even if the Trust is not specifically referenced.

The Trust's administrative procedures [APIT] under point 9 indicate that the Trust partly agrees with this community expectation, when it comes to licensing:

  • The Trust shall be guided by IETF process documents, decisions of the IETF leadership, IETF consensus, and any legally binding agreements when licensing use of its intellectual property in accordance with the Trust Agreement.

The IETF community, however, expects the Trust to more broadly follow IETF consensus and leadership decisions, unless they would conflict with the Trust's purpose [TAV2].

2.2. Compliance with Foundational Documents

[TAV2] requires the Trust to publish a number of procedures, including:

  1. Procedures for administration of the Trust

    These have been published [APIT] and revised, with some - but not all - prior revisions available [OPPD].

  2. Procedures for reimbursement by Trustees of their fees and expenses from the Trust

    [APIT] contains a statement about reimbursements (under point 8), but does not describe a procedure.

  3. Procedures for management of the Trust assets

    No such procedures seem to be published at the time of writing.

  4. Procedures for conflicts of interest

    These have been published [COIP].

  5. Standards of conduct

    No such standards of conduct seem to be published at the time of writing.

The IETF community expects the Trust to comply with its founding document, and hence expects it to publish the missing procedures.

This is especially true for procedures for management of the Trust assets, which is the Trust's main responsibility. (The Trust does maintain a lengthy FAQ [FAQ], but that does not take the place of a procedural document on management of the Trust assets.)

2.3. Asset Licensing

Assets held by the Trust are critically important to the operation of the IETF and the broader Internet industry. The IETF community hence expects the Trust to license those assets freely, in a manner that preserves its the core rights the assets.

The Trust Legal Provisions [TLP] have been fulfilling this expectation, allowing broad use of the Trust assets both within and and outside the IETF standards process. Code components and other materials are available under the Revised BSD License [BSD3CLAUSE] or a Creative Commons Attribution 4.0 license [CCBY40], respectively.

2.4. Transparency of Operation

The IETF community expects the Trust to operate transparently whenever possible, matching the level of transparency demonstrated by other parts of the IETF.

2.4.1. Assets

The purpose of the Trust is [TAV2]

  • (...) maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process (...)

An up-to-date detailed public asset register is a key requirement to fulfill this purpose. While the Trust website contains an asset register [AREG], the information presented there is not detailed and likely out-of-date.

At the time of writing, for example, "IETF contributions" is one type of asset mentioned without further detail such as whether a copyright was granted for contributions predating [RFC5378]. Another example is that no "licenses to others" are being shown after 2015. A third is that the IRTF logo is missing from [TAL], for which the Trust was given the copyright in 2012.

In order to fulfill its purpose, the IETF community expects the Trust to maintain an up-to-date detailed public record on the assets it manages, the licenses under which different asset types may be licensable, and the license requests it receives and grants. This should as a minimum include:

  • The current known licensing position of every RFC.
  • A list of every logo, badge or other graphical asset for which the Trust holds the copyright.
  • A list of every website for which the Trust holds the copyright.
  • A list of every domain name registered to the Trust.
  • All other assets that are maintained by the Trust, such as the hardware security module holding the keys used to provide IETF Secretariat signatures for Internet-Drafts [RFC5485].

The IPR associated with IANA, which was transferred from ICANN to the IETF Trust [IICA], should be included in the detailed record of assets above.

2.4.2. Reporting

[TAV2] requires

  • The Trustees shall report annually to the IETF community concerning the activities of the Trust, including grants or licenses given by the Trust (...)

The Trust presents at the IETF plenary to report to the IETF community, and its presentations are available as part of the IETF proceedings [PM].

The Trust presents roughly once a year, which while strictly conforming to [TAV2] is notably less frequent than the other parts of the IETF that report at every plenary. The Trust should match the level of reporting of the other parts of the IETF and present at every plenary.

The Trust also makes information available on its website [TRUST], and sends occasional announcements to the IETF community by email [ANN].

However, its presentations and announcements to the community do not include information on grants or licenses given by the Trust, and the asset register on its website [AREG] is not suitable, as described in Section 2.4.1.

The Trust publishes financial information [FIN], including annual budgets and monthly statements, fulfilling the IETF community expectations on financial transparency.

2.4.3. Community Interactions

The IETF community expects to be able to have public discussions with the Trust and the Trustees. Many IETF bodies maintain public discussion email lists for this purpose, hold "office hour" sessions during IETF meetings, or allow questions during their working meetings. The Trust should explore these options to strengthen interactions with the community.

The Trust operates the "tlp-interest" mailing list [TLPINT], which was originally created for questions related to the Trust Legal Provisions [TLP]. The Trust has since informally indicated that this list should be seen as their general public discussion list. However, the list is not described or advertised as such on the Trust website.

The Trust holds regular meetings and publishes their minutes [MIN]. In order to further increase transparency and improve community interactions, the Trust should consider announcing the meetings to the public, and let observers join and ask questions.

2.5. Funding

[TAV2] charges the Trust to

  • (...) use reasonable efforts to secure contributions or commitments from third parties to contribute or make available sufficient funds to or on behalf of the Trust to administer the Trust and to maintain the Trust Assets (...)

Under [RFC8711], the IETF LLC is responsible for raising money on behalf of the IETF, specifically to avoid confusion about who is responsible for representing the IETF to sponsors.

The IETF community therefore expects the Trust to direct its fundraising solely at the IETF LLC, and conversely expects the IETF LLC to fund the operations of the Trust. Should the IETF Trust need to demonstrate a diversity of funding, the IETF LLC is expected to manage that.

2.6. Accountability

The Trust consists of five Trustees. Three are appointed by the IETF NomCom, one by the IESG, and one by the Internet Society (ISOC) Board of Trustees [RFC8714]. Trustees appointed by the NomCom may be recalled per [RFC8713]. Trustees appointed by the IESG or by the ISOC Board of Trustees may be recalled by the appointing body.

Individual decisions or actions by the Trust may also be appealed by community members [APP] following the process in [RFC2026], with the IAB and the ISOC Board of Trustees as the appeal chain. The Trust documents appeals and responses [APP].

Additionally, the IETF community as beneficiaries of the Trust, has legal standing to take action against the Trust if they believe it is not acting in their best interests.

Together, these mechanisms provide sufficient community accountability.

In the event of the Trust changing its legal structure then these three layers of accountability must be maintained.

3. Security Considerations

The usual security considerations [RFC3552] do not apply to this document.

4. IANA Considerations

This document does not request any IANA actions.

5. Informative References

"Announcements", <>.
"Administrative Procedures of the IETF Trust", , <>.
"Appeals", <>.
"Asset Register", <>.
"The 3-Clause BSD License", <>.
Creative Commons, "Attribution 4.0 International — CC BY 4.0", <>.
"Conflict of Interest Policy", , <>.
"Frequently Asked Questions", <>.
"Financials", <>.
"IANA IPR Community Agreement", , <>.
"Minutes", <>.
"Obsolete Policies, Procedures & Drafts", <>.
"IETF - Past Meetings", <>.
Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, , <>.
Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, , <>.
Klensin, J., Ed. and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, DOI 10.17487/RFC4846, , <>.
Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, , <>.
Housley, R., "Digital Signatures on Internet-Draft Documents", RFC 5485, DOI 10.17487/RFC5485, , <>.
Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743, , <>.
Braden, R. and J. Halpern, "Procedures for Rights Handling in the RFC Independent Submission Stream", RFC 5744, DOI 10.17487/RFC5744, , <>.
Malis, A., Ed. and IAB, "Procedures for Rights Handling in the RFC IAB Stream", RFC 5745, DOI 10.17487/RFC5745, , <>.
Housley, R., "Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG)", RFC 8090, DOI 10.17487/RFC8090, , <>.
Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, DOI 10.17487/RFC8179, , <>.
Haberman, B., Hall, J., and J. Livingood, "Structure of the IETF Administrative Support Activity, Version 2.0", BCP 101, RFC 8711, DOI 10.17487/RFC8711, , <>.
Camarillo, G. and J. Livingood, "The IETF-ISOC Relationship", RFC 8712, DOI 10.17487/RFC8712, , <>.
Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood, Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees", BCP 10, RFC 8713, DOI 10.17487/RFC8713, , <>.
Arkko, J. and T. Hardie, "Update to the Process for Selection of Trustees for the IETF Trust", BCP 101, RFC 8714, DOI 10.17487/RFC8714, , <>.
Arkko, J., "IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust", RFC 8715, DOI 10.17487/RFC8715, , <>.
Klensin, J., Ed., "IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology", BCP 101, RFC 8717, DOI 10.17487/RFC8717, , <>.
Halpern, J., Ed., "Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents", RFC 8721, DOI 10.17487/RFC8721, , <>.
McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed., and G. Huston, Ed., "Defining the Role and Function of IETF Protocol Parameter Registry Operators", RFC 8722, DOI 10.17487/RFC8722, , <>.
Saint-Andre, P., Ed., "RFC Editor Model (Version 3)", RFC 9280, DOI 10.17487/RFC9280, , <>.
Salz, R., "Entities Involved in the IETF Standards Process", BCP 11, RFC 9281, DOI 10.17487/RFC9281, , <>.
"Trademarks and Logos", <>.
"Second Amended and Restated Trust Agreement", , <>.
"Trust Legal Provisions (TLP)", n.d., <>.
"tlp-interest - Discussion of proposed revisions to the Trust Legal Provisions", n.d., <>.
"IETF Trust", <>.

Appendix A. RFCs about the IETF Trust

This section gives a brief overview of the various current RFCs that make statements about the Trust.

There are numerous other RFCs that mention the Trust in passing, reiterating various aspects of its purpose, process or operation. Yet others are older RFCs that have been obsoleted by the ones mentioned above.

Appendix B. Changelog


These individuals suggested improvements to this document:

Authors' Addresses

Lars Eggert
Stenbergintie 12 B
FI-02700 Kauniainen
Russ Housley
Vigil Security, LLC
516 Dranesville Road
Herndon, VA, 20170
United States of America