Re: what do we think about this row destroy

[Andy Bierman <abierman@cisco.com>]

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.

I agree. If the other rowPointers never get changed or deleted,
then this row will never get destroyed.

>opinions appreciated
>Bert 

Andy