Subject: alarm definitions

From: Tammy Ferris <[email-masked]>
Date: Thu, 15 Mar 2001 14:46:25 -0600

All,
In reviewing the alarm definition in the Alarm MIB and also
used in the ITU Alarm MIB, I had the following
questions/comments/conerns:
1) The current definition of Fault is:  Lasting error or
warning condition.  I am uncomfortable with the word
lasting.  A fault need not be persistent and it is not clear
what is meant by lasting.  X.733 defines a Fault as the
cause of a malfunction which may be manifest by errors.  I
interpret a fault to be the root cause of possibly many
symptoms using the X.733 definition.

2) The current definition of Alarm is:  Persistent
indication of a fault.  I am not comfortable with this
definition because an alarm may or may  not persist.  In
addition, an alarm, while ideally an probably most
represents a fault (according to X.733 definition of fault -
see comments above), may not be representing a fault.  For
example, threshold crossing alerts are not faults.  In the
ITU, an alarm is defined as a special type of event (or in
other words, an event that has been classified as an alarm
event).  Q.821 specifically states that an alarm event may
be persistent or temporary.  Within the ITU there is
additionally the concept of a current alarm which seems more
compatible with your alarm definition.  A current alarm is
defined as an active alarm which has not been cleared.  Or,
if you like, you could say it is an alarm that has been
raised which has not yet been cleared for better consistency
with your other alarm definitions.

3)The current definition of Alarm Raise is:  The initial
detection of the fault indicated by an alarm.  A
Notification SHOULD be sent on alarm raise.  In this
definition, it is not clear what is meant by initial.  Also,
the term fault should not be used here or should be noted as
an example or one of the possible reasons for an alarm
event.  Finally, whether or not a notification should be
sent is determined by the provisioned severity and by ARC
(at least if we are going for consistency with T1 and ITU)
and other factors possibly such as whether or not a
management system that is able to receive such messages is
connected.  It is not clear to me whether or not
notification behavior needs to be a part of this definition.

4)The current definition of Alarm Clear is:  The detection
that the fault indicated by an alarm no longer exists.   A
Notification SHOULD be sent on alarm clear.  My comments
here are similar to item 3.

5)I know there were several discussions on what ARC
should/should not do and I was not able to participate in
all of them, so I apologize if I am repeating what has
already been said.  I wanted it to be clear that Alarm
Notification Suppression as currently defined is not
equivalent to T1/ITU ARC.  For example, T1/ITU ARC
suppresses the alarm from being logged in the alarm log.
See Figure 7 of the ARC document.  If the intent is
equivalency, I am open to walking through Figure 7 at the
IETF meeting if it would be helpful.
Tammy

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 15 Mar 2001 14:43:32 -0800

HI,

Tammy - there are three different proposals for an Alarm MIB. There
are some major differences and some similarities. It would be helpful
if you read and commented on all three.

Secondly, I believe that the ITU-T alarm model and description as
specified by X.733 is fatally flawed. So, the assumption that we would
try to duplicate it is certainly not one of my goals. Others
do not understand why I believe that it is flawed, and this it
not the place to describe the flaws. Note that Q.821 does not
define "alarm". This is VERY curious.

Thirdly, the terminology used by the X and Q series documents comes
from a CMIP-based management model. Words like "object" from these
documents mean different things in the SNMP-based management model.
A reader of these documents must be fully versed in both the
CMIP-based management model and the SNMP-based management model
to be able to bring concepts and featured from these documents and
apply them to the SNMP-based management model.
 
Fourthly, it has been pointed out on this list and others that the
terms "alarm", "fault", "alert", "notification", "trap", etc
are used by different management systems (in addition to SNMP and
CMIP) and have many times different or fuzzy definitions. People
have been confused by the lack of clarity. Again, I do not believe
that the ITU-T definitions provide clarity, and, thus, I do not
believe in using direct translations of them.

Can you provide references to a consistent and complete definition
of alarms and exception based management? 

Regards,
/david t. perkins

---

From: Tammy Ferris <[email-masked]>
Date: Thu, 15 Mar 2001 23:14:49 -0600

David,
I am working through all the recommended reading for the
meeting next week.  Can you clarify where the 3 different
and competing
proposals are for the Alarm MIB.

I agree that the X.733 model is not perfect.  I would be
interested to
know what you think is/are the fatal flaw(s) of
X.733..off-line if you like. If we can find a better way to
support alarming and provide alarm definitions, I am all for
it.

I am not aware of any single document which provides these
definitions with the necessary detail and clarity needed (A
pity
really).  Assuming that there are none, we are left with
looking through them all and trying to come up with a
consistent (wherever possible) but clearer picture.  I have
no problem with the notion of not taking the ITU definitions
verbatim.  I do, however, have a problem with using the same
term differently (especially in a MIB called the ITU Alarm
MIB or
referencing the definitions as part of ITU extensions).  I
think that would make a difficult situation even more
difficult.

It is not clear to me from your e-mail what your are
opposing in my comments specifically.  Could you please
clarify.

Thanks,
Tammy