Re: last minute change
Anil Rijsinghani <anil@levers.enet.dec.com> Tue, 11 August 1992 18:42 UTC
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05534; 11 Aug 92 14:42 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05530; 11 Aug 92 14:42 EDT
Received: from babyoil.ftp.com by NRI.Reston.VA.US id aa01271; 11 Aug 92 14:43 EDT
Received: from inet-gw-2.pa.dec.com by ftp.com with SMTP id AA12583; Tue, 11 Aug 92 14:34:22 -0400
Received: by inet-gw-2.pa.dec.com; id AA14929; Tue, 11 Aug 92 11:34:17 -0700
Received: by us1rmc.bb.dec.com; id AA20273; Tue, 11 Aug 92 14:31:20 -0400
Message-Id: <9208111831.AA20273@us1rmc.bb.dec.com>
Received: from levers.enet; by us1rmc.enet; Tue, 11 Aug 92 14:31:34 EDT
Date: Tue, 11 Aug 1992 14:31:34 -0400
From: Anil Rijsinghani <anil@levers.enet.dec.com>
To: enet_mib@ftp.com
Cc: kasten@ftp.com
Apparently-To: kasten@ftp.com, enet_mib@ftp.com
Subject: Re: last minute change
> Mark them as obsolete, not deprecated This certainly appears to be a more appropriate status - however it seems that the presence of these objects doesn't seem to serve any real purpose; given that the objects that went away are listed in one of the sections at the front of the MIB. Additionally, since people usually take Draft Standard a lot more seriously from a deployment standpoint, in my opinion it would be better to clean it up; it would be less confusing. (I imagine lots of people reading it for the first time would just miss the obsolete status in a table of objects which are mostly mandatory.) Plus, then it won't be necessary to issue yet another RFC when it comes time to advance to Full Std. It's a minor point, but my vote would be to remove.. agr
- last minute change Frank Kastenholz
- Re: last minute change Marshall Rose
- Re: last minute change Anil Rijsinghani
- Re: last minute change Donna McMaster
- last minute change Kenneth Virgile
- Re: last minute change Frank Kastenholz
- last minute change Dan Romascanu