RFC 3683

RFC 3683: A Practice for Revoking Posting Rights to IETF Mailing Lists 💅🎀

Title block tea ☕: This is RFC 3683, written by Marshall T. Rose of Dover Beach Consulting, Inc. in March 2004. It's a Best Current Practice (BCP 83), so it's the community's recommended way of doing things, not a protocol spec. It doesn't list anything it obsoletes or updates. 🌸

---

Status of This Memo 🫶

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

Copyright Notice 🔖

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract ✨

Okay so every self-governing group has ways to manage how people interact, and the IETF is no exception. 🧚 The IETF builds computer-communications standards through a consensus-driven process out in the open, and mailing lists are a huge part of that. 💌 But in a small number of cases, someone has pulled a "denial-of-service" attack on the process to disrupt it. 😭 As these bad faith attacks get more common, the IETF needs a practice that reduces or eliminates them, and this memo recommends exactly that. 🦋

Table of Contents 📚

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  A Revocation Practice . . . . . . . . . . . . . . . . . . . .   5
   3.  Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  Normative References. . . . . . . . . . . . . . . . . . . . .   9
   Appendix -  Q & A . . . . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address. . . . . . . . . . . . . . . . . . . . . . . . .  12
   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .  13

1. Introduction 🌈

Okay bestie, so the vibe is: every self-governing body has rules about who talks, when, and for how long. 🎤 Think of "rules of order" in a meeting. 🪑 There's also a big agreement in so-called "liberal" societies that free speech isn't absolute. Political speech gets more leeway than commercial speech, and some stuff (like egregious libel or incitement to violence) is just not okay. 🙅‍♀️

Now back to the IETF. It runs on consensus, in the open, and the mailing lists are where the magic happens. 🪄 What makes it iconic is that anyone can post to these lists and join the IETF process. 💖 That open door has worked really well because it brings in a wide range of stakeholders. (Quick note: in this memo, "IETF mailing list" means any list running under IETF auspices, like the IETF general discussion list or a working group or design team list. 📬)

Here's the tea ☕: in a small number of cases, someone has basically launched a "denial-of-service" attack to disrupt the consensus process. 💀 They usually do it by spamming messages that are off-topic, inflammatory, or otherwise counter-productive. Healthy disagreement is totally normal and good, though. 🫶

Like, if a working group can't reach consensus, that's acceptable, if unfortunate. 🥲 But if the group can't reach consensus because it's being continuously disrupted, then that disruption is an abuse of the process. 🚨 This is totally different from "the lone voice of dissent," where someone shares a view that gets discussed but doesn't win consensus. In other words, individual bad faith should not trump community goodwill. 👑

There are guidelines for dealing with abusive behavior (see Section 3.2 of [1] and [2]). 📖 Not an exhaustive list, but examples of abusive or otherwise inappropriate postings to IETF mailing lists include:

• unsolicited bulk e-mail;
• discussion of subjects unrelated to IETF policy, meetings, activities, or technical concerns;
• unprofessional commentary, regardless of the general subject; and,
• announcements of conferences, events, or activities that are not sponsored or endorsed by the Internet Society or IETF.

In practice, applying those guidelines has meant temporarily suspending someone's posting rights on a specific mailing list. 🔇 If needed, each suspension has gotten longer than the last. 📈 Honestly, those guidelines often fix the behaviour. 🙌 But when they don't, more drastic measures should be available to reduce or eliminate these attacks' impact on the IETF process. 🌪️

This document describes one of those drastic measures. 🧨

2. A Revocation Practice 🎀

Please refer to [3] for the meaning conveyed by the uppercase words in this section. 🔠

Okay so the IESG (Internet Engineering Steering Group) makes decisions about "actions." 🗳️ Usually an action is things like publishing a standards-track document or chartering a working group. This memo recommends that the IESG also take on a new type of action, called a PR-action ("posting rights" action). 🆕

A PR-action names one or more individuals and cites messages they posted to an IETF mailing list that appear to be abusive of the consensus process. 🚫 If the IESG approves it, then:

• those identified in the PR-action have their posting rights to that IETF mailing list removed; and,
• maintainers of any IETF mailing list may, at their discretion, also remove posting rights to that IETF mailing list.

Once a PR-action is taken, it stays in force until it's explicitly nullified, and it SHOULD remain in force for at least one year. ⏳ Lowkey a whole year, but that's the point. 🫠

One year after the PR-action is approved, a new PR-action MAY be introduced that restores posting rights for that individual. 🔓 When the IESG is evaluating that new PR-action, it SHOULD consider how often nullifying requests have come in. 🔍 And if posting rights do get restored, the individual is responsible for contacting the mailing list owners to get them restored. 📩

Whether a PR-action revokes or restores rights, the IESG follows the same algorithm it uses for all its other actions: 🔁

1. it is introduced by an IESG Area Director (AD), who, prior to doing so, may choose to inform the interested parties;
2. it is published as an IESG last call on the IETF general discussion list;
3. it is discussed by the community;
4. it is discussed by the IESG; and, finally,
5. using the usual consensus-based process, it is decided upon by the IESG.

Of course, just like every IESG action, the appeals process outlined in [4] may be invoked to contest a PR-action the IESG approved. ⚖️ Due process, periodt. 💅

Working groups SHOULD ensure that their associated mailing list is manageable. 🧹 For example, some people may try to dodge a revocation by changing their email addresses, so it should be possible to restrict the new email address. 🕵️‍♀️ Not okay, sis. 🙅‍♀️

Finally, the scope of a PR-action is only about posting rights. 📭 Consistent with the final paragraph of Section 3.2 of [1], no action may be taken to prevent individuals from receiving messages sent to a mailing list. 📬 They can still read everything, they just can't post. 🫶

---

Part 1 of 2. Part 2 picks up with Section 3 (Acknowledgements) and the rest of the document. 🦋

Full Copyright Statement ✨

Okay, legal bit, but make it cute 🎀. The Internet Society owns the copyright here (2004 🌸), and this doc is governed by the rights, licenses, and restrictions in BCP 78. Except for what BCP 78 says, the authors keep all their rights 💅.

This document and everything in it are provided "AS IS". THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranty of merchantability or fitness for a particular purpose 🙈

Intellectual Property

The IETF doesn't take a side on whether any Intellectual Property Rights or other rights that might be claimed over the technology in this document are valid or how far they reach 🧐. It also doesn't know whether any license under those rights would be available, and it hasn't made any independent effort to find such rights 🤷‍♀️. If you want to learn how RFC documents handle rights, check out BCP 78 and BCP 79 📚.

Copies of IPR disclosures sent to the IETF Secretariat are available, and so are any assurances that licenses will be provided. You can also get them if someone tried to get a general license or permission to use the proprietary rights, whether that was an implementer or a user of this spec. All of this lives in the IETF online IPR repository at http://www.ietf.org/ipr 🗂️✨.

The IETF also invites anyone interested to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard 🙌. Send that info to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement

Shoutout to the Internet Society 🫶. For now, it's the one funding the RFC Editor function 💖.