RE: what do we think about this row destroy

["Dave Thaler" <dthaler@windows.microsoft.com>]

> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> 
> 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.

Was there a good reason in this case why a set to destroy shouldn't 
instead have a side effect of changing/deleting the other
RowPointer objects?

-Dave