



Internet Engineering Task Force (IETF)                    L. Eggert, Ed.
Request for Comments: 9945                                       Mozilla
BCP: 245                                                    E. Lear, Ed.
Obsoletes: 3683, 3934                                      Cisco Systems
Updates: 2418, 9245                                        February 2026
Category: Best Current Practice                                         
ISSN: 2070-1721


                       IETF Community Moderation

Abstract

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

   This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and
   9245 by establishing a policy for the moderation of disruptive
   participation across the IETF's various public contribution channels
   and discussion fora.  It establishes guardrails for moderation and a
   moderator team.  That team will develop a set of moderation
   procedures and facilitate their consistent implementation with chairs
   and administrators.

Status of This Memo

   This memo documents an Internet Best Current Practice.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   BCPs is available in Section 2 of RFC 7841.

   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 (c) 2026 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
     1.1.  Terminology Note
     1.2.  General Philosophy
   2.  IETF Moderator Team
     2.1.  Composition
       2.1.1.  Team Diversity
     2.2.  Training
   3.  Scope and Responsibilities
     3.1.  Actions That Are Out of Scope
     3.2.  Unsolicited Bulk Messages
   4.  Moderation Procedures and Transparency
     4.1.  Consistency and Conflict Resolution
     4.2.  Reinstatement
   5.  Relationship to Other IETF Functions
     5.1.  Relation to the Ombudsteam
     5.2.  Relation to the IETF LLC
   6.  Security Considerations
   7.  IANA Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Appendix A.  Motivation
     A.1.  Background
     A.2.  Problems with the Previous Approach
   Appendix B.  Non-Normative Examples of Disruptive Behavior
   Acknowledgments
   Authors' Addresses

1.  Introduction

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

   This memo obsoletes and updates some prior IETF processes, summarized
   here.  Background information is described in more detail in
   Appendix A.

   This memo makes the following changes to existing processes:

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

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

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

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

   The processes described in this memo are solely applicable to IETF
   activities, and not to other related organizations, such as the
   Internet Research Task Force (IRTF), the Internet Architecture Board
   (IAB), the RFC Series Working Group (RSWG), the RFC Series Approval
   Board (RSAB), or the Independent RFC Submission Stream, without their
   explicit agreement.  These changes take effect when the procedures
   described in Section 4 have been approved by the IESG.

1.1.  Terminology Note

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

1.2.  General Philosophy

   The cornerstone of this policy is that individuals are responsible
   for furthering the goals of the IETF as an organization [RFC3935] in
   a manner consistent with the policy laid out in [RFC7154].

   Disagreement and diverse points of view within any standards
   organization are to be expected and are even healthy.  The IETF is an
   open standards organization with a discussion-based rough consensus
   process, a non-normative description of which is in [RFC7282].
   Engaged, respectful discussion that is within the scope of an IETF
   forum should therefore not be considered disruptive, nor should
   someone be considered disruptive solely because they are outside the
   rough consensus.  However, when someone crosses the line into
   disruptive behavior, 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 online IETF participation channels and
      participation fora without regard to a participant's role in the
      IETF or previous technical contributions;

   *  Ensure that appeals are available to address disagreements about
      moderation actions;

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

   *  Allow moderation decisions to be reconsidered; and

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

   Questions about the processes detailed below should be answered with
   these goals in mind.

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

2.  IETF Moderator Team

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

