Re: Design Teams (was "v 1.2, IETF material")
"James R. (Chuck) Davin" <davin@bellcore.com> Fri, 04 December 1992 23:39 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14295; 4 Dec 92 18:39 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14285; 4 Dec 92 18:39 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21354; 4 Dec 92 18:40 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14191; 4 Dec 92 18:39 EST
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa21303; 4 Dec 92 18:38 EST
Received: from phila.bellcore.com by thumper.bellcore.com (4.1/4.7) id <AA27687> for poised@CNRI.Reston.VA.US; Fri, 4 Dec 92 18:37:08 EST
Received: from localhost.bellcore.com by phila.bellcore.com (4.1/4.7) id <AA09237> for gmalkin@xylogics.com; Fri, 4 Dec 92 18:37:29 EST
Message-Id: <9212042337.AA09237@phila.bellcore.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "James R. (Chuck) Davin" <davin@bellcore.com>
To: poised@CNRI.Reston.VA.US
Cc: John C Klensin <KLENSIN@infoods.mit.edu>, gmalkin@xylogics.com
Subject: Re: Design Teams (was "v 1.2, IETF material")
In-Reply-To: Your message of Wed, 02 Dec 92 11:07:48 -0800. <9145.723323268@dbc.mtview.ca.us>
Date: Fri, 04 Dec 1992 18:37:28 -0500
X-Orig-Sender: davin@phila.bellcore.com
The notion of "Design Teams" should not be formalized. When people get together in a small, informal, closed group to exchange ideas on technology, they are having fun and doing the community a service. When people get together in a small, formally recognized, closed group for the purpose of producing an agreed specification destined for promulgation as a standard, they may be in violation of Federal law. Moreover, formalizing the notion of Design Teams will not ease much of the tension, real or perceived, in recent community affairs. I believe that all three of the examples of so-called design team activity that have been cited share an important characteristic that has not yet been stated: an artificially abbreviated timeframe. This, I believe, has been the underlying source of "tension" in these activities, not the (historically familiar and positive) notion that some small group went off and typed up a contribution. I am less familiar with the SMTP-EXT case, but my understanding is that much of the excitement began very late in the process --- after an IESG Last Call. In every discussion of that affair that I can remember, there was reference to the urgent need for progress, "finishing up", and how important it was to maintain "progress" (even when the working group was stalled owing to a profound disagreement). Bob Stewart, Frank Kastenholz, and Craig Partridge have all commented on the SNMPV2 activity. I'm a little more familiar with that case, and I do not believe that the "tension" in that affair has had much at all to do with the formal status of Design Teams or lack thereof. Rather, it is again a matter of an artificially abbreviated timeframe. Bob Stewart said, in effect, that perceptions of impropriety will always be there, and so we should not worry about them. Bob's analysis is incomplete insofar as it centers on personalities and motives: it perpetuates the myth that somehow anybody who criticizes the technical work of a design team or questions the conduct of a working group evaluating a team contribution is motivated only by envy or dislike of the design team members. Although there can often be a tension between technical quality and politics (ice cream and manure, as Bob says), this is not the whole story, and, in this community (put on Pollyanna hat?), we do fairly well most of the time in the ice-cream-manure isolation task. Frank Kastenholz pointed out a cyclic pattern observed in some WGs that are considering design team proposals: 1. WG member points out a deficiency with the proposal and proposes a change. 2. Design Team members say "Foo is a bad idea because ..." 3. Go to Step 1. Craig Partridge pointed out that there is no real problem with this pattern as long as the WG as a whole understands and (metaphorically) "hums" along with the decision. Both Frank and Craig are right. So, whence the perceived tension? I believe that the tension arises from the artificially abbreviated timeframe. That is, tension arises most often when, at Step 2, someone says, "Foo may be an OK idea, but we don't have time to consider it at length, or the immediately apparent benefit of that idea does not warrant our time to give it the consideration it requires." In the SNMP Security WG, there has been tension quite similar in flavor, but it would be hard to say that there is even a bona fide "Design Team" present in the drama. Rather, the tension arises from the dilution of WG deliberation caused by real or imagined time limits and the possibility of using those real or imagined limits to limit working group review of proposals. Indeed, in almost every IETF screw-up that I have seen or been party to (and the sample size is non-trivial :-)), one of the major factors has been an attempt to do things faster, to "optimize" the process. It is true that we must work to reduce bureaucratic delays that are introduced by our structure, and we must streamline our procedures so that they, in and of themselves, are not a source of inappropriate delay, but attempting to reduce delay by abbreviating working group discussions is DEFINITELY the WRONG answer. We should be streamlining our formal procedures in order to allow for LONGER working group discussions. Now those who are fond of talking about commercial reality and the need for timely progress may pipe up at this point to remind us of other standards organizations where progress is sometimes limited by protracted discussion. Or they may remind us that sometimes certain crucial decisions must be made quickly. But it is not clear that the historical technical success enjoyed by this community has been primarily the result of lock-step working group schedules or clock watching. Rather, things get done because we very broadly and very sincerely share a very simple goal (interoperability). Our success owes most to the "community spirit" -- our faith in each other -- of which Marshall Rose spoke so eloquently in Washington. Not to our ability to tell time. Conclusion: The notion of Design Teams is largely irrelevant and does not warrant pursuit as part of the poised effort. Design Teams have only become an "issue" because they have been coincidently associated with cases in which quality technical deliberation may have been sacrificed to haste. Moral: don't set artificial time limits for working group deliberations. If WG members are motivated to work cooperatively, and the WG has an able chair, any truly important schedule will probably be met. Chuck P.S. Bob Stewart was concerned about the judgement of history on the SNMPV2 WG. My (speculative) belief is that history may be more kind to the WG chair than it may to the AD (and others) who bear much of the responsibility for (mistakenly) imposing time limits to begin with. History may deal most harshly with those who either seek to impose time limits gratuitously or to abuse them for some advantage.
- v 1.2, IETF material Carl Malamud
- Change suggestion Re: v 1.2, IETF material Einar Stefferud
- Re: v 1.2, IETF material John C Klensin
- Re: v 1.2, IETF material Erik Huizer
- Re: v 1.2, IETF material Dave Crocker
- Re: v 1.2, IETF material Bob Stewart
- Re: v 1.2, IETF material John C Klensin
- Re: v 1.2, IETF material Barry M. Leiner
- Re: v 1.2, IETF material Frank Kastenholz
- Re: v 1.2, IETF material John C Klensin
- Re: Design Teams (was v 1.2, IETF material) Bob Stewart
- Re: v 1.2, IETF material Einar Stefferud
- Re: v 1.2, IETF material Dave Crocker
- Re: v 1.2, IETF material Einar Stefferud
- Re: v 1.2, IETF material Vinton G. Cerf
- Design Teams (was "v 1.2, IETF material") Gary Scott Malkin
- Re: Design Teams (was "v 1.2, IETF material") Dave Crocker
- Re: Design Teams (was "v 1.2, IETF material") Marshall Rose
- Re: Design Teams (was "v 1.2, IETF material") Bob Stewart
- Re: Design Teams (was "v 1.2, IETF material") John C Klensin
- Re: Design Teams (was "v 1.2, IETF material") Marshall Rose
- Design Teams (was "v 1.2, IETF material") Gary Scott Malkin
- Re: Design Teams (was "v 1.2, IETF material") Marshall Rose
- Re: v 1.2, IETF material Barry M. Leiner
- Re: v 1.2, IETF material Dave Crocker
- Re: v 1.2, IETF material Einar Stefferud
- Re: v 1.2, IETF material Beast (Donald E. Eastlake, 3rd)
- Re: v 1.2, IETF material Frank Kastenholz
- Re: v 1.2, IETF material Beast (Donald E. Eastlake, 3rd)
- Re: Design Teams (was "v 1.2, IETF material") James R. (Chuck) Davin
- Re: Design Teams (was "v 1.2, IETF material") John Curran
- Re: v 1.2, IETF material Einar Stefferud
- Re: v 1.2, IETF material Beast (Donald E. Eastlake, 3rd)
- Re: v 1.2, IETF material Vinton G. Cerf
- Re: v 1.2, IETF material Vinton G. Cerf
- Re: v 1.2, IETF material Beast (Donald E. Eastlake, 3rd)
- Re: v 1.2, IETF material Carl Malamud
- Re: v 1.2, IETF material Vinton G. Cerf
- Re: v 1.2, IETF material Einar Stefferud
- v 1.2, IETF material Gary Scott Malkin
- Re: Design Teams (was "v 1.2, IETF material") Bob Stewart
- Re: Design Teams (was "v 1.2, IETF material") Einar Stefferud
- Re: Design Teams (was "v 1.2, IETF material") Dave Crocker