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

Re: snmpconf PM MIB Issue #9



> 
> >>>>> Jon Saperia writes:
> 
> Steve> This adapts to multiple strategies, including: 1) Write to
> Steve> nvram immediately on activating the target row (sync is a
> Steve> no-op) 2) Every N seconds, look for unwritten rows and write
> Steve> them (sync only writes rows that have been modified since last
> Steve> interval) 3) Delay writes until sync button is pushed
> 
> >>  Option 3) is a bit problematic with the current StorageType. Right
> >> now, applications assume that setting the StorageType to
> >> nonVolatile is enough to put the configuration information into
> >> stable storage, even though it is right now implementation specific
> >> when this actually happens. But it should happen at some point in
> >> time. So only relying on the sync button might confuse existing
> >> applications that do not know about sync buttons. So if 3) is an
> >> option we want, then we probably need to have a new StorageType
> >> kind of TC.
> >> 
> 
> Jon> Option three is an important sematic. To what applications do you
> Jon> refer?
> 
> Lets take a management application which configures SNMPv3 users or
> access control. Such an application (which I assume exists) will set
> the relevant RowStatus objects to nonVolatile and it will be done.
> 
> If now someone implements StorageType objects (e.g. SNMPv3 user and
> access control tables) which are never written to stable storage
> unless you press a magic new sync button, then the manager I was
> talking about will screw up since it can not know that it has to press
> a sync button.
> 
> So if we continue with the existing StorageType TC (which has some
> value since several of our MIBs already use it), then the behaviour
> described in option 3) above does not work - at least for the set of
> already published MIBs.
> 
> (In fact, we probably need a requirement that StorageType descriptions
>  must clearly say how managers can identify sync buttons.)
> 
> /js
> 
Juergen, lets not optimize for the wrong thing. I would rather move
forward with the requried semantic. This is really needed for
configuration and is much more important than protecting any extant
applications.

/jon

> -- 
> Juergen Schoenwaelder      Technical University Braunschweig
> <schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
> Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
> Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
> 
> 
> 

Thanks,
/jon
--

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