Subject: Re: disman alarm mib comments

From: "David L. Partain" <[email-masked]>
Date: Thu, 17 Jan 2002 12:05:55 -0500

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:16:04 -0600

I support the idea of having a text string associated with the alarm.  This alarm
information field is optional in telecom but widely used.
Tammy

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