[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
> no-op)
> 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
> MIB).

Clarification in another document that does not hold up our work is
great. There are of course other mechanisms in Juegens proposal that
will also help - but down the road. For that reason I like your
suggestions #2.

> 2) Add a scalar to the PM MIB that writes all nonVolatile entries
> 
One thing to be clear on about this is that the only changes we are
talking about are changes within the PM MIB Objects. That is to say we
are simply writing the objects in the scope of the PM MIB, not waiting
for configuration changes that might or might not be activated as a
result of a policy execution. Those objects are defined in other (mostly
private for now) MIB Objects.
/jon

> 
> Steve
> 
> 
> 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
> 

Thanks,
/jon
--

Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/