<<<
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).
I didn't see any response to Abel Wisman's request for clarification,
either.
We shouldn't be surprised.
The horse is dead - no sense in wasting any more energy trying to beat
it.
Thanks,
Monday, May 12, 2003, 1:49:09 PM, John Palmer <jp@ADNS.NET> wrote:
JP> For your information, my message to the powers that be regarding the infraction that
JP> I discovered was met with deafening silence. Do you realize that when you behave
JP> in the hypocritical way, that you loose all credibility. Why haven't my concerns been
JP> addressed by the list moderator?
JP> ----- Original Message -----
JP> From: "Don Brown" <donbrown_l@inetconcepts.net>
JP> To: <owner-ga@dnso.org>; "Stephane Bortzmeyer" <bortzmeyer@nic.fr>
JP> Cc: "Joop Teernstra" <terastra@terabytz.co.nz>; <ga@dnso.org>
JP> Sent: Friday, May 09, 2003 10:17
JP> Subject: Re: [ga] Re: Even Handed Application of The Rules (Yes or No? - We shall see) (was Re: [ga] Posting rights of Jeff Williams
JP> 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
>>
>>
>>
JP> --
JP> This message was passed to you via the ga@dnso.org list.
JP> Send mail to majordomo@dnso.org to unsubscribe
JP> ("unsubscribe ga" in the body of the message).
JP> 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
>>>
|