Subject: RE: dynamic text string in alarms (was Re: disman alarm mib comme nts)

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 21 Jan 2002 08:56:24 -0500

hi

Dave> Again, the text string is not for application or machine
Dave> consumption.  It's for a human sitting in front of a screen.
Dave> Even if it's not my job of choice, there are people who do just
Dave> that - sit in front of a machine watching incoming alarms and
Dave> reacting as a human would.

Ok. So this human is sitting in front of a simple manager that only
displays raw notifications, as appose to one capable of producing
meaningful messages? I don't think you are saying that the user
is using the CLI. I think in this case we are not talking about
the difference between humans and programs, but the complexity of
the tools the human is using to view the alarms. You seem to be asking
that the alarm notifications be meaningful in simple, notification-based
systems?  Is that the requirement?

I realize you are asking for support of this in addition to something
better suited for programs, but I'm trying to better understand
the requirement.

Sharon

---

From: David Partain <[email-masked]>
Date: Mon, 21 Jan 2002 15:06:35 +0100

Hi Sharon,

Sharon wrote:

> meaningful messages?

I guess it is somewhat analogous to doing

  tail -25f /var/adm/messages

on some machines.  It's not very interesting, but there are
going to be people who do it and it's sometimes the fastest
way to know something happened.

> I don't think you are saying that the user
> is using the CLI.

You're correct.

> I think in this case we are not talking about
> the tools the human is using to view the alarms.

Perhaps that's true.  I realize that the information may be
available in other ways by doing various kinds of processing.
This is just to short-circuit that.

Get it on the screen -- fast.

> You seem to be asking

I think so, yes.

> better suited for programs, but I'm trying to better understand

Thanks.  I think you understand what I'm after.

Cheers,

dlp

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 21 Jan 2002 07:48:23 -0800

HI,

While I understand that there are organizations that don't support
their employees with usable tools, catering to them is something that
I don't support.

If the model is that the only tool that is available is the basic
notification receiver that uses MIB information to translate the OIDs
that identify OIDs variables in the varBind list to text, and
writes these and associated values to a file, then I say, get
some tools that are not 10+ years old.
At minimum, you need to move away from MIB tools that only do
OID to "descriptor" translation, and upgrade to ones that know
how to decode index values of variables.

Any tool has at minimal got to be custom written to efficiently monitor
the "alarm logs" so that it can efficiently manage the alarm state
of the device.

Has the team that you are working with ever written a sophisticated
alarm management (and device state management) system before? Do they
have members with previous SNMP experience?

Does the team have a model for alarms? If so, what is it? Does it
match the alarm model specified in the documents?

Does the team you are working with understand the difference between
events and alarms? Do they understand the difference between alarms
based on "standing conditions" and "incidence conditions"?

This area of "network management" is difficult due to the
conflicting requirements, terminology, and models. I wish
the best for the team because it is truly difficult to
do a good engineering job unless you have a big budget and
an engineering team with the right mix of skills and
experience.

>Thanks.  I think you understand what I'm after.
Regards,
/david t. perkins

---

From: David Partain <[email-masked]>
Date: Tue, 22 Jan 2002 08:53:54 +0100

Hi all,

> their employees with usable tools, catering to them is something that

I personally don't feel that I am in a position to dictate to
customers how they should or should not do things.  If people
want to configure their boxes using a CLI, I provide the tools.
If they want to use COPS, I use the tools.  If they want to
use SNMP, I provide the tools.  If they want to see their
traps immediately on the screen in a simplistic way, I provide
the tools.  If they want a "sophisticated alarm management
system", I provide the tools.

Whether the working group wants to "cater to them" or not,
we'll certainly have to provide the tools.

Besides, it's not about simple and stupid managers:

 - it is about intelligent agents
 - it is about information loss

When an alarm state change occurs in the agent, information
about the alarm state change and contextual information must
be squeezed into the available objects in the notification.
In many cases not all relevant information can be put into
the typed information that is targeted at automated tools.

After all expensive, automated, fancy alarm correlation, etc. in
the alarm mgmt app, sometimes the user wants to see the details
about a discrete event, and it is very hard for the mgmt app to
infer/guess what really happened within the device if the device
did not provide this info when it occurred.  No information
should get lost anywhere in the chain.  Of course, there are
other tools/ways to help solve this problem, but this is one
way to do so.

> have members with previous SNMP experience?

Of course.  I think it's safe to say that alarms are something
that the telco world knows something about.  I also think
it's safe to say that my employer as well as its customers
have built/used sophisticated alarm management systems for a
long time.

> based on "standing conditions" and "incidence conditions"?

I'm asking for a readily-displayable text string _in addition
to_ information needed for a "sophisticated alarm management
system".  Nothing more.  I believe this will be useful.  If the
working group doesn't, that's fine, too.  I'll certainly live
through the experience. :-)

I don't see how that somehow implies that someone doesn't
"understand the difference between events and alarms" or doesn't
"understand the difference between alarms based on 'standing
conditions' and 'incidence conditions'".  That seems a stretch.

Cheers,

dlp