Re: [mpowr] Why MPOWR?

John C Klensin <john-ietf@jck.com> Wed, 11 February 2004 18:56 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 NAA13768 for <mpowr-archive@odin.ietf.org>; Wed, 11 Feb 2004 13:56:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzWZ-0000dd-8f for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 13:55:51 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BItp5r002449 for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 13:55:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzWY-0000dQ-VK for mpowr-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 13:55:51 -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 NAA13747 for <mpowr-web-archive@ietf.org>; Wed, 11 Feb 2004 13:55:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzWW-0006CR-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 13:55:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzVa-00066b-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 13:54:51 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqzUm-00061W-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 13:54:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzUn-0000Re-PB; Wed, 11 Feb 2004 13:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzUb-0000Ff-0H for mpowr@optimus.ietf.org; Wed, 11 Feb 2004 13:53:53 -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 NAA13680 for <mpowr@ietf.org>; Wed, 11 Feb 2004 13:53:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzUY-00060U-00 for mpowr@ietf.org; Wed, 11 Feb 2004 13:53:46 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzTa-0005uo-00 for mpowr@ietf.org; Wed, 11 Feb 2004 13:52:47 -0500
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1AqzSa-0005ke-00 for mpowr@ietf.org; Wed, 11 Feb 2004 13:51:44 -0500
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1AqzSP-000ILU-00; Wed, 11 Feb 2004 13:51:33 -0500
Date: Wed, 11 Feb 2004 13:51:33 -0500
From: John C Klensin <john-ietf@jck.com>
To: "Joel M. Halpern" <joel@stevecrocker.com>, Pekka Savola <pekkas@netcore.fi>, mpowr@ietf.org
Subject: Re: [mpowr] Why MPOWR?
Message-ID: <18968725.1076507493@scan.jck.com>
In-Reply-To: <5.1.0.14.0.20040207182708.01b278d8@localhost>
References: <Pine.LNX.4.56.0402040844140.19559@internaut.com> <Pine.LNX.4.56.0402040844140.19559@internaut.com> <5.1.0.14.0.20040207182708.01b278d8@localhost>
X-Mailer: Mulberry/3.1.0 (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

Joel, and Pekka,

As you have probably guessed, this discussion was one of the 
inspirations for the "trust the IESG" 
(draft-klensin-problem-july15-00.txt) and "cannot trust the 
IESG" (draft-klensin-problem-planB-00.txt) drafts.  We need to 
get unstuck from the dichotomy of beliefs that Joel identifies, 
or, to be a little melodramatic, we are dead in the water and 
nothing else will make any difference.

While I'm appalled at some of the procedural changes the IESG 
has made, apparently without consulting anyone or making 
announcements (see my comments some months ago (on the 
Problem-Statement list, I think) about playing "gotcha" with the 
community), my personal view is that "trust the IESG" (aka "use 
your judgment") is the only plausible answer because:

	* No amount of charter-bashing is ever, in progress,
	going to define and eliminate all of the ways in which a
	WG might go wrong.  So someone --and, in our current
	model, it has to be the IESG or individual ADs-- has got
	to, in the last analysis, have the ability to make a
	judgment about overall community consensus and the
	health of the IETF and the Internet and shut off WGs who
	are not productive (see below).  And, for me at least,
	one clear corollary to that is that dragging out the
	chartering process is, beyond some point, a poor use of
	time.  When that point is reached is also, inevitably, a
	judgment call.  I think the community has driven the
	IESG to be too liberal about letting those discussions
	continue endlessly (ok, some IESG members have
	"helped"), and that we need to apply some corrections in
	that area.
	
	* I've "been there and done that" -- on the IESG, as a
	somewhat internal observer of the IESG from the IAB, and
	in management and overview positions in a number of
	other standards bodies.  My conclusion from those
	experiences is that any scheme that relies on in-depth
	community input and decision-making on every issue,
	rather than on the IESG's ability to interpret consensus
	and to lead, is going to either not work or will require
	us to adopt a formal system or membership and voting.
	
	* Given how much fun most of the people who are doing
	significant work in the IETF seem to find fussing with
	process and administrative issues, I'd much rather find
	13 or so hard-working and dedicated people who are
	willing to deal with this stuff and waste their time (on
	a "someone has to do it" basis) than waste the time of
	the thousands of the rest of us.  And, if an IESG member
	starts liking the process stuff too much, I hope the
	Nomcom is able to notice that and rotate him or her out
	-- in the interest of preserving the sanity of a valued
	colleague, if nothing else.

Sometimes, if we want an IESG-led model, we are going to have to 
shrug some things off as falling into the "sometimes consistency 
is the refuge of small minds" category.  Excessive procedural 
rigidity ultimately benefits neither the IESG, nor the IETF, nor 
the Internet.

Re "not producing", I intended that in the broadest way 
possible, to include everything Pekka lists and also "is taking 
up, and is likely to continue to take up, more energy to manage 
and keep pointed in the right direction than their outputs are 
likely to be worth ... either on an absolute scale or in 
comparison to other Area or IETF activities".   If we don't have 
a mechanism for shutting down a WG because it is no longer clear 
that the value of its likely product is worth the costs in 
management, oversight, reviews, meeting slots, etc., then, 
again, things are probably hopeless because every charter must 
be perfect in both definition and foresight.

     john


--On Saturday, 07 February, 2004 18:32 -0500 "Joel M. Halpern" 
<joel@stevecrocker.com> wrote:

> The problem I see with this is that the IESG (and IAB, and
> nomcom) are caught in the middle of a distinctly bimodal
> community.  A significant portion of the community (probably
> myself included) would be very happy with an approach that
> said "charter more easily, clsoe if the results / work starts
> to look bad."  The properties of this could be paraphrase as a
> direction to the leadership of "use you judgement." with the
> balance being that if they exhibit bad judgement the nomcom
> replaces them.
> Another (apparently equally large, and clearly equally
> vociferous) portion of the community is extremely
> uncomfortable with the leadership just using their judgement.
> Any time such judgement is used, they request detailed
> explanations.  If they disagree, they point to different
> behavior in the past an demand consistency.  This point of
> view is as defensible as the first one.
>...



--On Sunday, 08 February, 2004 09:01 +0200 Pekka Savola 
<pekkas@netcore.fi> wrote:

>
> .. you seem to state "aren't producing" as a criterion for
> shutting  down a WG.  I'm not sure if this is intended, but
> the problem seems to  be more generic than that.
>
> For example,
>
>  a) the WG could get nothing done, because of the lack of
> interested/committed people, or do so only slowly;
>
>  b) the WG might be getting something done, but the stuff
> produced  would not seem to be a useful approach (e.g.,
> architecturally wrong  choice after the fast-track WG process
> began)
>
>  c) the WG might be producing something, but the results will
> be  irrelevant, as it lacks the support/commitment from major
> vendors,  which would be a requirement for getting any useful
> work done (e.g.,  forces WG could be one example).
>
> There are probably more issues to spell out, but "aren't
> producing"  could be interpreted in a narrow fashion ("aren't
> producing  anything"), or broader ("aren't producing good,
> useful output").
>
> It is important to see the distinction, and the unavoidable
> pitfalls  of the latter interpretation, as b) and c) are
> likely to be another  (subjective) judgment call.
>
> Thus it seems to make sense to "charter carefully because
> you've got to live with the results", and "charter with
> sufficient number of checkpoints to check whether the WG is
> producing the right stuff".   However, this doesn't
> necessarily mean the chartering process needs to be slow..





_______________________________________________
mpowr mailing list
mpowr@ietf.org
https://www1.ietf.org/mailman/listinfo/mpowr