Re: comments on draft-presuhn-referent-00.txt

[Margaret Wasserman <mrw@windriver.com>]

Interesting point...

> (a) pointers from table A to table B should be enforced in the sense
>     that you defer row deletions until the references are gone as
>     well
>
> (b) whether you should delete rows when requested to do so leaving
>     dangling pointers around
>
> (c) reject row deletions until there are not pointers anymore,
>     assuming the application understand why you reject a delete
>     requet
>
> (d) require that row deletions cleanup any dangling pointers
>
> All these solutions have some pros and cons and it would be nice if
> the document could expand on this.
Are you suggesting that we come up with a single choice for all
MIB pointers/references?  Or that MIBs should explicitly list which
one they use in a description clause?

Either way, I am concerned that choices (a) or (d) might make it
more difficult to add MIB support to an existing implementation's
data structures.  Choice (a) would require reference counting in
the implementation, which might be difficult to add if not present.
And, choice (d) would require clean-up code in the implementation,
again difficult to add if not present.

Ideally, an agent implementation would have some way to give the
management station more information about its behaviour.  For
instance, a real error message could be returned in choice (b),
indicating, specifically, which other rows/objects need to be
deleted or modified before the indicated row can be deleted.
Unfortunately, SNMP doesn't work that way.

SNMP/SMIv2 doesn't seem to present a good model for handling
complex internally-referential data structures, and I have some
fundamental misgivings about whether the semantics of SNMP are
sufficient to support writes/adds/deletes to complex data
structures at all.

Margaret