[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf PM MIB Issue #9

I believe Juergen's proposal gives the flexibility that the write can be
done early but it must be complete by the time the button push is
complete in the snmpStorage MIB. In other words, it's like syncing a
file system. Prior to the sync the application knows that things *might*
have been written to disk but there is no guarantee. The sync can't
complete until any unwritten data is written. After the sync the app has
a guarantee that the data is written.

This adapts to multiple strategies, including:
1) Write to nvram immediately on activating the target row (sync is a
2) Every N seconds, look for unwritten rows and write them (sync only
writes rows that have been modified since last interval)
3) Delay writes until sync button is pushed

I also agree with Juergen's point that if an agent did #1 for a given
target table, it wouldn't necessarily add an entry to the snmpStorage
table for that target table. This gives such an agent another option.

My main question is, given that there's no way for Juergen's proposal to
be standardized before the PM MIB, how do we proceed now? We could:

1) Do nothing and wait for the storage-type MIB to clarify the PM MIB in
the same way as it will clarify all other existing use of storageType.
(This doesn't add any dependence on the completion of the storage type
2) Add a scalar to the PM MIB that writes all nonVolatile entries


Wes Hardaker wrote:
> Steve> 2) Add a scalar to the PM MIB that writes all nonVolatile entries
> Steve> Comments?
> I'm not convinced that forcing this upon the implementer is a "good
> thing".  It's entirely possible that some implementations will only be
> able to write immediately, and others will not be able to write until
> some time X later.
> I fail to see what the problem is with the existing storage type
> mechanisms.  If one box must write everything nonVolatile at once and
> another one may not, then it is sort of implementation specific as to
> what saving methodology is used.
> --
> Wes Hardaker
> NAI Labs
> Network Associates