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

Re: snmpconf PM MIB Issue #9


I like your idea of creating standard write buttons. I believe this would be 
very helpful.

My first reaction though is that you have made this a bit more than it needs 
to be. What I mean is that I do not think we really need a new mib module with 
a table. Your concern about the complexity of many scalars is well taken. My 
concern is that we need to be able to write at many levels of granularity and 
we could approximate with with the table but it would be another 
'registration' task agent implementors would have to deal with. In the end a 
trade of decision.

All that said, we probably want to separate that discussion from the current 
snmpconf discussion. Would this be an appropriate topic for EOS.  I know that 
people on this list are on that one. We should probably move this good 
discussion there or wherever people think appropriate.


> >>>>> Steve Waldbusser writes:
> Steve> I'm happy to replace storage type with another mechanism but
> Steve> I'd rather not invent it from scratch given that I've never
> Steve> personally had experience with this problem myself. Is there a
> Steve> generally-accepted solution to this problem? A single
> Steve> write-everything-to-nvram button? Or keep (son of) storage-type
> Steve> and add a button that only writes all storage-type=nonvolatile
> Steve> rows?
> Steve> If this happens to just be a DiffServ issue, I hope someone
> Steve> will speak up. The PM MIB is designed to go well beyond
> Steve> DiffServ.
> One can argue that the StorageType definition is vague as it does not
> clearly spell out when new values are written to non-volatile
> storage.
> I know from talking to various people that implementors use different
> strategies to implement StorageType. I started work on an ID which
> "clarifies" the behaviour of the StorageType TC and adds some new MIB
> objects that give you a central set of "write buttons". I never got
> around to post the ID since I wanted to get more feedback first.
> Feedback is welcome and if people think this is a good approach, then
> I am willing to push this forward.
> /js