



Network Working Group                                     L. Eggert, Ed.
Internet-Draft                                                   Mozilla
Obsoletes: 3683, 3934 (if approved)                         E. Lear, Ed.
Updates: 2418, 9245 (if approved)                          Cisco Systems
Intended status: Best Current Practice                      29 July 2025
Expires: 30 January 2026


                       IETF Community Moderation
                  draft-ietf-modpod-group-processes-09

Abstract

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

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

About This Document

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

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

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

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

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.







Eggert & Lear            Expires 30 January 2026                [Page 1]

Internet-Draft          IETF Community Moderation              July 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 30 January 2026.

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  . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  General Philosophy  . . . . . . . . . . . . . . . . . . .   4
     1.3.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  IETF Moderator Team . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Composition . . . . . . . . . . . . . . . . . . . . . . .   6
       2.1.1.  Team Diversity  . . . . . . . . . . . . . . . . . . .   6
     2.2.  Training  . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Scope and Responsibilities  . . . . . . . . . . . . . . . . .   7
     3.1.  Out of Scope: Non-IETF Fora, Private Communications, and
           Content Removal . . . . . . . . . . . . . . . . . . . . .   8
   4.  Moderation Procedures and Transparency  . . . . . . . . . . .   8
     4.1.  Consistency and Conflict Resolution . . . . . . . . . . .   9
     4.2.  Reinstatement . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Relationship to other IETF functions  . . . . . . . . . . . .  10
     5.1.  Relation to the Ombudsteam  . . . . . . . . . . . . . . .  10
     5.2.  Relation to the IETF LLC  . . . . . . . . . . . . . . . .  10
     5.3.  Relation to the IRTF  . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11



Eggert & Lear            Expires 30 January 2026                [Page 2]

Internet-Draft          IETF Community Moderation              July 2025


   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Appendix A.  Changes  . . . . . . . . . . . . . . . . . . . . . .  14
     A.1.  Since draft-ietf-modpod-group-processes-08  . . . . . . .  14
     A.2.  Since draft-ietf-modpod-group-processes-07  . . . . . . .  14
     A.3.  Since draft-ietf-modmod-group-processes-06  . . . . . . .  14
     A.4.  Since draft-ietf-modpod-group-processes-05  . . . . . . .  14
     A.5.  Since draft-ietf-modpod-group-processes-04  . . . . . . .  15
     A.6.  Since draft-ietf-modpod-group-processes-03  . . . . . . .  15
     A.7.  Since draft-ietf-modpod-group-processes-02  . . . . . . .  15
     A.8.  Since draft-ietf-modpod-group-processes-01  . . . . . . .  15
     A.9.  Since draft-ietf-modpod-group-processes-00  . . . . . . .  15
     A.10. Since draft-ecahc-moderation-01 . . . . . . . . . . . . .  16
   Appendix B.  Problems with the Previous Approach  . . . . . . . .  16
   Appendix C.  Non-Normative Examples of Disruptive Behavior  . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

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

   This memo makes the following changes:

   *  Obsoletes [RFC3683] as the "posting rights" (PR) action it defines
      are replaced by procedures defined herein;

   *  Obsoletes[RFC3934] as it replaces working group moderation
      procedures;

   *  Obsoletes Section 3 of [RFC9245] and the second paragraph of
      Section 4 of [RFC9245], as the moderator team replaces the IETF
      discussion list moderation team.

   *  Updates Section 6.1 of [RFC2418], because the moderator team will
      now work together with working group chairs to moderate disruptive
      behavior.

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







Eggert & Lear            Expires 30 January 2026                [Page 3]

Internet-Draft          IETF Community Moderation              July 2025


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.  [RFC2418] tasks the chairs of each IETF working
   group with moderating their group's in-person meetings while
   [RFC3934] provided chairs a procedure to help manage mailing lists.
   An IESG statement [MODML] described additional guidance to working
   group chairs about how — but not when — to moderate their lists.

   For IETF mailing lists not associated with a working group, another
   IESG statement [DP] clarifies that the IESG tasks list administrators
   with moderation.  And the IETF list for general discussions has,
   mostly for historic reasons, a team of moderators that are not list
   administrators and operate by a different set of processes [RFC9245].

   Note that the term "moderation" can refer both to _preemptive_
   moderation, where 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].





Eggert & Lear            Expires 30 January 2026                [Page 4]

Internet-Draft          IETF Community Moderation              July 2025


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

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

   The moderation policy goals are as follows:

   *  Apply consistent, fair, and timely moderation of communication
      across all public IETF participation channels and participation
      fora; without regard to one's position or previous contributions;

   *  Appeals are available to address disagreements about moderation
      actions;

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

   *  Allow moderation decisions to be reconsidered; and

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

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

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

1.3.  Terminology

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




Eggert & Lear            Expires 30 January 2026                [Page 5]

Internet-Draft          IETF Community Moderation              July 2025


2.  IETF Moderator Team

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

2.1.  Composition

   The moderator team 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.

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



Eggert & Lear            Expires 30 January 2026                [Page 6]

Internet-Draft          IETF Community Moderation              July 2025


