Network Working Group L. Eggert, Ed.
Internet-Draft Mozilla
Obsoletes: 3683, 9245 (if approved) E. Lear, Ed.
Updates: 2418 (if approved) Cisco Systems
Intended status: Best Current Practice 3 June 2025
Expires: 5 December 2025
IETF Community Moderation
draft-ietf-modpod-group-processes-05
Abstract
The IETF will treat people with kindness and grace, but not endless
patience.
This document describes the creation of a moderator team for all the
IETF's various contribution channels. Without removing existing
responsibilities for working group management, this team enables a
uniform approach to moderation of disruptive participation across all
mailing lists and other methods of IETF collaboration.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://larseggert.github.io/draft-ietf-modpod-group-processes/draft-
ietf-modpod-group-processes.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-ietf-
modpod-group-processes/.
Discussion of this document takes place on the mod-discuss Working
Group mailing list (mailto:mod-discuss@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/mod-discuss/. Subscribe
at https://www.ietf.org/mailman/listinfo/mod-discuss/.
Source for this draft and an issue tracker can be found at
https://github.com/larseggert/draft-ietf-modpod-group-processes.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Eggert & Lear Expires 5 December 2025 [Page 1]
Internet-Draft IETF Community Moderation June 2025
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 December 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. General Philosophy . . . . . . . . . . . . . . . . . . . 4
2. IETF Moderator Team . . . . . . . . . . . . . . . . . . . . . 5
2.1. Composition . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Team Diversity . . . . . . . . . . . . . . . . . . . 6
2.2. Training . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Non-IETF Communication Channels And Private Communications
Excluded . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. IETF Working Groups . . . . . . . . . . . . . . . . . . . 7
4. Operations and Procedures of the Moderator Team and
Transparency . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Reinstatement . . . . . . . . . . . . . . . . . . . . . . 8
5. Relationship to other IETF functions . . . . . . . . . . . . 9
5.1. Relation to the Ombudsteam . . . . . . . . . . . . . . . 9
5.2. Relation to the IETF LLC . . . . . . . . . . . . . . . . 9
5.3. Relation to the IRTF . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
Eggert & Lear Expires 5 December 2025 [Page 2]
Internet-Draft IETF Community Moderation June 2025
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 13
A.1. Since draft-ietf-modpod-group-processes-04 . . . . . . . 13
A.2. Since draft-ietf-modpod-group-processes-03 . . . . . . . 13
A.3. Since draft-ietf-modpod-group-processes-02 . . . . . . . 13
A.4. Since draft-ietf-modpod-group-processes-01 . . . . . . . 14
A.5. Since draft-ietf-modpod-group-processes-00 . . . . . . . 14
A.6. Since draft-ecahc-moderation-01 . . . . . . . . . . . . . 14
Appendix B. Problems with the Previous Approach . . . . . . . . 14
Appendix C. Non-Normative Examples of Disruptive Behavior . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
This document proposes the creation of a moderator team for all the
IETF's various contribution channels. The moderator team is modeled
after, and subsumes, the moderator team for the IETF discussion list
[RFC9245] and is tasked to moderate *all* IETF participation
channels.
As a consequence, this document obsoletes [RFC3683] and the "posting
rights" (PR) action it defines. It also obsoletes Section 4 of
[RFC9245], which defines the IETF discussion list moderation team.
Finally, it updates Section 6.1 of [RFC2418], because the moderator
team will now work together with working group chairs to moderate
disruptive behavior.
1.1. Background
The IETF community has defined general guidelines for personal
interactions in the IETF [RFC7154], and the IESG has defined an anti-
harassment policy for the IETF [AHP] for which the IETF community has
defined anti-harassment procedures [RFC7776], empowering an
ombudsteam [OT] to take necessary action.
Dealing with _disruptive_ behavior, however, is not part of the role
of the ombudsteam. [RFC3934] tasks the chairs of each IETF working
group with moderating their group's in-person meetings and mailing
lists, and an IESG statement [MODML] describes additional guidance to
working group chairs about how — but not when — to moderate their
lists.
Eggert & Lear Expires 5 December 2025 [Page 3]
Internet-Draft IETF Community Moderation June 2025
For IETF mailing lists not associated with a working group, another
IESG statement [DP] clarifies that the list administrators are tasked
with moderation. And the IETF list for general discussions has,
mostly for historic reasons, a team of moderators that are not list
administrators and operate by a different set of processes [RFC9245].
Note that the term "moderation" can refer both to _preemptive_
moderation, where moderators review attempted participation before it
occurs (such as reviewing messages to a mailing list), and _reactive_
moderation, where moderators intervene after problematic
participation has occurred. The IETF historically mainly practiced
reactive moderation, with a spectrum from gentle reminders on- and
off-list, all the way to suspension of posting rights and other ways
of participating or communicating. It is up to the moderators to
decide which mix of preemptive and reactive moderation to employ as
part of their processes.
In addition, [RFC3683] defines a process for revoking an individual's
posting rights to IETF mailing lists following a community last-call
of a "posting rights" action (PR-action) proposed by the IESG, often
in response to complaints from the community.
Experience and community input suggests that an evolution of the
existing processes is necessary (see Appendix B).
1.2. General Philosophy
The cornerstone of our philosophy is first and foremost the
individual, whose responsibility is to further the goals of the
organization [RFC3935] in a manner consistent with the policy laid
out in [RFC7154].
The IETF is an open standards organization. Engaged, respectful
discussion that is within the scope of a forum should not be
considered abuse, nor should someone be considered abusive solely
because they are outside the rough consensus. Disagreement and
diverse points of view within any standards organization are to be
expected, and are even healthy. However, when someone crosses the
line into disruptive behavior, some action must be taken in order to
maintain decorum of the community.
The moderation policy goals are as follows:
* Apply consistent, fair, and timely moderation of communication
across all IETF channels without regard to one's position or
previous contributions;
Eggert & Lear Expires 5 December 2025 [Page 4]
Internet-Draft IETF Community Moderation June 2025
* Disagreements about moderation actions are addressed through
appeals;
* Balance transparency against both privacy of individuals involved
and further disruption to the community;
* Allow moderators to reconsider decisions; and
* Provide the broadest possible latitude to moderators, so that they
may have the flexibility to address a broad range of individuals
and circumstances.
Questions about processes detailed below should be answered through
the lens of these aims.
The goal is explicitly *not* punishment, but to maintain an open,
welcoming, non-hostile environment in which all may participate on an
equal footing, regardless of their position or past contributions.
2. IETF Moderator Team
This document proposes a different, uniform approach to moderating
the IETF's various participation channels: a moderator team for the
IETF. The creation of this team intends to address the issues
identified in the previous model Appendix B and the principles
described in the introduction.
2.1. Composition
The moderator team consists of no less than five individuals. The
IESG appoints and replaces moderators. In selecting members, the
IESG will take into account geographic coverage, expected and
unexpected absences, and team diversity. The moderator team may
expand or contract based on operational experience. Apart from
appointing and replacing moderators, the IESG shall refrain from the
day-to-day operation and management of the moderator team. The
moderators may decide to consult with the IESG when needed.
Because the IESG and IAB are in the appeals chain for moderator team
decisions (see Section 4.1), the IESG must not appoint a moderator
who is serving on the IESG or IAB. Individuals serving on other
bodies to which the NomCom appoints members, such as the IETF Trust
or the LLC Board, as well as LLC staff and contractors shall also be
excluded from serving on the moderator team. If a moderator is
assuming any such role, they shall step down from the moderator team
soon after.
Eggert & Lear Expires 5 December 2025 [Page 5]
Internet-Draft IETF Community Moderation June 2025
2.1.1. Team Diversity
Due to the global nature of the IETF, the membership of this team
should reflect a diversity of time zones and other participant
characteristics that lets it operate effectively around the clock and
throughout the year. Ideally, the moderators should be able to
respond to issues within a few hours.
Team diversity is also important to ensure any participant observing
problematic behavior can identify a moderator they feel comfortable
contacting.
2.2. Training
The IETF is committed to providing and/or funding training for
appointed moderators as necessary. The IESG will negotiate any
required funding or resources with IETF Administration LLC [RFC8711].
3. Scope
The IETF moderator team is responsible for establishing processes to
address moderation needs across all IETF fora, both present and
future, including, but not limited to, mailing lists, chat channels,
and discussions in other systems that the IETF or WGs have chosen to
employ, such as GitHub repositories, Wikis, or issue trackers.
The moderators are authorized to moderate all non-working group fora,
including the IETF discussion and last-call mailing lists and all
non-WG mailing lists, as well as area mailing lists. This also
includes non-WG IETF-sponsored chat mechanisms. (Involvement in the
moderation of WGs is further discussed in Section 3.2.)
It is not expected that the moderators will be monitoring every IETF
channel, but rather that participants may and group management should
flag concerns about disruptive behavior to the moderators. However,
the moderators should actively monitor a small set of key
participation channels, including, for example, the IETF discussion
and last-call mailing lists or the IETF plenary chat channel. The
moderators should decide which channels are in this set based on
their own judgment and community suggestions. (Note that some
participation channels, such as the examples given in the previous
sentence, have no chairs or other community leadership, so the
moderators must handle those.)
Moderators are expected to be a resource that the community can use
to address problematic contributions.
Eggert & Lear Expires 5 December 2025 [Page 6]
Internet-Draft IETF Community Moderation June 2025
3.1. Non-IETF Communication Channels And Private Communications
Excluded
It is important to note that the moderator team only moderates
_public_ IETF participation channels. Their mandate does not extend
to problematic behavior in private channels, such as private chat
channels, direct messages, or conversations or other interactions
outside of meetings. In such cases, the Ombudsteam should be
approached.
3.2. IETF Working Groups
The management and moderation of participation channels associated
with various IETF working groups, including their mailing lists, chat
channels and in-person, remote, or interim meetings remains primarily
a task of the relevant group's management, such as WG chairs. Group
participants may and chairs must alert the moderators to problematic
behavior that rises to the level that some action is needed.
In the interest of timely and consistent moderation, moderators may
take actions against someone in a working group setting, but they
must immediately inform management of relevant groups, including WG
chairs and area directors, when they do so.
If working group management and moderators disagree about a group
moderation action taken by one party unilaterally, the matter shall
be taken up with the responsible area director(s) for resolution,
and, when more than one area is involved, with the IESG. Based on
the result of this consultation, the moderation action may be upheld,
modified or reverted.
It is anticipated that such disagreements will be exceedingly rare.
The moderators should respect the views of the group management in
such cases, and the group management should respect the moderators'
task of upholding an overall IETF-wide uniformity for moderation.
4. Operations and Procedures of the Moderator Team and Transparency
Within the bounds of the policies set within this memo and with the
approval of the IESG, the moderator team shall define any additional
processes and moderation criteria necessary to execute their role.
Those processes and criteria shall be developed with community input
and made public, but need not be documented in the RFC series.
The intent of this memo is to provide the widest possible freedom of
action to the moderators, with a few constraints. Examples of
actions that could be taken include:
Eggert & Lear Expires 5 December 2025 [Page 7]
Internet-Draft IETF Community Moderation June 2025
* Automated rate limiting mechanisms;
* Review and approval of submissions/messages;
* A private or public admonishment;
* Temporary or permanent bans in one or more fora.
We stress that these are only examples, and not in any way
prescriptive. The moderator team is free to decide on these or other
actions.
The expectation is that the minimal action necessary to maintain the
comity of a forum will be attempted.
Any attempt to circumvent or otherwise ignore a moderation action is
a demonstration of bad faith that may warrant further moderation.
The moderator team is responsible to the IESG. The IESG may create
or designate a forum to facilitate discussion about moderation, and
refer interested parties to that forum. All actions taken by the
moderator team shall be reported to the IESG, as well as to those
against whom those actions are directed. To address inappropriate
contributions in a timely manner, only bans longer than fourteen (14)
days shall be reported to the forum in which the person was banned,
and in the case of a ban that spans more than one forum, to the
community in a manner decided by the IESG.
Content removal or redaction from IETF archives are not moderation
actions, and are therefore beyond the scope of this memo.
4.1. Appeals
Because the moderator team serves at the discretion of the IESG, any
moderation decision can be appealed to the IESG by anyone, per
[RFC2026]. Disagreements with a decision by the moderator team can
be brought to their attention. If this does not lead to a
resolution, a decision by the IESG can be appealed to the IAB as
described in [RFC2026].
4.2. Reinstatement
People and circumstances change. Individuals who have been banned
from a forum may request reinstatement. Any such request must be
directed to the entity that made the decision (e.g., moderation team,
working group chairs, etc.) or their successors, and that party may -
at their discretion - reinstate someone, conditionally or
unconditionally. Decisions to not reinstate someone may not be
Eggert & Lear Expires 5 December 2025 [Page 8]
Internet-Draft IETF Community Moderation June 2025
appealed. Requests for reinstatement may be entertained only a year
after the initial decision, and then only annually.
A ban imposed prior to this process shall be reconsidered only in
accordance with the processes in place at the time of the ban, even
if the corresponding RFC has been formally obsoleted.
5. Relationship to other IETF functions
5.1. Relation to the Ombudsteam
The moderator team shall complement the efforts of the IETF
ombudsteam [OT], whose focus on anti-harassment and operation shall
remain unchanged. The moderator team and ombudsteam are expected to
work together in cases that may involve both disruptive behavior and
harassment; they may determine the most effective way to do so in
each case. For example, the ombudsteam may decide to have one of
their members serve as a liaison to the moderator team.
The ombudsteam has strict rules of confidentiality. If a moderation
case overlaps with an ombudsteam case, confidential information must
not be shared between the teams.
5.2. Relation to the IETF LLC
The Board of Directors of the IETF Administration LLC (IETF LLC) has
fiduciary duty for the overall organization, which includes the duty
to protect the organization from serious legal risk that may arise
from the behavior of IETF participants.
This protection may include the need for the IETF LLC to take
emergency moderation actions. These emergency actions are expected
to be taken only when the IETF LLC has received legal advice that
such action is necessary, and therefore extremely rare in frequency.
Some examples of where this might be necessary are:
* Someone making credible threat of harm to other IETF participants.
* Someone using IETF mailing lists and/or websites to share content
where publishing that content on IETF lists and/or websites brings
serious legal risk.
* Someone making credible threats of legal action where any form of
interaction with them on IETF mailing lists may have serious legal
consequences for the IETF.
Eggert & Lear Expires 5 December 2025 [Page 9]
Internet-Draft IETF Community Moderation June 2025
If any such action is taken, the IETF LLC should, except where
limited by legal advice to the contrary, inform the IESG as soon as
possible, providing full details of the subject of the action, nature
of the action, reason for the action and expected duration. The IETF
LLC should also inform the moderator team and IETF community, except
where it receives legal advice to the contrary.
As such an action would be taken by the IETF LLC in order to protect
the IETF according to its fiduciary duty, then it cannot allow that
to be overridden by a decision of the moderation team or the IESG.
The subject of any such action may request a review by the IETF LLC
board, as documented in section 4.7 of [RFC8711]
Any such action taken by the IETF LLC under this section of this
policy, is not subject to the rest of the policy in this document.
5.3. Relation to the IRTF
The Internet Research Task Force (IRTF) [RFC2014] is a peer
organization separate from the IETF that is governed by its own set
or rules and processes. Sections 3, 6 and 7 of
[I-D.perkins-irtf-code-of-conduct] discuss rules for participating in
the IRTF and moderation of IRTF participation channels.
6. Security Considerations
The usual security considerations [RFC3552] do not apply to this
document.
Potential abuse of the moderation process for the suppression of
undesired opinions is counteracted by the availability of an appeals
process, per Section 4.1.
The actions of the moderator team are intended to limit the
likelihood of disruptive behavior by a few IETF participants from
discouraging participation by other IETF participants.
7. IANA Considerations
This document has no IANA actions.
Eggert & Lear Expires 5 December 2025 [Page 10]
Internet-Draft IETF Community Moderation June 2025
8. Acknowledgments
This document is based on two individual Internet-Drafts, draft-
ecahc-moderation (https://datatracker.ietf.org/doc/draft-ecahc-
moderation/) authored by Lars Eggert, Alissa Cooper, Jari Arkko, Russ
Housley and Brian E. Carpenter, and draft-lear-bcp83-replacement
(https://datatracker.ietf.org/doc/draft-lear-bcp83-replacement/)
authored by Eliot Lear, Robert Wilton, Bron Gondwana and John R.
Levine. Many of the ideas in this document originated in those I-Ds.
Robert Sayre authored draft-sayre-modpod-excellent
(https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/),
which also originated ideas reflected in this WG document.
These individuals suggested additional improvements to this document:
* Alissa Cooper
* Chris Box
* Eric Rescorla
* Jay Daley
* Joel Halpern
* Melinda Shore
* Michael Richardson
* Rich Salz
* Robert Sayre
* Brian Carpenter
9. References
9.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/rfc/rfc2026>.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
September 1998, <https://www.rfc-editor.org/rfc/rfc2418>.
Eggert & Lear Expires 5 December 2025 [Page 11]
Internet-Draft IETF Community Moderation June 2025
[RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF
Mailing Lists", BCP 83, RFC 3683, DOI 10.17487/RFC3683,
March 2004, <https://www.rfc-editor.org/rfc/rfc3683>.
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
<https://www.rfc-editor.org/rfc/rfc3935>.
[RFC7154] Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54,
RFC 7154, DOI 10.17487/RFC7154, March 2014,
<https://www.rfc-editor.org/rfc/rfc7154>.
[RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment
Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March
2016, <https://www.rfc-editor.org/rfc/rfc7776>.
[RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of
the IETF Administrative Support Activity, Version 2.0",
BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020,
<https://www.rfc-editor.org/rfc/rfc8711>.
[RFC9245] Eggert, L. and S. Harris, "IETF Discussion List Charter",
BCP 45, RFC 9245, DOI 10.17487/RFC9245, June 2022,
<https://www.rfc-editor.org/rfc/rfc9245>.
9.2. Informative References
[AHP] IESG, "IETF Anti-Harassment Policy", 3 November 2013,
<<https://www.ietf.org/about/groups/iesg/statements/anti-
harassment-policy/>>.
[DP] IESG, "IESG Statement on Disruptive Posting", 16 February
2006, <<https://www.ietf.org/about/groups/iesg/statements/
disruptive-posting/>>.
[I-D.perkins-irtf-code-of-conduct]
Perkins, C., "IRTF Code of Conduct", Work in Progress,
Internet-Draft, draft-perkins-irtf-code-of-conduct-08, 2
February 2025, <https://datatracker.ietf.org/doc/html/
draft-perkins-irtf-code-of-conduct-08>.
[MODML] IESG, "IESG Guidance on the Moderation of IETF Working
Group Mailing Lists", 29 August 2000,
<<https://www.ietf.org/about/groups/iesg/statements/
mailing-lists-moderation/>>.
[OT] "Ombudsteam",
<<https://www.ietf.org/contact/ombudsteam/>>.
Eggert & Lear Expires 5 December 2025 [Page 12]
Internet-Draft IETF Community Moderation June 2025
[RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014,
October 1996, <https://www.rfc-editor.org/rfc/rfc2014>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/rfc/rfc3552>.
[RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the
Management of IETF Mailing Lists", BCP 25, RFC 3934,
DOI 10.17487/RFC3934, October 2004,
<https://www.rfc-editor.org/rfc/rfc3934>.
Appendix A. Changes
| RFC Editor: Please remove this appendix before publication.
A.1. 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.2. 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.3. 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)
Eggert & Lear Expires 5 December 2025 [Page 13]
Internet-Draft IETF Community Moderation June 2025
A.4. 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.5. 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.6. 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. Problems with the Previous Approach
The previous approach to moderation of disruptive participation
through chairs, list administrators, and moderator teams, combined
with the IESG-led process of PR-actions, has proven to be less than
ideal:
Eggert & Lear Expires 5 December 2025 [Page 14]
Internet-Draft IETF Community Moderation June 2025
* The IETF community has not been able to agree on a common
definition of disruptive behavior. Therefore, chairs and list
administrators apply individually different criteria when making
decisions, and participants have different expectations for when
PR-actions are warranted.
* The moderation process that chairs and list administrators need to
follow [RFC3934] is slow and cumbersome, which makes it ill-suited
to situations that escalate quickly. It also assumes that the
originator of disruptive behavior is a misguided participant who
can be reasoned with and who will change their ways.
* Chairs and list administrators may only enact moderation actions
for their single list, which is ill-suited when a pattern of
disruptive behavior spans multiple lists. Also, chairs and list
administrators may not be fully aware of disruptive behavior that
spans multiple lists, due to not being subscribed to some of them.
* PR-actions, which can address disruptive behavior across several
lists, are cumbersome and slow, and the community has not been
able to agree on a common definition of disruptive behavior. This
has led to a situation where PR-actions are rarely used, and when
they are used, they are perceived as very heavy-handed.
* For a given mailing list, participants may not feel comfortable
reporting disruptive behavior to a chair or list administrator,
for various reasons. For mailing lists not associated with
working groups, list administrators are not even publicly
identified - they can only be contacted through an anonymous alias
address. This exacerbates the problem, because participants may
not be comfortable reporting disruptive behavior to an anonymous
party.
* The IETF offers participation not only through in-person meetings
and mailing lists, which are the two channels of participation for
which moderation processes are currently defined. IETF business
also happens in chat channels, remote meeting participation
systems, virtual meetings, wikis, GitHub repositories, and more.
How disruptive behavior is moderated in these channels is
currently undefined.
Appendix C. Non-Normative Examples of Disruptive Behavior
The list below describes some types of disruptive behavior, but it is
non-exhaustive.
* unsolicited bulk e-mail;
Eggert & Lear Expires 5 December 2025 [Page 15]
Internet-Draft IETF Community Moderation June 2025
* discussion of subjects unrelated to IETF policy, meetings,
activities, or technical concerns;
* uncivil commentary, regardless of the general subject;
* announcements of conferences, events, or activities that are not
sponsored or endorsed by the Internet Society or IETF;
* 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 just examples. The moderator team's task consists of
subjective judgement calls. Behaviors not listed here might require
moderation, and it is not possible to write a complete list of all
such behaviors.
Authors' Addresses
Lars Eggert (editor)
Mozilla
Stenbergintie 12 B
FI-02700 Kauniainen
Finland
Email: lars@eggert.org
URI: <https://eggert.org/>
Eliot Lear (editor)
Cisco Systems
Richtistrasse 7
CH-8304 Wallisellen
Switzerland
Phone: +41 44 878 9200
Email: lear@lear.ch
Eggert & Lear Expires 5 December 2025 [Page 16]