<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [ga] Re: Even Handed Application of The Rules (Yes or No? - We shall see) (was Re: [ga] Posting rights of Jeff Williams suspended for 14 days).
Take note that this process narrowly applies to a DoS of the consensus
building process. That's very different from censorship.
Are you saying that Jim Fleming is guilty of such an infraction WRT
the GA list (if so, I disagree) or are you just, again, preaching your
personal prospective that Jim Fleming is a jerk?
Note that the "group" "votes" on the actions.
Wednesday, May 7, 2003, 3:36:12 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
SB> On Wed, May 07, 2003 at 11:05:02AM +1200,
SB> Joop Teernstra <terastra@terabytz.co.nz> wrote
SB> a message of 26 lines which said:
>> BTW, as a matter of interest, a poll among icannatlarge listmembers
>> revealed that more than 63% are in favor of a mailing list with Rules.
>> The comments are of interest.
>> http://www.icannatlarge.com/results-may4a.htm
SB> It may be interesting also to read the attached Internet-Draft which
SB> is proposed to the IETF (background: anyone can write an
SB> Internet-Draft, as its name suggest, they have no official value) to
SB> deal with jerks. Since some are common to the IETF and to the GA
SB> mailing list (Jim Fleming...), it is interesting reading:
SB> Network Working Group M. Rose
SB> Internet-Draft Dover Beach Consulting, Inc.
SB> Expires: November 2, 2003 May 4, 2003
SB> A Practice for Revoking Posting Rights to IETF mailing lists
SB> draft-mrose-ietf-posting-02
SB> Status of this Memo
SB> This document is an Internet-Draft and is in full conformance with
SB> all provisions of Section 10 of RFC2026.
SB> Internet-Drafts are working documents of the Internet Engineering
SB> Task Force (IETF), its areas, and its working groups. Note that other
SB> groups may also distribute working documents as Internet-Drafts.
SB> Internet-Drafts are draft documents valid for a maximum of six months
SB> and may be updated, replaced, or obsoleted by other documents at any
SB> time. It is inappropriate to use Internet-Drafts as reference
SB> material or to cite them other than as "work in progress."
SB> The list of current Internet-Drafts can be accessed at http://
SB> www.ietf.org/ietf/1id-abstracts.txt.
SB> The list of Internet-Draft Shadow Directories can be accessed at
SB> http://www.ietf.org/shadow.html.
SB> This Internet-Draft will expire on November 2, 2003.
SB> Copyright Notice
SB> Copyright (C) The Internet Society (2003). All Rights Reserved.
SB> Abstract
SB> All self-governing bodies have ways of managing the scope of
SB> participant interaction. The IETF uses a consensus-driven process for
SB> developing computer-communications standards in an open fashion. An
SB> important part of this consensus-driven process is the pervasive use
SB> of mailing lists for discussion. Notably, in a small number of cases,
SB> a participant has engaged in a "denial-of-service" attack to disrupt
SB> the consensus-driven process. Regrettably, as these bad faith attacks
SB> become more common, the IETF needs to establish a practice that
SB> reduces or eliminates these attacks. This memo recommends such a
SB> practice for use by the IETF.
SB> Rose Expires November 2, 2003 [Page 1]
SB> Internet-Draft Revocation Practice: IETF Mailing Lists May 2003
SB> Table of Contents
SB> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
SB> 2. A Revocation Practice . . . . . . . . . . . . . . . . . . . . 4
SB> 3. Q & A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
SB> 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
SB> 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
SB> Normative References . . . . . . . . . . . . . . . . . . . . . 10
SB> Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
SB> Intellectual Property and Copyright Statements . . . . . . . . 11
SB> Rose Expires November 2, 2003 [Page 2]
SB> Internet-Draft Revocation Practice: IETF Mailing Lists May 2003
SB> 1. Introduction
SB> All self-governing bodies have ways of managing the scope of
SB> participant interaction. For example, deliberative assemblies often
SB> employ "rules of order" for determining who gets to speak, when, and
SB> for how long. Similarly, there is widespread agreement in so-called
SB> "liberal" societies that the right to free speech is not absolute,
SB> e.g., political speech is given more leeway than commercial speech,
SB> and some forms of speech (e.g., egregious libel or incitement to
SB> violence) are considered unacceptable.
SB> The IETF uses a consensus-driven process for developing
SB> computer-communications standards in an open fashion. An important
SB> part of this consensus-driven process is the pervasive use of mailing
SB> lists for discussion. Unlike many other organizations, anyone may
SB> post messages on those IETF mailing lists, and in doing so,
SB> participate in the IETF process. Historically, this approach has
SB> worked very well in the IETF, as it fosters participation from a wide
SB> range of stakeholders.
SB> Notably, in a small number of cases, a participant has engaged in a
SB> "denial-of-service" attack to disrupt the consensus-driven process.
SB> Typically, these attacks are made by repeatedly posting messages that
SB> are off-topic, inflammatory, or otherwise counter-productive. In
SB> contrast, good faith disagreement is a healthy part of the
SB> consensus-driven process.
SB> For example, if a working group is unable to reach consensus, this is
SB> an acceptable, albeit unfortunate, outcome; however, if that working
SB> group fails to achieve consensus because it is being continuously
SB> disrupted, then the disruption constitutes an abuse of the
SB> consensus-driven process. Interactions of this type are fundamentally
SB> different from "the lone voice of dissent" in which a participant
SB> expresses a view that is discussed but does not achieve consensus. In
SB> other words, individual bad faith should not trump community
SB> goodwill.
SB> Guidelines have been developed for dealing with abusive behavior
SB> (c.f., Section 6.1 of [1] and [2]). In practice, the application of
SB> those guidelines has included the temporary suspension of posting
SB> rights to a specific mailing list. If necessary, the length of the
SB> suspension has been increased with each successive suspension. In
SB> many cases, applying those guidelines will produce the desired
SB> modification in behaviour. However, as these bad faith attacks become
SB> more common and the desired modification in behaviour fails to be
SB> forthcoming, the IETF needs to establish a practice that directly
SB> reduces or eliminates these attacks.
SB> Rose Expires November 2, 2003 [Page 3]
SB> Internet-Draft Revocation Practice: IETF Mailing Lists May 2003
SB> 2. A Revocation Practice
SB> Please refer to [3] for the meaning conveyed by the uppercase words
SB> in this section.
SB> As a part of its activities, the Internet Engineering Steering Group
SB> (IESG) votes on "actions". Typically, an action refers to the
SB> publication of a document on the standards-track, the chartering of a
SB> working group, and so on. This memo recommends that the IESG also
SB> undertake a new type of action, termed a PR-action.
SB> A PR-action identifies one or more individuals, citing messages
SB> posted by those individuals to an IETF mailing list, that appear to
SB> be abusive of the consensus-driven process. If approved by the IESG,
SB> then:
SB> o those identified on the PR-action have their posting rights to
SB> that IETF mailing list removed; and,
SB> o maintainers of any IETF mailing list may, at their discretion,
SB> also remove posting rights to that IETF mailing list.
SB> Once taken, this action remains in force until explicitly nullified
SB> and MUST remain in force for at least one year.
SB> One year after the PR-action is approved, a new PR-action MAY be
SB> introduced which restores the posting rights for that individual. The
SB> IESG SHOULD consider the frequency of nullifying requests when
SB> evaluating a new PR-action. If the posting rights are restored the
SB> individual is responsible for contacting the owners of the mailing
SB> lists to have them restored.
SB> Regardless of whether the PR-action revokes or restores posting
SB> rights, the IESG follows the same algorithm as with its other
SB> actions:
SB> 1. it is introduced by an IESG Area Director (AD), who, prior to
SB> doing so, may choose to inform the interested parties;
SB> 2. is is published as an IESG last call on the IETF general
SB> discussion list;
SB> 3. it is discussed by the community;
SB> 4. it is discussed by the IESG; and, finally,
SB> 5. it is voted upon by the IESG.
SB> Rose Expires November 2, 2003 [Page 4]
SB> Internet-Draft Revocation Practice: IETF Mailing Lists May 2003
SB> Of course, as with all IESG actions, the appeals process outlined in
SB> [4] may be invoked to contest a PR-action approved by the IESG.
SB> Finally, working groups SHOULD ensure that their associated mailing
SB> list is manageable. For example, some may try to circumvent the
SB> revocation of their posting rights by changing email addresses.
SB> Rose Expires November 2, 2003 [Page 5]
SB> Internet-Draft Revocation Practice: IETF Mailing Lists May 2003
SB> 3. Q & A
SB> Q: Isn't a year too long?
SB> A: No.
SB> An initial PR-action is not undertaken lightly. It is approved
SB> only after a period of substantive consideration and community
SB> review. If a PR-action is approved, then this indicates that a
SB> serious situation has arisen.
SB> Q: Why not require one PR-action per IETF mailing list?
SB> A: To do so would enable a prolonged series of denial-of-service
SB> attacks.
SB> If someone is poorly-behaved on one IETF mailing list, but
SB> well-behaved on another, then the maintainer for the second IETF
SB> mailing list needn't revoke posting rights. However, the more
SB> likely scenario is that someone who behaves poorly on one IETF
SB> mailing list is unwilling to be well-behaved on any IETF mailing
SB> list.
SB> Q: Should the initiation of a PR-action come from outside the IESG?
SB> A: Informally, sure; formally, no.
SB> Under the IETF's consensus-driven process, IESG actions are always
SB> formally initiated by an IESG Area Director (AD). In practice, the
SB> motivation for an IESG member to initiate an action almost always
SB> comes from outside the IESG. For example, when a working group
SB> (WG) reaches consensus on a document, the WG chair informs the
SB> relevant AD that the document is ready for the AD to consider it
SB> for a document action. In the case of this document -- an IETF
SB> individual submission -- the author will iteratively circulate the
SB> document for wide discussion and make revisions. At some point,
SB> the author will contact an AD and ask for a document action to
SB> publish this document as a Best Current Practice (BCP).
SB> Q: Is this censorship?
SB> A: Only if you believe in anarchy.
SB> What is important is that the rules surrounding PR-actions exhibit
SB> the same properties used by the rest of the consensus-based
SB> process.
SB> Rose Expires November 2, 2003 [Page 6]
SB> Internet-Draft Revocation Practice: IETF Mailing Lists May 2003
SB> Q: C'mon! You really are a closet fascist.
SB> A: No, I'm a libertarian.
SB> Frankly, I would prefer that people behave reasonably and act in
SB> good faith. Since my first involvement with the IETF (nee GADS,
SB> circa 1983), everyone understood that reasonable behavior was a
SB> good thing. After 20 years, I regret to inform you that this step
SB> is inevitable.
SB> Rose Expires November 2, 2003 [Page 7]
SB> Internet-Draft Revocation Practice: IETF Mailing Lists May 2003
SB> 4. Acknowledgements
SB> The author gratefully acknowledges the contributions of: Brian
SB> Carpenter, Jim Galvin, Jeff Haas, and Bert Wijnen.
SB> Rose Expires November 2, 2003 [Page 8]
SB> Internet-Draft Revocation Practice: IETF Mailing Lists May 2003
SB> 5. Security Considerations
SB> This memo deals with matters of process, not protocol.
SB> Rose Expires November 2, 2003 [Page 9]
SB> Internet-Draft Revocation Practice: IETF Mailing Lists May 2003
SB> Normative References
SB> [1] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP
SB> 25, RFC 2418, September 1998.
SB> [2] Harris, S., "IETF Discussion List Charter", BCP 45, RFC 3005,
SB> November 2000.
SB> [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
SB> Levels", BCP 14, RFC 2119, March 1997.
SB> [4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
SB> 9, RFC 2026, October 1996.
SB> Author's Address
SB> Marshall T. Rose
SB> Dover Beach Consulting, Inc.
SB> POB 255268
SB> Sacramento, CA 95865-5268
SB> US
SB> Phone: +1 916 483 8878
SB> EMail: mrose@dbc.mtview.ca.us
SB> Rose Expires November 2, 2003 [Page 10]
SB> Internet-Draft Revocation Practice: IETF Mailing Lists May 2003
SB> Intellectual Property Statement
SB> The IETF takes no position regarding the validity or scope of any
SB> intellectual property or other rights that might be claimed to
SB> pertain to the implementation or use of the technology described in
SB> this document or the extent to which any license under such rights
SB> might or might not be available; neither does it represent that it
SB> has made any effort to identify any such rights. Information on the
SB> IETF's procedures with respect to rights in standards-track and
SB> standards-related documentation can be found in BCP-11. Copies of
SB> claims of rights made available for publication and any assurances of
SB> licenses to be made available, or the result of an attempt made to
SB> obtain a general license or permission for the use of such
SB> proprietary rights by implementors or users of this specification can
SB> be obtained from the IETF Secretariat.
SB> The IETF invites any interested party to bring to its attention any
SB> copyrights, patents or patent applications, or other proprietary
SB> rights which may cover technology that may be required to practice
SB> this standard. Please address the information to the IETF Executive
SB> Director.
SB> Full Copyright Statement
SB> Copyright (C) The Internet Society (2003). All Rights Reserved.
SB> This document and translations of it may be copied and furnished to
SB> others, and derivative works that comment on or otherwise explain it
SB> or assist in its implementation may be prepared, copied, published
SB> and distributed, in whole or in part, without restriction of any
SB> kind, provided that the above copyright notice and this paragraph are
SB> included on all such copies and derivative works. However, this
SB> document itself may not be modified in any way, such as by removing
SB> the copyright notice or references to the Internet Society or other
SB> Internet organizations, except as needed for the purpose of
SB> developing Internet standards in which case the procedures for
SB> copyrights defined in the Internet Standards process must be
SB> followed, or as required to translate it into languages other than
SB> English.
SB> The limited permissions granted above are perpetual and will not be
SB> revoked by the Internet Society or its successors or assignees.
SB> This document and the information contained herein is provided on an
SB> "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
SB> TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
SB> BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
SB> Rose Expires November 2, 2003 [Page 11]
SB> Internet-Draft Revocation Practice: IETF Mailing Lists May 2003
SB> HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
SB> MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
SB> Acknowledgement
SB> Funding for the RFC Editor function is currently provided by the
SB> Internet Society.
SB> Rose Expires November 2, 2003 [Page 12]
SB> --
SB> This message was passed to you via the ga@dnso.org list.
SB> Send mail to majordomo@dnso.org to unsubscribe
SB> ("unsubscribe ga" in the body of the message).
SB> Archives at http://www.dnso.org/archives.html
----
Don Brown - Dallas, Texas USA Internet Concepts, Inc.
donbrown_l@inetconcepts.net http://www.inetconcepts.net
PGP Key ID: 04C99A55 (972) 788-2364 Fax: (972) 788-5049
Providing Internet Solutions Worldwide - An eDataWeb Affiliate
----
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|