Re: what do we think about this row destroy

[Steve Waldbusser <waldbusser@nextbeacon.com>]

"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. Silently ignoring the delete can't be a good alternative.

One really has 3 choices:

1. Returning inconsistent value
2. Deleting known rowPointers
3. Deleting the row and allowing the rowPointers to dangle.

The MIB designer gets to decide based on the peculiar circumstances of
that MIB. If the MIB designer doesn't decide (most don't), then the
lattitude falls to the implementor.

BTW, it's nearly impossible to deterministically avoid dangling
references because you don't always know what is pointing to the deleted
row.
The rowPointer could be in a plug-in Expression MIB module or even on
another system.


Steve