rfc9945-alt.txt		rfc9945.txt
	Internet Engineering Task Force (IETF) L. Eggert, Ed.		Internet Engineering Task Force (IETF) L. Eggert, Ed.
	Request for Comments: 9945 Mozilla		Request for Comments: 9945 Mozilla
	bcp: 245 E. Lear, Ed.		BCP: 245 E. Lear, Ed.
	Obsoletes: 3683, 3934 Cisco Systems		Obsoletes: 3683, 3934 Cisco Systems
	Updates: 2418, 9245 February 2026		Updates: 2418, 9245 February 2026
	Category: Best Current Practice		Category: Best Current Practice
	ISSN: 2070-1721		ISSN: 2070-1721
	IETF Community Moderation		IETF Community Moderation
	Abstract		Abstract
	The IETF community will treat people with kindness and grace, but not		The IETF community will treat people with kindness and grace, but not
	endless patience.		endless patience.
	This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and		This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and
	9245 by establishing a policy for the moderation of disruptive		9245 by establishing a policy for the moderation of disruptive
	participation across the IETF's various public contribution channels		participation across the IETF's various public contribution channels
	and discussion fora. It establishes guardrails for moderation and a		and discussion fora. It establishes guardrails for moderation and a
	moderator team. That team will develop a set of moderation		moderator team. That team will develop a set of moderation
	procedures and facilitate their consistent implementation with chairs		procedures and facilitate their consistent implementation with chairs
	and administrators.		and administrators.
	Status of This Memo		Status of This Memo
	This memo documents an Internet Best Current Practice.		This memo documents an Internet Best Current Practice.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	BCPs is available in Section 2 of RFC 7841.		BCPs is available in Section 2 of RFC 7841.
	Information about the current status of this document, any errata,		Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc9945.		https://www.rfc-editor.org/info/rfc9945.
	Copyright Notice		Copyright Notice
	Copyright (c) 2026 IETF Trust and the persons identified as the		Copyright (c) 2026 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	1.1. Terminology Note		1.1. Terminology Note
	1.2. General Philosophy		1.2. General Philosophy
	2. IETF Moderator Team		2. IETF Moderator Team
	2.1. Composition		2.1. Composition
	2.1.1. Team Diversity		2.1.1. Team Diversity
	2.2. Training		2.2. Training
	3. Scope and Responsibilities		3. Scope and Responsibilities
	3.1. Actions That Are Out of Scope		3.1. Actions That Are Out of Scope
	3.2. Unsolicited Bulk Messages		3.2. Unsolicited Bulk Messages
	4. Moderation Procedures and Transparency		4. Moderation Procedures and Transparency
	4.1. Consistency and Conflict Resolution		4.1. Consistency and Conflict Resolution
	4.2. Reinstatement		4.2. Reinstatement
	5. Relationship to Other IETF Functions		5. Relationship to Other IETF Functions
	5.1. Relation to the Ombudsteam		5.1. Relation to the Ombudsteam
	5.2. Relation to the IETF LLC		5.2. Relation to the IETF LLC
	6. Security Considerations		6. Security Considerations
	7. IANA Considerations		7. IANA Considerations
	8. Acknowledgments		8. References
	9. References		8.1. Normative References
	9.1. Normative References		8.2. Informative References
	9.2. Informative References
	Appendix A. Motivation		Appendix A. Motivation
	A.1. Background		A.1. Background
	A.2. Problems with the Previous Approach		A.2. Problems with the Previous Approach
	Appendix B. Non-Normative Examples of Disruptive Behavior		Appendix B. Non-Normative Examples of Disruptive Behavior
			Acknowledgments
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	This memo establishes a policy for the moderation of disruptive		This memo establishes a policy for the moderation of disruptive
	participation across the IETF's various public online contribution		participation across the IETF's various public online contribution
	channels and discussion fora. It creates a moderator team to develop		channels and discussion fora. It creates a moderator team to develop
	procedures and to facilitate their consistent application.		procedures and to facilitate their consistent application.
	This memo obsoletes and updates some prior IETF processes, summarized		This memo obsoletes and updates some prior IETF processes, summarized
	here. Background information is described in more detail in		here. Background information is described in more detail in
	Appendix A.		Appendix A.
	This memo makes the following changes to existing processes:		This memo makes the following changes to existing processes:
	* Obsoletes [RFC3683] as the "posting rights" (PR) action it defines		* Obsoletes [RFC3683] as the "posting rights" (PR) action it defines
	is replaced by processes defined herein;		is replaced by processes defined herein;
	* Obsoletes [RFC3934] as it replaces working group moderation		* Obsoletes [RFC3934] as it replaces working group moderation
	procedures;		procedures;
	* Obsoletes Section 3 of [RFC9245] and the second paragraph of		* Obsoletes Section 3 of [RFC9245] and the second paragraph of
	Section 4 of [RFC9245], as the moderator team replaces the IETF		Section 4 of [RFC9245], as the IETF moderator team defined in this
	discussion list moderation team.		document subsumes the IETF discussion list moderator team.
	* Updates Section 6.1 of [RFC2418], because the moderator team will		* Updates Section 6.1 of [RFC2418], because the moderator team will
	work together with working group chairs to moderate disruptive		work together with working group chairs to moderate disruptive
	behavior.		behavior.
	The processes described in this memo are solely applicable to IETF		The processes described in this memo are solely applicable to IETF
	activities, and not to other related organizations, such as the		activities, and not to other related organizations, such as the
	Internet Research Task Force (IRTF), the Internet Architecture Board		Internet Research Task Force (IRTF), the Internet Architecture Board
	(IAB), the RFC Series Working Group (RSWG), the RFC Series Approval		(IAB), the RFC Series Working Group (RSWG), the RFC Series Approval
	Board (RSAB), or the Independent RFC Submission Stream, without their		Board (RSAB), or the Independent RFC Submission Stream, without their
	explicit agreement. These changes take effect when the procedures		explicit agreement. These changes take effect when the procedures
	described in Section 4 have been approved by the IESG.		described in Section 4 have been approved by the IESG.
	1.1. Terminology Note		1.1. Terminology Note
	In this document, the term "administrator" refers to the people who		In this document, the term "administrator" refers to the people who
	are assigned by the IESG to manage a particular public participation		are assigned by the IESG to manage a particular public participation
	channel or discussion forum. This memo uses the term "forum" to		channel or discussion forum. This memo uses the term "forum" to
	refer to any public IETF participation channel, such as a mailing		refer to any public IETF participation channel, such as a mailing
	list, chat group, or discussion in a collaborative tool such as		list, chat group, or discussion in a collaborative tool such as
	GitHub or GitLab. For example, working group chairs are		GitHub or GitLab. For example, working group chairs are
	administrators of all the public fora that their working groups use,		administrators of all the public fora that their working groups use,
	which typically includes mailing lists and chat groups, but might		which typically includes mailing lists and chat groups, but might
	also include collaborative tools such as GitHub or GitLab. The		also include collaborative tools such as GitHub or GitLab. The
	"owners" of non-WG IETF mailing lists are another example of		"owners" of non-WG IETF mailing lists are another example of
	administrators.		administrators.
	1.2. General Philosophy		1.2. General Philosophy
	This cornerstone of this policy is that individuals are responsible		The cornerstone of this policy is that individuals are responsible
	for furthering the goals of the IETF as an organization [RFC3935] in		for furthering the goals of the IETF as an organization [RFC3935] in
	a manner consistent with the policy laid out in [RFC7154].		a manner consistent with the policy laid out in [RFC7154].
	Disagreement and diverse points of view within any standards		Disagreement and diverse points of view within any standards
	organization are to be expected and are even healthy. The IETF is an		organization are to be expected and are even healthy. The IETF is an
	open standards organization with a discussion-based rough consensus		open standards organization with a discussion-based rough consensus
	process, a non-normative description of which is in [RFC7282].		process, a non-normative description of which is in [RFC7282].
	Engaged, respectful discussion that is within the scope of an IETF		Engaged, respectful discussion that is within the scope of an IETF
	forum should therefore not be considered disruptive, nor should		forum should therefore not be considered disruptive, nor should
	someone be considered disruptive solely because they are outside the		someone be considered disruptive solely because they are outside the
	rough consensus. However, when someone crosses the line into		rough consensus. However, when someone crosses the line into
	disruptive behavior, action must be taken in order to maintain		disruptive behavior, action must be taken in order to maintain
	decorum of the community.		decorum of the community.
	The moderation policy goals are as follows:		The moderation policy goals are as follows:
	* Apply consistent, fair, and timely moderation of communication		* Apply consistent, fair, and timely moderation of communication
	across all public online IETF participation channels and		across all public online IETF participation channels and
	participation fora without regard to a participant's role in the		participation fora without regard to a participant's role in the
	IETF or previous technical contributions;		IETF or previous technical contributions;
	* Ensure appeals are available to address disagreements about		* Ensure that appeals are available to address disagreements about
	moderation actions;		moderation actions;
	* Balance transparency against both privacy of individuals involved		* Balance transparency against both privacy of individuals involved
	and further disruption to the community;		and further disruption to the community;
	* Allow moderation decisions to be reconsidered; and		* Allow moderation decisions to be reconsidered; and
	* Provide the broadest possible latitude to all people doing		* Provide the broadest possible latitude to all people doing
	moderation, so that they have the flexibility to address a broad		moderation, so that they have the flexibility to address a broad
	range of individuals and circumstances.		range of individuals and circumstances.
	Questions about the processes detailed below should be answered		Questions about the processes detailed below should be answered with
	through the lens of these aims.		these goals in mind.
	The objective is explicitly *not* punishment, but to maintain an		The objective is explicitly *not* punishment, but to maintain an
	open, welcoming, non-hostile environment in which all may participate		open, welcoming, non-hostile environment in which all may participate
	on an equal footing, regardless of their role in the IETF or past		on an equal footing, regardless of their role in the IETF or past
	technical contributions.		technical contributions.
	2. IETF Moderator Team		2. IETF Moderator Team
	This memo defines a consistent approach to moderating the IETF's		This memo defines a consistent approach to moderating the IETF's
	various public online fora. A moderator team for the IETF will		various public online fora. A moderator team for the IETF will
	develop and maintain guidelines for moderation and will facilitate		develop and maintain guidelines for moderation and will facilitate
	their consistent implementation and application as detailed below.		their consistent implementation and application as detailed below.
	These changes are intended to address the issues identified in the		These changes are intended to address the issues identified in the
	previous model (see Appendix A.2) and the principles described in the		previous model (see Appendix A.2) and the principles described in the
	introduction.		introduction.
	2.1. Composition		2.1. Composition
	The IESG appoints and recalls moderators. The moderator team		The IESG appoints and recalls moderators. The moderator team
	initially consists of no fewer than five individuals. The moderator		initially consists of no fewer than five individuals. The moderator
	team may expand or contract based on operational experience. In		team may expand or contract based on operational experience. In
	selecting members, the IESG will take into account geographic		selecting members, the IESG will take into account geographic
	coverage, expected and unexpected absences, and team diversity.		coverage, expected and unexpected absences, and team diversity.
	Because the IESG and IAB are in the appeals chain for moderator team		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		decisions (see Section 4.1), the IESG must not appoint a moderator
	who is serving on the IESG or IAB. Individuals serving on other		who is serving on the IESG or IAB. Individuals serving on other
	bodies to which the NomCom appoints members, such as the IETF Trust		bodies to which the NomCom appoints members, such as the IETF Trust
	or the LLC Board, as well as LLC staff and contractors, shall also be		or the IETF LLC Board, as well as IETF LLC staff and contractors
	excluded from serving on the moderator team. If a moderator assumes		shall also be excluded from serving on the moderator team. If a
	any such role, they shall step down from the moderator team soon		moderator assumes any such role, they shall step down from the
	after.		moderator team soon after.
	2.1.1. Team Diversity		2.1.1. Team Diversity
	Due to the global nature of the IETF, the membership of this team		Due to the global nature of the IETF, the membership of this team
	should reflect a diversity of time zones and other participant		should reflect a diversity of time zones and other participant
	characteristics that lets it operate effectively around the clock and		characteristics that lets it operate effectively around the clock and
	throughout the year. Ideally, the moderators should be able to		throughout the year. Ideally, the moderators should be able to
	respond to issues within a few hours.		respond to issues within a few hours.
	Team diversity is also important to ensure any participant observing		Team diversity also improves the likelihood that any participant
	disruptive behavior can identify a moderator they feel comfortable		experiencing or observing disruptive behavior can identify a
	contacting.		moderator they feel comfortable contacting.
	2.2. Training		2.2. Training
	The IETF is committed to providing and/or funding training for		The IETF is committed to providing and/or funding training for
	administrators and moderators as necessary. The IESG will negotiate		administrators and moderators as necessary. The IESG will negotiate
	any required funding or resources with IETF Administration LLC		any required funding or resources with IETF Administration LLC
	[RFC8711].		[RFC8711].
	3. Scope and Responsibilities		3. Scope and Responsibilities
	This policy applies to all public online IETF fora, both present and		This policy applies to all public online IETF fora, both present and
	future, including, but not limited to, mailing lists, chat groups,		future, including, but not limited to, mailing lists, chat groups,
	and discussions in other systems that the IETF or WGs have chosen to		and discussions in other systems that the IETF or WGs have chosen to
	employ, such as GitHub repositories, wikis, or issue trackers.		employ, such as GitHub repositories, wikis, or issue trackers.
	Different people have different moderation responsibilities:		Different people have different moderation responsibilities:
	* *Participants* should always behave in the manner discussed in		* *Participants* should always behave in the manner discussed in
	Section 1.2. They are also encouraged to report disruptive		Section 1.2. They are also encouraged to report disruptive
	behavior directed at them or someone else to an administrator of		behavior directed at them or someone else to an administrator of
	the respective forum *and* the moderators.		the respective forum *and* the moderators.
	* *Administrators* are primarily responsible for managing their fora		* *Administrators* are primarily responsible for managing their fora
	in accordance with procedures developed by the moderators and		in accordance with procedures developed by the moderators and
	approved by the IESG. As such, they shall address reports of		approved by the IESG. As such, they shall address reports of
	disruptive behavior in a timely fashion, apprising moderators of		disruptive behavior in a timely fashion, apprising moderators of
	reports or actions taken. Administrators may amend or rescind		reports or actions taken. Administrators may amend or rescind
	actions, including those taken by members of the moderation team		actions, including those taken by members of the moderation team
	*after* they have consulted with that team.		*after* they have consulted with that team.
	For a working group, chairs are by default the administrators.		For a working group, chairs are by default the administrators.
	They may delegate this responsibility in the same vein as		They may delegate this responsibility in the same vein as
	Section 6.4 of [RFC2418], but they must always accept,		Section 6.4 of [RFC2418], but they must always accept,
	acknowledge, and keep track of complaints of disruptive behavior.		acknowledge, and keep track of complaints of disruptive behavior.
	Forum administrators should perform moderation in a way that		Forum administrators should perform moderation in a way that
	obviates the need for moderator team involvement.		obviates the need for moderator team involvement.
	* *Moderators* are responsible for establishing procedures to		* *Moderators* are responsible for establishing procedures to
	address moderation needs across all IETF fora, both present and		address moderation needs across all IETF fora, both present and
	future. They are a resource that the community can use to address		future. They are a resource that the community can use to address
	disruptive behavior. The moderator team is responsible to the		disruptive behavior. The moderator team is responsible to the
	IESG. The IESG will create or designate a forum to facilitate		IESG. The IESG will create or designate a forum to facilitate
	discussion about moderation and refer interested parties to that		discussion about moderation and refer interested parties to that
	forum.		forum.
	Moderators may take actions when administrators do not respond to		Moderators may take actions when administrators do not respond to
	reports in a timely fashion. Their first action should generally		reports in a timely fashion. Their first action should generally
	be to attempt to contact and advise the relevant administrators.		be to attempt to contact and advise the relevant administrators.
	They should only take moderation actions when administrators are		They should only take moderation actions when administrators are
	not responsive or when someone disrupts multiple fora at the same		not responsive or when someone disrupts multiple fora at the same
	time. Moderators should generally give WG chairs the opportunity		time. Moderators should generally give WG chairs the opportunity
	to manage what may be difficult and contentious debates within		to manage what may be difficult and contentious debates within
	their groups. Within the bounds of this principle, it is left to		their groups. Within the bounds of this principle, it is left to
	moderators' judgment to determine when they must act, with the		moderators' judgment to determine when they must act, with the
	understanding that some situations may require fast responses.		understanding that some situations may require fast responses.
	Moderators must notify administrators of any actions they take.		Moderators must notify administrators of any actions they take.
	Section 4.1 discusses the handling of disagreements.		Section 4.1 discusses the handling of disagreements.
	Moderators are administrators for IETF plenary fora, currently		Moderators are administrators for IETF plenary fora, currently
	including the IETF discussion and Last Call lists and any plenary		including the IETF discussion and Last Call lists and any plenary
	chat sessions. They are also administrators for any forum that		chat sessions. They are also administrators for any forum that
	does not otherwise have an administrator.		does not otherwise have an administrator.
	In order to scale the function, except for plenary fora as		In order to scale the function, except for plenary fora as
	described above, moderators are not expected to always actively		described above, moderators are not expected to always actively
	monitor all communications. In general, they will process reports		monitor all communications. In general, they will process reports
	from participants.		from participants.
	* *Area directors* are expected to resolve conflicts as described		* *Area directors* are expected to resolve conflicts as described
	here and in Section 4.1. The IESG will periodically evaluate the		here and in Section 4.1. The IESG will periodically evaluate the
	performance and needs of moderators, and may appoint and recall		performance and needs of moderators, and may appoint and recall
	moderators as they deem appropriate. Apart from that, the IESG		moderators as they deem appropriate. Apart from that, the IESG
	shall refrain from the day-to-day operation and management of the		shall refrain from the day-to-day operation and management of the
	moderator team. The moderators may consult with the IESG when		moderator team. The moderators may consult with the IESG when
	needed.		needed.
	3.1. Actions That Are Out of Scope		3.1. Actions That Are Out of Scope
	Moderator actions are only permitted for the purposes of limiting		Moderator actions are only permitted for the purposes of limiting
	disruptive communications in online IETF fora. All other actions are		disruptive communications in online IETF fora. All other actions are
	beyond the scope of this memo. Examples of actions that are out of		beyond the scope of this memo. Examples of actions that are out of
	scope include, but are not limited to, Datatracker account removal;		scope include, but are not limited to, Datatracker account removal;
	restriction of in-person, virtual, or hybrid meeting participation;		restriction of in-person, virtual, or hybrid meeting participation;
	content removal or redaction; and moderation or policing of private		content removal or redaction; and moderation or policing of private
	or non-IETF communications. While the moderator team does not		or non-IETF communications. While the moderator team does not
	moderate non-public IETF mailing lists, the administrators of such		moderate non-public IETF mailing lists, the administrators of such
	lists can choose to adopt some of the procedures that the moderator		lists can choose to adopt some of the procedures that the moderator
	team develops.		team develops.
	3.2. Unsolicited Bulk Messages		3.2. Unsolicited Bulk Messages
	Unsolicited bulk messages are considered disruptive and should be		Unsolicited bulk messages are considered disruptive and should be
	handled in a manner consistent with the "IESG Statement on Spam		handled in a manner consistent with the "IESG Statement on Spam
	Control on IETF Mailing Lists" [IESG-SPAM] or its successors.		Control on IETF Mailing Lists" [IESG-SPAM] or its successors.
	Administrators and moderators may take similar actions in other fora		Administrators and moderators may take similar actions in other fora
	(e.g., GitHub or instant messaging). Such actions require no		(e.g., GitHub or instant messaging). Such actions require no
	additional reporting.		additional reporting.
	4. Moderation Procedures and Transparency		4. Moderation Procedures and Transparency
	Within the bounds of the policies set herein, the moderator team		Within the bounds of the policies set herein, the moderator team
	shall develop and maintain procedures and criteria relating to		shall develop and maintain procedures and criteria relating to
	moderation, including the moderator team's own operating procedures.		moderation, including the moderator team's own operating procedures.
	Those procedures and criteria shall be developed with community		Those procedures and criteria shall be developed with community
	input, be approved by the IESG prior to going into effect, and be		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.		made public. However, they need not be documented in the RFC Series.
	This shall be the first task for the moderator team. Until those		This shall be the first task for the moderator team. Until those
	procedures and criteria are established, all previous processes		procedures and criteria are established, all previous processes
	referenced in Section 1 shall remain in effect.		referenced in Section 1 shall remain in effect.
	The intent of this memo is to provide the widest possible freedom of		The intent of this memo is to provide the widest possible freedom of
	action to administrators and moderators, with the expectation that		action to administrators and moderators, with the expectation that
	the minimal actions necessary will be taken. Those who are directed		the minimal actions necessary will be taken. Those who are directed
	to stop disrupting a forum must do so immediately. Further		to stop disrupting a forum must do so immediately. Further
	disruptions may lead to further corrective actions.		disruptions may lead to further corrective actions.
	Examples of actions that could be taken include:		Examples of actions that could be taken include:
	* Automated rate-limiting mechanisms;		* Automated rate-limiting mechanisms;
	* Review and approval of submissions/messages;		* Review and approval of submissions/messages;
	* A private or public admonishment;		* A private or public admonishment;
	* Temporary or indefinite suspension of participation privileges in		* Temporary or indefinite suspension of participation privileges in
	one or more fora.		one or more fora.
	These are only examples and are not in any way prescriptive.		These are only examples and are not in any way prescriptive.
	Administrators and moderators are free to decide on these or other		Administrators and moderators are free to decide on these or other
	actions.		actions.
	All moderation actions that restrict participation privileges shall		All moderation actions that restrict participation privileges shall
	be immediately reported to those against whom those actions take		be immediately reported to those against whom those actions take
	effect, to relevant administrators, and to the moderator team for		effect, to relevant administrators, and to the moderator team for
	their review. They shall also be periodically reported to the IESG.		their review. They shall also be periodically reported to the IESG.
	Only moderation actions suspending participation privileges for		Only moderation actions suspending participation privileges for
	longer than fourteen (14) days must be reported to the forum to which		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		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,		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		it should be communicated to the community in a manner decided by the
	IESG.		IESG.
	Moderators will periodically provide an aggregate report to the		Moderators will periodically provide an aggregate report to the
	community on actions taken under this policy.		community on actions taken under this policy.
	4.1. Consistency and Conflict Resolution		4.1. Consistency and Conflict Resolution
	Administrators and moderators shall act in a manner consistent with		Administrators and moderators shall act in a manner consistent with
	this memo and the guidelines approved by the IESG. In cases of		this memo and the guidelines approved by the IESG. In cases of
	disagreement over a moderation decision, anyone may take the matter		disagreement over a moderation decision, anyone may take the matter
	up with the responsible area director for resolution, or with the		up with the responsible area director for resolution, or with the
	IETF Chair if a responsible area director cannot be determined or is		IETF Chair if a responsible area director cannot be determined or is
	not assigned. If the disagreement cannot be resolved by the area		not assigned. If the disagreement cannot be resolved by the area
	director, that person may then appeal to the IESG and subsequently to		director, that person may then appeal to the IESG and subsequently to
	the IAB using the processes stated in Sections 6.5.1 and 6.5.4 of		the IAB using the processes stated in Sections 6.5.1 and 6.5.4 of
	[RFC2026].		[RFC2026].
	4.2. Reinstatement		4.2. Reinstatement
	People and circumstances change. Individuals whose participation		People and circumstances change. Individuals whose participation
	privileges have been indefinitely suspended from a forum may request		privileges have been indefinitely suspended from a forum may request
	reinstatement. Requests for reinstatement may be made no earlier		reinstatement. Requests for reinstatement may be made no earlier
	than a year after the initial decision and then only annually		than a year after the initial decision and then only annually
	afterward.		afterward.
	Any such request must be directed to the entity who made the decision		Any such request must be directed to the entity who made the decision
	(e.g., moderator team, working group chairs, etc.) or their		(e.g., moderator team, working group chairs, etc.) or their
	successors. That party may at their discretion reinstate someone,		successors. That party may at their discretion reinstate someone,
	conditionally or unconditionally.		conditionally or unconditionally.
	To avoid denial-of-service attacks on IETF processes, decisions to		To avoid denial-of-service attacks on IETF processes, decisions to
	not reinstate someone's participation privileges may not be appealed.		not reinstate someone's participation privileges may not be appealed.
	Any reinstatement is a grace and not a right.		Any reinstatement is a grace and not a right.
	A suspension of participation privileges imposed prior to this		A suspension of participation privileges imposed prior to this
	process shall be reconsidered only in accordance with the processes		process shall be reconsidered only in accordance with the processes
	in place at the time of the suspension, even if the corresponding RFC		in place at the time of the suspension, even if the corresponding RFC
	has been formally obsoleted.		has been formally obsoleted.
	5. Relationship to Other IETF Functions		5. Relationship to Other IETF Functions
	5.1. Relation to the Ombudsteam		5.1. Relation to the Ombudsteam
	Administrators and moderators shall complement the efforts of the		Administrators and moderators shall complement the efforts of the
	IETF Ombudsteam [OT], whose focus on anti-harassment and operation		IETF Ombudsteam [OT], whose focus on anti-harassment shall remain
	shall remain unchanged. Administrators and moderators should always		unchanged. Administrators and moderators should always report
	report suspected harassment. They should nonetheless take any		suspected harassment. They should nonetheless take any necessary
	necessary actions regarding disruptive behavior.		actions regarding disruptive behavior.
	5.2. Relation to the IETF LLC		5.2. Relation to the IETF LLC
	The Board of Directors of the IETF Administration LLC (IETF LLC) has		The Board of Directors of the IETF Administration LLC (IETF LLC) has
	fiduciary duty for the overall organization, which includes the duty		fiduciary duty for the overall organization, which includes the duty
	to protect the organization from serious legal risk that may arise		to protect the organization from serious legal risk that may arise
	from the behavior of IETF participants.		from the behavior of IETF participants.
	This protection may include the need for the IETF LLC to take		This protection may include the need for the IETF LLC to take
	emergency moderation actions. These emergency actions are expected		emergency moderation actions. These emergency actions are expected
	to be taken only when the IETF LLC has received legal advice that		to be taken only when the IETF LLC has received legal advice that
	such action is necessary and therefore will be extremely rare in		such action is necessary and therefore will be extremely rare in
	frequency. Some examples of where this might be necessary are:		frequency. Some examples of where this might be necessary are:
	* Someone making a credible threat of harm to other IETF		* Someone making a credible threat of harm to other IETF
	participants.		participants.
	* Someone using IETF mailing lists and/or websites to share content		* Someone using IETF mailing lists and/or websites to share content
	where publishing that content on IETF lists and/or websites brings		where publishing that content on IETF lists and/or websites brings
	serious legal risk to the IETF.		serious legal risk to the IETF.
	* Someone making a credible threat of legal action where any form of		* Someone making a credible threat of legal action where any form of
	interaction with them on IETF mailing lists may have serious legal		interaction with them on IETF mailing lists may have serious legal
	consequences for the IETF.		consequences for the IETF.
	If any such action is taken, the IETF LLC should, except where		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		limited by legal advice to the contrary, inform the IESG as soon as
	possible, providing full details of the subject of the action, nature		possible, providing full details of the subject of the action, nature
	of the action, reason for the action, and the expected duration. The		of the action, reason for the action, and the expected duration. The
	IETF LLC should also inform the moderator team and IETF community,		IETF LLC should also inform the moderator team and IETF community,
	except where it receives legal advice to the contrary.		except where it receives legal advice to the contrary.
	As such an action would be taken by the IETF LLC in order to protect		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		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.		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		The subject of any such action may request a review by the IETF LLC
	Board, as documented in Section 4.7 of [RFC8711].		Board, as documented in Section 4.7 of [RFC8711].
	Any such action taken by the IETF LLC under this section of this		Any such action taken by the IETF LLC under this section of this
	policy is not subject to the rest of this policy.		policy is not subject to the rest of this policy.
	6. Security Considerations		6. Security Considerations
	The usual security considerations [RFC3552] do not apply to this		The usual security considerations [RFC3552] do not apply to this
	memo.		memo.
	There is the potential abuse of the moderation procedures by		There is the potential abuse of the moderation procedures by
	moderators, working group chairs, and potentially others that could		moderators, working group chairs, and potentially others that could
	lead to censorship of legitimate participation. This potential risk		lead to censorship of legitimate participation. This potential risk
	is mitigated in eight ways:		is mitigated in eight ways:
	1. Section 4 requires the moderator team to first establish		1. Section 4 requires the moderator team to first establish
	procedures that are intended to apply uniformly across the IETF.		procedures that are intended to apply uniformly across the IETF.
	2. Section 1.2 explicitly states that viewpoints outside the rough		2. Section 1.2 explicitly states that viewpoints outside the rough
	consensus are not in and of themselves disruptive.		consensus are not in and of themselves disruptive.
	3. Section 4 provides transparency by requiring that moderation		3. Section 4 provides transparency by requiring that moderation
	actions that restrict participation privileges be immediately		actions that restrict participation privileges be immediately
	reported to the affected person and to the moderation team, and		reported to the affected person and to the moderation team, and
	periodically reported to the IESG.		periodically reported to the IESG.
	4. Section 4 also requires that the community be informed in the		4. Section 4 also requires that the community be informed in the
	case of suspensions lasting longer than 14 days.		case of suspensions lasting longer than 14 days.
	5. Section 4.1 lays out an appeals process in the case of		5. Section 4.1 lays out an appeals process in the case of
	disagreements.		disagreements.
	6. If moderators find that the procedures themselves are leading to		6. If moderators find that the procedures themselves are leading to
	inappropriate moderation, Section 4 allows them to update those		inappropriate moderation, Section 4 allows them to update those
	procedures in consultation with the community and with the		procedures in consultation with the community and with the
	approval of the IESG.		approval of the IESG.
	7. If IETF participants believe that either the IESG or the IAB are		7. If IETF participants believe that either the IESG or the IAB are
	not performing their respective oversight functions as described		not performing their respective oversight functions as described
	in this document, they may comment to the NomCom [BCP10] or the		in this document, they may comment to the NomCom [BCP10] or the
	community at large.		community at large.
	8. Finally, if it appears that these processes are not functioning		8. Finally, if it appears that these processes are not functioning
	properly, the policies stated in this memo may be amended. They		properly, the policies stated in this memo may be amended. They
	are not set in stone.		are not set in stone.
	Moderation actions are intended to limit the likelihood of disruptive		Moderation actions are intended to limit the likelihood of disruptive
	behavior by a few IETF participants that may discourage participation		behavior by a few IETF participants that may discourage participation
	by other IETF participants.		by other IETF participants.
	7. IANA Considerations		7. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	9. References		8. References
	9.1. Normative References		8.1. Normative References
	[BCP10] Best Current Practice 10,		[BCP10] Best Current Practice 10,
	<https://www.rfc-editor.org/info/bcp10>.		<https://www.rfc-editor.org/info/bcp10>.
	At the time of writing, this BCP comprises the following:		At the time of writing, this BCP comprises the following:
	Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,		Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
	Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection,		Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection,
	Confirmation, and Recall Process: Operation of the IETF		Confirmation, and Recall Process: Operation of the IETF
	Nominating and Recall Committees", BCP 10, RFC 8713,		Nominating and Recall Committees", BCP 10, RFC 8713,
	DOI 10.17487/RFC8713, February 2020,		DOI 10.17487/RFC8713, February 2020,
	<https://www.rfc-editor.org/info/rfc8713>.		<https://www.rfc-editor.org/info/rfc8713>.
	Duke, M., "Nominating Committee Eligibility", BCP 10,		Duke, M., "Nominating Committee Eligibility", BCP 10,
	RFC 9389, DOI 10.17487/RFC9389, April 2023,		RFC 9389, DOI 10.17487/RFC9389, April 2023,
	<https://www.rfc-editor.org/info/rfc9389>.		<https://www.rfc-editor.org/info/rfc9389>.
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision		[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,		3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
	<https://www.rfc-editor.org/info/rfc2026>.		<https://www.rfc-editor.org/info/rfc2026>.
	[RFC2418] Bradner, S., "IETF Working Group Guidelines and		[RFC2418] Bradner, S., "IETF Working Group Guidelines and
	Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,		Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
	September 1998, <https://www.rfc-editor.org/info/rfc2418>.		September 1998, <https://www.rfc-editor.org/info/rfc2418>.
	[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",		[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
	BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,		BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
	<https://www.rfc-editor.org/info/rfc3935>.		<https://www.rfc-editor.org/info/rfc3935>.
	[RFC7154] Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54,		[RFC7154] Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54,
	RFC 7154, DOI 10.17487/RFC7154, March 2014,		RFC 7154, DOI 10.17487/RFC7154, March 2014,
	<https://www.rfc-editor.org/info/rfc7154>.		<https://www.rfc-editor.org/info/rfc7154>.
	[RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment		[RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment
	Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March		Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March
	2016, <https://www.rfc-editor.org/info/rfc7776>.		2016, <https://www.rfc-editor.org/info/rfc7776>.
	[RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of		[RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of
	the IETF Administrative Support Activity, Version 2.0",		the IETF Administrative Support Activity, Version 2.0",
	BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020,		BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020,
	<https://www.rfc-editor.org/info/rfc8711>.		<https://www.rfc-editor.org/info/rfc8711>.
	9.2. Informative References		8.2. Informative References
	[AHP] IESG, "IETF Anti-Harassment Policy", 3 November 2013,		[AHP] IESG, "IETF Anti-Harassment Policy", 3 November 2013,
	<https://www.ietf.org/about/groups/iesg/statements/anti-		<https://www.ietf.org/about/groups/iesg/statements/anti-
	harassment-policy/>.		harassment-policy/>.
	[DP] IESG, "IESG Statement on Disruptive Posting", 17 February		[DP] IESG, "IESG Statement on Disruptive Posting", 17 February
	2006, <https://www.ietf.org/about/groups/iesg/statements/		2006, <https://www.ietf.org/about/groups/iesg/statements/
	disruptive-posting/>.		disruptive-posting/>.
	[IESG-SPAM]		[IESG-SPAM]
	IESG, "IESG Statement on Spam Control on IETF Mailing		IESG, "IESG Statement on Spam Control on IETF Mailing
	Lists", 14 April 2008, <https://datatracker.ietf.org/doc/		Lists", 14 April 2008, <https://datatracker.ietf.org/doc/
	statement-iesg-iesg-statement-on-spam-control-on-ietf-		statement-iesg-iesg-statement-on-spam-control-on-ietf-
	mailing-lists-20080414/>.		mailing-lists-20080414/>.
	[MODML] IESG, "IESG Guidance on the Moderation of IETF Working		[MODML] IESG, "IESG Guidance on the Moderation of IETF Working
	Group Mailing Lists", 29 August 2000,		Group Mailing Lists", 29 August 2000,
	<https://www.ietf.org/about/groups/iesg/statements/		<https://www.ietf.org/about/groups/iesg/statements/
	mailing-lists-moderation/>.		mailing-lists-moderation/>.
	[OT] "Ombudsteam", <https://www.ietf.org/contact/ombudsteam/>.		[OT] "Ombudsteam", <https://www.ietf.org/contact/ombudsteam/>.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC		[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,		Text on Security Considerations", BCP 72, RFC 3552,
	DOI 10.17487/RFC3552, July 2003,		DOI 10.17487/RFC3552, July 2003,
	<https://www.rfc-editor.org/info/rfc3552>.		<https://www.rfc-editor.org/info/rfc3552>.
	[RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF		[RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF
	Mailing Lists", BCP 83, RFC 3683, DOI 10.17487/RFC3683,		Mailing Lists", BCP 83, RFC 3683, DOI 10.17487/RFC3683,
	March 2004, <https://www.rfc-editor.org/info/rfc3683>.		March 2004, <https://www.rfc-editor.org/info/rfc3683>.
	[RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the		[RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the
	Management of IETF Mailing Lists", BCP 25, RFC 3934,		Management of IETF Mailing Lists", BCP 25, RFC 3934,
	DOI 10.17487/RFC3934, October 2004,		DOI 10.17487/RFC3934, October 2004,
	<https://www.rfc-editor.org/info/rfc3934>.		<https://www.rfc-editor.org/info/rfc3934>.
	[RFC7282] Resnick, P., "On Consensus and Humming in the IETF",		[RFC7282] Resnick, P., "On Consensus and Humming in the IETF",
	RFC 7282, DOI 10.17487/RFC7282, June 2014,		RFC 7282, DOI 10.17487/RFC7282, June 2014,
	<https://www.rfc-editor.org/info/rfc7282>.		<https://www.rfc-editor.org/info/rfc7282>.
	[RFC9245] Eggert, L. and S. Harris, "IETF Discussion List Charter",		[RFC9245] Eggert, L. and S. Harris, "IETF Discussion List Charter",
	BCP 45, RFC 9245, DOI 10.17487/RFC9245, June 2022,		BCP 45, RFC 9245, DOI 10.17487/RFC9245, June 2022,
	<https://www.rfc-editor.org/info/rfc9245>.		<https://www.rfc-editor.org/info/rfc9245>.
	Appendix A. Motivation		Appendix A. Motivation
	Section 1 summarizes the process changes introduced by this memo.		Section 1 summarizes the process changes introduced by this memo.
	This appendix discusses the background that led to them.		This appendix discusses the background that led to them.
	A.1. Background		A.1. Background
	The IETF community has defined general guidelines for personal		The IETF community has defined general guidelines for personal
	interactions in the IETF [RFC7154]. The IESG has defined an anti-		interactions in the IETF [RFC7154]. The IESG has defined an anti-
	harassment policy for the IETF [AHP] for which the IETF community has		harassment policy for the IETF [AHP] for which the IETF community has
	defined anti-harassment procedures [RFC7776], empowering an		defined anti-harassment procedures [RFC7776], empowering an
	Ombudsteam [OT] to take necessary action.		Ombudsteam [OT] to take necessary action.
	Dealing with _disruptive_ behavior, however, is not part of the role		Dealing with _disruptive_ behavior, however, is not part of the role
	of the Ombudsteam. [RFC2418] tasks the chairs of each IETF working		of the Ombudsteam. [RFC2418] tasks the chairs of each IETF working
	group with moderating their group's in-person meetings while		group with moderating their group's in-person meetings while
	[RFC3934] provides chairs a procedure to help manage mailing lists.		[RFC3934] provides chairs a procedure to help manage mailing lists.
	An IESG statement [MODML] describes additional guidance to working		An IESG statement [MODML] describes additional guidance to working
	group chairs about how -- but not when -- to moderate their lists.		group chairs about how -- but not when -- to moderate their lists.
	For IETF mailing lists not associated with a working group, another		For IETF mailing lists not associated with a working group, another
	IESG statement [DP] clarifies that the IESG tasks list administrators		IESG statement [DP] clarifies that the IESG tasks list administrators
	with moderation. And the IETF list for general discussions has,		with moderation. And the IETF list for general discussions has,
	mostly for historic reasons, a team of moderators that are not list		mostly for historic reasons, a team of moderators that are not list
	administrators and operate by a different set of processes [RFC9245].		administrators and operate by a different set of processes [RFC9245].
	Note that the term "moderation" can refer both to _preemptive_		Note that the term "moderation" can refer both to _preemptive_
	moderation, where administrators review attempted participation		moderation, where administrators review attempted participation
	before it occurs (such as reviewing messages to a mailing list), and		before it occurs (such as reviewing messages to a mailing list), and
	_reactive_ moderation, where administrators intervene after		_reactive_ moderation, where administrators intervene after
	disruptive participation has occurred. Historically, the IETF has		disruptive participation has occurred. Historically, the IETF has
	mainly practiced reactive moderation, with a spectrum from gentle		mainly practiced reactive moderation, employing actions ranging from
	reminders on- and off-list, all the way to suspension of posting		gentle reminders on- and off-list, all the way to suspension of
	rights and other ways of participating or communicating. It is up to		posting rights and other ways of participating or communicating. It
	the moderators and administrators to decide which mix of preemptive		is up to the moderators and administrators to decide which mix of
	and reactive moderation to employ as part of their procedures.		preemptive and reactive moderation to employ as part of their
			procedures.
	In addition, [RFC3683] defines a process for revoking an individual's		In addition, [RFC3683] defines a process for revoking an individual's
	posting rights to IETF mailing lists following a community Last Call		posting rights to IETF mailing lists following a community Last Call
	of a "posting rights" action (PR-action) proposed by the IESG, often		of a "posting rights" action (PR-action) proposed by the IESG, often
	in response to complaints from the community.		in response to complaints from the community.
	Experience and community input suggests that an evolution of the		Experience and community input suggests that an evolution of the
	existing processes is necessary.		existing processes is necessary.
	A.2. Problems with the Previous Approach		A.2. Problems with the Previous Approach
	The previous approach to moderation of disruptive participation		The previous approach to moderation of disruptive participation
	through chairs, list administrators, and moderator teams, combined		through chairs, list administrators, and moderator teams, combined
	with the IESG-led process of PR-actions, has proven to be less than		with the IESG-led process of PR-actions, has proven to be less than
	ideal:		ideal:
	* The IETF community has not been able to agree on a common		* The IETF community has not been able to agree on a common
	definition of disruptive behavior. Therefore, chairs and list		definition of disruptive behavior. Therefore, chairs and list
	administrators apply individually different criteria when making		administrators apply individually different criteria when making
	decisions, and participants have different expectations for when		decisions, and participants have different expectations for when
	PR-actions are warranted.		PR-actions are warranted.
	* The moderation process that chairs and list administrators need to		* The moderation process that chairs and list administrators need to
	follow [RFC3934] is slow and cumbersome, which makes it ill-suited		follow [RFC3934] is slow and cumbersome, which makes it ill-suited
	to situations that escalate quickly. It also assumes that the		to situations that escalate quickly. It also assumes that the
	originator of disruptive behavior is a misguided participant who		originator of disruptive behavior is a misguided participant who
	can be reasoned with and who will change their ways.		can be reasoned with and who will change their ways.
	* Chairs and list administrators may only enact moderation actions		* Chairs and list administrators may only enact moderation actions
	for their single list, which is ill-suited when a pattern of		for their single list, which is ill-suited when a pattern of
	disruptive behavior spans multiple lists. Also, chairs and list		disruptive behavior spans multiple lists. Also, chairs and list
	administrators may not be fully aware of disruptive behavior that		administrators may not be fully aware of disruptive behavior that
	spans multiple lists, due to not being subscribed to some of them.		spans multiple lists, due to not being subscribed to some of them.
	* PR-actions, which can address disruptive behavior across several		* PR-actions, which can address disruptive behavior across several
	lists, are cumbersome, slow, and inconsistent. This has led to a		lists, are cumbersome, slow, and inconsistent. This has led to a
	situation where PR-actions are rarely used, and when they are		situation where PR-actions are rarely used, and when they are
	used, they are perceived as very heavy-handed.		used, they are perceived as very heavy-handed.
	* For a given mailing list, participants may not feel comfortable		* For a given mailing list, participants may not feel comfortable
	reporting disruptive behavior to a chair or list administrator,		reporting disruptive behavior to a chair or list administrator,
	for various reasons. For mailing lists not associated with		for various reasons. For mailing lists not associated with
	working groups, list administrators are not even publicly		working groups, list administrators are not even publicly
	identified -- they can only be contacted through an anonymous		identified -- they can only be contacted through an anonymous
	alias address. This exacerbates the problem, because participants		alias address. This exacerbates the problem, because participants
	may not be comfortable reporting disruptive behavior to an		may not be comfortable reporting disruptive behavior to an
	anonymous party.		anonymous party.
	* The IETF offers participation not only through in-person meetings		* Moderation processes have been defined for only two channels of
	and mailing lists, which are the two channels of participation for		participation in the IETF: in-person meetings and mailing lists.
	which moderation processes are currently defined. IETF business		However, IETF business now happens in a number of fora (e.g., chat
	also happens in chat groups, remote meeting participation systems,		groups, remote meeting participation systems, virtual meetings,
	virtual meetings, wikis, GitHub repositories, and more. How		wikis, and GitHub repositories). Procedures for moderating
	disruptive behavior is moderated in these fora is currently		disruptive behavior in these fora are currently undefined.
	undefined.
	Appendix B. Non-Normative Examples of Disruptive Behavior		Appendix B. Non-Normative Examples of Disruptive Behavior
	The list below describes some types of disruptive behavior, but it is		The list below describes some types of disruptive behavior, but it is
	non-exhaustive.		non-exhaustive.
	* Discussion of subjects unrelated to a forum's charter or scope;		* Discussion of subjects unrelated to a forum's charter or scope;
	* Uncivil commentary, regardless of the general subject;		* Uncivil commentary, regardless of the general subject;
	* Messages announcing conferences, events, or activities that are		* Messages announcing conferences, events, or activities that are
	not sponsored or endorsed by the Internet Society or IETF, unless		not sponsored or endorsed by the Internet Society or IETF, unless
	posted with prior approval of list administrators;		posted with prior approval of list administrators;
	* Repeatedly arguing counter to a WG charter that has been approved		* Repeatedly arguing counter to a WG charter that has been approved
	by the IESG; and		by the IESG; and
	* "Sealioning", where a participant makes incessant requests for		* "Sealioning", where a participant makes incessant requests for
	evidence or data, even while remaining superficially polite.		evidence or data, even while remaining superficially polite.
	These items are examples. Moderators and administrators may take		These items are examples. Moderators and administrators may take
	moderation actions for many other cases.		moderation actions for many other cases.
	The moderator team's task consists of subjective judgment calls.		The moderator team's task consists of subjective judgment calls.
	Behaviors not listed here might require moderation, and it is not		Behaviors not listed here might require moderation, and it is not
	possible to write a complete list of all such behaviors.		possible to write a complete list of all such behaviors.
	8. Acknowledgments		Acknowledgments
	This memo is based on two individual Internet-Drafts, draft-ecahc-		This memo is based on two individual Internet-Drafts, draft-ecahc-
	moderation (https://datatracker.ietf.org/doc/draft-ecahc-moderation/)		moderation (https://datatracker.ietf.org/doc/draft-ecahc-moderation/)
	authored by Lars Eggert, Alissa Cooper, Jari Arkko, Russ Housley, and		authored by Lars Eggert, Alissa Cooper, Jari Arkko, Russ Housley, and
	Brian E. Carpenter, and draft-lear-bcp83-replacement		Brian E. Carpenter, and draft-lear-bcp83-replacement
	(https://datatracker.ietf.org/doc/draft-lear-bcp83-replacement/)		(https://datatracker.ietf.org/doc/draft-lear-bcp83-replacement/)
	authored by Eliot Lear, Robert Wilton, Bron Gondwana, and John		authored by Eliot Lear, Robert Wilton, Bron Gondwana, and John
	R. Levine. Robert Sayre authored draft-sayre-modpod-excellent		R. Levine. Robert Sayre authored draft-sayre-modpod-excellent
	(https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/),		(https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/),
	which also originated ideas reflected in this work. Pete Resnick		which also originated ideas reflected in this work. Pete Resnick
	provided the basis for how the moderators interact with list/forum		provided the basis for how the moderators interact with list/forum
	leadership.		leadership.
	These individuals contributed additional improvements:		These individuals contributed additional improvements:
	* Alissa Cooper		* Alissa Cooper
	* Brian Carpenter		* Brian Carpenter
	* Chris Box		* Chris Box
	* Colin Perkins		* Colin Perkins
	* David Schinazi		* David Schinazi
			* Deb Cooley
			* Dhruv Dhody
	* Eric Rescorla		* Eric Rescorla
			* Éric Vyncke
			* Erik Kline
			* Harald Alvestrand
	* Jay Daley		* Jay Daley
	* Joel Halpern		* Joel Halpern
	* John Klensin		* John Klensin
	* John Scudder		* John Scudder
			* Lisa Dusseault
	* Martin Thomson		* Martin Thomson
	* Melinda Shore		* Melinda Shore
	* Michael Richardson		* Michael Richardson
			* Mike Bishop
			* Mohamed Boucadair
			* Murray Kucherawy
	* Nick Hilliard		* Nick Hilliard
			* Orie Steele
			* Paul Hoffman
			* Paul Wouters
	* Pete Resnick		* Pete Resnick
	* Rich Salz		* Rich Salz
	* Robert Sayre		* Robert Sayre
			* Robert Sparks
			* Roman Danyliw
	* Russ Housley		* Russ Housley
	* Sean Turner		* Sean Turner
	* Simon Josefsson		* Simon Josefsson
	* Stephen Farrell		* Stephen Farrell
	* Ted Lemon		* Ted Lemon
	* Tim Bray		* Tim Bray
	N.B., acknowledgment should not be taken as endorsement by the		N.B., acknowledgment should not be taken as endorsement by the
	individuals named above.		individuals named above.
	Authors' Addresses		Authors' Addresses
	Lars Eggert (editor)		Lars Eggert (editor)
	Mozilla		Mozilla
	Stenbergintie 12 B		Stenbergintie 12 B
	FI-02700 Kauniainen		FI-02700 Kauniainen
	Finland		Finland
	Email: lars@eggert.org		Email: lars@eggert.org
	URI: https://eggert.org/		URI: https://eggert.org/
	Eliot Lear (editor)		Eliot Lear (editor)
	Cisco Systems		Cisco Systems
	Richtistrasse 7		Richtistrasse 7
	CH-8304 Wallisellen		CH-8304 Wallisellen
	Switzerland		Switzerland
	Phone: +41 44 878 9200		Phone: +41 44 878 9200
	Email: lear@lear.ch		Email: lear@lear.ch
End of changes. 22 change blocks.
	38 lines changed or deleted		66 lines changed or added
This html diff was produced by rfcdiff 1.48.