RE: what do we think about this row destroy

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Thanks all for your reactions. 

It supports my decision to push back on such DESCRIPTION
clauses or mechanisms.

Thanks,
Bert 

> At 04:13 PM 11/16/2002 +0100, Wijnen, Bert (Bert) wrote:
> >mplsFTNRowStatus OBJECT-TYPE
> >   SYNTAX              RowStatus
> >   MAX-ACCESS          read-create
> >   STATUS              current
> >   DESCRIPTION
> >       "Used for controlling the creation and deletion of this
> >        row.  All writable objects in this row may be
> >        modified at any time. Setting this variable to
> >        'destroy' when the MIB contains one or more RowPointers
> >        pointing to it results in destruction being
> >        delayed until the row is no longer used."
> >   ::= { mplsFTNEntry 2 }
> >
> >so a SET to destroy will return a noError. Sofar so good
> >But what about a GET while in delay-destroy mode?
> >
> >I think a better approach would be to return a inconsistentValue
> >which should hint to the manager that some other table entries
> >in other tables need to be deleted first.
> >
> >opinions appreciated
> >Bert