Subject: RE: Notifications != alarms

From: Dan Romascanu <[email-masked]>
Date: Thu, 1 Mar 2001 15:31:03 +0200

Dave and Mike,

Sharon answered concerning the use of the naming space. I will refer to the
example because ...

...that's an excellent example of the advantage of the modular approach
taken by the Alarm MIB.

Though one may be critical about the notification design in this example
(note that I avoid to use the term 'broken' :-)) the way it works is that
alarmDetailsModelPointer will point to the temperatureAlarmMIB. In the
temperatureAlarmDetailstable a temperatureAlarmDetrailsType will indicate
that this is a zone2/zone3... transition. Querying the model specific
current alarms table allows you to detect if certain threshold have been
exceeded or not.

Note that I did not use the word 'notification' in the precedent paragraph.

I think that both of you are focusing too much in your analysis in the
relationship with the Notification MIB, and are trying to build an argument
around the perceived problems of this MIB, without looking seriously at how
the modular approach in our proposal can provide more flexibility and is
offering a stronger infrastructure for the different alarm types that can
show up in real life. I suggest that you leave the Notification MIB aside,
read our proposal until the end, and try to see how it can solve the
problems.

The unique alarm space is an important - but orthogonal issue.

Regards,

Dan

> -----Original Message-----
> From:	David T. Perkins [SMTP:[email-masked]]
> Sent:	Thu March 01 2001 3:37
> To:	[email-masked]
> Subject:	Re: Notifications != alarms
>
>
> 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
>
> At 06:31 PM 2/28/2001 -0600, Ayers, Mike wrote:
>
>
> >        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: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Mar 2001 17:53:51 +0100

>>>>> Dan Romascanu writes:

Dan> Though one may be critical about the notification design in this
Dan> example (note that I avoid to use the term 'broken' :-)) the way
Dan> it works is that alarmDetailsModelPointer will point to the
Dan> temperatureAlarmMIB. In the temperatureAlarmDetailstable a
Dan> temperatureAlarmDetrailsType will indicate that this is a
Dan> zone2/zone3... transition. Querying the model specific current
Dan> alarms table allows you to detect if certain threshold have been
Dan> exceeded or not.

I would prefer a model where I can understand alarms sufficiently well
without having to have knowledge of potentially lots of alarm specific
MIBs.

Dan> I think that both of you are focusing too much in your analysis
Dan> in the relationship with the Notification MIB, and are trying to
Dan> build an argument around the perceived problems of this MIB,
Dan> without looking seriously at how the modular approach in our
Dan> proposal can provide more flexibility and is offering a stronger
Dan> infrastructure for the different alarm types that can show up in
Dan> real life. I suggest that you leave the Notification MIB aside,
Dan> read our proposal until the end, and try to see how it can solve
Dan> the problems.

I prefer to work towards agreement on a single alarm model which is
just sufficient to cover 90 % of the alarm cases rather than an
absolutely generic model which can cover 100 % of the cases but makes
it much harder to use in general. Having to follow pointers into alarm
specific MIBs scares me. The ITU alarm model is IMHO really not that
bad as a starting point since at least the telco world seems to be
able to fit the majority of their alarms into this model...

/js

--
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>