rfc9945.original   rfc9945.txt 
Network Working Group L. Eggert, Ed. Internet Engineering Task Force (IETF) L. Eggert, Ed.
Internet-Draft Mozilla Request for Comments: 9945 Mozilla
Obsoletes: 3683, 3934 (if approved) E. Lear, Ed. bcp: 245 E. Lear, Ed.
Updates: 2418, 9245 (if approved) Cisco Systems Obsoletes: 3683, 3934 Cisco Systems
Intended status: Best Current Practice 9 February 2026 Updates: 2418, 9245 February 2026
Expires: 13 August 2026 Category: Best Current Practice
ISSN: 2070-1721
IETF Community Moderation IETF Community Moderation
draft-ietf-modpod-group-processes-16
Abstract Abstract
The IETF community will treat people with kindness and grace, but not The IETF community will treat people with kindness and grace, but not
endless patience. endless patience.
This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and
9245 establishing a policy for the moderation of disruptive 9245 by establishing a policy for the moderation of disruptive
participation across the IETF's various public contribution channels participation across the IETF's various public contribution channels
and discussion fora. It establishes guardrails for moderation and a and discussion fora. It establishes guardrails for moderation and a
moderator team. That team will develop a set of moderation moderator team. That team will develop a set of moderation
procedures and facilitate their consistent implementation with chairs procedures and facilitate their consistent implementation with chairs
and administrators. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 13 August 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9945.
Copyright Notice Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology Note . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology Note
1.2. General Philosophy . . . . . . . . . . . . . . . . . . . 4 1.2. General Philosophy
2. IETF Moderator Team . . . . . . . . . . . . . . . . . . . . . 5 2. IETF Moderator Team
2.1. Composition . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Composition
2.1.1. Team Diversity . . . . . . . . . . . . . . . . . . . 6 2.1.1. Team Diversity
2.2. Training . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Training
3. Scope and Responsibilities . . . . . . . . . . . . . . . . . 6 3. Scope and Responsibilities
3.1. Actions That Are Out of Scope . . . . . . . . . . . . . . 7 3.1. Actions That Are Out of Scope
3.2. Unsolicited Bulk Messages . . . . . . . . . . . . . . . . 8 3.2. Unsolicited Bulk Messages
4. Moderation Procedures and Transparency . . . . . . . . . . . 8 4. Moderation Procedures and Transparency
4.1. Consistency and Conflict Resolution . . . . . . . . . . . 9 4.1. Consistency and Conflict Resolution
4.2. Reinstatement . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Reinstatement
5. Relationship to other IETF functions . . . . . . . . . . . . 10 5. Relationship to Other IETF Functions
5.1. Relation to the Ombudsteam . . . . . . . . . . . . . . . 10 5.1. Relation to the Ombudsteam
5.2. Relation to the IETF LLC . . . . . . . . . . . . . . . . 10 5.2. Relation to the IETF LLC
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References
Appendix A. Change History of this I-D . . . . . . . . . . . . . 15 Appendix A. Motivation
A.1. Since draft-ietf-modpod-group-processes-11 . . . . . . . 15 A.1. Background
A.2. Since draft-ietf-modpod-group-processes-10 . . . . . . . 15 A.2. Problems with the Previous Approach
A.3. Since draft-ietf-modpod-group-processes-09 . . . . . . . 16 Appendix B. Non-Normative Examples of Disruptive Behavior
A.4. Since draft-ietf-modpod-group-processes-08 . . . . . . . 16 Authors' Addresses
A.5. Since draft-ietf-modpod-group-processes-07 . . . . . . . 16
A.6. Since draft-ietf-modmod-group-processes-06 . . . . . . . 17
A.7. Since draft-ietf-modpod-group-processes-05 . . . . . . . 17
A.8. Since draft-ietf-modpod-group-processes-04 . . . . . . . 17
A.9. Since draft-ietf-modpod-group-processes-03 . . . . . . . 17
A.10. Since draft-ietf-modpod-group-processes-02 . . . . . . . 17
A.11. Since draft-ietf-modpod-group-processes-01 . . . . . . . 18
A.12. Since draft-ietf-modpod-group-processes-00 . . . . . . . 18
A.13. Since draft-ecahc-moderation-01 . . . . . . . . . . . . . 18
Appendix B. Motivation . . . . . . . . . . . . . . . . . . . . . 18
B.1. Background . . . . . . . . . . . . . . . . . . . . . . . 19
B.2. Problems with the Previous Approach . . . . . . . . . . . 19
Appendix C. Non-Normative Examples of Disruptive Behavior . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
This memo establishes a policy for the moderation of disruptive This memo establishes a policy for the moderation of disruptive
participation across the IETF's various public online contribution participation across the IETF's various public online contribution
channels and discussion fora. It creates a moderator team to develop channels and discussion fora. It creates a moderator team to develop
procedures and to facilitate their consistent application. procedures and to facilitate their consistent application.
This memo obsoletes and updates some prior IETF processes, summarized This memo obsoletes and updates some prior IETF processes, summarized
here. Background information is described in more detail in here. Background information is described in more detail in
Appendix B. Appendix A.
This memo makes the following changes to existing processes: This memo makes the following changes to existing processes:
* Obsoletes [RFC3683] as the "posting rights" (PR) action it defines * Obsoletes [RFC3683] as the "posting rights" (PR) action it defines
are replaced by processes defined herein; is replaced by processes defined herein;
* Obsoletes [RFC3934] as it replaces working group moderation * Obsoletes [RFC3934] as it replaces working group moderation
procedures; procedures;
* Obsoletes Section 3 of [RFC9245] and the second paragraph of * Obsoletes Section 3 of [RFC9245] and the second paragraph of
Section 4 of [RFC9245], as the moderator team replaces the IETF Section 4 of [RFC9245], as the moderator team replaces the IETF
discussion list moderation team. discussion list moderation team.
* Updates Section 6.1 of [RFC2418], because the moderator team will * Updates Section 6.1 of [RFC2418], because the moderator team will
work together with working group chairs to moderate disruptive work together with working group chairs to moderate disruptive
skipping to change at page 4, line 15 skipping to change at line 121
The processes described in this memo are solely applicable to IETF The processes described in this memo are solely applicable to IETF
activities, and not to other related organizations, such as the activities, and not to other related organizations, such as the
Internet Research Task Force (IRTF), the Internet Architecture Board Internet Research Task Force (IRTF), the Internet Architecture Board
(IAB), the RFC Series Working Group (RSWG), the RFC Series Approval (IAB), the RFC Series Working Group (RSWG), the RFC Series Approval
Board (RSAB), or the Independent RFC Submission Stream, without their Board (RSAB), or the Independent RFC Submission Stream, without their
explicit agreement. These changes take effect when the procedures explicit agreement. These changes take effect when the procedures
described in Section 4 have been approved by the IESG. described in Section 4 have been approved by the IESG.
1.1. Terminology Note 1.1. Terminology Note
Below, the term "administrator" refers to the people who are assigned In this document, the term "administrator" refers to the people who
by the IESG to manage a particular public participation channel or are assigned by the IESG to manage a particular public participation
discussion forum. This memo uses the term "forum" to refer to any channel or discussion forum. This memo uses the term "forum" to
public IETF participation channel, such as a mailing list, chat refer to any public IETF participation channel, such as a mailing
group, or discussion in a collaborative tool such as GitHub or list, chat group, or discussion in a collaborative tool such as
GitLab. For example, working group chairs are administrators of all GitHub or GitLab. For example, working group chairs are
the public fora that their working groups use, which typically administrators of all the public fora that their working groups use,
includes mailing lists and chat groups, but might also include which typically includes mailing lists and chat groups, but might
collaborative tools such as GitHub or GitLab. Another example of also include collaborative tools such as GitHub or GitLab. The
administrators are the "owners" of non-WG IETF mailing lists. "owners" of non-WG IETF mailing lists are another example of
administrators.
1.2. General Philosophy 1.2. General Philosophy
This policy's cornerstone is that individuals are responsible for This cornerstone of this policy is that individuals are responsible
furthering the goals of the IETF as an organization [RFC3935] in a for furthering the goals of the IETF as an organization [RFC3935] in
manner consistent with the policy laid out in [RFC7154]. a manner consistent with the policy laid out in [RFC7154].
Disagreement and diverse points of view within any standards Disagreement and diverse points of view within any standards
organization are to be expected, and are even healthy. The IETF is organization are to be expected and are even healthy. The IETF is an
an open standards organization with a discussion-based rough open standards organization with a discussion-based rough consensus
consensus process, a non-normative description of which is in process, a non-normative description of which is in [RFC7282].
[RFC7282]. Engaged, respectful discussion that is within the scope Engaged, respectful discussion that is within the scope of an IETF
of an IETF forum should therefore not be considered disruptive, nor forum should therefore not be considered disruptive, nor should
should someone be considered disruptive solely because they are someone be considered disruptive solely because they are outside the
outside the rough consensus. However, when someone crosses the line rough consensus. However, when someone crosses the line into
into disruptive behavior, some action must be taken in order to disruptive behavior, action must be taken in order to maintain
maintain decorum of the community. decorum of the community.
The moderation policy goals are as follows: The moderation policy goals are as follows:
* Apply consistent, fair, and timely moderation of communication * Apply consistent, fair, and timely moderation of communication
across all public online IETF participation channels and across all public online IETF participation channels and
participation fora without regard to a participant's role in the participation fora without regard to a participant's role in the
IETF or previous technical contributions; IETF or previous technical contributions;
* Appeals are available to address disagreements about moderation * Ensure appeals are available to address disagreements about
actions; moderation actions;
* Balance transparency against both privacy of individuals involved * Balance transparency against both privacy of individuals involved
and further disruption to the community; and further disruption to the community;
* Allow moderation decisions to be reconsidered; and * Allow moderation decisions to be reconsidered; and
* Provide the broadest possible latitude to all people doing * Provide the broadest possible latitude to all people doing
moderation, so that they have the flexibility to address a broad moderation, so that they have the flexibility to address a broad
range of individuals and circumstances. range of individuals and circumstances.
Questions about processes detailed below should be answered through Questions about the processes detailed below should be answered
the lens of these aims. through the lens of these aims.
The goal is explicitly *not* punishment, but to maintain an open, The objective is explicitly *not* punishment, but to maintain an
welcoming, non-hostile environment in which all may participate on an open, welcoming, non-hostile environment in which all may participate
equal footing, regardless of their role in the IETF or past technical on an equal footing, regardless of their role in the IETF or past
contributions. technical contributions.
2. IETF Moderator Team 2. IETF Moderator Team
This memo defines a consistent approach to moderating the IETF's This memo defines a consistent approach to moderating the IETF's
various public online fora. A moderator team for the IETF will various public online fora. A moderator team for the IETF will
develop and maintain guidelines for moderation and will facilitate develop and maintain guidelines for moderation and will facilitate
their consistent implementation and application as detailed below. their consistent implementation and application as detailed below.
These changes are intended to address the issues identified in the These changes are intended to address the issues identified in the
previous model Appendix B.2 and the principles described in the previous model (see Appendix A.2) and the principles described in the
introduction. introduction.
2.1. Composition 2.1. Composition
The IESG appoints and recalls moderators. The moderator team The IESG appoints and recalls moderators. The moderator team
initially consists of no fewer than five individuals. The moderator initially consists of no fewer than five individuals. The moderator
team may expand or contract based on operational experience. In team may expand or contract based on operational experience. In
selecting members, the IESG will take into account geographic selecting members, the IESG will take into account geographic
coverage, expected and unexpected absences, and team diversity. coverage, expected and unexpected absences, and team diversity.
Because the IESG and IAB are in the appeals chain for moderator team 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 decisions (see Section 4.1), the IESG must not appoint a moderator
who is serving on the IESG or IAB. Individuals serving on other who is serving on the IESG or IAB. Individuals serving on other
bodies to which the NomCom appoints members, such as the IETF Trust 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 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 excluded from serving on the moderator team. If a moderator assumes
assuming any such role, they shall step down from the moderator team any such role, they shall step down from the moderator team soon
soon after. after.
2.1.1. Team Diversity 2.1.1. Team Diversity
Due to the global nature of the IETF, the membership of this team Due to the global nature of the IETF, the membership of this team
should reflect a diversity of time zones and other participant should reflect a diversity of time zones and other participant
characteristics that lets it operate effectively around the clock and characteristics that lets it operate effectively around the clock and
throughout the year. Ideally, the moderators should be able to throughout the year. Ideally, the moderators should be able to
respond to issues within a few hours. respond to issues within a few hours.
Team diversity is also important to ensure any participant observing Team diversity is also important to ensure any participant observing
skipping to change at page 6, line 33 skipping to change at line 232
3. Scope and Responsibilities 3. Scope and Responsibilities
This policy applies to all public online IETF fora, both present and This policy applies to all public online IETF fora, both present and
future, including, but not limited to, mailing lists, chat groups, future, including, but not limited to, mailing lists, chat groups,
and discussions in other systems that the IETF or WGs have chosen to and discussions in other systems that the IETF or WGs have chosen to
employ, such as GitHub repositories, wikis, or issue trackers. employ, such as GitHub repositories, wikis, or issue trackers.
Different people have different moderation responsibilities: Different people have different moderation responsibilities:
* *Participants* should always behave in a manner discussed in * *Participants* should always behave in the manner discussed in
Section 1.2. They are also encouraged to report disruptive Section 1.2. They are also encouraged to report disruptive
behavior directed at them or someone else to an administrator of behavior directed at them or someone else to an administrator of
the respective forum *and* the moderators. the respective forum *and* the moderators.
* *Administrators* are primarily responsible for managing their fora * *Administrators* are primarily responsible for managing their fora
in accordance with procedures developed by the moderators and in accordance with procedures developed by the moderators and
approved by the IESG. As such, they shall address reports of approved by the IESG. As such, they shall address reports of
disruptive behavior in a timely fashion, apprising moderators of disruptive behavior in a timely fashion, apprising moderators of
reports or actions taken. Administrators may amend or rescind reports or actions taken. Administrators may amend or rescind
actions, including those taken by members of the moderation team actions, including those taken by members of the moderation team
*after* they have consulted with that team. *after* they have consulted with that team.
For a working group, chairs are by default the administrators. For a working group, chairs are by default the administrators.
They may delegate this responsibility in the same vein as They may delegate this responsibility in the same vein as
Section 6.4 of [RFC2418] but they must always accept, acknowledge, Section 6.4 of [RFC2418], but they must always accept,
and keep track of complaints of disruptive behavior. Forum acknowledge, and keep track of complaints of disruptive behavior.
administrators should perform moderation in a way that obviates Forum administrators should perform moderation in a way that
the need for moderator team involvement. obviates the need for moderator team involvement.
* *Moderators* are responsible for establishing procedures to * *Moderators* are responsible for establishing procedures to
address moderation needs across all IETF fora, both present and address moderation needs across all IETF fora, both present and
future. They are a resource that the community can use to address future. They are a resource that the community can use to address
disruptive behavior. The moderator team is responsible to the disruptive behavior. The moderator team is responsible to the
IESG. The IESG will create or designate a forum to facilitate IESG. The IESG will create or designate a forum to facilitate
discussion about moderation, and refer interested parties to that discussion about moderation and refer interested parties to that
forum. forum.
Moderators may take actions when administrators do not respond to Moderators may take actions when administrators do not respond to
reports in a timely fashion. Their first action should generally reports in a timely fashion. Their first action should generally
be to attempt to contact and advise the relevant administrators. be to attempt to contact and advise the relevant administrators.
They should only take moderation actions when administrators are They should only take moderation actions when administrators are
not responsive, or when someone disrupts multiple fora at the same not responsive or when someone disrupts multiple fora at the same
time. Moderators should generally give WG chairs the opportunity time. Moderators should generally give WG chairs the opportunity
to manage what may be difficult and contentious debates within to manage what may be difficult and contentious debates within
their groups. Within the bounds of this principle, it is left to their groups. Within the bounds of this principle, it is left to
moderators' judgment to determine when they must act, with the moderators' judgment to determine when they must act, with the
understanding that some situations may require fast responses. understanding that some situations may require fast responses.
Moderators must notify administrators of any actions they take. Moderators must notify administrators of any actions they take.
Section 4.1 discusses the handling of disagreements. Section 4.1 discusses the handling of disagreements.
Moderators are administrators for IETF plenary fora, currently Moderators are administrators for IETF plenary fora, currently
including the IETF discussion and last-call lists and any plenary including the IETF discussion and Last Call lists and any plenary
chat sessions. They are also administrators for any forum that chat sessions. They are also administrators for any forum that
does not otherwise have an administrator. does not otherwise have an administrator.
In order to scale the function, except for plenary fora as In order to scale the function, except for plenary fora as
described above, moderators are not expected to always actively described above, moderators are not expected to always actively
monitor all communications. In general, they will process reports monitor all communications. In general, they will process reports
from participants. from participants.
* *Area Directors* are expected to resolve conflicts as described * *Area directors* are expected to resolve conflicts as described
here and in Section 4.1. The IESG will periodically evaluate the here and in Section 4.1. The IESG will periodically evaluate the
performance and needs of moderators, and may appoint and recall performance and needs of moderators, and may appoint and recall
moderators as they deem appropriate. Apart from that, the IESG moderators as they deem appropriate. Apart from that, the IESG
shall refrain from the day-to-day operation and management of the shall refrain from the day-to-day operation and management of the
moderator team. The moderators may consult with the IESG when moderator team. The moderators may consult with the IESG when
needed. needed.
3.1. Actions That Are Out of Scope 3.1. Actions That Are Out of Scope
Moderator actions are only permitted for the purposes of limiting Moderator actions are only permitted for the purposes of limiting
skipping to change at page 8, line 11 skipping to change at line 307
restriction of in-person, virtual, or hybrid meeting participation; restriction of in-person, virtual, or hybrid meeting participation;
content removal or redaction; and moderation or policing of private content removal or redaction; and moderation or policing of private
or non-IETF communications. While the moderator team does not or non-IETF communications. While the moderator team does not
moderate non-public IETF mailing lists, the administrators of such moderate non-public IETF mailing lists, the administrators of such
lists can choose to adopt some of the procedures that the moderator lists can choose to adopt some of the procedures that the moderator
team develops. team develops.
3.2. Unsolicited Bulk Messages 3.2. Unsolicited Bulk Messages
Unsolicited bulk messages are considered disruptive and should be Unsolicited bulk messages are considered disruptive and should be
handled in a manner consistent with the IESG statement on IETF Spam handled in a manner consistent with the "IESG Statement on Spam
Control on IETF Mailing Lists[IESG-SPAM], or its successors. Control on IETF Mailing Lists" [IESG-SPAM] or its successors.
Administrators and moderators may take similar actions in other fora Administrators and moderators may take similar actions in other fora
(e.g., GitHub or Instant Messaging). Such actions require no (e.g., GitHub or instant messaging). Such actions require no
additional reporting. additional reporting.
4. Moderation Procedures and Transparency 4. Moderation Procedures and Transparency
Within the bounds of the policies set herein, the moderator team Within the bounds of the policies set herein, the moderator team
shall develop and maintain procedures and criteria relating to shall develop and maintain procedures and criteria relating to
moderation, including the moderator team's own operating procedures. moderation, including the moderator team's own operating procedures.
Those procedures and criteria shall be developed with community Those procedures and criteria shall be developed with community
input, be approved by the IESG prior to going into effect, and be input, be approved by the IESG prior to going into effect, and be
made public. However, they need not be documented in the RFC series. made public. However, they need not be documented in the RFC Series.
This shall be the first task for the moderator team. Until those This shall be the first task for the moderator team. Until those
procedures and criteria are established, all previous processes procedures and criteria are established, all previous processes
referenced in Section 1 shall remain in effect. referenced in Section 1 shall remain in effect.
The intent of this memo is to provide the widest possible freedom of The intent of this memo is to provide the widest possible freedom of
action to administrators and moderators, with the expectation that action to administrators and moderators, with the expectation that
the minimal actions necessary will be taken. Those who are directed the minimal actions necessary will be taken. Those who are directed
to stop disrupting a forum must do so immediately. Further to stop disrupting a forum must do so immediately. Further
disruptions may lead to further corrective actions. disruptions may lead to further corrective actions.
Examples of actions that could be taken include: Examples of actions that could be taken include:
* Automated rate limiting mechanisms; * Automated rate-limiting mechanisms;
* Review and approval of submissions/messages; * Review and approval of submissions/messages;
* A private or public admonishment; * A private or public admonishment;
* Temporary or indefinite suspension of participation privileges in * Temporary or indefinite suspension of participation privileges in
one or more fora. one or more fora.
These are only examples, and not in any way prescriptive. These are only examples and are not in any way prescriptive.
Administrators and moderators are free to decide on these or other Administrators and moderators are free to decide on these or other
actions. actions.
All moderation actions that restrict participation privileges shall All moderation actions that restrict participation privileges shall
be immediately reported to those against whom those actions take be immediately reported to those against whom those actions take
effect, to relevant administrators, and to the moderator team for effect, to relevant administrators, and to the moderator team for
their review. They shall also be periodically reported to the IESG. their review. They shall also be periodically reported to the IESG.
Only moderation actions suspending participation privileges for Only moderation actions suspending participation privileges for
longer than fourteen (14) days must be reported to the forum to which longer than fourteen (14) days must be reported to the forum to which
skipping to change at page 9, line 25 skipping to change at line 367
IESG. IESG.
Moderators will periodically provide an aggregate report to the Moderators will periodically provide an aggregate report to the
community on actions taken under this policy. community on actions taken under this policy.
4.1. Consistency and Conflict Resolution 4.1. Consistency and Conflict Resolution
Administrators and moderators shall act in a manner consistent with Administrators and moderators shall act in a manner consistent with
this memo and the guidelines approved by the IESG. In cases of this memo and the guidelines approved by the IESG. In cases of
disagreement over a moderation decision, anyone may take the matter disagreement over a moderation decision, anyone may take the matter
up with the responsible Area Director for resolution, or with the up with the responsible area director for resolution, or with the
IETF chair if a responsible Area Director cannot be determined or is IETF Chair if a responsible area director cannot be determined or is
not assigned. If the disagreement cannot be resolved by the Area not assigned. If the disagreement cannot be resolved by the area
Director, that person may then appeal to the IESG, and subsequently director, that person may then appeal to the IESG and subsequently to
to the IAB using the processes stated in Sections 6.5.1 and 6.5.4 of the IAB using the processes stated in Sections 6.5.1 and 6.5.4 of
[RFC2026]. [RFC2026].
4.2. Reinstatement 4.2. Reinstatement
People and circumstances change. Individuals whose participation People and circumstances change. Individuals whose participation
privileges have been indefinitely suspended from a forum may request privileges have been indefinitely suspended from a forum may request
reinstatement. Requests for reinstatement may be made no earlier reinstatement. Requests for reinstatement may be made no earlier
than a year after the initial decision, and then only annually than a year after the initial decision and then only annually
afterward. afterward.
Any such request must be directed to the entity who made the decision Any such request must be directed to the entity who made the decision
(e.g., moderator team, working group chairs, etc.) or their (e.g., moderator team, working group chairs, etc.) or their
successors. That party may at their discretion reinstate someone, successors. That party may at their discretion reinstate someone,
conditionally or unconditionally. conditionally or unconditionally.
To avoid denial-of-service attacks on IETF processes, decisions to To avoid denial-of-service attacks on IETF processes, decisions to
not reinstate someone's participation privileges may not be appealed. not reinstate someone's participation privileges may not be appealed.
Any reinstatement is a grace and not a right. Any reinstatement is a grace and not a right.
A suspension of participation privileges imposed prior to this A suspension of participation privileges imposed prior to this
process shall be reconsidered only in accordance with the processes process shall be reconsidered only in accordance with the processes
in place at the time of the suspension, even if the corresponding RFC in place at the time of the suspension, even if the corresponding RFC
has been formally obsoleted. has been formally obsoleted.
5. Relationship to other IETF functions 5. Relationship to Other IETF Functions
5.1. Relation to the Ombudsteam 5.1. Relation to the Ombudsteam
Administrators and moderators shall complement the efforts of the Administrators and moderators shall complement the efforts of the
IETF ombudsteam [OT], whose focus on anti-harassment and operation IETF Ombudsteam [OT], whose focus on anti-harassment and operation
shall remain unchanged. Administrators and moderators should always shall remain unchanged. Administrators and moderators should always
report suspected harassment. They should nonetheless take any report suspected harassment. They should nonetheless take any
necessary actions regarding disruptive behavior. necessary actions regarding disruptive behavior.
5.2. Relation to the IETF LLC 5.2. Relation to the IETF LLC
The Board of Directors of the IETF Administration LLC (IETF LLC) has The Board of Directors of the IETF Administration LLC (IETF LLC) has
fiduciary duty for the overall organization, which includes the duty fiduciary duty for the overall organization, which includes the duty
to protect the organization from serious legal risk that may arise to protect the organization from serious legal risk that may arise
from the behavior of IETF participants. from the behavior of IETF participants.
This protection may include the need for the IETF LLC to take This protection may include the need for the IETF LLC to take
emergency moderation actions. These emergency actions are expected emergency moderation actions. These emergency actions are expected
to be taken only when the IETF LLC has received legal advice that to be taken only when the IETF LLC has received legal advice that
such action is necessary, and therefore extremely rare in frequency. such action is necessary and therefore will be extremely rare in
Some examples of where this might be necessary are: frequency. Some examples of where this might be necessary are:
* Someone making a credible threat of harm to other IETF * Someone making a credible threat of harm to other IETF
participants. participants.
* Someone using IETF mailing lists and/or websites to share content * Someone using IETF mailing lists and/or websites to share content
where publishing that content on IETF lists and/or websites brings where publishing that content on IETF lists and/or websites brings
serious legal risk to the IETF. serious legal risk to the IETF.
* Someone making a credible threat of legal action where any form of * Someone making a credible threat of legal action where any form of
interaction with them on IETF mailing lists may have serious legal interaction with them on IETF mailing lists may have serious legal
consequences for the IETF. consequences for the IETF.
If any such action is taken, the IETF LLC should, except where 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 limited by legal advice to the contrary, inform the IESG as soon as
possible, providing full details of the subject of the action, nature possible, providing full details of the subject of the action, nature
of the action, reason for the action and expected duration. The IETF of the action, reason for the action, and the expected duration. The
LLC should also inform the moderator team and IETF community, except IETF LLC should also inform the moderator team and IETF community,
where it receives legal advice to the contrary. except where it receives legal advice to the contrary.
As such an action would be taken by the IETF LLC in order to protect 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 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. 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 The subject of any such action may request a review by the IETF LLC
board, as documented in Section 4.7 of [RFC8711]. Board, as documented in Section 4.7 of [RFC8711].
Any such action taken by the IETF LLC under this section of this Any such action taken by the IETF LLC under this section of this
policy is not subject to the rest of this policy. policy is not subject to the rest of this policy.
6. Security Considerations 6. Security Considerations
The usual security considerations [RFC3552] do not apply to this The usual security considerations [RFC3552] do not apply to this
memo. memo.
There is the potential abuse of the moderation procedures by There is the potential abuse of the moderation procedures by
skipping to change at page 11, line 29 skipping to change at line 467
procedures that are intended to apply uniformly across the IETF. procedures that are intended to apply uniformly across the IETF.
2. Section 1.2 explicitly states that viewpoints outside the rough 2. Section 1.2 explicitly states that viewpoints outside the rough
consensus are not in and of themselves disruptive. consensus are not in and of themselves disruptive.
3. Section 4 provides transparency by requiring that moderation 3. Section 4 provides transparency by requiring that moderation
actions that restrict participation privileges be immediately actions that restrict participation privileges be immediately
reported to the affected person and to the moderation team, and reported to the affected person and to the moderation team, and
periodically reported to the IESG. periodically reported to the IESG.
4. That same section requires that the community be informed in the 4. Section 4 also requires that the community be informed in the
case of suspensions lasting longer than 14 days. case of suspensions lasting longer than 14 days.
5. Section 4.1 lays out an appeals process in the case of 5. Section 4.1 lays out an appeals process in the case of
disagreements. disagreements.
6. If moderators find that the procedures themselves are leading to 6. If moderators find that the procedures themselves are leading to
inappropriate moderation, Section 4 allows them to update those inappropriate moderation, Section 4 allows them to update those
procedures in consultation with the community, and with the procedures in consultation with the community and with the
approval of the IESG. approval of the IESG.
7. If IETF participants believe that either the IESG or the IAB are 7. If IETF participants believe that either the IESG or the IAB are
not performing their respective oversight functions as described not performing their respective oversight functions as described
in this document, they may comment to the NomCom [BCP10] or the in this document, they may comment to the NomCom [BCP10] or the
community at large. community at large.
8. Finally, if it appears that these processes are not functioning 8. Finally, if it appears that these processes are not functioning
properly, the policies stated in this memo may be amended. They properly, the policies stated in this memo may be amended. They
are not set in stone. are not set in stone.
Moderation actions are intended to limit the likelihood of disruptive Moderation actions are intended to limit the likelihood of disruptive
behavior by a few IETF participants from discouraging participation behavior by a few IETF participants that may discourage participation
by other IETF participants. by other IETF participants.
7. IANA Considerations 7. IANA Considerations
No IANA actions are requested. This document has no IANA actions.
8. Acknowledgments 8. Acknowledgments
This memo is based on two individual Internet-Drafts, draft-ecahc- This memo is based on two individual Internet-Drafts, draft-ecahc-
moderation (https://datatracker.ietf.org/doc/draft-ecahc-moderation/) moderation (https://datatracker.ietf.org/doc/draft-ecahc-moderation/)
authored by Lars Eggert, Alissa Cooper, Jari Arkko, Russ Housley and authored by Lars Eggert, Alissa Cooper, Jari Arkko, Russ Housley, and
Brian E. Carpenter, and draft-lear-bcp83-replacement Brian E. Carpenter, and draft-lear-bcp83-replacement
(https://datatracker.ietf.org/doc/draft-lear-bcp83-replacement/) (https://datatracker.ietf.org/doc/draft-lear-bcp83-replacement/)
authored by Eliot Lear, Robert Wilton, Bron Gondwana and John R. authored by Eliot Lear, Robert Wilton, Bron Gondwana, and John
Levine. Robert Sayre authored draft-sayre-modpod-excellent R. Levine. Robert Sayre authored draft-sayre-modpod-excellent
(https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/), (https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/),
which also originated ideas reflected in this work. Pete Resnick which also originated ideas reflected in this work. Pete Resnick
provided the basis for how the moderators interact with list/forum provided the basis for how the moderators interact with list/forum
leadership. leadership.
These individuals contributed additional improvements: These individuals contributed additional improvements:
* Alissa Cooper * Alissa Cooper
* Brian Carpenter * Brian Carpenter
skipping to change at page 13, line 46 skipping to change at line 581
Nominating and Recall Committees", BCP 10, RFC 8713, Nominating and Recall Committees", BCP 10, RFC 8713,
DOI 10.17487/RFC8713, February 2020, DOI 10.17487/RFC8713, February 2020,
<https://www.rfc-editor.org/info/rfc8713>. <https://www.rfc-editor.org/info/rfc8713>.
Duke, M., "Nominating Committee Eligibility", BCP 10, Duke, M., "Nominating Committee Eligibility", BCP 10,
RFC 9389, DOI 10.17487/RFC9389, April 2023, RFC 9389, DOI 10.17487/RFC9389, April 2023,
<https://www.rfc-editor.org/info/rfc9389>. <https://www.rfc-editor.org/info/rfc9389>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/rfc/rfc2026>. <https://www.rfc-editor.org/info/rfc2026>.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and [RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
September 1998, <https://www.rfc-editor.org/rfc/rfc2418>. September 1998, <https://www.rfc-editor.org/info/rfc2418>.
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", [RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
<https://www.rfc-editor.org/rfc/rfc3935>. <https://www.rfc-editor.org/info/rfc3935>.
[RFC7154] Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54, [RFC7154] Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54,
RFC 7154, DOI 10.17487/RFC7154, March 2014, RFC 7154, DOI 10.17487/RFC7154, March 2014,
<https://www.rfc-editor.org/rfc/rfc7154>. <https://www.rfc-editor.org/info/rfc7154>.
[RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment [RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment
Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March
2016, <https://www.rfc-editor.org/rfc/rfc7776>. 2016, <https://www.rfc-editor.org/info/rfc7776>.
[RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of [RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of
the IETF Administrative Support Activity, Version 2.0", the IETF Administrative Support Activity, Version 2.0",
BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020, BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020,
<https://www.rfc-editor.org/rfc/rfc8711>. <https://www.rfc-editor.org/info/rfc8711>.
9.2. Informative References 9.2. Informative References
[AHP] IESG, "IETF Anti-Harassment Policy", 3 November 2013, [AHP] IESG, "IETF Anti-Harassment Policy", 3 November 2013,
<https://www.ietf.org/about/groups/iesg/statements/anti- <https://www.ietf.org/about/groups/iesg/statements/anti-
harassment-policy/>. harassment-policy/>.
[DP] IESG, "IESG Statement on Disruptive Posting", 16 February [DP] IESG, "IESG Statement on Disruptive Posting", 17 February
2006, <https://www.ietf.org/about/groups/iesg/statements/ 2006, <https://www.ietf.org/about/groups/iesg/statements/
disruptive-posting/>. disruptive-posting/>.
[IESG-SPAM] [IESG-SPAM]
IESG, "IESG Statement on Spam Control on IETF Mailing IESG, "IESG Statement on Spam Control on IETF Mailing
Lists", 18 April 2008, <https://datatracker.ietf.org/doc/ Lists", 14 April 2008, <https://datatracker.ietf.org/doc/
statement-iesg-iesg-statement-on-spam-control-on-ietf- statement-iesg-iesg-statement-on-spam-control-on-ietf-
mailing-lists-20080414/>. mailing-lists-20080414/>.
[MODML] IESG, "IESG Guidance on the Moderation of IETF Working [MODML] IESG, "IESG Guidance on the Moderation of IETF Working
Group Mailing Lists", 29 August 2000, Group Mailing Lists", 29 August 2000,
<https://www.ietf.org/about/groups/iesg/statements/ <https://www.ietf.org/about/groups/iesg/statements/
mailing-lists-moderation/>. mailing-lists-moderation/>.
[OT] "Ombudsteam", <https://www.ietf.org/contact/ombudsteam/>. [OT] "Ombudsteam", <https://www.ietf.org/contact/ombudsteam/>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/rfc/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF [RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF
Mailing Lists", BCP 83, RFC 3683, DOI 10.17487/RFC3683, Mailing Lists", BCP 83, RFC 3683, DOI 10.17487/RFC3683,
March 2004, <https://www.rfc-editor.org/rfc/rfc3683>. March 2004, <https://www.rfc-editor.org/info/rfc3683>.
[RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the [RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the
Management of IETF Mailing Lists", BCP 25, RFC 3934, Management of IETF Mailing Lists", BCP 25, RFC 3934,
DOI 10.17487/RFC3934, October 2004, DOI 10.17487/RFC3934, October 2004,
<https://www.rfc-editor.org/rfc/rfc3934>. <https://www.rfc-editor.org/info/rfc3934>.
[RFC7282] Resnick, P., "On Consensus and Humming in the IETF", [RFC7282] Resnick, P., "On Consensus and Humming in the IETF",
RFC 7282, DOI 10.17487/RFC7282, June 2014, RFC 7282, DOI 10.17487/RFC7282, June 2014,
<https://www.rfc-editor.org/rfc/rfc7282>. <https://www.rfc-editor.org/info/rfc7282>.
[RFC9245] Eggert, L. and S. Harris, "IETF Discussion List Charter", [RFC9245] Eggert, L. and S. Harris, "IETF Discussion List Charter",
BCP 45, RFC 9245, DOI 10.17487/RFC9245, June 2022, BCP 45, RFC 9245, DOI 10.17487/RFC9245, June 2022,
<https://www.rfc-editor.org/rfc/rfc9245>. <https://www.rfc-editor.org/info/rfc9245>.
Appendix A. Change History of this I-D
| RFC Editor: Please remove this appendix before publication.
A.1. 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)
A.2. 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)
A.3. 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)
A.4. 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)
A.5. 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)
A.6. 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)
A.7. 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)
A.8. 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)
A.9. Since draft-ietf-modpod-group-processes-03
* Non-normative Examples of Disruptive Behavior
(https://github.com/larseggert/draft-ietf-modpod-group-processes/
pull/121)
A.10. 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)
A.11. 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)
A.12. 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)
A.13. 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)
Appendix B. Motivation Appendix A. Motivation
Section 1 summarized the process changes introduced by this memo. Section 1 summarizes the process changes introduced by this memo.
This appendix discusses the background that led to them. This appendix discusses the background that led to them.
B.1. Background A.1. Background
The IETF community has defined general guidelines for personal The IETF community has defined general guidelines for personal
interactions in the IETF [RFC7154], and the IESG has defined an anti- interactions in the IETF [RFC7154]. The IESG has defined an anti-
harassment policy for the IETF [AHP] for which the IETF community has harassment policy for the IETF [AHP] for which the IETF community has
defined anti-harassment procedures [RFC7776], empowering an defined anti-harassment procedures [RFC7776], empowering an
ombudsteam [OT] to take necessary action. Ombudsteam [OT] to take necessary action.
Dealing with _disruptive_ behavior, however, is not part of the role Dealing with _disruptive_ behavior, however, is not part of the role
of the ombudsteam. [RFC2418] tasks the chairs of each IETF working of the Ombudsteam. [RFC2418] tasks the chairs of each IETF working
group with moderating their group's in-person meetings while group with moderating their group's in-person meetings while
[RFC3934] provided chairs a procedure to help manage mailing lists. [RFC3934] provides chairs a procedure to help manage mailing lists.
An IESG statement [MODML] described additional guidance to working An IESG statement [MODML] describes additional guidance to working
group chairs about how — but not when — to moderate their lists. group chairs about how -- but not when -- to moderate their lists.
For IETF mailing lists not associated with a working group, another For IETF mailing lists not associated with a working group, another
IESG statement [DP] clarifies that the IESG tasks list administrators IESG statement [DP] clarifies that the IESG tasks list administrators
with moderation. And the IETF list for general discussions has, with moderation. And the IETF list for general discussions has,
mostly for historic reasons, a team of moderators that are not list mostly for historic reasons, a team of moderators that are not list
administrators and operate by a different set of processes [RFC9245]. administrators and operate by a different set of processes [RFC9245].
Note that the term "moderation" can refer both to _preemptive_ Note that the term "moderation" can refer both to _preemptive_
moderation, where administrators review attempted participation moderation, where administrators review attempted participation
before it occurs (such as reviewing messages to a mailing list), and before it occurs (such as reviewing messages to a mailing list), and
_reactive_ moderation, where administrators intervene after _reactive_ moderation, where administrators intervene after
disruptive participation has occurred. The IETF historically mainly disruptive participation has occurred. Historically, the IETF has
practiced reactive moderation, with a spectrum from gentle reminders mainly practiced reactive moderation, with a spectrum from gentle
on- and off-list, all the way to suspension of posting rights and reminders on- and off-list, all the way to suspension of posting
other ways of participating or communicating. It is up to the rights and other ways of participating or communicating. It is up to
moderators and administrators to decide which mix of preemptive and the moderators and administrators to decide which mix of preemptive
reactive moderation to employ as part of their procedures. and reactive moderation to employ as part of their procedures.
In addition, [RFC3683] defines a process for revoking an individual's In addition, [RFC3683] defines a process for revoking an individual's
posting rights to IETF mailing lists following a community last-call posting rights to IETF mailing lists following a community Last Call
of a "posting rights" action (PR-action) proposed by the IESG, often of a "posting rights" action (PR-action) proposed by the IESG, often
in response to complaints from the community. in response to complaints from the community.
Experience and community input suggests that an evolution of the Experience and community input suggests that an evolution of the
existing processes is necessary. existing processes is necessary.
B.2. Problems with the Previous Approach A.2. Problems with the Previous Approach
The previous approach to moderation of disruptive participation The previous approach to moderation of disruptive participation
through chairs, list administrators, and moderator teams, combined through chairs, list administrators, and moderator teams, combined
with the IESG-led process of PR-actions, has proven to be less than with the IESG-led process of PR-actions, has proven to be less than
ideal: ideal:
* The IETF community has not been able to agree on a common * The IETF community has not been able to agree on a common
definition of disruptive behavior. Therefore, chairs and list definition of disruptive behavior. Therefore, chairs and list
administrators apply individually different criteria when making administrators apply individually different criteria when making
decisions, and participants have different expectations for when decisions, and participants have different expectations for when
skipping to change at page 20, line 24 skipping to change at line 720
originator of disruptive behavior is a misguided participant who originator of disruptive behavior is a misguided participant who
can be reasoned with and who will change their ways. can be reasoned with and who will change their ways.
* Chairs and list administrators may only enact moderation actions * Chairs and list administrators may only enact moderation actions
for their single list, which is ill-suited when a pattern of for their single list, which is ill-suited when a pattern of
disruptive behavior spans multiple lists. Also, chairs and list disruptive behavior spans multiple lists. Also, chairs and list
administrators may not be fully aware of disruptive behavior that administrators may not be fully aware of disruptive behavior that
spans multiple lists, due to not being subscribed to some of them. spans multiple lists, due to not being subscribed to some of them.
* PR-actions, which can address disruptive behavior across several * PR-actions, which can address disruptive behavior across several
lists, are cumbersome and slow, and inconsistent. This has led to lists, are cumbersome, slow, and inconsistent. This has led to a
a situation where PR-actions are rarely used, and when they are situation where PR-actions are rarely used, and when they are
used, they are perceived as very heavy-handed. used, they are perceived as very heavy-handed.
* For a given mailing list, participants may not feel comfortable * For a given mailing list, participants may not feel comfortable
reporting disruptive behavior to a chair or list administrator, reporting disruptive behavior to a chair or list administrator,
for various reasons. For mailing lists not associated with for various reasons. For mailing lists not associated with
working groups, list administrators are not even publicly working groups, list administrators are not even publicly
identified - they can only be contacted through an anonymous alias identified -- they can only be contacted through an anonymous
address. This exacerbates the problem, because participants may alias address. This exacerbates the problem, because participants
not be comfortable reporting disruptive behavior to an anonymous may not be comfortable reporting disruptive behavior to an
party. anonymous party.
* The IETF offers participation not only through in-person meetings * The IETF offers participation not only through in-person meetings
and mailing lists, which are the two channels of participation for and mailing lists, which are the two channels of participation for
which moderation processes are currently defined. IETF business which moderation processes are currently defined. IETF business
also happens in chat groups, remote meeting participation systems, also happens in chat groups, remote meeting participation systems,
virtual meetings, wikis, GitHub repositories, and more. How virtual meetings, wikis, GitHub repositories, and more. How
disruptive behavior is moderated in these fora is currently disruptive behavior is moderated in these fora is currently
undefined. undefined.
Appendix C. Non-Normative Examples of Disruptive Behavior Appendix B. Non-Normative Examples of Disruptive Behavior
The list below describes some types of disruptive behavior, but it is The list below describes some types of disruptive behavior, but it is
non-exhaustive. non-exhaustive.
* Discussion of subjects unrelated to a forum's charter or scope; * Discussion of subjects unrelated to a forum's charter or scope;
* Uncivil commentary, regardless of the general subject; * Uncivil commentary, regardless of the general subject;
* Messages announcing conferences, events, or activities that are * Messages announcing conferences, events, or activities that are
not sponsored or endorsed by the Internet Society or IETF, unless not sponsored or endorsed by the Internet Society or IETF, unless
posted with prior approval of list administrators; posted with prior approval of list administrators;
* Repeatedly arguing counter to a WG charter that has been approved * Repeatedly arguing counter to a WG charter that has been approved
by the IESG; and by the IESG; and
* "Sealioning", where a participant makes incessant requests for * "Sealioning", where a participant makes incessant requests for
evidence or data, even while remaining superficially polite. evidence or data, even while remaining superficially polite.
skipping to change at page 21, line 29 skipping to change at line 775
possible to write a complete list of all such behaviors. possible to write a complete list of all such behaviors.
Authors' Addresses Authors' Addresses
Lars Eggert (editor) Lars Eggert (editor)
Mozilla Mozilla
Stenbergintie 12 B Stenbergintie 12 B
FI-02700 Kauniainen FI-02700 Kauniainen
Finland Finland
Email: lars@eggert.org Email: lars@eggert.org
URI: <https://eggert.org/> URI: https://eggert.org/
Eliot Lear (editor) Eliot Lear (editor)
Cisco Systems Cisco Systems
Richtistrasse 7 Richtistrasse 7
CH-8304 Wallisellen CH-8304 Wallisellen
Switzerland Switzerland
Phone: +41 44 878 9200 Phone: +41 44 878 9200
Email: lear@lear.ch Email: lear@lear.ch
 End of changes. 71 change blocks. 
367 lines changed or deleted 166 lines changed or added

This html diff was produced by rfcdiff 1.48.