Subject: Problems with Variables table

From: "David T. Perkins" <[email-masked]>
Date: Thu, 18 Apr 2002 00:02:39 -0700

HI,

The "variables" table is given an inappropriate descriptors and
incorrectly described.
It is really a "varBind" table, since is includes both
the name of variables (an OID value that identifies an instance)
and the associated value. SNMP terminology is to call such
a list a "varBind" list. Also the descriptor for object
alarmActiveVariables should be changed to alarmActiveVarBinds.

A replacement might look like the following...

alarmActiveVarBindTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF AlarmActiveVarBindEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of variable binding that are associated with
        entries in the active alarm table.  The number of entries is
        equal to the sum of the values for all instances of
        object alarmActiveVarBinds."
    ::= { alarmActive 3 }

alarmActiveVarBindEntry OBJECT-TYPE
    SYNTAX      AlarmActiveVarBindEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "An entry in the table of variable bindings for active
        alarms.

        Entries appear in this table when there are variable bindings
        in the varbind list of a notification that caused an
        entry in the active alarm table."
    INDEX       { alarmListName, alarmActiveIndex,
                  alarmActiveVarBindIndex }
    ::= { alarmActiveVarBindTable 1 }

Also note that it is not clear whether the VarBind table includes the
two entries for sysUpTime and snmpTrapOID. (Of course the value for
these two are redundant. So I would say not to include them. However,
it is not clear if they are or are not included).

Finally, it appears to me that it would be useful to associate
variables with the cleared table. If so, this table could be used
as is with a global cleanup and change of descriptors alarmActiveIndex
and alarmClearIndex.

Regards,
/david t. perkins

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Apr 2002 19:49:16 +0300

>     ::= { alarmActiveVarBindTable 1 }
I would not be oposed to such a change, if I was conviced that this makes the intention more clear. Though 'logically' this is a varBind table, the SMI limitations prevent it to be a real varbind, as only one of the objects between ...Entry 4 to ...Entry 12 in the row has a meaningful signification. I would rather go with an improved DESCRIPTION clasue, adding something like ' This table provides a logical table of varBinds expressed within the limitations of SMIv2'.

> it is not clear if they are or are not included).
They are not.

> as is with a global cleanup and change of descriptors alarmActiveIndex
I am not sure that I understand this. Can you describe more specifically the required change.

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 22 Apr 2002 17:28:23 -0700 (PDT)

Hi -

> Subject: RE: Problems with Variables table
> Date: Thu, 18 Apr 2002 19:49:16 +0300
> Message-ID: <[email-masked]>
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "David T. Perkins" <[email-masked]>, <[email-masked]>
...
> > it is not clear if they are or are not included).
...

As a technical contributor, I think we do indeed need sysUpTime,
for the reasons mentioned on the thread regarding the distinction
between the time when the problem was detected and the time when
the active alarm came into being, unless we break that information
into a separate object.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------