Internet DRAFT - draft-ecahc-moderation
draft-ecahc-moderation
Network Working Group L. Eggert
Internet-Draft NetApp
Intended status: Best Current Practice A. Cooper
Expires: 7 January 2024 Cisco
J. Arkko
Ericsson
R. Housley
Vigil Security
B. Carpenter
Univ. of Auckland
6 July 2023
IETF Community Moderation
draft-ecahc-moderation-00
Abstract
This document describes the creation of a moderator team for all of
the IETF's various contribution channels. Without removing existing
responsibilities for working group management, this team enables a
uniform approach to moderation of disruptive participation across all
mailing lists and other methods of IETF collaboration.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://larseggert.github.io/moderation/draft-ecahc-moderation.html.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ecahc-moderation/.
Discussion of this document takes place on the gendispatch Working
Group mailing list (mailto:gendispatch@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/gendispatch/. Subscribe
at https://www.ietf.org/mailman/listinfo/gendispatch/.
Source for this draft and an issue tracker can be found at
https://github.com/larseggert/moderation.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Eggert, et al. Expires 7 January 2024 [Page 1]
Internet-Draft IETF Community Moderation July 2023
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. IETF Moderator Team . . . . . . . . . . . . . . . . . . . . . 4
4.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Membership . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Team Diversity . . . . . . . . . . . . . . . . . . . . . 6
4.5. Relation to Ombudsteam . . . . . . . . . . . . . . . . . 7
5. Changes to Existing RFCs . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Eggert, et al. Expires 7 January 2024 [Page 2]
Internet-Draft IETF Community Moderation July 2023
1. Introduction
This document proposes the creation of a moderator team for all of
the IETF's various contribution channels. This moderator team is
modeled after, and subsumes, the moderator team for the IETF
discussion list [RFC9245].
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Motivation
The IETF community has defined general guidelines of conduct for
personal interaction in the IETF [RFC7154], and the IESG has defined
an anti-harassment policy for the IETF [AHP] for which the IETF
community has defined anti-harassment procedures [RFC7776],
empowering an ombudsteam [OT] to take necessary action.
Dealing with _disruptive_ behavior, however, is not part of the role
of the ombudsteam. [RFC3934] task the chairs of each IETF working
group with moderating their group's in-person meetings and mailing
lists, and an IESG statement [MODML] describes additional guidance to
working group chairs. For IETF mailing lists not associated with a
working group, another IESG statement clarifies [DP] that the list
administrators are tasked with moderation. And the IETF list for
general discussions has, mostly for historic reasons, a team of
moderators that are not list administrators and operate by a
different set of processes [RFC9245].
In addition, [RFC3683] defines a process for revoking an individual's
posting rights to IETF mailing lists following a community last-call
of a "PR-action" proposed by the IESG, often in response to
complaints from the community.
This fractured approach to moderation of disruptive participation
through chairs, list administrators, and moderator teams, combined
with the IESG-led process of PR-actions, has proven to be less than
ideal:
Eggert, et al. Expires 7 January 2024 [Page 3]
Internet-Draft IETF Community Moderation July 2023
* The IETF community has not been able to agree on a common
definition of disruptive behavior. Therefore, chairs and list
administrators apply individually different criteria when making
decisions, and participants have different expectations for when
PR-actions are warranted.
* The moderation process that chairs and list administrators need to
follow [RFC3934] is slow and cumbersome, which makes it ill-suited
to situations that escalate quickly. It also assumes that the
originator of disruptive behavior is a misguided participant that
can be reasoned with and who will change their ways.
* Chairs and list administrators may only enact moderation actions
for their single list, which is ill-suited when a pattern of
disruptive behavior spans multiple lists. Also, chairs and list
administrators may not be fully aware of disruptive behavior that
spans multiple lists, due to not being subscribed to some of the
affected.
* PR-actions, which can address disruptive behavior across several
lists, are cumbersome and slow, and the community has not been
able to agree on a common definition of disruptive behavior. This
has led to a situation where PR-actions are rarely used, and when
they are used, they are perceived as very heavy-handed.
* For a given mailing list, participants may not feel comfortable
reporting disruptive behavior to a chair or list administrator,
for various reasons. For mailing lists not associated with
working groups, list administrators are not even publicly
identified - they can only be contacted through an anonymous alias
address. This exacerbates the problem, because participants may
not be comfortable reporting disruptive behavior to an anonymous
party.
* The IETF offers participation not only through in-person meetings
and mailing lists, which are the two channels of participation for
which moderation processes are currently defined. IETF business
also happens in chat channels, remote meeting participation
systems, virtual meetings, wikis, GitHub repositories, and more.
How disruptive behavior is moderated in these channels is
currently undefined.
4. IETF Moderator Team
This document proposes a different, uniform approach to moderating
the IETF's various participation channels: a moderator team for the
IETF. The creation of this team intends to address the issues
identified in Section 3.
Eggert, et al. Expires 7 January 2024 [Page 4]
Internet-Draft IETF Community Moderation July 2023
| TODO: Decide whether moderation rights remain also with WG
| chairs, list admins, and others who currently have them, or
| whether all moderation rights centralize with the moderator
| team.
4.1. Scope
This IETF moderator team consists of a small number of individuals
(no less than three) that SHALL moderate all the IETF's various
current and future participation channels. At present, these include
mailing lists, chat channels, and discussions in other systems that
the IETF or WGs have chosen to employ, such as GitHub repositories,
Wikis, or issue trackers.
The management and moderation of in-person, remote, and interim
meetings remains a task of the relevant group's management, such as
WG chairs. However, it is expected that moderators are available for
consultation and assistance should issues arise, and they may confer
with the group management over potential patterns of behavior.
The moderator team SHALL operate according to a consistent and
uniform set of criteria, processes, and actions. The moderator team
SHALL independently define and execute their role. They SHALL
maintain a public set of moderation criteria, processes, actions, and
other material that allows the community to understand and comment on
the role of the team. The moderator team SHOULD consider adopting
moderation criteria, processes, and actions that other technical
communities have found suitable. The moderator team's criteria and
processes SHALL be developed with community input, but they are not
expected to be documented in the RFC series.
The moderator team MAY initiate moderation actions by itself;
individual participants SHOULD also alert the team to disruptive
behavior they observe. Participants should be able to contact the
moderator team in ways that are, ideally, integrated into the various
participation channels the IETF offers.
It is not expected that the moderator team will be monitoring every
IETF channel, but rather that participants will proactively flag
concerns about disruptive behavior to the moderator team. However,
the moderator team SHOULD actively monitor a small set of key
participation channels, including, for example, the IETF discussion
and last-call mailing lists or the IETF plenary chat channel. The
moderator team should decide which channels are in this set based on
their own judgement and community suggestions.
Eggert, et al. Expires 7 January 2024 [Page 5]
Internet-Draft IETF Community Moderation July 2023
| TODO: Decide whether chairs and list admins should retain the
| ability to moderate their lists in addition to the moderator
| team, or whether chair and list admins should only inform the
| moderator team of potentially disruptive behavior and let them
| deal with it.
4.2. Membership
The IETF Chair appoints members of the moderator team. Apart from
appointing moderators, the IETF Chair SHALL refrain from the day-to-
day operation and management of the moderator team. The moderator
team MAY decide to consult with IETF Chair when needed.
Because the IESG and IAB are in the appeals chain for moderator team
decisions (see Section 4.3), the IETF Chair SHOULD NOT appoint a
moderator who is serving on the IESG or IAB. Individuals serving on
other bodies to which the NomCom appoints members, such as the IETF
Trust or the LLC Board, as well as LLC staff and contractors SHALL
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 soon after.
4.3. Appeals
Because the moderator team serves at the discretion of the IETF
Chair, any moderation decision can be appealed to the IETF Chair, per
[RFC2026]. Disagreements with a decision by the IETF Chair can be
brought to their attention. If this does not lead to a resolution,
the decision can be appealed as described in [RFC2026], as with any
other Area Director decision. In this case, the appeals chain starts
with an appeal to the entire IESG.
4.4. Team Diversity
Due to the global nature of the IETF, the membership of this team
SHOULD reflect a diversity of time zones and other participant
characteristics that lets it operate effectively around the clock and
throughout the year. Team diversity is also important to ensure any
participant observing problematic behavior can identify a moderator
they feel comfortable contacting.
Eggert, et al. Expires 7 January 2024 [Page 6]
Internet-Draft IETF Community Moderation July 2023
4.5. Relation to Ombudsteam
The moderator team SHALL complement the efforts of the IETF
ombudsteam [OT], whose focus on anti-harassment and operation SHALL
remain unchanged. The moderator team and ombudsteam are expected to
work together in cases that may involve both disruptive behavior and
harassment; they may determine the most effective way to do so in
each case.
The ombudsteam has strict rules of confidentiality. If a moderation
case overlaps with an ombudsteam case, confidential information MUST
NOT be shared between the teams.
5. Changes to Existing RFCs
Creation of the IETF moderator team requires some changes to existing
RFCs and also requires the IESG to update a number of their
statements. This section describes these changes.
| TODO: Add once we know this I-D will go forward in some form.
6. Security Considerations
The usual security considerations [RFC3552] do not apply to this
document.
Potential abuse of the moderation process for the suppression of
undesired opinions is counteracted by the availability of an appeals
process, per Section 4.3.
7. IANA Considerations
This document has no IANA actions.
8. References
8.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/rfc/rfc2026>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Eggert, et al. Expires 7 January 2024 [Page 7]
Internet-Draft IETF Community Moderation July 2023
[RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment
Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March
2016, <https://www.rfc-editor.org/rfc/rfc7776>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
8.2. Informative References
[AHP] IESG, "IETF Anti-Harassment Policy", 3 November 2013,
<https://www.ietf.org/about/groups/iesg/statements/anti-
harassment-policy/>.
[DP] IESG, "IESG Statement on Disruptive Posting", 16 February
2006, <https://www.ietf.org/about/groups/iesg/statements/
disruptive-posting/>.
[MODML] IESG, "IESG Guidance on the Moderation of IETF Working
Group Mailing Lists", 29 August 2000,
<https://www.ietf.org/about/groups/iesg/statements/
mailing-lists-moderation/>.
[OT] "Ombudsteam", <https://www.ietf.org/contact/ombudsteam/>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/rfc/rfc3552>.
[RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF
Mailing Lists", BCP 83, RFC 3683, DOI 10.17487/RFC3683,
March 2004, <https://www.rfc-editor.org/rfc/rfc3683>.
[RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the
Management of IETF Mailing Lists", BCP 25, RFC 3934,
DOI 10.17487/RFC3934, October 2004,
<https://www.rfc-editor.org/rfc/rfc3934>.
[RFC7154] Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54,
RFC 7154, DOI 10.17487/RFC7154, March 2014,
<https://www.rfc-editor.org/rfc/rfc7154>.
[RFC9245] Eggert, L. and S. Harris, "IETF Discussion List Charter",
BCP 45, RFC 9245, DOI 10.17487/RFC9245, June 2022,
<https://www.rfc-editor.org/rfc/rfc9245>.
Eggert, et al. Expires 7 January 2024 [Page 8]
Internet-Draft IETF Community Moderation July 2023
Acknowledgments
These individuals suggested improvements to this document:
* Jay Daley
Authors' Addresses
Lars Eggert
NetApp
Stenbergintie 12 B
FI-02700 Kauniainen
Finland
Email: lars@eggert.org
URI: https://eggert.org/
Alissa Cooper
Cisco
Email: alcoop@cisco.com
Jari Arkko
Ericsson
FI-02700 Kauniainen
Finland
Email: jari.arkko@ericsson.com
Russ Housley
Vigil Security
Email: housley@vigilsec.com
Brian E. Carpenter
The University of Auckland
School of Computer Science
PB 92019
Auckland 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Eggert, et al. Expires 7 January 2024 [Page 9]
