<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-modpod-group-processes-16" category="bcp" consensus="true" submissionType="IETF" xml:lang="en" number="9945" obsoletes="3683, 3934" updates="2418, 9245" tocInclude="true" sortRefs="true" symRefs="true" prepTime="2026-02-27T14:09:20" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://dx.doi.org/10.17487/rfc9945" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <link href="https://datatracker.ietf.org/doc/draft-ietf-modpod-group-processes-latest" rel="prev"/>
  <front>
    <title abbrev="IETF Community Moderation">IETF Community Moderation</title>
    <seriesInfo name="RFC" value="9945" stream="IETF"/>
    <seriesInfo name="BCP" value="245" stream="IETF"/>
    <author initials="L." surname="Eggert" fullname="Lars Eggert" role="editor">
      <organization showOnFrontPage="true">Mozilla</organization>
      <address>
        <postal>
          <street>Stenbergintie 12 B</street>
          <city>Kauniainen</city>
          <code>02700</code>
          <country>FI</country>
        </postal>
        <email>lars@eggert.org</email>
        <uri>https://eggert.org/</uri>
      </address>
    </author>
    <author initials="E." surname="Lear" fullname="Eliot Lear" role="editor">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <postal>
          <street>Richtistrasse 7</street>
          <city>Wallisellen</city>
          <code>8304</code>
          <country>Switzerland</country>
        </postal>
        <phone>+41 44 878 9200</phone>
        <email>lear@lear.ch</email>
      </address>
    </author>
    <date month="02" year="2026"/>
    <area>GEN</area>
    <workgroup>modpod</workgroup>
    <keyword>disruption</keyword>
    <keyword>moderation</keyword>
    <keyword>participation</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">The IETF community will treat people with kindness and grace, but not endless patience.</t>
      <t indent="0" pn="section-abstract-2">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.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This memo documents an Internet Best Current Practice.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9945" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2026 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology-note">Terminology Note</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-philosophy">General Philosophy</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ietf-moderator-team">IETF Moderator Team</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-composition">Composition</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.1.2">
                  <li pn="section-toc.1-1.2.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.2.2.1.2.1.1"><xref derivedContent="2.1.1" format="counter" sectionFormat="of" target="section-2.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-team-diversity">Team Diversity</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-training">Training</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scope-and-responsibilities">Scope and Responsibilities</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-actions-that-are-out-of-sco">Actions That Are Out of Scope</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-unsolicited-bulk-messages">Unsolicited Bulk Messages</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-moderation-procedures-and-t">Moderation Procedures and Transparency</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-consistency-and-conflict-re">Consistency and Conflict Resolution</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reinstatement">Reinstatement</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-relationship-to-other-ietf-">Relationship to Other IETF Functions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-relation-to-the-ombudsteam">Relation to the Ombudsteam</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-relation-to-the-ietf-llc">Relation to the IETF LLC</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-motivation">Motivation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-background">Background</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-problems-with-the-previous-">Problems with the Previous Approach</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-non-normative-examples-of-d">Non-Normative Examples of Disruptive Behavior</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">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.</t>
      <t indent="0" pn="section-1-2">This memo obsoletes and updates some prior IETF processes, summarized here.
Background information is described in more detail in <xref target="motivation" format="default" sectionFormat="of" derivedContent="Appendix A"/>.</t>
      <t indent="0" pn="section-1-3">This memo makes the following changes to existing processes:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-4">
        <li pn="section-1-4.1">
          <t indent="0" pn="section-1-4.1.1">Obsoletes <xref target="RFC3683" format="default" sectionFormat="of" derivedContent="RFC3683"/> as the "posting rights" (PR) action it defines
is replaced by processes defined herein;</t>
        </li>
        <li pn="section-1-4.2">
          <t indent="0" pn="section-1-4.2.1">Obsoletes <xref target="RFC3934" format="default" sectionFormat="of" derivedContent="RFC3934"/> as it replaces working group moderation
procedures;</t>
        </li>
        <li pn="section-1-4.3">
          <t indent="0" pn="section-1-4.3.1">Obsoletes <xref section="3" sectionFormat="of" target="RFC9245" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9245#section-3" derivedContent="RFC9245"/> and the second paragraph of
<xref section="4" sectionFormat="of" target="RFC9245" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9245#section-4" derivedContent="RFC9245"/>, as the IETF moderator team defined in this document
replaces the IETF discussion list moderator team.</t>
        </li>
        <li pn="section-1-4.4">
          <t indent="0" pn="section-1-4.4.1">Updates <xref section="6.1" sectionFormat="of" target="RFC2418" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2418#section-6.1" derivedContent="RFC2418"/>, because the moderator team will
work together with working group chairs to moderate disruptive
behavior.</t>
        </li>
      </ul>
      <t indent="0" pn="section-1-5">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 <xref target="prod" format="default" sectionFormat="of" derivedContent="Section 4"/> have been approved by the IESG.</t>
      <section anchor="terminology-note" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-terminology-note">Terminology Note</name>
        <t indent="0" pn="section-1.1-1">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.</t>
      </section>
      <section anchor="genphil" numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-general-philosophy">General Philosophy</name>
        <t indent="0" pn="section-1.2-1">The cornerstone of this policy is that individuals are responsible for
