Subject: RE: Proposed disman charter addition: alarm tracking

From: "Ayers, Mike" <[email-masked]>
Date: Tue, 2 Jan 2001 17:39:26 -0600

> From: Dan Romascanu [mailto:[email-masked]]

>
> > 	3.)  The Alarm MIB should be maintained by the device
> posting the
> > alarms or by a device which directly or indirectly polls
> such devices for
> > information.  The Alarm MIB must not be maintained by gathering
> > information
> > from notifications, since that is the function of the
> Notification Log
> > MIB.
> >
> 	[Dan]  I am not sure that I can agree with you on this
> - at least
> not at this stage. I think we need to invest some more thinking in how
> mechanism of gathering alarms are to be reflected in this MIB
> (or maybe
> not). During this process we need to clarify relationship
> with Notification
> Log MIB.
<mike>

	I tried to clarify that already, but you didn't comment on it - or I
wasn't clear enough.  Let me try this:

<propose>

	Alarms are not notifications.  Notifications are not alarms.  Alarms
represent persistent conditions.  Notifications indicate transient
conditions.  The requirements for the raising and clearing of alarms are
specific to each alarm.  The Notification Log MIB shall keep track of
previous notifications.  There shall be no storage of previous (cleared)
alarms.

	Alarms and notifications maye be used in concert by the simple
expedient of issuing a notification each time an alarm is raised or cleared.
This supplements the alarm with information from the Notification Log MIB,
which can be used to find out when the alarm was raised and which will
indicate any previous alarms by containing their raise and clear
notifications.

</propose>

	Does this make sense?

</mike>
>
> > 	I think that's enough to start.  You may notice (I did) that the
> > raise/clear mechanism doesn't fit very neatly into my
> vision.  In truth,
> > I'm
> > not sure what the raise/clear is for.  Could someone be so
> kind as to
> > enlighten?
> >
> 	[Dan]  The issue is of keeping states of alarms within
> the device.
> The concepts of raise and clear are a very simple
> formalization of these
> states, which in my opinion works in most of the cases. We
<mike>

	I'm with you there.  I was (unclearly) referring to
alarmDetailsClearNotificationId, which is supposed to point to "the alarm
which clears this alarm" (HUH??!!?).  I cannot reconcile such an object -
clues?

</mike>
> need to consider
> if this needs to be reflected in the MIB and where - especially if we
> separate the model independent and model dependent alarm MIB modules.
<mike>

	I favor leaving only raise and clear states, which are implicitly
represented by the alarm being there or not.  Alarm levels are already
handled by the alarmDetailsPerceivedSeverity object, so there should be no
need for more such information.  Note that there is a "cleared" severity - I
hope this is only intended for reflecting X.733 alarm tables.

</mike>
> 	Note also some text in Sharon's draft about alarms
> management and
> aging within the device.
<mike>

	I have noted the text, but am unable to extract anything from it.
Aging is explicitly not addressed, and the management refers to raise/clear
mechanics, but doesn't illuminate much.  The example in section 8 helps a
little, and looks a bit like what I described as the combination of
notifications and alrms, except that it shows the Active Alarm MIB as
reflecting all notifications, a situation I consider to be undesireable.

	Also, I note that there has been precious little discussion on this
issue, which I think is central to the MIB itself:  what are alarms and how
should they be used?  Contribution from the group at large is rather
important here, I think...

/|/|ike

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 2 Jan 2001 17:47:30 -0800 (PST)

Hi -

> Message-ID: <[email-masked]>
> From: "Ayers, Mike" <[email-masked]>
> To: "'Dan Romascanu'" <[email-masked]>, [email-masked]
> Subject: RE: Proposed disman charter addition: alarm tracking
> Date: Tue, 2 Jan 2001 17:39:26 -0600
...
> 	Alarms are not notifications.  Notifications are not alarms.  

Agreed.

> 	                                                              Alarms
> conditions.  

I disagree.  I might have agreed to something like
"alarms generally correspond to conditions; notifications
typically correspond to events, such as state transitions".

It is possible for a notification in a particular system to
have no manifestation in protocol, or even as a log record.

>              The requirements for the raising and clearing of alarms are
> specific to each alarm.

Is there a requirement to make it possible to manage the set of
alarm types supported by a system?  To describe the conditions
which trigger and clear them?

>                          The Notification Log MIB shall keep track of
...

Rhetorical question: If one were to do this, what value would
the alarm record provide?

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 2 Jan 2001 19:51:37 -0600

hi

> -----Original Message-----
> From: Ayers, Mike [mailto:[email-masked]]
> Sent: Tuesday, January 02, 2001 6:39 PM
> To: 'Dan Romascanu'; [email-masked]

I think we are in agreement, except in terminology.

I consider an alarm to be a type of notification, just as informational
traps are also notifications.  I guess it is the informational traps which
you are referring to as transient.  An alarm is  persistent so long as it is
still occurring.  When they are no longer occurring, they get removed from
the active list. Since alarms are a subset of notifications, they would go
into the notification log, and remain there after they have been cleared.

