Re: The Storage Type MIB

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Jon Saperia writes:

Jon> Comments on: draft-schoenw-storage-type-00.txt

Jon> The idea of a global control object such as the one proposed by
Jon> snmpStorageGlobControl is very helpful should be pursued. The
Jon> snmpStorageTable does not have enough information in the
Jon> description clauses for me to comment. There are several concerns
Jon> that I think we should address for control of write operations
Jon> that might be helped with this table:

Jon>      1. The scope of the configuration operation. In many modules
Jon> that I have written for private vendor modules, we have a control
Jon> object whose semantics state specifically which tables or scalar
Jon> objects are 'committed' via setting the control object.  We could
Jon> do this by setting the scope via OIDs in an evolution of either
Jon> the snmpStorageDescr or creating a new Scope object which may be
Jon> better. For a table this would be the base oid of the table.

This is listed as open issue #1 in the ID. We need to work out how
we best identify the scope of a write button.

Jon>      2. Logical groupings of configuration objects. With the
Jon> approach I have taken in private MIB Modules, it is possible to
Jon> associate several tables and scalar objects together under the
Jon> control of a specific MIB object. To mimic this in a standard
Jon> module we might want to be able to group rows in a table together
Jon> so that they can be 'committed' simultaneously.

The question is how much flexibility is desirable and needed. Did you
really have a need to group individual rows rather than complete
tables? In the extreme case, we could end up with a mechanism which
works similar to VACM views. Perhaps we can get away with a simpler
approach which does covers > 98 % of the real-world cases and is much
simpler to deal with.

Jon>      3. We also need to disambiguate between the write to
Jon> permanent storage from activation of the new parameters in the
Jon> operational code. This should also be done in this table. That is
Jon> we need to have semantics:

Jon>                 1. Place in stable storage 2. Place in stable
Jon> storage and put new parameters in operation (note in some systems
Jon> this will require a reboot).  3. Activate the changes in
Jon> operational code right now, but do not save in permanent
Jon> storage. This means on the next initialization of the affected
Jon> sub-system, that those parameters that are saved for it locally
Jon> will be used instead of these new parameters that will be lost.
 
My personal opinion is that solving 3. goes too far. Existing MIBs use
different mechanism to activate rows. Some MIBs overload the RowStatus
TC, other MIBs introduce xxxAdminStatus/xxxOperStatus objects, others
use special purpose objects and some MIBs are totally silent about
activation.

I believe it is possible to make the StorageType (which is used in
many MIBs) more useful by clarifying its semantic and purpose and
providing a relatively simple MIB which can be used by command
generators to commit changes to stable storage. I prefer to stay
focussed and to get this work item done before looking at a much more
complex problem.

/js

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