Re: [mpowr] WG Formation
John C Klensin <john-ietf@jck.com> Sun, 15 February 2004 21:52 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 QAA25949 for <mpowr-archive@odin.ietf.org>; Sun, 15 Feb 2004 16:52:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsUAz-0001Yg-V5 for mpowr-archive@odin.ietf.org; Sun, 15 Feb 2004 16:51:46 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FLpjiK005986 for mpowr-archive@odin.ietf.org; Sun, 15 Feb 2004 16:51:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsUAz-0001YT-Pn for mpowr-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 16:51: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 QAA25937 for <mpowr-web-archive@ietf.org>; Sun, 15 Feb 2004 16:51:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsUAx-0005PA-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 16:51:43 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsU9z-0005MC-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 16:50:44 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsU9K-0005Jj-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 16:50:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsU9L-0001WZ-2x; Sun, 15 Feb 2004 16:50:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsU92-0001VX-UL for mpowr@optimus.ietf.org; Sun, 15 Feb 2004 16:49: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 QAA25899 for <mpowr@ietf.org>; Sun, 15 Feb 2004 16:49:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsU91-0005J9-00 for mpowr@ietf.org; Sun, 15 Feb 2004 16:49:43 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsU85-0005Gd-00 for mpowr@ietf.org; Sun, 15 Feb 2004 16:48:46 -0500
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1AsU79-0005Dr-00 for mpowr@ietf.org; Sun, 15 Feb 2004 16:47:47 -0500
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1AsU77-0004Va-00; Sun, 15 Feb 2004 16:47:45 -0500
Date: Sun, 15 Feb 2004 16:47:45 -0500
From: John C Klensin <john-ietf@jck.com>
To: Dave Crocker <dcrocker@brandenburg.com>, Pete Resnick <presnick@qualcomm.com>
cc: mpowr@ietf.org
Subject: Re: [mpowr] WG Formation
Message-ID: <79230247.1076863665@scan.jck.com>
In-Reply-To: <747830562.20040215100030@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>
X-Mailer: Mulberry/3.1.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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 Sunday, 15 February, 2004 10:00 -0800 Dave Crocker <dhc@dcrocker.net> wrote: > I think the difference in our views involves very different > expectations about changing people's behavior. > > We have a track record of people behaving a certain way that is > inefficient and unproductive. Lots of different people, over a > long period of time. So it clearly is not a matter of > particular people. It is a matter of the organizational > structure and process. It is a matter of context. Yes, people > can change, but we have not yet figured out how to do that in > this forum. > > Rather than mandate that various people shall start behaving > differently, the suggestion is to remove the problem from the > IETF management venue. Allow entry only after a group has > demonstrated a basic ability to do the work necessary. > > In other words, the problem is with the context, so let's > change the context. Dave, One problem I have with your suggestion -- I think the major one -- is that it would actually reduce our ability to say "no, go away, this doesn't belong here" in a prompt and efficient way. As Pete points out, it would save surprisingly little in terms of the other things we do. Can that be fixed by "changing the context"? Not, I think, in the way you suggest. If we stop the circumlocutions, I think you are saying "the IESG doesn't have what it takes to shut down WGs that are not being productive". I think that is a problem, a big one. But, if you believe that can't be changed, then why is it reasonable to believe that they won't permit WGs to be created with half-baked evidence of viability and then permit _those_ to go on forever? I'd rather see us * Remind those ADs who haven't gotten Bert's message that getting a group to demonstrate that it is functional is usually a good pre-BOF criterion. * Focus as much thinking as possible on the principle that some WGs succeed in spite of sloppy charters, and others fail in spite of huge amounts of time spent trying to get their charters exactly right, and that this suggests we ought to be spending more time on technical work, and monitoring of technical work, than on charter nit-picking (regardless of what does, or does not, precede chartering). * Make sure the IESG understands that they will have strong community backing for killing off WGs that don't appear to be functional and/or worth the resources they consume. My strong impression is that, in the past, the perceived lack of that backing has been an important contributor to the problem of letting these groups drift: often, when one is shut down, the people who still care about its work raise a mighty outcry, while the rest of the community ignores the situation. That makes it, for most ADs, a lot easier to let a moribund group drag on -- at least to the point that its ineffectualness is painfully obvious to everyone -- than to shut it down when that would be most efficient. This is another situation in which, IMO, the community keeps sending the wrong message to the IESG and the IESG does what we want them to do, which is to listen and respond. The procedural change we may have a place for in this is a WG with a specified sunset time. E.g., a "Here is a charter, you are now subject to all of the normal WG rules, but you have X months to demonstrate that you are worth the trouble. If you can demonstrate within that period that you are functional, we can negotiate a new charter. If not, you disappear". I can't imagine a value of X greater than 12 months would ever make sense, and I can see values tied to an IETF meeting or two (e.g., "you get to meet at IETF NN, but, if you haven't shown significant progress by the time scheduling comes around for IETF NN+1, not only do you not get a meeting slot, but you disappear entirely"). More speedy and efficient experiments within the system, followed by quick termination if the experiments _succeed_ in showing that the ducks aren't lined of or the topic is IETF-inappropriate. But not more ways to encourage people to work in a way that is sort of in the system, and sort of out, with the expectation of monitoring that busy people won't do, etc. Pete has covered most of the rest of what I would say here if he hadn't, and expressed it better than I would have. 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