Re: [mpowr] WG Formation
John C Klensin <klensin@jck.com> Sun, 22 February 2004 21:41 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09675 for <mpowr-archive@odin.ietf.org>; Sun, 22 Feb 2004 16:41:12 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av1LB-0000MG-GL for mpowr-archive@odin.ietf.org; Sun, 22 Feb 2004 16:40:45 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1MLej11001373 for mpowr-archive@odin.ietf.org; Sun, 22 Feb 2004 16:40:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av1LB-0000M4-C1 for mpowr-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 16:40: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 QAA09651 for <mpowr-web-archive@ietf.org>; Sun, 22 Feb 2004 16:40:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av1L9-0003u5-00 for mpowr-web-archive@ietf.org; Sun, 22 Feb 2004 16:40:43 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av1KI-0003rM-00 for mpowr-web-archive@ietf.org; Sun, 22 Feb 2004 16:39:51 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Av1JU-0003np-00 for mpowr-web-archive@ietf.org; Sun, 22 Feb 2004 16:39:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av1JV-0000JS-3e; Sun, 22 Feb 2004 16:39:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av0u4-0007VH-FW for mpowr@optimus.ietf.org; Sun, 22 Feb 2004 16:12:44 -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 QAA09028 for <mpowr@ietf.org>; Sun, 22 Feb 2004 16:12:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av0u2-0002O2-00 for mpowr@ietf.org; Sun, 22 Feb 2004 16:12:42 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av0t7-0002Le-00 for mpowr@ietf.org; Sun, 22 Feb 2004 16:11:46 -0500
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1Av0sY-0002Ip-00 for mpowr@ietf.org; Sun, 22 Feb 2004 16:11:11 -0500
Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 1Av0sP-0001RD-00; Sun, 22 Feb 2004 16:11:04 -0500
Date: Sun, 22 Feb 2004 14:20:04 -0500
From: John C Klensin <klensin@jck.com>
To: Dave Crocker <dcrocker@brandenburg.com>
cc: mpowr@ietf.org
Subject: Re: [mpowr] WG Formation
Message-ID: <12404238.1077459604@localhost>
In-Reply-To: <1974503943.20040221224129@brandenburg.com>
References: <Pine.LNX.4.56.0402040844140.19559@internaut.com> <327742548.1076153200@scan.jck.com> <1943493383.20040214081341@brandenburg.com> <38529151.1076758786@scan.jck.com> <14410174609.20040214094846@brandenburg.com> <19274234.1076779857@scan.jck.com> <52955238.20040214145840@brandenburg.com> <p06100d16bc545a46cf5e@[216.43.25.67]> <1461962205.20040215075530@brandenburg.com> <p06100d1bbc554a8e204c@[216.43.25.67]> <747830562.20040215100030@brandenburg.com> <79230247.1076863665@scan.jck.com> <1974503943.20040221224129@brandenburg.com>
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.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
--On Saturday, 21 February, 2004 22:41 +0900 Dave Crocker <dhc@dcrocker.net> wrote: > John, > > > JCK> One problem I have with your suggestion -- I think the > major one JCK> -- is that it would actually reduce our ability > to say "no, go JCK> away, this doesn't belong here" in a > prompt and efficient way. > > It does not do that at all. I think, perhaps, you've taken my > suggestion as meaning that performing the steps I described > would be "sufficient" for gaining working group status. No, I think it does something a little different. If we use, more or less, the current processes (see below), an AD who has told a group to demonstrate that it can be productive can say, at almost any time during the pre-WG, pre-BOF proof of concept period "sorry, this doesn't belong in the IETF, why don't you find another venue". If my guess as to how what you have proposed would play itself out is correct, we would be creating another "late surprise" situation: a group would go off and spend a lot of energy trying to prove concern, come in, and be told, "even if you have demonstrated that you can do that, we don't want it". Yes, that helps the IETF statistically -- the time that is wasted isn't "ours" -- but it isn't good for the Internet, since some of these activities really could thrive in other venues. > My suggestion is not meant to remove any other criteria that > we already have. > > And let me again stress that my suggestion is nothing but > codifying existing practise, in or to have it be applied > consistently, as Bert has essentially pointed out. No, it takes an existing practice that is used often, sometimes with great success, and turns it into the _only_ option. That ignores and excludes other paths that might work better in particular situations. As others have pointed out, if it were the existing practice, and it was working well in the overwhelming number of cases, we wouldn't be having this discussion. Or we shouldn't be having it and should, instead, be focusing on the bad practices and/or stupidity of selected ADs who can't recognize a good thing when they see it. But, as far as I can tell, the existing practice, even when applied, isn't good enough to solve a significant fraction of the situations we are talking about. To draw a perhaps-unfortunate analogy, this suggestion has the ring of mandatory sentencing laws: if one commits a crime that meets certain criteria, then the exact penalty is specified by law, with no possible deviations. Such things have the attraction that similar or identical crimes receive identical punishment, making the system very predictable. But they fail to allow for special or unusual circumstances that the criteria are, inevitably, never good (or prescient) enough to capture. My own preference --for both sentences and WG creation -- is for strong guidelines, perhaps even strong enough that judges or ADs who go outside them are expected to explain their reasoning in public, but for the flexibility for those people to consider all of the circumstances of a particular situation and apply judgment. > JCK> As Pete points out, it would save surprisingly little in > terms JCK> of the other things we do. > > I'm frankly surprised that the difference in management and > administrative overhead seems such a small thing to you. That is because I'm not convinced there is much difference in management and/or administrative overhead. No matter how we constitute these things, ADs often have a choice between "manage now or manage later". Under your plan, the "now" part becomes just general oversight. But where, I think, we may agree is that WGs that have a clear focus, good understanding of what they are about, and effective ways of working with the rest of the IETF simply require much less active management than ones that fail on one or more of those criteria. On the principle that early course corrections typically require fewer turns of the wheel --and may be more successful-- than later ones, I'd rather see ADs in a position to decide that spending some energy on a group early on in the hope that they will run more smoothly (and require significantly less management time) later is a good tradeoff. And, to some extent, your model, in order to make a reduction in management and administrative time early in a WG's life, discards the ability to make that sort of decision. > JCK> Can that be fixed by "changing the context"? Not, I > think, in JCK> the way you suggest. If we stop the > circumlocutions, I think JCK> you are saying "the IESG > doesn't have what it takes to shut down JCK> WGs that are not > being productive". > > The problem is bigger and deeper than that. Working group > creation is a particular moment of incentives and leverage. > After chartering, the only real leverage is changing chairs or > disbanding the working group. > > First of all, those are big hammers. Absent smaller ones then > we should do as much as we can to make sure the big hammer is > not needed. More stringent "entrance requirements" is a pretty > obvious way to make sure we are getting better "students" of > the IETF process. Well, part of what I've been arguing for is precisely to reduce the amount of energy it takes to lift and swing those hammers. We've seen perfectly good WGs that would meet any entrance criteria one could identify go off in the weeds after a while, and seen external developments create situations in which the WG is just on the wrong track (even if it remains within charter and current on benchmarks). "The world has passed you by, events have overtaken you, you are therefore irrelevant and should go away" should be as reasonable a criterion for shutting down a WG as anything else we have... and your proposal won't help with it at all. If we really wanted to shut down the unproductive, ineffective, and irrelevant, we would institute a probationary period for WGs in which each new one got, say, a year. At the end of that time, it would automatically come up for rechartering, would need to demonstrate that it was useful, productive, and not consuming more resources than its likely results justified. If it could not make that demonstration, it would disappear. Similar "sunset" limits on WG Chairs, etc., might not be a bad idea either. Now, at one level, a proposal like that is complementary to what you are proposing, not in conflict with it. But, in both cases, giving the ADs some explicit discretion seems to me to be more appropriate than trying to impose a particular management mechanism and style. > As for the IESG track record, you are kidding, right? Do we > have a solid pattern of wasteful, thrashing working groups > that drag on, being disbanded? I could have sworn we did not. We do not. That is a problem. Indeed, to my mind, a serious one. But imposing a rigid set of mechanisms on the IESG won't, IMO, fix it, _given the track record_. Instead... * The track record predicts that they will simply ignore such rules if they don't like them. Net effect: much wasted time, many hard feelings in the community. Now the community could start recalling people for ignoring written rules, but we don't have any track record of that either (partially, IMO, because of the "big hammer" problem and partially because we have all observed that pointing out to the Nomcom that some particular AD routinely ignores the rules doesn't reliably predict to that AD's being retired). (That is, of course, why "plan B" makes removal mandatory if an AD is recalled for ignoring certain types of rules.) * We further reduce the pool of possible ADs to including only those who like the management style we are trying to impose. I'd rather the Nomcom judge ADs on effectiveness (of which rule-following ought to be a part, but adherence to one particular management strategy should be secondary). > That leaves the IESG question to one of "they will do better". > And that leads to the questions "why, how and when"? > > Your suggestion requires no procedural changes. So the IESG > could have started taking this more stringent position > anytime. Yet they haven't. And I suggest that your suggestion, if approved (and remember that the IESG would need to approve it, so the discussion may be a waste of time if the IESG doesn't like the idea), would probably just be ignored by the same IESG, or the same ADs, who aren't inclined to do it today. > Your question is particularly important given that any > reasonable evaluation of the IETF's track record would say > that, indeed, that is exactly what has been happening. > > The idea is to change the IETF culture about the requirement, > so that it is a community thing, rather than an IESG thing. > The idea is to have the high bar for entrance be a shared > value, with complete transparency. And I believe in reasonably high bars for entrance _and_ in performance/ effectiveness reviews and in sunset periods. I believe that the longer a WG hangs around, the more it should need to do to justify its continued existence. I believe that any IETF activity that is consuming resources should be required to justify its continued existence in terms of the marginal opportunity costs of those resources. I just don't believe that a rigid rule about what someone has to do before getting a BOF or a WG --in minimum rules or in sequencing-- is going to help. Perhaps a partial example would be helpful in clarifying where I think we disagree. Suppose a group showed up tomorrow with a clearly-defined problem, a smattering of experience IETF types in its membership, and a theory about how they were going to proceed. Suppose the formation of the group came out of a bar-BOF at some IETF meeting, or a discussion in the hall during some conference or other non-IETF meeting. And suppose they think they can get something together and have it ready for standardization in nine months. I'd prefer to let them approach an AD with a proposal and a "good enough" charter draft, skip BOFs, go directly to a chartered WG with a minimum of fuss, recruit more participants as part of Charter posting, and go do their thing. I'd like the AD to be able to say "ok, I'll sign off on this given your promise that you can be finished in nine months, but, if you are still around at the end of month 12, I'm going to shut you down and you can start justifying a more realistic group and schedule". Now _that_ would reduce management and administrative time and investment. Will we see it very often? No, but we have seen a few very close approximations. And I would like to see those cases less bogged down in bureaucracy rather than more so. > JCK> * Make sure the IESG understands that they will have > JCK> strong community backing for killing off WGs that don't > JCK> appear to be functional and/or worth the resources they > JCK> consume. > > So, rather than put the affirmative burden on the group > supposed to do the work you want to increase the > responsibility on the IESG to perform a negative action. This > seems like a very bad process design. Nope. The burden is on the group either way. But groups rarely kill themselves, nor do they generally conclude that they aren't ready for whatever the next procedural step is. The IESG is going to need to make decisions either way ... unless one makes the process completely mechanical so that the necessary steps and actions are also treated as sufficient ones. john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr
- Re: [mpowr] Why MPOWR? John C Klensin
- Re: [mpowr] Why MPOWR? Melinda Shore
- [mpowr] Why MPOWR? Bernard Aboba
- Re: [mpowr] Why MPOWR? Joel M. Halpern
- Re: [mpowr] Why MPOWR? Pekka Savola
- Re: [mpowr] Why MPOWR? Spencer Dawkins
- Re: [mpowr] Why MPOWR? John C Klensin
- [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation John C Klensin
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation John C Klensin
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation Pete Resnick
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation Pete Resnick
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation John C Klensin
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation John C Klensin