Subject: RE: Examples and Potential Delta for Alarm & ITU Alarm MIBs

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 9 Mar 2001 13:49:09 -0500

hi

Sharon> The alarmDetailTable is potential alarms and the idea is to
Sharon> list all the states that are applicable to that alarm.  If you
Sharon> consider alarms as entities having state, previously we had
Sharon> been listing the arrows which transition between the states,
Sharon> where now we are discussing the nodes/states.

Sharon> Would alarmDefinitionTable be a better name?
I'm responding to my own question, but I sort of like
alarmPotentialTable since we also have alarmActiveTable.

Juergen > Well, the model still does not match what I have in mind. I do not
Juergen > think that the alarmDetailTable defines an alarm. It defines a
Juergen > predefined alarm type and state. The actual alarm is listed in the
Juergen > active alarm table which points to the currently applicable
predefined
Juergen > alarm tyep and state, right? Having predefined alarm types may be
Juergen > OK. Mixing them together with a state attribute however concerns
me.

Juergen > Are we really gaining much by having predefined alarm states and
Juergen > having pointers back to that table for the active alarms? 

What you are referring to almost goes back to my original proposal which 
just consisted of active alarms.  We then started asking questions, like
how do we tell what the alarms are and what the raise/clear relationship
is between them. I suppose if we do look at how we have defined alarm
so far, you are correct in saying it is the stuff in the alarmActiveTable
that is actually the alarm.  But, the alarmDetailsTable helps us
understand what alarms and behaviour we can expect to see on a device
so we can easily manage the alarms when they do get raised.

Juergen > Why is the
Juergen > state not just an attribute of the active alarm? What happens if I
Juergen > have a sub-agent which wants to report an alarm? How does the
subagent
Juergen > find the right entry in the alarmDetailTable? Or is it just
throwing
Juergen > in its own one ignoring what is there (which means that the
argument
Juergen > of saving space would not really hold anymore)?

The argument of saving space had more to do with the previous model of
storing all the state transitions instead of the states.

How does a sub-agent know which notifications to send?  I'm not all
that familiar with sub-agents, so I'm not really sure where the
problem would be.

Juergen > Given this, the name should probably be alarmTypeTable and all
state
Juergen > attributes removed...

I'm not sure what the point of the alarm definition if it does
not include the states.

Juergen > But this is not a problem. You can report a NULL value for things
that
Juergen > do not apply and if you are worried about implementation
complexity,
Juergen > then make some attributes not required for conformance. Much
easier to
Juergen > deal with than multiple tables with forward pointers. If you need
to
Juergen > extend the IETF alarm model attributes, then you can augment the
alarm
Juergen > tables with your own proprietary attributes. Can you give a good
Juergen > reason why this would not work?

From a technical point of view, this can also work.  I still prefer
two MIBs, but, to be honest, I'm somewhat flexible on this point.

Sharon

---

From: arif <[email-masked]>
Date: Mon, 12 Mar 2001 10:34:10 +0530

Hi,

I came in late into the discussion, and have a few queries.

<Sharon>

     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>

from another mail,

<Sharon>

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

</Sharon>

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 ?

It seems to me you are saying  that all alarms  _will_  have a source and a
atate (severity ?), and we might as well put them as an integral part of all
alarm
notifications. It’s a good idea, and i suggest we add a few more such ‘must
have’
fields.

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.

Thanks,

Arif

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Mar 2001 16:27:19 +0100

>>>>> Sharon Chisholm writes:

Sharon> What you are referring to almost goes back to my original
Sharon> proposal which just consisted of active alarms.  We then
Sharon> started asking questions, like how do we tell what the alarms
Sharon> are and what the raise/clear relationship is between them. I
Sharon> suppose if we do look at how we have defined alarm so far, you
Sharon> are correct in saying it is the stuff in the alarmActiveTable
Sharon> that is actually the alarm.  But, the alarmDetailsTable helps
Sharon> us understand what alarms and behaviour we can expect to see
Sharon> on a device so we can easily manage the alarms when they do
Sharon> get raised.

I think you either have (a) enough details in the alarm representation
itself so that a manager can find out what it is or you have (b) a
formal definition what the semantics of an alarm are and you just
refer to it. Option (b) requires extensions to the SMI since there is
no concept of an alarm in the SMI. Option (a) is hard to get right.

The current AlarmDetailsEntry uses notification OIDs to identify
alarms, which I have serious problems with since until now,
notifications just serve a different purpose.

Sharon> How does a sub-agent know which notifications to send?  I'm
Sharon> not all that familiar with sub-agents, so I'm not really sure
Sharon> where the problem would be.

The idea of just sending notifications which are then turned into
alarms is not what I want to do (because I believe the concept is
broken and I do not want to formally define lots of new notifications
to report some alarms). All I need is a sub-agent which instantiates
some alarm records when needed. This requires in your proposal that
the sub-agent knows the alarmDetailTable so that it can get the
pointers right. I would prefer if I would not have to go through this,
even if this means some redundant MIB variables when you have lots of
identical alarms (which IMHO should only happen on broken or
mis-configured systems).

/js