Subject: RE: disman alarm mib comments

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 17 Jan 2002 19:34:16 +0200

This is probably a discussion that started the day the first
notification was sent on the wire. The argument is not about the fact
that users would rather see messages in English (or Swedish, or Hebrew)
rather than OIDs, that might actually include re-directing information.
We should never argue with customers. The question is about how we
implement this. Should we build clear text messages in the agent, or
should we somehow code these messages, use some (quite simple) parsing
SW in the application and refer a text file to present the readable
information to the user.

Am I mistaken, or do you suggest a third way to do it - not only have
the agent send clear readable text, but even define the text as part of
the standard?

I just want to make sure that I do not mis-read you and Stefan.

Thanks,

Dan

> -----Original Message-----
> From: David L. Partain [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 7:06 PM
> To: Sharon Chisholm; [email-masked]; Stefan Wallin
> Subject: Re: disman alarm mib comments
> 
> 
> Greetings,
> 
> I don't believe I have seen an answer to some of the issues
> herein, so I'll give it my 2 eurocents.  I've cut out lots of
> things that I think have been discussed elsewhere.  I hope I
> haven't whacked too zealously.
> 
> > <Stefan>
> > But again, traps are displayed in real-time
> > for end-users and it is critical for them to quickly 
> identify the resource.
> >
> > Example: an ifIndex does not tell the typical alarm 
> operator that much...
> > The alarm should say: "Slot 1, port 17, link is down 
> administratively."
> >
> > My recommendation is that the user-friendly var-bind above has this
> > information
> > embedded.
> > </Stefan>
> >
> > I disagree that this should be done in the agent,
> 
> And I agree with Stefan that it should.  The point is that
> there are going to be many settings where a human operator is
> sitting in front of a screen watching incoming alarms.  Not the
> job I want, but there are people that do this.  What Stefan is
> suggesting, and I think it makes great sense, is that the agent
> indeed include some reasonable text string that can be shown to
> this human operator _immediately_ upon receipt of the alarm.
> Whether this is the best way to manage networks or not is
> of course debatable, but there is no question that there are
> definitely users of this technology who would benefit from this.
> 
> > especially if it ends up being done somewhere like a text
> > string. The result of this approach can be seen with fields such
> > as ifName and ifDescription. No agent gives either consistent
> > information or consistent format.
> 
> That certainly is true, but it doesn't really change the fact
> that this would be useful in many cases.  I guarantee that if we
> build boxes that put silliness into such a text string, we'll
> hear about it very quickly from our customers.
> 
> > I've even seen systems where
> > it isn't even consistent for its different ifTypes. My approach
> > is that base information should be given in a consistent, hard
> > to mess up format such as an integer, and the manager does the
> > mapping to get physical components or other information it needs
> > and then displays it in a nice consistent format to the user. In
> > my experience, this is the only way this sort of thing works.
> 
> I obviously cannot argue with your experience.  I can, though,
> make a case for the fact that our customers are definitely going
> to want to have something easily displayable when an alarm
> arrives at the manager.  The text string would allow this to
> happen.
> 
> > <Stefan>
> > Issue 2: index variables in notifications
> > -----------------------------------------
> > Notifications should not be carried by traps, see "7.7.
> > Mapping of the INDEX clause", rfc2578.  If we go for Solution
> > 1 above, sending the alarmModelDescription in the traps,
> > we would implicit send the index variables in the var bind:
> > alarmModelDescription.<alarmModelIndex>.<alarmModelState> =
> > "Toaster burning"
> >
> > The definition would be:
> > alarmRaise NOTIFICATION-TYPE
> >     OBJECTS     { alarmModelDescription,
> >                   alarmActiveResourceType,
> >                   alarmActiveResourceId }
> >     STATUS      current
> > </Stefan>
> 
> > This goes back to how annoying it is that table indices are 
> not accessible
> > in SMIv2. Annoying, Annoying, Annoying. It looks like we 
> should be fixing
> > this in SMIng.
> 
> I don't think it's broken.  I think it's absolutely correct.  If
> I do a get-next on interfaces and get back ifDescr.1 = "blah" why
> it is so hard to figure out that ifIndex is 1.  I think the
> reason for this change (to promote better management applications
> since they don't display indices based on separate objects in a
> response) are very sound.  I certainly hope that SMIng won't
> "fix" this.
> 
> And whether one considers it broken or not, the rule exists in
> RFC 2578, so I think Stefan's correct.
> 
> Cheers,
> 
> David
>

---

From: Tammy Ferris <[email-masked]>
Date: Fri, 18 Jan 2002 10:09:48 -0600

Dan,
In the applications that I am familiar with, this type of text information
is not standardized.   I don't think the text or the format of the text
needs to be standardized as I would think the content would vary depending
on the application.  In the telecom standards, it is up to the agent to
determine what to put in the text description.  In some applications,
operators are allowed to edit the text descriptions that are to be emitted
by the agent.
Tammy

Tammy Ferris
Merkita, Incorporated
+1 (763)577-5945
[email-masked]

---

From: David Partain <[email-masked]>
Date: Mon, 21 Jan 2002 13:24:01 +0100

Hi,

I've changed the subject line to make it clearer what we're
talking about.  I've also removed individual addresses.
Hope everyone that was there before is a disman subscriber :-)

