Most RFCs define wire protocols. A few define how humans on those wires are supposed to behave. RFC 3683 is one of the rarest kinds: an RFC about how to silence humans. It formalizes a procedure — universally known as a "PR-action" (Posting Rights action) — for revoking a person's ability to post to IETF mailing lists. It is short, awkward, and has shaped the social fabric of the organization that runs the internet for two decades.

The problem. The IETF runs on email. Working groups debate, consensus is judged, and standards are forged in plaintext threads on lists like [email protected]. By the early 2000s, those lists had become large enough to attract a familiar problem: a small number of participants who would not stop. Not spammers — actual participants who repeatedly derailed threads, harassed contributors, or refused to drop dead arguments. The existing escalation path was murky: a working group chair could ask someone to stop, the IESG could intervene informally, but there was no written procedure with named actors, durations, and appeal rights. Marshall Rose, who had already authored dozens of foundational RFCs (BEEP, SMI, SNMP MIBs), wrote one.

The mechanism. RFC 3683 defines a clean process. Anyone — usually a working group chair — submits a request to the IESG identifying the participant and the disruption. The IESG announces a proposed PR-action on the relevant lists for a comment period (originally 14 days). If after weighing community input the IESG still concludes the person is being persistently disruptive, it issues the action: the named participant's posting rights to specified lists are revoked, typically for a fixed term (often a year). The person retains the right to read the lists and to participate at face-to-face IETF meetings. An appeals path runs through the IAB.

Design choices worth noticing.

• Posting only, not reading. The IETF archive is the historical record of internet standards. Even a disruptive participant cannot be cut off from seeing what's being decided. The asymmetry is deliberate.
• Public process. The proposed action, the comment period, and the final decision are all posted to the affected lists. There are no quiet bans. This is uncomfortable but consistent with the IETF's "rough consensus and running code" culture: governance happens in the open.
• Bounded duration. A PR-action expires. The default is not permanent exile.
• Named offender. The RFC requires the request to name the individual and cite specific messages. No vague "tone" complaints.

Why it matters today. Every modern open-source community eventually rediscovers this problem: GitHub repos, Discord servers, Kubernetes SIGs, language steering committees. Most invent ad-hoc moderation as they go. RFC 3683 is a 22-year-old written-down version of what good moderation looks like in a technical standards body — public process, due notice, bounded penalties, preservation of read access, an appeal path. The Rust moderation team, the Python Steering Council's conduct procedures, and countless code-of-conduct documents echo its shape, often without citing it.

The backstory. RFC 3683 was not theoretical. It was written in the wake of specific years-long disputes on IETF lists where individual participants had become a chronic burden on chairs. The RFC was itself contentious — some argued it would chill participation; Rose and the IESG argued the alternative was that working groups would quietly suffocate. The procedure has been invoked sparingly (a handful of times per decade), which its defenders point to as evidence it works: the existence of a written, public mechanism deters before it has to be used. It was updated by RFC 9245 in 2022, but the core shape is unchanged.