furthering the goals of the IETF as an organization <xref target="RFC3935" format="default" sectionFormat="of" derivedContent="RFC3935"/>
in a manner consistent with the policy laid out in <xref target="RFC7154" format="default" sectionFormat="of" derivedContent="RFC7154"/>.</t>
        <t indent="0" pn="section-1.2-2">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 <xref target="RFC7282" format="default" sectionFormat="of" derivedContent="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.</t>
        <t indent="0" pn="section-1.2-3">The moderation policy goals are as follows:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.2-4">
          <li pn="section-1.2-4.1">
            <t indent="0" pn="section-1.2-4.1.1">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;</t>
          </li>
          <li pn="section-1.2-4.2">
            <t indent="0" pn="section-1.2-4.2.1">Ensure that appeals are available to address disagreements about moderation actions;</t>
          </li>
          <li pn="section-1.2-4.3">
            <t indent="0" pn="section-1.2-4.3.1">Balance transparency against both privacy of individuals involved and further
disruption to the community;</t>
          </li>
          <li pn="section-1.2-4.4">
            <t indent="0" pn="section-1.2-4.4.1">Allow moderation decisions to be reconsidered; and</t>
          </li>
          <li pn="section-1.2-4.5">
            <t indent="0" pn="section-1.2-4.5.1">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.</t>
          </li>
        </ul>
        <t indent="0" pn="section-1.2-5">Questions about the processes detailed below should be answered with these
goals in mind.</t>
        <t indent="0" pn="section-1.2-6">The objective is explicitly <strong>not</strong> 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.</t>
      </section>
    </section>
    <section anchor="ietf-moderator-team" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-ietf-moderator-team">IETF Moderator Team</name>
      <t indent="0" pn="section-2-1">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 <xref target="motive" format="default" sectionFormat="of" derivedContent="Appendix A.2"/>) and the principles described in the
introduction.</t>
      <section anchor="composition" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-composition">Composition</name>
        <t indent="0" pn="section-2.1-1">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.</t>
        <t indent="0" pn="section-2.1-2">Because the IESG and IAB are in the appeals chain for moderator team
