]> NetApp

Stenbergintie 12 B Kauniainen 02700 FI lars@eggert.org https://eggert.org/

Vigil Security, LLC

516 Dranesville Road Herndon, VA 20170 US housley@vigilsec.com

IETF This document describes the expectations the IETF community has on the structure and operation of the IETF Trust. About This Document 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 .

Introduction The IETF 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 is the revision of the original founding document currently in effect. Various RFCs, summarized in , 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.

Community Expectations about the IETF Trust The Trust Agreement is the foundational document of the IETF Trust, and defines the purpose of the Trust as

• (...) the advancement of education and public interest by acquiring, holding, maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process and its administration, for the advancement of the science and technology associated with the Internet and related technology.

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 . 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.

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 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 .

Compliance with Foundational Documents requires the Trust to publish a number of procedures, including:

1. Procedures for administration of the Trust These have been published and revised, with some - but not all - prior revisions available .
2. Procedures for reimbursement by Trustees of their fees and expenses from the Trust 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 .
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 , but that does not take the place of a procedural document on management of the Trust assets.)

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 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 or a Creative Commons Attribution 4.0 license , respectively.

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.

Assets The purpose of the Trust is

• (...) 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 , 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 . Another example is that no "licenses to others" are being shown after 2015. A third is that the IRTF logo is missing from , 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 .

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

Reporting 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 . The Trust presents roughly once a year, which while strictly conforming to 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 , and sends occasional announcements to the IETF community by email . 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 is not suitable, as described in . The Trust publishes financial information , including annual budgets and monthly statements, fulfilling the IETF community expectations on financial transparency.

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 , which was originally created for questions related to the Trust Legal Provisions . 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 . 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.

Funding 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 , 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.

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 . Trustees appointed by the NomCom may be recalled per . 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 following the process in , with the IAB and the ISOC Board of Trustees as the appeal chain. The Trust documents appeals and responses . 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.

Security Considerations The usual security considerations do not apply to this document.

IANA Considerations This document does not request any IANA actions.

Informative References n.d. n.d. Creative Commons 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. This document specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. This memo provides information for the Internet community. The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe the IETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board (IETF LLC Board), the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board. This document obsoletes RFC 4071, RFC 4333, and RFC 7691. 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. 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. The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC (IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF Administrative Support Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents. This document obsoletes RFC 7437 and RFC 8318. This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the individuals and organizations involved in the IETF standards process, as described in BCP 9. It includes brief descriptions of the entities involved and the role they play in the standards process. The IETF and its structure have undergone many changes since RFC 2028 was published in 1996. This document reflects the changed organizational structure of the IETF and obsoletes RFC 2028. 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. This document obsoletes RFC 8728. This document updates RFCs 7841, 8729, and 8730. Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document obsoletes RFC 6220 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model. 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). In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure. In addition to more substantive changes that are described in other documents, the transition to the 2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere. Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes. This document captures the rationale for the changes introduced in RFC 8714, "Update to the Process for Selection of Trustees for the IETF Trust". At the time RFC 8714 was published, the changes 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. This document summarizes the Internet Engineering Task Force (IETF) - Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in 2018. The IASA was revised under a new "IASA 2.0" structure by the IASA2 Working Group, which changed the IETF's administrative, legal, and financial structure. As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031. The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879. This document outlines the procedures by which the IETF makes appointments to the Community Coordination Group (CCG), which provides advice and guidance to the IETF Trust in matters related to the IANA trademarks and the IANA domain names. IAB This document specifies the procedures by which authors of RFC IAB stream documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community. This document specifies the procedures by which authors of RFC Independent Submission documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community. There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher. This memo provides information for the Internet community. This memo defines the publication stream for RFCs from the Internet Research Task Force. Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. This document is not an Internet Standards Track specification; it is published for informational purposes.

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

• , aka BCP11, describes the role of the Trust in the context of other entities involved in the IETF standards process.
• defines the role of the Trust in Version 3 of the RFC Editor Model.
• defines that the Trust holds - on behalf of the IETF - any intellectual property rights of IETF protocol parameter assignment information, including the registry and its contents, and all registry publications.
• describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions.
• updates the process for selection of Trustees for the IETF Trust under Version 2 of the IETF Administrative Support Activity (IASA) ; updates the related IETF terminology. Together, these three RFCs form BCP101. captures the rationale for the changes introduced in .
• , a part of BCP10, defines the selection, confirmation, and recall process of IETF nominating and recall committees, including for Trustees.
• describes the IETF-ISOC relationship and reiterates that ISOC selects one of the Trustees.
• , aka BCP79, sets out the IETF policies concerning IPR related to technology worked on within the IETF.
• outlines the procedures by which the IETF makes appointments to the Community Coordination Group (CCG), which provides advice and guidance to the IETF Trust in matters related to the IANA trademarks and the IANA domain names.
• , and clarify that the Trust also manages the copyrights associated with RFCs published on the IAB, Independent and IRTF RFC streams.
• that the Trust logically owns the hardware security module holding the keys used to provide IETF Secretariat signatures for Internet-Drafts.
• , aka BCP78, is the key document that details which rights IETF contributors provide to 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.

Changelog

draft-eggert-ietf-and-trust-00 Initial submission.

Acknowledgments These individuals suggested improvements to this document: