From exim@www1.ietf.org Sun Feb 1 23:59:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04791 for ; Sun, 1 Feb 2004 23:59:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnWAT-0002bg-AO for mpowr-archive@odin.ietf.org; Sun, 01 Feb 2004 23:58:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i124wfZW010014 for mpowr-archive@odin.ietf.org; Sun, 1 Feb 2004 23:58:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnWAT-0002bR-5l for mpowr-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 23:58:41 -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 XAA04607 for ; Sun, 1 Feb 2004 23:58:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnWAQ-0007cI-00 for mpowr-web-archive@ietf.org; Sun, 01 Feb 2004 23:58:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnW9J-0007O7-00 for mpowr-web-archive@ietf.org; Sun, 01 Feb 2004 23:57:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AnW8R-0007H9-03 for mpowr-web-archive@ietf.org; Sun, 01 Feb 2004 23:56:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AnVzI-0002oj-5m for mpowr-web-archive@ietf.org; Sun, 01 Feb 2004 23:47:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnVz9-0002AB-UZ; Sun, 01 Feb 2004 23:46:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnVyS-00021H-N2 for mpowr@optimus.ietf.org; Sun, 01 Feb 2004 23:46: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 XAA04290 for ; Sun, 1 Feb 2004 23:46:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnVyQ-0006Um-00 for mpowr@ietf.org; Sun, 01 Feb 2004 23:46:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnVxZ-0006QS-00 for mpowr@ietf.org; Sun, 01 Feb 2004 23:45:21 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1AnVws-0006Dh-00 for mpowr@ietf.org; Sun, 01 Feb 2004 23:44:38 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 6E5AA77AA09; Sun, 1 Feb 2004 23:44:07 -0500 (EST) To: David.Partain@ericsson.com From: Mark Allman Reply-To: mallman@icir.org Cc: mpowr@ietf.org Subject: Re: [mpowr] Re: Getting Bad Ideas to Fail Early In-Reply-To: <200401301538.06548.david.partain@ericsson.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Play Guitar Date: Sun, 01 Feb 2004 23:44:07 -0500 Message-Id: <20040202044407.6E5AA77AA09@guns.icir.org> 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 David- Thanks for the note! I think we are agreeing more than we are not. I think that any sort of early review mechanism needs to be a "first class" IETF citizen. It must explicitly have the respect and backing of the IESG. That's not to say that the IESG will always agree with every review produced by some early review entity (whatever that might look like). But, the IESG has to buy into the early review process in a way that everyone knows that the reviews do, in fact, carry some weight and that they are to be taken seriously by WGs and WG chairs. And, the expectation should be that issues raised during such reviews should be dealt with before documents are forwarded to the IESG. (And, of course, if the WG / WG chair is having a problem working through these issues the IESG should be willing to help manage that process. But, that is no different from the current system.) That said, I do not think that we need to assign any special "authority" to these reviews. For instance, I don't think such reviews would be more or less important than a high quality review received by a random person who read an i-d and decided to send some comment on it. All issues raised should be dealt with by the WG using due diligence. The major change I see is in the more explcit gathering of reviews from different perspectives - not in any special status they might have. My $0.02 for tonight. Thanks! allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 7 09:01:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04172 for ; Sat, 7 Feb 2004 09:01:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApT0n-0007nK-S3 for mpowr-archive@odin.ietf.org; Sat, 07 Feb 2004 09:00:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17E0jmL029958 for mpowr-archive@odin.ietf.org; Sat, 7 Feb 2004 09:00:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApT0n-0007n7-Ku for mpowr-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 09:00: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 JAA04120 for ; Sat, 7 Feb 2004 09:00:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApT0m-0007ey-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 09:00:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApSzo-0007TZ-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 08:59:46 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ApSyB-000787-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 08:58:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ApSyC-0008MF-72 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 08:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApSyA-0007WH-MR; Sat, 07 Feb 2004 08:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQ6Y-0000su-Bj for mpowr@optimus.ietf.org; Wed, 04 Feb 2004 11:42:22 -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 LAA13915 for ; Wed, 4 Feb 2004 11:42:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQ6X-0000Wq-00 for mpowr@ietf.org; Wed, 04 Feb 2004 11:42:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQ5a-0000RU-00 for mpowr@ietf.org; Wed, 04 Feb 2004 11:41:23 -0500 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1AoQ5L-0000M2-00 for mpowr@ietf.org; Wed, 04 Feb 2004 11:41:07 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i14Gs5621139 for ; Wed, 4 Feb 2004 08:54:05 -0800 Date: Wed, 4 Feb 2004 08:54:05 -0800 (PST) From: Bernard Aboba To: mpowr@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [mpowr] Why MPOWR? 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 If MPOWR is a solution, I would like to understand what the problem is. To me, the issue is not IESG overload. It is the inability of the IETF to deliver timely and relevant protocol standards. I can see how the standards track reforms and perhaps even cross area review might address that problem (though I'm skeptical about whether either will make a major difference), but MPOWR seems largely tangential. In general, I'd prefer to see the reform effort make an effort to pick a few success metrics and make substantive progress on them. The IETF is beginning to show signs of a vicious cycle, which when started, can become very hard to break. You don't break a cycle like that and start on an upward path again without a very clear idea of what you're trying to do, and what reforms can make a meaningful difference in the key success metrics, enough to make people stand up and take notice. A month ago, I attended the IEEE 802 meeting in Vancouver, and it resembled the IETF meetings of several years ago. Not just in spirit -- there were lots of former IETF attendees there, some former chairs of WGs, and even ex-IAB and IESG members. Many of them now consider IEEE 802 their primary standards body, not IETF. If we're going to bring those people back, we are going to need to do something to make the IETF a place where people feel convinced that they can get important work done in a timely way. Some simple reforms could probably make a measurable difference in the total time from a -00 to an RFC in the short term. For example, one could cut considerable time off the end of the process by addressing the issues with IANA and also by having a seminar at each IETF about reference dependencies. In examining the RFC Editor Queue, it is fairly clear to me that many authors do not understand what a normative dependency is, and as a result their drafts languish in the queue awaiting resolution of dependencies which are not really normative. There are even some drafts in the queue with no prospects for publication, since they have normative dependencies on drafts that were abandoned long ago and will never be completed (one of the MIDCOM documents is an example of this). A simple education program on normative references could probably cut several months off the average completion time. I also believe we could cut significant time off the beginning of the process by streamlining the BOF process and moving more quickly to form "study groups". There are quite a few cases where it has taken more than a year to form a working group, and even at least one case where formation took several years. Streamlining the BOF process seems quite likely to shave several months without a lot of effort. Making issue tracking facilities generally available to WGs is also something that is likely to cut significant time off the process. In at least one WG I've been involved in, it can be argued that the WG process only began to become effective *after* IESG review, when a tracking system was installed. More real work was done in 12 months with an issue tracking system than was accomplished in the previous two years. So significant productivity increases seem likely. A few months here, a few months there... soon you're talking about significant time savings. The difference between a standard that takes 3.5 years and one that takes 5 years is in practice, large. The former is late, but perhaps tolerable if the quality is high. The latter is likely to have arrived after the market has already chosen a (proprietary) alternative. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 7 09:01:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04189 for ; Sat, 7 Feb 2004 09:01:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApT0q-0007nq-Gb for mpowr-archive@odin.ietf.org; Sat, 07 Feb 2004 09:00:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17E0mRO029988 for mpowr-archive@odin.ietf.org; Sat, 7 Feb 2004 09:00:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApT0q-0007nb-6o for mpowr-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 09:00:48 -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 JAA04130 for ; Sat, 7 Feb 2004 09:00:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApT0o-0007fO-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 09:00:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApSzs-0007UB-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 08:59:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ApSyE-00078Z-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 08:58:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ApSyE-0008MI-Qf for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 08:58:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApSyA-0007WV-SP; Sat, 07 Feb 2004 08:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVk1-0006NT-7b for mpowr@optimus.ietf.org; Wed, 04 Feb 2004 17:43:29 -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 RAA05349 for ; Wed, 4 Feb 2004 17:43:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoVjy-0002qM-00 for mpowr@ietf.org; Wed, 04 Feb 2004 17:43:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoVj1-0002mF-00 for mpowr@ietf.org; Wed, 04 Feb 2004 17:42:28 -0500 Received: from pigeon.verisign.com ([65.205.251.71]) by ietf-mx with esmtp (Exim 4.12) id 1AoViI-0002ht-00 for mpowr@ietf.org; Wed, 04 Feb 2004 17:41:42 -0500 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id i14MfbeJ022371 for ; Wed, 4 Feb 2004 14:41:37 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <120CL008>; Wed, 4 Feb 2004 14:41:37 -0800 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0356EF96@mou1wnexm02.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "'mpowr@ietf.org'" Subject: Re: [mpowr] SUMMARY: Give WG chairs more shepherding responsibili ty? Date: Wed, 4 Feb 2004 14:41:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.3 required=5.0 tests=AWL autolearn=no version=2.60 >On Fri, 9 Jan 2004, Margaret Wasserman wrote: > > (1) There is rough consensus among the people active on this list > that WG chairs should be allowed to revoke the posting privileges of > disruptive participants with AD approval and the possibility of > appeal. > >There is one point that has not been made in this discussion far. >Personally, I believe a Working Group Chair should have the authority to >revoke posting privileges and further believe they would have it if it >was not explicitly assigned to the IESG by documented procedures. I think that the problem here is that there are not enough checks and balances on the WG chair, particularly if the chair is also an AD. The two recent bad experiences I have had with the IETF/IRTF are both cases where a WG chair has blatantly abused their position. What am I meant to think when the first time I stand up in a WG meeting I get heckled by the chair? What am I meant to think when I see a chair allowing a number of individuals to be highly disruptive, making personal insults to myself and other group members and a chair that refuses to step in? What am I meant to think when I see a chair using a group to publicise their own company in the media? What am I meant to think when the chair interprets criticism of proposals his company markets as a product as 'unacceptable and disruptive' behavior? What am I meant to think when a WG chair tells me that he has barred me from a WG list because I have proposed starting another working group in a different forum? I don't think, "lets give the WG chair the power to control all communications with the group". There are very good reasons why I called for the ASRG group to be disbanded. The original chair blatantly abused his position. But it took 6 months for anything to be done. Complaints get seen as being disruptive - even when they are later recognized and accepted as justified. The chair was replaced, but the damage was already done. The people I wanted to work with had left by that time. I think that what you need to have here is at the very least requirement that the chair tell the working group whenever a person is barred from the group and the grounds for doing so. I think you also need a mechanism where the WG gets to participate in the choice of chair and a means of forcing a recall. The way things work at the moment the chair will frequently change before most of the people in the group know there is even a vacancy. Phill _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 7 09:18:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04576 for ; Sat, 7 Feb 2004 09:18:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTH3-00017L-BD for mpowr-archive@odin.ietf.org; Sat, 07 Feb 2004 09:17:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17EHXQe004289 for mpowr-archive@odin.ietf.org; Sat, 7 Feb 2004 09:17:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTH3-000176-7S for mpowr-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 09:17:33 -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 JAA04572 for ; Sat, 7 Feb 2004 09:17:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApTH1-00011y-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 09:17:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApTG7-0000yk-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 09:16:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApTFX-0000vS-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 09:15:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTFY-0000rg-E6; Sat, 07 Feb 2004 09:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApTFF-0000pG-Bx for mpowr@optimus.ietf.org; Sat, 07 Feb 2004 09:15:41 -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 JAA04550 for ; Sat, 7 Feb 2004 09:15:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApTFD-0000vL-00 for mpowr@ietf.org; Sat, 07 Feb 2004 09:15:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApTEM-0000r3-00 for mpowr@ietf.org; Sat, 07 Feb 2004 09:14:46 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ApTDm-0000k8-00 for mpowr@ietf.org; Sat, 07 Feb 2004 09:14:10 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i17EDbpp024077; Sat, 7 Feb 2004 06:13:37 -0800 (PST) Received: from cisco.com ([10.25.65.182]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AQS42379; Sat, 7 Feb 2004 06:13:36 -0800 (PST) Date: Sat, 7 Feb 2004 09:13:34 -0500 Subject: Re: [mpowr] Why MPOWR? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: mpowr@ietf.org To: Bernard Aboba From: Melinda Shore In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Wednesday, February 4, 2004, at 11:54 AM, Bernard Aboba wrote: > There are even some drafts in the queue with no prospects for > publication, since they have normative dependencies on drafts that were > abandoned long ago and will never be completed (one of the MIDCOM > documents is an example of this). Note that the references in the midcom draft in question have been corrected and the revised document is in the RFC editor's hands. The problem in this particular case is that because we don't have a way of flagging documents as being dependencies there's no way to know who to notify when work on a document is stopped or the document is dropped completely. This isn't an mpowr problem but rather a tools problem. It would be useful to tag unpublished documents that are cited in somebody else's normative references so that when the documents change status notifications can be propagated. We're nowhere near being able to put that kind of capability in the hands of document editors, which is where it seems to me to belong. Melinda _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 7 11:31:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08172 for ; Sat, 7 Feb 2004 11:31:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVLs-0006gb-A7 for mpowr-archive@odin.ietf.org; Sat, 07 Feb 2004 11:30:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17GUemj025695 for mpowr-archive@odin.ietf.org; Sat, 7 Feb 2004 11:30:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVLs-0006gM-4C for mpowr-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 11:30:40 -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 LAA08166 for ; Sat, 7 Feb 2004 11:30:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApVLr-0001iz-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 11:30:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApVKt-0001f7-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 11:29:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApVKG-0001b0-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 11:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVKG-0006ap-GB; Sat, 07 Feb 2004 11:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVJr-0006aH-QO for mpowr@optimus.ietf.org; Sat, 07 Feb 2004 11:28:35 -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 LAA08131 for ; Sat, 7 Feb 2004 11:28:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApVJq-0001aG-00 for mpowr@ietf.org; Sat, 07 Feb 2004 11:28:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApVIs-0001WX-00 for mpowr@ietf.org; Sat, 07 Feb 2004 11:27:35 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1ApVI2-0001Sx-00 for mpowr@ietf.org; Sat, 07 Feb 2004 11:26:42 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1ApVI0-000C1F-00; Sat, 07 Feb 2004 11:26:40 -0500 Date: Sat, 07 Feb 2004 11:26:40 -0500 From: John C Klensin To: Bernard Aboba , mpowr@ietf.org Subject: Re: [mpowr] Why MPOWR? Message-ID: <327742548.1076153200@scan.jck.com> In-Reply-To: References: 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 I want to seize on, and expand a bit on, one aspect of Bernard's note (I generally agree with all of it)... --On Wednesday, 04 February, 2004 08:54 -0800 Bernard Aboba wrote: >... > I also believe we could cut significant time off the beginning > of the process by streamlining the BOF process and moving more > quickly to form "study groups". There are quite a few cases > where it has taken more than a year to form a working group, > and even at least one case where formation took several years. > Streamlining the BOF process seems quite likely to shave > several months without a lot of effort. >... This, unfortunately, is another example of the process-rot problem that I've been trying to point out. A decade ago, a BOF (much less a couple of BOFs) were not requirements for creating a WG. BOFs were used if there was a need to get more information about interest and focus; if that need did not appear to exist, we went directly into a charter process. If a BOF is unlikely to produce new information or insights, moving directly to chartering at least avoids having the nit-picking and grand philosophy arguments twice (or more) --once as to whether the BOF(s) should be permitted and with what agenda(s) and again over the details of the charter. More about the grand philosophy arguments below. In addition, there was a somewhat more relaxed attitude toward chartering WGs. Several ADs took the position that, if a group seemed coherent but was unfocused, it was rational to charter them as a WG and watch them closely for a while to determine whether they were going to produce something useful or go off into the weeds. If the latter, they got pruned, if the former, they flowered. The assumption was that the best way to evaluate whether a WG was going to do something useful and competent was to let it try. This direct approach was believed to be much more efficient, and less likely to waste a lot of everyone's time, than interminable discussions about charters, wondering whether WG proponents were trying to tune charters to what people wanted to hear even while planning something else, speculation about results, and so on. Growth, and the "just too many WGs" problem would make that model more difficult if applied today. More important, the IESG became shy of using it, probably for several reasons. Certainly one of them was hearing from too many WGs "we struggled to get a charter, you chartered us, we did all this work, so we are _entitled_ to complete our work and have our output standardized". Of course, the more time and effort goes into the chartering process, the stronger that argument gets. I also assume that most ADs would prefer to spend time managing/ coordinating WGs that are trying to do technical work --and shutting down those that are hopelessly wedged-- than to spend the same time in charter debates, especially philosophical ones. I might even suggest that people who don't have that preference are unsuitable to serve as ADs. It is important to note that the key procedures have not changed at all in the last decade. The evolution to "you need a BOF or two" and "charters are subject to long community debate" both occurred without formal process changes. If we don't like them --and they certainly add a lot to the time between "proposal to do work" and "finished product"-- they can presumably be undone by the same quiet and efficient mechanisms. Now these changes occurred mostly because of IESG perceptions (I think accurate ones) that the community wanted more input into early-stage WG establishment efforts. Well, that greater opportunity for discussion and greater openness now has a track record. The track record is dismal, at least with regard to a "how long does it take to get things done" criterion. We start a discussion. It generates a few comments and, especially in "hot button" areas, a lot of noise (see below). So a BOF is held, either because everyone believes by now that they are a requirement or to see if a face to face meeting resolves some of the controversy. It doesn't resolve the controversy, partially because it is easier for someone to block progress by seizing a microphone and grandstanding than it is to do so on a mailing list -- if only because most of us have adopted "delete before reading" approaches to comments beyond a certain number by some people on some threads (that has its own bad effects, but they are another matter). The mailing list is then filled, for the next few months, by the same noise, the same passionate arguments repeated many times, and by debates about what the first BOF actually concluded. So a second BOF is held in the vain hope of sorting that out, and the process repeats. If the effort then starts a charter process, the same arguments are replayed again, typically with little evidence that the BOFs were held or accomplished anything. But six months to a year go down the rathole -- much time spent, little real work done. 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). And we need to be able to try that way of doing things (again?) without getting bogged down for months in BOFs, chartering discussions, and philosophical arguments about how to plan the process to do so. We didn't need any of that process to get into this mess, and we shouldn't have to exercise the symptoms of the mess to get us out of it. (A couple of us are finishing up an I-D that suggests a radical way out of this impasse. It will be queued before the Monday deadline. But it doesn't suggest anything that couldn't be done tomorrow if the IESG sees a requirement and mandate for it, sees community rough consensus about that mandate, and is actually inclined to make changes rather than fostering debate about them.) Finally, that comment about philosophical debates. There are a number of hard philosophical and/or architectural questions facing the IETF and the Internet. They include a number of issues surrounding the NAT and middlebox questions; how much we are willing to distort the operations of well-established protocols in order to provide small, possibly-useful, patches for high-impact problems that arguably really lie elsewhere (spam fighting and the impact of email-spread and http/html-embedded malware being good examples here); questions about configuration alternatives; variations on the "open source" and/or "free software" debates; and so on. They are important issues. We need, IMO, to face and debate them in clear and open ways and, ideally, reach some conclusions. But passions about them run high on both (all?) sides. If every attempt to charter a WG or review a proposal for standardization that might infringe on one of those "hot button" areas restarts the debate in the context of that charter or proposal, things will move slowly --perhaps to the point that we will never get anything done-- and the passion of those debates will drown out any real analysis and discussion of the specifics of the proposal. Unfortunately, we have ample worked examples of that pattern, more than enough that we should be learning from them. The people who are doing this are presumably sufficiently self-aware to know who they are. In the interest of progress in the IETF --of having an IETF that, a few years from now, will [still be?] perceived as able to do useful work -- they need to stop attacking individual WG proposals and work on a more general debate and discussion. And, if they can't or won't --especially after the general decisions of what the IETF will and will not do in a particular area have been made-- then the community needs to understand that this behavior, no matter how well motivated, is as destructive to progress in the IETF as personal attacks, repeated off-topic postings, and so on, and deal with them accordingly. john p.s. While triggered by a note on MPOWR, this note probably is applicable across much of the "solutions" spectrum. If someone feels that it has enough value to call attention to it on some other list, feel free. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 7 18:36:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18302 for ; Sat, 7 Feb 2004 18:36:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApbzJ-0002FF-Mb for mpowr-archive@odin.ietf.org; Sat, 07 Feb 2004 18:35:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17NZnr2008629 for mpowr-archive@odin.ietf.org; Sat, 7 Feb 2004 18:35:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApbzJ-0002F6-5r for mpowr-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 18:35:49 -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 SAA18293 for ; Sat, 7 Feb 2004 18:35:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApbzG-0000kx-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 18:35:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApbyL-0000hX-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 18:34:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApbxW-0000dq-00 for mpowr-web-archive@ietf.org; Sat, 07 Feb 2004 18:33:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApbxY-0002BF-JR; Sat, 07 Feb 2004 18:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApbxO-0002AR-8n for mpowr@optimus.ietf.org; Sat, 07 Feb 2004 18:33:50 -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 SAA18263 for ; Sat, 7 Feb 2004 18:33:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApbxL-0000ct-00 for mpowr@ietf.org; Sat, 07 Feb 2004 18:33:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApbwP-0000ZS-00 for mpowr@ietf.org; Sat, 07 Feb 2004 18:32:50 -0500 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1ApbwJ-0000Vl-00 for mpowr@ietf.org; Sat, 07 Feb 2004 18:32:43 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6182116 for mpowr@ietf.org; Sat, 07 Feb 2004 18:32:38 -0500 Message-Id: <5.1.0.14.0.20040207182708.01b278d8@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 07 Feb 2004 18:32:20 -0500 To: mpowr@ietf.org From: "Joel M. Halpern" Subject: Re: [mpowr] Why MPOWR? In-Reply-To: <327742548.1076153200@scan.jck.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 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. However, I can not imagine how leadership should behave when there are equally strong demands for two such antithetical positions. Yours, Joel M. Halpern PS: Yes, I think this aspect at least belongs on MPOWR, because this drives very directly the question of allowing WG Chairs to use their judgement. At 11:26 AM 2/7/2004 -0500, 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). _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Feb 8 02:07:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04426 for ; Sun, 8 Feb 2004 02:07:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apj1z-0006es-Q6 for mpowr-archive@odin.ietf.org; Sun, 08 Feb 2004 02:07:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18773uc025578 for mpowr-archive@odin.ietf.org; Sun, 8 Feb 2004 02:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apj1y-0006e9-S3 for mpowr-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 02:07:02 -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 CAA03745 for ; Sun, 8 Feb 2004 02:07:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apj1v-0000so-00 for mpowr-web-archive@ietf.org; Sun, 08 Feb 2004 02:06:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Apj0y-0000oB-00 for mpowr-web-archive@ietf.org; Sun, 08 Feb 2004 02:06:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Apj03-0000iz-00 for mpowr-web-archive@ietf.org; Sun, 08 Feb 2004 02:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Apj01-0005gv-MO; Sun, 08 Feb 2004 02:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApizG-0005Ll-Ba for mpowr@optimus.ietf.org; Sun, 08 Feb 2004 02:04:14 -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 CAA00549 for ; Sun, 8 Feb 2004 02:04:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApizC-0000ew-00 for mpowr@ietf.org; Sun, 08 Feb 2004 02:04:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApiyL-0000ae-00 for mpowr@ietf.org; Sun, 08 Feb 2004 02:03:17 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Apixb-0000Ut-00 for mpowr@ietf.org; Sun, 08 Feb 2004 02:02:31 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1871mZ24683; Sun, 8 Feb 2004 09:01:49 +0200 Date: Sun, 8 Feb 2004 09:01:48 +0200 (EET) From: Pekka Savola To: John C Klensin cc: mpowr@ietf.org Subject: Re: [mpowr] Why MPOWR? In-Reply-To: <327742548.1076153200@scan.jck.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 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.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Feb 8 08:15:45 2004 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 ; 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 ; 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 ; 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" From: "Spencer Dawkins" To: References: Subject: Re: [mpowr] Why MPOWR? Date: Sun, 8 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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" To: "John C Klensin" Cc: 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 From exim@www1.ietf.org Sun Feb 8 23:18:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16590 for ; Sun, 8 Feb 2004 23:18: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 1Aq2rn-00011p-JG for mpowr-archive@odin.ietf.org; Sun, 08 Feb 2004 23:17:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i194Hp1H003953 for mpowr-archive@odin.ietf.org; Sun, 8 Feb 2004 23:17:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq2rm-00011g-GU for mpowr-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 23:17:50 -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 XAA16550 for ; Sun, 8 Feb 2004 23:17:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq2rf-0004Iz-00 for mpowr-web-archive@ietf.org; Sun, 08 Feb 2004 23:17:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq2qi-0004EB-00 for mpowr-web-archive@ietf.org; Sun, 08 Feb 2004 23:16:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq2q2-0004AF-00 for mpowr-web-archive@ietf.org; Sun, 08 Feb 2004 23:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq2q2-0000o1-HR; Sun, 08 Feb 2004 23:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq2pk-0000mx-SF for mpowr@optimus.ietf.org; Sun, 08 Feb 2004 23:15: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 XAA16472 for ; Sun, 8 Feb 2004 23:15:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq2pi-00048a-00 for mpowr@ietf.org; Sun, 08 Feb 2004 23:15:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq2ok-00043g-00 for mpowr@ietf.org; Sun, 08 Feb 2004 23:14:43 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1Aq2nw-0003wM-00 for mpowr@ietf.org; Sun, 08 Feb 2004 23:13:52 -0500 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc12) with SMTP id <2004020904132301400hif74e> (Authid: sdawkins@comcast.net); Mon, 9 Feb 2004 04:13:23 +0000 Message-ID: <00a301c3eec3$11868d90$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <20040202044407.6E5AA77AA09@guns.icir.org> Subject: Re: [mpowr] Re: Getting Bad Ideas to Fail Early Date: Sun, 8 Feb 2004 22:13:27 -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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 I agree with Mark on each point. One note below. Spencer ----- Original Message ----- From: "Mark Allman" To: Cc: Sent: Sunday, February 01, 2004 10:44 PM Subject: Re: [mpowr] Re: Getting Bad Ideas to Fail Early > > David- > > Thanks for the note! I think we are agreeing more than we are not. I > think that any sort of early review mechanism needs to be a "first > class" IETF citizen. It must explicitly have the respect and backing of > the IESG. That's not to say that the IESG will always agree with every > review produced by some early review entity (whatever that might look > like). But, the IESG has to buy into the early review process in a way > that everyone knows that the reviews do, in fact, carry some weight and > that they are to be taken seriously by WGs and WG chairs. And, the > expectation should be that issues raised during such reviews should be > dealt with before documents are forwarded to the IESG. (And, of course, > if the WG / WG chair is having a problem working through these issues > the IESG should be willing to help manage that process. But, that is no > different from the current system.) > > That said, I do not think that we need to assign any special "authority" > to these reviews. For instance, I don't think such reviews would be > more or less important than a high quality review received by a random > person who read an i-d and decided to send some comment on it. All > issues raised should be dealt with by the WG using due diligence. The > major change I see is in the more explcit gathering of reviews from > different perspectives - not in any special status they might have. Are we still talking about mechanisms to identify early reviewers? I think such a mechanism is a significant, and important, change. > > My $0.02 for tonight. > > Thanks! > > allman _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Feb 10 02:27:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03573 for ; Tue, 10 Feb 2004 02:27:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSI5-0001CP-Ie for mpowr-archive@odin.ietf.org; Tue, 10 Feb 2004 02:26:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A7Qfub004591 for mpowr-archive@odin.ietf.org; Tue, 10 Feb 2004 02:26:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSI3-0001Bp-MR for mpowr-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 02:26:39 -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 CAA03529 for ; Tue, 10 Feb 2004 02:26:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqSI0-0002XC-00 for mpowr-web-archive@ietf.org; Tue, 10 Feb 2004 02:26:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqSH3-0002Sv-00 for mpowr-web-archive@ietf.org; Tue, 10 Feb 2004 02:25:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqSGU-0002Oc-00 for mpowr-web-archive@ietf.org; Tue, 10 Feb 2004 02:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSGU-0000mI-L8; Tue, 10 Feb 2004 02:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSG6-0000gg-LI for mpowr@optimus.ietf.org; Tue, 10 Feb 2004 02:24:38 -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 CAA03374 for ; Tue, 10 Feb 2004 02:24:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqSG2-0002Nu-00 for mpowr@ietf.org; Tue, 10 Feb 2004 02:24:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqSF5-0002Ja-00 for mpowr@ietf.org; Tue, 10 Feb 2004 02:23:36 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AqSEO-0002BH-00 for mpowr@ietf.org; Tue, 10 Feb 2004 02:22:52 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EE90361B92; Tue, 10 Feb 2004 08:22:21 +0100 (CET) Date: Mon, 09 Feb 2004 23:12:50 -0800 From: Harald Tveit Alvestrand To: David.Partain@ericsson.com, mpowr@ietf.org Subject: Re: [mpowr] Re: Getting Bad Ideas to Fail Early Message-ID: <2480163516.1076368370@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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 30. januar 2004 12:31 +0100 "David Partain (LI/EAB)" wrote: >> > What do we do if the WG refuses to acknowledge that an idea is >> > "bad" and forges ahead? >> >> Wait for IESG to decide. It would be nice to design some procedure for >> IESG to decide sooner (early) rather than at PS stage. > > Might be a very good idea, but at the risk of making them > interrupt driven, which I personally find to be a hard way > to work. that would be no change ... the IESG document evaluation process is currently highly interrupt driven - the interrupt is the other ADs putting documents on the agenda..... _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Feb 10 12:17:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28176 for ; Tue, 10 Feb 2004 12:17:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqbVN-0007pO-I1 for mpowr-archive@odin.ietf.org; Tue, 10 Feb 2004 12:17:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AHH1Pk030087 for mpowr-archive@odin.ietf.org; Tue, 10 Feb 2004 12:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqbVN-0007pC-9Z for mpowr-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 12:17:01 -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 MAA28047 for ; Tue, 10 Feb 2004 12:16:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqbVL-0006tO-00 for mpowr-web-archive@ietf.org; Tue, 10 Feb 2004 12:17:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqbUM-0006jF-00 for mpowr-web-archive@ietf.org; Tue, 10 Feb 2004 12:15:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqbTR-0006dN-00 for mpowr-web-archive@ietf.org; Tue, 10 Feb 2004 12:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqbTR-0007mZ-H2; Tue, 10 Feb 2004 12:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqbTN-0007m4-Tq for mpowr@optimus.ietf.org; Tue, 10 Feb 2004 12:14:57 -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 MAA27989 for ; Tue, 10 Feb 2004 12:14:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqbTM-0006ci-00 for mpowr@ietf.org; Tue, 10 Feb 2004 12:14:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqbST-0006Xo-00 for mpowr@ietf.org; Tue, 10 Feb 2004 12:14:01 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1AqbS6-0006Sr-00 for mpowr@ietf.org; Tue, 10 Feb 2004 12:13:38 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1AqbS5-000Kje-00; Tue, 10 Feb 2004 12:13:37 -0500 Date: Tue, 10 Feb 2004 12:13:37 -0500 From: John C Klensin To: Harald Tveit Alvestrand , David.Partain@ericsson.com, mpowr@ietf.org Subject: Re: [mpowr] Re: Getting Bad Ideas to Fail Early Message-ID: <136684602.1076415217@scan.jck.com> In-Reply-To: <2480163516.1076368370@localhost> References: <2480163516.1076368370@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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Monday, 09 February, 2004 23:12 -0800 Harald Tveit Alvestrand wrote: > > > --On 30. januar 2004 12:31 +0100 "David Partain (LI/EAB)" > wrote: > >>> > What do we do if the WG refuses to acknowledge that an >>> > idea is "bad" and forges ahead? >>> >>> Wait for IESG to decide. It would be nice to design some >>> procedure for IESG to decide sooner (early) rather than at >>> PS stage. >> >> Might be a very good idea, but at the risk of making them >> interrupt driven, which I personally find to be a hard way >> to work. > > that would be no change ... the IESG document evaluation > process is currently highly interrupt driven - the interrupt > is the other ADs putting documents on the agenda..... Different answer, complementary to Harald's. If the AD responsible for a particular WG concludes that the WG is promoting "bad" ideas and can't get unstuck from them, has a very wide range of mechanisms available for focusing the WG's attention. We can discuss how these should be exercised, what degree of consultation should be required and with whom, etc., but the basic mechanisms remain. They include: * Additional, forceful, explanations of why the idea is bad and isn't going anywhere. ("reading of the riot act" is probably a member of this category) * Replacing WG Chairs * Rechartering the WG to eliminate the task(s) that the WG doesn't want to get right. * Closing the WG entirely. With the possible exception of the third (I can't think of an example at the moment) each of these has been used, at one time or another, in the past. They are not new, and do not require procedural changes. john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Feb 11 10:33:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05435 for ; Wed, 11 Feb 2004 10:33:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwM0-0008V0-9a for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 10:32:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BFWiNN032670 for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 10:32:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwM0-0008Ur-5P for mpowr-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 10:32: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 KAA05426 for ; Wed, 11 Feb 2004 10:32:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqwLy-00005z-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 10:32:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqwL7-00000Y-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 10:31:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqwKK-0007j6-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 10:31:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwKM-0008Lc-3y; Wed, 11 Feb 2004 10:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwK6-0008Kh-7J for mpowr@optimus.ietf.org; Wed, 11 Feb 2004 10:30:46 -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 KAA05346 for ; Wed, 11 Feb 2004 10:30:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqwK1-0007hv-00 for mpowr@ietf.org; Wed, 11 Feb 2004 10:30:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqwJ9-0007d0-00 for mpowr@ietf.org; Wed, 11 Feb 2004 10:29:48 -0500 Received: from smtp.exodus.net ([66.35.230.236]) by ietf-mx with esmtp (Exim 4.12) id 1AqwIQ-0007Rk-00 for mpowr@ietf.org; Wed, 11 Feb 2004 10:29:02 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp.exodus.net (8.12.8/8.12.8) with ESMTP id i1BH7Kw3004917 for ; Wed, 11 Feb 2004 09:07:20 -0800 Received: from ala-mrwtemp.thingmagic.com (unverified [24.61.30.237]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id for ; Wed, 11 Feb 2004 07:28:30 -0800 Message-Id: <5.1.0.14.2.20040211102507.04190e40@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Feb 2004 10:26:06 -0500 To: mpowr@ietf.org From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [mpowr] Fwd: I-D ACTION:draft-wasserman-rfc2418-ml-update-00.txt 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 FYI -- I attempted to capture our mailing list discussions in a (very short) draft. Feedback will be appreciated. Margaret >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-wasserman-rfc2418-ml-update-00.txt >Date: Tue, 10 Feb 2004 16:05:36 -0500 >Sender: owner-ietf-announce@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Update to RFC 2418 Regarding the Management of > IETF Mailing Lists > Author(s) : M. Wasserman > Filename : draft-wasserman-rfc2418-ml-update-00.txt > Pages : 9 > Date : 2004-2-10 > >This document is an update to RFC 2418 that gives WG chairs explicit >responsibility for managing WG mailing lists. In particular, it gives >WG chairs the authority to temporarily suspend the mailing list >posting privileges of disruptive individuals. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-wasserman-rfc2418-ml-update-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-wasserman-rfc2418-ml-update-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-wasserman-rfc2418-ml-update-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-2-10154649.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-wasserman-rfc2418-ml-update-00.txt > > _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Feb 11 13:56:19 2004 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 ; 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 ; 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 ; 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 To: "Joel M. Halpern" , Pekka Savola , 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: <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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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" 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 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 From exim@www1.ietf.org Wed Feb 11 14:10:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14818 for ; Wed, 11 Feb 2004 14:10:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzkE-00032K-Sc for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 14:09:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJ9weh011666 for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 14:09:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzkE-000325-Nr for mpowr-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 14:09:58 -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 OAA14770 for ; Wed, 11 Feb 2004 14:09:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzkC-0000C4-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 14:09:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzjJ-00002M-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 14:09:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqziI-0007i1-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 14:07:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqziK-0002oZ-D4; Wed, 11 Feb 2004 14:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzhS-0002aM-IT for mpowr@optimus.ietf.org; Wed, 11 Feb 2004 14:07:06 -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 OAA14583 for ; Wed, 11 Feb 2004 14:07:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzhQ-0007a8-00 for mpowr@ietf.org; Wed, 11 Feb 2004 14:07:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzgX-0007Sb-00 for mpowr@ietf.org; Wed, 11 Feb 2004 14:06:10 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqzfi-0007Kj-00 for mpowr@ietf.org; Wed, 11 Feb 2004 14:05:18 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1Aqzfi-000ISj-00; Wed, 11 Feb 2004 14:05:18 -0500 Date: Wed, 11 Feb 2004 14:05:18 -0500 From: John C Klensin To: Margaret Wasserman cc: mpowr@ietf.org Message-ID: <19793531.1076508318@scan.jck.com> 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 Subject: [mpowr] Re: Fwd: I-D ACTION:draft-wasserman-rfc2418-ml-update-00.txt 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Margaret, I think this summarizes what I have gotten out of the discussions, with one qualification, noted below. I'd love to see this be a candidate for either an immediate IETF Last Call or the procedure outlined in draft-klensin-process-july14-00.txt, since I have no reason to imagine that more debates about charters, or debates within a WG, would tell us anything we don't know already. (1) Qualification/ Substantive Issue: If you are going to be precise here, the last sentence should read something like "Other methods of mailing list control, and longer or additional suspensions, must be approved by the IESG or carried out in accordance with other IESG-approved procedures." This makes two changes, one of which I think is clearly consistent with mailing list discussions. The other is too, although less clearly because there has been less discussion: (i) The intent, as I understand it, is to permit a WG chair to rather quickly suspend posting privileges in an abusive situation and for a short period of time. Even the possibility of attaching a second 30 day suspension to the end of the first one smells like abuse, and was not what seems to be intended. So the WG Chair gets one 30 day suspension as specified, but longer or additional ones need some additional consultation, up through and including application of draft-mrose-ietf-posting-04.txt. (ii) Driven partially by the frustration and thinking that went into the above-cited "process-july15" draft, I note that the mailing list discussions identified a rather large space between "maybe shutting someone out for 30 days is ok" and "shutting someone off forever". I think we need to view that 30 days largely as a "cooling off" period and an opportunity for further consultation about what might happen next, if needed, and under what circumstances. At the same time, I believe that the IESG ought to be able to tailor the "what next" to the circumstances -- which might include giving guidance to the WG Chair about appropriate responses to different actions -- and then delegate authority, either to the Chair, an AD, an IESG-designated committee or subcommittee, or some combination of them that made sense. If we try to figure out those circumstances and rules in advance, we will end up with very long procedural documents that will always be responding to previous battles and wars. (2) The -01 version of this, if there is one, needs spell-checking. (3) The procedural change I'd most like to see --not, in any sense, the one that is the most important, but one of those I find most irritating -- would result in an Internet Draft with two or three pages of substance not ending up nine pages long. I think those 8 1/2 pages are yet another symptom that things have gotten somewhat out of hand. john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Feb 11 15:57:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23161 for ; Wed, 11 Feb 2004 15:57:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Pj-0004vf-LM for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 15:56:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKutfO018946 for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 15:56:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Pj-0004vV-Go for mpowr-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 15:56: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 PAA23148 for ; Wed, 11 Feb 2004 15:56:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Pi-0004JE-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 15:56:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1Ol-0004CZ-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 15:55:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Nv-00046a-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 15:55:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Nt-0004dt-PR; Wed, 11 Feb 2004 15:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1N8-0004b1-5K for mpowr@optimus.ietf.org; Wed, 11 Feb 2004 15:54:14 -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 PAA22901 for ; Wed, 11 Feb 2004 15:54:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1N6-0003zq-00 for mpowr@ietf.org; Wed, 11 Feb 2004 15:54:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1MC-0003s6-00 for mpowr@ietf.org; Wed, 11 Feb 2004 15:53:17 -0500 Received: from smtp.exodus.net ([66.35.230.237] helo=smtp02-w.exodus.net) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Lg-0003jC-00 for mpowr@ietf.org; Wed, 11 Feb 2004 15:52:44 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp02-w.exodus.net (8.12.8/8.12.8) with ESMTP id i1BI1fEv018014 for ; Wed, 11 Feb 2004 12:01:41 -0600 Received: from ala-mrwtemp.thingmagic.com (unverified [207.31.248.169]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Wed, 11 Feb 2004 12:52:12 -0800 Message-Id: <5.1.0.14.2.20040211142958.03fec7e8@ms101.mail1.com> X-Sender: margaret@thingmagic.com@ms101.mail1.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Feb 2004 14:49:48 -0500 To: John C Klensin From: Margaret Wasserman Cc: mpowr@ietf.org In-Reply-To: <19793531.1076508318@scan.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [mpowr] Re: Fwd: I-D ACTION:draft-wasserman-rfc2418-ml-update-00.txt 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Hi John, At 02:05 PM 2/11/2004 -0500, John C Klensin wrote: >I think this summarizes what I have gotten out of the discussions, with >one qualification, noted below. I'd love to see this be a candidate for >either an immediate IETF Last Call or the procedure outlined in >draft-klensin-process-july14-00.txt, since I have no reason to imagine >that more debates about charters, or debates within a WG, would tell us >anything we don't know already. I prefer an approach that runs: (1) Tune as needed, (2) Four week last call, (3) Publish. I'd accept the experimental July 14 approach, though. >(i) The intent, as I understand it, is to permit a WG chair to rather >quickly suspend posting privileges in an abusive situation and for a short >period of time. Even the possibility of attaching a second 30 day >suspension to the end of the first one smells like abuse, and was not what >seems to be intended. So the WG Chair gets one 30 day suspension as >specified, but longer or additional ones need some additional >consultation, up through and including application of >draft-mrose-ietf-posting-04.txt. I'm not sure that I fully agree.... I agree that a chair should not ban someone from a mailing list for longer than 30 days by issuing back-to-back 30 day suspensions. However, I do think that a chair should be able to suspend a person for 30 days, let him back on the list, and eventually suspend him for 30 days again if there is another period of disruptive behaviour. How about changing that final sentence to a separate paragraph that says: This mechanism is intended to permit a WG chair to suspend posting privileges of a disruptive individual for a short period of time. This mechanism does not permit WG chairs to suspend an individual's posting privileges for a period longer than 30 days regardless of the type or severity of the disruptive incident. However, further disruptive behaviour by the same individual will be considered separately and may result in further warnings or suspensions. Other methods of mailing list control, including longer suspensions, must be approved by the IESG or carried out in accordance with other IESG-approved procedures. >(2) The -01 version of this, if there is one, needs spell-checking. Sorry, I produced it under a rather tight deadline. I expect to publish an -01 update shortly after Seoul (hopefully for IETF Last Call), and I'll do better. >(3) The procedural change I'd most like to see --not, in any sense, the >one that is the most important, but one of those I find most irritating -- >would result in an Internet Draft with two or three pages of substance not >ending up nine pages long. I think those 8 1/2 pages are yet another >symptom that things have gotten somewhat out of hand. Me, too. Some of the length can be attributed to the fact that the formatting tool I use puts each section on a new page. Does anyone know if there is an option in xml2rfc to override that? But, there are at least 4 pages of overhead, most of which has very limited utility. Margaret _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Feb 11 16:24:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26549 for ; Wed, 11 Feb 2004 16:24:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1q5-00089l-57 for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 16:24:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLO9tS031352 for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 16:24:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1q4-00089b-OJ for mpowr-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 16:24:09 -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 QAA26428 for ; Wed, 11 Feb 2004 16:24:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1q2-0001OS-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 16:24:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1oU-00010m-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 16:22:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1nV-0000kr-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 16:21:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar1iG-0006Ij-9q for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 16:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1iD-00073l-Bv; Wed, 11 Feb 2004 16:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1hI-00072G-Up for mpowr@optimus.ietf.org; Wed, 11 Feb 2004 16:15:04 -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 QAA25061 for ; Wed, 11 Feb 2004 16:15:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1hH-0007JZ-00 for mpowr@ietf.org; Wed, 11 Feb 2004 16:15:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1g7-00074Z-00 for mpowr@ietf.org; Wed, 11 Feb 2004 16:13:52 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1es-0006kd-00 for mpowr@ietf.org; Wed, 11 Feb 2004 16:12:34 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1Ar1er-000KW8-00; Wed, 11 Feb 2004 16:12:33 -0500 Date: Wed, 11 Feb 2004 16:12:33 -0500 From: John C Klensin To: Margaret Wasserman cc: mpowr@ietf.org Message-ID: <27428319.1076515953@scan.jck.com> In-Reply-To: <5.1.0.14.2.20040211142958.03fec7e8@ms101.mail1.com> References: <5.1.0.14.2.20040211142958.03fec7e8@ms101.mail1.com> 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 Subject: [mpowr] Re: Fwd: I-D ACTION:draft-wasserman-rfc2418-ml-update-00.txt 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Wednesday, 11 February, 2004 14:49 -0500 Margaret Wasserman wrote: > > Hi John, > > At 02:05 PM 2/11/2004 -0500, John C Klensin wrote: > >> I think this summarizes what I have gotten out of the >> discussions, with one qualification, noted below. I'd love >> to see this be a candidate for either an immediate IETF Last >> Call or the procedure outlined in >> draft-klensin-process-july14-00.txt, since I have no reason >> to imagine that more debates about charters, or debates >> within a WG, would tell us anything we don't know already. > > I prefer an approach that runs: (1) Tune as needed, (2) Four > week last call, (3) Publish. > > I'd accept the experimental July 14 approach, though. Of course, the two differ only in how much time one spends tuning before the Last Call is issued. The "July 14" approach would move a little closer toward "issue four week last call, then make tuning improvements suggested during the last call before publication". That difference is not significant enough to spend time on, unless the "tune as needed" process is likely to consume an unbounded amount of time. Of course, were one to make an inference from the charter discussion, that may be worth worrying about :-( >> (i) The intent, as I understand it, is to permit a WG chair >> to rather quickly suspend posting privileges in an abusive >> situation and for a short period of time. Even the >> possibility of attaching a second 30 day suspension to the >> end of the first one smells like abuse, and was not what >> seems to be intended. So the WG Chair gets one 30 day >> suspension as specified, but longer or additional ones need >> some additional consultation, up through and including >> application of draft-mrose-ietf-posting-04.txt. > > I'm not sure that I fully agree.... > > I agree that a chair should not ban someone from a mailing > list for longer > than 30 days by issuing back-to-back 30 day suspensions. > However, I do think > that a chair should be able to suspend a person for 30 days, > let him back on > the list, and eventually suspend him for 30 days again if > there is another > period of disruptive behaviour. Ok. I don't have a strong feeling one way or the other. And I think this falls clearly into the category of things about which will learn more by trying it than by endless debate. I'd rather see us get moving --on either model-- and then tune as/if needed, than spend a lot of time debating this. > How about changing that final sentence to a separate paragraph > that says: > > This mechanism is intended to permit a WG chair to suspend > posting privileges > of a disruptive individual for a short period of time. This > mechanism does > not permit WG chairs to suspend an individual's posting > privileges for > a period longer than 30 days regardless of the type or > severity of the > disruptive incident. However, further disruptive behaviour by > the same > individual will be considered separately and may result in > further warnings > or suspensions. Other methods of mailing list control, > including longer > suspensions, must be approved by the IESG or carried out in > accordance with > other IESG-approved procedures. Sure. Whatever turns you on. See above. >> (2) The -01 version of this, if there is one, needs >> spell-checking. > > Sorry, I produced it under a rather tight deadline. I expect > to publish > an -01 update shortly after Seoul (hopefully for IETF Last > Call), and I'll do better. Not a problem. I noticed and thought it was worth flagging. >> (3) The procedural change I'd most like to see --not, in any >> sense, the one that is the most important, but one of those >> I find most irritating -- would result in an Internet Draft >> with two or three pages of substance not ending up nine >> pages long. I think those 8 1/2 pages are yet another >> symptom that things have gotten somewhat out of hand. > > Me, too. Some of the length can be attributed to the fact > that the > formatting tool I use puts each section on a new page. Does > anyone > know if there is an option in xml2rfc to override that? You are probably looking for but should be warned that it has other consequences, such as squeezing lists up against preceding and subsequent text. > But, there are at least 4 pages of overhead, most of which has > very limited utility. Dear IESG member :-) ...my recollection is that almost every time the lawyers have been carefully asked about this, they have agreed that much of that text can be incorporated by reference, especially in I-Ds. Somehow, we have ended up with a requirement for all of the text in the I-Ds themselves, and it wasn't because there was a community discussion, a Last Call, etc. The one argument I've heard for its inclusion is that, if I'm forced to explicitly include it, I at least can't claim I don't know what I've agreed to. But tools like xml2rfc make that argument largely, if not completely, obsolete, since the only thing that actually gets included is and it then spews out all of the boilerplate, including the bits that flunk my spell and/or grammar checkers. At the risk of turning this into a mantra, "the IESG created this problem, the IESG can fix it (with no in-depth or amateur lawyer help from the community)". And, that said, I strongly suspect the IESG has more important priorities, and I trust you (collectively) to make that decision too. best, john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Feb 11 17:25:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04019 for ; Wed, 11 Feb 2004 17:25:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2mv-0007Xp-V7 for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 17:24:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BMOva8028989 for mpowr-archive@odin.ietf.org; Wed, 11 Feb 2004 17:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2mv-0007XS-Kz for mpowr-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 17:24:57 -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 RAA03989 for ; Wed, 11 Feb 2004 17:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2mt-0003Um-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 17:24:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2m7-0003MQ-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 17:24:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2l1-0003Ca-00 for mpowr-web-archive@ietf.org; Wed, 11 Feb 2004 17:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2l3-0007Ak-JM; Wed, 11 Feb 2004 17:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2l1-0007AR-Qg for mpowr@optimus.ietf.org; Wed, 11 Feb 2004 17:22:59 -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 RAA03862 for ; Wed, 11 Feb 2004 17:22:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2kz-0003CE-00 for mpowr@ietf.org; Wed, 11 Feb 2004 17:22:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2k8-00034V-00 for mpowr@ietf.org; Wed, 11 Feb 2004 17:22:05 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar2jc-0002w4-00 for mpowr@ietf.org; Wed, 11 Feb 2004 17:21:32 -0500 Received: from chardonnay ([127.0.0.1] helo=chardonnay.local.levkowetz.com) by chardonnay.local.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1Ar2jY-0003Zc-00; Wed, 11 Feb 2004 23:21:28 +0100 Date: Wed, 11 Feb 2004 23:21:24 +0100 From: Henrik Levkowetz To: Margaret Wasserman Cc: John C Klensin , mpowr@ietf.org Subject: Re: [mpowr] Re: Fwd: I-D ACTION:draft-wasserman-rfc2418-ml-update-00.txt Message-Id: <20040211232124.4ca441dc.henrik@levkowetz.com> In-Reply-To: <5.1.0.14.2.20040211142958.03fec7e8@ms101.mail1.com> References: <19793531.1076508318@scan.jck.com> <5.1.0.14.2.20040211142958.03fec7e8@ms101.mail1.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Margaret, Since I'm replying to your xml2rfc question at the bottom, I might as well touch on the rest too.. Wednesday 11 February 2004, Margaret Wasserman wrote: > How about changing that final sentence to a separate paragraph that > says: > > This mechanism is intended to permit a WG chair to suspend posting privileges > of a disruptive individual for a short period of time. This mechanism does > not permit WG chairs to suspend an individual's posting privileges for > a period longer than 30 days regardless of the type or severity of the > disruptive incident. However, further disruptive behaviour by the same > individual will be considered separately and may result in further warnings > or suspensions. Other methods of mailing list control, including longer > suspensions, must be approved by the IESG or carried out in accordance with > other IESG-approved procedures. I find this is an improvement over both -00 and Johns alternative. > >(2) The -01 version of this, if there is one, needs spell-checking. > > Sorry, I produced it under a rather tight deadline. I expect to publish > an -01 update shortly after Seoul (hopefully for IETF Last Call), and I'll > do better. If you are running a system with ispell on it (linux, or windows with cygwin) you can use ispell with the -h flag on the .xml file before running it through xml2rfc. Works well. > >(3) The procedural change I'd most like to see --not, in any sense, the > >one that is the most important, but one of those I find most irritating -- > >would result in an Internet Draft with two or three pages of substance not > >ending up nine pages long. I think those 8 1/2 pages are yet another > >symptom that things have gotten somewhat out of hand. Agree. > Me, too. Some of the length can be attributed to the fact that the > formatting tool I use puts each section on a new page. Does anyone > know if there is an option in xml2rfc to override that? Add this at the top of the .xml file (after the XML declaration): Henrik _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Feb 13 04:08:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29410 for ; Fri, 13 Feb 2004 04:08:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZIg-0007i0-Op for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 04:07:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D97reH029626 for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 04:07:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZIe-0007hl-GU for mpowr-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 04:07:52 -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 EAA29403 for ; Fri, 13 Feb 2004 04:07:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZIW-0002Md-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 04:07:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZHZ-0002HR-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 04:06:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArZGl-0002Ds-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 04:05:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZGs-0007XN-Gb; Fri, 13 Feb 2004 04:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZGh-0007X5-7B for mpowr@optimus.ietf.org; Fri, 13 Feb 2004 04:05: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 EAA29325 for ; Fri, 13 Feb 2004 04:05:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZGY-0002Cn-00 for mpowr@ietf.org; Fri, 13 Feb 2004 04:05:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZFa-00028N-00 for mpowr@ietf.org; Fri, 13 Feb 2004 04:04:42 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1ArZEe-00024K-00 for mpowr@ietf.org; Fri, 13 Feb 2004 04:03:44 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1D93kAh030868 for ; Fri, 13 Feb 2004 10:03:46 +0100 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Feb 2004 10:03:46 +0100 Received: from lmlinux01.lmera.ericsson.se ([150.132.83.141]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1VSH8D7R; Fri, 13 Feb 2004 10:03:57 +0100 From: David Partain Reply-To: david.partain@ericsson.com Organization: Ericsson To: mpowr@ietf.org Subject: Re: [mpowr] Re: Getting Bad Ideas to Fail Early Date: Fri, 13 Feb 2004 10:02:55 +0100 User-Agent: KMail/1.6 References: <20040120141958.C8D3577A6FA@guns.icir.org> <200401301538.06548.david.partain@ericsson.com> <035e01c3e782$7601a590$606015ac@dclkempt40> In-Reply-To: <035e01c3e782$7601a590$606015ac@dclkempt40> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402131002.55332.david.partain@ericsson.com> X-OriginalArrivalTime: 13 Feb 2004 09:03:46.0382 (UTC) FILETIME=[498C0EE0:01C3F210] 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, Thanks for the comments, James. I've cut out previous conversations since this discussion seems to live on its own. On Friday 30 January 2004 22.57, James Kempf wrote: > I think we need to make a distinction between the IESG approving publishing > a document, as currently, and a change where an individual AD could approve > a document. I can see a process where, if the reviews come in good and the > WG agrees to make any proposed changes, an individual AD is allowed to > simply approve publication without requiring the entire IESG to review or > even to have to read the reviewers comments. This could save the IESG a lot > of work. This is certainly worth considering. As long as we can assure credible cross-area review and subsequent consensus with the working group, the streamlining effect of this might be a very good thing. It might be good in such a process if the IESG at least gets a heads up and 5 minute rundown on the document during the telechat before it goes through. If it raises any red flags at that point, the person who's concerned gets X days to look at and comment on the document or it just moves on. Maybe I'm endowing the IESG with too much wisdom, but it seems very important to me to have some entity with the Ultimate Sanity Check authority. > I can't see a case where the document gets approved automatically > without the AD's involvement. We agree. > I believe there will always be an element of > judgement in deciding whether the reviews were adequate, the WG's response > was appropriate, etc. that one would want to have a knowledgable human in > the loop for publication approval. Absolutely. Cheers, David -- Text after this signature is inserted automatically in accordance with Ericsson corporate policy. It's not my fault. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Feb 13 04:24:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29961 for ; Fri, 13 Feb 2004 04:24:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZYC-0000ki-8e for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 04:23:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D9NuZr002889 for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 04:23:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZYB-0000kW-M2 for mpowr-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 04:23: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 EAA29941 for ; Fri, 13 Feb 2004 04:23:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZY3-0003eS-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 04:23:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZX7-0003Yz-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 04:22:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArZWE-0003Tz-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 04:21:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZWL-0000Tt-NQ; Fri, 13 Feb 2004 04:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZWK-0000TM-0k for mpowr@optimus.ietf.org; Fri, 13 Feb 2004 04:22: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 EAA29879 for ; Fri, 13 Feb 2004 04:21:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZWB-0003TL-00 for mpowr@ietf.org; Fri, 13 Feb 2004 04:21:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZVF-0003Oq-00 for mpowr@ietf.org; Fri, 13 Feb 2004 04:20:54 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1ArZUv-0003K5-00 for mpowr@ietf.org; Fri, 13 Feb 2004 04:20:33 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1D9KaAh003293 for ; Fri, 13 Feb 2004 10:20:36 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Feb 2004 10:20:36 +0100 Received: from lmlinux01.lmera.ericsson.se ([150.132.83.141]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJRHV1B; Fri, 13 Feb 2004 10:20:35 +0100 From: David Partain Reply-To: david.partain@ericsson.com Organization: Ericsson To: mpowr@ietf.org Subject: Re: [mpowr] Re: Getting Bad Ideas to Fail Early Date: Fri, 13 Feb 2004 10:19:44 +0100 User-Agent: KMail/1.6 References: <2480163516.1076368370@localhost> <136684602.1076415217@scan.jck.com> In-Reply-To: <136684602.1076415217@scan.jck.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402131019.44713.david.partain@ericsson.com> X-OriginalArrivalTime: 13 Feb 2004 09:20:36.0061 (UTC) FILETIME=[A35CD8D0:01C3F212] 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Good day, This feels really ICAR-ish. I hate to just move it, though, for fear of losing participants. Maybe the thread'll end now, though. > On Monday, 09 February, 2004 23:12 -0800 Harald Tveit Alvestrand wrote: > > that would be no change ... the IESG document evaluation > > process is currently highly interrupt driven - the interrupt > > is the other ADs putting documents on the agenda..... Let's just say that I don't envy them their task. On Tuesday 10 February 2004 18.13, John C Klensin wrote: > Different answer, complementary to Harald's. If the AD > responsible for a particular WG concludes that the WG is > promoting "bad" ideas and can't get unstuck from them, has a > very wide range of mechanisms available for focusing the WG's > attention. And rightly so. > We can discuss how these should be exercised, what > degree of consultation should be required and with whom, etc., > but the basic mechanisms remain. They include: > > * Additional, forceful, explanations of why the idea is > bad and isn't going anywhere. ("reading of the riot act" > is probably a member of this category) > > * Replacing WG Chairs > > * Rechartering the WG to eliminate the task(s) that the > WG doesn't want to get right. > > * Closing the WG entirely. Yes, I understand and those are all rational ways to deal with eventual problems. Perhaps ICAR can provide additional input to allow these things to happen (when needed) more speedily. Cheers, David -- Text after this signature is inserted automatically in accordance with Ericsson corporate policy. It's not my fault. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Feb 13 04:37:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00379 for ; Fri, 13 Feb 2004 04:37:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZkn-0001KS-Ot for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 04:36:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D9auTT005087 for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 04:36:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZkk-0001Jy-6f for mpowr-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 04:36:54 -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 EAA00362 for ; Fri, 13 Feb 2004 04:36:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZkb-0004f2-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 04:36:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZjh-0004b5-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 04:35:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArZip-0004XA-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 04:34:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZix-0001H9-5x; Fri, 13 Feb 2004 04:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZiq-0001GZ-3v for mpowr@optimus.ietf.org; Fri, 13 Feb 2004 04:34:56 -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 EAA00310 for ; Fri, 13 Feb 2004 04:34:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZih-0004W4-00 for mpowr@ietf.org; Fri, 13 Feb 2004 04:34:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZhm-0004Rp-00 for mpowr@ietf.org; Fri, 13 Feb 2004 04:33:51 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ArZhJ-0004Ni-00 for mpowr@ietf.org; Fri, 13 Feb 2004 04:33:21 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1D9XOqY007285 for ; Fri, 13 Feb 2004 10:33:24 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Feb 2004 10:33:24 +0100 Received: from lmlinux01.lmera.ericsson.se ([150.132.83.141]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1VSH8N5Y; Fri, 13 Feb 2004 10:33:35 +0100 From: David Partain Reply-To: david.partain@ericsson.com Organization: Ericsson To: mpowr@ietf.org Subject: Re: [mpowr] Re: Getting Bad Ideas to Fail Early Date: Fri, 13 Feb 2004 10:32:33 +0100 User-Agent: KMail/1.6 References: <20040202044407.6E5AA77AA09@guns.icir.org> In-Reply-To: <20040202044407.6E5AA77AA09@guns.icir.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402131032.33160.david.partain@ericsson.com> X-OriginalArrivalTime: 13 Feb 2004 09:33:24.0484 (UTC) FILETIME=[6D60E440:01C3F214] 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Mark, thank for the summary of your view, with which I agree. On Monday 02 February 2004 05.44, Mark Allman wrote: > Thanks for the note! I think we are agreeing more than we > are not. Actually, I think we're in agreement. > I think that any sort of early review mechanism > needs to be a "first class" IETF citizen. It must explicitly > have the respect and backing of the IESG. Absolutely. > That's not to say > that the IESG will always agree with every review produced > by some early review entity (whatever that might look like). Put two engineers in two different rooms with the same problem to solve and you're likely to get two pretty different solutions :-) > But, the IESG has to buy into the early review process in a > way that everyone knows that the reviews do, in fact, carry > some weight and that they are to be taken seriously by WGs and > WG chairs. And, the expectation should be that issues raised > during such reviews should be dealt with before documents > are forwarded to the IESG. (And, of course, if the WG / WG > chair is having a problem working through these issues the > IESG should be willing to help manage that process. But, > that is no different from the current system.) This looks great to me. Please don't mistake my voicing of concerns as disagreement. I believe _strongly_ in the IETF concensus process and will oppose any attempts to undermine that fundamental philosophy of cooperation. It's just important to me that we understand how fragile that is and do whatever we can to preserve it. > That said, I do not think that we need to assign any special > "authority" to these reviews. For instance, I don't think such > reviews would be more or less important than a high quality > review received by a random person who read an i-d and decided > to send some comment on it. All issues raised should be dealt > with by the WG using due diligence. The major change I see > is in the more explcit gathering of reviews from different > perspectives - not in any special status they might have. Good. This is entirely in line with the way I think things should work. Is there a way we can collectively say "Ship it!" at this point? :-) Cheers, David -- Text after this signature is inserted automatically in accordance with Ericsson corporate policy. It's not my fault. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Feb 13 04:41:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00489 for ; Fri, 13 Feb 2004 04:41:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZog-0001iZ-7g for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 04:40:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D9eufL006590 for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 04:40:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZod-0001iB-Rv for mpowr-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 04:40: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 EAA00472 for ; Fri, 13 Feb 2004 04:40:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZoV-0004x0-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 04:40:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZnc-0004t0-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 04:39:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArZme-0004ot-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 04:38:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZmm-0001Yc-1L; Fri, 13 Feb 2004 04:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZmi-0001Xx-EY for mpowr@optimus.ietf.org; Fri, 13 Feb 2004 04:38:56 -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 EAA00417 for ; Fri, 13 Feb 2004 04:38:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZmZ-0004o0-00 for mpowr@ietf.org; Fri, 13 Feb 2004 04:38:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZlc-0004jp-00 for mpowr@ietf.org; Fri, 13 Feb 2004 04:37:48 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ArZl5-0004g3-00 for mpowr@ietf.org; Fri, 13 Feb 2004 04:37:16 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1D9bJqY008512 for ; Fri, 13 Feb 2004 10:37:19 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Feb 2004 10:37:18 +0100 Received: from lmlinux01.lmera.ericsson.se ([150.132.83.141]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1LJHHGQ2; Fri, 13 Feb 2004 10:38:21 +0100 From: David Partain Reply-To: david.partain@ericsson.com Organization: Ericsson To: mpowr@ietf.org Subject: Re: [mpowr] Re: Getting Bad Ideas to Fail Early Date: Fri, 13 Feb 2004 10:36:27 +0100 User-Agent: KMail/1.6 References: <20040202044407.6E5AA77AA09@guns.icir.org> <00a301c3eec3$11868d90$0400a8c0@DFNJGL21> In-Reply-To: <00a301c3eec3$11868d90$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402131036.27845.david.partain@ericsson.com> X-OriginalArrivalTime: 13 Feb 2004 09:37:18.0996 (UTC) FILETIME=[F9289540:01C3F214] 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, On Monday 09 February 2004 05.13, Spencer Dawkins wrote: > Are we still talking about mechanisms to identify early reviewers? I > think such a mechanism is a significant, and important, change. Now that _is_ an ICAR discussion. Perhaps we could ask the same question there? :-) David -- Text after this signature is inserted automatically in accordance with Ericsson corporate policy. It's not my fault. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Feb 13 08:45:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09100 for ; Fri, 13 Feb 2004 08:45:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ardcn-0005du-60 for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 08:44:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DDivii021686 for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 08:44:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ardcn-0005dh-1u for mpowr-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 08:44:57 -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 IAA09097 for ; Fri, 13 Feb 2004 08:44:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ardcl-0001Ft-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 08:44:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ardbq-0001CR-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 08:43:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ardav-00018N-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 08:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ardav-0005b4-B4; Fri, 13 Feb 2004 08:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arda4-0005ZR-La for mpowr@optimus.ietf.org; Fri, 13 Feb 2004 08:42:08 -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 IAA09004 for ; Fri, 13 Feb 2004 08:42:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arda3-00013e-00 for mpowr@ietf.org; Fri, 13 Feb 2004 08:42:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArdZM-0000yI-00 for mpowr@ietf.org; Fri, 13 Feb 2004 08:41:24 -0500 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1ArdYN-0000mq-00 for mpowr@ietf.org; Fri, 13 Feb 2004 08:40:23 -0500 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc12) with SMTP id <20040213133953012000ehr4e> (Authid: sdawkins@comcast.net); Fri, 13 Feb 2004 13:39:53 +0000 Message-ID: <00e401c3f236$e143ab50$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <20040120141958.C8D3577A6FA@guns.icir.org> <200401301538.06548.david.partain@ericsson.com> <035e01c3e782$7601a590$606015ac@dclkempt40> <200402131002.55332.david.partain@ericsson.com> Subject: Re: [mpowr] Re: Getting Bad Ideas to Fail Early Date: Fri, 13 Feb 2004 07:40:00 -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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 ... and this line of thought, which I happen to agree with, has a decent amount of overlap with something like a Working Group Snapshot (the concept, not the current proposals), being discussed on NEWTRK... Maybe the right number of ideas, but spread over too many mailing lists! I understand the desire for modularity, but modularity also required low coupling between modules. Spencer ----- Original Message ----- From: "David Partain" To: Sent: Friday, February 13, 2004 3:02 AM Subject: Re: [mpowr] Re: Getting Bad Ideas to Fail Early > Hi all, > > Thanks for the comments, James. I've cut out previous > conversations since this discussion seems to live on its own. > > On Friday 30 January 2004 22.57, James Kempf wrote: > > I think we need to make a distinction between the IESG approving publishing > > a document, as currently, and a change where an individual AD could approve > > a document. I can see a process where, if the reviews come in good and the > > WG agrees to make any proposed changes, an individual AD is allowed to > > simply approve publication without requiring the entire IESG to review or > > even to have to read the reviewers comments. This could save the IESG a lot > > of work. > > This is certainly worth considering. As long as we can assure > credible cross-area review and subsequent consensus with the > working group, the streamlining effect of this might be a > very good thing. It might be good in such a process if the > IESG at least gets a heads up and 5 minute rundown on the > document during the telechat before it goes through. If it > raises any red flags at that point, the person who's concerned > gets X days to look at and comment on the document or it just > moves on. Maybe I'm endowing the IESG with too much wisdom, > but it seems very important to me to have some entity with > the Ultimate Sanity Check authority. > > > I can't see a case where the document gets approved automatically > > without the AD's involvement. > > We agree. > > > I believe there will always be an element of > > judgement in deciding whether the reviews were adequate, the WG's response > > was appropriate, etc. that one would want to have a knowledgable human in > > the loop for publication approval. > > Absolutely. > > Cheers, > > David _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Feb 13 11:20:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17520 for ; Fri, 13 Feb 2004 11:20:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg2q-0000r2-VY for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 11:20:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGK0ns003278 for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 11:20:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg2q-0000qn-PJ for mpowr-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 11:20: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 LAA17482 for ; Fri, 13 Feb 2004 11:19:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arg2p-0006ui-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 11:19:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arg1r-0006pc-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 11:18:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arg0u-0006ke-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 11:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg0v-0000b8-1V; Fri, 13 Feb 2004 11:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg05-0000YV-5O for mpowr@optimus.ietf.org; Fri, 13 Feb 2004 11:17:09 -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 LAA17377 for ; Fri, 13 Feb 2004 11:17:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arg04-0006fj-00 for mpowr@ietf.org; Fri, 13 Feb 2004 11:17:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfzT-0006Zm-00 for mpowr@ietf.org; Fri, 13 Feb 2004 11:16:32 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1ArfxL-0006MQ-00 for mpowr@ietf.org; Fri, 13 Feb 2004 11:14:19 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C9D4A61BFA; Fri, 13 Feb 2004 17:13:46 +0100 (CET) Date: Fri, 13 Feb 2004 08:11:00 -0800 From: Harald Tveit Alvestrand To: solutions@alvestrand.no, mpowr@ietf.org Message-ID: <261249637.1076659860@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 Subject: [mpowr] General Area meeting in Seoul 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 folks, given the topics that's been discussed on the MPOWR and Solutions mailing lists, I've decided to ask for a General Area meeting in Seoul, so that we can talk about: - the overall shape of the "change" effort for IETF process - the specific proposals that are either larger or smaller than what a working group seems appropriate for This replaces the originally planned MPOWR BOF - NEWTRK and ICAR are specific enough, and far enough along, that they will have their own meetings. I'll send out the proposed agenda shortly (to MPOWR and Solutions) - I suggest that we use the Solutions mailing list as the main list for discussing the Gen-Area agenda. Harald _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Feb 13 11:26:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17737 for ; Fri, 13 Feb 2004 11:26:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg8g-0001Cd-GY for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 11:26:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGQ2pM004617 for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 11:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg8g-0001CM-Cf for mpowr-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 11:26:02 -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 LAA17704 for ; Fri, 13 Feb 2004 11:25:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arg8f-0007ME-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 11:26:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arg7g-0007Hn-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 11:25:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arg6i-0007Dl-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 11:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg6j-00016n-12; Fri, 13 Feb 2004 11:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg5q-00014V-83 for mpowr@optimus.ietf.org; Fri, 13 Feb 2004 11:23:06 -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 LAA17629 for ; Fri, 13 Feb 2004 11:23:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arg5p-00079u-00 for mpowr@ietf.org; Fri, 13 Feb 2004 11:23:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arg4v-00076C-00 for mpowr@ietf.org; Fri, 13 Feb 2004 11:22:09 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1Arg4M-00071x-00 for mpowr@ietf.org; Fri, 13 Feb 2004 11:21:34 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1DGHm2B007786 for ; Fri, 13 Feb 2004 11:17:48 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1DGHa2B007507 for ; Fri, 13 Feb 2004 11:17:47 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 13 Feb 2004 18:21:12 +0200 Message-ID: Thread-Topic: [Solutions] General Area meeting in Seoul Thread-Index: AcPyTPMrlNoKkfWBRRWzOAilXFfK5AAADfkw From: "Romascanu, Dan (Dan)" To: "Harald Tveit Alvestrand" , , Content-Transfer-Encoding: quoted-printable Subject: [mpowr] RE: [Solutions] General Area meeting in Seoul 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Harald, Taking into account the level of general interest that this discussion = may arise, would not a plenary be a better scheduling spot, rather than = a WG meeting spot, in conflict with other WG meetings? Regards, Dan > -----Original Message----- > From: solutions-bounces@alvestrand.no=20 > [mailto:solutions-bounces@alvestrand.no]On Behalf Of Harald=20 > Tveit Alvestrand > Sent: 13 February, 2004 6:11 PM > To: solutions@alvestrand.no; mpowr@ietf.org > Subject: [Solutions] General Area meeting in Seoul >=20 >=20 > Hi folks, >=20 > given the topics that's been discussed on the MPOWR and=20 > Solutions mailing=20 > lists, I've decided to ask for a General Area meeting in=20 > Seoul, so that we=20 > can talk about: >=20 > - the overall shape of the "change" effort for IETF process > - the specific proposals that are either larger or smaller=20 > than what a=20 > working group seems appropriate for >=20 > This replaces the originally planned MPOWR BOF - NEWTRK and ICAR are=20 > specific enough, and far enough along, that they will have their own=20 > meetings. >=20 > I'll send out the proposed agenda shortly (to MPOWR and=20 > Solutions) - I=20 > suggest that we use the Solutions mailing list as the main list for=20 > discussing the Gen-Area agenda. >=20 > Harald >=20 > _______________________________________________ > Solutions mailing list > Solutions@alvestrand.no > http://eikenes.alvestrand.no/mailman/listinfo/solutions >=20 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Feb 13 12:37:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22083 for ; Fri, 13 Feb 2004 12:37:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhFU-000831-H4 for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 12:37:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DHb8V8030929 for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 12:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhFT-00082e-Oy for mpowr-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 12:37:07 -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 MAA22066 for ; Fri, 13 Feb 2004 12:37:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArhFS-0007CC-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 12:37:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArhET-00076U-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 12:36:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArhDT-0006zz-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 12:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhDT-0007k4-Kh; Fri, 13 Feb 2004 12:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhCd-0007Yu-Kl for mpowr@optimus.ietf.org; Fri, 13 Feb 2004 12:34:11 -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 MAA21856 for ; Fri, 13 Feb 2004 12:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArhCc-0006uj-00 for mpowr@ietf.org; Fri, 13 Feb 2004 12:34:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArhBj-0006pB-00 for mpowr@ietf.org; Fri, 13 Feb 2004 12:33:15 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1ArhAx-0006f2-00 for mpowr@ietf.org; Fri, 13 Feb 2004 12:32:27 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8232D61B9A; Fri, 13 Feb 2004 18:31:55 +0100 (CET) Date: Fri, 13 Feb 2004 09:22:17 -0800 From: Harald Tveit Alvestrand To: "Romascanu, Dan (Dan)" , solutions@alvestrand.no, mpowr@ietf.org Message-ID: <265526627.1076664137@localhost> In-Reply-To: References: 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 Subject: [mpowr] RE: [Solutions] General Area meeting in Seoul 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 13. februar 2004 18:21 +0200 "Romascanu, Dan (Dan)" wrote: > Harald, > > Taking into account the level of general interest that this discussion > may arise, would not a plenary be a better scheduling spot, rather than a > WG meeting spot, in conflict with other WG meetings? When I compared the insight gathered from the discussion at the plenary with the insight gathered from the discussion at the NEWTRK BOF in Minneapolis, I came to the opposite conclusion. YMMV - but I think a smaller forum may be beneficial to getting focused discussion on the issues. They will all go back to the mailing lists, I-D publication process and Last Call mechanisms, of course. Harald _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Feb 13 13:52:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25115 for ; Fri, 13 Feb 2004 13:52:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriQ7-0006Na-5a for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 13:52:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DIqBLY024516 for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 13:52:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriQ7-0006NL-0S for mpowr-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 13:52:11 -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 NAA25107 for ; Fri, 13 Feb 2004 13:52:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AriQ4-0005Um-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 13:52:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AriPC-0005Ra-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 13:51:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AriOx-0005Nd-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 13:50:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriOy-0006Kj-Sb; Fri, 13 Feb 2004 13:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriOB-0006Jj-4D for mpowr@optimus.ietf.org; Fri, 13 Feb 2004 13:50:11 -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 NAA25047 for ; Fri, 13 Feb 2004 13:50:08 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AriO8-0005M4-00 for mpowr@ietf.org; Fri, 13 Feb 2004 13:50:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AriNB-0005I4-00 for mpowr@ietf.org; Fri, 13 Feb 2004 13:49:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AriMS-0005EZ-00 for mpowr@ietf.org; Fri, 13 Feb 2004 13:48:24 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1DImNv10368 for ; Fri, 13 Feb 2004 20:48:23 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Feb 2004 20:48:23 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 20:48:21 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 20:48:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Feb 2004 20:48:20 +0200 Message-ID: Thread-Topic: [Solutions] General Area meeting in Seoul Thread-Index: AcPyTG+GbtCFGJMVRreDB8JWIWfPgAAFS3xg To: , , X-OriginalArrivalTime: 13 Feb 2004 18:48:22.0641 (UTC) FILETIME=[F4A06E10:01C3F261] Content-Transfer-Encoding: quoted-printable Subject: [mpowr] RE: [Solutions] General Area meeting in Seoul 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Harald, I think this is a good solution. Working Group meetings are a place to do some work, plenaries are places to report what has happened. Perhaps if the General Area Meeting is before the Plenary, you could summarize what happened at the meeting. At this point, we need to focus on getting work done. thanks, John > Hi folks, >=20 > given the topics that's been discussed on the MPOWR and Solutions = mailing=20 > lists, I've decided to ask for a General Area meeting in Seoul, so = that we=20 > can talk about: >=20 > - the overall shape of the "change" effort for IETF process > - the specific proposals that are either larger or smaller than what a = > working group seems appropriate for >=20 > This replaces the originally planned MPOWR BOF - NEWTRK and ICAR are=20 > specific enough, and far enough along, that they will have their own=20 > meetings. >=20 > I'll send out the proposed agenda shortly (to MPOWR and Solutions) - I = > suggest that we use the Solutions mailing list as the main list for=20 > discussing the Gen-Area agenda. >=20 > Harald >=20 > _______________________________________________ > Solutions mailing list > Solutions@alvestrand.no > http://eikenes.alvestrand.no/mailman/listinfo/solutions >=20 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Feb 13 19:39:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17115 for ; Fri, 13 Feb 2004 19:39:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArnqE-00024j-GN for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 19:39:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1E0dUH4007973 for mpowr-archive@odin.ietf.org; Fri, 13 Feb 2004 19:39:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArnqE-00024W-C1 for mpowr-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 19:39:30 -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 TAA17072 for ; Fri, 13 Feb 2004 19:39:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArnqC-0005fw-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 19:39:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArnpC-0005bE-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 19:38:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arnol-0005Ww-00 for mpowr-web-archive@ietf.org; Fri, 13 Feb 2004 19:37:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arnom-0001qK-38; Fri, 13 Feb 2004 19:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arno7-0001aU-AV for mpowr@optimus.ietf.org; Fri, 13 Feb 2004 19:37:19 -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 TAA17008 for ; Fri, 13 Feb 2004 19:37:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arno5-0005Vx-00 for mpowr@ietf.org; Fri, 13 Feb 2004 19:37:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arnn8-0005Sl-00 for mpowr@ietf.org; Fri, 13 Feb 2004 19:36:18 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1Arnmn-0005Ph-00 for mpowr@ietf.org; Fri, 13 Feb 2004 19:35:57 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 91D6161B9A for ; Sat, 14 Feb 2004 01:35:26 +0100 (CET) Date: Fri, 13 Feb 2004 16:34:36 -0800 From: Harald Tveit Alvestrand To: mpowr@ietf.org Message-ID: <291464714.1076690076@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 Subject: [mpowr] Proposed agenda for a GEN Area meeting 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 A General Area meeting has been scheduled in Seoul; we are not planning to schedule an MPOWR BOF. At the moment, it's the 1930-2200 slot on Monday evening. A proposed agenda is below, and will be discussed further on the solutions@alvestrand.no mailing list. Comments welcome! Harald Proposed agenda for the GEN-AREA meeting in Seoul Chair: Harald Alvestrand, GEN AD Purpose of meeting: - Go through the "high level picture" of where the problems in the IETF are, and what is being done to address them - Look at specific proposals that do not have WG meetings to look at them, and provide a quick "thumbs up/thumbs down" feedback indication, which can serve as feedback to the proposers and a hint to the IESG on how to handle the proposals. Agenda: 00:00 Welcome, scribe and agenda bashing 00:10 Overview - Harald Alvestrand See http://www.ietf.org/u/ietfchair/change-status.html See also ICAR, NEWTRK charters; PROTO charter; EDU charter and website 00:25 Notes from specific non-WG/non-BOF efforts - PROTO team: working to make tools better for WG chair followup work - EDU team: working to make sure IETF participants know as much as possible on how to be effective - MPOWR discussions: What the mailing list discussions have led to 00:55 Specific proposals - "thumbs-up" / "thumbs-down" Rules of the game / intro - Harald (5 min) 01:00 Mailing list procedure change - Margaret Wasserman draft-wasserman-rfc2418-ml-update-00.txt (10 min) 01:10 Procedures for changing procedures - John Klensin Documents: draft-klensin-process-july14-00 ("Trust the IESG") draft-klensin-process-planb-00 ("Distrust the IESG") 01:40 Discussing the overall problem: Does this distribution of tasks (small changes, individual proposals, PROTO team, EDU team, ICAR, NEWTRK) make sense? What is NOT within the list of things being worked on? How does it need to be done? 02:00 Wrap up and conclude _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 14 11:20:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22688 for ; Sat, 14 Feb 2004 11:20:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2WA-0008Qz-UF for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 11:19:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EGJkwK032421 for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 11:19:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2WA-0008Qq-KQ for mpowr-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 11:19:46 -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 LAA22685 for ; Sat, 14 Feb 2004 11:19:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2W9-00071Q-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 11:19:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2VB-0006wa-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 11:18:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As2UU-0006t9-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 11:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2UT-0008MM-0K; Sat, 14 Feb 2004 11:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2Tv-0008M7-8m for mpowr@optimus.ietf.org; Sat, 14 Feb 2004 11:17:31 -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 LAA22644 for ; Sat, 14 Feb 2004 11:17:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2Tn-0006pe-00 for mpowr@ietf.org; Sat, 14 Feb 2004 11:17:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2RN-0006kL-00 for mpowr@ietf.org; Sat, 14 Feb 2004 11:14:49 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1As2Qs-0006gz-00 for mpowr@ietf.org; Sat, 14 Feb 2004 11:14:18 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1EGMEd10510 for ; Sat, 14 Feb 2004 08:22:14 -0800 Date: Sat, 14 Feb 2004 08:13:41 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1943493383.20040214081341@brandenburg.com> To: mpowr@ietf.org In-Reply-To: <327742548.1076153200@scan.jck.com> References: <327742548.1076153200@scan.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpowr] WG Formation 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.6 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (many thanks to bernard for creating this line of discussion and John for focusing on the startup issue.) JCK> ... A decade ago, a BOF JCK> (much less a couple of BOFs) were not requirements for creating JCK> a WG. In fact, a common requirement for authorizing a BOF was that there _already_ be an active mailing list. If the IETF still believes that the primary venue for work is the mailing list, then that is where the primary work of _formation_ needs to take place. I think that the desires for "give it a try and stop it if there is not sufficient progress" can be satisfied entirely by a simple structure that involves almost no extra IETF administrative or management effort. In fact it will require _less_ effort than needed today: 1. Anyone wanting to form a working group must first create a mailing list, and a web page that lists at least a mailing list and archive, and a candidate charter, 2. The mailing list must show enough history of activity to assess a pattern, specifically one of productive IETF-like discussion, for the charter and for the actual work. 3. The IETF should provide a "WG Formative Efforts" page and list any and all efforts that satisfy step 1. 4. A BOF can be authorized after #2 is satisfied. This gives efforts some visibility and allows them whatever startup thrashing they need. When they get past that stage and start doing productive, IETF types of work, they can be treated as a serious candidate for IETF oversight. I think that "relaxed chartering" has the very serious problem of creating lots of management pain, for little or no gain. It is too easy to do the pre-IETF work in a pre-IETF environment. Forcing IETF management to be involved -- especially with killing unproductive efforts -- is pretty much a lose-lose structure. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 14 11:44:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23431 for ; Sat, 14 Feb 2004 11:44:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2tU-0001h6-3W for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 11:43:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EGhqWE006506 for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 11:43:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2tT-0001gr-UU for mpowr-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 11:43: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 LAA23411 for ; Sat, 14 Feb 2004 11:43:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2tS-0000lo-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 11:43:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2sX-0000il-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 11:42:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As2rg-0000fW-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 11:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2rh-0001dQ-45; Sat, 14 Feb 2004 11:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2rT-0001cz-Hx for mpowr@optimus.ietf.org; Sat, 14 Feb 2004 11:41:47 -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 LAA23368 for ; Sat, 14 Feb 2004 11:41:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2rS-0000e9-00 for mpowr@ietf.org; Sat, 14 Feb 2004 11:41:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2qT-0000aZ-00 for mpowr@ietf.org; Sat, 14 Feb 2004 11:40:46 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1As2pW-0000XB-00 for mpowr@ietf.org; Sat, 14 Feb 2004 11:39:47 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1As2pW-0005n0-00; Sat, 14 Feb 2004 11:39:46 -0500 Date: Sat, 14 Feb 2004 11:39:46 -0500 From: John C Klensin To: Dave Crocker , mpowr@ietf.org Subject: Re: [mpowr] WG Formation Message-ID: <38529151.1076758786@scan.jck.com> In-Reply-To: <1943493383.20040214081341@brandenburg.com> References: <327742548.1076153200@scan.jck.com> <1943493383.20040214081341@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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Dave, I think your proposal and mine are largely compatible. Let me try to explain that... I think there should be a number of different ways of getting to a WG and that _any_ model through which all pre-WGs and WGs must go is an invitation to getting ourselves bogged down in procedural nonsense and rigidity rather than keeping the focus on getting the job done. So, e.g., any of the following ought to be considered reasonable, depending on circumstances, AD/ IESG/ community perspective, etc... * As you suggest, demonstrate, by action and drafts, that there is work which is ready to be turned into a WG, with or without a BOF or two, depending on what is and is not demonstrated. * Hold a BOF or two and demonstrate that things have crystallized that way (I note that we used to have a fairly rigid "two BOFs and no more" rule, but that, now, we seem to be able to have two or three BOFs, a change of name and microscopic change of focus, a few more BOFs,... and that cannot often be a good sign). * Spin up an RG which eventually makes a WG recommendation. * Charter a group on a "short leash" basis as my comments suggested. That isn't an exclusive list -- I imagine that there might be a half-dozen other options that would make sense occasionally -- and some of the above might be combined. For example, no matter how a WG gets started, I would hope for significant AD oversight in the first six months or a year with rapid plug-pulling if it heads resolutely off into the weeds (on Valentine's Day, I am somehow drawn to analogies to couples who have really good relationships until they get married, then start having serious trouble almost immediately). For me, the observation that some ADs have started using BOFs as a way to getting the community to shoot down a WG proposal, rather than doing it themselves, is a symptom of another problem. But the solution isn't obviously to replace a BOF-rigidity with some other rigidity. And there are certainly groups who could have, and did, managed to organize pre-WG (and even pre-BOF) mailing list discussions, documents, etc., which ended up not working out well as WGs. In these troubled times, there is also two risks inherent in lots of pre-BOF work: (i) if a small, semi-private, group holds a lot of discussions and formulates a position, any IETF review, even if it occurs the day after chartering, is likely to be "late" review in terms of its interactions with already-hardened positions. (ii) And such discussions may not be subject to IETF IPR provisions which could lead to some interesting ways to plant time bombs. We could protect against some of that by being aggressive about the "formative efforts" listing you suggest, but such a listing would be taken by many groups (and their publicists) as IETF endorsement of, and commitment to, their efforts. So, while I think the model you suggest would be a very useful tool (and, as you say, we more or less used to do it that way), there are unfriendly dragons by the sides of the path and we need to be aware of them. In no case do I think we can afford to get ourselves into a "if you manage to jump through the following hoops, you are entitled to have a WG, and, if the WG jumps through the following additional hoops, it is entitled to get a standard approved". More flexibility about creation, evaluation, and termination would seem to help us avoid even the impression of that situation. regards, john --On Saturday, 14 February, 2004 08:13 -0800 Dave Crocker wrote: > (many thanks to bernard for creating this line of discussion > and John for focusing on the startup issue.) > > > JCK> ... A decade ago, a BOF > JCK> (much less a couple of BOFs) were not requirements for > creating JCK> a WG. > > In fact, a common requirement for authorizing a BOF was that > there _already_ be an active mailing list. If the IETF still > believes that the primary venue for work is the mailing list, > then that is where the primary work of _formation_ needs to > take place. > > I think that the desires for "give it a try and stop it if > there is not sufficient progress" can be satisfied entirely by > a simple structure that involves almost no extra IETF > administrative or management effort. In fact it will require > _less_ effort than needed today: > > > 1. Anyone wanting to form a working group must first > create a mailing list, and a web page that lists at least > a mailing list and archive, and a candidate charter, > > 2. The mailing list must show enough history of activity > to assess a pattern, specifically one of productive > IETF-like discussion, for the charter and for the actual > work. > > 3. The IETF should provide a "WG Formative Efforts" page > and list any and all efforts that satisfy step 1. > > 4. A BOF can be authorized after #2 is satisfied. > > This gives efforts some visibility and allows them whatever > startup thrashing they need. When they get past that stage and > start doing productive, IETF types of work, they can be > treated as a serious candidate for IETF oversight. > > I think that "relaxed chartering" has the very serious problem > of creating lots of management pain, for little or no gain. > It is too easy to do the pre-IETF work in a pre-IETF > environment. Forcing IETF management to be involved -- > especially with killing unproductive efforts -- is pretty much > a lose-lose structure. > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > > > _______________________________________________ > mpowr mailing list > mpowr@ietf.org > https://www1.ietf.org/mailman/listinfo/mpowr _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 14 11:45:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23486 for ; Sat, 14 Feb 2004 11:45:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2uP-0001lQ-I8 for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 11:44:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EGineu006774 for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 11:44:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2uP-0001lB-EH for mpowr-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 11:44:49 -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 LAA23455 for ; Sat, 14 Feb 2004 11:44:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2uO-0000ph-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 11:44:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2tT-0000m2-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 11:43:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As2se-0000it-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 11:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2se-0001f5-My; Sat, 14 Feb 2004 11:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As2sT-0001ec-41 for mpowr@optimus.ietf.org; Sat, 14 Feb 2004 11:42:49 -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 LAA23390 for ; Sat, 14 Feb 2004 11:42:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As2sS-0000hr-00 for mpowr@ietf.org; Sat, 14 Feb 2004 11:42:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As2rY-0000ey-00 for mpowr@ietf.org; Sat, 14 Feb 2004 11:41:52 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1As2qg-0000YR-00 for mpowr@ietf.org; Sat, 14 Feb 2004 11:40:58 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1EGeOD15817 for ; Sat, 14 Feb 2004 10:40:25 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <16989BJQ>; Sat, 14 Feb 2004 17:40:23 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC61A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Dave Crocker'" , mpowr@ietf.org Subject: RE: [mpowr] WG Formation Date: Sat, 14 Feb 2004 17:40:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Inline > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: zaterdag 14 februari 2004 17:14 > To: mpowr@ietf.org > Subject: [mpowr] WG Formation > > > (many thanks to bernard for creating this line of discussion > and John for > focusing on the startup issue.) > > > JCK> ... A decade ago, a BOF > JCK> (much less a couple of BOFs) were not requirements for creating > JCK> a WG. > > In fact, a common requirement for authorizing a BOF was that there > _already_ be an active mailing list. If the IETF still believes that > the primary venue for work is the mailing list, then that is where the > primary work of _formation_ needs to take place. > > I think that the desires for "give it a try and stop it if there is not > sufficient progress" can be satisfied entirely by a simple structure > that involves almost no extra IETF administrative or management effort. > In fact it will require _less_ effort than needed today: > > > 1. Anyone wanting to form a working group must first create a > mailing list, and a web page that lists at least a mailing list and > archive, and a candidate charter, > > 2. The mailing list must show enough history of activity to assess > a pattern, specifically one of productive IETF-like discussion, for > the charter and for the actual work. > Interestingly, those two questions and actions is what many (if not all) ADs ask and want to see before approving a BOF. Some people do not like that... but... such is life. So it seems we are doing the right thing? > 3. The IETF should provide a "WG Formative Efforts" page and list > any and all efforts that satisfy step 1. > That would indeed be a nice thing. > 4. A BOF can be authorized after #2 is satisfied. > Agreed! And that is how I work when people ask me to approve a BOF Bert _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 14 12:53:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25141 for ; Sat, 14 Feb 2004 12:53:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3yI-0006Xd-MC for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 12:52:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EHqs5q025139 for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 12:52:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3yI-0006XO-HS for mpowr-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 12:52:54 -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 MAA25109 for ; Sat, 14 Feb 2004 12:52:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3yG-00056k-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 12:52:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3xJ-00050d-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 12:51:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As3wS-0004xU-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 12:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3wT-0006Q6-HV; Sat, 14 Feb 2004 12:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3wN-0006Pe-4h for mpowr@optimus.ietf.org; Sat, 14 Feb 2004 12:50: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 MAA25070 for ; Sat, 14 Feb 2004 12:50:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3wL-0004wr-00 for mpowr@ietf.org; Sat, 14 Feb 2004 12:50:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3vM-0004tu-00 for mpowr@ietf.org; Sat, 14 Feb 2004 12:49:54 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1As3uu-0004ql-00 for mpowr@ietf.org; Sat, 14 Feb 2004 12:49:24 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1EHvKd14356 for ; Sat, 14 Feb 2004 09:57:20 -0800 Date: Sat, 14 Feb 2004 09:48:46 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <14410174609.20040214094846@brandenburg.com> To: mpowr@ietf.org Subject: Re: [mpowr] WG Formation In-Reply-To: <38529151.1076758786@scan.jck.com> References: <327742548.1076153200@scan.jck.com> <1943493383.20040214081341@brandenburg.com> <38529151.1076758786@scan.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.6 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable JCK> I think your proposal and mine are largely compatible. oh, you optimist, you... JCK> I think there should be a number of different ways of getting to JCK> a WG and that _any_ model through which all pre-WGs and WGs must=20 JCK> go is an invitation to getting ourselves bogged down in=20 JCK> procedural nonsense and rigidity rather than keeping the focus=20 JCK> on getting the job done. I think we have a meaningful difference, here. By their nature, rules are Procrustean. Hence, rules should be created only when the tradeoffs among flexibility, efficiency, quality and the like all warrant it. In this case, I think we have a very serious problem with wasteful formation of unproductive working groups. So, the rule is a very straightforward way of moving the cost of wastefulness to be outside of IETF concern. It creates a simple and entirely relevant admission criterion: To get chartered for doing IETF work, a group much demonstrate that it is already _able_ to do IETF work. Of the alternatives you list, some are in fact not so good. For example, an IRTF activity may or may not be productive as an IETF effort, so I'm not inclined to use the IRTF history as an automatic ticket to working group status. Some IRTF efforts do show the necessary qualities, but others do not. Dealing with this is simple: subject it to the same requirements as all other efforts. For a good effort, the previous IRTF effort will make satisfying the criteria I list trivial. JCK> That isn't an exclusive list -- I imagine that there might be a JCK> half-dozen other options that would make sense occasionally -- Fuzzy procedures and criteria invite sloppy, wasteful action. Since this is what we have been seeing regularly, in working group formation, we need to make sure that an effort to fix the problem really does fix it. We should only make rules that respond to a demonstrated need, but the rules should be as simple and clear and precise as we can make them. As Bert notes, in reality I'm only documenting an established good practise. The problem has been not enough adherence to it. And let's be clear about the 'rigidity' that I am proposing. Note that the actual assessment of productivity is unspecified. _That_ is where it makes sense to use the typically fuzzy rough-consensus approach, not in the basic procedure. JCK> In these troubled times, there is also two risks inherent in JCK> lots of pre-BOF work: (i) if a small, semi-private, group holds=20 JCK> a lot of discussions and formulates a position, any IETF review,=20 JCK> even if it occurs the day after chartering, is likely to be=20 JCK> "late" review in terms of its interactions with already-hardened First of all, the requirement I offered for pre-IETF work is that it be conducted in an IETF manner. This means open and flexible, as well as productive. Second of all, we already have that issue in many situations, which means we already have ways of dealing the problem you list. So, either a group that wishes IETF assistance and imprimateur is willing to conduct itself according to IETF requirements, or it isn't. JCK> positions. (ii) And such discussions may not be subject to IETF=20 JCK> IPR provisions which could lead to some interesting ways to=20 JCK> plant time bombs. We are stuck with that reality, no matter what. JCK> We could protect against some of that by=20 JCK> being aggressive about the "formative efforts" listing you=20 JCK> suggest, but such a listing would be taken by many groups (and=20 JCK> their publicists) as IETF endorsement of John, perhaps you have noticed that _any_ action is subject to political exploitation. The only way to avoid such exploitation is to be invisible and inactive. We simply cannot let fear of external stupidity and abuse dominate our thinking and working. If we think something is reasonable and productive, in its own right, then it is what we should do. If others choose to be stupid or nasty or exploitive about it, that is their problem and the problem of anyone who believes them. JCK> In no case do I think we can afford to get ourselves into a "if JCK> you manage to jump through the following hoops, you are entitled=20 JCK> to have a WG, I agree completely. My suggestion was for steps that should be necessary. But, no, they are not sufficient by themselves. They are designed to provide highly relevant input to the formation decision process, not to replace that process. and now for something completely different... WBB> Interestingly, those two questions and actions is what many (if not al= l) ADs WBB> ask and want to see before approving a BOF. Some people do not like th= at... WBB> but... such is life. WBB> So it seems we are doing the right thing? Bert, Your note triggers two lines of reaction from me: 1. Established Practise If the IESG were typically imposing the requirements I listed, then we would not be experiencing wasteful BOFs and wasteful working group startup "thrashing". Since we do, in fact, _frequently_ experience both of these problems, then no, it is not what all (or possibly even most) ADs do. Some do, yes. In fact, my intent was merely to document and require practise that I have viewed as long-used and effective. The problem has been with its inconsistent application. 2. Response from an AD Since I have not yet done IETF work that interacted with you, I am intrigued by your note. My lack of first-person experience with you is tempered by extremely consistent comments from others that you are an excellent AD. From=20what I can determine, you in particular have nothing to be defensive about. Yet I take your note frankly to be defensive. (I apologize for making this personal, but I do not know any other way to broach this specific topic and I think the topic of IESG participation in these discussions is absolutely fundamental to the question of making improvements in IETF timeliness and productivity. My own view is that John K's trust/distrust proposals go at exactly this issue. So my response, here, is really a plea: We must find a way to have IESG members engaged in these discussions without our attacking them and with their being candid with us. Defensive or hostile tone or content are simply not productive.) Clearly "we are doing the right thing" is not correct. "We" the IESG, and "We" the IETF, frequently are _not_ doing the right thing. "Some", yes. "All", no. In particular, "not enough". Not nearly enough. The IETF has established a very damaging pattern with working group formation, conduct and output. All three are highly problematic. Not every working group, of course. But enough to prompt the crisis that we have been trying to address for two years. Yet those two years have produced virtually no significant progress in improving any of them. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 14 17:35:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03308 for ; Sat, 14 Feb 2004 17:35:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As8NK-0007gf-7D for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 17:35:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EMZ2at029538 for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 17:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As8NI-0007g6-6p for mpowr-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 17:35: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 RAA03298 for ; Sat, 14 Feb 2004 17:34:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As8NF-00008L-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 17:34:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As8MH-00004e-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 17:33:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As8LL-00000D-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 17:32:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As8LN-0007ZI-Bc; Sat, 14 Feb 2004 17:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As8LL-0007Z4-RJ for mpowr@optimus.ietf.org; Sat, 14 Feb 2004 17:32:59 -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 RAA03186 for ; Sat, 14 Feb 2004 17:32:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As8LJ-0007ne-00 for mpowr@ietf.org; Sat, 14 Feb 2004 17:32:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As8KK-0007jV-00 for mpowr@ietf.org; Sat, 14 Feb 2004 17:31:57 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1As8JN-0007gK-00 for mpowr@ietf.org; Sat, 14 Feb 2004 17:30:58 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1As8JN-000AqQ-00; Sat, 14 Feb 2004 17:30:57 -0500 Date: Sat, 14 Feb 2004 17:30:57 -0500 From: John C Klensin To: Dave Crocker , mpowr@ietf.org Subject: Re: [mpowr] WG Formation Message-ID: <19274234.1076779857@scan.jck.com> In-Reply-To: <14410174609.20040214094846@brandenburg.com> References: <327742548.1076153200@scan.jck.com> <1943493383.20040214081341@brandenburg.com> <38529151.1076758786@scan.jck.com> <14410174609.20040214094846@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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Saturday, 14 February, 2004 09:48 -0800 Dave Crocker wrote: > JCK> I think your proposal and mine are largely compatible. > > oh, you optimist, you... Sigh. > JCK> I think there should be a number of different ways of > getting to JCK> a WG and that _any_ model through which all > pre-WGs and WGs must JCK> go is an invitation to getting > ourselves bogged down in JCK> procedural nonsense and > rigidity rather than keeping the focus JCK> on getting the > job done. > > I think we have a meaningful difference, here. > > By their nature, rules are Procrustean. Hence, rules should > be created only when the tradeoffs among flexibility, > efficiency, quality and the like all warrant it. In this > case, I think we have a very serious problem with wasteful > formation of unproductive working groups. Our diagnosis differs somewhat. I'd say we have a lifecycle problem with the time between when an effort starts to come together and when we either have it producing standards or move it off the IETF queue. While we can certainly manipulate things like nominal starting points to make the IETF look better statistically, I don't consider that a useful objective. There are perfectly good efforts that don't belong in the IETF but that need some input and feedback from us. We may be able to figure that out quickly; it may take a while. Leaving them on their own for a long time and then providing them that feedback when they decide they want a charter may be the right thing to do for some of them, early BOFs and strong early feedback may be right for others, and the spotlight of a WG which then gets its plug pulled may be right for yet others. I think we have a serious problem in that we are wasteful in the processes we use to [decide to] create and terminate WGs. I think your conclusion, above, is a symptom of the fact that we have made the creation and deletion processes much too complex and ponderous. So, on the one hand, were I giving ADs advice, my advice would be that, in a very large fraction of cases, the model you and Bert have suggested is the right one. But I'd like to see ADs look at these situations one at a time, make judgments (consulting mailing lists, directorates, and other mechanisms for understanding community views as appropriate), and then choose models, tools, and methods for particular groups as they think appropriate... to the situation and to their particular management styles and preferences. Obviously, "trust the IESG" models are an important part of that approach. If those folks can't figure out which pre-WG (or during-WG, or post-WG) approach is likely to work best for them and a given situation, I don't see any reason to believe that they can do better with a single standardized sequence of events that still cumulate in the need to make subjective evaluations and decisions. We also got some new data yesterday that, I believe, deserves very careful consideration: for all of the complaints about IESG poor decisions, poor allocations of priorities, and so forth, the Nomcom looked at the IESG, discussed issues with the community, evaluated people and alternatives... and returned every single IESG member except the one who had voluntarily stepped down. Like it or not, that is a pretty strong statement, on behalf of the community, that we are in reasonable shape and that IESG members are behaving reasonably and making mostly the right decisions. If we don't believe that conclusion, we need to stop wasting our time with little details like WG creating and, instead, start thinking about how to replace the Nomcom model and with what. And, if we do believe it, then, IMO, the IESG may need suggestions, guidelines, and reminders, but probably doesn't need more rule to try to constrain their behavior (especially since rules to constrain them have a history of being, effectively, ignored). I think the rest of your note reflects this difference in perspective, so won't make this one longer by running through it point by point. I do want to note that nothing I suggested involves "an automatic ticket to WG status". Each of them, including, to me, your suggestion, is a way for the IESG to accumulate data on which a decision can then be made -- a decision to establish a WG, to send the group elsewhere, or to advise them to develop more data (using the same or different methods). john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 14 18:04:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04277 for ; Sat, 14 Feb 2004 18:04:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As8pN-0003gn-LU for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 18:04:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EN41oq014171 for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 18:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As8pN-0003gQ-Av for mpowr-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 18:04:01 -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 SAA04226 for ; Sat, 14 Feb 2004 18:03:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As8pK-0001tQ-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 18:03:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As8oN-0001qS-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 18:03:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As8nP-0001n9-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 18:01:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As8nR-0002Sr-Do; Sat, 14 Feb 2004 18:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As8mY-0001k7-31 for mpowr@optimus.ietf.org; Sat, 14 Feb 2004 18:01:06 -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 SAA04081 for ; Sat, 14 Feb 2004 18:01:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As8mV-0001kV-00 for mpowr@ietf.org; Sat, 14 Feb 2004 18:01:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As8lX-0001hH-00 for mpowr@ietf.org; Sat, 14 Feb 2004 18:00:04 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1As8kt-0001bG-00 for mpowr@ietf.org; Sat, 14 Feb 2004 17:59:23 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1EN79d28088; Sat, 14 Feb 2004 15:07:09 -0800 Date: Sat, 14 Feb 2004 14:58:40 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <52955238.20040214145840@brandenburg.com> To: John C Klensin CC: mpowr@ietf.org Subject: Re: [mpowr] WG Formation In-Reply-To: <19274234.1076779857@scan.jck.com> References: <327742548.1076153200@scan.jck.com> <1943493383.20040214081341@brandenburg.com> <38529151.1076758786@scan.jck.com> <14410174609.20040214094846@brandenburg.com> <19274234.1076779857@scan.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.6 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit JCK> While we can certainly manipulate things JCK> like nominal starting points to make the IETF look better JCK> statistically, I don't consider that a useful objective. Neither do I. There are two purposes to my propsal: 1. Impose a rigorous barrier to IETF entry It will filter out quite a bit of poor work, simply by requiring that a group demonstrate that it can be productive, _before_ it is made a working group. This is an entirely natural barrier. Do we have significant indication that working groups with truly lousy initial behavior later turn out to do something valuable? (I'm looking for a pattern here, not an exception.) If a working group cannot have its act together initially, it is not ready for open, standards-oriented engineering prime time. So let's not give them a ticket to the game until they are ready. Please note that I did not say to ignore them until they are chartered. The suggestion to list them gives them visibility. I've no doubt some other cheap and useful actions will also help. 2. Significantly reduce the IETF management and operations burden of wasteful working groups. This is not just an AD issue. There is also the small matter of WG chair time, Secretariat time, IETF meeting space and time, etc. All of these are very, very scarce resources, which we have a pattern of squandering. Rather than task ADs with watching out for questionable working groups and rather than having those questionable working groups add to the congestion of IETF week meeting time, move the startup noise out of the organization. JCK> There JCK> are perfectly good efforts that don't belong in the IETF but JCK> that need some input and feedback from us. We may be able to JCK> figure that out quickly; it may take a while. That sounds as if the IETF has some sort of track record "taking awhile" and giving corrective feedback that is productive. Again, I'd be interested in hearing about the pattern of achievement here, because my own sense is that it is quite poor. JCK> So, on the one hand, were I giving ADs advice, my advice would JCK> be that, in a very large fraction of cases, the model you and JCK> Bert have suggested is the right one. But I'd like to see ADs JCK> look at these situations one at a time, make judgments JCK> (consulting mailing lists, directorates, and other mechanisms JCK> for understanding community views as appropriate), and then JCK> choose models, tools, and methods for particular groups as they JCK> think appropriate... to the situation and to their particular JCK> management styles and preferences. In a perfect world, I would agree with you. In world with ADs who were consistently expert in these skills and in a world where ADs had plenty of time for such activities, I would agree with you. However the reality is that the IETF succeeds when a group self-form and had develops enough motivation and cohesion to be productive. For any other scenario, I believe the IETF experience is frustrating, at best, and more often wasteful and unproductive. The idea that ADs actually can or should have the task of "teaching" working groups to be productive is a very serious and strategic management error, based on the IETF performance I've witnessed. JCK> I do want to note that nothing I suggested JCK> involves "an automatic ticket to WG status". Yeah, I thought you'd take exception to that, and indeed it went beyond your words. However it is not clear what to do with something like "prior IRTF effort", beyond feed it into the paradigm I am suggesting. Once we try to do anything else with it, I believe the pragmatics turn it into "automatic ticket". Anything else, I believe, will be too subtle for practical use. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 14 18:43:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06056 for ; Sat, 14 Feb 2004 18:43:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As9R8-00010T-Aa for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 18:43:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ENh2ke003863 for mpowr-archive@odin.ietf.org; Sat, 14 Feb 2004 18:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As9R8-00010E-5X for mpowr-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 18:43:02 -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 SAA06044 for ; Sat, 14 Feb 2004 18:42:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As9R5-0003mC-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 18:42:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As9Q7-0003in-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 18:42:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As9P9-0003fQ-00 for mpowr-web-archive@ietf.org; Sat, 14 Feb 2004 18:40:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As9PB-0000wq-Nc; Sat, 14 Feb 2004 18:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As9OE-0000v9-QQ for mpowr@optimus.ietf.org; Sat, 14 Feb 2004 18:40:02 -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 SAA05962 for ; Sat, 14 Feb 2004 18:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As9OB-0003cZ-00 for mpowr@ietf.org; Sat, 14 Feb 2004 18:39:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As9NE-0003a9-00 for mpowr@ietf.org; Sat, 14 Feb 2004 18:39:01 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1As9Mu-0003Xg-00 for mpowr@ietf.org; Sat, 14 Feb 2004 18:38:40 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b4); Sat, 14 Feb 2004 17:38:10 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <52955238.20040214145840@brandenburg.com> References: <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> X-Mailer: Eudora [Macintosh version 6.1a13] Date: Sat, 14 Feb 2004 17:38:08 -0600 To: Dave Crocker From: Pete Resnick Subject: Re: [mpowr] WG Formation Cc: John C Klensin , mpowr@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 On 2/14/04 at 2:58 PM -0800, Dave Crocker wrote: >1. Impose a rigorous barrier to IETF entry > >It will filter out quite a bit of poor work, simply by requiring >that a group demonstrate that it can be productive, _before_ it is >made a working group. This is an entirely natural barrier. > >Do we have significant indication that working groups with truly >lousy initial behavior later turn out to do something valuable? (I'm >looking for a pattern here, not an exception.) If a working group >cannot have its act together initially, it is not ready for open, >standards-oriented engineering prime time. So let's not give them a >ticket to the game until they are ready. > >Please note that I did not say to ignore them until they are >chartered. The suggestion to list them gives them visibility. I've >no doubt some other cheap and useful actions will also help. I'm trying really hard to figure out what exactly is gained by not chartering a group but still letting them start their work, put them on a list, and expect the IETF-writ-large to start monitoring and/or working with them. If the IETF-writ-large is going to have to participate anyway (i.e., the folks in the not-yet-working-group request and get early cross-area feedback from other folks in the IETF before they produce their first I-D), that sounds like using exactly the same resources that a working group would. If the IETF-writ-large is *not* going to participate, there is some great likelihood that the group will not get good cross-area review, they will float off into the weeds, and they will have invested a great deal of effort in what will turn out to be useless work (i.e., the "late surprise"/"not enough early feedback" problem), which I thought was exactly one of the problems we were trying to fix. (Note that I have not made a distinction here between "outsiders" who want a working group and IETFers who want a working group. There is now a significant enough number of people inside the IETF who are perfectly capable of doing lots of bad work if left to their own devices.) If we're going to ask folks to demonstrate "good work", that's going to include: - getting architectural input, security input, transport input (e.g., if your working in applications), applications input (e.g., if you're working down in the lower layers), etc. - having a well-run mailing list with good moderation (i.e., a chair) - producing I-Ds. Once we add putting them on a public list or other "visibility mechanisms" (maybe having a document stating what they intend to do, i.e., a charter), what do we have that distinguishes that from a working group? If the answer is, "We don't have to spend weeks having the IESG argue about the charter, and the default action if they do bad work after a while is that they go away", why don't we just tell the IESG that they should stop arguing about charters and that bad working groups should be killed early and often? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Feb 15 11:03:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16450 for ; Sun, 15 Feb 2004 11:03:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsOj4-0001Bj-W8 for mpowr-archive@odin.ietf.org; Sun, 15 Feb 2004 11:02:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FG2YAs004561 for mpowr-archive@odin.ietf.org; Sun, 15 Feb 2004 11:02:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsOj4-0001BU-Qn for mpowr-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 11:02:34 -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 LAA16392 for ; Sun, 15 Feb 2004 11:02:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsOj2-0001Rr-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 11:02:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsOi2-0001Ho-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 11:01:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsOgy-00012c-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 11:00:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsOgp-0000pD-1c; Sun, 15 Feb 2004 11:00:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsOgS-0000jR-UT for mpowr@optimus.ietf.org; Sun, 15 Feb 2004 10:59: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 KAA15909 for ; Sun, 15 Feb 2004 10:59:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsOgQ-0000wi-00 for mpowr@ietf.org; Sun, 15 Feb 2004 10:59:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsOe3-0000YN-00 for mpowr@ietf.org; Sun, 15 Feb 2004 10:57:24 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AsOcp-0000Jp-00 for mpowr@ietf.org; Sun, 15 Feb 2004 10:56:07 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1FG43d10924; Sun, 15 Feb 2004 08:04:03 -0800 Date: Sun, 15 Feb 2004 07:55:30 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1461962205.20040215075530@brandenburg.com> To: Pete Resnick CC: mpowr@ietf.org Subject: Re: [mpowr] WG Formation In-Reply-To: References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.6 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pete, PR> I'm trying really hard to figure out what exactly is gained by not PR> chartering a group but still letting them start their work, put them PR> on a list, and expect the IETF-writ-large to start monitoring and/or PR> working with them. The difference is quite large. I apologize for not succeeding at making it clear enough. First of all, there is no "letting them start". That's a key point. They must take their own initiative and self-form a working entity. I need to stress that this is what already happens for efforts that have real, community-based impetus. So what would be different? We would not be expending resources on efforts that try to become an IETF working group and only _then_ figure out what the heck they are going to do. Second of all, the administrative and management overhead on the IETF is almost zero, which cannot be said for chartered working groups. And they get no IETF meeting time. Since a mailing list is supposed to be the core of working group effort, we should make the ability to operate over a mailing list a pre-condition for working group status. R> they PR> will float off into the weeds, and they will have invested a great PR> deal of effort in what will turn out to be useless work (i.e., the PR> "late surprise"/"not enough early feedback" problem), which I thought PR> was exactly one of the problems we were trying to fix. Well, this is certainly an important concern. So let's be clear about the suggestion: It's not that the group should seek IETF formal status when it is nearly done. It should seek formal status when it has achieved enough coherence to show motivation and focus. For any good group, that is usually very quickly. PR> If we're going to ask folks to demonstrate "good work", that's going PR> to include: First of all, there is a difference in the IETF's leverage between a wg-in-formation, versus an already-chartered working group. The former is (or should be) highly motivated to take the initiative of getting itself on a productive vector. The degree to which the latter has to develop that motivation or must be pressured towards it by their AD has proven consistently problematic. Second of all demonstrating the motivation and "skill", at recruiting whatever input is needed, is a key point. Better to have them fail at doing that before they are working group than after. PR> Once we add putting them on a public list or other "visibility PR> mechanisms" (maybe having a document stating what they intend to do, PR> i.e., a charter), what do we have that distinguishes that from a PR> working group? If the answer is, "We don't have to spend weeks having PR> the IESG argue about the charter, and the default action if they do PR> bad work after a while is that they go away", why don't we just tell PR> the IESG that they should stop arguing about charters and that bad PR> working groups should be killed early and often? The footprint of IETF impact is larger than that, as I've noted above and earlier. But the issue is larger than that. IETF Working Groups succeed when they have coherence and focus. The ability to form into a coherent group and develop a discussion process with a productive vector should be a fundamental test for the creation of a working group. If folks cannot demonstrate these, they are not ready for IETF prime time. So let's make these a pre-charter requirement, rather than do the charter and spend considerable resources trying to "fix" groups with this problem. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Feb 15 11:49:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17401 for ; Sun, 15 Feb 2004 11:49:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsPRc-0003Ok-Qi for mpowr-archive@odin.ietf.org; Sun, 15 Feb 2004 11:48:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FGmaEq013056 for mpowr-archive@odin.ietf.org; Sun, 15 Feb 2004 11:48:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsPRc-0003OV-KX for mpowr-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 11:48:36 -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 LAA17397 for ; Sun, 15 Feb 2004 11:48:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsPRb-0004F4-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 11:48:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsPQe-0004CJ-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 11:47:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsPQ6-00049d-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 11:47:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsPQ4-0003MK-VV; Sun, 15 Feb 2004 11:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsPPm-0003LG-AP for mpowr@optimus.ietf.org; Sun, 15 Feb 2004 11:46:42 -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 LAA17364 for ; Sun, 15 Feb 2004 11:46:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsPPl-00049F-00 for mpowr@ietf.org; Sun, 15 Feb 2004 11:46:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsPOq-00046I-00 for mpowr@ietf.org; Sun, 15 Feb 2004 11:45:45 -0500 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx with esmtp (Exim 4.12) id 1AsPOW-000420-00 for mpowr@ietf.org; Sun, 15 Feb 2004 11:45:24 -0500 Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3) for ; Sun, 15 Feb 2004 10:44:53 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <1461962205.20040215075530@brandenburg.com> References: <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> <1461962205.20040215075530@brandenburg.com> X-Mailer: Eudora [Macintosh version 6.1a13] Date: Sun, 15 Feb 2004 10:44:51 -0600 To: mpowr@ietf.org From: Pete Resnick Subject: Re: [mpowr] WG Formation Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 On 2/15/04 at 7:55 AM -0800, Dave Crocker wrote: >>I'm trying really hard to figure out what exactly is gained by not >>chartering a group but still letting them start their work, put >>them on a list, and expect the IETF-writ-large to start monitoring >>and/or working with them. > >The difference is quite large. I apologize for not succeeding at >making it clear enough. Maybe I'm being dense, but this message didn't really clear up the situation for me. Let me try to ask specific questions. >First of all, there is no "letting them start". That I understood. I didn't mean to imply that "letting them start" was an active action by the IETF. >We would not be expending resources on efforts that try to become an >IETF working group and only _then_ figure out what the heck they are >going to do. OK, so here's the first one: What resources? Are we talking about all that effort that now goes on during charter review? Well, a different answer to that is, "Stop spending all of that effort doing nit-picking charter reviews." We seem to be doing that so that we can have some grand justification to stop working groups from doing bad things in the future. There's another tool at our disposal to do that, which is to have the AD mercilessly kill the working group if it strays. If you're not talking about charter review, what resources are you talking about? >Second of all, the administrative and management overhead on the >IETF is almost zero, which cannot be said for chartered working >groups. What overhead are we talking about here? Secretariat time? IESG time? They're certainly going to use the same technical review overhead as a chartered working group if they're doing the right thing to get chartered in the future, and that seems like the biggest resource use. What overhead are you referring to specifically? >And they get no IETF meeting time. Neither do working groups if an AD doesn't want them to. >Since a mailing list is supposed to be the core of working group >effort, we should make the ability to operate over a mailing list a >pre-condition for working group status. That I understand. >>they will float off into the weeds, and they will have invested a >>great deal of effort in what will turn out to be useless work >>(i.e., the "late surprise"/"not enough early feedback" problem), >>which I thought was exactly one of the problems we were trying to >>fix. > >Well, this is certainly an important concern. So let's be clear >about the suggestion: It's not that the group should seek IETF >formal status when it is nearly done. It should seek formal status >when it has achieved enough coherence to show motivation and focus. >For any good group, that is usually very quickly. OK, but this is starting to sound like, "Form a mailing list and demonstrate on that mailing list that you have a clue." That doesn't require producing documents or doing a bunch of work prior to chartering; it's just demonstrating some ability to have a coherent discussion. But do we have lots of examples now of working groups that are chartered which have not been having some coherent discussions on *some* mailing list, even if that mailing list was not dedicated to a particular activity? If a bunch of folks start having a coherent discussion on the IETF-SMTP list about some wiz-bang extension to SMTP and get a charter together, is there really a need to have them go off and have some number of weeks of discussion on a new mailing list before we charter the group? Or if an IRTF group comes up with a good engineering idea, a proposal for what needs to be done, and a group of people on the IRTF list that commit to doing the work in the IETF, do we really need another hoop for them to jump through? >there is a difference in the IETF's leverage between a >wg-in-formation, versus an already-chartered working group. The >former is (or should be) highly motivated to take the initiative of >getting itself on a productive vector. The degree to which the >latter has to develop that motivation or must be pressured towards >it by their AD has proven consistently problematic. But that sounds like more of a problem with ADs being unwilling to pull the rip cord early enough on unmotivated working groups instead "pressuring" them to do something, not with the chartering process. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Feb 15 13:05:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18983 for ; Sun, 15 Feb 2004 13:05:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsQdO-0006tE-BV for mpowr-archive@odin.ietf.org; Sun, 15 Feb 2004 13:04:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FI4ooL026478 for mpowr-archive@odin.ietf.org; Sun, 15 Feb 2004 13:04:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsQdO-0006sz-63 for mpowr-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 13:04:50 -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 NAA18975 for ; Sun, 15 Feb 2004 13:04:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsQdM-0000R2-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 13:04:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsQcW-0000Lx-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 13:03:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsQbc-0000GM-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 13:03:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsQbd-0006m5-Ap; Sun, 15 Feb 2004 13:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsQbI-0006j1-1t for mpowr@optimus.ietf.org; Sun, 15 Feb 2004 13:02:40 -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 NAA18943 for ; Sun, 15 Feb 2004 13:02:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsQbG-0000Dl-00 for mpowr@ietf.org; Sun, 15 Feb 2004 13:02:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsQaN-00008e-00 for mpowr@ietf.org; Sun, 15 Feb 2004 13:01:44 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AsQZp-00005N-00 for mpowr@ietf.org; Sun, 15 Feb 2004 13:01:10 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1FI94d16816; Sun, 15 Feb 2004 10:09:04 -0800 Date: Sun, 15 Feb 2004 10:00:30 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <747830562.20040215100030@brandenburg.com> To: Pete Resnick CC: mpowr@ietf.org Subject: Re: [mpowr] WG Formation In-Reply-To: References: <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> <1461962205.20040215075530@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pete, PR> that effort that now goes on during charter review? Well, a different PR> answer to that is, "Stop spending all of that effort doing PR> nit-picking charter reviews." We seem to be doing that so that we can PR> have some grand justification to stop working groups from doing bad PR> things in the future. There's another tool at our disposal to do PR> that, which is to have the AD mercilessly kill the working group if PR> it strays. 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. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Feb 15 16:52:14 2004 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 ; 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 ; 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 ; 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 To: Dave Crocker , Pete Resnick cc: mpowr@ietf.org Subject: Re: [mpowr] WG Formation Message-ID: <79230247.1076863665@scan.jck.com> In-Reply-To: <747830562.20040215100030@brandenburg.com> References: <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> <1461962205.20040215075530@brandenburg.com> <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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 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 From exim@www1.ietf.org Sun Feb 15 23:13:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12294 for ; Sun, 15 Feb 2004 23:13:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asa7t-000686-I1 for mpowr-archive@odin.ietf.org; Sun, 15 Feb 2004 23:12:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G4CvPl023556 for mpowr-archive@odin.ietf.org; Sun, 15 Feb 2004 23:12:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asa7t-00067r-65 for mpowr-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 23:12:57 -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 XAA12291 for ; Sun, 15 Feb 2004 23:12:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asa7r-0001Vu-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 23:12:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asa6s-0001Qa-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 23:11:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asa60-0001NV-00 for mpowr-web-archive@ietf.org; Sun, 15 Feb 2004 23:11:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asa62-00065z-80; Sun, 15 Feb 2004 23:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asa55-00064u-C6 for mpowr@optimus.ietf.org; Sun, 15 Feb 2004 23:10:03 -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 XAA12236 for ; Sun, 15 Feb 2004 23:09:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asa51-0001Ks-00 for mpowr@ietf.org; Sun, 15 Feb 2004 23:09:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asa49-0001I8-00 for mpowr@ietf.org; Sun, 15 Feb 2004 23:09:05 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1Asa3v-0001Eo-00 for mpowr@ietf.org; Sun, 15 Feb 2004 23:08:51 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6EDE861BE7; Mon, 16 Feb 2004 05:08:19 +0100 (CET) Date: Sun, 15 Feb 2004 20:08:05 -0800 From: Harald Tveit Alvestrand To: Dave Crocker , mpowr@ietf.org Subject: Re: [mpowr] WG Formation Message-ID: <126800950.1076875685@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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 actually I see at least 3 different types of BOF being run in the IETF: - Proposals, often externally initiated, for IETF activities. There, evidence of an active, open community/discussion is the first thing we ask for. - "This is a problem" BOFs. Examples are various SPAM BOFs, the Anycast BOFs and so on - things where we (members of the community, some set of WG chairs, IESG members.....) recognize that there's a problem, but it doesn't seem like WG material, and it doesn't belong to any WG's scope. At the upcoming IETF, it remains to be seen whether MXCOMP will be such a BOF or the initation of a WG activity. Here, making a separate mailing list may be a result of the decision to have a BOF, rather than a precondition - and sometimes a mailing list is even inappropriate. - "Haven't finished the paperwork" BOFs - things that are obviously going to be a WG, but for some reason the charter hasn't been approved (such as haven't got WG chairs, can't agree on a name, didn't get the review messages sent in time....). Examples were L2VPN and L3VPN at the time of the split. One thing I really liked about draft-iesg-hardie-outline was the discussion of the various types of WGs. BOFs, too, don't come in "one size fits all". When we have a reason to have a meeting at the IETF that doesn't fit the WG category, we usually call it a BOF. That means - some variety is to be expected, and some judgment needs to be exercised. I hope that works, most of the time...... Harald _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Feb 16 00:51:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14827 for ; Mon, 16 Feb 2004 00:51:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asbel-0002GX-Km for mpowr-archive@odin.ietf.org; Mon, 16 Feb 2004 00:50:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G5oxnb008703 for mpowr-archive@odin.ietf.org; Mon, 16 Feb 2004 00:50:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asbel-0002GI-Cs for mpowr-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 00:50:59 -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 AAA14822 for ; Mon, 16 Feb 2004 00:50:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asbei-0006o6-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 00:50:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asbdl-0006lQ-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 00:49:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asbcp-0006ia-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 00:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asbcq-0002CX-OJ; Mon, 16 Feb 2004 00:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asbbw-00025Z-SY for mpowr@optimus.ietf.org; Mon, 16 Feb 2004 00:48:04 -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 AAA14782 for ; Mon, 16 Feb 2004 00:48:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asbbu-0006fo-00 for mpowr@ietf.org; Mon, 16 Feb 2004 00:48:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asbay-0006d4-00 for mpowr@ietf.org; Mon, 16 Feb 2004 00:47:04 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AsbaB-0006Xh-00 for mpowr@ietf.org; Mon, 16 Feb 2004 00:46:15 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1G5s8d19856; Sun, 15 Feb 2004 21:54:08 -0800 Date: Sun, 15 Feb 2004 21:45:31 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1801091131.20040215214531@brandenburg.com> To: Harald Tveit Alvestrand CC: mpowr@ietf.org Subject: Re: [mpowr] WG Formation In-Reply-To: <126800950.1076875685@localhost> References: <126800950.1076875685@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Harald, HTA> - Proposals, often externally initiated, for IETF activities. There, HTA> evidence of an active, open community/discussion is the first thing we ask HTA> for. Excellent. Then it is not a big step to make it a requirement, is it? Except that most of the formative BOFs that I've been to in the last few years have had little or no prior activity. And the requirement I am suggesting is for actual work getting done. That's different from simply having active discussion. Active discussion is easy. Make progress is not. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Feb 16 01:24:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15772 for ; Mon, 16 Feb 2004 01:24:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AscAr-00042e-NU for mpowr-archive@odin.ietf.org; Mon, 16 Feb 2004 01:24:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G6O9tO015523 for mpowr-archive@odin.ietf.org; Mon, 16 Feb 2004 01:24:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AscAr-00042H-6W for mpowr-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 01:24:09 -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 BAA15731 for ; Mon, 16 Feb 2004 01:24:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AscAo-0000c2-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 01:24:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asc9v-0000W0-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 01:23:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Asc95-0000Rd-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 01:22:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Asc3x-0008ID-9A for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 01:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asc3w-0003kd-G0; Mon, 16 Feb 2004 01:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asc2z-0003iq-NB for mpowr@optimus.ietf.org; Mon, 16 Feb 2004 01:16:01 -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 BAA15586 for ; Mon, 16 Feb 2004 01:15:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asc2w-0000Dg-00 for mpowr@ietf.org; Mon, 16 Feb 2004 01:15:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asc1z-0000Bf-00 for mpowr@ietf.org; Mon, 16 Feb 2004 01:15:00 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1Asc1n-00009b-00 for mpowr@ietf.org; Mon, 16 Feb 2004 01:14:48 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1Asc1j-000BX2-00; Mon, 16 Feb 2004 01:14:43 -0500 Date: Mon, 16 Feb 2004 01:14:43 -0500 From: John C Klensin To: Dave Crocker , Harald Tveit Alvestrand cc: mpowr@ietf.org Subject: Re: [mpowr] WG Formation Message-ID: <26002169.1076894083@scan.jck.com> In-Reply-To: <1801091131.20040215214531@brandenburg.com> References: <126800950.1076875685@localhost> <1801091131.20040215214531@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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 21:45 -0800 Dave Crocker wrote: > Harald, > > HTA> - Proposals, often externally initiated, for IETF > activities. There, HTA> evidence of an active, open > community/discussion is the first thing we ask HTA> for. > > Excellent. Then it is not a big step to make it a > requirement, is it? I.e. -- "the requirement won't add much, so we should do it"? Wouldn't a better interpretation be "we are doing this already most of the time, and maybe flexibility is useful, so why tamper with it" or "what we are doing isn't working well enough, so why write it into a rule" Now, from my perspective, the more interesting question to ask would have been: "And how much real information comes out of these BOFs? If the answer is often 'not much' and the IESG has the sense that the group will end up chartered as a WG sooner or later anyway, might it not be better to just set them up as a WG on a trial basis and with a short leash?" > Except that most of the formative BOFs that I've been to in > the last few years have had little or no prior activity. FWIW, I'd say the ones I've been to have been about evenly divided between "little or not prior activity" and "enough prior activity, some of it possibly in poor directions" that efforts to recalibrate their directions would be "late surprises" even at the time a BOF is held. john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Feb 16 12:10:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06179 for ; Mon, 16 Feb 2004 12:10:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsmGI-00074Z-VQ for mpowr-archive@odin.ietf.org; Mon, 16 Feb 2004 12:10:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GHAQpF027183 for mpowr-archive@odin.ietf.org; Mon, 16 Feb 2004 12:10:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsmGI-00074M-Pv for mpowr-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 12:10:26 -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 MAA06092 for ; Mon, 16 Feb 2004 12:10:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsmGH-0001h3-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 12:10:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsmFP-0001dY-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 12:09:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsmEu-0001ZS-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 12: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 1AsmEu-0006tS-Rd; Mon, 16 Feb 2004 12:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsmEP-0006sX-Nk for mpowr@optimus.ietf.org; Mon, 16 Feb 2004 12:08:29 -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 MAA05949 for ; Mon, 16 Feb 2004 12:08:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsmEO-0001XA-00 for mpowr@ietf.org; Mon, 16 Feb 2004 12:08:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsmDQ-0001Ss-00 for mpowr@ietf.org; Mon, 16 Feb 2004 12:07:28 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AsmCd-0001K8-00 for mpowr@ietf.org; Mon, 16 Feb 2004 12:06:40 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 46A6661B89; Mon, 16 Feb 2004 18:06:07 +0100 (CET) Date: Mon, 16 Feb 2004 08:40:05 -0800 From: Harald Tveit Alvestrand To: Dave Crocker Cc: mpowr@ietf.org Subject: Re: [mpowr] WG Formation Message-ID: <171920638.1076920805@localhost> In-Reply-To: <1801091131.20040215214531@brandenburg.com> References: <126800950.1076875685@localhost> <1801091131.20040215214531@brandenburg.com> 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 15. februar 2004 21:45 -0800 Dave Crocker wrote: > Harald, > > HTA> - Proposals, often externally initiated, for IETF activities. There, > HTA> evidence of an active, open community/discussion is the first thing > we ask HTA> for. > > Excellent. Then it is not a big step to make it a requirement, is it? > > Except that most of the formative BOFs that I've been to in the last few > years have had little or no prior activity. Dave, at the risk of beating an old, tired drum once again: Can you name some of these BOFs, so that we can check whether all of us have the same perception of whether there was prior activity? > And the requirement I am suggesting is for actual work getting done. > That's different from simply having active discussion. Active > discussion is easy. Make progress is not. On the last two sentences, we fully agree :-) But the point I was trying to make was a completely different one - that we make BOFs for many reasons. For some types of BOFs, it's appropriate to ask for prior activity on a mailing list. For others, it's not. So we either have to invent new names for subgroups of what we currently call "BOFs", or we have to trust someone's judgment on when to require proof of prior activity. Which one is the best use of resources? Harald _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Feb 16 12:19:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06556 for ; Mon, 16 Feb 2004 12:19:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsmOB-0007lP-Ln for mpowr-archive@odin.ietf.org; Mon, 16 Feb 2004 12:18:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GHIZSi029837 for mpowr-archive@odin.ietf.org; Mon, 16 Feb 2004 12:18:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsmOB-0007lA-Hb for mpowr-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 12:18:35 -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 MAA06551 for ; Mon, 16 Feb 2004 12:18:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsmO9-0002K5-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 12:18:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsmNN-0002Fj-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 12:17:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsmMe-0002Aw-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 12:17:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsmMf-0007a3-Ei; Mon, 16 Feb 2004 12:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsmM9-0007WD-Cu for mpowr@optimus.ietf.org; Mon, 16 Feb 2004 12:16:29 -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 MAA06476 for ; Mon, 16 Feb 2004 12:16:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsmM7-00027F-00 for mpowr@ietf.org; Mon, 16 Feb 2004 12:16:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsmLP-00024C-00 for mpowr@ietf.org; Mon, 16 Feb 2004 12:15:44 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AsmKx-00020A-00 for mpowr@ietf.org; Mon, 16 Feb 2004 12:15:16 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1GHN9d27443 for ; Mon, 16 Feb 2004 09:23:09 -0800 Date: Mon, 16 Feb 2004 09:14:30 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1872241726.20040216091430@brandenburg.com> To: mpowr@ietf.org Subject: Re: [mpowr] WG Formation In-Reply-To: <26002169.1076894083@scan.jck.com> References: <126800950.1076875685@localhost> <1801091131.20040215214531@brandenburg.com> <26002169.1076894083@scan.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Since John and Harald seem to be missing the points I've been trying to make, I will assume that others are also missing it. So, here is a concise re-statement: The IETF is good at facilitating working groups that have clear, practical direction, with significant participation and an ability to conduct productive discussion in a timely fashion. The IETF has a poor track record of "fixing" broken working groups. In particular, working groups that lack cohesive, productive discussion rarely change. Problematic working groups are a significant drain on IETF resources, including time for management oversight, consumption of valuable participant time, and consumption of scarce meeting time. Problematic working groups also have an opportunity cost. They set expectations for a solution that is, in fact, unlikely to be produced in a timely or useful fashion. It is to the IETF's general benefit to find ways to avoid this waste of resources and tone of frustration and non-productivity. One approach that will help is to require that working group formation be predicated on a demonstrated ability to conduct productive discussion over a mailing list and with enough participation to demonstrate meaningful constituency. This _adds_ to the list of IETF BOF and working group chartering pre-requisites. It requires that groups expected to be productive and timely first show that they can be. In fact, this requirement is already listed as being optional, in RFC 2418 (IETF Working Group Guidelines and Procedures), before holding a pre-chartering BOF. So the only change would be to make it always required, before chartering and before holding a pre-chartering BOF. An alternative would be to continue to charter working groups that lack a track record for timely productivity, and continue to task the working group chairs and cognizant area director with fixing the working groups that fail to become coherent and productive in a timely fashion. The problem with this approach is that it is very expensive and it does not work. It has not worked reliably -- and probably has not worked at all -- for any of the life of the modern IETF. Rather, it dilutes allocations of time and focus, and it reduces the community sense of productivity. All three of these are, in fact, problematic in the current IETF. Over the life of the IETF, some area directors have employed the policy of requiring a group to demonstrate the requisite capabilities, before chartering as an IETF working group. In fact, some area directors have required this before permitting a BOF to be held. A BOF session is very short and BOFs drain from the total pool of congested IETF meeting time. The suggestion is to move this requirement from "sometimes" to "always", just as we always require a coherent charter with constituency support, before creating a working group. This moves the responsibility for timely productivity entirely to the nascent working group, rather than imposing any of that requirement on IETF management. The nascent group must, of course, interact with IETF management and IETF participants. However there is a considerable difference between the obligations and costs of dealing with chartered efforts, versus other efforts. Hence, a nascent group's ability to recruit participation and assistance is a significant "market" test of that group's effort. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Mon Feb 16 13:03:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09305 for ; Mon, 16 Feb 2004 13:03:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asn5U-00027s-2V for mpowr-archive@odin.ietf.org; Mon, 16 Feb 2004 13:03:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GI3Kab008171 for mpowr-archive@odin.ietf.org; Mon, 16 Feb 2004 13:03:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asn5T-00027i-O2 for mpowr-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 13:03:19 -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 NAA09153 for ; Mon, 16 Feb 2004 13:03:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asn5R-0006Jd-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 13:03:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asn3s-00062G-00 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 13:01:41 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Asn2t-0005xM-01 for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 13:00:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Asmtb-0001Qw-Oe for mpowr-web-archive@ietf.org; Mon, 16 Feb 2004 12:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsmtZ-0001O8-Ln; Mon, 16 Feb 2004 12:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asmt1-0001Ek-5O for mpowr@optimus.ietf.org; Mon, 16 Feb 2004 12:50:27 -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 MAA08840 for ; Mon, 16 Feb 2004 12:50:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asmsz-0005Xr-00 for mpowr@ietf.org; Mon, 16 Feb 2004 12:50:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsmsH-0005TP-00 for mpowr@ietf.org; Mon, 16 Feb 2004 12:49:42 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AsmrJ-0005CT-00 for mpowr@ietf.org; Mon, 16 Feb 2004 12:48:41 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1GHudd30516; Mon, 16 Feb 2004 09:56:39 -0800 Date: Mon, 16 Feb 2004 09:48:00 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <36725270.20040216094800@brandenburg.com> To: Harald Tveit Alvestrand CC: mpowr@ietf.org In-Reply-To: <171920638.1076920805@localhost> References: <126800950.1076875685@localhost> <1801091131.20040215214531@brandenburg.com> <171920638.1076920805@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpowr] bookkeeping 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Harald, >> Except that most of the formative BOFs that I've been to in the last few >> years have had little or no prior activity. HTA> Dave, at the risk of beating an old, tired drum once again: HTA> Can you name some of these BOFs, so that we can check whether all of us HTA> have the same perception of whether there was prior activity? No. It would distract from the discussion. However your query highlights a basic difference in views about discussing and resolving strategic issues in the IETF. Either there is rough consensus that we have a problem with working groups and BOFs that are unproductive, or we don't. If we don't, then let's move on. I'll shut up. If we do have rough consensus about this, then we do not need to cite statistics. Let me repeat: If there is rough consensus that BOF time is generally well spent, then everyone should please ignore my suggestion. On the other hand, if there is rough consensus that BOF time is too often wasted or, at least, inefficient, then we can focus on the nature of my suggestions rather than on bookeeping. Similarly, there is a basic difference in views, between "empowering" groups to self-form and demonstrate capabilities, versus tasking volunteer management with "fixing" those groups that lack the capabilities. If there is rough consensus that IETF management fixes things well, then again, ignore my suggestion and let's move on. If there is rough consensus that problematic working groups do not get fixed all that well and do constitute a problem, then let's talk about solutions. One solution is to expect IETF management to do a better job of fixing things, or of generally "managing" things better. Another is to look for ways to prevent the problems in the first place, or at least to move the problems to be outside the IETF. HTA> But the point I was trying to make was a completely different one - that we HTA> make BOFs for many reasons. For some types of BOFs, it's appropriate to ask HTA> for prior activity on a mailing list. That's nice. My own focus has been on pre-chartering BOFs. HTA> or we have to trust someone's judgment on when to require HTA> proof of prior activity. HTA> Which one is the best use of resources? That sounds like the status quo. Forgive me, but I thought that that was not working very well. As in, it has not been working at all. So why will it work in the future>? Rather than trivialize this as a labeling excercise, I suggest we look at real problems and pursue real solutions. "Trust someone's judgement" has not been working. I believe we have community consensus on this point. That means we need to look for changes to make. If you are suggesting a change, I'm not understanding what it is. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Feb 17 12:17:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18836 for ; Tue, 17 Feb 2004 12:17:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8qW-0006If-Cu for mpowr-archive@odin.ietf.org; Tue, 17 Feb 2004 12:17:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HHHK8T024213 for mpowr-archive@odin.ietf.org; Tue, 17 Feb 2004 12:17:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8qW-0006IS-8K for mpowr-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 12:17:20 -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 MAA18828 for ; Tue, 17 Feb 2004 12:17:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At8qV-0000OA-00 for mpowr-web-archive@ietf.org; Tue, 17 Feb 2004 12:17:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At8pm-0000Kg-00 for mpowr-web-archive@ietf.org; Tue, 17 Feb 2004 12:16:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1At8pI-0000G6-00 for mpowr-web-archive@ietf.org; Tue, 17 Feb 2004 12:16:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1At8pI-0005St-W3 for mpowr-web-archive@ietf.org; Tue, 17 Feb 2004 12:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8pF-0006GC-FP; Tue, 17 Feb 2004 12:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8oi-0006FZ-2n for mpowr@optimus.ietf.org; Tue, 17 Feb 2004 12:15:28 -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 MAA18668 for ; Tue, 17 Feb 2004 12:15:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At8og-0000Ck-00 for mpowr@ietf.org; Tue, 17 Feb 2004 12:15:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At8nj-00003n-00 for mpowr@ietf.org; Tue, 17 Feb 2004 12:14:28 -0500 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1At8ml-0007bC-00 for mpowr@ietf.org; Tue, 17 Feb 2004 12:13:27 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i1HHCnF4508498; Tue, 17 Feb 2004 12:12:49 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-136-235.mts.ibm.com [9.49.136.235]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1HHCh1Z129712; Tue, 17 Feb 2004 10:12:45 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i1HHBOf04010; Tue, 17 Feb 2004 12:11:27 -0500 Message-Id: <200402171711.i1HHBOf04010@cichlid.raleigh.ibm.com> To: Dave Crocker cc: mpowr@ietf.org Subject: Re: [mpowr] WG Formation In-Reply-To: Message from dhc@dcrocker.net of "Mon, 16 Feb 2004 09:14:30 PST." <1872241726.20040216091430@brandenburg.com> Date: Tue, 17 Feb 2004 12:11:18 -0500 From: Thomas Narten 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 > The IETF is good at facilitating working groups that have clear, > practical direction, with significant participation and an ability to > conduct productive discussion in a timely fashion. Note: as an AD, I find that making the judgement call as to whether an effort (e.g., BOF preparation and/or mailing list BOF preparation) is actually a "productive discussion" is not always so easy, and that my assessment is frequently at odds with that of those participating in or driving the effort. There are multiple dimensions here. Ability to articulate the root problem. Ability to see potential solutions that solve the exact problem (and no more). Willinginess to keep the solution simple. Willingness (or ability) to see implications of a particular approach on other parts of the Internet which are not an immediate focus of the WG. Etc. And because there is a judgement call (on which different people may not agree) on many of these points, coming up with clear criteria that folks will generally agree on is probably not so easy. > The IETF has a poor track record of "fixing" broken working groups. In > particular, working groups that lack cohesive, productive discussion > rarely change. > Problematic working groups are a significant drain on IETF resources, > including time for management oversight, consumption of valuable > participant time, and consumption of scarce meeting time. Problematic > working groups also have an opportunity cost. They set expectations for > a solution that is, in fact, unlikely to be produced in a timely or > useful fashion. > It is to the IETF's general benefit to find ways to avoid this waste of > resources and tone of frustration and non-productivity. I suspect everyone would agree that finding a way to address this would be good! > One approach that will help is to require that working group formation > be predicated on a demonstrated ability to conduct productive discussion > over a mailing list and with enough participation to demonstrate > meaningful constituency. I think that in practice this is already being done. I'd be interested in hearing of specific cases where it is not. But as I said earlier, people's views of "productive" vary, so in the end there is often a judgement call that has to be made. As one example (since folk here probably aren't aware of it...) Some folk asked for an anycast BOF for the upcoming IETF. The RTG and INT ADs were involved. We basically said no, because we weren't convinced that enough prep work had been done for a BOF, even though the proponent(s) probably felt otherwise. We specifically wanted more mailing list discussion, a more clear problem statement and IDs. But they did have a mailng list, a proposed charter and pointed to a number of IDs... > This _adds_ to the list of IETF BOF and working group chartering > pre-requisites. It requires that groups expected to be productive and > timely first show that they can be. In fact, this requirement is already > listed as being optional, in RFC 2418 (IETF Working Group Guidelines and > Procedures), before holding a pre-chartering BOF. > So the only change would be to make it always required, before > chartering and before holding a pre-chartering BOF. > An alternative would be to continue to charter working groups that lack > a track record for timely productivity, and continue to task the working > group chairs and cognizant area director with fixing the working groups > that fail to become coherent and productive in a timely fashion. One thing the above doesn't help with is work areas where there are clearly folk interested in working on the problem, the problem is real and in need of a solution, but the effort needs help getting on track. Is it better to work with the group within the IETF? Or to keep them at arms length outside and hope the can figure things out for themselves? I think the answer depends on many factors, but when the problem is of importance to the IETF, and there is enough activity going on that if the IETF ignores it, it will have to deal with the consequences later anyway, keeping them at arms length doesn't seem like the better alternative. > Over the life of the IETF, some area directors have employed the policy > of requiring a group to demonstrate the requisite capabilities, before > chartering as an IETF working group. In fact, some area directors have > required this before permitting a BOF to be held. A BOF session is > very short and BOFs drain from the total pool of congested IETF > meeting time. Speaking personally, I've certainly hosted a number of BOFs that didn't seem like they were that well run or had prepared adequately. At the same time, those efforts usually did have a fair amount of behind-the-scene steering/encouragement from the ADs (and others) trying to make them better and good enough. But at the end of the day the question is: is the community better served by letting the BOF (with whatever shortcomings) go forward, or should it be delayed for at least another cycle in attempt (hope?) to make things more baked? Pushing off a BOF for another cycle has the downside of delaying an effort and/or opening the AD up to criticism that they just don't (for whatever reason) like the BOF (or an ID, or a particular solutions, or...). > The suggestion is to move this requirement from "sometimes" to "always", > just as we always require a coherent charter with constituency support, > before creating a working group. I certainly look for this before creating a WG. Among the factors I look for: - clear problem statement? Well-scoped and understood? (and is it written down so folk are agreeing to the same words?) - Is the problem important? - Is there really a need for a standard? (I.e., multiple vendors will need to implement this, solves an end-user problem) - are there sufficient worker bees? (editors, chairs, etc) - are the sufficient reviewers (with necessary expertise)? - do the participants seem to be largely in agreement on what the WG needs to do and how to get there? (or will this group be hard to manage and keep on track)? > This moves the responsibility for timely productivity entirely to the > nascent working group, rather than imposing any of that requirement on > IETF management. Certainly, there is a time for this. But I think there are too many differences in each BOF situation to make hard-and-fast rules that MUST be adhered to. Thomas _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Tue Feb 17 12:48:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21518 for ; Tue, 17 Feb 2004 12:48:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9Ki-0000w6-3J for mpowr-archive@odin.ietf.org; Tue, 17 Feb 2004 12:48:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HHmWIR003592 for mpowr-archive@odin.ietf.org; Tue, 17 Feb 2004 12:48:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9Kh-0000vr-Rg for mpowr-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 12:48:31 -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 MAA21505 for ; Tue, 17 Feb 2004 12:48:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9Kg-0003oo-00 for mpowr-web-archive@ietf.org; Tue, 17 Feb 2004 12:48:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9K1-0003jT-00 for mpowr-web-archive@ietf.org; Tue, 17 Feb 2004 12:47:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At9JD-0003bX-00 for mpowr-web-archive@ietf.org; Tue, 17 Feb 2004 12:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9JE-0000tx-Gu; Tue, 17 Feb 2004 12:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9Iq-0000tM-CN for mpowr@optimus.ietf.org; Tue, 17 Feb 2004 12:46:36 -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 MAA21224 for ; Tue, 17 Feb 2004 12:46:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9Io-0003Xu-00 for mpowr@ietf.org; Tue, 17 Feb 2004 12:46:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9Hp-0003NE-00 for mpowr@ietf.org; Tue, 17 Feb 2004 12:45:34 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1At9Gp-000377-00 for mpowr@ietf.org; Tue, 17 Feb 2004 12:44:31 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1HHq6d20397; Tue, 17 Feb 2004 09:52:06 -0800 Date: Tue, 17 Feb 2004 09:43:31 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <687385108.20040217094331@brandenburg.com> To: Thomas Narten CC: mpowr@ietf.org Subject: Re: [mpowr] WG Formation In-Reply-To: <200402171711.i1HHBOf04010@cichlid.raleigh.ibm.com> References: Message from dhc@dcrocker.net of "Mon, 16 Feb 2004 09:14:30 PST." <1872241726.20040216091430@brandenburg.com> <200402171711.i1HHBOf04010@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thomas, I had a more detailed response written, and then decided the most salient point of your note was what should be focused on: >> This moves the responsibility for timely productivity entirely to the >> nascent working group, rather than imposing any of that requirement on >> IETF management. TN> Certainly, there is a time for this. But I think there are too many TN> differences in each BOF situation to make hard-and-fast rules that TN> MUST be adhered to. Do we have a problem? Is the pattern of BOFs typically productive? Is the timely productivity of a working group distinguished by the up-front preparatory work that is done? Do working groups that start badly end well? Should we leave all of the details and procedure fuzzy, to be decided by the subjective assessment of individual ADs, as they are now? If we do not have a problem, then we certainly should not try to fix it. If we do have a problem, then what are you suggesting for fixing it? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Wed Feb 18 21:13:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07846 for ; Wed, 18 Feb 2004 21:13:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtdgH-0006PE-MV for mpowr-archive@odin.ietf.org; Wed, 18 Feb 2004 21:12:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J2CnSh024620 for mpowr-archive@odin.ietf.org; Wed, 18 Feb 2004 21:12:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtdgH-0006P1-HJ for mpowr-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 21:12:49 -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 VAA07840 for ; Wed, 18 Feb 2004 21:12:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtdgF-0001rV-00 for mpowr-web-archive@ietf.org; Wed, 18 Feb 2004 21:12:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtdfH-0001pq-00 for mpowr-web-archive@ietf.org; Wed, 18 Feb 2004 21:11:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtdeW-0001oB-00 for mpowr-web-archive@ietf.org; Wed, 18 Feb 2004 21:11:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtdeY-0006Cx-5J; Wed, 18 Feb 2004 21:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtdeL-00064g-Tx for mpowr@optimus.ietf.org; Wed, 18 Feb 2004 21:10:50 -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 VAA07762 for ; Wed, 18 Feb 2004 21:10:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtdeJ-0001nc-00 for mpowr@ietf.org; Wed, 18 Feb 2004 21:10:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtddS-0001m7-00 for mpowr@ietf.org; Wed, 18 Feb 2004 21:09:54 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1Atdcw-0001ik-00 for mpowr@ietf.org; Wed, 18 Feb 2004 21:09:22 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1J2HOd25249; Wed, 18 Feb 2004 18:17:24 -0800 Date: Wed, 18 Feb 2004 18:08:48 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1209179081.20040218180848@brandenburg.com> To: Thomas Narten CC: mpowr@ietf.org Subject: Re: [mpowr] WG Formation In-Reply-To: <200402171711.i1HHBOf04010@cichlid.raleigh.ibm.com> References: Message from dhc@dcrocker.net of "Mon, 16 Feb 2004 09:14:30 PST." <1872241726.20040216091430@brandenburg.com> <200402171711.i1HHBOf04010@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thomas, TN> immediate focus of the WG. Etc. And because there is a judgement call TN> (on which different people may not agree) on many of these points, TN> coming up with clear criteria that folks will generally agree on is TN> probably not so easy. Your list is quite good. And the subjectivity in applying the criteria is exactly why my suggestion does not specify any of those details. In other words, it proposes a rigid requirement for some activities that will provide very useful -- and very visible -- input to the chartering process. However, it wisely does not alter the core nature of that process. Notably, the judgement call remains as it is now. And again we should note that the suggestion is for something that is already done, just not often enough. >> One approach that will help is to require that working group formation >> be predicated on a demonstrated ability to conduct productive discussion >> over a mailing list and with enough participation to demonstrate >> meaningful constituency. TN> I think that in practice this is already being done. As I said, if there is rough consensus that we do not have a problem with BOFs (and, yes, working groups) being authorized without sufficient preparatory work, then my suggestion should not carry the day. TN> As one example (since folk here probably aren't aware of it...) Some There are many examples of good decisions. The problem is with the pattern for the IETF. If folks think the _pattern_ or preparatory work is acceptable, then let's move on to a topic that folks feel _is_ a problem. >> An alternative would be to continue to charter working groups that lack >> a track record for timely productivity, and continue to task the working >> group chairs and cognizant area director with fixing the working groups >> that fail to become coherent and productive in a timely fashion. TN> One thing the above doesn't help with is work areas where there are TN> clearly folk interested in working on the problem, the problem is TN> real and in need of a solution, but the effort needs help getting on TN> track. It's probably worth exploring the term "getting on track". I believe that it usually refers to a lack of clear focus, typically including a problem and solution statement that is too fuzzy. Such situations are not yet ready for a standards effort, because they do not know what they want to standardize. Maybe they need an IRTF effort. Maybe they just need the usual array of organizing pre-standards effort that _any_ standards effort requires. My own sense of things is that we do a really terrible job at getting fuzzy efforts on track after a group is chartered. So let's stop trying. TN> I think the answer depends on many factors, but when the problem is of TN> importance to the IETF, and there is enough activity going on that if TN> the IETF ignores it, it will have to deal with the consequences later TN> anyway, keeping them at arms length doesn't seem like the better TN> alternative. Importance to the net is, of course... important. However a failure to develop a clear working path is a show-stopper. The IETF has demonstrated a pretty clear pattern of success only when folks who will work on a problem have a clear, shared sense of the problem and the approach towards solving it. I believe that working groups that are chartered without having this usually fare very poorly, and that they take a long time and often take a lot of resources to achieve that poor result. TN> Certainly, there is a time for this. But I think there are too many TN> differences in each BOF situation to make hard-and-fast rules that TN> MUST be adhered to. Does that mean keep the status quo for dealing with BOFs or did you have a suggestion for something that will make them more useful? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Fri Feb 20 14:18:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07580 for ; Fri, 20 Feb 2004 14:18:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuGA6-0006ax-Bq for mpowr-archive@odin.ietf.org; Fri, 20 Feb 2004 14:18:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KJIAWq025345 for mpowr-archive@odin.ietf.org; Fri, 20 Feb 2004 14:18:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuGA6-0006aZ-5e for mpowr-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 14:18:10 -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 OAA07575 for ; Fri, 20 Feb 2004 14:18:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuGA3-0001OU-00 for mpowr-web-archive@ietf.org; Fri, 20 Feb 2004 14:18:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuG9B-0001Lo-00 for mpowr-web-archive@ietf.org; Fri, 20 Feb 2004 14:17:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuG8w-0001IJ-00 for mpowr-web-archive@ietf.org; Fri, 20 Feb 2004 14:16:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuG8y-0006Mw-Fk; Fri, 20 Feb 2004 14:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuG8A-0006J2-Dw for mpowr@optimus.ietf.org; Fri, 20 Feb 2004 14:16:10 -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 OAA07497 for ; Fri, 20 Feb 2004 14:16:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuG87-0001Ge-00 for mpowr@ietf.org; Fri, 20 Feb 2004 14:16:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuG7D-0001D7-00 for mpowr@ietf.org; Fri, 20 Feb 2004 14:15:12 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1AuG6Y-000167-00 for mpowr@ietf.org; Fri, 20 Feb 2004 14:14:30 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i1KJDpvC506726; Fri, 20 Feb 2004 14:13:51 -0500 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1KJDoDC024908; Fri, 20 Feb 2004 12:13:50 -0700 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id i1KJDo7c025082; Fri, 20 Feb 2004 14:13:50 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i1KJDnD9025078; Fri, 20 Feb 2004 14:13:49 -0500 Message-Id: <200402201913.i1KJDnD9025078@rotala.raleigh.ibm.com> To: Dave Crocker cc: mpowr@ietf.org Subject: Re: [mpowr] WG Formation In-Reply-To: Message from dcrocker@brandenburg.com of "Wed, 18 Feb 2004 18:08:48 PST." <1209179081.20040218180848@brandenburg.com> Date: Fri, 20 Feb 2004 14:13:49 -0500 From: Thomas Narten 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Dave, > As I said, if there is rough consensus that we do not have a problem > with BOFs (and, yes, working groups) being authorized without sufficient > preparatory work, then my suggestion should not carry the day. I don't think the problem with underperforming WGs can be attributed to something as simple as inadequate preparatory work. Later, you say: > Importance to the net is, of course... important. However a failure to > develop a clear working path is a show-stopper. The IETF has > demonstrated a pretty clear pattern of success only when folks who will > work on a problem have a clear, shared sense of the problem and the > approach towards solving it. I think this is one of the better predictors for success. When the folks in the WG (and the WG Chair/AD/IESG) are all on the same page in terms you describe above. But it is not all that uncommon for an effort (whether BOF or even WG) for there to be much more diversity in where folks heads are at. The challenge then is finding a way to steer towards a shared vision/direction. And in some sense, that is part of the what the WG process is all about. I.e, finding (or developing) consensus among the set of participants. > Does that mean keep the status quo for dealing with BOFs or did you have > a suggestion for something that will make them more useful? My own view is that the BOF->WG process does have problems. Namely, as I recall the original message of the thread mentioning , we have cases where it just seems to take longer than it should from start to finish. I don't have any obvious answers. What I think might be useful though it see if we can understand the problem better than "it's not working". I.e., it might make sense to look at 5-10 BOF->WG efforts that happened in the last year or so, and try to understand how well the system worked (or didn't work) in each of those cases. There may be some general observations/lessons there that can be used to improve future efforts. Thomas _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 21 16:11:23 2004 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 ; 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 ; 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 ; 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 Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1974503943.20040221224129@brandenburg.com> To: John C Klensin CC: mpowr@ietf.org Subject: Re: [mpowr] WG Formation In-Reply-To: <79230247.1076863665@scan.jck.com> References: <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> <1461962205.20040215075530@brandenburg.com> <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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sat Feb 21 17:00:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14743 for ; 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 1AueOk-0006z6-Ui 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 i1LLAsCF026842 for mpowr-archive@odin.ietf.org; Sat, 21 Feb 2004 16:10:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AueOk-0006yr-Oq for mpowr-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 16:10:54 -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 QAA14719 for ; Sat, 21 Feb 2004 16:10:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AueOj-0006hW-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 1AueNm-0006ev-00 for mpowr-web-archive@ietf.org; Sat, 21 Feb 2004 16:09:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AueMu-0006ce-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-0006sQ-58; 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-0006s5-61 for mpowr@optimus.ietf.org; Sat, 21 Feb 2004 16:08:59 -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 QAA14690 for ; 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 1AueMr-0006c4-00 for mpowr@ietf.org; Sat, 21 Feb 2004 16:08:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AueLv-0006Zc-00 for mpowr@ietf.org; Sat, 21 Feb 2004 16:08:00 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AueLd-0006Wh-00 for mpowr@ietf.org; Sat, 21 Feb 2004 16:07:41 -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 i1LLFad05641; Sat, 21 Feb 2004 13:15:36 -0800 Date: Sat, 21 Feb 2004 22:42:02 +0900 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1102859505.20040221224202@brandenburg.com> To: Thomas Narten CC: mpowr@ietf.org Subject: Re: [mpowr] WG Formation In-Reply-To: <200402201913.i1KJDnD9025078@rotala.raleigh.ibm.com> References: Message from dcrocker@brandenburg.com of "Wed, 18 Feb 2004 18:08:48 PST." <1209179081.20040218180848@brandenburg.com> <200402201913.i1KJDnD9025078@rotala.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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: 7bit Content-Transfer-Encoding: 7bit Thomas, TN> Later, you say: >> Importance to the net is, of course... important. However a failure to >> develop a clear working path is a show-stopper. The IETF has >> demonstrated a pretty clear pattern of success only when folks who will >> work on a problem have a clear, shared sense of the problem and the >> approach towards solving it. TN> I think this is one of the better predictors for success. OK. Let's work with that point of agreement: What I mean with the term "preparatory work" is the really difficult stuff of a) being very clear about what problem is being solved, b) so clear that there is a very good idea how it will get used, and c) a clear, strong vendor push, and d) a reasonably clear customer pull. In other words, what is the problem? what is the line of attack on the problem; is there good indication of interest by folks who will do the work; and is there good indication of interest by folks who will use the result? (All of this should sound pretty familiar, since it is already supposed to be the basis for approving a working group.) TN> When the TN> folks in the WG (and the WG Chair/AD/IESG) are all on the same page in TN> terms you describe above. right. TN> But it is not all that uncommon for an effort (whether BOF or even WG) TN> for there to be much more diversity in where folks heads are at. The TN> challenge then is finding a way to steer towards a shared TN> vision/direction. right. TN> And in some sense, that is part of the what the WG TN> process is all about. I.e, finding (or developing) consensus among the TN> set of participants. Sure. But the question is what is reasonable for a chartered working group to formulate consensus on, and what consensus must exist _before_ chartering? The question is how much shared sense of things there is, at the start, versus how much risk there is of getting enough shared sense, to get work done, _after_ working group chartering. Some cliche like "critical mass" applies here. And, yes, different groups can have very different degrees of working things out and different timeframes for doing it. The question is what the IETF should spend its scarce resources on? We have serious and consistent patterns of working groups being neither timely nor productive. Having a _really_ good chartering process and _really_ demanding both a rock solid charter and a strong indication of group focus _before_ chartering does not guarantee timeliness or productivity. But it sure helps. >> Does that mean keep the status quo for dealing with BOFs or did you have >> a suggestion for something that will make them more useful? TN> My own view is that the BOF->WG process does have problems. Namely, as TN> I recall the original message of the thread mentioning , we have cases TN> where it just seems to take longer than it should from start to TN> finish. I don't have any obvious answers. TN> What I think might be useful though it see if we can understand the TN> problem better than "it's not working". I.e., it might make sense to Thomas, we have been in a state of terminal crisis for at least 2 years. How much longer shall we "study" it? TN> try to understand how well the system worked (or didn't work) in each TN> of those cases. There may be some general observations/lessons there TN> that can be used to improve future efforts. Well, I think it's fine to do such a study. What is not fine is waiting around for another two years, making no improvements to the IETF other than training and moving around some administrative duties Or should we, perhaps, break this pattern of paralysis? So let's consider this more simply: BOFs are, at best, inefficient. Working groups do, in fact, typically start with little clue about their work. Working groups often do, in fact, thrash for a long time. And all of this does, in fact, drain the life out of the IETF. So the suggestion is to raise the bar for entry of new BOFs and working groups. This permits us to focus our limited resources and energy far better, to the groups that come to the IETF with their act together (or, at least, _more_ together). When your study shows that we can lower the bar, then we can lower it. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Feb 22 16:20:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09140 for ; Sun, 22 Feb 2004 16:20: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 1Av10x-0007fi-0s for mpowr-archive@odin.ietf.org; Sun, 22 Feb 2004 16:19:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1MLJogr029481 for mpowr-archive@odin.ietf.org; Sun, 22 Feb 2004 16:19:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av10w-0007fQ-Qd for mpowr-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 16:19:50 -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 QAA09122 for ; Sun, 22 Feb 2004 16:19:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av10v-0002j9-00 for mpowr-web-archive@ietf.org; Sun, 22 Feb 2004 16:19:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av101-0002f0-00 for mpowr-web-archive@ietf.org; Sun, 22 Feb 2004 16:18:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Av0zA-0002ax-00 for mpowr-web-archive@ietf.org; Sun, 22 Feb 2004 16:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av0zB-0007dK-73; Sun, 22 Feb 2004 16:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av0yp-0007cP-Qj for mpowr@optimus.ietf.org; Sun, 22 Feb 2004 16:17:39 -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 QAA09052 for ; Sun, 22 Feb 2004 16:17:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av0yo-0002Z5-00 for mpowr@ietf.org; Sun, 22 Feb 2004 16:17:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av0xp-0002WG-00 for mpowr@ietf.org; Sun, 22 Feb 2004 16:16:39 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1Av0wz-0002Ub-00 for mpowr@ietf.org; Sun, 22 Feb 2004 16:15:45 -0500 Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 1Av0wq-0001SS-00; Sun, 22 Feb 2004 16:15:39 -0500 Date: Sun, 22 Feb 2004 16:15:25 -0500 From: John C Klensin To: Dave Crocker cc: mpowr@ietf.org Subject: Re: [mpowr] WG Formation Message-ID: <19326065.1077466525@P2> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Saturday, 21 February, 2004 22:41 +0900 Dave Crocker wrote: > 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. No, I think it does something a little different. If we use, more or less, the current processes (see below), an AD who has told a group to demonstrate that it can be productive can say, at almost any time during the pre-WG, pre-BOF proof of concept period "sorry, this doesn't belong in the IETF, why don't you find another venue". If my guess as to how what you have proposed would play itself out is correct, we would be creating another "late surprise" situation: a group would go off and spend a lot of energy trying to prove concern, come in, and be told, "even if you have demonstrated that you can do that, we don't want it". Yes, that helps the IETF statistically -- the time that is wasted isn't "ours" -- but it isn't good for the Internet, since some of these activities really could thrive in other venues. > 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. No, it takes an existing practice that is used often, sometimes with great success, and turns it into the _only_ option. That ignores and excludes other paths that might work better in particular situations. As others have pointed out, if it were the existing practice, and it was working well in the overwhelming number of cases, we wouldn't be having this discussion. Or we shouldn't be having it and should, instead, be focusing on the bad practices and/or stupidity of selected ADs who can't recognize a good thing when they see it. But, as far as I can tell, the existing practice, even when applied, isn't good enough to solve a significant fraction of the situations we are talking about. To draw a perhaps-unfortunate analogy, this suggestion has the ring of mandatory sentencing laws: if one commits a crime that meets certain criteria, then the exact penalty is specified by law, with no possible deviations. Such things have the attraction that similar or identical crimes receive identical punishment, making the system very predictable. But they fail to allow for special or unusual circumstances that the criteria are, inevitably, never good (or prescient) enough to capture. My own preference --for both sentences and WG creation -- is for strong guidelines, perhaps even strong enough that judges or ADs who go outside them are expected to explain their reasoning in public, but for the flexibility for those people to consider all of the circumstances of a particular situation and apply judgment. > 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. That is because I'm not convinced there is much difference in management and/or administrative overhead. No matter how we constitute these things, ADs often have a choice between "manage now or manage later". Under your plan, the "now" part becomes just general oversight. But where, I think, we may agree is that WGs that have a clear focus, good understanding of what they are about, and effective ways of working with the rest of the IETF simply require much less active management than ones that fail on one or more of those criteria. On the principle that early course corrections typically require fewer turns of the wheel --and may be more successful-- than later ones, I'd rather see ADs in a position to decide that spending some energy on a group early on in the hope that they will run more smoothly (and require significantly less management time) later is a good tradeoff. And, to some extent, your model, in order to make a reduction in management and administrative time early in a WG's life, discards the ability to make that sort of decision. > 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. Well, part of what I've been arguing for is precisely to reduce the amount of energy it takes to lift and swing those hammers. We've seen perfectly good WGs that would meet any entrance criteria one could identify go off in the weeds after a while, and seen external developments create situations in which the WG is just on the wrong track (even if it remains within charter and current on benchmarks). "The world has passed you by, events have overtaken you, you are therefore irrelevant and should go away" should be as reasonable a criterion for shutting down a WG as anything else we have... and your proposal won't help with it at all. If we really wanted to shut down the unproductive, ineffective, and irrelevant, we would institute a probationary period for WGs in which each new one got, say, a year. At the end of that time, it would automatically come up for rechartering, would need to demonstrate that it was useful, productive, and not consuming more resources than its likely results justified. If it could not make that demonstration, it would disappear. Similar "sunset" limits on WG Chairs, etc., might not be a bad idea either. Now, at one level, a proposal like that is complementary to what you are proposing, not in conflict with it. But, in both cases, giving the ADs some explicit discretion seems to me to be more appropriate than trying to impose a particular management mechanism and style. > 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. We do not. That is a problem. Indeed, to my mind, a serious one. But imposing a rigid set of mechanisms on the IESG won't, IMO, fix it, _given the track record_. Instead... * The track record predicts that they will simply ignore such rules if they don't like them. Net effect: much wasted time, many hard feelings in the community. Now the community could start recalling people for ignoring written rules, but we don't have any track record of that either (partially, IMO, because of the "big hammer" problem and partially because we have all observed that pointing out to the Nomcom that some particular AD routinely ignores the rules doesn't reliably predict to that AD's being retired). (That is, of course, why "plan B" makes removal mandatory if an AD is recalled for ignoring certain types of rules.) * We further reduce the pool of possible ADs to including only those who like the management style we are trying to impose. I'd rather the Nomcom judge ADs on effectiveness (of which rule-following ought to be a part, but adherence to one particular management strategy should be secondary). > 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. And I suggest that your suggestion, if approved (and remember that the IESG would need to approve it, so the discussion may be a waste of time if the IESG doesn't like the idea), would probably just be ignored by the same IESG, or the same ADs, who aren't inclined to do it today. > 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. And I believe in reasonably high bars for entrance _and_ in performance/ effectiveness reviews and in sunset periods. I believe that the longer a WG hangs around, the more it should need to do to justify its continued existence. I believe that any IETF activity that is consuming resources should be required to justify its continued existence in terms of the marginal opportunity costs of those resources. I just don't believe that a rigid rule about what someone has to do before getting a BOF or a WG --in minimum rules or in sequencing-- is going to help. Perhaps a partial example would be helpful in clarifying where I think we disagree. Suppose a group showed up tomorrow with a clearly-defined problem, a smattering of experience IETF types in its membership, and a theory about how they were going to proceed. Suppose the formation of the group came out of a bar-BOF at some IETF meeting, or a discussion in the hall during some conference or other non-IETF meeting. And suppose they think they can get something together and have it ready for standardization in nine months. I'd prefer to let them approach an AD with a proposal and a "good enough" charter draft, skip BOFs, go directly to a chartered WG with a minimum of fuss, recruit more participants as part of Charter posting, and go do their thing. I'd like the AD to be able to say "ok, I'll sign off on this given your promise that you can be finished in nine months, but, if you are still around at the end of month 12, I'm going to shut you down and you can start justifying a more realistic group and schedule". Now _that_ would reduce management and administrative time and investment. Will we see it very often? No, but we have seen a few very close approximations. And I would like to see those cases less bogged down in bureaucracy rather than more so. > 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. Nope. The burden is on the group either way. But groups rarely kill themselves, nor do they generally conclude that they aren't ready for whatever the next procedural step is. The IESG is going to need to make decisions either way ... unless one makes the process completely mechanical so that the necessary steps and actions are also treated as sufficient ones. john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Feb 22 16:41:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09675 for ; Sun, 22 Feb 2004 16:41:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av1LB-0000MG-GL for mpowr-archive@odin.ietf.org; Sun, 22 Feb 2004 16:40:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1MLej11001373 for mpowr-archive@odin.ietf.org; Sun, 22 Feb 2004 16:40:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av1LB-0000M4-C1 for mpowr-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 16:40: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 QAA09651 for ; Sun, 22 Feb 2004 16:40:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av1L9-0003u5-00 for mpowr-web-archive@ietf.org; Sun, 22 Feb 2004 16:40:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av1KI-0003rM-00 for mpowr-web-archive@ietf.org; Sun, 22 Feb 2004 16:39:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Av1JU-0003np-00 for mpowr-web-archive@ietf.org; Sun, 22 Feb 2004 16:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av1JV-0000JS-3e; Sun, 22 Feb 2004 16:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av0u4-0007VH-FW for mpowr@optimus.ietf.org; Sun, 22 Feb 2004 16:12: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 QAA09028 for ; Sun, 22 Feb 2004 16:12:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av0u2-0002O2-00 for mpowr@ietf.org; Sun, 22 Feb 2004 16:12:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av0t7-0002Le-00 for mpowr@ietf.org; Sun, 22 Feb 2004 16:11:46 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx with esmtp (Exim 4.12) id 1Av0sY-0002Ip-00 for mpowr@ietf.org; Sun, 22 Feb 2004 16:11:11 -0500 Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 1Av0sP-0001RD-00; Sun, 22 Feb 2004 16:11:04 -0500 Date: Sun, 22 Feb 2004 14:20:04 -0500 From: John C Klensin To: Dave Crocker cc: mpowr@ietf.org Subject: Re: [mpowr] WG Formation Message-ID: <12404238.1077459604@localhost> In-Reply-To: <1974503943.20040221224129@brandenburg.com> References: <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> <1461962205.20040215075530@brandenburg.com> <747830562.20040215100030@brandenburg.com> <79230247.1076863665@scan.jck.com> <1974503943.20040221224129@brandenburg.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Saturday, 21 February, 2004 22:41 +0900 Dave Crocker wrote: > 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. No, I think it does something a little different. If we use, more or less, the current processes (see below), an AD who has told a group to demonstrate that it can be productive can say, at almost any time during the pre-WG, pre-BOF proof of concept period "sorry, this doesn't belong in the IETF, why don't you find another venue". If my guess as to how what you have proposed would play itself out is correct, we would be creating another "late surprise" situation: a group would go off and spend a lot of energy trying to prove concern, come in, and be told, "even if you have demonstrated that you can do that, we don't want it". Yes, that helps the IETF statistically -- the time that is wasted isn't "ours" -- but it isn't good for the Internet, since some of these activities really could thrive in other venues. > 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. No, it takes an existing practice that is used often, sometimes with great success, and turns it into the _only_ option. That ignores and excludes other paths that might work better in particular situations. As others have pointed out, if it were the existing practice, and it was working well in the overwhelming number of cases, we wouldn't be having this discussion. Or we shouldn't be having it and should, instead, be focusing on the bad practices and/or stupidity of selected ADs who can't recognize a good thing when they see it. But, as far as I can tell, the existing practice, even when applied, isn't good enough to solve a significant fraction of the situations we are talking about. To draw a perhaps-unfortunate analogy, this suggestion has the ring of mandatory sentencing laws: if one commits a crime that meets certain criteria, then the exact penalty is specified by law, with no possible deviations. Such things have the attraction that similar or identical crimes receive identical punishment, making the system very predictable. But they fail to allow for special or unusual circumstances that the criteria are, inevitably, never good (or prescient) enough to capture. My own preference --for both sentences and WG creation -- is for strong guidelines, perhaps even strong enough that judges or ADs who go outside them are expected to explain their reasoning in public, but for the flexibility for those people to consider all of the circumstances of a particular situation and apply judgment. > 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. That is because I'm not convinced there is much difference in management and/or administrative overhead. No matter how we constitute these things, ADs often have a choice between "manage now or manage later". Under your plan, the "now" part becomes just general oversight. But where, I think, we may agree is that WGs that have a clear focus, good understanding of what they are about, and effective ways of working with the rest of the IETF simply require much less active management than ones that fail on one or more of those criteria. On the principle that early course corrections typically require fewer turns of the wheel --and may be more successful-- than later ones, I'd rather see ADs in a position to decide that spending some energy on a group early on in the hope that they will run more smoothly (and require significantly less management time) later is a good tradeoff. And, to some extent, your model, in order to make a reduction in management and administrative time early in a WG's life, discards the ability to make that sort of decision. > 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. Well, part of what I've been arguing for is precisely to reduce the amount of energy it takes to lift and swing those hammers. We've seen perfectly good WGs that would meet any entrance criteria one could identify go off in the weeds after a while, and seen external developments create situations in which the WG is just on the wrong track (even if it remains within charter and current on benchmarks). "The world has passed you by, events have overtaken you, you are therefore irrelevant and should go away" should be as reasonable a criterion for shutting down a WG as anything else we have... and your proposal won't help with it at all. If we really wanted to shut down the unproductive, ineffective, and irrelevant, we would institute a probationary period for WGs in which each new one got, say, a year. At the end of that time, it would automatically come up for rechartering, would need to demonstrate that it was useful, productive, and not consuming more resources than its likely results justified. If it could not make that demonstration, it would disappear. Similar "sunset" limits on WG Chairs, etc., might not be a bad idea either. Now, at one level, a proposal like that is complementary to what you are proposing, not in conflict with it. But, in both cases, giving the ADs some explicit discretion seems to me to be more appropriate than trying to impose a particular management mechanism and style. > 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. We do not. That is a problem. Indeed, to my mind, a serious one. But imposing a rigid set of mechanisms on the IESG won't, IMO, fix it, _given the track record_. Instead... * The track record predicts that they will simply ignore such rules if they don't like them. Net effect: much wasted time, many hard feelings in the community. Now the community could start recalling people for ignoring written rules, but we don't have any track record of that either (partially, IMO, because of the "big hammer" problem and partially because we have all observed that pointing out to the Nomcom that some particular AD routinely ignores the rules doesn't reliably predict to that AD's being retired). (That is, of course, why "plan B" makes removal mandatory if an AD is recalled for ignoring certain types of rules.) * We further reduce the pool of possible ADs to including only those who like the management style we are trying to impose. I'd rather the Nomcom judge ADs on effectiveness (of which rule-following ought to be a part, but adherence to one particular management strategy should be secondary). > 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. And I suggest that your suggestion, if approved (and remember that the IESG would need to approve it, so the discussion may be a waste of time if the IESG doesn't like the idea), would probably just be ignored by the same IESG, or the same ADs, who aren't inclined to do it today. > 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. And I believe in reasonably high bars for entrance _and_ in performance/ effectiveness reviews and in sunset periods. I believe that the longer a WG hangs around, the more it should need to do to justify its continued existence. I believe that any IETF activity that is consuming resources should be required to justify its continued existence in terms of the marginal opportunity costs of those resources. I just don't believe that a rigid rule about what someone has to do before getting a BOF or a WG --in minimum rules or in sequencing-- is going to help. Perhaps a partial example would be helpful in clarifying where I think we disagree. Suppose a group showed up tomorrow with a clearly-defined problem, a smattering of experience IETF types in its membership, and a theory about how they were going to proceed. Suppose the formation of the group came out of a bar-BOF at some IETF meeting, or a discussion in the hall during some conference or other non-IETF meeting. And suppose they think they can get something together and have it ready for standardization in nine months. I'd prefer to let them approach an AD with a proposal and a "good enough" charter draft, skip BOFs, go directly to a chartered WG with a minimum of fuss, recruit more participants as part of Charter posting, and go do their thing. I'd like the AD to be able to say "ok, I'll sign off on this given your promise that you can be finished in nine months, but, if you are still around at the end of month 12, I'm going to shut you down and you can start justifying a more realistic group and schedule". Now _that_ would reduce management and administrative time and investment. Will we see it very often? No, but we have seen a few very close approximations. And I would like to see those cases less bogged down in bureaucracy rather than more so. > 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. Nope. The burden is on the group either way. But groups rarely kill themselves, nor do they generally conclude that they aren't ready for whatever the next procedural step is. The IESG is going to need to make decisions either way ... unless one makes the process completely mechanical so that the necessary steps and actions are also treated as sufficient ones. john _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Feb 29 01:51:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25461 for ; Sun, 29 Feb 2004 01:51:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxKmf-0003aq-Mt for mpowr-archive@odin.ietf.org; Sun, 29 Feb 2004 01:50:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1T6ofFj013805 for mpowr-archive@odin.ietf.org; Sun, 29 Feb 2004 01:50:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxKmf-0003aa-FQ for mpowr-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 01:50:41 -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 BAA25446 for ; Sun, 29 Feb 2004 01:50:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxKmc-00041c-00 for mpowr-web-archive@ietf.org; Sun, 29 Feb 2004 01:50:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxKlg-0003ww-00 for mpowr-web-archive@ietf.org; Sun, 29 Feb 2004 01:49:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxKl0-0003sO-00 for mpowr-web-archive@ietf.org; Sun, 29 Feb 2004 01:48:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxKl2-0003Yq-WF; Sun, 29 Feb 2004 01:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxKkj-0003YA-Tt for mpowr@optimus.ietf.org; Sun, 29 Feb 2004 01:48:42 -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 BAA25369 for ; Sun, 29 Feb 2004 01:48:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxKkg-0003rO-00 for mpowr@ietf.org; Sun, 29 Feb 2004 01:48:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxKjq-0003mY-00 for mpowr@ietf.org; Sun, 29 Feb 2004 01:47:46 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxKj2-0003aD-00 for mpowr@ietf.org; Sun, 29 Feb 2004 01:46:56 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1T6kQn14163; Sun, 29 Feb 2004 08:46:26 +0200 Date: Sun, 29 Feb 2004 08:46:26 +0200 (EET) From: Pekka Savola To: mpowr@ietf.org cc: rfc-interest@rfc-editor.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [mpowr] Increasing WG chair role in RFC-editor editing process? 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 Hi, This little practicality has hit me as WG chair a couple of times, so.. perhas this is just a matter of RFC editor changing its process, but if not, this should be another tiny improvement in the process. When a document which is product of a WG is being edited by the RFC editor, any questions/issues/etc. are addressed to the document authors and the shepherding AD. My argument is that this list should be the document authors (or editor, whatever's the case), WG chairs, and the shepherding AD. The AD's job would be just to ensure that WG chairs don't get out of hand.. and the final check & balance would be at AUTH48, AD approving that the document hasn't been substantially modified. This kind of slight "power raise" helps in the scenario where the document authors have gone dormant, and are not responding to their mails in {days, weeks, months, never}. Currently either the AD has to take care of these issues, or act as an SMTP relay between the RFC editor and the chairs. Would make sense? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr From exim@www1.ietf.org Sun Feb 29 17:17:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12624 for ; Sun, 29 Feb 2004 17:17:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZFJ-0003iC-93 for mpowr-archive@odin.ietf.org; Sun, 29 Feb 2004 17:17:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TMHDgc014262 for mpowr-archive@odin.ietf.org; Sun, 29 Feb 2004 17:17:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZFJ-0003hx-0i for mpowr-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 17:17: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 RAA12603 for ; Sun, 29 Feb 2004 17:17:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxZFG-0006yD-00 for mpowr-web-archive@ietf.org; Sun, 29 Feb 2004 17:17:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxZEJ-0006uM-00 for mpowr-web-archive@ietf.org; Sun, 29 Feb 2004 17:16:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxZE8-0006qL-00 for mpowr-web-archive@ietf.org; Sun, 29 Feb 2004 17:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZE9-0003aR-OX; Sun, 29 Feb 2004 17:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxZDJ-0003Xq-Ug for mpowr@optimus.ietf.org; Sun, 29 Feb 2004 17:15:09 -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 RAA12575 for ; Sun, 29 Feb 2004 17:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxZDH-0006pH-00 for mpowr@ietf.org; Sun, 29 Feb 2004 17:15:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxZCJ-0006lB-00 for mpowr@ietf.org; Sun, 29 Feb 2004 17:14:07 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1AxZBN-0006dF-00 for mpowr@ietf.org; Sun, 29 Feb 2004 17:13:09 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id i1TMCe3K002155; Sun, 29 Feb 2004 14:12:40 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.10/Submit) id i1TMCeAj002154; Sun, 29 Feb 2004 14:12:40 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Sun, 29 Feb 2004 14:12:40 -0800 From: David Meyer To: Pekka Savola Cc: mpowr@ietf.org, rfc-interest@rfc-editor.org Subject: Re: [mpowr] Increasing WG chair role in RFC-editor editing process? Message-ID: <20040229221240.GA2130@1-4-5.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon 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: , List-Id: Management Positions -- Oversight, Work and Results List-Post: List-Help: List-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 On Sun, Feb 29, 2004 at 08:46:26AM +0200, Pekka Savola wrote: >> Hi, >> >> This little practicality has hit me as WG chair a couple of times, >> so.. perhas this is just a matter of RFC editor changing its process, >> but if not, this should be another tiny improvement in the process. >> >> When a document which is product of a WG is being edited by the RFC >> editor, any questions/issues/etc. are addressed to the document >> authors and the shepherding AD. >> >> My argument is that this list should be the document authors (or >> editor, whatever's the case), WG chairs, and the shepherding AD. >> >> The AD's job would be just to ensure that WG chairs don't get out of >> hand.. and the final check & balance would be at AUTH48, AD approving >> that the document hasn't been substantially modified. >> >> This kind of slight "power raise" helps in the scenario where the >> document authors have gone dormant, and are not responding to their >> mails in {days, weeks, months, never}. >> >> Currently either the AD has to take care of these issues, or act as an >> SMTP relay between the RFC editor and the chairs. >> >> Would make sense? Pekka, I think this would be a place there there is good "bang for the WG time buck", and fits well in the "Chair as shepherd" framework that is developing. Dave _______________________________________________ mpowr mailing list mpowr@ietf.org https://www1.ietf.org/mailman/listinfo/mpowr