Subject: description clause alarmActiveTable

From: "Stefan Wallin" <[email-masked]>
Date: Fri, 15 Mar 2002 10:15:19 +0100

Hi!
I think we should improve on the description clause of alarmActiveTable:

alarmActiveTable OBJECT-TYPE
...
          "A table of Active Alarms entries."
      ::= { alarmActive 2 }

We should emphasize the following:
1) It should not depend on traps sent:
Traps may be suppressed by the resources in order not to flood.
Rather it is a mirror of the alarm state of the resources.

2) It is not necessarily empty at coldStart/warmStart.
Alarm states persist may persist irrespective of agent or (sub)system
restart
The agent should audit the resources to populate the table.
A StorageType column is not correct since we do not imply persisten
storage, rather a resource synchronisation.
The text in the example on p 51 is a little bit dangerous:
"       0. At system start, the active alarm table, alarm clear table and
          the notification log are all empty."
Yes, I know it is a example...

--

There is a general discussion needed here as well:
When agents restart I have seen two principles:
1) The agent "resends" its traps for active alarms
2) The agent does not resend its traps but populates activeAlarmTable

I vote for (2)

best regards Stefan

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 18 Mar 2002 13:04:01 -0800 (PST)

Hi -

Some comments as a tecnical contributor....

> From: "Stefan Wallin" <[email-masked]>
> To: "Disman" <[email-masked]>
> Subject: description clause alarmActiveTable
> Date: Fri, 15 Mar 2002 10:15:19 +0100
> Message-ID: <[email-masked]>
...
> Traps may be suppressed by the resources in order not to flood.

This I agree with.

> Rather it is a mirror of the alarm state of the resources.

I don't fully agree with this.  It reflects whether
notification of the existance of an alarmable condition has
gotten past ARC.

> Alarm states persist may persist irrespective of agent or (sub)system

Is persistance mandatory, optional, or contingent?

> The agent should audit the resources to populate the table.

This isn't terribly reasonable using, for example, subagent
technology, where it would make more sense for the subagents
to notify the master agent of any persisting alarm conditions
on (re)boot.

> Yes, I know it is a example...

This text would actually be correct if the implementation model were
one of subagents notifying the master agent on boot of any outstanding
alarm conditions not suppressed by ARC.

...
...

This is a *big* philosphical divide with network-wide
implications.  Historically, the SNMP community has tried
to avoid requiring more "memory" in implementations than
absolutely necessary.  This philosphy strongly favors (1).

 ------------------------------------------------------
 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.
 ------------------------------------------------------