Subject: RE: Notifications != alarms

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 1 Mar 2001 08:01:20 -0500

hi

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

Couldn't this all be done in the existing naming space?
This gives the implementer the option of NOT redefining
all their notifications if what they have is good enough.
It also gives implementers the option of defining new
notifications which behave exactly like we think alarms
should. A best current practices section could be added
to help design notifications which make good alarms. It's
a little less formal than creating a new naming space, but
the result is more or less the same.

Sharon

---

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

>>>>> 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: Lauren Heintz <[email-masked]>
Date: Thu, 01 Mar 2001 09:03:27 -0800

For legacy notifications, you could just
tack on a new varbind (no change in def)
that points to the appropriate alarm MIB
table.  Just sort of a "Hey, I'm now an
alarm too!" signal for those newer mgrs that
speak the alarm MIB language, and which
is simply ignored by legacy mgrs.

Of course, newer alarm defs could still be designed
to replace the legacy defs (which may or may not
thus become deprecated as a result).  And
if the alarm MIBs are designed correctly,
cognizant mgrs could configure the agent to either
enable the newer notifications in place of the
legacy ones, enable/disable the additional alarm
varbind in the legacy notification, or to send
both the legacy and the the newer alarm notification
side by side.

Even if some agents adopt support of the new
alarm MIBs, but don't support the new varbind
in the legacy notification, they can still
choose to send the duplicated notifications
(and possibly disable all/selected legacy ones).

Just a thought.

Thanks,
Lauren