Re: [mpowr] Mailing List Management
John C Klensin <john-ietf@jck.com> Tue, 23 December 2003 01:59 UTC
Received: from optimus.ietf.org ([132.151.1.19])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21093
for <mpowr-archive@odin.ietf.org>; Mon, 22 Dec 2003 20:59:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20) id 1AYbp1-0001mr-2d
for mpowr-archive@odin.ietf.org; Mon, 22 Dec 2003 20:58:55 -0500
Received: (from exim@localhost)
by www1.ietf.org (8.12.8/8.12.8/Submit) id hBN1ws8S006864
for mpowr-archive@odin.ietf.org; Mon, 22 Dec 2003 20:58:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20) id 1AYbp0-0001md-Q3
for mpowr-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 20:58:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21029
for <mpowr-web-archive@ietf.org>; Mon, 22 Dec 2003 20:58:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12)
id 1AYboy-0002J2-00
for mpowr-web-archive@ietf.org; Mon, 22 Dec 2003 20:58:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1AYbo8-0002Eo-00
for mpowr-web-archive@ietf.org; Mon, 22 Dec 2003 20:58:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
by ietf-mx with esmtp (Exim 4.12) id 1AYbo7-0002Eb-00
for mpowr-web-archive@ietf.org; Mon, 22 Dec 2003 20:57:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 1AYbo8-0001kx-IQ; Mon, 22 Dec 2003 20:58:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20) id 1AYbnt-0001kK-Tg
for mpowr@optimus.ietf.org; Mon, 22 Dec 2003 20:57:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20980
for <mpowr@ietf.org>; Mon, 22 Dec 2003 20:57:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12)
id 1AYblJ-000234-00
for mpowr@ietf.org; Mon, 22 Dec 2003 20:55:05 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1AYbhg-0001tq-00
for mpowr@ietf.org; Mon, 22 Dec 2003 20:51:21 -0500
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
by ietf-mx with esmtp (Exim 4.12) id 1AYbhf-0001tm-00
for mpowr@ietf.org; Mon, 22 Dec 2003 20:51:19 -0500
Received: from bs.jck.com ([209.187.148.211] helo=localhost)
by bs.jck.com with esmtp (Exim 4.10)
id 1AYbhS-000LL1-00; Mon, 22 Dec 2003 20:51:09 -0500
Date: Mon, 22 Dec 2003 17:01:53 -0500
From: John C Klensin <john-ietf@jck.com>
To: Harald Tveit Alvestrand <harald@alvestrand.no>, MPowr <mpowr@ietf.org>
Subject: Re: [mpowr] Mailing List Management
Message-ID: <11225820.1072112513@localhost>
In-Reply-To: <383969298.1071956717@localhost>
References: <011901c3c654$24fdc830$5b6015ac@dclkempt40>
<383969298.1071956717@localhost>
X-Mailer: Mulberry/3.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: mpowr-admin@ietf.org
Errors-To: mpowr-admin@ietf.org
X-BeenThere: mpowr@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpowr>,
<mailto:mpowr-request@ietf.org?subject=unsubscribe>
List-Id: Management Positions -- Oversight, Work and Results <mpowr.ietf.org>
List-Post: <mailto:mpowr@ietf.org>
List-Help: <mailto:mpowr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpowr>,
<mailto:mpowr-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06
autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
--On Saturday, December 20, 2003 21:45 -0800 Harald Tveit Alvestrand <harald@alvestrand.no> wrote: > in my opinion Alex Conta and Scott Bradner are wrong. > > There are cases where, for the good of the working group, a > person should have his or her posting privilleges revoked - > FAST - as on the order of a day or three. > > This is NOT a free speech issue - it has to do with the > ability of the IETF to conduct its work in an open and orderly > fashion - BOTH open AND orderly. > > For these cases, a simple procedure with 100% clarity on who > makes the decision is needed - not a "three strikes and then > wait another month" procedure, as any procedure involving the > whole IESG is likely to be. Two additions to Harald's comments... As people have probably deduced from other comments I've made, I'm very concerned about the ability of the IETF to produce high quality standards in, with apologies to Wirth, as much time as that takes but no longer. I don't think we are doing nearly as well at that -- along either the quality or speed/efficiency dimensions-- as we were several years ago. There are certainly some reasons for that which are unavoidable, e.g., our typical standard today really does seem to be more complex than was typical, say, a decade ago. But some of it is that "we" have just gotten tied up in a lot more procedures and rules and requirements. And, sometimes because of those procedures and requirements and sometimes because there is just less sense of collaboration and community, we seem much more subject to DoS attacks... whether through volume or abuse and whether intentionally or not. Those attacks need be to stopped in a length of time that is inverse to their severity. If someone is merely making a few off-topic postings too many, there should reasonably be warnings and a serious attempt to be sure that the person understands what is, and is not, off-topic before anyone starts contemplating revoking privileges. With more severe attacks, it may be entirely appropriate, IMO, to pull someone off a list instantly and negotiate (or appeal, or whatever) later. Do we need firm rules or procedures to cover these cases? I certainly hope not: not only do I not want to see more procedures, but because I am certain that they will not work, especially against someone whose intent really is to disrupt or prevent work getting done. I believe we should look at every potential new rule or procedure and ask ourselves the questions: (i) What is the problem this proposed rule is trying to solve? (ii) Will it actually solve that problem, or does it only address the easy cases that can be dealt with in other ways and/or some problem that occurred once or twice in the past but may not occur again? Put differently, if some protocol lawyer and potential deliberate abuser comes along and reads the rule, will he or she be able to find a loophole through which to cause harm and then claim that it is permitted behavior since the rule doesn't say anything about it? If the answer to that question is "yes", we are better off without highly-specific rules and procedures in almost all cases. (iii) Can we solve the problem equally well by clearly giving someone discretion and authority (ideally with general guidelines that represent clear community consensus) and then holding them responsible if they abuse one or the other or both? If the answers to those questions don't clearly indicate that we need a new rule we are, IMO, almost always better off without it. And I think the IESG ought to be going through the current collection of procedural rules, finding the ones that wouldn't be approved if the above criteria were applied, and getting rid of them. Now, going down this path probably implies that we will have more appeals, and maybe even a few recalls, in our future than we have had in the past. Personally, I would prefer to see that rather than having us spend large amounts of time getting rules just right which then, because of the loophole problem or other characteristics, end up getting appealed anyway. If the Nomcom does not understand that ADs are going to need to exercise a good deal of discretion so that it selects only people for those positions who can be trusted to do so wisely, then we better given them the message because nothing is going to work otherwise, no matter how many rules we make. If ADs don't understand that WG Chairs intrinsically have a lot of discretion and that they need to select only those people as WG Chairs who can be trusted to exercise it wisely, then we need a different set of ADs -- and, again, the Nomcom needs to understand that the ability to make those selection decisions wisely is an important requirement for ADs. So, should a WG Chair have the authority to put someone off a mailing list for at least a while? Yes, I think so (and really see no alternative that doesn't tie us in knots). Should there be some guidelines so that WG Chairs can guess what is appropriate, yes, if we can get someone to do the work. Should someone ejected from a list have the right to get (via appeal or otherwise), a quick review and response from the AD? Yes, and I hope that doesn't require a rule (see below). Should the WG Chair consult the relevant AD before pushing someone off a list? Yes, that would be sensible and reasonable. Should we _require_ that the WG Chair do that? No, I don't think so, partially because, if something really needs immediate action and the AD isn't available, the action shouldn't need to wait... But a WG Chair who pushes someone off a mailing list --or takes any of several other actions I think a WG Chair should be able to take on his or her own-- ought to expect to get fired if the AD later concludes that the judgments involved were excessively bad. So, the needed rules here are: (1) A WG Chair can eject someone from a meeting or mailing list or take any other reasonable action, if it is reasonably and sensibly required to prevent or eliminate disruptive activities so that the WG can get work done. In exercising that authority, the WG Chair is expected to consult as necessary and reflect current community culture and judgment as to what actions are appropriate under what types of circumstances. (2) Someone who has been ejected from a mailing list or otherwise subjected to WG Chair discipline has the right to appeal and has the right to expect a timely review and response to the first stage appeal to the relevant AD. ADs who do not respond to such appeals on a timely basis are a menace to the smooth and efficient workings of the IETF and should be swiftly recalled. What is interesting about those rules, of course, is that they don't require any changes to existing written formal rules and procedures, only the application of common sense to those rules... and changes to some of our habits and assumptions about how we do business. Two final coments, lest I be accused about writing too-short notes :-( (1) "Free speech" makes a nice chant. There are any number of places on the Internet in which it can be exercised. But, chants aside, the interpretation of "free speech" necessary to have a society work is that one person's free speech not create dangers for, or infringe on the rights of, others. In the IETF context, one should be "free" to "speak" on a given mailing list, or in a WG meeting, if ones postings are reasonably on-topic, constructive, polite, and civilized. If not, we need to remember that the costs of excessive hostile postings (for any definition of "hostile") include driving people off lists and participation in discussions whose input really would be valuable. We must not get to the point at which it becomes acceptable to have the requirements for participating in an IETF WG be not only expertise and a concern about the issues but also the willingness to suffer high-volume abuse. If we drive away the people who do have the expertise and concern but won't take the abuse, any claims we make to _community_ consensus around the results of the relevant WGs work become highly questionable. (2) This issue has nothing to do with debates about the political theory of the rights/ authority of a group versus those of it chair/ moderator/ leadership. Down through the centuries, people and organizations have always discovered that open, everyone-talks-at-once, assemblies are a lousy way of getting anything done and, as a result, figured out some "leadership" selection mechanism. And, regardless of how those people are selected (or for how long, or by whom), they always end up being give the authority to restrain or eject or isolate someone who is being sufficiently disruptive... or the organization doesn't survive and function. So, while I think ongoing discussions about how Chairs are selected, and to whom they have the most responsibility, are worthwhile, I think we need to accept that, in order to get work done, Chairs are going to need some authority to steer or moderate discussions, interpret and enforce agendas, and limit potential damage or disruptions... or we are basically finished around here except for the shouting (or whimpering). john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr
- [mpowr] Mailing List Management James Kempf
- RE: [mpowr] Mailing List Management Margaret.Wasserman
- Re: [mpowr] Mailing List Management Alex Rousskov
- Re: [mpowr] Mailing List Management Alex Conta
- Re: [mpowr] Mailing List Management James Kempf
- Re: [mpowr] Mailing List Management Alex Conta
- RE: [mpowr] Mailing List Management Alex Rousskov
- Re: [mpowr] Mailing List Management Spencer Dawkins
- Re: [mpowr] Mailing List Management Harald Tveit Alvestrand
- Re: [mpowr] Mailing List Management John C Klensin
- Re: [mpowr] Mailing List Management Alex Conta
- Re: [mpowr] Mailing List Management Alex Rousskov
- Re: [mpowr] Mailing List Management Alex Conta
- Re: [mpowr] Mailing List Management James Kempf
- Re: [mpowr] Mailing List Management Alex Rousskov
- Re: [mpowr] Mailing List Management James Kempf
- Re: [mpowr] Mailing List Management Melinda Shore
- Re: [mpowr] Mailing List Management Alex Rousskov
- Re: [mpowr] Mailing List Management James Kempf
- RE: [mpowr] Mailing List Management Margaret.Wasserman
- RE: [mpowr] Mailing List Management Margaret.Wasserman
- RE: [mpowr] Mailing List Management Alex Rousskov
- Re: [mpowr] Mailing List Management Alex Rousskov
- Re: [mpowr] Mailing List Management James Kempf
- RE: [mpowr] Mailing List Management John C Klensin
- Re: [mpowr] Mailing List Management Spencer Dawkins
- RE: [mpowr] Mailing List Management Margaret.Wasserman
- Re: [mpowr] Mailing List Management Alex Conta
- Re: [mpowr] Mailing List Management Alex Conta
- Re: [mpowr] Mailing List Management Spencer Dawkins
- RE: [mpowr] Mailing List Management John C Klensin
- RFC Editor doc approvals (RE: [mpowr] Mailing Lis… Harald Tveit Alvestrand
- Re: RFC Editor doc approvals (RE: [mpowr] Mailing… John C Klensin
- Re: RFC Editor doc approvals (RE: [mpowr] Mailing… Harald Tveit Alvestrand
- Re: RFC Editor doc approvals (RE: [mpowr] Mailing… Dave Crocker
- Re: [mpowr] Mailing List Management Harald Tveit Alvestrand
- Re: [mpowr] Mailing List Management Alex Rousskov
- Re: [mpowr] Mailing List Management Harald Tveit Alvestrand
- Re: [mpowr] Mailing List Management Alex Rousskov
- Re: [mpowr] Mailing List Management John C Klensin
- Re: Re: [mpowr] Mailing List Management Dave Crocker
- Re: [mpowr] Mailing List Management Alex Rousskov