Skip to content

Commit

Permalink
Merge pull request #65 from ietf-llc/jay-updates
Browse files Browse the repository at this point in the history 
Renamed Ombudsteam to Legal Risks and updated Trust
  • Loading branch information
@jlivingood
jlivingood authored Aug 27, 2024
2 parents d6720ac + c678d1f commit ce46231
Showing 1 changed file with 13 additions and 15 deletions.
28 changes: 13 additions & 15 deletions draft-iasa2-retrospective-2.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -138,42 +138,40 @@ To the extent that the IETF LLC undertakes any significant special projects for

## D. Other Gaps

### Ombusteam
### Legal risks

After the IETF LLC was formed, [RFC 7776](https://www.rfc-editor.org/info/rfc7776) was updated in [RFC 8716 / BCP 25](https://www.rfc-editor.org/info/rfc8716). However, no other substantive changes in the operation or oversight of the Ombudsteam were made; the name of the IAOC function was simply updated to the IETF LLC. Since that time, the IETF LLC has identified some issues of concern that need to be addressed by the IETF as a whole.
The IETF LLC is responsible, on behalf of the IETF, for legal compliance, which includes managing legal risks and third-party legal activity. Since 2018, this has included things such as responding to subpoenas, initiating litigation to recover debt and responding to threats of litigation. This recent experience has identified two important gaps that need to be resolved.

The IETF LLC Board is responsible for assuring the long term financial solvency of the IETF and safeguarding it from a variety of risks. These responsibilities give the IETF LLC a fiduciary and legal responsibility.
First, is how the IETF as a whole responds when a third-party makes a credible threat of litigation against the IETF or initiates litigation against the IETF. In these cases, the best practice is to minimize risk by only communicating with the litigant through counsel. However, with an organization as distributed and volunteer-based as the IETF, it is not clear how this affects the roles and activity of such groups as the IESG or Ombudsteam when communication with or engaging with third-parties thave have threatened or are engaged in litigation agains the IETF.

The Ombudsteam is a critical function for the IETF to mitigate the risk of harassment in the IETF. The IETF LLC Board has identified two concerns that should be addressed by the IETF community.
To address this first gap, we propose consulting with the IESG, IAB, IRTF, Ombudsteam, and any other parts of the IETF to agree a legal protocol to be used to communicate with a third-party who makes a credible threat of litigation or initiates litigation, and to document this in an official IETF LLC policy. As with other policies, this would be developed with community input.

First, the work of the Ombudsteam function can have significant legal implications for the IETF (e.g., harassment, assault). However, under the current operating practices defined in RFC 7776, the IETF LLC Board does not have any visibility into those possible legal implications and is therefore unable to properly implement risk management procedures.
Second, the work of the Ombudsteam function can have significant legal implications for the IETF. For example, if the Ombudsteam excludes an individual from any part of the IETF process then that person, or their employer, may litigate this decision. However, under the current operating practices defined in [RFC 7776](https://www.rfc-editor.org/info/rfc7776), the Ombusdteam is required to keep their decisions confidential and so IETF LLC Board does not have any visibility into those possible legal issues and risks, and is therefore unable to properly implement risk management procedures. This issue remains even though [RFC 8716 / BCP 25](https://www.rfc-editor.org/info/rfc8716) updated RFC 7776, because that update was not substantive (the name of the IAOC function was simply updated to the IETF LLC).

Second, the IETF LLC Board also observes that for the Ombudsteam to credibly perform its function, it requires the confidence of the community. The current confidentiality procedures derived from RFC 7776 prevent the community from having even the most basic insight into whether the Ombudsteam is functioning. The IETF LLC Board believes that the community would benefit from additional transparency, as [other organizations have demonstrated](https://ombuds.jhu.edu/wp-content/uploads/sites/51/2022-23-JHU-Ombuds-Office-Annual-Report.pdf). We believe an annual transparency report should be required of the Ombudsteam function at the IETF.

We recommend and will initiate a community proceeding to update RFCs pertaining to the Ombudsteam function.
To address the second gap, we propose to initiate a community proceeding to update RFCs pertaining to the Ombudsteam function to enable information sharing with the IETF LLC in order to allow the IETF LLC to properly discharge its duty to manage legal risk.

### RFC Production Center (RPC)

The [RFC Production Center](https://www.rfc-editor.org/about/) (RPC) edits documents and creates Requests for Comment (RFC). Publishing RFCs is the output of the IETF standards process (and similar processes), and as such is a critical productivity metric for the IETF LLC in operating the IETF. These are metrics such as the volume of RFCs published over time and how long it takes the RPC to edit and publish RFCs once they have entered their work queue.

For quite some time, the RPC has not met the Service Level Agreement (SLA) targets established by the IETF. One reason can be attributed to the age and complexity of the publishing tools used by the RPC, most of which are several decades old. The IETF LLC is investing in a complete rewrite of these tools but supporting that project is further stretching RPC resources. Another can be attributable to the changes introduced by [RFCXML v3](https://datatracker.ietf.org/doc/html/rfc7991), which has significantly increased the work the RPC is required to carry out pre-publication. The third can be attributed to the ongoing requests for the RPC to support GitHub and Markdown editing as now used by many Working Groups.
For quite some time, the RPC [has not met the Service Level Agreement (SLA) targets](https://www.rfc-editor.org/report-summary/#sla) established by the IETF. One reason can be attributed to the age and complexity of the publishing tools used by the RPC, most of which are several decades old. The IETF LLC is investing in a complete rewrite of these tools, but supporting that project is stretching limited RPC resources. A second reason is attributable to the changes introduced by [RFCXML v3](https://datatracker.ietf.org/doc/html/rfc7991), which has significantly increased the work the RPC is required to carry out pre-publication. The third reason can be attributed to the ongoing requests for the RPC to support GitHub and Markdown editing, now used extensively by many Working Groups.

In addition, the whole RFC Editor function has been going through a major changes with the new RFC Editor model in RFC 9280 that introduced the RSWG/RSAB and removed the RSE role. This change has brought the RPC closer to the IETF community by giving it more responsibility for editing decisions, more direct contact with community members who want different services, and more direct community reporting requirements. Ultimately, these developments acknowledge the integral and vital role of the RPC, but they have put the RPC leadership in a difficult position as arms-length contractors.
In addition, the whole RFC Editor function has been going through a major change, with the new RFC Editor model in [RFC 9280](https://www.rfc-editor.org/info/rfc9280) that introduced the RFC Series Working Group (RSWG) and RFC Advisory Board (RSAB), and removing the RFC Series Editor (RSE) role. This change has brought the RPC closer to the IETF community by giving it more responsibility for editing decisions, more direct contact with community members who want different services, and more direct community reporting requirements. Ultimately, these developments acknowledge the integral and vital role of the RPC, but they have put the RPC leadership in a difficult position as arms-length contractors.

As a result, the IETF LLC needs to provide additional operational direction to the RPC, establish internal workflow metrics, and make significant improvements to the technical tools used by the RPC to perform their work. This will likely have upstream effects over document publishing tools, which should become easier to use and ensure that the RPC is provided with consistently high quality document input.
As a result, the IETF LLC needs to provide additional operational direction and support to the RPC, including establishing internal workflow metrics, and investing in significant improvements to the technical tools used by the RPC to perform their work. This should have positive upstream effects over document publishing tools, which should become easier to use and ensure that the RPC is provided with consistently high quality document input.

The IETF LLC expects to announce steps being taken in this area soon. For the next retrospective in 2027, the community should expect significant improvements to have been made in the RPC.

### IETF Trust

Prior to the IASA2 changes, the IAOC members and the trustees of the [IETF Trust](https://trustee.ietf.org/) were the same people, with executive support provided by the same person, the then IAD (IETF Administrative Director). Under IASA2, the people managing the IETF Trust became different people from those managing the IETF (the IETF LLC). This has had knock-on effects that the IETF community may not fully recognize.

As a result of IASA2 there is now a separation at the governance level as the trustees of the IETF Trust and IETF LLC board members. There is no cross-over or personnel or formally designated liaison. In addition, at the executive support level there is also separation, as the IETF Executive Director works solely for the IETF LLC and does not operate the IETF Trust or act as an executive for the IETF Trust. Over time, the two organizations' operational approaches have diverged but it is not clear if this was an expected outcome of the IASA2 process.
Prior to the IASA2 changes, the IAOC members and the trustees of the [IETF Trust](https://trustee.ietf.org/) were the same people, with executive support provided by the same person, the then IAD (IETF Administrative Director). Under IASA2, there is now a separation at the governance level between the trustees of the IETF Trust and IETF LLC board members with no cross-over or personnel or formally designated liaison. This has had knock-on effects that the IETF community may not fully recognize.

Despite this divergence, it seems clear that the IETF Trust solely exists due to and in the service of the IETF. Not only is IETF in the name of the IETF Trust, but the IETF Trust's website is within the IETF's ietf.org domain, the IETF Nominating Committee selects trustees, and the IETF Trust notes their purpose is "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..." The IETF, and thus by extension the IETF LLC as the legal home of the IETF, is thus the sole beneficiary of the IETF Trust.
In addition, at the executive support level there is also separation, as the IETF Executive Director works solely for the IETF LLC and does not operate the IETF Trust or act as an executive for the IETF Trust. Over time, the two organizations' operational approaches have diverged but it is not clear if this was an expected outcome of the IASA2 process.

The key reason for this divergence is that the IETF LLC, as the more recent of the two organizations to be created by the community, was given a clear and detailed set of community requirements in BCP 101 for how it should operate. These include a set of principles for it to follow, such as significant transparency and strong community responsiveness, and a requirement for an extensive set of governance policies created through community consultation, which it put in place since soon after inception.

More fundamentally, the IETF LLC understands that the IETF Trust solely exists due to and in the service of the IETF. Not only is IETF in the name of the IETF Trust, but the IETF Trust's website is within the IETF's ietf.org domain, the IETF Nominating Committee selects trustees, and the IETF Trust notes their purpose is "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..." The IETF, and thus by extension the IETF LLC as the legal home of the IETF, is thus the sole beneficiary of the IETF Trust.

The community may wish to consider discussing potential structural options for closing the gap between the IETF LLC and IETF Trust, and consider whether a similar set of community requirements would be appropriate for the IETF Trust - particularly as it completes its transformation from a trust to a corporation with similar legal obligations as the IETF LLC.

### IETF Secretariat - Managing Director Role
Expand Down

0 comments on commit ce46231

Please sign in to comment.