ftp://ftp.cisco.com/fred/rreq-03.txt

"Craig A. Finseth" <fin@unet.umn.edu> Wed, 04 January 1995 15:01 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02473; 4 Jan 95 10:01 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02469; 4 Jan 95 10:01 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa07812; 4 Jan 95 10:01 EST
Received: from norge.unet.umn.edu by venera.isi.edu (5.65c/5.61+local-20) id <AA28963>; Wed, 4 Jan 1995 06:41:12 -0800
Received: by norge.unet.umn.edu (5.65c) id AA25756; Wed, 4 Jan 1995 08:40:55 -0600
Date: Wed, 4 Jan 1995 08:40:55 -0600
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Craig A. Finseth" <fin@unet.umn.edu>
Message-Id: <199501041440.AA25756@norge.unet.umn.edu>
To: djw@bbn.com
Cc: rreq@isi.edu
In-Reply-To: David Waitzman's message of Tue, 03 Jan 95 18:24:15 -0500 <199501032325.AA01817@venera.isi.edu>
Subject: ftp://ftp.cisco.com/fred/rreq-03.txt

	...
   (assuming another version follows this one).  Given these, I suggest
   that mentioning SNMPv2 is reasonable, but conditionally, as in:

       "When SNMPv2 reaches Full Standard, you MUST implement it.  You MAY
       continue to implement SNMPv1 at that point, but you MUST not allow
       use of SNMPv1 to compromise the security constraints imposed by
       SNMPv2".
	...

I would think people would be very uncomfortable _requiring_ the use
of a mechanism that is neither standardized nor widely implemented.

As with any major protocol change, i would expect a period of
improving quality.  This wording appears to mandate a hard cut.

According to this wording, when vendor X does its first new release
after the SNMPv2 becomes standardized, it MUST use SNMPv2 and can not
use SNMPv1 for management.  This means that every network management
package and utility must also be upgraded to SNMPv2 _simultaneously_.
We all know that's a bad idea.

Perhaps something like

	...You MAY provide a configuration option to restore use of
	SNMPv1, or a range of such options to facilitate the
	transition.  However such options MUST default to SNMPv2
	with no compromise.

I think this would achieve the same end goal without breaking every
network in the world along the way...

Craig