summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3683.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3683.txt')
-rw-r--r--doc/rfc/rfc3683.txt731
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]
+