decisions (see <xref target="appeals" format="default" sectionFormat="of" derivedContent="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.</t>
        <section anchor="team-diversity" numbered="true" removeInRFC="false" toc="include" pn="section-2.1.1">
          <name slugifiedName="name-team-diversity">Team Diversity</name>
          <t indent="0" pn="section-2.1.1-1">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.</t>
          <t indent="0" pn="section-2.1.1-2">Team diversity also improves the likelihood that any participant experiencing
or observing disruptive behavior can identify a moderator they feel comfortable
contacting.</t>
        </section>
      </section>
      <section anchor="training" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-training">Training</name>
        <t indent="0" pn="section-2.2-1">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 <xref target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>.</t>
      </section>
    </section>
    <section anchor="scope-and-responsibilities" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-scope-and-responsibilities">Scope and Responsibilities</name>
      <t indent="0" pn="section-3-1">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.</t>
      <t indent="0" pn="section-3-2">Different people have different moderation responsibilities:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-3">
        <li pn="section-3-3.1">
          <t indent="0" pn="section-3-3.1.1"><strong>Participants</strong> should always behave in the manner discussed in
<xref target="genphil" format="default" sectionFormat="of" derivedContent="Section 1.2"/>.  They are also encouraged to report disruptive behavior
directed at them or someone else to an administrator of the respective
forum <strong>and</strong> the moderators.</t>
        </li>
        <li pn="section-3-3.2">
          <t indent="0" pn="section-3-3.2.1"><strong>Administrators</strong> 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 <strong>after</strong> they have consulted with that team.  </t>
          <t indent="0" pn="section-3-3.2.2">
For a working group, chairs are by default the administrators.  They may
delegate this responsibility in the same vein as <xref section="6.4" sectionFormat="of" target="RFC2418" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2418#section-6.4" derivedContent="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.</t>
        </li>
        <li pn="section-3-3.3">
          <t indent="0" pn="section-3-3.3.1"><strong>Moderators</strong> 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.  </t>
          <t indent="0" pn="section-3-3.3.2">
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.
<xref target="appeals" format="default" sectionFormat="of" derivedContent="Section 4.1"/> discusses the handling of disagreements.  </t>
          <t indent="0" pn="section-3-3.3.3">
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.  </t>
          <t indent="0" pn="section-3-3.3.4">
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.</t>
        </li>
        <li pn="section-3-3.4">
          <t indent="0" pn="section-3-3.4.1"><strong>Area directors</strong> are expected to resolve conflicts as described here and
in <xref target="appeals" format="default" sectionFormat="of" derivedContent="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.</t>
        </li>
      </ul>
      <section anchor="actions-that-are-out-of-scope" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-actions-that-are-out-of-sco">Actions That Are Out of Scope</name>
        <t indent="0" pn="section-3.1-1">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.</t>
      </section>
      <section anchor="unsolicited-bulk-messages" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-unsolicited-bulk-messages">Unsolicited Bulk Messages</name>
        <t indent="0" pn="section-3.2-1">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" 
<xref target="IESG-SPAM" format="default" sectionFormat="of" derivedContent="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.</t>
      </section>
    </section>
    <section anchor="prod" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-moderation-procedures-and-t">Moderation Procedures and Transparency</name>
      <t indent="0" pn="section-4-1">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.</t>
      <t indent="0" pn="section-4-2">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 <xref target="introduction" format="default" sectionFormat="of" derivedContent="Section 1"/> shall remain in effect.</t>
      <t indent="0" pn="section-4-3">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.</t>
      <t indent="0" pn="section-4-4">Examples of actions that could be taken include:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-5">
        <li pn="section-4-5.1">
          <t indent="0" pn="section-4-5.1.1">Automated rate-limiting mechanisms;</t>
        </li>
        <li pn="section-4-5.2">
          <t indent="0" pn="section-4-5.2.1">Review and approval of submissions/messages;</t>
        </li>
        <li pn="section-4-5.3">
          <t indent="0" pn="section-4-5.3.1">A private or public admonishment;</t>
        </li>
        <li pn="section-4-5.4">
          <t indent="0" pn="section-4-5.4.1">Temporary or indefinite suspension of participation privileges
in one or more fora.</t>
        </li>
      </ul>
      <t indent="0" pn="section-4-6">These are only examples and are not in any way
prescriptive. Administrators and moderators are free to decide on
these or other actions.</t>
      <t indent="0" pn="section-4-7">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.</t>
      <t indent="0" pn="section-4-8">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.</t>
      <t indent="0" pn="section-4-9">Moderators will periodically provide an aggregate report to the community on
actions taken under this policy.</t>
      <section anchor="appeals" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-consistency-and-conflict-re">Consistency and Conflict Resolution</name>
        <t indent="0" pn="section-4.1-1">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 <xref target="RFC2026" section="6.5.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2026#section-6.5.1" derivedContent="RFC2026"/> and <xref target="RFC2026" section="6.5.4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2026#section-6.5.4" derivedContent="RFC2026"/> of <xref target="RFC2026" format="default" sectionFormat="of" derivedContent="RFC2026"/>.</t>
      </section>
      <section anchor="reinstatement" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-reinstatement">Reinstatement</name>
        <t indent="0" pn="section-4.2-1">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.</t>
        <t indent="0" pn="section-4.2-2">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.</t>
        <t indent="0" pn="section-4.2-3">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.</t>
        <t indent="0" pn="section-4.2-4">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.</t>
      </section>
    </section>
    <section anchor="relationship-to-other-ietf-functions" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-relationship-to-other-ietf-">Relationship to Other IETF Functions</name>
      <section anchor="relation-to-the-ombudsteam" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-relation-to-the-ombudsteam">Relation to the Ombudsteam</name>
        <t indent="0" pn="section-5.1-1">Administrators and moderators shall complement the efforts of the IETF
Ombudsteam <xref target="OT" format="default" sectionFormat="of" derivedContent="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.</t>
      </section>
      <section anchor="relation-to-the-ietf-llc" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-relation-to-the-ietf-llc">Relation to the IETF LLC</name>
        <t indent="0" pn="section-5.2-1">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.</t>
        <t indent="0" pn="section-5.2-2">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:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.2-3">
          <li pn="section-5.2-3.1">
            <t indent="0" pn="section-5.2-3.1.1">Someone making a credible threat of harm to other IETF participants.</t>
          </li>
          <li pn="section-5.2-3.2">
            <t indent="0" pn="section-5.2-3.2.1">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.</t>
          </li>
          <li pn="section-5.2-3.3">
            <t indent="0" pn="section-5.2-3.3.1">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.</t>
          </li>
        </ul>
        <t indent="0" pn="section-5.2-4">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.</t>
        <t indent="0" pn="section-5.2-5">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 <xref section="4.7" sectionFormat="of" target="RFC8711" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8711#section-4.7" derivedContent="RFC8711"/>.</t>
        <t indent="0" pn="section-5.2-6">Any such action taken by the IETF LLC under this section of this
policy is not subject to the rest of this policy.</t>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">The usual security considerations <xref target="RFC3552" format="default" sectionFormat="of" derivedContent="RFC3552"/> do not apply to this
memo.</t>
      <t indent="0" pn="section-6-2">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:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-6-3"><li pn="section-6-3.1" derivedCounter="1.">
          <t indent="0" pn="section-6-3.1.1"><xref target="prod" format="default" sectionFormat="of" derivedContent="Section 4"/> requires the moderator team to first establish procedures
that are intended to apply uniformly across the IETF.</t>
        </li>
        <li pn="section-6-3.2" derivedCounter="2.">
          <t indent="0" pn="section-6-3.2.1"><xref target="genphil" format="default" sectionFormat="of" derivedContent="Section 1.2"/> explicitly states that viewpoints outside the rough
consensus are not in and of themselves disruptive.</t>
        </li>
        <li pn="section-6-3.3" derivedCounter="3.">
          <t indent="0" pn="section-6-3.3.1"><xref target="prod" format="default" sectionFormat="of" derivedContent="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.</t>
        </li>
        <li pn="section-6-3.4" derivedCounter="4.">
          <t indent="0" pn="section-6-3.4.1"><xref target="prod" format="default" sectionFormat="of" derivedContent="Section 4"/> also requires that the community be informed in the case
of suspensions lasting longer than 14 days.</t>
        </li>
        <li pn="section-6-3.5" derivedCounter="5.">
          <t indent="0" pn="section-6-3.5.1"><xref target="appeals" format="default" sectionFormat="of" derivedContent="Section 4.1"/> lays out an appeals process in the case of
disagreements.</t>
        </li>
        <li pn="section-6-3.6" derivedCounter="6.">
          <t indent="0" pn="section-6-3.6.1">If moderators find that the procedures themselves are leading to
inappropriate moderation, <xref target="prod" format="default" sectionFormat="of" derivedContent="Section 4"/> allows them to update those procedures
in consultation with the community and with the approval of the IESG.</t>
        </li>
        <li pn="section-6-3.7" derivedCounter="7.">
          <t indent="0" pn="section-6-3.7.1">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 <xref target="BCP10" format="default" sectionFormat="of" derivedContent="BCP10"/> or the community at large.</t>
        </li>
        <li pn="section-6-3.8" derivedCounter="8.">
          <t indent="0" pn="section-6-3.8.1">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.</t>
        </li>
      </ol>
      <t indent="0" pn="section-6-4">Moderation actions are intended to limit the likelihood
of disruptive behavior by a few IETF participants that may discourage
participation by other IETF participants.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references" pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <referencegroup anchor="BCP10" target="https://www.rfc-editor.org/info/bcp10" derivedAnchor="BCP10">
          <reference anchor="RFC8713" target="https://www.rfc-editor.org/info/rfc8713" quoteTitle="true">
            <front>
              <title>IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees</title>
              <author fullname="M. Kucherawy" initials="M." role="editor" surname="Kucherawy"/>
              <author fullname="R. Hinden" initials="R." role="editor" surname="Hinden"/>
              <author fullname="J. Livingood" initials="J." role="editor" surname="Livingood"/>
              <date month="February" year="2020"/>
              <abstract>
                <t indent="0">The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC (IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF Administrative Support Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.</t>
                <t indent="0">This document obsoletes RFC 7437 and RFC 8318.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="10"/>
            <seriesInfo name="RFC" value="8713"/>
            <seriesInfo name="DOI" value="10.17487/RFC8713"/>
          </reference>
          <reference anchor="RFC9389" target="https://www.rfc-editor.org/info/rfc9389" quoteTitle="true">
            <front>
              <title>Nominating Committee Eligibility</title>
              <author fullname="M. Duke" initials="M." surname="Duke"/>
              <date month="April" year="2023"/>
              <abstract>
                <t indent="0">The IETF Nominating Committee (NomCom) appoints candidates to several IETF leadership committees. RFC 8713 provides criteria for NomCom membership that attempt to ensure NomCom volunteers are members of the loosely defined IETF community, by requiring in-person attendance in three of the past five in-person meetings. In 2020 and 2021, the IETF had six consecutive fully online plenary meetings that drove rapid advancement in remote meeting technologies and procedures, including an experiment that included remote attendance for NomCom eligibility. This document updates RFC 8713 by defining a new set of eligibility criteria from first principles, with consideration to the increased salience of remote attendance. This document obsoletes RFCs 8788 and 8989.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="10"/>
            <seriesInfo name="RFC" value="9389"/>
            <seriesInfo name="DOI" value="10.17487/RFC9389"/>
          </reference>
        </referencegroup>
        <reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2026" quoteTitle="true" derivedAnchor="RFC2026">
          <front>
            <title>The Internet Standards Process -- Revision 3</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="October" year="1996"/>
            <abstract>
              <t indent="0">This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="9"/>
          <seriesInfo name="RFC" value="2026"/>
          <seriesInfo name="DOI" value="10.17487/RFC2026"/>
        </reference>
        <reference anchor="RFC2418" target="https://www.rfc-editor.org/info/rfc2418" quoteTitle="true" derivedAnchor="RFC2418">
          <front>
            <title>IETF Working Group Guidelines and Procedures</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="September" year="1998"/>
            <abstract>
              <t indent="0">This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="25"/>
          <seriesInfo name="RFC" value="2418"/>
          <seriesInfo name="DOI" value="10.17487/RFC2418"/>
        </reference>
        <reference anchor="RFC3935" target="https://www.rfc-editor.org/info/rfc3935" quoteTitle="true" derivedAnchor="RFC3935">
          <front>
            <title>A Mission Statement for the IETF</title>
            <author fullname="H. Alvestrand" initials="H." surname="Alvestrand"/>
            <date month="October" year="2004"/>
            <abstract>
              <t indent="0">This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="95"/>
          <seriesInfo name="RFC" value="3935"/>
          <seriesInfo name="DOI" value="10.17487/RFC3935"/>
        </reference>
        <reference anchor="RFC7154" target="https://www.rfc-editor.org/info/rfc7154" quoteTitle="true" derivedAnchor="RFC7154">
          <front>
            <title>IETF Guidelines for Conduct</title>
            <author fullname="S. Moonesamy" initials="S." role="editor" surname="Moonesamy"/>
            <date month="March" year="2014"/>
            <abstract>
              <t indent="0">This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.</t>
              <t indent="0">This document is an updated version of the guidelines for conduct originally published in RFC 3184.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="54"/>
          <seriesInfo name="RFC" value="7154"/>
          <seriesInfo name="DOI" value="10.17487/RFC7154"/>
        </reference>
        <reference anchor="RFC7776" target="https://www.rfc-editor.org/info/rfc7776" quoteTitle="true" derivedAnchor="RFC7776">
          <front>
            <title>IETF Anti-Harassment Procedures</title>
            <author fullname="P. Resnick" initials="P." surname="Resnick"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <date month="March" year="2016"/>
            <abstract>
              <t indent="0">IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy.</t>
              <t indent="0">This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="25"/>
          <seriesInfo name="RFC" value="7776"/>
          <seriesInfo name="DOI" value="10.17487/RFC7776"/>
        </reference>
        <reference anchor="RFC8711" target="https://www.rfc-editor.org/info/rfc8711" quoteTitle="true" derivedAnchor="RFC8711">
          <front>
            <title>Structure of the IETF Administrative Support Activity, Version 2.0</title>
            <author fullname="B. Haberman" initials="B." surname="Haberman"/>
            <author fullname="J. Hall" initials="J." surname="Hall"/>
            <author fullname="J. Livingood" initials="J." surname="Livingood"/>
            <date month="February" year="2020"/>
            <abstract>
              <t indent="0">The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe the IETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board (IETF LLC Board), the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board.</t>
              <t indent="0">This document obsoletes RFC 4071, RFC 4333, and RFC 7691.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="101"/>
          <seriesInfo name="RFC" value="8711"/>
          <seriesInfo name="DOI" value="10.17487/RFC8711"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="AHP" target="https://www.ietf.org/about/groups/iesg/statements/anti-harassment-policy/" quoteTitle="true" derivedAnchor="AHP">
          <front>
            <title>IETF Anti-Harassment Policy</title>
            <author>
              <organization showOnFrontPage="true">IESG</organization>
            </author>
            <date year="2013" month="November" day="03"/>
          </front>
        </reference>
        <reference anchor="DP" target="https://www.ietf.org/about/groups/iesg/statements/disruptive-posting/" quoteTitle="true" derivedAnchor="DP">
          <front>
            <title>IESG Statement on Disruptive Posting</title>
            <author>
              <organization showOnFrontPage="true">IESG</organization>
            </author>
            <date year="2006" month="February" day="17"/>
          </front>
        </reference>
        <reference anchor="IESG-SPAM" target="https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-spam-control-on-ietf-mailing-lists-20080414/" quoteTitle="true" derivedAnchor="IESG-SPAM">
          <front>
            <title>IESG Statement on Spam Control on IETF Mailing Lists</title>
            <author>
              <organization showOnFrontPage="true">IESG</organization>
            </author>
            <date year="2008" month="April" day="14"/>
          </front>
        </reference>
        <reference anchor="MODML" target="https://www.ietf.org/about/groups/iesg/statements/mailing-lists-moderation/" quoteTitle="true" derivedAnchor="MODML">
          <front>
            <title>IESG Guidance on the Moderation of IETF Working Group Mailing Lists</title>
            <author>
              <organization showOnFrontPage="true">IESG</organization>
            </author>
            <date year="2000" month="August" day="29"/>
          </front>
        </reference>
        <reference anchor="OT" target="https://www.ietf.org/contact/ombudsteam/" quoteTitle="true" derivedAnchor="OT">
          <front>
            <title>Ombudsteam</title>
            <author>
              <organization showOnFrontPage="true"/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC3552" target="https://www.rfc-editor.org/info/rfc3552" quoteTitle="true" derivedAnchor="RFC3552">
          <front>
            <title>Guidelines for Writing RFC Text on Security Considerations</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="B. Korver" initials="B." surname="Korver"/>
            <date month="July" year="2003"/>
            <abstract>
              <t indent="0">All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="72"/>
          <seriesInfo name="RFC" value="3552"/>
          <seriesInfo name="DOI" value="10.17487/RFC3552"/>
        </reference>
        <reference anchor="RFC3683" target="https://www.rfc-editor.org/info/rfc3683" quoteTitle="true" derivedAnchor="RFC3683">
          <front>
            <title>A Practice for Revoking Posting Rights to IETF Mailing Lists</title>
            <author fullname="M. Rose" initials="M." surname="Rose"/>
            <date month="March" year="2004"/>
            <abstract>
              <t indent="0">All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion. An important part of this consensus-driven process is the pervasive use of mailing lists for discussion. Notably, in a small number of cases, a participant has engaged in a "denial-of-service" attack to disrupt the consensus-driven process. Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks. This memo recommends such a practice for use by the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="83"/>
          <seriesInfo name="RFC" value="3683"/>
          <seriesInfo name="DOI" value="10.17487/RFC3683"/>
        </reference>
        <reference anchor="RFC3934" target="https://www.rfc-editor.org/info/rfc3934" quoteTitle="true" derivedAnchor="RFC3934">
          <front>
            <title>Updates to RFC 2418 Regarding the Management of IETF Mailing Lists</title>
            <author fullname="M. Wasserman" initials="M." surname="Wasserman"/>
            <date month="October" year="2004"/>
            <abstract>
              <t indent="0">This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="25"/>
          <seriesInfo name="RFC" value="3934"/>
          <seriesInfo name="DOI" value="10.17487/RFC3934"/>
        </reference>
        <reference anchor="RFC7282" target="https://www.rfc-editor.org/info/rfc7282" quoteTitle="true" derivedAnchor="RFC7282">
          <front>
            <title>On Consensus and Humming in the IETF</title>
            <author fullname="P. Resnick" initials="P." surname="Resnick"/>
            <date month="June" year="2014"/>
            <abstract>
              <t indent="0">The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus.</t>
              <t indent="0">Note: This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7282"/>
          <seriesInfo name="DOI" value="10.17487/RFC7282"/>
        </reference>
        <reference anchor="RFC9245" target="https://www.rfc-editor.org/info/rfc9245" quoteTitle="true" derivedAnchor="RFC9245">
          <front>
            <title>IETF Discussion List Charter</title>
            <author fullname="L. Eggert" initials="L." surname="Eggert"/>
            <author fullname="S. Harris" initials="S." surname="Harris"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through the general discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist. As this is the most general IETF mailing list, considerable latitude in terms of topics is allowed, but there are posts and topics that are unsuitable for this mailing list. This document defines the charter for the IETF discussion list and explains its scope.</t>
              <t indent="0">This document obsoletes RFC 3005 and updates RFC 3683.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="45"/>
          <seriesInfo name="RFC" value="9245"/>
          <seriesInfo name="DOI" value="10.17487/RFC9245"/>
        </reference>
      </references>
    </references>
    <section anchor="motivation" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-motivation">Motivation</name>
      <t indent="0" pn="section-appendix.a-1"><xref target="introduction" format="default" sectionFormat="of" derivedContent="Section 1"/> summarizes the process changes introduced by this memo.
This appendix discusses the background that led to them.</t>
      <section anchor="background" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.1">
        <name slugifiedName="name-background">Background</name>
        <t indent="0" pn="section-appendix.a.1-1">The IETF community has defined general guidelines for
personal interactions in the IETF <xref target="RFC7154" format="default" sectionFormat="of" derivedContent="RFC7154"/>. The IESG has
defined an anti-harassment policy for the IETF <xref target="AHP" format="default" sectionFormat="of" derivedContent="AHP"/> for which the IETF
community has defined anti-harassment procedures <xref target="RFC7776" format="default" sectionFormat="of" derivedContent="RFC7776"/>,
empowering an Ombudsteam <xref target="OT" format="default" sectionFormat="of" derivedContent="OT"/> to take necessary action.</t>
        <t indent="0" pn="section-appendix.a.1-2">Dealing with <em>disruptive</em> behavior, however, is not part of the role
of the Ombudsteam. <xref target="RFC2418" format="default" sectionFormat="of" derivedContent="RFC2418"/> tasks the chairs of each IETF working
group with moderating their group's in-person meetings while
<xref target="RFC3934" format="default" sectionFormat="of" derivedContent="RFC3934"/> provides chairs a procedure to help manage mailing
lists. An IESG statement <xref target="MODML" format="default" sectionFormat="of" derivedContent="MODML"/> describes additional guidance
to working group chairs about how -- but not when -- to moderate their
lists.</t>
        <t indent="0" pn="section-appendix.a.1-3">For IETF mailing lists not associated with a working group, another
IESG statement <xref target="DP" format="default" sectionFormat="of" derivedContent="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
<xref target="RFC9245" format="default" sectionFormat="of" derivedContent="RFC9245"/>.</t>
        <t indent="0" pn="section-appendix.a.1-4">Note that the term "moderation" can refer both to <em>preemptive</em>
moderation, where administrators review attempted participation before
it occurs
(such as reviewing messages to a mailing list), and <em>reactive</em> 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.</t>
        <t indent="0" pn="section-appendix.a.1-5">In addition, <xref target="RFC3683" format="default" sectionFormat="of" derivedContent="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.</t>
        <t indent="0" pn="section-appendix.a.1-6">Experience and community input suggests that an evolution of the
existing processes is necessary.</t>
      </section>
      <section anchor="motive" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.2">
        <name slugifiedName="name-problems-with-the-previous-">Problems with the Previous Approach</name>
        <t indent="0" pn="section-appendix.a.2-1">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:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-2">
          <li pn="section-appendix.a.2-2.1">
            <t indent="0" pn="section-appendix.a.2-2.1.1">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.</t>
          </li>
          <li pn="section-appendix.a.2-2.2">
            <t indent="0" pn="section-appendix.a.2-2.2.1">The moderation process that chairs and list administrators need to
follow <xref target="RFC3934" format="default" sectionFormat="of" derivedContent="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.</t>
          </li>
          <li pn="section-appendix.a.2-2.3">
            <t indent="0" pn="section-appendix.a.2-2.3.1">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.</t>
          </li>
          <li pn="section-appendix.a.2-2.4">
            <t indent="0" pn="section-appendix.a.2-2.4.1">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.</t>
          </li>
          <li pn="section-appendix.a.2-2.5">
            <t indent="0" pn="section-appendix.a.2-2.5.1">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.</t>
          </li>
          <li pn="section-appendix.a.2-2.6">
            <t indent="0" pn="section-appendix.a.2-2.6.1">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.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="examples" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-non-normative-examples-of-d">Non-Normative Examples of Disruptive Behavior</name>
      <t indent="0" pn="section-appendix.b-1">The list below describes some types of disruptive behavior, but it
is non-exhaustive.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.b-2">
        <li pn="section-appendix.b-2.1">
          <t indent="0" pn="section-appendix.b-2.1.1">Discussion of subjects unrelated to a forum's charter or scope;</t>
        </li>
        <li pn="section-appendix.b-2.2">
          <t indent="0" pn="section-appendix.b-2.2.1">Uncivil commentary, regardless of the general subject;</t>
        </li>
        <li pn="section-appendix.b-2.3">
          <t indent="0" pn="section-appendix.b-2.3.1">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;</t>
        </li>
        <li pn="section-appendix.b-2.4">
          <t indent="0" pn="section-appendix.b-2.4.1">Repeatedly arguing counter to a WG charter that has been approved by
the IESG; and</t>
        </li>
        <li pn="section-appendix.b-2.5">
          <t indent="0" pn="section-appendix.b-2.5.1">"Sealioning", where a participant makes incessant requests for evidence or
data, even while remaining superficially polite.</t>
        </li>
      </ul>
      <t indent="0" pn="section-appendix.b-3">These items are examples. Moderators and administrators may take moderation
actions for many other cases.</t>
      <t indent="0" pn="section-appendix.b-4">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.</t>
    </section>
    <section anchor="acknowledgments" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.c-1">This memo is based on two individual Internet-Drafts,
<eref target="https://datatracker.ietf.org/doc/draft-ecahc-moderation/" brackets="none">draft-ecahc-moderation</eref>
authored by <contact fullname="Lars Eggert"/>, <contact fullname="Alissa Cooper"/>, <contact fullname="Jari Arkko"/>, <contact fullname="Russ Housley"/>, and <contact fullname="Brian E. Carpenter"/>, and
<eref target="https://datatracker.ietf.org/doc/draft-lear-bcp83-replacement/" brackets="none">draft-lear-bcp83-replacement</eref>
authored by <contact fullname="Eliot Lear"/>, <contact fullname="Robert Wilton"/>, <contact fullname="Bron Gondwana"/>, and <contact fullname="John R. Levine"/>.
<contact fullname="Robert Sayre"/> authored
<eref target="https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/" brackets="none">draft-sayre-modpod-excellent</eref>,
which also originated ideas reflected in this work.  <contact fullname="Pete Resnick"/> provided the
basis for how the moderators interact with list/forum leadership.</t>
      <t indent="0" pn="section-appendix.c-2">These individuals contributed additional improvements:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.c-3">
        <li pn="section-appendix.c-3.1">
          <t indent="0" pn="section-appendix.c-3.1.1"><contact fullname="Alissa Cooper"/></t>
        </li>
        <li pn="section-appendix.c-3.2">
          <t indent="0" pn="section-appendix.c-3.2.1"><contact fullname="Brian Carpenter"/></t>
        </li>
        <li pn="section-appendix.c-3.3">
          <t indent="0" pn="section-appendix.c-3.3.1"><contact fullname="Chris Box"/></t>
        </li>
        <li pn="section-appendix.c-3.4">
          <t indent="0" pn="section-appendix.c-3.4.1"><contact fullname="Colin Perkins"/></t>
        </li>
        <li pn="section-appendix.c-3.5">
          <t indent="0" pn="section-appendix.c-3.5.1"><contact fullname="David Schinazi"/></t>
        </li>
        <li pn="section-appendix.c-3.6">
          <t indent="0" pn="section-appendix.c-3.6.1"><contact fullname="Deb Cooley"/></t>
        </li>
        <li pn="section-appendix.c-3.7">
          <t indent="0" pn="section-appendix.c-3.7.1"><contact fullname="Dhruv Dhody"/></t>
        </li>
        <li pn="section-appendix.c-3.8">
          <t indent="0" pn="section-appendix.c-3.8.1"><contact fullname="Eric Rescorla"/></t>
        </li>
        <li pn="section-appendix.c-3.9">
          <t indent="0" pn="section-appendix.c-3.9.1"><contact fullname="Éric Vyncke"/></t>
        </li>
        <li pn="section-appendix.c-3.10">
          <t indent="0" pn="section-appendix.c-3.10.1"><contact fullname="Erik Kline"/></t>
        </li>
        <li pn="section-appendix.c-3.11">
          <t indent="0" pn="section-appendix.c-3.11.1"><contact fullname="Harald Alvestrand"/></t>
        </li>
        <li pn="section-appendix.c-3.12">
          <t indent="0" pn="section-appendix.c-3.12.1"><contact fullname="Jay Daley"/></t>
        </li>
        <li pn="section-appendix.c-3.13">
          <t indent="0" pn="section-appendix.c-3.13.1"><contact fullname="Joel Halpern"/></t>
        </li>
        <li pn="section-appendix.c-3.14">
          <t indent="0" pn="section-appendix.c-3.14.1"><contact fullname="John Klensin"/></t>
        </li>
        <li pn="section-appendix.c-3.15">
          <t indent="0" pn="section-appendix.c-3.15.1"><contact fullname="John Scudder"/></t>
        </li>
        <li pn="section-appendix.c-3.16">
          <t indent="0" pn="section-appendix.c-3.16.1"><contact fullname="Lisa Dusseault"/></t>
        </li>
        <li pn="section-appendix.c-3.17">
          <t indent="0" pn="section-appendix.c-3.17.1"><contact fullname="Martin Thomson"/></t>
        </li>
        <li pn="section-appendix.c-3.18">
          <t indent="0" pn="section-appendix.c-3.18.1"><contact fullname="Melinda Shore"/></t>
        </li>
        <li pn="section-appendix.c-3.19">
          <t indent="0" pn="section-appendix.c-3.19.1"><contact fullname="Michael Richardson"/></t>
        </li>
        <li pn="section-appendix.c-3.20">
          <t indent="0" pn="section-appendix.c-3.20.1"><contact fullname="Mike Bishop"/></t>
        </li>
        <li pn="section-appendix.c-3.21">
          <t indent="0" pn="section-appendix.c-3.21.1"><contact fullname="Mohamed Boucadair"/></t>
        </li>
        <li pn="section-appendix.c-3.22">
          <t indent="0" pn="section-appendix.c-3.22.1"><contact fullname="Murray Kucherawy"/></t>
        </li>
        <li pn="section-appendix.c-3.23">
          <t indent="0" pn="section-appendix.c-3.23.1"><contact fullname="Nick Hilliard"/></t>
        </li>
        <li pn="section-appendix.c-3.24">
          <t indent="0" pn="section-appendix.c-3.24.1"><contact fullname="Orie Steele"/></t>
        </li>
        <li pn="section-appendix.c-3.25">
          <t indent="0" pn="section-appendix.c-3.25.1"><contact fullname="Paul Hoffman"/></t>
        </li>
        <li pn="section-appendix.c-3.26">
          <t indent="0" pn="section-appendix.c-3.26.1"><contact fullname="Paul Wouters"/></t>
        </li>
        <li pn="section-appendix.c-3.27">
          <t indent="0" pn="section-appendix.c-3.27.1"><contact fullname="Pete Resnick"/></t>
        </li>
        <li pn="section-appendix.c-3.28">
          <t indent="0" pn="section-appendix.c-3.28.1"><contact fullname="Rich Salz"/></t>
        </li>
        <li pn="section-appendix.c-3.29">
          <t indent="0" pn="section-appendix.c-3.29.1"><contact fullname="Robert Sayre"/></t>
        </li>
        <li pn="section-appendix.c-3.30">
          <t indent="0" pn="section-appendix.c-3.30.1"><contact fullname="Robert Sparks"/></t>
        </li>
        <li pn="section-appendix.c-3.31">
          <t indent="0" pn="section-appendix.c-3.31.1"><contact fullname="Roman Danyliw"/></t>
        </li>
        <li pn="section-appendix.c-3.32">
          <t indent="0" pn="section-appendix.c-3.32.1"><contact fullname="Russ Housley"/></t>
        </li>
        <li pn="section-appendix.c-3.33">
          <t indent="0" pn="section-appendix.c-3.33.1"><contact fullname="Sean Turner"/></t>
        </li>
        <li pn="section-appendix.c-3.34">
          <t indent="0" pn="section-appendix.c-3.34.1"><contact fullname="Simon Josefsson"/></t>
        </li>
        <li pn="section-appendix.c-3.35">
          <t indent="0" pn="section-appendix.c-3.35.1"><contact fullname="Stephen Farrell"/></t>
        </li>
        <li pn="section-appendix.c-3.36">
          <t indent="0" pn="section-appendix.c-3.36.1"><contact fullname="Ted Lemon"/></t>
        </li>
        <li pn="section-appendix.c-3.37">
          <t indent="0" pn="section-appendix.c-3.37.1"><contact fullname="Tim Bray"/></t>
        </li>
      </ul>
      <t indent="0" pn="section-appendix.c-4">N.B., acknowledgment should not be taken as endorsement by the
individuals named above.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="L." surname="Eggert" fullname="Lars Eggert" role="editor">
        <organization showOnFrontPage="true">Mozilla</organization>
        <address>
          <postal>
            <street>Stenbergintie 12 B</street>
            <city>Kauniainen</city>
            <code>02700</code>
            <country>FI</country>
          </postal>
          <email>lars@eggert.org</email>
          <uri>https://eggert.org/</uri>
        </address>
      </author>
      <author initials="E." surname="Lear" fullname="Eliot Lear" role="editor">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <postal>
            <street>Richtistrasse 7</street>
            <city>Wallisellen</city>
            <code>8304</code>
            <country>Switzerland</country>
          </postal>
          <phone>+41 44 878 9200</phone>
          <email>lear@lear.ch</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
