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


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