Internet-Draft IETF Community Moderation July 2024
Eggert, et al. Expires 4 January 2025 [Page]
Network Working Group
Intended Status:
Best Current Practice
L. Eggert
A. Cooper
J. Arkko
R. Housley
Vigil Security
B. Carpenter
Univ. of Auckland

IETF Community Moderation


This document describes the creation of a moderator team for all of the IETF's various contribution channels. Without removing existing responsibilities for working group management, this team enables a uniform approach to moderation of disruptive participation across all mailing lists and other methods of IETF collaboration.

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 4 January 2025.

Table of Contents

1. Introduction

This document proposes the creation of a moderator team for all of the IETF's various contribution channels. This moderator team is modeled after, and subsumes, the moderator team for the IETF discussion list [RFC9245].

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted in their normal English sense; they are shown in uppercase for emphasis and clarity.

3. Motivation

The IETF community has defined general guidelines of conduct for personal interaction in the IETF [RFC7154], and the IESG has defined an anti-harassment policy for the IETF [AHP] for which the IETF community has defined anti-harassment procedures [RFC7776], empowering an ombudsteam [OT] to take necessary action.

Dealing with disruptive behavior, however, is not part of the role of the ombudsteam. [RFC3934] tasks the chairs of each IETF working group with moderating their group's in-person meetings and mailing lists, and an IESG statement [MODML] describes additional guidance to working group chairs about how - but not when - to moderate their lists.

For IETF mailing lists not associated with a working group, another IESG statement [DP] clarifies that the list administrators are tasked with moderation. And the IETF list for general discussions has, mostly for historic reasons, a team of moderators that are not list administrators and operate by a different set of processes [RFC9245].

Note that the term "moderation" can refer both to preemptive moderation, where moderators review attempted participation before it occurs (such as reviewing messages to a mailing list), and reactive moderation, where moderators intervene after problematic participation has occurred. The IETF historically mainly practiced reactive moderation, with a spectrum from gentle reminders on- and off-list, all the way to suspension of posting rights and other ways of participating or communicating. It is up to the moderator team to decide which mix of preemptive and reactive moderation to employ as part of their processes.

In addition, [RFC3683] defines a process for revoking an individual's posting rights to IETF mailing lists following a community last-call of a "posting rights" action (PR-action) proposed by the IESG, often in response to complaints from the community.

This fractured approach to moderation of disruptive participation through chairs, list administrators, and moderator teams, combined with the IESG-led process of PR-actions, has proven to be less than ideal:

4. IETF Moderator Team

This document proposes a different, uniform approach to moderating the IETF's various participation channels: a moderator team for the IETF. The creation of this team intends to address the issues identified in Section 3.

4.1. Scope

The IETF moderator team consists of a number of individuals that SHALL moderate all the IETF's various current and future participation channels. At present, these include mailing lists, chat channels, and discussions in other systems that the IETF or WGs have chosen to employ, such as GitHub repositories, Wikis, or issue trackers.

The moderator team consists of no less than five individuals, to establish some minimum basis for consensus-based team decisions and geographic spread, but realistically needs to have several more members to spread the moderation load and provide redundancy in the cases of absences, etc. It is up to the moderator team to determine a useful team size.

It is not expected that the moderator team will be monitoring every IETF channel, but rather that participants MAY and chairs SHOULD flag concerns about disruptive behavior to the moderator team. However, the moderator team SHOULD actively monitor a small set of key participation channels, including, for example, the IETF discussion and last-call mailing lists or the IETF plenary chat channel. The moderator team should decide which channels are in this set based on their own judgment and community suggestions. (Note that some participation channels, such as the examples given in the previous sentence, have no chairs or other community leadership, so the moderation team MUST handle those.)

It is important to note that the moderation team only moderates public IETF participation channels. Their mandate does not extend to problematic behavior in private channels, such as private chat channels, direct messages, or conversations or other interactions outside of meetings. In such cases, the Ombudsteam should be approached.

The management and moderation of participation channels associated with various IETF groups, inculding their mailing lists, chat channels and in-person, remote, or interim meetings remains primarily a task of the relevant group's management, such as WG chairs. However, moderators are available for consultation and assistance should issues arise, and they MAY proactively confer with the group management over potential patterns of behavior. Group participants MAY and chairs SHOULD alert the moderators to problematic behavior. When moderators observe or are alerted to problematic behavior on such channels, they SHOULD consult with the group's management to jointly determine an appropriate moderation response. The moderation team should respect the views of the group management in such cases, and the group management should respect the moderation team's task of upholding an overall IETF-wide uniformity for moderation.

The moderator team MAY initiate moderation actions by itself; individual participants SHOULD also alert the team to disruptive behavior they observe. Participants should be able to contact the moderator team in ways that are, ideally, integrated into the various participation channels the IETF offers. The moderator team SHALL keep the identities of participants requesting moderation confidential.

4.2. Transparency

The moderator team SHALL operate according to a consistent set of criteria, processes, and actions. The moderator team SHALL independently define and execute their role. They SHALL maintain a public set of moderation criteria, processes, actions, and other material that allows the community to understand and comment on the role of the team. The moderator team SHOULD consider adopting moderation criteria, processes, and actions that other technical communities have found suitable. The moderator team's criteria and processes SHALL be developed with community input, but they are not expected to be documented in the RFC series.