3.  Scope and Responsibilities

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

   Different people have different responsibilities.

   *Participants* should always behave in a manner discussed in
   Section 1.2.  They are also encouraged to report inappropriate
   behavior directed at them or someone else to an administrator of the
   respective forum *and* the moderators.

   *Administrators* are primarily responsible for managing their fora in
   accordance with guidance developed by the moderators and approved by
   the IESG.  As such, they shall address reports of inappropriate
   behavior in a timely fashion, apprising moderators of their
   disposition.  For a Working Group, the chairs should perform
   moderation in a way that obviates the need for moderator team
   involvement.

   *Moderators* are responsible for establishing processes to address
   moderation needs across all IETF fora, both present and future.  They
   are a resource that the community can use to address problematic
   contributions.

   Moderators may take actions when administrators do not respond to
   reports in a timely fashion.  Their first action should generally be
   to attempt to contact and advise the relevant administrators.  They
   should only take moderation actions when administrators are not
   responsive.  In particular, moderators should give WG chairs every
   opportunity to manage what may be difficult and contentious debates
   within their groups.  Within the bounds of this principle, it is left
   to moderators' judgement to determine when they must act.
   Section 4.1 discusses the handling of disagreements.

   Moderators are administrators for IETF plenary fora, currently
   including the IETF discussion and last-call lists, attendee lists,
   and any plenary chat sessions.  They are also administrators for any
   forum that cuts across IETF areas or does not have an administrator.

   In order to scale the function, except for plenary fora as described
   above, moderators are not expected to always actively monitor all
   communications.  Instead, they will process reports from
   participants.





Eggert & Lear            Expires 30 January 2026                [Page 7]

Internet-Draft          IETF Community Moderation              July 2025


   *Area Directors* are expected to resolve conflicts as described here
   and in Section 4.1.  The IESG is responsible for appointing and
   overseeing the moderator team, and approving guidance provided by
   that team.

3.1.  Out of Scope: Non-IETF Fora, Private Communications, and Content
      Removal

   It is important to note that the moderator team only moderates
   _public_ IETF fora.  Their mandate does not extend to problematic
   behavior in private communication, such as private chat groups,
   direct messages, or conversations or other interactions outside of
   meetings.  In such cases, the Ombudsteam should be approached.

   Content removal or redaction from IETF archives are not moderation
   actions, and are therefore also beyond the scope of this memo.

4.  Moderation Procedures and Transparency

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

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

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

   *  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.  Administrators and moderators are 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.




Eggert & Lear            Expires 30 January 2026                [Page 8]

Internet-Draft          IETF Community Moderation              July 2025


   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 moderation actions that restrict posting rights shall be
   periodically reported to the IESG, as well as immediately to those
   against whom those actions take effect.

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

4.1.  Consistency and Conflict Resolution

   Administrators and moderators shall act in a manner consistent with
   guidelines approved by the IESG.  In cases of disagreement between
   the administrators and the moderator team over a moderation decision,
   the matter should be taken up with the responsible area director for
   resolution, or the IETF chair if a responsible area director cannot
   be determined or is not assigned.

   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 whose participation
   rights have been suspended from a forum may request reinstatement.
   Requests for reinstatement may be made only a year after the initial
   decision, and then only annually afterwards.

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






Eggert & Lear            Expires 30 January 2026                [Page 9]

Internet-Draft          IETF Community Moderation              July 2025


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

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

5.  Relationship to other IETF functions

5.1.  Relation to the Ombudsteam

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

5.2.  Relation to the IETF LLC

   The Board of Directors of the IETF Administration LLC (IETF LLC) has
   fiduciary duty for the overall organization, which includes the duty
   to protect the organization from serious legal risk that may arise
   from the behavior of IETF participants.

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

   *  Someone making 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.

   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.




Eggert & Lear            Expires 30 January 2026               [Page 10]

Internet-Draft          IETF Community Moderation              July 2025


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

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

5.3.  Relation to the IRTF

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

6.  Security Considerations

   The usual security considerations [RFC3552] do not apply to this
   document.

   Potential abuse of the moderation process for the suppression of
   undesired opinions is counteracted by the availability of an appeals
   process, per Section 4.1.

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

7.  IANA Considerations

   No IANA actions are requested.

8.  Acknowledgments

   This memo is based on two individual Internet-Drafts, draft-ecahc-
   moderation (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.  Robert Sayre authored draft-sayre-modpod-excellent
   (https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/),
   which also originated ideas reflected in this work.  Pete Resnick
   provided the basis for how the moderators interact with list/forum
   leadership.




Eggert & Lear            Expires 30 January 2026               [Page 11]

Internet-Draft          IETF Community Moderation              July 2025


   These individuals contributed additional improvements:

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

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

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

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





Eggert & Lear            Expires 30 January 2026               [Page 12]

Internet-Draft          IETF Community Moderation              July 2025


   [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/>>.

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







Eggert & Lear            Expires 30 January 2026               [Page 13]

Internet-Draft          IETF Community Moderation              July 2025


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

Appendix A.  Changes

      |  RFC Editor: Please remove this appendix before publication.

A.1.  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.2.  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.3.  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.4.  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)







Eggert & Lear            Expires 30 January 2026               [Page 14]

Internet-Draft          IETF Community Moderation              July 2025


A.5.  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.6.  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.7.  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.8.  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.9.  Since draft-ietf-modpod-group-processes-00

   *  Spelling fix (https://github.com/larseggert/draft-ietf-modpod-
      group-processes/pull/80)





Eggert & Lear            Expires 30 January 2026               [Page 15]

Internet-Draft          IETF Community Moderation              July 2025


   *  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.10.  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:

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



Eggert & Lear            Expires 30 January 2026               [Page 16]

Internet-Draft          IETF Community Moderation              July 2025


   *  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 groups, remote meeting participation systems,
      virtual meetings, wikis, GitHub repositories, and more.  How
      disruptive behavior is moderated in these fora 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;

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



Eggert & Lear            Expires 30 January 2026               [Page 17]

Internet-Draft          IETF Community Moderation              July 2025


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 30 January 2026               [Page 18]
