Network Working Group L. Eggert, Ed. Internet-Draft Mozilla Intended status: Best Current Practice E. Lear, Ed. Expires: 7 August 2025 Cisco Systems 3 February 2025 IETF Community Moderation draft-ietf-modpod-group-processes-02 Abstract The IETF will treat people with kindness and grace, but not endless patience. This document describes the creation of a moderator team for all 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 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/. Eggert & Lear Expires 7 August 2025 [Page 1] Internet-Draft IETF Community Moderation February 2025 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 7 August 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. General Philosophy . . . . . . . . . . . . . . . . . . . 4 1.3. Conventions and Definitions . . . . . . . . . . . . . . . 4 2. IETF Moderator Team . . . . . . . . . . . . . . . . . . . . . 4 2.1. Composition . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Team Diversity . . . . . . . . . . . . . . . . . . . 5 2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Non-IETF Communication Channels And Private Communications Excluded . . . . . . . . . . . . . . . 6 2.2.2. IETF Working Groups . . . . . . . . . . . . . . . . . 6 2.3. Operations of the Moderator Team and Transparency . . . . 7 2.4. Training . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.6. Relation to the Ombudsteam . . . . . . . . . . . . . . . 8 2.7. Relation to the IETF LLC . . . . . . . . . . . . . . . . 8 2.8. Relation to the IRTF . . . . . . . . . . . . . . . . . . 9 3. Changes to Existing RFCs . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 12 Eggert & Lear Expires 7 August 2025 [Page 2] Internet-Draft IETF Community Moderation February 2025 A.1. Since draft-ietf-modpod-group-processes-00 . . . . . . . 12 A.2. Since draft-ecahc-moderation-01 . . . . . . . . . . . . . 12 Appendix B. Problems with the Previous Approach . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction This document proposes the creation of a moderator team for all the IETF's various contribution channels. This moderator team is modeled after, and subsumes, the moderator team for the IETF discussion list [RFC9245]. This memo is applicable to *all* IETF participation channels. 1.1. Background 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 moderators to decide which mix of preemptive and reactive moderation to employ as part of their processes. Eggert & Lear Expires 7 August 2025 [Page 3] Internet-Draft IETF Community Moderation February 2025 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.2. General Philosophy This memo specifies a flexible moderation framework with an eye toward consistency across all IETF communication fora, timeliness, fairness, while also addressing transparency, appeals, and periodic review of moderation actions. In particular, moderators are given the broadest possible freedom of action to address disruptive behavior. The IETF is an open standards organization. Engaged, respectful discussion that is within the scope of a forum should not be considered abuse, nor should someone be considered abusive 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. With that in mind, moderators are expected to identify when someone has crossed a line, and what action is appropriate. 1.3. 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. | TODO: Get feedback from the community whether this redefinition | of BCP14 terms in process documents is something they support. 2. 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 the previous model Appendix B and the principles described in the introduction. Eggert & Lear Expires 7 August 2025 [Page 4] Internet-Draft IETF Community Moderation February 2025 2.1. Composition The moderator team consists of no less than five individuals. The IESG appoints and replaces moderators. In selecting members, the IESG will take into account geographic coverage, expected and unexpected absenses, 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 decide to consult with the IESG when needed. Because the IESG and IAB are in the appeals chain for moderator team decisions (see Section 2.5), 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 problematic behavior can identify a moderator they feel comfortable contacting. 2.2. Scope The IETF moderator team is responsible for establishing processes to address moderation needs across all IETF fora, both present and future, including, but not limited to, 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 moderators are authorized to moderate all non-working group fora, including the IETF discussion and last-call mailing lists and all non-WG mailing lists, as well as area mailing lists. This also includes non-WG IETF-sponsored chat mechanisms. Interactions with WGs are discussed below. Eggert & Lear Expires 7 August 2025 [Page 5] Internet-Draft IETF Community Moderation February 2025 It is not expected that the moderators will be monitoring every IETF channel, but rather that participants MAY and chairs SHOULD flag concerns about disruptive behavior to the moderators. However, the moderators 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 moderators 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 moderators MUST handle those.) 2.2.1. Non-IETF Communication Channels And Private Communications Excluded It is important to note that the moderator 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. 2.2.2. IETF Working Groups The management and moderation of participation channels associated with various IETF groups, including 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 MUST alert the moderators to problematic behavior that rises to the level that some action is needed. Similarly, when moderators observe or are alerted to problematic behavior on such channels, they MUST consult with the group's management to jointly determine an appropriate response. Only when necessary MAY the moderators take actions against someone in a working group setting, but they MUST inform management of relevant groups, including WG chairs and area directors, when they do so. If working group management and moderators have a disagreement about how to proceed in any given circumstance, before any further action is taken, the matter should be taken up with the responsible area director(s) for resolution, and, when more than one area is involved, with the IESG. Eggert & Lear Expires 7 August 2025 [Page 6] Internet-Draft IETF Community Moderation February 2025 It is anticipated that such disagreements will be exceedingly rare. The moderators should respect the views of the group management in such cases, and the group management should respect the moderators' task of upholding an overall IETF-wide uniformity for moderation. 2.3. Operations of the Moderator Team and Transparency Within the bounds of the policies set within this memo and with the approval of the IESG, the moderator team SHALL define any additional processes and moderation criteria necessary to execute their role. Those processes and criteria SHALL be developed with community input and made public, but need not be documented in the RFC series. The intent of this memo is to provide the widest possible freedom of action to the moderators, with a few constraints. Examples of actions that could be taken include: * Automated rate limiting mechanisms; * Review and approval of submissions/messages; * A private or public admonishment; * Temporary or permanent bans in one or more fora. We stress that these are only examples, and not in any way prescriptive. The moderator team is free to decide on these actions. The expectation is that the minimal action necessary to maintain the comity of a forum will be attempted. The moderator team is responsible to the IESG. The IESG MAY create or designate a forum to facilitate discussion about moderation, and refer interested parties to that forum. All actions taken by the moderator team SHALL be reported to the IESG, as well as to those against whom those actions are directed. All bans longer than fourteen (14) days SHALL be reported to the forum in which the person was banned, and in the case of a broad ban, to the community in a manner decided by the IESG. 2.4. Training The IETF is committed to providing and/or funding training for appointed moderators as necessary. The IESG will negotiate any required funding or resources with IETF Administration LLC [RFC8711]. Eggert & Lear Expires 7 August 2025 [Page 7] Internet-Draft IETF Community Moderation February 2025 2.5. Appeals Because the moderator team serves at the discretion of the IESG, any moderation decision can be appealed to the IESG by anyone, per [RFC2026]. Disagreements with a decision by the moderator team can be brought to their attention. If this does not lead to a resolution, a decision by the IESG can be appealed to the IAB as described in [RFC2026]. 2.6. 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. 2.7. 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 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 credible threats of legal action where any form of interaction with them on IETF mailing lists may have serious legal consequences for the IETF. Eggert & Lear Expires 7 August 2025 [Page 8] Internet-Draft IETF Community Moderation February 2025 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 moderation 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 the policy in this document. 2.8. 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 [I-D.perkins-irtf-code-of-conduct] discuss rules for participating in the IRTF and moderation of IRTF participation channels. 3. 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. | TODO: Add once we know this I-D will go forward in some form. 4. 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 2.5. The actions of the moderator team are intended to limit the likelihood of disruptive behavior by a few IETF participants from discouraging participation by other IETF participants. Eggert & Lear Expires 7 August 2025 [Page 9] Internet-Draft IETF Community Moderation February 2025 5. IANA Considerations This document has no IANA actions. 6. Acknowledgments This document is based on two individual Internet-Drafts, draft- ecahc-moderation (https://datatracker.ietf.org/doc/draft-ecahc- moderation/) authored by Lars Eggert, Alissa Cooper, Jari Arkko, Russ Housley and Brian E. Carpenter, and draft-lear-bcp83-replacement (https://datatracker.ietf.org/doc/draft-lear-bcp83-replacement/) authored by Eliot Lear, Robert Wilton, Bron Gondwana and John R. Levine. Many of the ideas in this document originated in those I-Ds. Robert Sayre authored draft-sayre-modpod-excellent (https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/), which also originated ideas reflected in this WG document. These individuals suggested additional improvements to this document: * Alissa Cooper * Chris Box * Eric Rescorla * Jay Daley * Joel Halpern * Melinda Shore * Michael Richardson * Rich Salz * Robert Sayre 7. References 7.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, . [RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March 2016, . Eggert & Lear Expires 7 August 2025 [Page 10] Internet-Draft IETF Community Moderation February 2025 [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, February 2020, . 7.2. Informative References [AHP] IESG, "IETF Anti-Harassment Policy", 3 November 2013, <>. [DP] IESG, "IESG Statement on Disruptive Posting", 16 February 2006, <>. [I-D.perkins-irtf-code-of-conduct] Perkins, C., "IRTF Code of Conduct", Work in Progress, Internet-Draft, draft-perkins-irtf-code-of-conduct-08, 2 February 2025, . [MODML] IESG, "IESG Guidance on the Moderation of IETF Working Group Mailing Lists", 29 August 2000, <>. [OT] "Ombudsteam", <>. [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, October 1996, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF Mailing Lists", BCP 83, RFC 3683, DOI 10.17487/RFC3683, March 2004, . [RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 25, RFC 3934, DOI 10.17487/RFC3934, October 2004, . Eggert & Lear Expires 7 August 2025 [Page 11] Internet-Draft IETF Community Moderation February 2025 [RFC7154] Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54, RFC 7154, DOI 10.17487/RFC7154, March 2014, . [RFC9245] Eggert, L. and S. Harris, "IETF Discussion List Charter", BCP 45, RFC 9245, DOI 10.17487/RFC9245, June 2022, . Appendix A. Changes | RFC Editor: Please remove this appendix before publication. A.1. Since draft-ietf-modpod-group-processes-00 * Spelling fix (https://github.com/larseggert/draft-ietf-modpod- group-processes/pull/80) * Initial attempt to balance what the moderator defines and what (https://github.com/larseggert/draft-ietf-modpod-group-processes/ pull/75) * Scope and relationship between WG chairs and moderators (https://github.com/larseggert/draft-ietf-modpod-group-processes/ pull/76) * Fix wording, spelling and capitalization. (https://github.com/larseggert/draft-ietf-modpod-group-processes/ pull/88) * Editorial changes to acknowledgments. (https://github.com/larseggert/draft-ietf-modpod-group-processes/ pull/87) * Update "Relation to the IETF LLC". (https://github.com/larseggert/ draft-ietf-modpod-group-processes/pull/92) * Point to relevant IRTF material. (https://github.com/larseggert/ draft-ietf-modpod-group-processes/pull/97) A.2. Since draft-ecahc-moderation-01 * Content taken from draft-ecahc-moderation-01 (https://datatracker.ietf.org/doc/draft-ecahc-moderation/01/). Updated editors. Acknowledge authors of original pre-WG I-Ds. (https://github.com/larseggert/draft-ietf-modpod-group-processes/ pull/65) Eggert & Lear Expires 7 August 2025 [Page 12] Internet-Draft IETF Community Moderation February 2025 * Add some text to explain the role of moderators. (https://github.com/larseggert/draft-ietf-modpod-group-processes/ pull/100) 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: * The IETF community has not been able to agree on a common definition of disruptive behavior. Therefore, chairs and list administrators apply individually different criteria when making decisions, and participants have different expectations for when PR-actions are warranted. * The moderation process that chairs and list administrators need to follow [RFC3934] is slow and cumbersome, which makes it ill-suited to situations that escalate quickly. It also assumes that the originator of disruptive behavior is a misguided participant who can be reasoned with and who will change their ways. * Chairs and list administrators may only enact moderation actions for their single list, which is ill-suited when a pattern of disruptive behavior spans multiple lists. Also, chairs and list administrators may not be fully aware of disruptive behavior that spans multiple lists, due to not being subscribed to some of them. * PR-actions, which can address disruptive behavior across several lists, are cumbersome and slow, and the community has not been able to agree on a common definition of disruptive behavior. This has led to a situation where PR-actions are rarely used, and when they are used, they are perceived as very heavy-handed. * For a given mailing list, participants may not feel comfortable reporting disruptive behavior to a chair or list administrator, for various reasons. For mailing lists not associated with working groups, list administrators are not even publicly identified - they can only be contacted through an anonymous alias address. This exacerbates the problem, because participants may not be comfortable reporting disruptive behavior to an anonymous party. * The IETF offers participation not only through in-person meetings and mailing lists, which are the two channels of participation for which moderation processes are currently defined. IETF business also happens in chat channels, remote meeting participation Eggert & Lear Expires 7 August 2025 [Page 13] Internet-Draft IETF Community Moderation February 2025 systems, virtual meetings, wikis, GitHub repositories, and more. How disruptive behavior is moderated in these channels is currently undefined. Authors' Addresses Lars Eggert (editor) Mozilla Stenbergintie 12 B FI-02700 Kauniainen Finland Email: lars@eggert.org URI: Eliot Lear (editor) Cisco Systems Richtistrasse 7 CH-8304 Wallisellen Switzerland Phone: +41 44 878 9200 Email: lear@lear.ch Eggert & Lear Expires 7 August 2025 [Page 14]