Re: Squashing important ideas (was Re: consensus coming?

["James R. (Chuck) Davin" <[e-mail]>]

Marshall,

The issues that have been raised are not connected with any proposals
that were contributed in response to the call in March 1992. It is
work that was introduced in what should have been the closing moments
of the evolution process, was developed very hastily, and addresses
longstanding problems that were not addressed in any of the baseline
proposals.

The special groundrules that were instituted in the SNMP V2 working
group to assure timely progess were based on the extended open period
for contributions, the availability of strong, widely available,
relatively stable baseline proposals, and the preference of the
community for a single transition rather than many.

These special groundrules did not represent some massive
weather-change in the way that the work of normal IETF WGs is
routinely conducted. In particular, the groundrules for the SNMP
Security WG are those of normal IETF WGs -- not the special
conventions introduced into the SNMPV2 WG. The charter of the SNMP
Security WG characterizes the revisions to the security documents as a
routine part of their maturation in the standards process.

The commitment that Steve Crocker and I jointly made for timely
completion of both the SNMP V2 and SNMP Security efforts was premised
on the work that was represented in the original baseline documents --
which contained between 8-12 fairly contained and well-understood
changes to the security specs that would increase their utility in the
new framework. All this work was mostly wrapped up on schedule (for
which many involved deserve due credit).

We did not tailor the rules to assure quick progress of the baseline
SMP proposals and then extend carte blanche for unlimited reworking of
those proposals and even the addition of new areas of work. And yet
this is exactly the premise on which this lastest episode is based.

I will observe that once again you have eschewed discussion of
substantive technical issues by calling into question my credibility
and motives.  While I'm willing (nay, eager?) to be shot down by sound
technical argument (!= unsupported claims to authority based on
idiomatic "implementation experience"), I am completely unwilling to
see important technical issues dismissed based on specious procedural
tactics, apathy, or exhaustion.

Let me suggest that bashing me technically is your fastest route to
success.

Regards,
Chuck

> To: [e-mail]
> Cc: [e-mail], [e-mail], [e-mail]
> Reply-To: [e-mail]
> Subject: Re: Squashing important ideas (was Re: consensus coming? 
> In-Reply-To: Your message of "Tue, 26 Jan 1993 22:58:05 EST."             <[e-mail]> 
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> Date: Tue, 26 Jan 1993 22:26:54 -0800
> Message-Id: <[e-mail]>
> From: Marshall Rose <[e-mail]>
> 
> For a moment, consider an alternate perspective.
> 
> At some point you just have to ask yourself "how much discussion is
> enough".  Certainly we could have an open-ended process that continually
> refined SNMPv2 until it was all things for all people.  However,
> experience shows that this does not produce useful technology.
> 
> The original call for proposals went out in March of last year.  For a
> six month period, people had a chance to put something together.  There
> have been repeated opportunities for people to formulate proposals,
> modifications, etc.  Some of this input has been productive.  Some has not.
> The moral of the story is that talk is cheap, but workable technology is
> not.
> 
> 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
> them).  I do understand them and I will tell you that from my admittedly
> biased--yet informed--position, they have little chance of resulting in
> fielded, interoperable implementations.  I've already explained why I
> think Chuck is engaging in this disruptive behavior, and you might
> disagree with my analysis.  However, it is a plain fact that his
> proposal has no constituency, nor does it have the force of
> interoperable implementation behind them.  As such, the resolution of a
> situation is a foregone conclusion.
> 
> /mtr