< draft-mrose-ietf-posting-03.txt		draft-mrose-ietf-posting-04.txt >
	Network Working Group M. Rose		Network Working Group M. Rose
	Internet-Draft Dover Beach Consulting, Inc.		Internet-Draft Dover Beach Consulting, Inc.
	Expires: November 10, 2003 May 12, 2003		Expires: May 26, 2004 November 26, 2003
	A Practice for Revoking Posting Rights to IETF mailing lists		A Practice for Revoking Posting Rights to IETF mailing lists
	draft-mrose-ietf-posting-03		draft-mrose-ietf-posting-04
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 30 ¶		skipping to change at page 1, line 30 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 10, 2003.		This Internet-Draft will expire on May 26, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	All self-governing bodies have ways of managing the scope of		All self-governing bodies have ways of managing the scope of
	participant interaction. The IETF uses a consensus-driven process for		participant interaction. The IETF uses a consensus-driven process for
	developing computer-communications standards in an open fashion. An		developing computer-communications standards in an open fashion. An
	skipping to change at page 2, line 9 ¶		skipping to change at page 2, line 9 ¶
	a participant has engaged in a "denial-of-service" attack to disrupt		a participant has engaged in a "denial-of-service" attack to disrupt
	the consensus-driven process. Regrettably, as these bad faith attacks		the consensus-driven process. Regrettably, as these bad faith attacks
	become more common, the IETF needs to establish a practice that		become more common, the IETF needs to establish a practice that
	reduces or eliminates these attacks. This memo recommends such a		reduces or eliminates these attacks. This memo recommends such a
	practice for use by the IETF.		practice for use by the IETF.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. A Revocation Practice . . . . . . . . . . . . . . . . . . . . 5		2. A Revocation Practice . . . . . . . . . . . . . . . . . . . . 5
	3. Q & A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		Normative References . . . . . . . . . . . . . . . . . . . . . 9
	Normative References . . . . . . . . . . . . . . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11		A. Q & A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Intellectual Property and Copyright Statements . . . . . . . . 12		Intellectual Property and Copyright Statements . . . . . . . . 12
	1. Introduction		1. Introduction
	All self-governing bodies have ways of managing the scope of		All self-governing bodies have ways of managing the scope of
	participant interaction. For example, deliberative assemblies often		participant interaction. For example, deliberative assemblies often
	employ "rules of order" for determining who gets to speak, when, and		employ "rules of order" for determining who gets to speak, when, and
	for how long. Similarly, there is widespread agreement in so-called		for how long. Similarly, there is widespread agreement in so-called
	"liberal" societies that the right to free speech is not absolute,		"liberal" societies that the right to free speech is not absolute,
	e.g., political speech is given more leeway than commercial speech,		e.g., political speech is given more leeway than commercial speech,
	and some forms of speech (e.g., egregious libel or incitement to		and some forms of speech (e.g., egregious libel or incitement to
	violence) are considered unacceptable.		violence) are considered unacceptable.
	The IETF uses a consensus-driven process for developing		The IETF uses a consensus-driven process for developing
	computer-communications standards in an open fashion. An important		computer-communications standards in an open fashion. An important
	part of this consensus-driven process is the pervasive use of mailing		part of this consensus-driven process is the pervasive use of mailing
	lists for discussion. Unlike many other organizations, anyone may		lists for discussion. Unlike many other organizations, anyone may
	post messages on those IETF mailing lists, and in doing so,		post messages on those IETF mailing lists, and in doing so,
	participate in the IETF process. Historically, this approach has		participate in the IETF process. Historically, this approach has
	worked very well in the IETF, as it fosters participation from a wide		worked very well in the IETF, as it fosters participation from a wide
	range of stakeholders.		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 a		Notably, in a small number of cases, a participant has engaged in
	"denial-of-service" attack to disrupt the consensus-driven process.		what ammounts to a "denial-of-service" attack to disrupt the
	Typically, these attacks are made by repeatedly posting messages that		consensus-driven process. Typically, these attacks are made by
	are off-topic, inflammatory, or otherwise counter-productive. In		repeatedly posting messages that are off-topic, inflammatory, or
	contrast, good faith disagreement is a healthy part of the		otherwise counter-productive. In contrast, good faith disagreement is
	consensus-driven process.		a healthy part of the consensus-driven process.
	For example, if a working group is unable to reach consensus, this is		For example, if a working group is unable to reach consensus, this is
	an acceptable, albeit unfortunate, outcome; however, if that working		an acceptable, albeit unfortunate, outcome; however, if that working
	group fails to achieve consensus because it is being continuously		group fails to achieve consensus because it is being continuously
	disrupted, then the disruption constitutes an abuse of the		disrupted, then the disruption constitutes an abuse of the
	consensus-driven process. Interactions of this type are fundamentally		consensus-driven process. Interactions of this type are fundamentally
	different from "the lone voice of dissent" in which a participant		different from "the lone voice of dissent" in which a participant
	expresses a view that is discussed but does not achieve consensus. In		expresses a view that is discussed but does not achieve consensus. In
	other words, individual bad faith should not trump community		other words, individual bad faith should not trump community
	goodwill.		goodwill.
	skipping to change at page 5, line 11 ¶		skipping to change at page 5, line 11 ¶
	these attacks' impact on the IETF process.		these attacks' impact on the IETF process.
	This document describes one such drastic measure.		This document describes one such drastic measure.
	2. A Revocation Practice		2. A Revocation Practice
	Please refer to [3] for the meaning conveyed by the uppercase words		Please refer to [3] for the meaning conveyed by the uppercase words
	in this section.		in this section.
	As a part of its activities, the Internet Engineering Steering Group		As a part of its activities, the Internet Engineering Steering Group
	(IESG) votes on "actions". Typically, an action refers to the		(IESG) makes decisions about "actions". Typically, an action refers
	publication of a document on the standards-track, the chartering of a		to the publication of a document on the standards-track, the
	working group, and so on. This memo recommends that the IESG also		chartering of a working group, and so on. This memo recommends that
	undertake a new type of action, termed a PR-action.		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		A PR-action identifies one or more individuals, citing messages
	posted by those individuals to an IETF mailing list, that appear to		posted by those individuals to an IETF mailing list, that appear to
	be abusive of the consensus-driven process. If approved by the IESG,		be abusive of the consensus-driven process. If approved by the IESG,
	then:		then:
	o those identified on the PR-action have their posting rights to		o those identified on the PR-action have their posting rights to
	that IETF mailing list removed; and,		that IETF mailing list removed; and,
	o maintainers of any IETF mailing list may, at their discretion,		o maintainers of any IETF mailing list may, at their discretion,
	also remove posting rights to that IETF mailing list.		also remove posting rights to that IETF mailing list.
	Once taken, this action remains in force until explicitly nullified		Once taken, this action remains in force until explicitly nullified
	and MUST remain in force for at least one year.		and SHOULD remain in force for at least one year.
	One year after the PR-action is approved, a new PR-action MAY be		One year after the PR-action is approved, a new PR-action MAY be
	introduced which restores the posting rights for that individual. The		introduced which restores the posting rights for that individual. The
	IESG SHOULD consider the frequency of nullifying requests when		IESG SHOULD consider the frequency of nullifying requests when
	evaluating a new PR-action. If the posting rights are restored the		evaluating a new PR-action. If the posting rights are restored the
	individual is responsible for contacting the owners of the mailing		individual is responsible for contacting the owners of the mailing
	lists to have them restored.		lists to have them restored.
	Regardless of whether the PR-action revokes or restores posting		Regardless of whether the PR-action revokes or restores posting
	rights, the IESG follows the same algorithm as with its other		rights, the IESG follows the same algorithm as with its other
	skipping to change at page 5, line 51 ¶		skipping to change at page 5, line 52 ¶
	1. it is introduced by an IESG Area Director (AD), who, prior to		1. it is introduced by an IESG Area Director (AD), who, prior to
	doing so, may choose to inform the interested parties;		doing so, may choose to inform the interested parties;
	2. is is published as an IESG last call on the IETF general		2. is is published as an IESG last call on the IETF general
	discussion list;		discussion list;
	3. it is discussed by the community;		3. it is discussed by the community;
	4. it is discussed by the IESG; and, finally,		4. it is discussed by the IESG; and, finally,
	5. it is voted upon by the IESG.		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		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.		[4] may be invoked to contest a PR-action approved by the IESG.
	Working groups SHOULD ensure that their associated mailing list is		Working groups SHOULD ensure that their associated mailing list is
	manageable. For example, some may try to circumvent the revocation of		manageable. For example, some may try to circumvent the revocation of
	their posting rights by changing email addresses.		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		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		rights. Consistent with the final paragraph of Section 3.2 of [1], no
	action may be taken to prevent individuals from receiving messages		action may be taken to prevent individuals from receiving messages
	sent to a mailing list.		sent to a mailing list.
	3. Q & A		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.
			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 againast the
			consensus-drive process used by the IETF.
			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.
			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
			Appendix A. Q & A
	Q: Isn't a year too long?		Q: Isn't a year too long?
	A: No.		A: No.
	An initial PR-action is not undertaken lightly. It is approved		An initial PR-action is not undertaken lightly. It is approved
	only after a period of substantive consideration and community		only after a period of substantive consideration and community
	review. If a PR-action is approved, then this indicates that a		review. If a PR-action is approved, then this indicates that a
	serious situation has arisen.		serious situation has arisen.
	skipping to change at page 9, line 5 ¶		skipping to change at page 12, line 5 ¶
	Q: C'mon! You really are a closet fascist.		Q: C'mon! You really are a closet fascist.
	A: No, I'm a libertarian.		A: No, I'm a libertarian.
	Frankly, I would prefer that people behave reasonably and act in		Frankly, I would prefer that people behave reasonably and act in
	good faith. Since my first involvement with the IETF (nee GADS,		good faith. Since my first involvement with the IETF (nee GADS,
	circa 1983), everyone understood that reasonable behavior was a		circa 1983), everyone understood that reasonable behavior was a
	good thing. After 20 years, I regret to inform you that this step		good thing. After 20 years, I regret to inform you that this step
	is inevitable.		is inevitable.
	4. Acknowledgements
	The author gratefully acknowledges the contributions of: Brian
	Carpenter, Jim Galvin, Jeff Haas, and Bert Wijnen.
	5. Security Considerations
	This memo deals with matters of process, not protocol.
	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.
	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
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of		standards-related documentation can be found in BCP-11. Copies of
	skipping to change at page 13, line 7 ¶		skipping to change at page 13, line 7 ¶
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assignees.		revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 13 change blocks.
	58 lines changed or deleted		69 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/