Subject: RE: Alarm Notification Structure

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 12 Mar 2001 08:37:04 -0500

hi

<Sharon-1>

     2.2) Generic Alarm Notifications

   alarmRaise NOTIFICATION-TYPE
       OBJECTS     { alarmDetailsIndex,
       alarmDetailsState,
                     alarmActiveEntity }
       STATUS      current
       DESCRIPTION "An instance of the alarm indicated by
       alarmDetailsIndex
     has been raised against the entity indicated by

               alarmActiveEntity."
       ::= { alarmNotifications 0 1 }

</Sharon-1>

<arif>
from another mail,
</arif>

<Sharon-1>

    (I have been giving thought to whether probably
    cause should be part of the concrete instance information, though)

</Sharon-1>

<arif>
from the above snippets, it's clear that source and severity will be an
integral

part of alarm notifications.

Why not add cause and  type to the notifications, and make it complete ?
</arif>
<sharon-2>
There would be a couple issues behind doing this:

1) That would be making the ITU information mandatory. 
   Compliance statements and values like "other" and 0.0 to indicate 
   that it does not apply work for MIB objects, but they really don't for
   trap varbinds. (We could do what Dave did, and have two separate
   traps though.)

2) It would be binding in static information.
   I like to see only information that changes in a trap.
   If I can cache this information and look it up locally when 
   a trap arrives, I'd rather do that.  If we move probably cause
   to be an instance specific parameter, which I think we probably
   need to, then this just applies to event type.

</sharon-2>  

<arif> 
Also, the source of an alarm is likely to be used in alarm correlation, and
entPhysicalIndex may not be granular enough for alarm correlation. Since
physical entities are not the only source of alarms, AlarmActiveEntity,
IMHO,
should be a more generically defined.
</arif>
<sharon-2>
Well, the advantage of using specific notifications is that you 
have the option to bind in any information you want, so you can
cover any situation.

entPhysicalIndex was the best thing I could come up with to cover
the generic case. It does provide some mapping to logical entities
like ifIndex. I've seen generic source information encoded in 
displays strings but that is a manager's worst nightmare. 

Do you have any suggestions for defining alarmActiveEntity?

thanks,

Sharon

<sharon-2>