RFC 9945

RFC 9945: IETF Community Moderation 🎀

Okay bestie, this one is a whole vibe. RFC 9945 is called IETF Community Moderation, and it's a Best Current Practice (BCP 245 🌸). It comes from the Internet Engineering Task Force, dated February 2026, with L. Eggert (Mozilla) and E. Lear (Cisco Systems) as the editors. It's an ISSN 2070-1721 document ✨. It obsoletes RFC 3683 and RFC 3934, and it updates RFC 2418 and RFC 9245. So it's basically the new moderation era for the IETF 👑.

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 setting up a policy for moderating disruptive participation across the IETF's public contribution channels and discussion fora 🦋. It sets guardrails for moderation and creates a moderator team. That team will write a set of moderation procedures and help make sure chairs and administrators apply them consistently 🫶.

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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🔥. If you want more info on BCPs, check out Section 2 of RFC 7841.

Info about the current status of this document, any errata, and how to give feedback is 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) as they're in effect on the date this document is published. Please actually read these, bestie, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they're 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 sets up a policy for moderating disruptive participation across the IETF's public online contribution channels and discussion fora 💖. It creates a moderator team that develops procedures and makes sure they get applied consistently.

This memo obsoletes and updates some older IETF processes. I'll sum them up here, and Appendix A has the longer backstory 📚.

Here's what changes in the existing processes:

• Obsoletes [RFC3683], because the "posting rights" (PR) action it defines is replaced by the processes in this document 🚫.
• Obsoletes [RFC3934], because it replaces working group moderation procedures 🔄.
• Obsoletes Section 3 of [RFC9245] and the second paragraph of Section 4 of [RFC9245], because the IETF moderator team defined here 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 in this memo only apply to IETF activities. They don't apply to other related organizations, like 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, unless those groups explicitly agree 🌸. These changes take effect when the IESG approves the procedures described in Section 4 ⭐.

1.1. Terminology Note 📝

In this document, "administrator" means the people the IESG assigns to manage a particular public participation channel or discussion forum. This memo uses "forum" for any public IETF participation channel, like a mailing list, a chat group, or a discussion in a collaborative tool such as GitHub or GitLab 💜. For example, working group chairs are administrators of all the public fora their working groups use. That usually means mailing lists and chat groups, but it could also mean tools like 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 way that fits the policy laid out in [RFC7154] 🫶.

Disagreement and diverse points of view are expected in any standards organization, and honestly they're healthy 💅. The IETF is an open standards organization with a discussion-based rough consensus process. A non-normative description of that is in [RFC7282] ✨. So engaged, respectful discussion that stays within the scope of an IETF forum shouldn't be treated as disruptive. Someone also isn't disruptive just because they're outside the rough consensus 🙌. But when someone crosses the line into disruptive behavior, action has to be taken to keep the community's decorum intact 🔥.

The moderation policy goals are:

• Apply consistent, fair, and timely moderation of communication across all public online IETF participation channels and participation fora, no matter a participant's role in the IETF or their previous technical contributions 🍓;
• Make sure appeals are available for disagreements about moderation actions ⚖️;
• Balance transparency against both the privacy of the individuals involved and further disruption to the community 🔒;
• Allow moderation decisions to be reconsidered 🔁; and
• Give all the people doing moderation the broadest possible latitude, so they have the flexibility to handle a wide range of individuals and situations 🧚.

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

The objective is explicitly not punishment. The goal is to keep an open, welcoming, non-hostile environment where everyone can take part on an equal footing, regardless of their role in the IETF or their past technical contributions 🌸.

2. IETF Moderator Team 👑

This memo defines a consistent approach to moderating the IETF's public online fora. A moderator team for the IETF will develop and maintain moderation guidelines, and it'll help make sure they're applied and implemented consistently, as detailed below 🦋. These changes address the issues in the previous model (see Appendix A.2) and follow the principles from the introduction ✨.

2.1. Composition 🎀

The IESG appoints and recalls moderators. The moderator team starts out with no fewer than five individuals. It can grow or shrink based on operational experience 🌱. When picking members, the IESG takes 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 serves on the IESG or IAB 🚫. People serving on other bodies that the NomCom appoints members to, like the IETF Trust or the IETF LLC Board, also get excluded from the moderator team, and so do IETF LLC staff and contractors. If a moderator takes on any of those roles, they shall step down from the moderator team soon after 💀.

2.1.1. Team Diversity 🌍

Because the IETF is global, the team should reflect a range of time zones and other participant characteristics. That way it can operate effectively around the clock and all year long 🌞. Ideally, moderators should be able to respond to issues within a few hours ⏰.

Team diversity also makes it more likely that any participant who sees or experiences disruptive behavior can find a moderator they feel comfortable reaching out to 🫶.

2.2. Training 🧠

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

3. Scope and Responsibilities ✨

okay so this policy covers ALL the public online IETF fora 🌸 like, present ones AND future ones. that includes mailing lists, chat groups, and any other discussion systems the IETF or WGs decide to use, such as GitHub repos, wikis, or issue trackers. bestie, the whole internet-hangout universe 🦋

different people have different moderation jobs, so let's break it down 💅

• Participants should always behave the way we talked about in Section 1.2. 🫶 They're also encouraged to report disruptive behavior aimed at them or someone else to an administrator of the forum and the moderators. like, report it to BOTH 🙈
• Administrators are mainly in charge of running their forums following procedures the moderators write and the IESG approves. 👑 So they SHALL address reports of disruptive behavior in a timely fashion, and they keep the moderators in the loop about reports or actions taken. Administrators MAY amend or rescind actions, including ones taken by members of the moderator team, after they've talked it through with that team. (the vibe is teamwork, periodt 💖)

