Internet-Draft IETF Community Moderation September 2025
Eggert & Lear Expires 6 March 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-ietf-modpod-group-processes-latest
Obsoletes:
3683, 3934 (if approved)
Updates:
2418, 9245 (if approved)
Published:
Intended Status:
Best Current Practice
Expires:
Authors:
L. Eggert, Ed.
Mozilla
E. Lear, Ed.
Cisco Systems

IETF Community Moderation

Abstract

The IETF community will treat people with kindness and grace, but not endless patience.

This memo establishes a policy for the moderation of disruptive participation across the IETF's various public contribution channels and discussion fora. It establishes guardrails for moderation and a moderator team. That team will develop a set of guidelines and facilitate their consistent implementation with chairs and administrators.

About This Document

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

The latest revision of this draft can be found at https://larseggert.github.io/draft-ietf-modpod-group-processes/draft-ietf-modpod-group-processes.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-modpod-group-processes/.

Discussion of this document takes place on the mod-discuss Working Group mailing list (mailto:mod-discuss@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mod-discuss/. Subscribe at https://www.ietf.org/mailman/listinfo/mod-discuss/.

Source for this draft and an issue tracker can be found at https://github.com/larseggert/draft-ietf-modpod-group-processes.

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 https://datatracker.ietf.org/drafts/current/.

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 6 March 2026.

Table of Contents

1. Introduction

This memo establishes a policy for the moderation of disruptive participation across the IETF's various public contribution channels and discussion fora. It creates a moderator team to develop procedures and to facilitate their consistent application.

This memo makes the following changes:

The details of each of these changes and the philosophy behind them are described below.

1.1. Terminology Note

Below we use the term "administrator" to refer to the people who are assigned by the IESG to manage a particular public participation channel or discussion forum. This document uses the term "forum" to refer to any public IETF participation channel, such as a mailing list, chat group, or discussion in a collaborative tool such as GitHub or GitLab. For example, working group chairs are administrators of all the public fora their WG uses, which typically includes mailing lists and chat groups, but might also include collaborative tools such as GitHub or GitLab. Another example of administrators are the "owners" of non-WG IETF mailing lists.

1.2. Background

The IETF community has defined general guidelines for personal interactions 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. [RFC2418] tasks the chairs of each IETF working group with moderating their group's in-person meetings while [RFC3934] provided chairs a procedure to help manage mailing lists. An IESG statement [MODML] described 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 IESG tasks list administrators 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 administrators review attempted participation before it occurs (such as reviewing messages to a mailing list), and reactive moderation, where administrators intervene after disruptive 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 moderators and administrators 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.

Experience and community input suggests that an evolution of the existing processes is necessary (see Appendix B).

1.3. General Philosophy

The cornerstone of our philosophy is that individuals are responsible for furthering the goals of the IETF as an organization [RFC3935] in a manner consistent with the policy laid out in [RFC7154].

The IETF is an open standards organization. Engaged, respectful discussion that is within the scope of a forum should not be considered disruptive, nor should someone be considered disruptive solely because they are outside the rough consensus.

Disagreement and diverse points of view within any standards organization are to be expected, and are even healthy. However, when someone crosses the line into disruptive behavior, some action must be taken in order to maintain decorum of the community.

The moderation policy goals are as follows:

  • Apply consistent, fair, and timely moderation of communication across all public IETF participation channels and participation fora without regard to a participant's role in the IETF or previous technical contributions;

  • Appeals are available to address disagreements about moderation actions;

  • Balance transparency against both privacy of individuals involved and further disruption to the community;

  • Allow moderation decisions to be reconsidered; and

  • Provide the broadest possible latitude to all people doing moderation, so that they have the flexibility to address a broad range of individuals and circumstances.

Questions about processes detailed below should be answered through the lens of these aims.

The goal is explicitly not punishment, but to maintain an open, welcoming, non-hostile environment in which all may participate on an equal footing, regardless of their role in the IETF or past technical contributions.

2. IETF Moderator Team

This memo proposes a consistent approach to moderating the IETF's various public fora. A moderator team for the IETF will develop guidelines for moderation and will facilitate their consistent implementation and application as detailed below. These changes are intended to address the issues identified in the previous model Appendix B and the principles described in the introduction.

2.1. Composition

The moderator team initially consists of at least five individuals. The IESG appoints and replaces moderators. In selecting members, the IESG will take into account geographic coverage, expected and unexpected absences, and team diversity.

The moderator team may expand or contract based on operational experience. Apart from appointing and replacing moderators, the IESG shall refrain from the day-to-day operation and management of the moderator team. The moderators may consult with the IESG when needed.

Because the IESG and IAB are in the appeals chain for moderator team decisions (see Section 4.1), the IESG 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.

2.1.1. 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 moderators should be able to respond to issues within a few hours.

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

2.2. Training

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

3. Scope and Responsibilities

This policy applies to all public IETF fora, both present and future, including, but not limited to, mailing lists, chat groups, and discussions in other systems that the IETF or WGs have chosen to employ, such as GitHub repositories, Wikis, or issue trackers.

Different people have different moderation responsibilities:

3.1. Actions That Are Out of Scope

Moderator actions are only permitted for the purposes of limiting disruptive communications in IETF fora. All other actions are beyond the scope of this memo. Examples of actions that are out of scope include, but are not limited to, datatracker account removal, in-person meeting registration, content removal or redaction, moderation or policing of private or non-IETF communications, and redaction from IETF archives.

3.2. Unsolicted Bulk Messages

Unsolicited bulk messages are considered disruptive and should be handled in a manner consistent with the IESG statement on IETF Spam Control on IETF Mailing Lists[IESG-SPAM], or its successors. Administrators may take similar actions in other fora (e.g., GitHub or Instant Messaging). Such actions require no additional reporting.

4. Moderation Procedures and Transparency

Within the bounds of the policies set herein, and with the approval of the IESG, the moderator team shall develop processes and criteria relating to moderation, including the moderator team's own operating procedures.

Those processes and criteria shall be developed with community input and made public, but need not be documented in the RFC series. This shall be the first task for the moderator team. Until that happens, the previous procedures remain in effect.

The intent of this memo is to provide the widest possible freedom of action to administrators and moderators, with a few constraints. Examples of actions that could be taken include:

We stress that these are only examples, and not in any way prescriptive. Administrators and moderators are free to decide on these or other actions.

The expectation is that the minimal actions necessary will be taken. Those who are directed to stop disrupting a forum must do so immediately. Further disruptions may lead to further corrective actions.

All moderation actions that restrict posting rights shall be periodically reported to the IESG, as well as immediately to those against whom those actions take effect.

To address disruptive behavior in a timely manner, only moderation actions suspending participation rights for longer than fourteen (14) days shall be reported to the forum to which such an action applies. If such an action applies to more than one forum, it should be communicated to the community in a manner decided by the IESG.

4.1. Consistency and Conflict Resolution

Administrators and moderators shall act in a manner consistent this memo and the guidelines approved by the IESG. In cases of disagreement over a moderation decision, anyone may take the matter up with the responsible area director for resolution, or with the IETF chair if a responsible area director cannot be determined or is not assigned. Further appeals may be made to the IESG per Section 6.5.2 of [RFC2026], and then if necessary to the IAB.

4.2. Reinstatement

People and circumstances change. Individuals whose participation rights have been suspended from a forum may request reinstatement. Requests for reinstatement may be made only a year after the initial decision, and then only annually afterwards.

Any such request must be directed to the entity who made the decision (e.g., moderator team, working group chairs, etc.) or their successors. That party may at their discretion reinstate someone, conditionally or unconditionally.

To avoid denial-of-service attacks on our processes, decisions to not reinstate someone's participation rights may not be appealed. Any reinstatement is a grace and not a right.

A ban imposed prior to this process shall be reconsidered only in accordance with the processes in place at the time of the ban, even if the corresponding RFC has been formally obsoleted.

5. Relationship to other IETF functions

5.1. Relation to the Ombudsteam

Administrators and moderators shall complement the efforts of the IETF ombudsteam [OT], whose focus on anti-harassment and operation shall remain unchanged. Administrators and moderators should always report suspected harassment. They should nonetheless take any necessary actions regarding disruptive behavior.

5.2. 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 serious legal risk that may arise from the behavior of IETF participants.

This protection may include the need for the IETF LLC to take emergency moderation actions. These emergency actions are expected to be taken only when the IETF LLC has received legal advice that such action is necessary, and therefore extremely rare in frequency. Some examples of where this might be necessary are:

  • Someone making a credible threat of harm to other IETF participants.

  • Someone using IETF mailing lists and/or websites to share content where publishing that content on IETF lists and/or websites brings serious legal risk.

  • Someone making a credible threat of legal action where any form of interaction with them on IETF mailing lists may have serious legal consequences for the IETF.

If any such action is taken, the IETF LLC should, except where limited by legal advice to the contrary, inform the IESG as soon as possible, providing full details of the subject of the action, nature of the action, reason for the action and expected duration. The IETF LLC should also inform the moderator team and IETF community, except where it receives legal advice to the contrary.

As such an action would be taken by the IETF LLC in order to protect the IETF according to its fiduciary duty, then it cannot allow that to be overridden by a decision of the moderator team or the IESG. The subject of any such action may request a review by the IETF LLC board, as documented in section 4.7 of [RFC8711]

Any such action taken by the IETF LLC under this section of this policy, is not subject to the rest of this policy.

5.3. Relation to the IRTF

The Internet Research Task Force (IRTF) [RFC2014] is a peer organization separate from the IETF that is governed by its own set or rules and processes. Sections 3, 6 and 7 of [RFC9775] discuss rules for participating in the IRTF and moderation of IRTF participation fora.

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

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

7. IANA Considerations

No IANA actions are requested.

8. Acknowledgments

This memo is based on two individual Internet-Drafts, draft-ecahc-moderation authored by Lars Eggert, Alissa Cooper, Jari Arkko, Russ Housley and Brian E. Carpenter, and draft-lear-bcp83-replacement authored by Eliot Lear, Robert Wilton, Bron Gondwana and John R. Levine. Robert Sayre authored draft-sayre-modpod-excellent, which also originated ideas reflected in this work. Pete Resnick provided the basis for how the moderators interact with list/forum leadership.

These individuals contributed additional improvements:

9. References

9.1. Normative References

[IESG-SPAM]
IESG, "IESG Statement on Spam Control on IETF Mailing Lists", , <https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-spam-control-on-ietf-mailing-lists-20080414/>.
[RFC2026]
Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, , <https://www.rfc-editor.org/rfc/rfc2026>.
[RFC2418]
Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, , <https://www.rfc-editor.org/rfc/rfc2418>.
[RFC3683]
Rose, M., "A Practice for Revoking Posting Rights to IETF Mailing Lists", BCP 83, RFC 3683, DOI 10.17487/RFC3683, , <https://www.rfc-editor.org/rfc/rfc3683>.
[RFC3934]
Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 25, RFC 3934, DOI 10.17487/RFC3934, , <https://www.rfc-editor.org/rfc/rfc3934>.
[RFC3935]
Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, DOI 10.17487/RFC3935, , <https://www.rfc-editor.org/rfc/rfc3935>.
[RFC7154]
Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54, RFC 7154, DOI 10.17487/RFC7154, , <https://www.rfc-editor.org/rfc/rfc7154>.
[RFC7776]
Resnick, P. and A. Farrel, "IETF Anti-Harassment Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, , <https://www.rfc-editor.org/rfc/rfc7776>.
[RFC8711]
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, , <https://www.rfc-editor.org/rfc/rfc8711>.
[RFC9245]
Eggert, L. and S. Harris, "IETF Discussion List Charter", BCP 45, RFC 9245, DOI 10.17487/RFC9245, , <https://www.rfc-editor.org/rfc/rfc9245>.

9.2. Informative References

[AHP]
IESG, "IETF Anti-Harassment Policy", , <https://www.ietf.org/about/groups/iesg/statements/anti-harassment-policy/>.
[DP]
IESG, "IESG Statement on Disruptive Posting", , <https://www.ietf.org/about/groups/iesg/statements/disruptive-posting/>.
[MODML]
IESG, "IESG Guidance on the Moderation of IETF Working Group Mailing Lists", , <https://www.ietf.org/about/groups/iesg/statements/mailing-lists-moderation/>.
[OT]
"Ombudsteam", <https://www.ietf.org/contact/ombudsteam/>.
[RFC2014]
Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, , <https://www.rfc-editor.org/rfc/rfc2014>.
[RFC3552]
Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, , <https://www.rfc-editor.org/rfc/rfc3552>.
[RFC9775]
Perkins, C. S., "IRTF Code of Conduct", RFC 9775, DOI 10.17487/RFC9775, , <https://www.rfc-editor.org/rfc/rfc9775>.

Appendix A. Changes

Appendix B. Problems with the Previous Approach

The previous 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:

Appendix C. Non-Normative Examples of Disruptive Behavior

The list below describes some types of disruptive behavior, but it is non-exhaustive.

These items are examples. Moderators and administrators may take moderation actions for many other cases.

The moderator team's task consists of subjective judgement calls. Behaviors not listed here might require moderation, and it is not possible to write a complete list of all such behaviors.

Authors' Addresses

Lars Eggert (editor)
Mozilla
Stenbergintie 12 B
FI-02700 Kauniainen
Finland
Eliot Lear (editor)
Cisco Systems
Richtistrasse 7
CH-8304 Wallisellen
Switzerland