The context for the message is at the end of this message,
but it basically comes down to whether to put a dynamic text
string in notifications or not.  That's what I'm after.

> SW in the application and refer a text file to present the readable

I've spent some time working with Stefan on these questions,
and this mail is a result of those conversations...

As I see it, an alarm notification is used by automated tools
_and_ human operators.  The notifications we send must support
both uses.

Automated tools provide functions such as filtering, sorting,
correlation, categorization, etc. Operators must be given enough
information quickly in order to respond to the alarm. In a
distributed alarm management environment there can be thousands
of alarms per day.

Information needed by automated tools includes:

  - Resource identification
  - Alarm and alarm clear correlation
  - Severity
  - Alarm identification

In my view, human operators need a short text message telling
as much as possible about the source of the alarm.

Let me try to be very concrete in this mail so that it's clear
what we're trying to change.

We want to add a dynamic textual string to the outbound generic
alarmRaise notifications.

1. We need model table information, which gives generic
   information about the alarm.  We can either change
   the indices to accessible-for-notify or send
   alarmModelDescription.  accessible-for-notify seems
   reasonable to me.

2. We need a pointer the resource raising the alarm.  We can
   have the relatively limited way of doing that as is done
   now or use an OID.  I'll send separate mail on this.

3. We need a dynamic string specific to the alarm that is
   intended for consumption by the human operator

To get (1), we should probably use alarmModelDescription
with its static nature.  Nothing else is from that table
is reasonable.  If we want to send the indices, we have to
change the MAX-ACCESS to accessible-for-notify

To get (2), we should use an OID rather than the current scheme
of two integers.  That means replacing alarmActiveResourceType
and alarmActiveResourceId with alarmActiveResourceOID, which is a
pointer to the appropriate resource.

To get (3), we should add an object called
alarmActiveDynamicDescription with a definition something like:

   alarmActiveDynamicDescription OBJECT-TYPE
      SYNTAX      SnmpAdminString
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
       "This object provides a textual description of the
       active alarm.  This text is generated dynamically by the
       notification generator to provide useful information
       to the human operator.  This information SHOULD
       provide information allowing the operator to locate
       the resource for which this alarm is being generated.
       This information is not intended for consumption by
       automated tools."
      ::= { alarmActiveEntry xxxx }

The alarmRaise would then look like this:

   alarmRaise NOTIFICATION-TYPE
    OBJECTS     { alarmModelIndex, -- now a-f-notify
                  alarmModelState, -- now a-f-notify
                  alarmActiveResourceOID, -- or 2 ints as done now
                  alarmActiveDynamicDescription }
    STATUS      current
    DESCRIPTION
       "An instance of the alarm indicated by alarmModelIndex
       has been raised against the entity indicated by
       alarmActiveResourceOID.  alarmActiveDynamicDescription
       provides information that can be displayed for the
       human operator.  When a device detects a fault, it
       shall dynamically generate a text message containing
       dynamic information, dependancies on other states, etc."
    ::= { alarmNotifications 1 }

> the agent send clear readable text, but even define the text as part of

No, not at all.  The text should be generated dynamically by
the agent.  But to be absolutely clear:  we should absolutely
NOT replace the objects that are useful for tools with text
strings.  Automated tools shouldn't have to parse text strings
to get the information they need.

When I'm done with changes, I'll send a pointer to a diff that
shows exactly what I've changed.  The group can then choose to
junk it or not...

Cheers,

dlp