--- title: "IETF Community Moderation"category: bcpabbrev: "IETF Community Moderation" number: 9945 seriesno: 245 docname: draft-ietf-modpod-group-processes-latest category: bcp submissiontype: IETFnumber: date:consensus: truev: 3ipr: trust200902 obsoletes: 3683, 3934 updates: 2418, 9245venue: mail: mod-discuss@ietf.org github: larseggert/draft-ietf-modpod-group-processes latest: https://larseggert.github.io/draft-ietf-modpod-group-processes/draft-ietf-modpod-group-processes.htmlpi: [toc, symrefs, sortrefs] v: 3 lang: en date: 2026-02 area: GEN workgroup: modpod keyword: author: - name: Lars Eggert role: editor org: Mozilla street: Stenbergintie 12 B city: Kauniainen code: "02700" country: FI email: lars@eggert.org uri:<https://eggert.org/>https://eggert.org/ - name: Eliot Lear role: editor org: Cisco Systems street: Richtistrasse 7 code: "8304" city: Wallisellen country: Switzerland phone: "+41 44 878 9200" email: lear@lear.ch normative: informative: IESG-SPAM: title: IESG Statement on Spam Control on IETF Mailing Lists date:2008-04-182008-04-14 author: - org: IESG target: https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-spam-control-on-ietf-mailing-lists-20080414/ AHP: title: IETF Anti-Harassment Policy date: 2013-11-03 author: - org: IESG target: https://www.ietf.org/about/groups/iesg/statements/anti-harassment-policy/ OT: title: Ombudsteam date: false target: https://www.ietf.org/contact/ombudsteam/ MODML: title: IESG Guidance on the Moderation of IETF Working Group Mailing Lists date: 2000-08-29 author: - org: IESG target: https://www.ietf.org/about/groups/iesg/statements/mailing-lists-moderation/ DP: title: IESG Statement on Disruptive Posting date:2006-02-162006-02-17 author: - org: IESG target: https://www.ietf.org/about/groups/iesg/statements/disruptive-posting/ --- abstract The IETF community will treat people with kindness and grace, but not endless patience. This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and 9245 by establishing 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 moderation procedures and facilitate their consistent implementation with chairs and administrators. --- middle # Introduction This memo establishes a policy for the moderation of disruptive participation across the IETF's various public online contribution channels and discussion fora. It creates a moderator team to develop procedures and to facilitate their consistent application. This memo obsoletes and updates some prior IETF processes, summarized here. Background information is described in more detail in {{motivation}}. This memo makes the following changes to existing processes: - Obsoletes {{?RFC3683}} as the "posting rights" (PR) action it definesareis replaced by processes defined herein; - Obsoletes {{?RFC3934}} as it replaces working group moderation procedures; - Obsoletes {{Section 3 of ?RFC9245}} and the second paragraph of {{Section 4 of ?RFC9245}}, as the moderator team replaces the IETF discussion list moderation team. - Updates {{Section 6.1 of !RFC2418}}, because the moderator team will work together with working group chairs to moderate disruptive behavior. The processes described in this memo are solely applicable to IETF activities, and not to other related organizations, such as the Internet Research Task Force (IRTF), the Internet Architecture Board (IAB), the RFC Series Working Group (RSWG), the RFC Series Approval Board (RSAB), or the Independent RFC Submission Stream, without their explicit agreement. These changes take effect when the procedures described in {{prod}} have been approved by the IESG. ## Terminology NoteBelow,In this document, the term "administrator" refers to the people who are assigned by the IESG to manage a particular public participation channel or discussion forum. This memo 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 that their working groups use, which typically includes mailing lists and chat groups, but might also include collaborative tools such as GitHub or GitLab.Another example of administrators are theThe "owners" of non-WG IETF mailinglists.lists are another example of administrators. ## General Philosophy {#genphil} Thispolicy'scornerstone of this policy 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}}. Disagreement and diverse points of view within any standards organization are to beexpected,expected and are even healthy. The IETF is an open standards organization with a discussion-based rough consensus process, a non-normative description of which is in {{?RFC7282}}. Engaged, respectful discussion that is within the scope of an IETF forum should therefore not be considered disruptive, nor should someone be considered disruptive solely because they are outside the rough consensus. However, when someone crosses the line into disruptive behavior,someaction 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 online IETF participation channels and participation fora without regard to a participant's role in the IETF or previous technical contributions; -AppealsEnsure 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 the processes detailed below should be answered through the lens of these aims. Thegoalobjective 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. # IETF Moderator Team This memo defines a consistent approach to moderating the IETF's various public online fora. A moderator team for the IETF will develop and maintain 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{{motive}}(see {{motive}}) and the principles described in the introduction. ## Composition The IESG appoints and recalls moderators. The moderator team initially consists of no fewer than five individuals. The moderator team may expand or contract based on operational experience. In selecting members, the IESG will take into account geographic coverage, expected and unexpected absences, and team diversity. Because the IESG and IAB are in the appeals chain for moderator team decisions (see {{appeals}}), 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 andcontractorscontractors, shall also be excluded from serving on the moderator team. If a moderatoris assumingassumes any such role, they shall step down from the moderator team soon after. ### 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. ## 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}}. # Scope and Responsibilities This policy applies to all public online 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: - **Participants** should always behave inathe manner discussed in {{genphil}}. They are also encouraged to report disruptive behavior directed at them or someone else to an administrator of the respective forum **and** the moderators. - **Administrators** are primarily responsible for managing their fora in accordance with procedures developed by the moderators and approved by the IESG. As such, they shall address reports of disruptive behavior in a timely fashion, apprising moderators of reports or actions taken. Administrators may amend or rescind actions, including those taken by members of the moderation team **after** they have consulted with that team. For a working group, chairs are by default the administrators. They may delegate this responsibility in the same vein as {{Section 6.4 ofRFC2418}}RFC2418}}, but they must always accept, acknowledge, and keep track of complaints of disruptive behavior. Forum administrators should perform moderation in a way that obviates the need for moderator team involvement. - **Moderators** are responsible for establishing procedures to address moderation needs across all IETF fora, both present and future. They are a resource that the community can use to address disruptive behavior. The moderator team is responsible to the IESG. The IESG will create or designate a forum to facilitate discussion aboutmoderation,moderation and refer interested parties to that forum. Moderators may take actions when administrators do not respond to reports in a timely fashion. Their first action should generally be to attempt to contact and advise the relevant administrators. They should only take moderation actions when administrators are notresponsive,responsive or when someone disrupts multiple fora at the same time. Moderators should generally give WG chairs the opportunity to manage what may be difficult and contentious debates within their groups. Within the bounds of this principle, it is left to moderators' judgment to determine when they must act, with the understanding that some situations may require fast responses. Moderators must notify administrators of any actions they take. {{appeals}} discusses the handling of disagreements. Moderators are administrators for IETF plenary fora, currently including the IETF discussion andlast-callLast Call lists and any plenary chat sessions. They are also administrators for any forum that does not otherwise have an administrator. In order to scale the function, except for plenary fora as described above, moderators are not expected to always actively monitor all communications. In general, they will process reports from participants. - **AreaDirectors**directors** are expected to resolve conflicts as described here and in {{appeals}}. The IESG will periodically evaluate the performance and needs of moderators, and may appoint and recall moderators as they deem appropriate. Apart from that, 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. ## Actions That Are Out of Scope Moderator actions are only permitted for the purposes of limiting disruptive communications in online 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; restriction of in-person, virtual, or hybrid meeting participation; content removal or redaction; and moderation or policing of private or non-IETF communications. While the moderator team does not moderate non-public IETF mailing lists, the administrators of such lists can choose to adopt some of the procedures that the moderator team develops. ## Unsolicited Bulk Messages Unsolicited bulk messages are considered disruptive and should be handled in a manner consistent with theIESG statement"IESG Statement onIETFSpam Control on IETF MailingLists{{IESG-SPAM}},Lists" {{IESG-SPAM}} or its successors. Administrators and moderators may take similar actions in other fora (e.g., GitHub orInstant Messaging).instant messaging). Such actions require no additional reporting. # Moderation Procedures and Transparency {#prod} Within the bounds of the policies set herein, the moderator team shall develop and maintain procedures and criteria relating to moderation, including the moderator team's own operating procedures. Those procedures and criteria shall be developed with community input, be approved by the IESG prior to going into effect, and be made public. However, they need not be documented in the RFCseries.Series. This shall be the first task for the moderator team. Until those procedures and criteria are established, all previous processes referenced in {{introduction}} shall remain in effect. The intent of this memo is to provide the widest possible freedom of action to administrators and moderators, with the expectation 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. Examples of actions that could be taken include: - Automatedrate limitingrate-limiting mechanisms; - Review and approval of submissions/messages; - A private or public admonishment; - Temporary or indefinite suspension of participation privileges in one or more fora. These are onlyexamples,examples and are not in any way prescriptive. Administrators and moderators are free to decide on these or other actions. All moderation actions that restrict participation privileges shall be immediately reported to those against whom those actions take effect, to relevant administrators, and to the moderator team for their review. They shall also be periodically reported to the IESG. Only moderation actions suspending participation privileges for longer than fourteen (14) days must be reported to the forum to which such an action applies, or in any event, at the request of the suspended person. If such an action applies to more than one forum, it should be communicated to the community in a manner decided by the IESG. Moderators will periodically provide an aggregate report to the community on actions taken under this policy. ## Consistency and Conflict Resolution {#appeals} Administrators and moderators shall act in a manner consistent with 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 responsibleArea Directorarea director for resolution, or with the IETFchairChair if a responsibleArea Directorarea director cannot be determined or is not assigned. If the disagreement cannot be resolved by theArea Director,area director, that person may then appeal to theIESG,IESG and subsequently to the IAB using the processes stated in {{Sections 6.5.1 and 6.5.4 of !RFC2026}}. ## Reinstatement People and circumstances change. Individuals whose participation privileges have been indefinitely suspended from a forum may request reinstatement. Requests for reinstatement may be made no earlier than a year after the initialdecision,decision and then only annually afterward. 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 IETF processes, decisions to not reinstate someone's participation privileges may not be appealed. Any reinstatement is a grace and not a right. A suspension of participation privileges imposed prior to this process shall be reconsidered only in accordance with the processes in place at the time of the suspension, even if the corresponding RFC has been formally obsoleted. # Relationship tootherOther IETFfunctionsFunctions ## Relation to the Ombudsteam Administrators and moderators shall complement the efforts of the IETFombudsteamOmbudsteam {{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. ## 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 isnecessary,necessary and therefore will be 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 to the IETF. - 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 theactionaction, and the 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 LLCboard,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. # Security Considerations The usual security considerations {{?RFC3552}} do not apply to this memo. There is the potential abuse of the moderation procedures by moderators, working group chairs, and potentially others that could lead to censorship of legitimate participation. This potential risk is mitigated in eight ways: 1. {{prod}} requires the moderator team to first establish procedures that are intended to apply uniformly across the IETF. 2. {{genphil}} explicitly states that viewpoints outside the rough consensus are not in and of themselves disruptive. 3. {{prod}} provides transparency by requiring that moderation actions that restrict participation privileges be immediately reported to the affected person and to the moderation team, and periodically reported to the IESG. 4.That same section{{prod}} also requires that the community be informed in the case of suspensions lasting longer than 14 days. 5. {{appeals}} lays out an appeals process in the case of disagreements. 6. If moderators find that the procedures themselves are leading to inappropriate moderation, {{prod}} allows them to update those procedures in consultation with thecommunity,community and with the approval of the IESG. 7. If IETF participants believe that either the IESG or the IAB are not performing their respective oversight functions as described in this document, they may comment to the NomCom {{!BCP10}} or the community at large. 8. Finally, if it appears that these processes are not functioning properly, the policies stated in this memo may be amended. They are not set in stone. Moderation actions are intended to limit the likelihood of disruptive behavior by a few IETF participantsfrom discouragingthat may discourage participation by other IETF participants. # IANA ConsiderationsNoThis document has no IANAactions are requested.actions. # Acknowledgments This memo is based on two individual Internet-Drafts, [draft-ecahc-moderation](<https://datatracker.ietf.org/doc/draft-ecahc-moderation/>) authored byLars Eggert, Alissa Cooper, Jari Arkko, Russ Housley{{{Lars Eggert}}}, {{{Alissa Cooper}}}, {{{Jari Arkko}}}, {{{Russ Housley}}}, andBrian{{{Brian E.Carpenter,Carpenter}}}, and [draft-lear-bcp83-replacement](<https://datatracker.ietf.org/doc/draft-lear-bcp83-replacement/>) authored byEliot Lear, Robert Wilton, Bron Gondwana{{{Eliot Lear}}}, {{{Robert Wilton}}}, {{{Bron Gondwana}}}, andJohn{{{John R.Levine. Robert SayreLevine}}}. {{{Robert Sayre}}} authored [draft-sayre-modpod-excellent](<https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/>), which also originated ideas reflected in this work.Pete Resnick{{{Pete Resnick}}} provided the basis for how the moderators interact with list/forum leadership. These individuals contributed additional improvements: -Alissa Cooper{{{Alissa Cooper}}} -Brian Carpenter{{{Brian Carpenter}}} -Chris Box{{{Chris Box}}} -Colin Perkins{{{Colin Perkins}}} -David Schinazi{{{David Schinazi}}} -Eric Rescorla{{{Eric Rescorla}}} -Jay Daley{{{Jay Daley}}} -Joel Halpern{{{Joel Halpern}}} -John Klensin{{{John Klensin}}} -John Scudder{{{John Scudder}}} -Martin Thomson{{{Martin Thomson}}} -Melinda Shore{{{Melinda Shore}}} -Michael Richardson{{{Michael Richardson}}} -Nick Hilliard{{{Nick Hilliard}}} -Pete Resnick{{{Pete Resnick}}} -Rich Salz{{{Rich Salz}}} -Robert Sayre{{{Robert Sayre}}} -Russ Housley{{{Russ Housley}}} -Sean Turner{{{Sean Turner}}} -Simon Josefsson{{{Simon Josefsson}}} -Stephen Farrell{{{Stephen Farrell}}} -Ted Lemon{{{Ted Lemon}}} -Tim Bray{{{Tim Bray}}} N.B., acknowledgment should not be taken as endorsement by the individuals named above. --- back #Change History of this I-D {:aside} > RFC Editor: Please remove this appendix before publication. ## Since draft-ietf-modpod-group-processes-11 - [clarify when changes take effect](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/238/) - [Refine security considerations](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/239) - [Multi group and moderator reversal](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/257/files) - [Last(?) bits from 2nd last call](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/258) ## Since draft-ietf-modpod-group-processes-10 - Many editorial suggestions received during WGLC. - [remove attendee mailing lists from moderator primary responsibility](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/181) - [Correct reference to appeals process.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/149) [Also this.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/230) - [Clarify fora that are out of scope.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/197) [Incl. attendees' lists.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/181) [Also this.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/235) - [Clarify WG chairs are default admins but can delegate.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/220) - [Mod team size guidance.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/231) - [Chair immediately notify mods and affected parties.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/229) - [Add all of the available mitigations to risks of censorship.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/232) - [Clarify AD responsibilities.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/234) ## Since draft-ietf-modpod-group-processes-09 - [Try to find another happy medium on power of moderators](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/147) ## Since draft-ietf-modpod-group-processes-08 - [Address timeliness and exisgent circumstances](https://github.com/larseggert/draft-ietf-modpod-group-processes/issues/142) - [Make clear that moderators should use their judgment on timing](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/143) ## Since draft-ietf-modpod-group-processes-07 - [Pete Resnick issues and similar](https://github.com/larseggert/draft-ietf-modpod-group-processes/issues/134) - [Includes changes to abstract, intro, tweaks to make relationship between admins/WG chairs clearer; makes roles clearer, moderation team → moderator team.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/135) ## Since draft-ietf-modmod-group-processes-06 - [Normalize handling of moderation across all fora](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/129) - [Obsolete RFC 3934, explicit admin responsibility](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/132) ## Since draft-ietf-modpod-group-processes-05 - [New attempt to address moderation/WG interactions](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/126) ## Since draft-ietf-modpod-group-processes-04 - [Use plain English instead of BCP 14 language](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/120) ## Since draft-ietf-modpod-group-processes-03 - [Non-normative Examples of Disruptive Behavior](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/121) ## Since draft-ietf-modpod-group-processes-02 - [Say which RFCs this obsoletes and updates.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/105 ) - [Address issue 113](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/116) - [Rewrite philosophy](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/103) - [Reinstatement](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/107) - [Content removal is not moderation.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/109) ## Since draft-ietf-modpod-group-processes-01 - [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) - [Add some text to explain the role of moderators.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/100) ## 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) ## 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) #Motivation {#motivation} {{introduction}}summarizedsummarizes the process changes introduced by this memo. This appendix discusses the background that led to them. ## Background The IETF community has defined general guidelines for personal interactions in the IETF{{!RFC7154}}, and the{{!RFC7154}}. The IESG has defined an anti-harassment policy for the IETF {{AHP}} for which the IETF community has defined anti-harassment procedures {{!RFC7776}}, empowering anombudsteamOmbudsteam {{OT}} to take necessary action. Dealing with *disruptive* behavior, however, is not part of the role of theombudsteam.Ombudsteam. {{!RFC2418}} tasks the chairs of each IETF working group with moderating their group's in-person meetings while {{?RFC3934}}providedprovides chairs a procedure to help manage mailing lists. An IESG statement {{MODML}}describeddescribes 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.TheHistorically, the IETFhistoricallyhas 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 procedures. In addition, {{?RFC3683}} defines a process for revoking an individual's posting rights to IETF mailing lists following a communitylast-callLast 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. ## Problems with the Previous Approach {#motive} 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, arecumbersome andcumbersome, slow, and inconsistent. 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 groups, remote meeting participation systems, virtual meetings, wikis, GitHub repositories, and more. How disruptive behavior is moderated in these fora is currently undefined. # Non-Normative Examples of Disruptive Behavior {#examples} The list below describes some types of disruptive behavior, but it is non-exhaustive. - Discussion of subjects unrelated to a forum's charter or scope; - Uncivil commentary, regardless of the general subject; - Messages announcing conferences, events, or activities that are not sponsored or endorsed by the Internet Society or IETF, unless posted with prior approval of list administrators; - Repeatedly arguing counter to a WG charter that has been approved by the IESG; and - "Sealioning", where a participant makes incessant requests for evidence or data, even while remaining superficially polite. These items are examples. Moderators and administrators may take moderation actions for many other cases. The moderator team's task consists of subjective judgment calls. Behaviors not listed here might require moderation, and it is not possible to write a complete list of all such behaviors.