doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc3683.txt b/doc/rfc/rfc3683.txt
new file mode 100644
index 0000000..70a06e7
--- /dev/null
+++ b/doc/rfc/rfc3683.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+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
+   (c.f., Section 3.2 of [1] and [2]).  Although not exhaustive,
+   examples of abusive or otherwise inappropriate postings to IETF
+   mailing lists include:
+
+   o  unsolicited bulk e-mail;
+
+   o  discussion of subjects unrelated to IETF policy, meetings,
+      activities, or technical concerns;
+
+   o  unprofessional commentary, regardless of the general subject; and,
+
+   o  announcements of conferences, events, or activities that are not
+      sponsored or endorsed by the Internet Society or IETF.
+
+   In practice, the application of those guidelines has included the
+   temporary suspension of posting rights to a specific mailing list.
+   If necessary, the length of the suspension has been increased with
+   each successive suspension.  In many cases, applying those guidelines
+   will produce the desired modification in behaviour.  However, when
+   those guidelines fail to provide the desired modification in
+   behaviour, more drastic measures should be available to reduce or
+   eliminate these attacks' impact on the IETF process.
+
+   This document describes one such drastic measure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                     Best Current Practice                  [Page 4]
+
+RFC 3683        Revocation Practice: IETF Mailing Lists       March 2004
+
+
+2. A Revocation Practice
+
+   Please refer to [3] for the meaning conveyed by the uppercase words
+   in this section.
+
+   As a part of its activities, the Internet Engineering Steering Group
+   (IESG) makes decisions about "actions".  Typically, an action refers
+   to the publication of a document on the standards-track, the
+   chartering of a working group, and so on.  This memo recommends that
+   the IESG also undertake a new type of action, termed a PR-action
+   ("posting rights" action).
+
+   A PR-action identifies one or more individuals, citing messages
+   posted by those individuals to an IETF mailing list, that appear to
+   be abusive of the consensus-driven process.  If approved by the IESG,
+   then:
+
+   o  those identified on the PR-action have their posting rights to
+      that IETF mailing list removed; and,
+
+   o  maintainers of any IETF mailing list may, at their discretion,
+      also remove posting rights to that IETF mailing list.
+
+   Once taken, this action remains in force until explicitly nullified
+   and SHOULD remain in force for at least one year.
+
+   One year after the PR-action is approved, a new PR-action MAY be
+   introduced which restores the posting rights for that individual.
+   The IESG SHOULD consider the frequency of nullifying requests when
+   evaluating a new PR-action.  If the posting rights are restored the
+   individual is responsible for contacting the owners of the mailing
+   lists to have them restored.
+
+   Regardless of whether the PR-action revokes or restores posting
+   rights, the IESG follows the same algorithm as with 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;
+
+
+
+
+
+
+
+Rose                     Best Current Practice                  [Page 5]
+
+RFC 3683        Revocation Practice: IETF Mailing Lists       March 2004
+
+
+   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, as with all IESG actions, the appeals process outlined in
+   [4] may be invoked to contest a PR-action approved by the IESG.
+
+   Working groups SHOULD ensure that their associated mailing list is
+   manageable.  For example, some may try to circumvent the revocation
+   of their posting rights by changing email addresses; accordingly it
+   should be possible to restrict the new email address.
+
+   Finally, note that the scope of a PR-action deals solely with 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                     Best Current Practice                  [Page 6]
+
+RFC 3683        Revocation Practice: IETF Mailing Lists       March 2004
+
+
+3. Acknowledgements
+
+   The author gratefully acknowledges the contributions of: Brian
+   Carpenter, Jim Galvin, Jeff Haas, Ted Hardie, Russ Housley, Thomas
+   Narten, Jon Peterson, Margaret Wasserman, and Bert Wijnen.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                     Best Current Practice                  [Page 7]
+
+RFC 3683        Revocation Practice: IETF Mailing Lists       March 2004
+
+
+4. Security Considerations
+
+   This memo deals with matters of process, not protocol.
+
+   A reasonable person might note that this memo describes a mechanism
+   to throttle active denial-of-service attacks against the consensus-
+   driven process used by the IETF.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                     Best Current Practice                  [Page 8]
+
+RFC 3683        Revocation Practice: IETF Mailing Lists       March 2004
+
+
+5.  Normative References
+
+   [1]  Bradner, S., "IETF Working Group Guidelines and Procedures", BCP
+        25, RFC 2418, September 1998.
+
+   [2]  Harris, S., "IETF Discussion List Charter", BCP 45, RFC 3005,
+        November 2000.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                     Best Current Practice                  [Page 9]
+
+RFC 3683        Revocation Practice: IETF Mailing Lists       March 2004
+
+
+Appendix A. Q & A
+
+   Q: Isn't a year too long?
+
+   A: No.
+
+      An initial PR-action is not undertaken lightly.  It is approved
+      only after a period of substantive consideration and community
+      review.  If a PR-action is approved, then this indicates that a
+      serious situation has arisen.
+
+   Q: Why not require one PR-action per IETF mailing list?
+
+   A: To do so would enable a prolonged series of denial-of-service
+      attacks.
+
+      If someone is poorly-behaved on one IETF mailing list, but well-
+      behaved on another, then the maintainer for the second IETF
+      mailing list needn't revoke posting rights.  However, the more
+      likely scenario is that someone who behaves poorly on one IETF
+      mailing list is unwilling to be well-behaved on any IETF mailing
+      list.
+
+   Q: Should the initiation of a PR-action come from outside the IESG?
+
+   A: Informally, sure; formally, no.
+
+      Under the IETF's consensus-driven process, IESG actions are always
+      formally initiated by an IESG Area Director (AD).  In practice,
+      the motivation for an IESG member to initiate an action almost
+      always comes from outside the IESG.  For example, when a working
+      group (WG) reaches consensus on a document, the WG chair informs
+      the relevant AD that the document is ready for the AD to consider
+      it for a document action.  In the case of this document -- an IETF
+      individual submission -- the author will iteratively circulate the
+      document for wide discussion and make revisions.  At some point,
+      the author will contact an AD and ask for a document action to
+      publish this document as a Best Current Practice (BCP).
+
+   Q: Is this censorship?
+
+   A: Only if you believe in anarchy.
+
+      What is important is that the rules surrounding PR-actions exhibit
+      the same properties used by the rest of the consensus-based
+      process.
+
+
+
+
+
+Rose                     Best Current Practice                 [Page 10]
+
+RFC 3683        Revocation Practice: IETF Mailing Lists       March 2004
+
+
+   Q: C'mon! You really are a closet fascist.
+
+   A: No, I'm a libertarian.
+
+      Frankly, I would prefer that people behave reasonably and act in
+      good faith.  Since my first involvement with the IETF (nee GADS,
+      circa 1983), everyone understood that reasonable behavior was a
+      good thing.  After 20 years, I regret to inform you that this step
+      is inevitable.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                     Best Current Practice                 [Page 11]
+
+RFC 3683        Revocation Practice: IETF Mailing Lists       March 2004
+
+
+Author's Address
+
+   Marshall T. Rose
+   Dover Beach Consulting, Inc.
+   POB 255268
+   Sacramento, CA  95865-5268
+   US
+
+   Phone: +1 916 483 8878
+   EMail: mrose@dbc.mtview.ca.us
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                     Best Current Practice                 [Page 12]
+
+RFC 3683        Revocation Practice: IETF Mailing Lists       March 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78 and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and 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, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed
+   to pertain to the implementation or use of the technology
+   described in this document or the extent to which any license
+   under such rights might or might not be available; nor does it
+   represent that it has made any independent effort to identify any
+   such rights.  Information on the procedures with respect to
+   rights in RFC documents can be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use
+   of such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository
+   at http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention
+   any copyrights, patents or patent applications, or other
+   proprietary rights that may cover technology that may be required
+   to implement this standard.  Please address the information to the
+   IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Rose                     Best Current Practice                 [Page 13]
+