Subject: terminology clarification

From: "David T. Perkins" <[email-masked]>
Date: Wed, 03 Jan 2001 08:57:45 -0800

HI,

It appears to me that there needs to be a little clarification on
terminology before progress can be made. Note that different
management systems have different meanings for the following
terms. However, in SNMP, here is what I believe each term means:

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

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

An SNMP notification message can be used to let a manager know that
an event has occurred. Alternatively, a manager can poll an agent to
determine if an event has occured.

Alarm - a term that is not yet part of the formal SNMP terminology.

What I, and it looks like many others would like, is the following
definition of alarm:

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.

Hope this helps...

Regards,
/david t. perkins

---

From: "Van Der Linde, Harmen, ALNTK" <[email-masked]>
Date: Wed, 3 Jan 2001 12:26:56 -0500

David,

> determine if an event has occured.

So, where do syslog messages fit in this classification?
 
> know that the start or termination of an Alarm has occured.

It seems to me that you referring to an error state, which is probably
a better term than 'level'.

Harmen

---------------------------------------------------
 Harmen van der Linde
 AT&T - Frame Relay Network Mgnt Platform Planning 
 Room C2-3C34
 200 Laurel Ave
 Middletown, NJ 07748
 Work: 732-420-1916 
 Home: 732-706-2838
 Cell: 732-809-3007
---------------------------------------------------

---

From: "Van Der Linde, Harmen, ALNTK" <[email-masked]>
Date: Wed, 3 Jan 2001 13:51:17 -0500

David,

you wrote:
 
> At 12:26 PM 1/3/2001 -0500, you wrote:
> 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. 

Harmen

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 4 Jan 2001 09:11:19 -0500

hi

I think we are all in agreement on the definition of notification
with the exception of whether they are originated from
managed objects or SNMP entities.

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.

Sharon
-----Original Message-----
From: David T. Perkins [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 2:14 PM
To: Randy Presuhn; [email-masked]
Subject: Re: terminology clarification

Randy,

In general, it seems like we are trying to converge. However, I didn't
use your model because SNMP allows SNMP entities other than "agents"
to send notifications to managers. I believe that this is a very
different way of modelling than CMIP/GDMO. 

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

SNMP allows observers of managed objects to send messages in addition
to agents that send messages in response to messages from managed
objects.

Regards,
/david t. perkins

At 10:23 AM 1/3/2001 -0800, Randy Presuhn wrote:

>Hi -
>
>> Message-Id: <[email-masked]>
>> Date: Wed, 03 Jan 2001 08:57:45 -0800
>> To: [email-masked]
>> From: "David T. Perkins" <[email-masked]>
>> Subject: terminology clarification
>> List-Id: IETF disman Working Group mailing list <[email-masked]>
>...
>...
>I think it's more useful to think of "notification" in the CMIP/GDMO
>sense, which is still compatible with the way it is used in the SMI.
>
>A notification is emitted by a managed object.  It may be manifested
>in protocol as a trap or inform.  An agent may create log records
>corresponding to a notification, even if no PDU has been sent.
>
>Maintaining the distinction between what managed objects generate
>(this would show up in AgentX protocol, for example) and what shows
>up on the wire (Traps & Informs) makes describing logging, filtering,
>and alarm handling a lot easier.
>
> Randy Presuhn           [email-masked]

---

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

Hi -

Another forwarded posting from Bob Natale...

 -------------------------------------------------------
 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 VAA29082
> 	for <[email-masked]>; Wed, 3 Jan 2001 21:46:25 -0800 (PST)
> From: [email-masked]
> 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 f045jGn15765
> 	for <[email-masked]>; Wed, 3 Jan 2001 23:45:16 -0600 (CST)
> Received: from 66-44-3-44.s806.apx1.lnh.md.dialup.rcn.com ([66.44.3.44] helo=bnatale.acecomm.com)
> 	by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.16 #5)
> 	id 14E3F9-000724-00 ; Thu, 04 Jan 2001 00:47:19 -0500
> Message-Id: <[email-masked]>
> X-Sender: [email-masked]
> X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
> Date: Thu, 04 Jan 2001 00:55:05 -0500
> To: "David T. Perkins" <[email-masked]>
> Cc: [email-masked]
> In-Reply-To: <[email-masked]>
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> 
> At 1/3/2001:11:57 AM, David T. Perkins wrote:
> 
> Hi Dave,
> 
> >terminology before progress can be made.
> 
> I agree.
> 
> >Note that different management systems have different meanings for
> >the following terms.
> 
> Very true.  That's why it's important -- for the sake of
> clarity -- the know whether we are in the process of establishing
> normative definitions for our own purposes here or trying to
> apply existing definitions from one or more realms.
> 
> >However, in SNMP, here is what I believe each term means:
> >
> 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.
> 
> Agreed.  An "event" in this sense may cause one or more notifications
> to be issued.
> 
> Right.
> Right...and I would suggest that this should be defined as "an SNMP
> notification corresponding to an event which a user has categorized
> as an alarm, for whatever downstream purposes the user may have for
> such a designation"...or better (fewer) words to that effect.
> 
> Again, I believe this overview corresponds closely to what I have
> seen over many years of dealing with OSS-grade fault management
> systems (sometimes involving SNMP, often not).
> 
> 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.
> 
> >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!).
> 
> Cordially,
> 
> BobN
> 
>

---

From: Dan Romascanu <[email-masked]>
Date: Fri, 5 Jan 2001 07:45:07 +0200

> >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."
> >
> Chris, I disagree - I still think "alarm" is generally taken to be the
> notification not the condition. 
> 
	[Dan]  ...and I need to disagree with you, Joe. I do not think that
this is the way that "alarm ... is generally taken". The way we are seeing
alarms in this work comes closer to the stateful conditions whose
transitions may generate the notifications. The management of the states of
alarms is the scope of the work that we want to undertake.

> >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.
> 
> 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.
> 
	[Dan]  We are closer to agreement on this issue. I might add that
faults are not the only possible roots of the alarms. However this is
probably out of the scope of the planned work.

	Regards, Dan