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, 04 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
- ftp://ftp.cisco.com/fred/rreq-03.txt Fred Baker
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt David Waitzman
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt David Waitzman
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt bmanning
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt bmanning
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt Robert Elz
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt Scott Bradner
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt Scott Bradner
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt Bill Manning
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt Bill Manning
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt Mike O'Dell
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt Frank Kastenholz
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt Frank Kastenholz
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt Frank Kastenholz
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt Robert Elz
- ftp://ftp.cisco.com/fred/rreq-03.txt Craig A. Finseth
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt David Waitzman
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt barns
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt Marshall Rose
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt David Waitzman
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt David Waitzman
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt David Waitzman
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt bmanning
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt Louis A. Mamakos
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt David Waitzman
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt barns
- Re: ftp://ftp.cisco.com/fred/rreq-03.txt bmanning