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

snmpconf The Storage Type MIB

Many of us will have seen the recent discussion about storage that was
on the SNMPCONF list. As a result, I went through the module that
Juergen proposed in:


Bert has suggested that we continue working with the above document and
I have some ideas below. With regard to the SNMPCONF BCP, I think we
should focus on documenting what we aready know (which is what has been
in that document). The new MIB Module that Juergen proposes would be a
formalization of some of that and build for the future in a standard
way. Both good things but I do not want to link the two in the name of
progress for now.

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

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

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

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

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

                1. Place in stable storage
                2. Place in stable storage and put new parameters in operation
                   (note in some systems this will require a reboot).
                3. Activate the changes in operational code right now,
                but do not save in permanent storage. This means on the
                next initialization of the affected sub-system, that
                those parameters that are saved for it locally will be
                used instead of these new parameters that will be lost.
I am aware this is somewhat more complex than the current table, but I
have found all of these functions required to properly manage a system
with SNMP. These semantics are also pretty much the same as they would
be for a CLI. Some changes take place as soon as the CLI command is
input to the system, others require a write to permanent storage and a
system (or sub-system) restart.


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