2.1.  Composition

   The IESG appoints and recalls moderators.  The moderator team
   initially consists of no fewer than five individuals.  The moderator
   team may expand or contract based on operational experience.  In
   selecting members, the IESG will take into account geographic
   coverage, expected and unexpected absences, and team diversity.

   Because the IESG and IAB are in the appeals chain for moderator team
   decisions (see 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 IETF LLC Board, as well as IETF LLC staff and contractors
   shall also be excluded from serving on the moderator team.  If a
   moderator assumes 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 also improves the likelihood that any participant
   experiencing or observing disruptive behavior can identify a
   moderator they feel comfortable contacting.

2.2.  Training

   The IETF is committed to providing and/or funding training for
   administrators and moderators as necessary.  The IESG will negotiate
   any required funding or resources with IETF Administration LLC
   [RFC8711].

3.  Scope and Responsibilities

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

   Different people have different moderation responsibilities:

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

   *  *Administrators* are primarily responsible for managing their fora
      in accordance with procedures developed by the moderators and
      approved by the IESG.  As such, they shall address reports of
      disruptive behavior in a timely fashion, apprising moderators of
      reports or actions taken.  Administrators may amend or rescind
      actions, including those taken by members of the moderator team
      *after* they have consulted with that team.

      For a working group, chairs are by default the administrators.
      They may delegate this responsibility in the same vein as
      Section 6.4 of [RFC2418], but they must always accept,
      acknowledge, and keep track of complaints of disruptive behavior.
      Forum administrators should perform moderation in a way that
      obviates the need for moderator team involvement.

   *  *Moderators* are responsible for establishing procedures to
      address moderation needs across all IETF fora, both present and
      future.  They are a resource that the community can use to address
      disruptive behavior.  The moderator team is responsible to the
      IESG.  The IESG will create or designate a forum to facilitate
      discussion about moderation and refer interested parties to that
      forum.

      Moderators may take actions when administrators do not respond to
      reports in a timely fashion.  Their first action should generally
      be to attempt to contact and advise the relevant administrators.
      They should only take moderation actions when administrators are
      not responsive or when someone disrupts multiple fora at the same
      time.  Moderators should generally give WG chairs the opportunity
      to manage what may be difficult and contentious debates within
      their groups.  Within the bounds of this principle, it is left to
      moderators' judgment to determine when they must act, with the
      understanding that some situations may require fast responses.
      Moderators must notify administrators of any actions they take.
      Section 4.1 discusses the handling of disagreements.

      Moderators are administrators for IETF plenary fora, currently
      including the IETF discussion and Last Call lists and any plenary
      chat sessions.  They are also administrators for any forum that
      does not otherwise have an administrator.

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

   *  *Area directors* are expected to resolve conflicts as described
      here and in Section 4.1.  The IESG will periodically evaluate the
      performance and needs of moderators, and may appoint and recall
      moderators as they deem appropriate.  Apart from that, the IESG
      shall refrain from the day-to-day operation and management of the
      moderator team.  The moderators may consult with the IESG when
      needed.

3.1.  Actions That Are Out of Scope

   Moderator actions are only permitted for the purposes of limiting
   disruptive communications in online IETF fora.  All other actions are
   beyond the scope of this memo.  Examples of actions that are out of
   scope include, but are not limited to, Datatracker account removal;
   restriction of in-person, virtual, or hybrid meeting participation;
   content removal or redaction; and moderation or policing of private
   or non-IETF communications.  While the moderator team does not
   moderate non-public IETF mailing lists, the administrators of such
   lists can choose to adopt some of the procedures that the moderator
   team develops.

3.2.  Unsolicited Bulk Messages

   Unsolicited bulk messages are considered disruptive and should be
   handled in a manner consistent with the "IESG Statement on Spam
   Control on IETF Mailing Lists" [IESG-SPAM] or its successors.
   Administrators and moderators may take similar actions in other fora
   (e.g., GitHub or instant messaging).  Such actions require no
   additional reporting.

4.  Moderation Procedures and Transparency

   Within the bounds of the policies set herein, the moderator team
   shall develop and maintain procedures and criteria relating to
   moderation, including the moderator team's own operating procedures.

   Those procedures and criteria shall be developed with community
   input, be approved by the IESG prior to going into effect, and be
   made public.  However, they need not be documented in the RFC Series.
   This shall be the first task for the moderator team.  Until those
   procedures and criteria are established, all previous processes
   referenced in Section 1 shall remain in effect.

   The intent of this memo is to provide the widest possible freedom of
   action to administrators and moderators, with the expectation that
   the minimal actions necessary will be taken.  Those who are directed
   to stop disrupting a forum must do so immediately.  Further
   disruptions may lead to further corrective actions.

   Examples of actions that could be taken include:

   *  Automated rate-limiting mechanisms;

   *  Review and approval of submissions/messages;

   *  A private or public admonishment;

   *  Temporary or indefinite suspension of participation privileges in
      one or more fora.

   These are only examples and are not in any way prescriptive.
   Administrators and moderators are free to decide on these or other
   actions.

   All moderation actions that restrict participation privileges shall
   be immediately reported to those against whom those actions take
   effect, to relevant administrators, and to the moderator team for
   their review.  They shall also be periodically reported to the IESG.

   Only moderation actions suspending participation privileges for
   longer than fourteen (14) days must be reported to the forum to which
   such an action applies, or in any event, at the request of the
   suspended person.  If such an action applies to more than one forum,
   it should be communicated to the community in a manner decided by the
   IESG.

   Moderators will periodically provide an aggregate report to the
   community on actions taken under this policy.

4.1.  Consistency and Conflict Resolution

   Administrators and moderators shall act in a manner consistent with
   this memo and the guidelines approved by the IESG.  In cases of
   disagreement over a moderation decision, anyone may take the matter
   up with the responsible area director for resolution, or with the
   IETF Chair if a responsible area director cannot be determined or is
   not assigned.  If the disagreement cannot be resolved by the area
   director, that person may then appeal to the IESG and subsequently to
   the IAB using the processes stated in Sections 6.5.1 and 6.5.4 of
   [RFC2026].

4.2.  Reinstatement

   People and circumstances change.  Individuals whose participation
   privileges have been indefinitely suspended from a forum may request
   reinstatement.  Requests for reinstatement may be made no earlier
   than a year after the initial decision and then only annually
   afterward.

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

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

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

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 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 will be extremely rare in
   frequency.  Some examples of where this might be necessary are:

   *  Someone making a credible threat of harm to other IETF
      participants.

   *  Someone using IETF mailing lists and/or websites to share content
      where publishing that content on IETF lists and/or websites brings
      serious legal risk to the IETF.

   *  Someone making a credible threat of legal action where any form of
      interaction with them on IETF mailing lists may have serious legal
      consequences for the IETF.

   If any such action is taken, the IETF LLC should, except where
   limited by legal advice to the contrary, inform the IESG as soon as
   possible, providing full details of the subject of the action, nature
   of the action, reason for the action, and the expected duration.  The
   IETF LLC should also inform the moderator team and IETF community,
   except where it receives legal advice to the contrary.

   As such an action would be taken by the IETF LLC in order to protect
   the IETF according to its fiduciary duty, then it cannot allow that
   to be overridden by a decision of the moderator team or the IESG.
   The subject of any such action may request a review by the IETF 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.

6.  Security Considerations

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

   There is the potential abuse of the moderation procedures by
   moderators, working group chairs, and potentially others that could
   lead to censorship of legitimate participation.  This potential risk
   is mitigated in eight ways:

   1.  Section 4 requires the moderator team to first establish
       procedures that are intended to apply uniformly across the IETF.

   2.  Section 1.2 explicitly states that viewpoints outside the rough
       consensus are not in and of themselves disruptive.

   3.  Section 4 provides transparency by requiring that moderation
       actions that restrict participation privileges be immediately
       reported to the affected person and to the moderator team, and
       periodically reported to the IESG.

   4.  Section 4 also requires that the community be informed in the
       case of suspensions lasting longer than 14 days.

   5.  Section 4.1 lays out an appeals process in the case of
       disagreements.

   6.  If moderators find that the procedures themselves are leading to
       inappropriate moderation, Section 4 allows them to update those
       procedures in consultation with the community and with the
       approval of the IESG.

   7.  If IETF participants believe that either the IESG or the IAB are
       not performing their respective oversight functions as described
       in this document, they may comment to the NomCom [BCP10] or the
       community at large.

   8.  Finally, if it appears that these processes are not functioning
       properly, the policies stated in this memo may be amended.  They
       are not set in stone.

   Moderation actions are intended to limit the likelihood of disruptive
   behavior by a few IETF participants that may discourage participation
   by other IETF participants.

7.  IANA Considerations

   This document has no IANA actions.

8.  References

8.1.  Normative References

   [BCP10]    Best Current Practice 10,
              <https://www.rfc-editor.org/info/bcp10>.
              At the time of writing, this BCP comprises the following:

              Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
              Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection,
              Confirmation, and Recall Process: Operation of the IETF
              Nominating and Recall Committees", BCP 10, RFC 8713,
              DOI 10.17487/RFC8713, February 2020,
              <https://www.rfc-editor.org/info/rfc8713>.

              Duke, M., "Nominating Committee Eligibility", BCP 10,
              RFC 9389, DOI 10.17487/RFC9389, April 2023,
              <https://www.rfc-editor.org/info/rfc9389>.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <https://www.rfc-editor.org/info/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/info/rfc2418>.

   [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF",
              BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
              <https://www.rfc-editor.org/info/rfc3935>.

   [RFC7154]  Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54,
              RFC 7154, DOI 10.17487/RFC7154, March 2014,
              <https://www.rfc-editor.org/info/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/info/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/info/rfc8711>.

8.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", 17 February
              2006, <https://www.ietf.org/about/groups/iesg/statements/
              disruptive-posting/>.

   [IESG-SPAM]
              IESG, "IESG Statement on Spam Control on IETF Mailing
              Lists", 14 April 2008, <https://datatracker.ietf.org/doc/
              statement-iesg-iesg-statement-on-spam-control-on-ietf-
              mailing-lists-20080414/>.

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

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

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

   [RFC7282]  Resnick, P., "On Consensus and Humming in the IETF",
              RFC 7282, DOI 10.17487/RFC7282, June 2014,
              <https://www.rfc-editor.org/info/rfc7282>.

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

Appendix A.  Motivation

   Section 1 summarizes the process changes introduced by this memo.
   This appendix discusses the background that led to them.

A.1.  Background

   The IETF community has defined general guidelines for personal
   interactions in the IETF [RFC7154].  The IESG has defined an anti-
   harassment policy for the IETF [AHP] for which the IETF community has
   defined anti-harassment procedures [RFC7776], empowering 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] provides chairs a procedure to help manage mailing lists.
   An IESG statement [MODML] describes additional guidance to working
   group chairs about how -- but not when -- to moderate their lists.

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

   Note that the term "moderation" can refer both to _preemptive_
   moderation, where administrators review attempted participation
   before it occurs (such as reviewing messages to a mailing list), and
   _reactive_ moderation, where administrators intervene after
   disruptive participation has occurred.  Historically, the IETF has
   mainly practiced reactive moderation, employing actions ranging from
   gentle reminders on- and off-list, all the way to suspension of
   posting rights and other ways of participating or communicating.  It
   is up to the moderators and administrators to decide which mix of
   preemptive and reactive moderation to employ as part of their
   procedures.

   In addition, [RFC3683] defines a process for revoking an individual's
   posting rights to IETF mailing lists following a 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.

A.2.  Problems with the Previous Approach

   The previous approach to moderation of disruptive participation
   through chairs, list administrators, and moderator teams, combined
   with the IESG-led process of PR-actions, has proven to be less than
   ideal:

   *  The IETF community has not been able to agree on a common
      definition of disruptive behavior.  Therefore, chairs and list
      administrators apply individually different criteria when making
      decisions, and participants have different expectations for when
      PR-actions are warranted.

   *  The moderation process that chairs and list administrators need to
      follow [RFC3934] is slow and cumbersome, which makes it ill-suited
      to situations that escalate quickly.  It also assumes that the
      originator of disruptive behavior is a misguided participant who
      can be reasoned with and who will change their ways.

   *  Chairs and list administrators may only enact moderation actions
      for their single list, which is ill-suited when a pattern of
      disruptive behavior spans multiple lists.  Also, chairs and list
      administrators may not be fully aware of disruptive behavior that
      spans multiple lists, due to not being subscribed to some of them.

   *  PR-actions, which can address disruptive behavior across several
      lists, are cumbersome, slow, and inconsistent.  This has led to a
      situation where PR-actions are rarely used, and when they are
      used, they are perceived as very heavy-handed.

   *  For a given mailing list, participants may not feel comfortable
      reporting disruptive behavior to a chair or list administrator,
      for various reasons.  For mailing lists not associated with
      working groups, list administrators are not even publicly
      identified -- they can only be contacted through an anonymous
      alias address.  This exacerbates the problem, because participants
      may not be comfortable reporting disruptive behavior to an
      anonymous party.

   *  Moderation processes have been defined for only two channels of
      participation in the IETF: in-person meetings and mailing lists.
      However, IETF business now happens in a number of fora (e.g., chat
      groups, remote meeting participation systems, virtual meetings,
      wikis, and GitHub repositories).  Procedures for moderating
      disruptive behavior in these fora are currently undefined.

Appendix B.  Non-Normative Examples of Disruptive Behavior

   The list below describes some types of disruptive behavior, but it is
   non-exhaustive.

   *  Discussion of subjects unrelated to a forum's charter or scope;

   *  Uncivil commentary, regardless of the general subject;

   *  Messages announcing conferences, events, or activities that are
      not sponsored or endorsed by the Internet Society or IETF, unless
      posted with prior approval of list administrators;

   *  Repeatedly arguing counter to a WG charter that has been approved
      by the IESG; and

   *  "Sealioning", where a participant makes incessant requests for
      evidence or data, even while remaining superficially polite.

   These items are examples.  Moderators and administrators may take
   moderation actions for many other cases.

   The moderator team's task consists of subjective judgment calls.
   Behaviors not listed here might require moderation, and it is not
   possible to write a complete list of all such behaviors.

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.

   These individuals contributed additional improvements:

   *  Alissa Cooper

   *  Brian Carpenter

   *  Chris Box

   *  Colin Perkins

   *  David Schinazi

   *  Deb Cooley

   *  Dhruv Dhody

   *  Eric Rescorla

   *  Éric Vyncke

   *  Erik Kline

   *  Harald Alvestrand

   *  Jay Daley

   *  Joel Halpern

   *  John Klensin

   *  John Scudder

   *  Lisa Dusseault

   *  Martin Thomson

   *  Melinda Shore

   *  Michael Richardson

   *  Mike Bishop

   *  Mohamed Boucadair

   *  Murray Kucherawy

   *  Nick Hilliard

   *  Orie Steele

   *  Paul Hoffman

   *  Paul Wouters

   *  Pete Resnick

   *  Rich Salz

   *  Robert Sayre

   *  Robert Sparks

   *  Roman Danyliw

   *  Russ Housley

   *  Sean Turner

   *  Simon Josefsson

   *  Stephen Farrell

   *  Ted Lemon

   *  Tim Bray

   N.B., acknowledgment should not be taken as endorsement by the
   individuals named above.

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
