RE: what do we think about this row destroy

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

Shawn writes:

> 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.

The risk then is that later a new row gets created with the same
index, and all of a sudden those old ptrs point to the new row
(which was probably not intended).

Bert

> 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 
>