> which clears this alarm" (HUH??!!?).  I cannot reconcile such an object -
Ok, perhaps not the best wording.  By way of example, if this particular
row in the table relates to the linkDown alarm, then the
alarmDetailsClearNotificationId would point to the linkUp OID.  The rows
for switchIsHot, switchIsReallyHot, switchIsOnFire would all point to
the swithcTemperatureFine OID.  If there is no clear alarm, then this
doesn't point to anything.

> hope this is only intended for reflecting X.733 alarm tables.
I agree.  In my first attempt to split my last draft into two pieces
I had raise/clear state in the generic MIB and the X.733 severity
in the other.

> reflecting all notifications, a situation I consider to be undesireable.
I do just show alarms.  It would be interesting to add an informational
notification to the example to show that the alarm MIB does not reflect it.

> important here, I think... 
I think we are delaying some of that discussion by saying we are going
to do a model-neutral MIB and an X.733 based MIB.  There is a certain
amount I think we are going to have to define and assume to make the 
model-neutral MIB useful though. 

>/|/|ike

Sharon

---

From: Dan Romascanu <[email-masked]>
Date: Wed, 3 Jan 2001 15:27:42 +0200

> .
	[Dan]  The problem is that the Notification Log MIB does not provide
any means of classification of the conditions reflected by alarms, control
of the status of the alarms, and optimization of the storage in the devices
according to the status. Because all these functions are missing from the
Notification Log MIB we feel that there is a need for the Alarm MIB.

> important here, I think...
	[Dan]  I agree, and the further discussions should better clarify
and formalize the definition, for inclusion in the documents.

	Regards,

	Dan

---

From: "Robert Moore" <[email-masked]>
Date: Wed, 3 Jan 2001 08:33:02 -0500

>>   Alarms are not notifications.  Notifications are not alarms.

Now I'm confused about the terminology.  From X.733's
"Additional definitions" section:

  Alarm:  A notification, of the form defined by this
          function, of a specific event.  An alarm may
          or may not represent an error.

If we are talking about X.733 alarms, I don't know how it
could be stated any more clearly that alarms *are*
notifications.  If we're using "alarm" in some other sense,
then hadn't we better define exactly what that sense is, so
that we won't have very different ideas in mind as we read
the charter update / proposed new work item?

By the way, I wasn't able to connect to Dave Sidor's FTP
server just now.   Is the server having a problem, or am I
just having a problem navigating our IBM firewall?

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

---

From: Dan Romascanu <[email-masked]>
Date: Wed, 3 Jan 2001 16:01:05 +0200

> the charter update / proposed new work item?
	[Dan]  We are talking about alarms in a more general sense. This is
the reason for which our work is separated into generic alarms management
objects, and model specific alarms management objects.  X.733 is one alarm
model that we intent to support, but no the only one.  The current
discussion tries to define the concept, and it will be defined in the
resulting documents.  

	The definition that you give is not complete without the context -
what is the referred 'function'?

	Regards,

	Dan

---

From: "Robert Moore" <[email-masked]>
Date: Wed, 3 Jan 2001 09:21:08 -0500

Dan,

The "function" referred to is the Alarm Reporting Function,
i.e., X.733.  So I think that "... of the form defined by
this function ..." is just another way of saying
"... of the form defined by this document...."

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

Dan Romascanu <[email-masked]> on 01/03/2001 09:01:05 AM

To:   Robert Moore/Raleigh/IBM@IBMUS, Randy Presuhn
      <[email-masked]>
cc:   [email-masked]
Subject:  RE: Proposed disman charter addition: alarm tracking

     Regards,

     Dan

---

From: "Golovinsky, Eugene" <[email-masked]>
Date: Wed, 3 Jan 2001 08:44:12 -0600

Hi.

> Sent: Tuesday, January 02, 2001 5:39 PM

I very much agree.

> represent persistent conditions.  Notifications indicate transient

Hmm... Yes. Alarm is a state or condition of the system (I use "system" and
not "device"),
However, I would not consider notification a condition at all. To me it's
rather informational
event notifying about something that has happened. For example, the system
has changed its status
from "Operational" to "Alarm" (whatever status definition means).

> indicate any previous alarms by containing their raise and clear

I agree that Notification Log MIB and Active Alarm MIB could be
complimentary to each other,
but it's not a "MUST" to have a linkage between them, since simply not every
alarm results
in notification.

Thanks,
--Eugene

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 3 Jan 2001 12:17:05 -0500

hi

The following url is working:
	ftp://47.234.32.16/itu_to_ietf/SG4/

It might have been a network hick-up.

Sharon

-----Original Message-----
From: Robert Moore [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 8:33 AM
To: Randy Presuhn
Cc: [email-masked]
Subject: RE: Proposed disman charter addition: alarm tracking

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

---

From: "Ayers, Mike" <[email-masked]>
Date: Wed, 3 Jan 2001 16:09:23 -0600

> From: Randy Presuhn [mailto:[email-masked]]

> the alarm record provide?

	If by "alarm record" you mean the Active Alarm MIB, it would contain
the alarms currently active.  The value of this is simple - the set of
current alarms can be retrieved with a minimal MIB walk, without needing to
download and peruse the entire Notification Log MIB.

/|/|ike