rfc9945.original.md		rfc9945.md
	---		---
	title: "IETF Community Moderation"		title: "IETF Community Moderation"
	category: bcp		abbrev: "IETF Community Moderation"
			number: 9945
			seriesno: 245
	docname: draft-ietf-modpod-group-processes-latest		docname: draft-ietf-modpod-group-processes-latest
			category: bcp
	submissiontype: IETF		submissiontype: IETF
	number:
	date:
	consensus: true		consensus: true
	v: 3		ipr: trust200902
	obsoletes: 3683, 3934		obsoletes: 3683, 3934
	updates: 2418, 9245		updates: 2418, 9245
	venue:		pi: [toc, symrefs, sortrefs]
	mail: mod-discuss@ietf.org		v: 3
	github: larseggert/draft-ietf-modpod-group-processes		lang: en
	latest: https://larseggert.github.io/draft-ietf-modpod-group-processes/draft-ietf		date: 2026-02
	-modpod-group-processes.html		area: GEN
			workgroup: modpod
			keyword:
	author:		author:
	-		-
	name: Lars Eggert		name: Lars Eggert
	role: editor		role: editor
	org: Mozilla		org: Mozilla
	street: Stenbergintie 12 B		street: Stenbergintie 12 B
	city: Kauniainen		city: Kauniainen
	code: "02700"		code: "02700"
	country: FI		country: FI
	email: lars@eggert.org		email: lars@eggert.org
	uri: <https://eggert.org/>		uri: https://eggert.org/
	-		-
	name: Eliot Lear		name: Eliot Lear
	role: editor		role: editor
	org: Cisco Systems		org: Cisco Systems
	street: Richtistrasse 7		street: Richtistrasse 7
	code: "8304"		code: "8304"
	city: Wallisellen		city: Wallisellen
	country: Switzerland		country: Switzerland
	phone: "+41 44 878 9200"		phone: "+41 44 878 9200"
	email: lear@lear.ch		email: lear@lear.ch
	normative:		normative:
	informative:		informative:
	IESG-SPAM:		IESG-SPAM:
	title: IESG Statement on Spam Control on IETF Mailing Lists		title: IESG Statement on Spam Control on IETF Mailing Lists
	date: 2008-04-18		date: 2008-04-14
	author:		author:
	- org: IESG		- org: IESG
	target: https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-spam-co ntrol-on-ietf-mailing-lists-20080414/		target: https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-spam-co ntrol-on-ietf-mailing-lists-20080414/
	AHP:		AHP:
	title: IETF Anti-Harassment Policy		title: IETF Anti-Harassment Policy
	date: 2013-11-03		date: 2013-11-03
	author:		author:
	- org: IESG		- org: IESG
	target: https://www.ietf.org/about/groups/iesg/statements/anti-harassment-policy/		target: https://www.ietf.org/about/groups/iesg/statements/anti-harassment-policy/
	OT:		OT:
	skipping to change at line 68 ¶		skipping to change at line 70 ¶
	date: false		date: false
	target: https://www.ietf.org/contact/ombudsteam/		target: https://www.ietf.org/contact/ombudsteam/
	MODML:		MODML:
	title: IESG Guidance on the Moderation of IETF Working Group Mailing Lists		title: IESG Guidance on the Moderation of IETF Working Group Mailing Lists
	date: 2000-08-29		date: 2000-08-29
	author:		author:
	- org: IESG		- org: IESG
	target: https://www.ietf.org/about/groups/iesg/statements/mailing-lists-moderatio n/		target: https://www.ietf.org/about/groups/iesg/statements/mailing-lists-moderatio n/
	DP:		DP:
	title: IESG Statement on Disruptive Posting		title: IESG Statement on Disruptive Posting
	date: 2006-02-16		date: 2006-02-17
	author:		author:
	- org: IESG		- org: IESG
	target: https://www.ietf.org/about/groups/iesg/statements/disruptive-posting/		target: https://www.ietf.org/about/groups/iesg/statements/disruptive-posting/
	--- abstract		--- abstract
	The IETF community will treat people with kindness and grace, but not endless patienc e.		The IETF community will treat people with kindness and grace, but not endless patienc e.
	This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and 9245		This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and 9245 by
	establishing a policy for the moderation of disruptive		establishing a policy for the moderation of disruptive
	participation		participation
	across the IETF's various public contribution channels and discussion fora.		across the IETF's various public contribution channels and discussion fora.
	It establishes guardrails		It establishes guardrails
	for moderation and a moderator team. That team will develop a		for moderation and a moderator team. That team will develop a
	set of moderation procedures and facilitate their consistent implementation with		set of moderation procedures and facilitate their consistent implementation with
	chairs and administrators.		chairs and administrators.
	--- middle		--- middle
	# Introduction		# Introduction
	skipping to change at line 102 ¶		skipping to change at line 104 ¶
	It creates a		It creates a
	moderator team to develop procedures and to facilitate their consistent		moderator team to develop procedures and to facilitate their consistent
	application.		application.
	This memo obsoletes and updates some prior IETF processes, summarized here.		This memo obsoletes and updates some prior IETF processes, summarized here.
	Background information is described in more detail in {{motivation}}.		Background information is described in more detail in {{motivation}}.
	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
	are 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		{{Section 4 of ?RFC9245}}, as the moderator team replaces the
	IETF discussion list moderation team.		IETF discussion list moderation 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		activities, and not to other related organizations, such as
	the Internet Research Task Force (IRTF),		the Internet Research Task Force (IRTF),
	the Internet Architecture Board (IAB),		the Internet Architecture Board (IAB),
	the RFC Series Working Group (RSWG), the RFC Series Approval Board (RSAB),		the RFC Series Working Group (RSWG), the RFC Series Approval Board (RSAB),
	or the Independent RFC Submission Stream, without their explicit agreement.		or the Independent RFC Submission Stream, without their explicit agreement.
	These changes take effect when the procedures described		These changes take effect when the procedures described
	in {{prod}} have been approved by the IESG.		in {{prod}} have been approved by the IESG.
	## Terminology Note		## Terminology Note
	Below, 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"		channel or discussion forum. This memo uses the term "forum"
	to refer to any public IETF participation channel, such as a mailing list,		to refer to any public IETF participation channel, such as a mailing list,
	chat group, or discussion in a collaborative tool such as GitHub or		chat group, or discussion in a collaborative tool such as GitHub or
	GitLab. For example, working		GitLab. For example, working
	group chairs are administrators of all the public fora that their working groups		group chairs are administrators of all the public fora that their working groups
	use, which typically includes mailing lists and chat groups, but might		use, which typically includes mailing lists and chat groups, but might
	also include collaborative tools such as GitHub or GitLab. Another example		also include collaborative tools such as GitHub or GitLab.
	of administrators are the "owners" of non-WG IETF mailing lists.		The "owners" of non-WG IETF mailing lists are another example of administrators.
	## General Philosophy {#genphil}		## General Philosophy {#genphil}
	This policy's cornerstone is that individuals are responsible for		This cornerstone of this policy is that individuals are responsible for
	furthering the goals of the IETF as an organization {{!RFC3935}}		furthering the goals of the IETF as an organization {{!RFC3935}}
	in a manner consistent with the policy laid out in {{!RFC7154}}.		in a manner consistent with the policy laid out in {{!RFC7154}}.
	Disagreement and diverse points of view within any standards organization		Disagreement and diverse points of view within any standards organization
	are to be expected, and are even healthy.		are to be expected and are even healthy.
	The IETF is an open standards organization with a discussion-based rough		The IETF is an open standards organization with a discussion-based rough
	consensus process, a non-normative description of which is in {{?RFC7282}}.		consensus process, a non-normative description of which is in {{?RFC7282}}.
	Engaged, respectful discussion that is within the scope of an IETF forum		Engaged, respectful discussion that is within the scope of an IETF forum
	should therefore not be considered disruptive,		should therefore not be considered disruptive,
	nor should someone be considered disruptive solely because they are outside		nor should someone be considered disruptive solely because they are outside
	the rough consensus.		the rough consensus.
	However, when someone crosses the line		However, when someone crosses the line
	into disruptive behavior, some action must be taken in order to maintain		into 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 across all public		- Apply consistent, fair, and timely moderation of communication across all public
	online IETF participation channels and participation fora		online IETF participation channels and participation fora
	without regard to a participant's role in the IETF or previous technical		without regard to a participant's role in the IETF or previous technical
	contributions;		contributions;
	- Appeals are available to address disagreements about moderation actions;		- Ensure appeals are available to address disagreements about moderation actions;
	- Balance transparency against both privacy of individuals involved and further		- Balance transparency against both privacy of individuals involved and further
	disruption to the community;		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 moderation, so		- Provide the broadest possible latitude to all people doing moderation, so
	that they have the flexibility to address a broad range of individuals		that they have the flexibility to address a broad range of individuals
	and circumstances.		and circumstances.
	Questions about processes detailed below should be answered through the lens		Questions about the processes detailed below should be answered through the lens
	of these aims.		of these aims.
	The goal is explicitly **not** punishment, but to maintain an open, welcoming,		The objective is explicitly **not** punishment, but to maintain an open,
	non-hostile environment in which all may participate on an equal footing,		welcoming, non-hostile environment in which all may participate on an
	regardless of their role in the IETF or past technical contributions.		equal footing, regardless of their role in the IETF or past technical
			contributions.
	# IETF Moderator Team		# IETF Moderator Team
	This memo defines a consistent approach to moderating the		This memo defines a consistent approach to moderating the
	IETF's various public online fora. A moderator team for the IETF		IETF's various public online fora. A moderator team for the IETF
	will develop and maintain guidelines for moderation and will facilitate		will 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		These changes are intended to address the issues identified
	in the previous model {{motive}} and the principles described in the		in the previous model (see {{motive}}) and the principles described in the
	introduction.		introduction.
	## Composition		## Composition
	The IESG appoints and recalls moderators.		The IESG appoints and recalls moderators.
	The moderator team initially consists of no fewer than five individuals.		The moderator team initially consists of no fewer than five individuals.
	The moderator team may expand or contract		The moderator team may expand or contract
	based on operational experience.		based on operational experience.
	In selecting members, the IESG will take into		In selecting members, the IESG will take into
	account geographic coverage, expected and unexpected absences, and		account geographic coverage, expected and unexpected absences, and
	team diversity.		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 {{appeals}}), the IESG must not appoint a		decisions (see {{appeals}}), the IESG must not appoint a
	moderator who is serving on the IESG or IAB. Individuals serving on		moderator who is serving on the IESG or IAB. Individuals serving on
	other bodies to which the NomCom appoints members, such as the IETF		other bodies to which the NomCom appoints members, such as the IETF
	Trust or the LLC Board, as well as LLC staff and contractors shall		Trust or the LLC Board, as well as LLC staff and contractors, shall
	also be excluded from serving on the moderator team. If a moderator		also be excluded from serving on the moderator team. If a moderator
	is assuming any such role, they shall step down from the moderator team		assumes any such role, they shall step down from the moderator team
	soon after.		soon after.
	### Team Diversity		### 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.
	skipping to change at line 230 ¶		skipping to change at line 233 ¶
	# Scope and Responsibilities		# 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 a manner discussed in		- **Participants** should always behave in the manner discussed in
	{{genphil}}. They are also encouraged to report disruptive behavior		{{genphil}}. They are also encouraged to report disruptive behavior
	directed at them or someone else to an administrator of the respective		directed at them or someone else to an administrator of the respective
	forum **and** the moderators.		forum **and** the moderators.
	- **Administrators** are primarily responsible for managing their fora in		- **Administrators** are primarily responsible for managing their fora in
	accordance with procedures developed by the moderators and approved by		accordance with procedures developed by the moderators and approved by
	the IESG. As such, they shall address reports of disruptive behavior		the IESG. As such, they shall address reports of disruptive behavior
	in a timely fashion, apprising moderators of reports or actions taken.		in a timely fashion, apprising moderators of reports or actions taken.
	Administrators may amend or rescind actions, including those taken by		Administrators may amend or rescind actions, including those taken by
	members of the moderation team **after** they have consulted with that team.		members of the moderation team **after** they have consulted with that team.
	For a working group, chairs are by default the administrators. They may		For a working group, chairs are by default the administrators. They may
	delegate this responsibility in the same vein as {{Section 6.4 of RFC2418}}		delegate this responsibility in the same vein as {{Section 6.4 of RFC2418}},
	but they must always accept, acknowledge,		but they must always accept, acknowledge,
	and keep track of complaints of disruptive behavior.		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		future. They are a resource that the community
	can use to address disruptive behavior.		can use to address disruptive behavior.
	The moderator team is responsible to the IESG. The IESG		The moderator team is responsible to the IESG. The IESG
	will create or designate a forum to facilitate discussion about		will create or designate a forum to facilitate discussion about
	moderation, and refer interested parties to that forum.		moderation and refer interested parties to that 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 be		reports in a timely fashion. Their first action should generally be
	to attempt to contact and advise the relevant administrators.		to attempt to contact and advise the relevant administrators.
	They should only take		They should only take
	moderation actions when administrators are not responsive, or when		moderation actions when administrators are not responsive or when
	someone disrupts multiple fora at the same time. Moderators should		someone disrupts multiple fora at the same time. Moderators should
	generally give WG chairs the opportunity to		generally give WG chairs the opportunity to
	manage what may be difficult and contentious debates within their		manage what may be difficult and contentious debates within their
	groups. Within the bounds of this principle, it is left to		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.
	{{appeals}} discusses the handling of disagreements.		{{appeals}} discusses the handling of disagreements.
	Moderators are administrators for IETF		Moderators are administrators for IETF
	plenary fora, currently including the IETF discussion and last-call		plenary fora, currently including the IETF discussion and Last Call
	lists and any plenary chat sessions. They are also administrators for		lists and any plenary chat sessions. They are also administrators for
	any forum that does not otherwise have an administrator.		any forum that does not otherwise have an administrator.
	In order to scale the function, except for plenary fora as described		In order to scale the function, except for plenary fora as described
	above, moderators are not expected to always actively monitor		above, moderators are not expected to always actively monitor
	all communications. In general, they will process reports from		all communications. In general, they will process reports from
	participants.		participants.
	- **Area Directors** are expected to resolve conflicts as described here and		- **Area directors** are expected to resolve conflicts as described here and
	in {{appeals}}. The IESG will periodically evaluate the performance		in {{appeals}}. The IESG will periodically evaluate the performance
	and needs of moderators, and may appoint and recall moderators as		and needs of moderators, and may appoint and recall moderators as
	they deem appropriate. Apart from that,		they deem appropriate. Apart from that,
	the IESG shall refrain from the day-to-day operation		the IESG shall refrain from the day-to-day operation
	and management of the moderator team. The moderators may		and management of the moderator team. The moderators may
	consult with the IESG when needed.		consult with the IESG when needed.
	## Actions That Are Out of Scope		## 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
	skipping to change at line 305 ¶		skipping to change at line 308 ¶
	virtual, or hybrid		virtual, or hybrid
	meeting participation; content removal or redaction; and moderation or		meeting participation; content removal or redaction; and moderation or
	policing of private or non-IETF communications.		policing of private or non-IETF communications.
	While the moderator team does not moderate non-public IETF mailing		While the moderator team does not moderate non-public IETF mailing
	lists, the administrators of such lists can choose to adopt some of the		lists, the administrators of such lists can choose to adopt some of the
	procedures that the moderator team develops.		procedures that the moderator team develops.
	## Unsolicited Bulk Messages		## Unsolicited Bulk Messages
	Unsolicited bulk messages are considered disruptive and should be handled in a		Unsolicited bulk messages are considered disruptive and should be handled in a
	manner consistent with the IESG statement on IETF Spam Control on IETF		manner consistent with the "IESG Statement on Spam Control on IETF Mailing Lists"
	Mailing Lists{{IESG-SPAM}}, or its successors. Administrators and moderators		{{IESG-SPAM}} or its successors. Administrators and moderators
	may take similar actions in other fora (e.g., GitHub or Instant Messaging).		may take similar actions in other fora (e.g., GitHub or instant messaging).
	Such actions require no additional reporting.		Such actions require no additional reporting.
	# Moderation Procedures and Transparency {#prod}		# Moderation Procedures and Transparency {#prod}
	Within the bounds of the policies set herein, the moderator team shall develop		Within the bounds of the policies set herein, the moderator team shall develop
	and maintain procedures and criteria relating to moderation, including		and maintain procedures and criteria relating to moderation, including
	the moderator team's own operating procedures.		the moderator team's own operating procedures.
	Those procedures and criteria shall be developed with community input,		Those procedures and criteria shall be developed with community input,
	be approved by the IESG prior to going into effect,		be approved by the IESG prior to going into effect,
	and be made public. However, they need not be documented in the RFC series. This		and be made public. However, they need not be documented in the RFC Series. This
	shall be the first task for the moderator team. Until		shall be the first task for the moderator team. Until
	those procedures and criteria are established, all previous processes		those procedures and criteria are established, all previous processes
	referenced in {{introduction}} shall remain in effect.		referenced in {{introduction}} 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.		to stop disrupting a forum must do so immediately.
	Further disruptions may lead to further corrective actions.		Further 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		- Temporary or indefinite suspension of participation privileges
	in one or more fora.		in one or more fora.
	These are only examples, and not in any way		These are only examples and are not in any way
	prescriptive. Administrators and moderators are free to decide on		prescriptive. Administrators and moderators are free to decide on
	these or other actions.		these or other actions.
	All moderation actions that restrict participation		All moderation actions that restrict participation
	privileges shall be immediately reported to those against		privileges shall be immediately reported to those against
	whom those actions take effect, to relevant administrators,		whom those actions take effect, to relevant administrators,
	and to the moderator team for		and to the moderator team for
	their review. They shall also be periodically reported to		their review. They shall also be periodically reported to
	the IESG.		the IESG.
	skipping to change at line 362 ¶		skipping to change at line 365 ¶
	the community in a manner decided by the IESG.		the community in a manner decided by the IESG.
	Moderators will periodically provide an aggregate report to the community on		Moderators will periodically provide an aggregate report to the community on
	actions taken under this policy.		actions taken under this policy.
	## Consistency and Conflict Resolution {#appeals}		## Consistency and Conflict Resolution {#appeals}
	Administrators and moderators shall act in a manner		Administrators and moderators shall act in a manner
	consistent with this memo and the guidelines approved by the IESG. In cases		consistent with this memo and the guidelines approved by the IESG. In cases
	of disagreement over a moderation decision, anyone may take the matter up		of disagreement over a moderation decision, anyone may take the matter up
	with the responsible Area Director for resolution, or with the IETF chair		with the responsible area director for resolution, or with the IETF Chair
	if a responsible Area Director cannot be determined or is not assigned.		if a responsible area director cannot be determined or is not assigned.
	If the disagreement cannot be resolved by the Area Director, that person may		If the disagreement cannot be resolved by the area director, that person may
	then appeal to the IESG, and subsequently to the IAB using the processes		then appeal to the IESG and subsequently to the IAB using the processes
	stated in {{Sections 6.5.1 and 6.5.4 of !RFC2026}}.		stated in {{Sections 6.5.1 and 6.5.4 of !RFC2026}}.
	## Reinstatement		## 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.		reinstatement.
	Requests for reinstatement		Requests for reinstatement
	may be made no earlier than a year after the initial decision, and then		may be made no earlier than a year after the initial decision and then
	only annually afterward.		only annually afterward.
	Any such request must be		Any such request must be
	directed to the entity who made the decision (e.g., moderator team,		directed to the entity who made the decision (e.g., moderator team,
	working group chairs, etc.) or their successors. That party may at		working group chairs, etc.) or their successors. That party may at
	their discretion		their discretion
	reinstate someone, conditionally or unconditionally.		reinstate someone, conditionally or unconditionally.
	To avoid		To avoid
	denial-of-service attacks on IETF processes, decisions to not reinstate		denial-of-service attacks on IETF processes, decisions to not reinstate
	someone's participation privileges may not be appealed.		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 process		A suspension of participation privileges imposed prior to this process
	shall be reconsidered only in		shall be reconsidered only in
	accordance with the processes in place at the time of the suspension,		accordance with the processes in place at the time of the suspension,
	even if the corresponding RFC has been formally obsoleted.		even if the corresponding RFC has been formally obsoleted.
	# Relationship to other IETF functions		# Relationship to Other IETF Functions
	## Relation to the Ombudsteam		## Relation to the Ombudsteam
	Administrators and moderators shall complement the efforts of the IETF		Administrators and moderators shall complement the efforts of the IETF
	ombudsteam {{OT}}, whose focus on anti-harassment and operation		Ombudsteam {{OT}}, whose focus on anti-harassment and operation
	shall remain unchanged. Administrators and moderators should always		shall remain unchanged. Administrators and moderators should always
	report suspected harassment. They should nonetheless take any		report suspected harassment. They should nonetheless take any
	necessary actions regarding disruptive behavior.		necessary actions regarding disruptive behavior.
	## Relation to the IETF LLC		## 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 to		emergency moderation actions. These emergency actions are expected to
	be taken only when the IETF LLC has received legal advice that such		be taken only when the IETF LLC has received legal advice that such
	action is necessary, and therefore extremely rare in frequency. Some		action is necessary and therefore will be extremely rare in frequency. Some
	examples of where this might be necessary are:		examples of where this might be necessary are:
	- Someone making a credible threat of harm to other IETF participants.		- Someone making a credible threat of harm to other IETF 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 expected duration. The IETF		of the action, reason for the action, and the expected duration. The IETF
	LLC should also inform the moderator team and IETF community, except		LLC should also inform the moderator team and IETF community, except
	where it receives legal advice to the contrary.		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.
	# Security Considerations		# 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 moderators,		There is the potential abuse of the moderation procedures by moderators,
	skipping to change at line 458 ¶		skipping to change at line 461 ¶
	eight ways:		eight ways:
	1. {{prod}} requires the moderator team to first establish procedures		1. {{prod}} requires the moderator team to first establish procedures
	that are intended to apply uniformly across the IETF.		that are intended to apply uniformly across the IETF.
	2. {{genphil}} explicitly states that viewpoints outside the rough		2. {{genphil}} explicitly states that viewpoints outside the rough
	consensus are not in and of themselves disruptive.		consensus are not in and of themselves disruptive.
	3. {{prod}} provides transparency by requiring that moderation actions		3. {{prod}} provides transparency by requiring that moderation actions
	that restrict participation privileges be immediately reported		that restrict participation privileges be immediately reported
	to the affected person and to the moderation team, and		to the affected person and to the moderation team, and
	periodically reported to the IESG.		periodically reported to the IESG.
	4. That same section requires that the community be informed in the case		4. {{prod}} also requires that the community be informed in the case
	of suspensions lasting longer than 14 days.		of suspensions lasting longer than 14 days.
	5. {{appeals}} lays out an appeals process in the case of		5. {{appeals}} 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, {{prod}} allows them to update those procedures		inappropriate moderation, {{prod}} allows them to update those procedures
	in consultation with the community, and with the approval of the IESG.		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		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		their respective oversight functions as described in this document, they may
	comment to the NomCom {{!BCP10}} or the community at large.		comment to the NomCom {{!BCP10}} or the 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.		properly, the policies stated in this memo may be amended.
	They are not set in stone.		They are not set in stone.
	Moderation actions are intended to limit the likelihood		Moderation actions are intended to limit the likelihood
	of disruptive behavior by a few IETF participants from discouraging		of disruptive behavior by a few IETF participants that may discourage
	participation by other IETF participants.		participation by other IETF participants.
	# IANA Considerations		# IANA Considerations
	No IANA actions are requested.		This document has no IANA actions.
	# Acknowledgments		# Acknowledgments
	This memo is based on two individual Internet-Drafts,		This memo is based on two individual Internet-Drafts,
	[draft-ecahc-moderation](<https://datatracker.ietf.org/doc/draft-ecahc-moderation/>)		[draft-ecahc-moderation](<https://datatracker.ietf.org/doc/draft-ecahc-moderation/>)
	authored by Lars Eggert, Alissa Cooper, Jari Arkko, Russ Housley and Brian E.		authored by {{{Lars Eggert}}}, {{{Alissa Cooper}}}, {{{Jari Arkko}}}, {{{Russ Housley
	Carpenter, and		}}}, and {{{Brian E.
			Carpenter}}}, and
	[draft-lear-bcp83-replacement](<https://datatracker.ietf.org/doc/draft-lear-bcp83-rep lacement/>)		[draft-lear-bcp83-replacement](<https://datatracker.ietf.org/doc/draft-lear-bcp83-rep lacement/>)
	authored by Eliot Lear, Robert Wilton, Bron Gondwana and John R. Levine.		authored by {{{Eliot Lear}}}, {{{Robert Wilton}}}, {{{Bron Gondwana}}}, and {{{John R
	Robert Sayre authored		. Levine}}}.
			{{{Robert Sayre}}} authored
	[draft-sayre-modpod-excellent](<https://datatracker.ietf.org/doc/draft-sayre-modpod-e xcellent/>),		[draft-sayre-modpod-excellent](<https://datatracker.ietf.org/doc/draft-sayre-modpod-e xcellent/>),
	which also originated ideas reflected in this work. Pete Resnick provided the		which also originated ideas reflected in this work. {{{Pete Resnick}}} provided the
	basis for how the moderators interact with list/forum leadership.		basis for how the moderators interact with list/forum 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}}}
	- Eric Rescorla		- {{{Eric Rescorla}}}
	- Jay Daley		- {{{Jay Daley}}}
	- Joel Halpern		- {{{Joel Halpern}}}
	- John Klensin		- {{{John Klensin}}}
	- John Scudder		- {{{John Scudder}}}
	- Martin Thomson		- {{{Martin Thomson}}}
	- Melinda Shore		- {{{Melinda Shore}}}
	- Michael Richardson		- {{{Michael Richardson}}}
	- Nick Hilliard		- {{{Nick Hilliard}}}
	- Pete Resnick		- {{{Pete Resnick}}}
	- Rich Salz		- {{{Rich Salz}}}
	- Robert Sayre		- {{{Robert Sayre}}}
	- Russ Housley		- {{{Russ Housley}}}
	- Sean Turner		- {{{Sean Turner}}}
	- Simon Josefsson		- {{{Simon Josefsson}}}
	- Stephen Farrell		- {{{Stephen Farrell}}}
	- Ted Lemon		- {{{Ted Lemon}}}
	- Tim Bray		- {{{Tim Bray}}}
	<span class="insert">{{{Tim Bray}}}</span>
	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.
	--- back		--- back
	# Change History of this I-D
	{:aside}
	> RFC Editor: Please remove this appendix before publication.
	## Since draft-ietf-modpod-group-processes-11
	- [clarify when changes take effect](https://github.com/larseggert/draft-ietf-modpod-
	group-processes/pull/238/)
	- [Refine security considerations](https://github.com/larseggert/draft-ietf-modpod-gr
	oup-processes/pull/239)
	- [Multi group and moderator reversal](https://github.com/larseggert/draft-ietf-modpo
	d-group-processes/pull/257/files)
	- [Last(?) bits from 2nd last call](https://github.com/larseggert/draft-ietf-modpod-g
	roup-processes/pull/258)
	## Since draft-ietf-modpod-group-processes-10
	- Many editorial suggestions received during WGLC.
	- [remove attendee mailing lists from moderator primary responsibility](https://githu
	b.com/larseggert/draft-ietf-modpod-group-processes/pull/181)
	- [Correct reference to appeals process.](https://github.com/larseggert/draft-ietf-mo
	dpod-group-processes/pull/149)
	[Also this.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/2
	30)
	- [Clarify fora that are out of scope.](https://github.com/larseggert/draft-ietf-modp
	od-group-processes/pull/197)
	[Incl. attendees' lists.](https://github.com/larseggert/draft-ietf-modpod-group-pro
	cesses/pull/181)
	[Also this.](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/2
	35)
	- [Clarify WG chairs are default admins but can delegate.](https://github.com/larsegg
	ert/draft-ietf-modpod-group-processes/pull/220)
	- [Mod team size guidance.](https://github.com/larseggert/draft-ietf-modpod-group-pro
	cesses/pull/231)
	- [Chair immediately notify mods and affected parties.](https://github.com/larseggert
	/draft-ietf-modpod-group-processes/pull/229)
	- [Add all of the available mitigations to risks of censorship.](https://github.com/l
	arseggert/draft-ietf-modpod-group-processes/pull/232)
	- [Clarify AD responsibilities.](https://github.com/larseggert/draft-ietf-modpod-grou
	p-processes/pull/234)
	## Since draft-ietf-modpod-group-processes-09
	- [Try to find another happy medium on power of moderators](https://github.com/larseg
	gert/draft-ietf-modpod-group-processes/pull/147)
	## Since draft-ietf-modpod-group-processes-08
	- [Address timeliness and exisgent circumstances](https://github.com/larseggert/draft
	-ietf-modpod-group-processes/issues/142)
	- [Make clear that moderators should use their judgment on timing](https://github.com
	/larseggert/draft-ietf-modpod-group-processes/pull/143)
	## Since draft-ietf-modpod-group-processes-07
	- [Pete Resnick issues and similar](https://github.com/larseggert/draft-ietf-modpod-g
	roup-processes/issues/134)
	- [Includes changes to abstract, intro, tweaks to make relationship
	between admins/WG chairs clearer; makes roles clearer,
	moderation team → moderator team.](https://github.com/larseggert/draft-ietf-modpod-
	group-processes/pull/135)
	## Since draft-ietf-modmod-group-processes-06
	- [Normalize handling of moderation across all fora](https://github.com/larseggert/dr
	aft-ietf-modpod-group-processes/pull/129)
	- [Obsolete RFC 3934, explicit admin responsibility](https://github.com/larseggert/dr
	aft-ietf-modpod-group-processes/pull/132)
	## Since draft-ietf-modpod-group-processes-05
	- [New attempt to address moderation/WG interactions](https://github.com/larseggert/d
	raft-ietf-modpod-group-processes/pull/126)
	## Since draft-ietf-modpod-group-processes-04
	- [Use plain English instead of BCP 14 language](https://github.com/larseggert/draft-
	ietf-modpod-group-processes/pull/120)
	## Since draft-ietf-modpod-group-processes-03
	- [Non-normative Examples of Disruptive Behavior](https://github.com/larseggert/draft
	-ietf-modpod-group-processes/pull/121)
	## Since draft-ietf-modpod-group-processes-02
	- [Say which RFCs this obsoletes and updates.](https://github.com/larseggert/draft-ie
	tf-modpod-group-processes/pull/105
	)
	- [Address issue 113](https://github.com/larseggert/draft-ietf-modpod-group-processes
	/pull/116)
	- [Rewrite philosophy](https://github.com/larseggert/draft-ietf-modpod-group-processe
	s/pull/103)
	- [Reinstatement](https://github.com/larseggert/draft-ietf-modpod-group-processes/pul
	l/107)
	- [Content removal is not moderation.](https://github.com/larseggert/draft-ietf-modpo
	d-group-processes/pull/109)
	## Since draft-ietf-modpod-group-processes-01
	- [Update "Relation to the IETF LLC".](https://github.com/larseggert/draft-ietf-modpo
	d-group-processes/pull/92)
	- [Point to relevant IRTF material.](https://github.com/larseggert/draft-ietf-modpod-
	group-processes/pull/97)
	- [Add some text to explain the role of moderators.](https://github.com/larseggert/dr
	aft-ietf-modpod-group-processes/pull/100)
	## Since draft-ietf-modpod-group-processes-00
	- [Spelling fix](https://github.com/larseggert/draft-ietf-modpod-group-processes/pull
	/80)
	- [Initial attempt to balance what the moderator defines and what](https://github.com
	/larseggert/draft-ietf-modpod-group-processes/pull/75)
	- [Scope and relationship between WG chairs and moderators](https://github.com/larseg
	gert/draft-ietf-modpod-group-processes/pull/76)
	- [Fix wording, spelling and capitalization.](https://github.com/larseggert/draft-iet
	f-modpod-group-processes/pull/88)
	- [Editorial changes to acknowledgments.](https://github.com/larseggert/draft-ietf-mo
	dpod-group-processes/pull/87)
	## Since draft-ecahc-moderation-01
	- Content taken from
	[draft-ecahc-moderation-01](https://datatracker.ietf.org/doc/draft-ecahc-moderation
	/01/).
	[Updated editors. Acknowledge authors of original pre-WG I-Ds.](https://github.com/
	larseggert/draft-ietf-modpod-group-processes/pull/65)
	# Motivation {#motivation}		# Motivation {#motivation}
	{{introduction}} summarized the process changes introduced by this memo.		{{introduction}} 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.
	## Background		## Background
	The IETF community has defined general guidelines for		The IETF community has defined general guidelines for
	personal interactions in the IETF {{!RFC7154}}, and the IESG has		personal interactions in the IETF {{!RFC7154}}. The IESG has
	defined an anti-harassment policy for the IETF {{AHP}} for which the IETF		defined an anti-harassment policy for the IETF {{AHP}} for which the IETF
	community has defined anti-harassment procedures {{!RFC7776}},		community has defined anti-harassment procedures {{!RFC7776}},
	empowering an ombudsteam {{OT}} to take necessary action.		empowering an 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}} provided chairs a procedure to help manage mailing		{{?RFC3934}} provides chairs a procedure to help manage mailing
	lists. An IESG statement {{MODML}} described additional guidance		lists. An IESG statement {{MODML}} describes additional guidance
	to working group chairs about how — but not when — to moderate their		to working group chairs about how -- but not when -- to moderate their
	lists.		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		with moderation. And the IETF list for general discussions
	has, mostly for historic reasons, a team of moderators that are not		has, mostly for historic reasons, a team of moderators that are not
	list administrators and operate by a different set of processes		list administrators and operate by a different set of processes
	{{?RFC9245}}.		{{?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 before		moderation, where administrators review attempted participation before
	it occurs		it occurs
	(such as reviewing messages to a mailing list), and *reactive* moderation,		(such as reviewing messages to a mailing list), and *reactive* moderation,
	where administrators intervene after disruptive participation has occurred.		where administrators intervene after disruptive participation has occurred.
	The		Historically, the
	IETF historically mainly practiced reactive moderation, with a spectrum from		IETF has mainly practiced reactive moderation, with a spectrum from
	gentle reminders on- and off-list, all the way to suspension of posting rights		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 other ways of participating or communicating. It is up to the moderators
	and administrators		and administrators
	to decide which mix of preemptive and reactive moderation to employ as		to decide which mix of preemptive and reactive moderation to employ as
	part of their procedures.		part of their procedures.
	In addition, {{?RFC3683}} defines a process for revoking an		In addition, {{?RFC3683}} defines a process for revoking an
	individual's posting rights to IETF mailing lists following a		individual's posting rights to IETF mailing lists following a
	community last-call of a "posting rights" action (PR-action) proposed		community Last Call of a "posting rights" action (PR-action) proposed
	by the IESG, often in response to complaints from the community.		by the IESG, often 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.
	## Problems with the Previous Approach {#motive}		## Problems with the Previous Approach {#motive}
	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
	skipping to change at line 689 ¶		skipping to change at line 603 ¶
	participant who can be reasoned with and who will change their		participant who can be reasoned with and who will change their
	ways.		ways.
	- Chairs and list administrators may only enact moderation actions for		- Chairs and list administrators may only enact moderation actions for
	their single list, which is ill-suited when a pattern of disruptive		their single list, which is ill-suited when a pattern of disruptive
	behavior spans multiple lists. Also, chairs and list administrators		behavior spans multiple lists. Also, chairs and list administrators
	may not be fully aware of disruptive behavior that spans multiple		may not be fully aware of disruptive behavior that spans multiple
	lists, due to not being subscribed to some of them.		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 and slow, and inconsistent. This has		lists, are cumbersome, slow, and inconsistent. This has
	led to a situation where PR-actions are rarely used, and when they		led to a situation where PR-actions are rarely used, and when they
	are used, they are perceived as very heavy-handed.		are 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, for		reporting disruptive behavior to a chair or list administrator, for
	various reasons. For mailing lists not associated with working		various reasons. For mailing lists not associated with working
	groups, list administrators are not even publicly identified - they		groups, list administrators are not even publicly identified -- they
	can only be contacted through an anonymous alias address. This		can only be contacted through an anonymous alias address. This
	exacerbates the problem, because participants may not be		exacerbates the problem, because participants may not be
	comfortable reporting disruptive behavior to an anonymous party.		comfortable reporting disruptive behavior to an anonymous party.
	- The IETF offers participation not only through in-person meetings		- The IETF offers participation not only through in-person meetings
	and mailing lists, which are the two channels of participation for		and mailing lists, which are the two channels of participation for
	which moderation processes are currently defined. IETF business		which moderation processes are currently defined. IETF business
	also happens in chat groups, remote meeting participation		also happens in chat groups, remote meeting participation
	systems, virtual meetings, wikis, GitHub repositories, and more.		systems, virtual meetings, wikis, GitHub repositories, and more.
	How disruptive behavior is moderated in these fora is currently		How disruptive behavior is moderated in these fora is currently
End of changes. 58 change blocks.
	226 lines changed or deleted		100 lines changed or added
This html diff was produced by rfcdiff 1.48.