Re: what do we think about this row destroy

["Shawn A. Routhier" <shawn.routhier@windriver.com>]

An alternative to inconsistentValue would be to modify the table's such that
the other rowPointers are allowed to point to a row that doesn't exist.  I'm not
familiar with this MIB and don't know if that is possible or practical.  I prefer
such a solution as it avoids other potential problems as well as this one.

However I agree that leaving the row in a stranded state indefinitely is a bad idea.

sar


At 04:13 PM 11/16/02 +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