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

snmpconf BCP document: Example MIB



There are a number of problems with the BLDG-HVAC-MIB
in the -04 version of the BCP document, arising, I think,
from trying to apply concepts and elements from the
DiffServ and DiffServ Policy MIBs to a significantly
different case.

1. First, a minor issue that looks like it's related to
   the evolution of the MIB through its different
   versions: it's not clear whether the indexing for
   the bldgHVACButtonTable is supposed to be the
   Floor and Office indexes from the bldgHVACTable (this
   is what it actually says), or its own integer-valued
   bldgHVACButtonIndex.  I'm going to argue below that
   a somewhat different version of this table should
   have an integer-valued index.

2. With the table structure currently in the MIB, there
   aren't any reusable configuration parameters.
   Specifically, the configuration parameters in
   the bldgHVACButtonTable aren't reusable because the
   entries in this table also include instance-specific
   read-only gauges and counters.

3. The bldgHVACPolicyTable doesn't add anything.  The
   reason for having a separate policy table in the
   DiffServ case is to provide a pointer to the first
   entry of a template that exists as a RowPointer-
   connected set of entries in the various datapath
   element tables.  There's nothing comparable needed
   in the HVAC case.  That is, there are no connected
   sets of entries that serve as templates.  There
   are just instance-specific (in this case, office-
   specific) entries, and reusable configuration
   entries.

So, here's what I think the MIB should look like:

bldgHVACTable -- contains *all* instance-specific objects
   INDEX {bldgHVACFloor, bldgHVACOffice}
   - bldgHVACFloor
         SYNTAX Unsigned32
         MAX-ACCESS not-accessible
   - bldgHVACOffice
         SYNTAX Unsigned32
         MAX-ACCESS not-accessible
   - bldgHVACHeatOrCool
         SYNTAX HvacOperation
         MAX-ACCESS read-write
   - bldgHVACConfig
         SYNTAX RowPointer
         MAX-ACCESS read-write  -- not read-create
         DEFVAL { zeroDotZero }
   - bldgHVACFanSpeed
         SYNTAX Gauge32
         MAX-ACCESS read-only
   - bldgHVACCurrentTemp
         SYNTAX Integer32 -- might be negative!
         MAX-ACCESS read-only
   - bldgHVACCoolORHeatMins
         SYNTAX Counter32 -- need to think about discontinuities
         MAX-ACCESS read-only

bldgHVACConfigTable -- contains *all* reusable objects
   INDEX {bldgHVACConfigIndex}
   - bldgHVACConfigIndex
         SYNTAX Unsigned32
         MAX-ACCESS not-accessible
   - bldgHVACConfigDescription
         SYNTAX SnmpAdminString
         MAX-ACCESS read-create
   - bldgHVACConfigDesiredTemp
         SYNTAX Integer32
         MAX-ACCESS read-create
   - bldgHVACConfigOwner
         SYNTAX OwnerString
         MAX-ACCESS read-create
   - bldgHVACConfigReusable
         SYNTAX ReusableRow -- Keith's "son of StaticRowPointer"
         MAX-ACCESS read-only
         DEFVAL { reusable }
   - bldgHVACConfigStatus
         SYNTAX RowStatus
         MAX-ACCESS read-create

With this set-up, there's one instance-specific entry in
bldgHVACTable for each office.  If I want to create a
named configuration entry ("Outside office, summer"),
then it goes into bldgHVACConfigTable.  Once this entry
exists, either I (at a management station) or a Policy
Script can go through and make selected offices'
bldgHVACConfig pointers point to it.

Structured this way, I think the MIB will illustrate
very clearly the use of, and proper separation of,
instance-specific objects and reusable ones.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com