Re: Time/space issues (was Re: Squashing important ideas

Marshall Rose <mrose@dbc.mtview.ca.us> Wed, 03 February 1993 06:43 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23001; 3 Feb 93 1:43 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22997; 3 Feb 93 1:43 EST
Received: from SLEEPY.TIS.COM by CNRI.Reston.VA.US id aa06051; 3 Feb 93 1:43 EST
Received: from sleepy.tis.com by sleepy.TIS.COM id aa02056; 3 Feb 93 6:35 GMT
Received: from tis.com by sleepy.TIS.COM id aa02054; 3 Feb 93 1:30 EST
Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by TIS.COM (4.1/SUN-5.64) id AA03777; Wed, 3 Feb 93 01:30:19 EST
Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA02580; Tue, 2 Feb 93 22:28:24 -0800
To: mlk%bir.UUCP@mathcs.emory.edu
Reply-To: snmp-sec-dev@tis.com
Cc: snmp-sec-dev@tis.com
Subject: Re: Time/space issues (was Re: Squashing important ideas
In-Reply-To: Your message of "Tue, 02 Feb 1993 14:30:12 EST." <0D15DDF1.p8dfki@bir.bir.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 02 Feb 1993 22:28:21 -0800
Message-Id: <2576.728720901@dbc.mtview.ca.us>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Marshall Rose <mrose@dbc.mtview.ca.us>

> > With respect to the current situation, the process and time pressures
> > have not squashed Chuck's proposals.  They have been on the table for
> > over a month.  The problem is that most people can not even understand
> > his proposals (and I wonder how many could even begin to implement
> 
> Yes it is hard to read, but it makes some important points.

But when pressed, I think you'll be hard pressed to find anyone on the
mailing list who could succinctly list those important points.

In order to a specification can be implemented, people have to be able
to read and understand it.  Chuck's missive does not do well against
this metric.

So, what has Chuck accomplished: a two-month delay.  December and
January are shot.  Not good.  On the plus side, during that time we were
able to streamline the "real" proposal so that it's better.  But, modulo
some typos that people are privately reporting, we aren't making any
additional progress.

We now spend our time waiting for the area director to become immersed
in all this so that when the working group chairs call for concensus,
if Chuck decides to press a "process complaint", it can be dealt with.
(In fairness to the AD, he's had to deal with the PEM debacle, which had
a prior claim on his time.)  Nonetheless, no further technical work is
happening, instead the process is making sure it's covered before
continuing.  Now isn't that a great use of everyone's time?

At this point, the outcome is inevitable.  The only thing open to
question is how long it will take for to get everything lined up to
minimize the delay if a "process complaint" occurs.  Of course, every
day's delay is another day that the community doesn't have SNMPv2. But
somehow, that doesn't seem to enter into the picture.

Chuck Davin could put an end to this right now by realizing that the
deal isn't going to get any better and that he is prolonging the
inevitable.  In fact, I might even appeal to his sense of community
spirit to simply drop the matter.  If he were to do so, we could wrap
this up, last call, and all, by month's end.  Otherwise, the clock keeps
ticking...

/mtr