[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
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
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 firstname.lastname@example.org