Re: what do we think about this row destroy

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

There are a couple of problems with the below. First, another manager
(of the same manager, if forgetful) will never known that the row
will soon depart. Secondly, what happens if a set is made to
active or notInService. Does this clear the "depart after last
ref is cleared" state?

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 
Regards,
/david t. perkins