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

[Randy Presuhn <rpresuhn@dorothy.bmc.com>]

Hi -

> Message-Id: <5.1.0.14.2.20021223174629.02f58120@mail.windriver.com>
> Date: Mon, 23 Dec 2002 17:51:52 -0500
> To: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
> From: Margaret Wasserman <mrw@windriver.com>
> Subject: Re: comments on draft-presuhn-referent-00.txt
> Cc: randy_presuhn@bmc.com, mibs@ops.ietf.org
> In-Reply-To: <200212232123.gBNLN0jq009541@hansa.ibr.cs.tu-bs.de>
> References: <5.1.0.14.2.20021221065432.04602340@mail.windriver.com>
>  <5.1.0.14.2.20021221065432.04602340@mail.windriver.com>
...
> If you were implementing the MIB and the datastructure at the same
> time, implementing reference counts (or automatic clean-up of
> dependent rows) wouldn't be a problem.

Assuming the references are within the MIB module.  This
excludes cases that involves things like interface indexes,
process IDs, user names, and so on.

...
> So, IMO, it is best for the MIB not to place too many constraints
> on the behaviour of the underlying datastructures.
...

Agreed.  This is why I generally prefer MIB designs that do
*not* require automatic clean up or elaborate inter-table
constraints on row creation or deletion.  With the sole
exception of the true AUGMENTS, where there by definition
must be fate-charing, I think it's generally simplest (and
more robust) to just spell out the semantics of a reference
to a non-existant thing.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  SJC-1.3141
 randy_presuhn@bmc.com  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------