Re: [mpowr] WG Formation

Dave Crocker <dhc@dcrocker.net> Sat, 21 February 2004 21:11 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 QAA14744 for <mpowr-archive@odin.ietf.org>; Sat, 21 Feb 2004 16:11:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AueOl-0006zN-F5 for mpowr-archive@odin.ietf.org; Sat, 21 Feb 2004 16:10:55 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1LLAtif026859 for mpowr-archive@odin.ietf.org; Sat, 21 Feb 2004 16:10:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AueOl-0006z8-96 for mpowr-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 16:10:55 -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 QAA14722 for <mpowr-web-archive@ietf.org>; Sat, 21 Feb 2004 16:10:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AueOj-0006hb-00 for mpowr-web-archive@ietf.org; Sat, 21 Feb 2004 16:10:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AueNn-0006f3-00 for mpowr-web-archive@ietf.org; Sat, 21 Feb 2004 16:09:56 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AueMu-0006cf-00 for mpowr-web-archive@ietf.org; Sat, 21 Feb 2004 16:09:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AueMv-0006sY-Ac; Sat, 21 Feb 2004 16:09:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AueMt-0006sA-QL for mpowr@optimus.ietf.org; Sat, 21 Feb 2004 16:09:00 -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 QAA14693 for <mpowr@ietf.org>; Sat, 21 Feb 2004 16:08:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AueMs-0006c9-00 for mpowr@ietf.org; Sat, 21 Feb 2004 16:08:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AueLw-0006Zk-00 for mpowr@ietf.org; Sat, 21 Feb 2004 16:08:01 -0500
Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AueLg-0006Wp-00 for mpowr@ietf.org; Sat, 21 Feb 2004 16:07:44 -0500
Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1LLFVd05636; Sat, 21 Feb 2004 13:15:34 -0800
Date: Sat, 21 Feb 2004 22:41:29 +0900
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <1974503943.20040221224129@brandenburg.com>
To: John C Klensin <john-ietf@jck.com>
CC: mpowr@ietf.org
Subject: Re: [mpowr] WG Formation
In-Reply-To: <79230247.1076863665@scan.jck.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
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=1.0 required=5.0 tests=AWL,DATE_IN_PAST_06_12, PRIORITY_NO_NAME autolearn=no version=2.60
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

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.

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.


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.


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.

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.

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.


JCK>   I think that is a problem, 
JCK> a big one.  But, if you believe that can't be changed, then why 
JCK> is it reasonable to believe that they won't permit WGs to be 
JCK> created with half-baked evidence of viability and then permit 
JCK> _those_ to go on forever?  I'd rather see us

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.


JCK> 	this suggests we ought to be spending more time on
JCK> 	technical work, and monitoring of technical work, than
JCK> 	on charter nit-picking (regardless of what does, or does
JCK> 	not, precede chartering).

If a group cannot formulate a clear, focused problem statement and a
clear, focused, practical statement of the solution path, then
concern over the charter is not nit-picking.  It means that the group
really has no idea what it is going to do.

This being an engineering group rather than a research group or coffee
klatsch, it is rather serious for them to lack a shared sense of the
problem and how to approach solving it.


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.


JCK>  My strong impression is that, in the past, the
JCK> 	perceived lack of that backing has been an important
JCK> 	contributor to the problem of letting these groups

My strong impression is that that your strong impression is crap.

First of all, working groups thrash for a reason. Threats are rarely
successful against that reason. So the "simple" step of somehow giving
ADs more resolve entirely ignores the core problem. Feel free to cite
a pattern that shows otherwise.

Second of all, my strong impression is that ADs who are diligent and
forceful about shutting down wayward working groups do just fine.

Third of all, the model of expecting people who are not senior
management in their day job to display the kind of management
understanding and skill this requires is just plain inappropriate.

And lastly, relying on ADs to do post-hoc quality control is entirely
the wrong model.  Note the constant return to the question of
"trusting" ADs.  The IETF's problems are not really about ADs.  They
are about working groups doing their work.  So if we are going to make
changes, let us try to make sure that they change how working groups
work.

Once again:  You are seeking to change a possible community failure to
give proper support for ADs who might otherwise get the resolve to
shut down bad working groups.  I hope both the fuzziness and
indirectness of your model is clear in that description.

By contrast, I am merely suggesting that we require a group that is
going to consume IETF resources demonstrate that it has the skills
necessary to do the job it is contracting for.


JCK> 	drift: often, when one is shut down, the people who
JCK> 	still care about its work raise a mighty outcry, while
JCK> 	the rest of the community ignores the situation.

Of course they raise a mighty cry.  That does not mean anything.  Have
we suddenly become afraid of noise?

What means something is an appeal and a reversal.  Do we have a track
record of shutdowns being reversed?  Do we have a track record of
groups that are shut down later doing well (presumably elsewhere)?


JCK>   That
JCK> 	makes it, for most ADs, a lot easier to let a moribund
JCK> 	group drag on

Now you are at the heart of the matter:  Shutting down a group is a
painful act.  That's why we need to make it a true last-resort.  What
you want to do is to make it a primary management tool.


JCK> -- at least to the point that its
JCK> 	ineffectualness is painfully obvious to everyone

I might have thought that, too, but then we get groups like IMPP that
went through 4 years, 3(!) sets of working group chair, and still did
not have its act together.


JCK> The procedural change we may have a place for in this is a WG
JCK> with a specified sunset time.   E.g., a "Here is a charter, you 
JCK> are now subject to all of the normal WG rules, but you have X 
JCK> months to demonstrate that you are worth the trouble.   If you 
JCK> can demonstrate within that period that you are functional, we 
JCK> can negotiate a new charter.

Given our limited resources, why in the world would this sort of "say
yes easily and then try to figure things out later" model work?

Where can we look for an example that shows a pattern of success with
such a model?


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>


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