Subject: Fwd: Re: terminology clarification

From: Randy Presuhn <[email-masked]>
Date: Thu, 4 Jan 2001 06:52:33 -0800 (PST)

Hi -

I'm forwarding a posting from Joe Fernandez.  I've added his
new email address to the disman "posters" list.

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

> Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA29172
> 	for <[email-masked]>; Wed, 3 Jan 2001 22:56:17 -0800 (PST)
> Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
> 	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f046t8v24933
> 	for <[email-masked]>; Thu, 4 Jan 2001 00:55:08 -0600 (CST)
> Received: from bert ([203.108.213.166]) by mta04.mail.mel.aone.net.au
>           with SMTP
>           id <20010104065711.MSCZ19873.mta04.mail.mel.aone.net.au@bert>
>           for <[email-masked]>; Thu, 4 Jan 2001 17:57:11 +1100
> X-Sender: [email-masked]
> X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
> Date: Thu, 04 Jan 2001 17:58:20 +1100
> To: [email-masked]
> From: Joe Fernandez <[email-masked]>
> Subject: Re: terminology clarification
> In-Reply-To: <[email-masked]>
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> Message-Id: <20010104065711.MSCZ19873.mta04.mail.mel.aone.net.au@bert>
> 
> At 08:57 AM 03-01-01 -0800, david t. perkins wrote:
> [...]
> 
> >What I, and it looks like many others would like, is the following
> >definition of alarm:
> >
> >Alarm - a persistent error or warning condition. 
> 
> I can't get at the ftp server you listed, to get X.733, but from memory ISO
> called this a Fault. 
> - and called the notification of the fault an "alarm". i.e. Notifications
> have a subset called alarms  - those notifications that provide information
> about fault occurrences or clearings
> 
> (My recall of) ISO's definition seems more intuitive to me.
> 
> >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.
> >
> 
> 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)
> 
> The fact that armed men are currently heading to Lexington is a condition.   
> But the statement "The Regulars are coming out " is an alarm, a member of a
> subclass of notification, and  not a condition.
> 
> 
> >Hope this helps...
> >
> >Regards,
> >/david t. perkins
> > 
> Joe Fernandez
> Kardinia Software
> [email-masked]
> 
> http://www.kardinia.com
> 
>

---

From: Chris Elliott <[email-masked]>
Date: Thu, 4 Jan 2001 16:12:21 -0500 (EST)

I struggled with these terms when writing my book, "Performance and Fault
Management." The definitions of these terms used come from my experience
in managing networks and are meant to fit with accepted SNMP terminology.

The book doesn't use the term "alarm" except in relation to RMON. It
defines an "RMON alarm" as the definition of a condition that, when
satisfied, triggers an "event." I think this could be used as a general
definition of an "alarm."

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."

It defines "fault" as a problem in the network as determined by a
diagnosis of the root cause. Rarely does an SNMP entity or agent have
sufficient knowledge to determine the root cause of an "event" or
"events"--usually only if the "event" is local in scope.

"Faults" are determined by a fault management system or a human network
manager from an active or passive analysis of all notifications received.
And, yes, the network user screaming that "the network is down again"
counts as a notification.

Chris.

> new email address to the disman "posters" list.

Chris Elliott  CCIE# 2013       |         |
Customer Diagnostic Engineer   |||       |||
RTP, NC, USA                  |||||     |||||
919-392-2146              .:|||||||||:|||||||||:.
[email-masked]        c i s c o S y s t e m s

---

From: Joe Fernandez <[email-masked]>
Date: Fri, 05 Jan 2001 14:07:05 +1100

At 04:12 PM 04-01-01 -0500, Chris Elliott wrote:
[...]
>definition of an "alarm."
Chris, I disagree - I still think "alarm" is generally taken to be the
notification not the condition. 

>"events"--usually only if the "event" is local in scope.

Even if this is true today, it may not be true tomorrow. Agents are
becoming more intelligent all the time. The protocol may be Simple
(although even that is debatable nowadays) but the Agents may not be.

Joe Fernandez
Kardinia Software
[email-masked]

http://www.kardinia.com

---

From: Chris Elliott <[email-masked]>
Date: Thu, 4 Jan 2001 23:30:58 -0500 (EST)

Joe,

I'll leave alarm to the consensus of the group.

I agree about agents and intelligence. I believe we have to drive this. We
need to be able to configure devices by telling them what we want instead
of how to do it. An agent that knows enough about it's place in the
network to configure itself on that basis can probably make intelligent
decisions about when something's wrong and how to adapt.

Chris.