Subject: Alarm terminology, part 2 (was: terminology clarification)(was: Proposed disman charter addition: alarm tracking)(was: other stuff)

From: Ayers, Mike <[email-masked]>
Date: Thu, 4 Jan 2001 17:52:41 -0600

I apologize in advance to those annoyed by the XML style - it was
the only way I could think of to clearly merge the threads.  All content
from me is new.

<BobN>

>Hope this helps...

Yes, I think it does.  (I hope we can unify the two threads
under which this same topic appears to be under discussion!).

</BobN>
<MikeA>

	A feat which I shall now attempt, before throwing out a few more
bits.  I believe that there is a lot of agreement here, but we seem to trip
over terminology.

</MikeA>

A. TERMINOLOGY

<BobN>

Of course, if we are engaged in an exercise of normative definition
here, then we do not need to refer to the ways these terms (and
a variety of synonyms) are used in practice.

</BobN>
<MikeA>

	This is exactly my intention, and I believe the group's intention.
We are trying to define (or clarify) a model for information modeling and
delivery via SNMP.  It seems the use of the word "alarm" is causing much
alarm - should we use a different term?

	I think we must be careful to avoid confusion over which definition
of a term is in use, which is why Dave Perkins' definition list (and
whatever modifications we agree to) is important to this discussion.

</MikeA>

B.  REACTING TO EVENTS

<DaveP>

Consider the following....
An event occurs. Several observers observe it and send messages to
entities that have subscribed to each observer.
Now, do you want to:
1) log at each observer each event they have witnessed
2) log at each observer the message (and content) each has sent
3) log at each subscriber the message (and content) each has received
4) log the event after reviewing and analyzing messages from multiple
   observers

</DaveP>
<SharonC>

I would say that 2) and 3) are the most interesting from
David's list.  For these, "SNMP Entities" makes for the
simplest discussion.  Also, as a manager, I can't talk to
"managed objects". It's nice to have a vocabulary to describe
what's happening internal to the system, but it would be
nice if it didn't complicate the vocabulary of how things
look out on the network.

</SharonC>
<MikeA>

	I think that 1) should be possible, although it would probably be
rarely used - this is, unless I am mistaken, the Notification Log MIB with
no event filter.  I believe that 4) would occur at a level above what this
group is concerned with, but is enabled by 3).

</MikeA>

C.  DEFINITIONS

C1.  "notification"

<DaveP>

notification - this is a unsolicited message from an "SNMP entity"
               to a manager. (It can be a TRAP, a v2TRAP, or INFORM.)

</DaveP>
<BobN>

I agree, with the exception that Informs were originally envisioned
as a form of "solicited" notification.  Indeed, in systems in which
trap destinations may be configured externally, it may also be argued
that Traps are solicited notifications too.  I guess to be literal
about it I would suggest that notifications are event-driven SNMP
messages as opposed to being Request-driven SNMP messages (aka,
Responses).  I believe this is consistent with and compatible with
you definition of "event", below.

</BobN>
<MikeA>

	Configuring a notification destination is not soliciting an
individual notification; rather, it is expressing interest in an area or
areas in which notification may occur.  Notifications occur even if there
are no destinations configured.  SNMP notifications are in all cases
unsolicited, i.e. no request for a notification precedes the notification.

</MikeA>

C2.  "event"

<DaveP>

event - an occurrence of something. This can be a state (or status)
        change, the crossing of a threshold, or an external input
        to the system

</DaveP>
<MikeA>

	I believe that everyone is happy with this definition.

</MikeA>

C3.  "alarm"

<DaveP>

Alarm - a persistent error or warning condition. An Alarm is a "level"
and not an "edge". However, the start (SET) of an Alarm condition
is an event, and the termination (CLEAR) of an Alarm condition is
also an event. Because the start and termination are events, it
is appropriate that an SNMP notification be used to let a manager
know that the start or termination of an Alarm has occured.

</DaveP>
<BobN>

Hmmm.  I'm still not sold on the "persistent" part...indeed, the
existence of a transitory period demarcated by "start" and "clear"
states seems to argue against "persistence" as a required element
of an alarm.  Indeed, many alarms issued in the OSS space are, in
fact, used to advise of fluctuations of state or tresholds, etc.,
and are often of extremely short duration.  (Hence, well-designed
fault management systems allow the user to define meta-alarms
that deal with repeat-counts-over-time-intervals, for example,
to promote a series of such base level alarms to a more
meaningful level.

</BobN>
<MikeA>

	When I have used "transient" and "persistent" in the context of this
issue I have always used them to mean "lacking duration" and "possessed of
duration", respectively.  In this context your alarms of extremely short
duration are still persistent.

</MikeA>
<JoeF>

You are using two different terms "Alarm condition" and "Alarm". I think
the former is a "level" (= Fault condition) and the latter is (almost) the
"edge" (=notification of state transition to/from fault condition)

</JoeF>
<MikeA>

	I partially agree.  Certainly a ringing bell is not a fire, but a
ringing bell is not a transient condition either.  May I propose some
definitions:

	fault - a persistent error or warning condition.

	alarm - the propogation of information concerning a fault.  An alarm
is a pure information object.  There are two processes (and their inverses)
of interest for an alarm - activation and realization.

	activation - the process of fault detection, information gathering,
and information propogation.

	realization - the receipt of the complete set of information of an
alarm.

</MikeA>

4.  SYSLOG

<HarmenVDL>

> >So, where do syslog messages fit in this classification?
>
> I don't believe that syslog messages are a part of SNMP.

I think you are right :-)

> How do you believe that they should fit in?

The reason why I asked this question is that it seems that
you, together with other working group members, are trying
to define a generic alarm/notification framework using ITU
standards. In this context, it seems appropriate that you
not limit the focus to SNMP but also include syslog notification
mechanism, for example.

</HarmenVDL>
<ChrisE>

It defines "events" are issues or symptoms noticed by an agent and they
can be reported as "notifications." And, yes, syslog is a delivery
mechanism, just as SNMP traps and informs are, for "notifications."

</ChrisE>
<MikeA>

	Would someone more familiar than I with the group's charter please
comment on whether we need to consider syslog?  Could we sidestep the issue
by pointing out that an application could monitor syslog and send out
corresponding traps?

</MikeA>

5.  ALARMS AND NOTIFICATIONS

<MikeA>

	In its current form, the Active Alarm MIB appears to realize alarms
from notifications.  This method probably supports many existing
deployments, and is quite practical.  Several contributors have also seen
alarms as defined by their edge notifications.  However, I do not see this
as the only possible way to realize alarms.  It should be possible for a
device to populate its alarm MIB without notifications, since there are
management environments in which notifications over the wire are
undesireable, and requiring notifications for alarms in devices designed for
such environments is just hoop-jumping.  I am pressing for the decoupling of
alarms and notifications, even though I am well aware that in practice they
will almost inevitably work together.

</MikeA>

6.  DEFINING ALARMS

<MikeA>

	The Active Alarm MIB currently uses the AlarmDetailsTable to
describe what notifications are perceived as alarms, but does not permit
this table to be configured.  I fail to see any reason not to allow
configuration of this table.

</MikeA>

	Okay, that's all for now  (what, you wanted *more*?   ;-)

/|/|ike