Re: [mpowr] WG Formation
Thomas Narten <narten@us.ibm.com> Tue, 17 February 2004 17:17 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18836 for <mpowr-archive@odin.ietf.org>; 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 <mpowr-web-archive@ietf.org>; 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 <mpowr@ietf.org>; 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 <dcrocker@brandenburg.com>
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 <narten@us.ibm.com>
Sender: mpowr-admin@ietf.org
Errors-To: mpowr-admin@ietf.org
X-BeenThere: mpowr@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpowr>, <mailto:mpowr-request@ietf.org?subject=unsubscribe>
List-Id: Management Positions -- Oversight, Work and Results <mpowr.ietf.org>
List-Post: <mailto:mpowr@ietf.org>
List-Help: <mailto:mpowr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpowr>, <mailto:mpowr-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.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
- RE: [mpowr] WG Formation Wijnen, Bert (Bert)
- Re: [mpowr] WG Formation Harald Tveit Alvestrand
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation John C Klensin
- Re: [mpowr] WG Formation Harald Tveit Alvestrand
- Re: [mpowr] WG Formation Dave Crocker
- [mpowr] bookkeeping Dave Crocker
- Re: [mpowr] WG Formation Thomas Narten
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation Thomas Narten
- Re: [mpowr] WG Formation Dave Crocker
- Re: [mpowr] WG Formation John C Klensin