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.