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

Document Type RFC - Best Current Practice (March 2004; No errata)
Also known as BCP 83
Last updated 2013-03-02
Stream ISE
Formats plain text pdf html bibtex
Stream ISE state (None)
Consensus Boilerplate Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3683 (Best Current Practice)
Telechat date
Responsible AD Steven Bellovin
Send notices to <mrose+mtr.ietf@dbc.mtview.ca.us>
Network Working Group                                            M. Rose
Request for Comments: 3683                  Dover Beach Consulting, Inc.
BCP: 83                                                       March 2004
Category: Best Current Practice

      A Practice for Revoking Posting Rights to IETF Mailing Lists

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

   All self-governing bodies have ways of managing the scope of
   participant interaction.  The IETF uses a consensus-driven process
   for developing computer-communications standards in an open fashion.
   An important part of this consensus-driven process is the pervasive
   use of mailing lists for discussion.  Notably, in a small number of
   cases, a participant has engaged in a "denial-of-service" attack to
   disrupt the consensus-driven process.  Regrettably, as these bad
   faith attacks become more common, the IETF needs to establish a
   practice that reduces or eliminates these attacks.  This memo
   recommends such a practice for use by the IETF.

Rose                     Best Current Practice                  [Page 1]
RFC 3683        Revocation Practice: IETF Mailing Lists       March 2004

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

Rose                     Best Current Practice                  [Page 2]
RFC 3683        Revocation Practice: IETF Mailing Lists       March 2004

1.  Introduction

   All self-governing bodies have ways of managing the scope of
   participant interaction.  For example, deliberative assemblies often
   employ "rules of order" for determining who gets to speak, when, and
   for how long.  Similarly, there is widespread agreement in so-called
   "liberal" societies that the right to free speech is not absolute,
   e.g., political speech is given more leeway than commercial speech,
   and some forms of speech (e.g., egregious libel or incitement to
   violence) are considered unacceptable.

   The IETF uses a consensus-driven process for developing computer-
   communications standards in an open fashion.  An important part of
   this consensus-driven process is the pervasive use of mailing lists
   for discussion.  Unlike many other organizations, anyone may post
   messages on those IETF mailing lists, and in doing so, participate in
   the IETF process.  Historically, this approach has worked very well
   in the IETF, as it fosters participation from a wide range of
   stakeholders.  (For the purposes of this memo, the term "IETF mailing
   list" refers to any mailing list functioning under IETF auspices,
   such as the IETF general discussion list, or a working group or
   design team mailing list.)

   Notably, in a small number of cases, a participant has engaged in
   what amounts to a "denial-of-service" attack to disrupt the
   consensus-driven process.  Typically, these attacks are made by
   repeatedly posting messages that are off-topic, inflammatory, or
   otherwise counter-productive.  In contrast, good faith disagreement
   is a healthy part of the consensus-driven process.

   For example, if a working group is unable to reach consensus, this is
   an acceptable, albeit unfortunate, outcome; however, if that working
   group fails to achieve consensus because it is being continuously
   disrupted, then the disruption constitutes an abuse of the
   consensus-driven process.  Interactions of this type are
   fundamentally different from "the lone voice of dissent" in which a
   participant expresses a view that is discussed but does not achieve
   consensus.  In other words, individual bad faith should not trump
   community goodwill.

Rose                     Best Current Practice                  [Page 3]
RFC 3683        Revocation Practice: IETF Mailing Lists       March 2004

   Guidelines have been developed for dealing with abusive behavior
Show full document text