Subject: Notifications != alarms

From: "Ayers, Mike" <[email-masked]>
Date: Wed, 28 Feb 2001 18:31:25 -0600

Concerning the identity of alarms:

<DaveP>
Proposal #1 uses the name-space of notification types to
identify (name) alarms. And it appears to double-up on the
indentification. It assumes that alarms are raised (set) and
cleared via a notification.
</DaveP>

<SharonC>
It requires that the notification be defined, but not
that it be sent.  I believe this allows for both the
efficient exploitation of the body of defined notifications
and for the use of non-notification based systems.
</SharonC>

<DaveP>
Proposal #2 uses OID values to identify (name) alarms. These OID
values are in a different name-space than the OID values used
to identify (name) notification-types. The proposal says that
since the SNMP SMI is not extensible to add an "ALARM-TYPE"
construct (macro), that the OBJECT-IDENTITY construct must
be used to define alarm types. (The -00 version of proposal #2
does not provide examples using the OBJECT-IDENTITY to define
an alarm.)
</DaveP>

<SharonC>
Right, so do I need to duplicate all my notifications as alarms?
</SharonC>

	The remainder is my writing (no XML tags).

	The idea of using a notification to identify an alarm at first
seemed attractive, but the more I look at it, the less I like it.  To cut
straight to the heart of the matter, I shall present a slightly modified
version of a real alarm design from a former job.

	Let us consider device X, which is designed to operate in a rack
environment, but may be used in other mountings.  The device contains a
temperature sensor which monitors the internal temperature to prevent damage
to the components due to overheating.  Because temperatures rise and fall
(as opposed to shifting values), we want to warn our operators when things
get dicey.  So we get the following alarm levels:

   -50C  Clear
51C-55C  Warning
55C-60C  Major
60C-     Critical

	We also stipulate that since temperatures above 60C may damage the
product, Critical alarms cannot be cleared - they require a power cycle of
the unit.  Next, we can outline our alarm state transitions:

Clear -> Warning
Warning -> Clear
Warning -> Major
Major -> Warning
Major -> Critical

	Finally, we want to be able to monitor the alarm from  a remote
station.  Although we support the disman's eventual final product - the
Alarm MIB, our manager may prefer to monitor notifications to learn of
transitions and reconstruct the alarm state from those notifications.  So we
define:

temperatureWarning
temperatureMajor
temperatureCritical
temperatureOK

	These notifications are sent when their respective temperature
ranges are entered from either side.  The trend can be determined by
remembering the last notification (starting from temperatureOK)

	Got all that?  Now back to our discussion...

	The above example is of an alarm, temperatureAlarm, with four
distinct levels.  I do not think that it would be appropriate to use any of
the notification IDs to indicate the alarm, since they indicate only a
subset of the alarm.  I feel that it is important to give an OID to the
alarm as a whole.  Therefore I think David Perkins' method is the best.

	Also, this example, as far as I can tell, cannot be fit into the
alarmDetailsTable of Sharon & Dan.  This is (in a way) the M:N case to which
I referred, but really it is a case that I didn't mention (or even think
about) - the multistate alarm as per X.733.

	Of course, since the semantics of the alarmDetailsTable have yet to
be specified, it is entirely possible that it can (in theory) describe the
above, but until I see those details I must consider it broken.

	Finally, concerning the ability to rapidly convert the existing body
of notifications into alarms, I believe that this is something that we do
not want.  The existing notifications were intended as notifications (which
is like someone saying "hey, check this out"), not as alarms (which is like
someone grabbing you while screaming at you).  Few things would compromise
the usefulness of the alarm system more severely than having it flooded with
bad alarms, which is what will happen if every trap is now promoted to
alarm.  Since we are defining something new, it follows simply that some
work will be needed to adapt the existing structure to fit it.  David's
example of the linkDown traps not indicating an alarm unless it is
determined that the link is supposed to be up is one case.  Generally, it
should take some work to design an alarm for a system, in order to make sure
that the alarm fits properly into one's structure, so requiring that bit of
work should not really be a problem.

/|/|ike /+yers
Test Engineer
BMC Software
                                             Beware of geeks bearing gifts.

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 28 Feb 2001 17:36:57 -0800

HI,

Consider Mike's example below changed to have only one notification
type of temperatureZoneChange that is sent when the temperature
changes from one zone to another, and the zones are
  Zone 1  below -50C
  Zone 2  51C-55C
  Zone 3  55C-60C
  Zone 4  above 60C
Some may want to criticize the MIB designer for having only one
notification type and requiring a management app to "read" the
contents of the varBind list to determine the situation. But
such definitions exist, and to assume that you can determine
from the type of notification (without looking at the contents
and maybe even other objects that were not included in the
notification) that an alarm condition is occurring is incorrect.

Regards,
/david t. perkins