Subject: RE: alarm definitions

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 15 Mar 2001 19:09:33 -0600

> From: Rutt, T E (Tom) [mailto:[email-masked]]
> 
> Tammy Ferris writes
> 
> >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.
> ---------------
> 
> I agree.   The definition of fault should be as tammy states. 
>  This does not
> change anything
> in the MIB.
> 
> The definition of alarm is not that important, but I tend to 
> think we can
> relate it to "potential
> fault indication" or something like that.  Maybe we just can let the
> definition be loose.

	Awww, for Pete's sake!

	The definiton of "alarm" is the only thing that matters here!  It's
the thing we're trying to model!  All these definitions were brought about
in an effort to clarify the difference between "alarm" and "notification",
which is thus:  notifications represent instantaneous things, and alarms
represent things which have a duration.  All the other definitions of
events, faults, etc. can (and should, given the confusion that they have
generated just within this group) be discarded.

> I  generally like the Dave Perkins mib, but I note He is also 
> using the
> integer probable
> cause, like the Nortel MIB
> 
>    SnmpItuAlarmProbCause ::= TEXTUAL-CONVENTION 
>        STATUS      current 
>        DESCRIPTION "The probable cause of the alarm as 
>                    specified in [X.733] and [X.736]. 
>                    <expand this>" 
>        SYNTAX      INTEGER { 
>                    other (1), 
>                    adapterError (2), 
>                    applicationSubsystemFailure (3), 
> 
> I think this is problematic.  Either use a string, or an 
> ObjectIdentifier,
> for greater flexibility
> is needed than can be offered by named numbers hard coded in the
> specification of the MIB.

	OID: maybe

	String: NO NO NO NO NO!  I don't even want to think about all the
hullabaloo over whether they're case sensitive strings or not, what encoding
we use, whether a tab character is differentiated from a space, etc.  There
is no need for this much flexibility.

	Also, if we want to sort (and ARC) on severity, integer is the best
way to go.  I was thinking about this recently, and I'd like to have:

	clear:           0
	informational:  25
	indeterminate:  50
	warning:       100
	minor:         150
	major:         200
	critical:      250

	this would permit (non-ITU) users to choose appropriate numbers for
finer-grained severity levels while still being amenable to a simple sort
for severity ranking and single compare for ARC filtering.  Sound good?

> Look forward to talking about this at the meeting.

	Ouch.  I won't be there.  Someone carry the fight there for me,
please.

	;-)

/|/|ike

---

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

Mike,
Is it the goal of this group to create new and different definitions for old
terms?

It seems to me that the idea of the event pre-processing function defined in the
ITU is missing from our discussions and a mapping of that 'framework' to an SNMP
interface.

As I understand the ITU definitions, instantaneous nor any concept of
time/duration is associated to the definition of a notification.  It is simply
an unsolicited message sent from a managed object.

I cannot support a definition of an alarm that requires duration.  It flies in
the face of too many existing implementations and expectations in the Telecom
world.  I have worked with many systems that report system initialization alarms
after the system is fully (re)initialized, and other systems that report certain
significant activities/events as alarms such as automatic gain adjustments,
ranging, dropped calls, etc.  Whether or not a clear is sent for such alarms is
typically implementation specific.

In an SNMP context and as you understand and have defined it, is an alarm logged
or the notification?  Where/how is correlation information identified and
provided?  Does the alarm or the notification trigger an audible and/or visual
alarm?  And so on... I think all of these questions need to be answered.
Tammy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Mar 2001 09:45:55 +0100

>>>>> Ayers, Mike writes:

Mike> Also, if we want to sort (and ARC) on severity, integer is the
Mike> best way to go.  I was thinking about this recently, and I'd
Mike> like to have:

Mike> 	clear: 0 informational: 25 indeterminate: 50 warning: 100
Mike> minor: 150 major: 200 critical: 250

Mike> this would permit (non-ITU) users to choose appropriate
Mike> numbers for finer-grained severity levels while still being
Mike> amenable to a simple sort for severity ranking and single
Mike> compare for ARC filtering.  Sound good?

I tend to disagree unless someone can reasonably explain to me the
difference between the perceived severity values 82 and 83.

The added value of having a perceived severity attribute is IMHO lost
when we allow implementors to choose from a nearly open ended set of
values. In other words, it is IMHO a feature to force implementors to
stick to a limited well defined set of perceived severity levels.

/js

---

From: arif <[email-masked]>
Date: Fri, 16 Mar 2001 18:27:31 +0530

> generated just within this group) be discarded.

Confusuion : why _are_ we comparing alarms and notifications ?

The logic flows thus : Events keep happening in the managed system, and a subset
of these events may be indicative / are indicative of a deviation of the system
from normal behaviour, therefore qualifying as alarms, and the manager needs to
know.He could poll, or could choose to be notified. A notification should
typically be defined for the event nevertheless, though it may end up being
suppressed, discarded, or ignored.

The subset of events that are alarming are system-specific. Ths subset often
changes dynamically, though a sub-subset may be static for a given system.

We now make two assumptions :

a) The set of events that can occur in a system are finite and defined.
b) The events can be given a generic structure of parameters / attributes

we now will be in a position to define alarms and a generic notification to
convey which of the set of alarms have occured.

This , IMHO, is how x.733 defines alarms, and the generic notification
structure.

X.733 definition of Alarm : a notification, of the type defined by this
function, of a specific event. An alarm may or may or may not represent an
error.

And, from Section 7 para 3 of x.733, this : Alarms are specfic types of
notifications concerning detected faults or abnormal conditions.

The definition is neither 'loose' nor 'fatally flawed'  nor inaccurate, and
Sharon made a good beginning by defining a generic notification containing the
source and the severity.
If we accept assumption (b) above, and nail down an event structure ( why not
x.733 , in part or in whole), we can build Sharon's MIB around it, and it should
meet most of the world's needs.

Arif

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 16 Mar 2001 11:14:11 -0800

HI,

The quoted text from X.733 show how it is fatally flawed. It uses
circular definitions.

See other comments below...

Regards,
/david t. perkins

At 06:27 PM 3/16/2001 +0530, arif wrote:
<stuff from mike cut>
>Confusuion : why _are_ we comparing alarms and notifications ?

We are not. Notifications are message types. If writers use terms
with different meanings interchangeably, then there is either 
clarity missing in the definition, or misunderstanding (or worse)
by the writer.

>The logic flows thus : Events keep happening in the managed system,
>and a subset of these events may be indicative / are indicative of
>a deviation of the system from normal behaviour, therefore qualifying
>as alarms, and the manager needs to know.
Yes events occur. However, in describing the system you have to be
very careful to differentiate between transitions between states
and the states. Much of the confusion and flawed logic is due to
this lack of clarity. I find the above description too simplistic,
and do not agree with it.

>He could poll, or could choose to be notified. A notification should
>typically be defined for the event nevertheless, though it may end
>up being suppressed, discarded, or ignored.
First, the definition of each specific bad state must be specified,
which includes specify the objects and their values that identify
(or characterize) the bad state. This part is what many seem to be
missing and instead focusing of how to report that a system is
in a "bad state".

>The subset of events that are alarming are system-specific. Ths
>subset often changes dynamically, though a sub-subset may be
>static for a given system.
Again, confusing state transitions with states.

>convey which of the set of alarms have occured.
No, you first need to define these "bad states".

>meet most of the world's needs.

Just don't agree.

Regards,
/david t. perkins