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

Marshall Rose <mrose@dbc.mtview.ca.us> Wed, 02 December 1992 19:09 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14644; 2 Dec 92 14:09 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14635; 2 Dec 92 14:09 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20608; 2 Dec 92 14:10 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14624; 2 Dec 92 14:09 EST
Received: from ppp.dbc.mtview.ca.us by CNRI.Reston.VA.US id aa20560; 2 Dec 92 14:09 EST
Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA09148; Wed, 2 Dec 92 11:07:50 -0800
To: John C Klensin <KLENSIN@infoods.mit.edu>
Reply-To: poised@CNRI.Reston.VA.US
Cc: poised@CNRI.Reston.VA.US, gmalkin@xylogics.com
Subject: Re: Design Teams (was "v 1.2, IETF material")
In-Reply-To: Your message of "02 Dec 1992 13:09:04 EST." <723319744.74040.KLENSIN@INFOODS.UNU.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 02 Dec 1992 11:07:48 -0800
Message-Id: <9145.723323268@dbc.mtview.ca.us>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Marshall Rose <mrose@dbc.mtview.ca.us>

>   There is a natural human tendency on the part of the ad hoc designing/
> drafting groups whom we are glorifying with the label of "design team"
> to believe that, since they have studied the issues carefully and in a
> concentrated way, they have the right answers.  Doesn't mean, usually,
> that their minds cannot be changed but sometimes, especially where
> aesthetic judgements are involved, it may take more than one loop or
> more evidence than would ordinarily be required to get a change.

There may be differences of opinion on significant technical issues, and
the working group process might work to resolve those.  If someone can
make a cogent argument and withstand the counter-arguments, then things
get changed.

However, a larg problem is the fact that a lot of people on working
groups want to micro-engineer everything to death.  There is more
concern about "getting my feature in", than on the impact of the feature
on the system as a whole.  This is how you get "kitchen-sink standards".

>   That is, of course, especially true if design team members are
> involved with prototype efforts or the equivalent that imply investments
> in the particular decisions already tentatively made by the time the
> questions arise.

There is no evidence to support this.  Quite the contrary.  Right now,
the people who have the heaviest investment in SNMP security code are
the people on the SNMPv2 design team.  And yet, it is this very set of
people which has made a proposal for an major overhaul to a portion of
this work, because their *implementation* experience has shown that
there is a much better way of doing things.  Everyone benefits from such
a situation.

/mtr