Some of these processes may rely on automated mechanisms, such as rate-limiting emails to lists or messages to chat channels. (The IETF's deliberately low bar to participation makes it easy to create throw-away personas for such denial-of-service behavior.)

The moderator team SHOULD create and maintain a public mailing list for the community to discuss both the general moderation criteria and individual moderation decisions. To not distract from the topic-oriented discussion on other IETF lists, such meta-discussions SHOULD be actively redirected to the moderation discussion list.

4.3. Membership

The IETF Chair appoints and replaces members of the moderator team. Apart from appointing and replacing moderators, the IETF Chair SHALL refrain from the day-to-day operation and management of the moderator team. The moderator team MAY decide to consult with the IETF Chair when needed.

Because the IESG and IAB are in the appeals chain for moderator team decisions (see Section 4.5), the IETF Chair MUST NOT appoint a moderator who is serving on the IESG or IAB. Individuals serving on other bodies to which the NomCom appoints members, such as the IETF Trust or the LLC Board, as well as LLC staff and contractors SHALL also be excluded from serving on the moderator team. If a moderator is assuming any such role, they SHALL step down from the moderator team soon after.

4.4. Training

The IETF is committed to providing and/or funding training for appointed moderators as necessary. The IETF Chair will negotiate any required funding or resources with IETF Administration LLC [RFC8711].

4.5. Appeals

Because the moderator team serves at the discretion of the IETF Chair, any moderation decision can be appealed to the IETF Chair by anyone, per [RFC2026]. Disagreements with a decision by the IETF Chair can brought to their attention. If this does not lead to a resolution, a decision by the IETF Chair can be appealed as described in [RFC2026], as with any other Area Director decision. In this case, the appeals chain starts with an appeal to the entire IESG.

4.6. Team Diversity

Due to the global nature of the IETF, the membership of this team SHOULD reflect a diversity of time zones and other participant characteristics that lets it operate effectively around the clock and throughout the year. Ideally, the moderator team should be able to respond to issues within a few hours.

Team diversity is also important to ensure any participant observing problematic behavior can identify a moderator they feel comfortable contacting.

4.7. Relation to the Ombudsteam

The moderator team SHALL complement the efforts of the IETF ombudsteam [OT], whose focus on anti-harassment and operation SHALL remain unchanged. The moderator team and ombudsteam are expected to work together in cases that may involve both disruptive behavior and harassment; they may determine the most effective way to do so in each case. For example, the ombudsteam MAY decide to have one of their members serve as a liaison to the moderator team.

The ombudsteam has strict rules of confidentiality. If a moderation case overlaps with an ombudsteam case, confidential information MUST NOT be shared between the teams.

4.8. Relation to the IETF LLC

The Board of Directors of the IETF Administration LLC (IETF LLC) has fiduciary duty for the overall organization, which includes the duty to protect the organization from legal risk that may arise from illegal, vulgar, or manifestly harassing behavior of IETF participants.

This protection MAY include the need for the LLC to take emergency moderation actions. These emergency actions are expected to be extremely rare, of temporary nature, and the indicdents that required them SHOULD be immediately raised with the moderator team to let them determine any follow-up or more permanent moderation action. These incidents and the taken emergency action SHOULD also be communitated to the IETF community.

5. Changes to Existing RFCs

Creation of the IETF moderator team requires some changes to existing RFCs and also requires the IESG to update a number of their statements. This section describes these changes.

6. Security Considerations

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

Potential abuse of the moderation process for the suppression of undesired opinions is counteracted by the availability of an appeals process, per Section 4.5.

The actions of the moderation team are intended to limit the likelihood of disruptive behavior by a few IETF participants from discouraging participation by other IETF participants.

7. IANA Considerations

This document has no IANA actions.

8. Acknowledgments

These individuals suggested improvements to this document:

9. References

9.1. Normative References

Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, , <>.
Resnick, P. and A. Farrel, "IETF Anti-Harassment Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, , <>.

9.2. Informative References

IESG, "IETF Anti-Harassment Policy", , <>.
IESG, "IESG Statement on Disruptive Posting", , <>.
IESG, "IESG Guidance on the Moderation of IETF Working Group Mailing Lists", , <>.
"Ombudsteam", <>.
Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, , <>.
Rose, M., "A Practice for Revoking Posting Rights to IETF Mailing Lists", BCP 83, RFC 3683, DOI 10.17487/RFC3683, , <>.
Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 25, RFC 3934, DOI 10.17487/RFC3934, , <>.
Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54, RFC 7154, DOI 10.17487/RFC7154, , <>.
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, , <>.
Eggert, L. and S. Harris, "IETF Discussion List Charter", BCP 45, RFC 9245, DOI 10.17487/RFC9245, , <>.

Authors' Addresses

Lars Eggert
Stenbergintie 12 B
FI-02700 Kauniainen
Alissa Cooper
Knight-Georgetown Institute (KGI)
Jari Arkko
FI-02700 Kauniainen
Russ Housley
Vigil Security
Brian E. Carpenter
The University of Auckland
School of Computer Science
PB 92019
Auckland 1142
New Zealand