Subject: RE: Notifications != alarms

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 3 Mar 2001 16:18:03 -0500

hi

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]

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

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

Ok.  I can see the value in that, but most implementations are
going to still want a notification to alert the manager in a timely manner.
We can achieve the same thing if we define default alarm notifications,
kind of like the ones Dave wants to use, which get used in the event that
the
notification has not been defined.  You can use these notifications if there

are no applicable notifications already defined, but if there are already
notifications which do what you want, you can set your alarm up to use these

instead. It gives the implementer the flexibility to go either way.

alarmDetailsTable.1 = linkUp, linkUp, (clear)
alarmDetailsTable.2 = linkDown, linkDown, (raise)
alarmDetailsTable.3 = fooTooHot, alarmRaise (raise)
alarmDetailsTable.4 = fooTooSmall, alarmRaise (raise)
alarmDetailsTable.5 = fooJustRight, alarmClear (clear)

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

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

Well, encoding this information in the Notification OID, allows you to
use RFC 2573 to filter on severity and other interesting things.  I've
kind of always preferred more notifications to less, but I've never really
come up with a decent argument for it.

Sharon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Mar 2001 12:41:48 +0100

>>>>> Sharon Chisholm writes:

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

Sharon> Well, encoding this information in the Notification OID,
Sharon> allows you to use RFC 2573 to filter on severity and other
Sharon> interesting things.

Yes, I know. But I am nevertheless concerned that we are now trying to
put all event details into the notification OIDs. I already know MIBs
that can not use RFC 2573 filtering because its too limited. They have
a severity parameter in the varbind - where I think it belongs. They
defined their own filter which allows to handle the severity check.
This is of course far from an ideal situation - but I think this issue
is currently not something the DISMAN WG has to solve. (It probably
belongs to the EOS WG.)

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