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