ICANN/GNSO
DNSO and GNSO Mailling lists archives

[ga]


<<< 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 >>>