For a working group, the chairs are the administrators by default. 🧚 They MAY delegate this in the same vein as Section 6.4 of [RFC2418], but they MUST always accept, acknowledge, and keep track of complaints about disruptive behavior. Forum administrators SHOULD moderate in a way that means the moderator team doesn't need to get involved. that's the dream ✨

• Moderators are responsible for setting up procedures for moderation needs across ALL IETF fora, present and future. 🌈 They're a resource the community can use to deal with disruptive behavior. The moderator team answers to the IESG. The IESG will create or designate a forum to talk about moderation and point interested people there 💜

Moderators MAY take action when administrators don't respond to reports in a timely fashion. 🙈 Their first move SHOULD generally be to try contacting and advising the relevant administrators. They SHOULD only take moderation actions when administrators are not responsive, or when someone is disrupting multiple fora at the same time. Moderators SHOULD generally give WG chairs the chance to handle what may be difficult and contentious debates within their groups. 🫶 Within the bounds of this principle, it's up to the moderators' judgment to decide when they MUST act, with the understanding that some situations may need fast responses ⚡ Moderators MUST notify administrators of any actions they take. Section 4.1 covers how disagreements get handled 💅

Moderators are administrators for IETF plenary fora, which currently includes the IETF discussion and Last Call lists and any plenary chat sessions. 👑 They're also administrators for any forum that doesn't otherwise have one.

To keep this scalable, except for plenary fora as described above, moderators are NOT expected to always actively monitor all communications. 🦋 In general, they'll process reports from participants.

• Area directors are expected to resolve conflicts as described here and in Section 4.1. 💖 The IESG will periodically evaluate how the moderators are performing and what they need, and MAY appoint and recall moderators as they see fit. 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 purpose of limiting disruptive communications in online IETF fora. Everything else is beyond the scope of this memo 🫠 Examples of out-of-scope actions include, but aren't 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. 🙃 The moderator team doesn't moderate non-public IETF mailing lists, but the administrators of those lists CAN choose to adopt some of the procedures the moderator team develops. (can, not must, lowkey a vibe 🌷)

3.2. Unsolicited Bulk Messages 📬

Unsolicited bulk messages are considered disruptive and SHOULD be handled in a way that's 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). Those actions require no additional reporting ✨

4. Moderation Procedures and Transparency 🔍

Within the bounds of the policies set here, the moderator team SHALL develop and maintain procedures and criteria for moderation, including the moderator team's own operating procedures. 🧁

Those procedures and criteria SHALL be developed with community input, be approved by the IESG before going into effect, and be made public. 📢 They do NOT need to be documented in the RFC Series, though. This SHALL be the first task for the moderator team 💅 Until those procedures and criteria are established, all the previous processes referenced in Section 1 SHALL remain in effect.

The intent of this memo is to give administrators and moderators the widest possible freedom of action, with the expectation that the minimal necessary actions will be taken 🌸 Anyone who is 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 reported immediately to the people they take effect against, to relevant administrators, and to the moderator team for review 📣 They SHALL also be reported periodically to the IESG.

Only moderation actions suspending participation privileges for longer than fourteen (14) days MUST be reported to the forum where that action applies, or in any case at the request of the suspended person. If the action applies to more than one forum, it SHOULD be communicated to the community in a way the IESG decides 🦋

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 way that's consistent with this memo and the guidelines approved by the IESG. 💅 If there's a disagreement over a moderation decision, anyone MAY take it up with the responsible area director for resolution, or with the IETF Chair if a responsible area director can't be determined or isn't assigned. If the area director can't resolve the disagreement, that person MAY then appeal to the IESG and then 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 once a year afterward 🗓️

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

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

A suspension of participation privileges imposed before 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 a 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, so they will be extremely rare 🤞 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, the nature of the action, the reason for the action, and the expected duration. 📝 The IETF LLC SHOULD also inform the moderator team and the IETF community, except where it receives legal advice to the contrary.

Because such an action would be taken by the IETF LLC to protect the IETF under its fiduciary duty, it CANNOT 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 🔒✨

Okay bestie, the usual security considerations from [RFC3552] do not apply to this memo 💅

Real talk though, there's a potential for the moderation procedures to get abused by moderators, working group chairs, and potentially others, and that could lead to censorship of legitimate participation 😭 Big no. The good news is that this risk gets mitigated in eight ways 🫶:

1. Section 4 requires the moderator team to first establish procedures that are meant to apply uniformly across the IETF 📋
2. Section 1.2 explicitly says 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 meant to limit the likelihood of disruptive behavior by a few IETF participants that may discourage participation by other IETF participants. That's the whole point, bestie 🌸

---

7. IANA Considerations 🌷

Good news for the IANA folks: 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 🧠

Okay, this is the backstory! 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. Lots of nuance here, bestie 🫶🦋

Okay bestie, I'm going to keep this part simple and honest: the text you pasted is only the Acknowledgments and Authors' Addresses, which are the very end of the document. Let me give you the full rewrite of that bit, with every name, address and email kept exactly as-is. 🎀

Acknowledgments ✨

This memo is based on two individual Internet-Drafts 💅. The first is draft-ecahc-moderation (https://datatracker.ietf.org/doc/draft-ecahc-moderation/), written by Lars Eggert, Alissa Cooper, Jari Arkko, Russ Housley, and Brian E. Carpenter. The second is draft-lear-bcp83-replacement (https://datatracker.ietf.org/doc/draft-lear-bcp83-replacement/), written by Eliot Lear, Robert Wilton, Bron Gondwana, and John R. Levine. Robert Sayre wrote draft-sayre-modpod-excellent (https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/), which also gave us ideas that show up in this work 🦋. Pete Resnick provided the basis for how the moderators work with list and 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