Re: Design Teams (was "v 1.2, IETF material")

Dave Crocker <dcrocker@mordor.stanford.edu> Tue, 08 December 1992 16:39 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04224; 8 Dec 92 11:39 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04212; 8 Dec 92 11:39 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12662; 8 Dec 92 11:40 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04193; 8 Dec 92 11:39 EST
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa12571; 8 Dec 92 11:40 EST
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA22695; Tue, 8 Dec 92 08:40:16 -0800
Message-Id: <9212081640.AA22695@Mordor.Stanford.EDU>
To: "James R. (Chuck) Davin" <davin@bellcore.com>
Cc: poised@CNRI.Reston.VA.US, John C Klensin <KLENSIN@infoods.mit.edu>, gmalkin@xylogics.com
Subject: Re: Design Teams (was "v 1.2, IETF material")
Org: The Branch Office, Sunnyvale CA
Phone: +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Fri, 04 Dec 92 18:37:28 -0500. <9212042337.AA09237@phila.bellcore.com>
Date: Tue, 08 Dec 1992 08:40:16 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker@mordor.stanford.edu>
X-Mts: smtp

Chuck,

When an issue occurs repeatedly, it usually is a good idea to study
it.  If the issue is viewed as a problem, it usually is a good idea to
solve it, or at least to resolve it.

Activity, contribution and control of working groups by subsets of
their members or by folks doing prior contribution and thereby constraining
the outcome of the wg is a repeated concern to IETF members.  I therefore
submit that we address the issue of these sub-groups explicitly.

You assert artificial timelines as a common thread for these.  And it
certainly is true that assertions of the need to expedite wg effort often
is invoked.  Sometimes this may be inappropriate, but other times it
seems essential.  The phrase "window of opportunity" exists for a reason
and protracted wg efforts suffer the danger of losing whatever window
is relevant.  They also wear out wg members.

It is not uncommon for a working group to have a number of members who
provide highly detailed feedback at every stage of the specification.
Sometimes, the feedback is wonderful.  Sometimes it is nitpicking.  In the
latter case, there often is a debate that ensues (repeatedly) when the
author(s) of the spec do not include every jot and tiddle that was 
offered.  I submit that proper specification of the role of Design
Teams will facilitate resolution of such debates.

At issue here is a very basic change in our theoretical model.  We have
always asserted that "a working group develops a spec."  I claim that that
is rarely true and that sub-sets of working groups develop the spec,
with guidance, contribution and consent of the working group.  The wg
keeps the design team honest and on track.  But the design team does the
core work.

I claim that the difference between our mythology and our reality is 
the cause of complaints about "mafias" and that it is about time we 
deal with it explicitly, so that we can settle on the appropriate 
rights and limitations of the parties.

Dave

P.S.  I believe that the core of Stef's observation about change control
is correct.  Design Teams report to working groups and design teams 
must be responsive to working group consensus.