Re: Changes for next RFI v2 MIB (draft 10)

Hi -

> From: "Eduardo Cardona" <[email protected]>
> To: "Randy Presuhn" <[email protected]>; <[email protected]>
> Sent: Wednesday, April 14, 2004 9:32 AM
> Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)

... (lots of agreement, questions to the WG, and explanations deleted) ...

>> There is no need for there to be any writeable objects in a table with a
>> StorageType object.  One could also use a "capabilities" object outside
>> the table to report whether this information can be retained. For an
>> example of total over-engineering, one could have a single read-only
>> BITS object with one bit for each of these tables, reporting whether the
>> implementation maintains the data persistently.
> <edo1>
> Any example or I assume all new MIB designs consider the StorageType by
> default.
>
> </edo1>
...

The work with which I am most familiar has been very explicit
about persistence, either mandating it in DESCRIPTIONs or using
StorageType to report / control it as needed.  However, using a
scalar to report capabilities, including persistance behaviour,
has a long history, especially in the rmonmib working group.  For
an example chosen at random, see "hcAlarmCapabilities" in
RFC 3434.

Randy