Subject: RE: Notifications != alarms

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 1 Mar 2001 12:50:37 -0500

hi

The extra definition and transmission of alarms/notifications
is precisely what we are trying to prevent by having them
share a name space.

If we create a new naming space, then lots of new alarms MUST
be defined.  If we re-use the naming space new alarms might
be defined.

Proposal #2) has alluded to new notifications to get sent to
notify the management station that an alarm has been raised
or cleared.  Systems are still going to have to send off,
or at least support, notifications as we know it to support
non-alarm based management, MIBs as currently defined, etc.
This is twice the notification traffic and more work for the
device.

I didn't quite get what you were saying/asking in your second
paragraph.

Sharon

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, March 01, 2001 12:02 PM
To: Chisholm, Sharon [CAR:5K32:EXCH]
Cc: [email-masked]; [email-masked]
Subject: Re: Notifications != alarms

>>>>> Sharon Chisholm writes:

Sharon> What we seem to be saying here is that the existing
Sharon> notifications are not necessarily well designed when you start
Sharon> talking about using them as alarms.  One proposed solution is
Sharon> to redefine them in a new naming space.  These new alarms
Sharon> would all have a raise/clear relationship and other things
Sharon> which makes then good alarms.

We have always been careful to be conservative on the number of
notifications we have defined in MIBs. If we go with your proposal,
than I expect that lots of new notifications will be defined just to
be able to use the notification OIDs to create alarms. As a side
effect, we might see lots of additional notifications flying around on
the wire and I am concerned about this (and the effort it takes to
suppress these notifications).

In fact, you are proposing to move more event semantics into the
notification OID, which in the extreme case means to encode the
notification variables in the OIDs. Is this really where we want
to go?

/js

--
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Mar 2001 19:18:25 +0100

>>>>> Sharon Chisholm writes:

Sharon> The extra definition and transmission of alarms/notifications
Sharon> is precisely what we are trying to prevent by having them
Sharon> share a name space.

Sharon> If we create a new naming space, then lots of new alarms MUST
Sharon> be defined.  If we re-use the naming space new alarms might be
Sharon> defined.

If you re-use the notification nameing space, then I guess we need two
notification types for each alarm. What I have in mind (and I guess
Dave Perkins as well) is to treat alarms as something which is
decoupled from notifications so that you can instantiate alarms
without requiring any notification definitions. So if I implement an
XYZ distributed manager or agent, I can just instantiate alarms
without having to first define notifications and perhaps even having
to define and implement an alarm type specific MIB.

<soap>
Some background: We have recently written scripts for our Jasmin RFC
2592 implementation which monitor the health of our systems and
services.  These scripts detect alarm conditions and we have written
an alarm MIB along the ITU model to actually export the alarm records
via SNMP.  We would be happy to adopt a standard solution for that -
but if it requires us to define notifications for all the alarms we
detect in our scripts (or even to introduce new alarm type specific
MIBs), then our interest goes quickly down. We would also love to have
a history of recent alarms since our scripts are actually kind of
mid-level managers that run autonomously most of the time.
</soap>

Sharon> I didn't quite get what you were saying/asking in your second
Sharon> paragraph.

I was trying to say that we currently have notifications that contain
in their objects list the information you need to decide whether this
notification marks the instantiation or clearance of an alarm (or none
of both options). Your model is a strong push to define notifications
in the future which have all this information encoded in the OIDs and
thus you will get lots of new notifications defined where we right now
get away with a single notification definition.

/js