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