Re: [mpowr] Why MPOWR?

"Spencer Dawkins" <spencer@mcsr-labs.org> Sun, 08 February 2004 13:15 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 IAA18021 for <mpowr-archive@odin.ietf.org>; Sun, 8 Feb 2004 08:15:45 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApomK-00010d-NG for mpowr-archive@odin.ietf.org; Sun, 08 Feb 2004 08:15:16 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18DFGrT003873 for mpowr-archive@odin.ietf.org; Sun, 8 Feb 2004 08:15:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApomK-00010O-J8 for mpowr-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 08:15:16 -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 IAA18018 for <mpowr-web-archive@ietf.org>; Sun, 8 Feb 2004 08:15:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApomJ-0004yc-00 for mpowr-web-archive@ietf.org; Sun, 08 Feb 2004 08:15:15 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApolM-0004uw-00 for mpowr-web-archive@ietf.org; Sun, 08 Feb 2004 08:14:17 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Apol7-0004rT-00 for mpowr-web-archive@ietf.org; Sun, 08 Feb 2004 08:14:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apol7-0000yb-8Y; Sun, 08 Feb 2004 08:14:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApokL-0000yG-Ux for mpowr@optimus.ietf.org; Sun, 08 Feb 2004 08:13:13 -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 IAA17998 for <mpowr@ietf.org>; Sun, 8 Feb 2004 08:13:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApokL-0004qb-00 for mpowr@ietf.org; Sun, 08 Feb 2004 08:13:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApojO-0004n8-00 for mpowr@ietf.org; Sun, 08 Feb 2004 08:12:14 -0500
Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1ApoiR-0004gE-00 for mpowr@ietf.org; Sun, 08 Feb 2004 08:11:15 -0500
Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc12) with SMTP id <2004020813103901400hkn2he> (Authid: sdawkins@comcast.net); Sun, 8 Feb 2004 13:10:39 +0000
Message-ID: <041801c3ee44$f5881970$0400a8c0@DFNJGL21>
Reply-To: Spencer Dawkins <spencer@mcsr-labs.org>
From: Spencer Dawkins <spencer@mcsr-labs.org>
To: mpowr@ietf.org
References: <Pine.LNX.4.44.0402080852260.24167-100000@netcore.fi>
Subject: Re: [mpowr] Why MPOWR?
Date: Sun, 08 Feb 2004 07:10:40 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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

Hi, Pekka,

If I understand the conditions you named so far might be summarized as

- not doing much of anything,

- doing the wrong thing,

- not doing anything that matters.

Taking on the third condition seems impossible as long as we remain
commited to an IETF with individual participation and no formal
membership. If 30 people from five major vendors participate actively
in mailing list discussions and produce documents in a timely fashion,
this says nothing about the willingness of those vendors to produce
products based on those documents or the willingness of their
customers to deploy these products. IPv6.

This is a much easier call in other standards bodies. The assumption
is that if you have people working in 3GPP, where companies pay tens
of thousands of dollars to participate, and meeting participation is
required to get anything done (every couple of months, for a week at
the time, scheduled around the world), you really could take a nose
count.

3GPP SA2, which interacts heavily with IETF, has six week-long
meetings scheduled this year (2 in France, plus China, South Korea,
Canada, and the US), and its recommendations are approved at four more
weeklong SA plenaries (two in the US, plus South Korea and Greece).

It is a lot easier for people to participate in the IETF with minimal
backing from employers. We seem to like it that way, for various
reasons, and we may be doing it the right way.

But this does mean we can't use "lacks the support/commitment from
major vendors" as a reason to kill something.

Spencer

From: "Pekka Savola" <pekkas@netcore.fi>
To: "John C Klensin" <john-ietf@jck.com>
Cc: <mpowr@ietf.org>
Sent: Sunday, February 08, 2004 1:01 AM
Subject: Re: [mpowr] Why MPOWR?


> Hi,
>
> I agree with Joel's comments, so I don't repeat them here, but only
> want to spell out an issue explicitly..
>
> On Sat, 7 Feb 2004, John C Klensin wrote:
> > If we want this to stop, we need to make it _very_ clear to the
> > IESG, clear enough to overwhelm the noise, that we are tired of
> > it.  No more BOFs, and especially no second BOFs, unless it is
> > clear that useful information is likely to come out of them.
> > An accelerated chartering process with clear community support
> > for shutting down WGs that looked marginal at charter time, were
> > given a chance anyway, but aren't producing (there may be
> > elements of the O'Dell-Klensin and/or Huston-Rose proposals from
> > early in this reform process that might be useful here).
>
>
> .. 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