Summary
- RFC 3005 made the IETF general discussion list a broad venue for technical work and institutional direction, but it did not make every subject, style or repetition appropriate for the shared channel.
- Named officers could restrict a person or thread only around inappropriate content forming a pattern of abuse, while complaints went to the IAB; later BCPs decomposed duration, warnings, receipt rights and appeal more precisely.
An open door does not answer what happens when one person repeatedly blocks the doorway. That was the governance problem inside the IETF Discussion List Charter, published as Best Current Practice 45 in November 2000. The document was only two substantive pages long. It nevertheless drew a control surface around the IETF’s most general public conversation.
The general discussion list had two purposes. It supported the development and specification of Internet technology through technical discussion, and it hosted discussion of IETF direction, policy, meetings and procedures. Because it was the most general list, the charter allowed “considerable latitude.” The breadth was functional: a proposal without a working group still needed somewhere to begin, and the whole community sometimes needed to debate a standards action or the institution’s own procedure.
Yet the list was explicitly a place for initial discussion. If a subject belonged to an established working group or another mature list, the conversation was expected to move there once someone pointed that out, unless wider input was genuinely required. Openness did not mean that one central channel had to carry every thread forever. The charter treated attention and venue as shared infrastructure.
It then listed examples. Last Call debate, emerging technical questions without a home, administrative policy, meeting clarification and announcements endorsed by the Internet Society or IETF were appropriate. Unsolicited bulk mail, unrelated subjects, unendorsed event promotion and “unprofessional commentary, regardless of the general subject” were not. The last phrase marked an important separation: a message could concern a legitimate technical topic and still be inappropriate in its conduct.
The enforcement rule was also more structured than a simple power to delete. The IETF Chair, the IETF Executive Director, or a sergeant-at-arms appointed by the Chair could restrict posting by a person or restrict a thread when the content was inappropriate and represented a pattern of abuse. The conjunction mattered. The text did not say that every isolated error, sharp disagreement or unwelcome conclusion was a pattern.
The decision-maker was encouraged to examine an individual’s overall postings and ask whether a particular message was an aberration or typical. That is contextual judgment, not an automatic word filter or numerical threshold. It locates risk over time while preserving the possibility that a contributor made one bad intervention rather than revealing an abusive mode of participation.
RFC 3005 also refused to make the initial actor the final procedural authority. Complaints about the decision were to be referred to the Internet Architecture Board. The charter did not specify a suspension length, warning schedule or detailed record format. But it did identify a review destination outside the person applying the restriction. Moderation was an accountable institutional act, not merely a property of the mailing-list software.
The wider IETF process explains why that balance mattered. RFC 2418 said there was no formal IETF membership, participation was open to all, and people contributed as individuals rather than as organizational representatives. Mailing lists were not publicity accessories; they were working surfaces of the standards process. Restricting posting could therefore affect participation, even though it did not settle whether the restricted person’s technical claim was right.
Later Best Current Practices exposed questions that RFC 3005 had left compact. RFC 3683, published in 2004, distinguished repeated disruption from the lone dissenting voice. It described a longer posting-rights action introduced by an Area Director, announced through an IESG Last Call, discussed by the community, decided by the IESG and open to appeal. It also limited the action to posting: the affected person was not to be prevented from receiving list messages.
That same year, RFC 3934 gave working-group chairs a different, temporary mechanism. Ordinarily, a chair should first communicate privately, then issue at least one public warning and consult the responsible Area Director. As a last resort, the chair could suspend posting for no more than 30 days. Receipt had to continue, and the decision remained appealable under the standards process. A general-list restriction, a working-group chair’s short suspension and an IESG posting-rights action were related governance tools, not one interchangeable power.
The historical lesson is not that moderation defeats openness, nor that declaring a forum open legitimizes every use of it. Each layer answers a separate question. A contribution may be technically relevant. Its expression may be professional or abusive. Repetition may reveal a pattern. An officer may act within or beyond delegated authority. An appeal may confirm or overturn process. Consensus may still accept or reject the technical point. Collapsing those receipts lets either side claim too much.
RFC 3005’s spare design captured a durable institutional bargain: lower the cost of entering the discussion, state the boundaries of the common channel, require a pattern rather than treating every anomaly as identity, name who may intervene, and provide somewhere else to contest that intervention. Openness became credible not through the absence of control, but through control whose scope could be described and reviewed.
Sources
- Lu Heng, “Minimum Initial Specification, Localized Future Decision, Voluntary Adoption: An Internet Coordination System”
- Lu Heng, “On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile”
- Lu Heng, “Running Code Primary: The Patch Needed to Preserve the Internet’s Original Design”
- RFC Editor information page for RFC 3005
- RFC 2026, The Internet Standards Process — Revision 3
- RFC 2418, IETF Working Group Guidelines and Procedures
- RFC 3005, IETF Discussion List Charter
- RFC 3683, A Practice for Revoking Posting Rights to IETF Mailing Lists
- RFC 3934, Updates to RFC 2418 Regarding the Management of IETF Mailing Lists
- RFC 7154, IETF Guidelines for Conduct
- RFC 7776, IETF Anti-Harassment Procedures
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
