Subject: RE: alarmModelEntry notInService

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 15 Jan 2002 19:21:49 -0500

hi

I'm not sure I fully understand the question.

I think what you are referring to we have been
discussing as either notification suppression
as defined by RFC2573 or alarm suppression
as defined by ARC.  In either of these cases
the suppression is an external factor on the
alarms.

In the case of ARC that uses its own notifications,
then when something is suppressed then no
notification is sent or logged and no active
alarm entry is created.

In the case of notification filter, the active
alarm would get created, but the notification
would not be sent out and would not be logged.

Did that answer your question?

Sharon

-----Original Message-----
From: Stefan Wallin [mailto:[email-masked]]
Sent: Tuesday, January 15, 2002 6:33 AM
To: Disman
Subject: alarmModelEntry notInService

Hi!
Is there a definition of an alarmModelEntry being in state notInService?
Possible interpretations:

1) In conflict with NOTIFICATION-MIB, so I assume wrong
- notifications not sent
- activeAlarmTable NOT updated

2) The entry does not represent a possible alarm:
- notifications sent, (depending on NOTIFICATION-MIB)
- activeAlarmTable NOT updated

best regards Stefan Wallin

---

From: "Stefan Wallin" <[email-masked]>
Date: Wed, 16 Jan 2002 09:03:10 +0100

Hi!
Sharon>Did that answer your question?
No it did not.

My question is how a alarmModelEntry in state notInService shall be
handled by the agent. My guess is that the correct behaviour is my
alternative 2:
activeAlarmTable is NOT updated when the corresponding event occurs.
Of course it does not affect notification sending.

See def of notInService in SMIv2-TC:
- `notInService', which indicates that the conceptual
 	     row exists in the agent, but is unavailable for use by
 	     the managed device

Assuming that interpretation, we have a transactional concern, it is
confusing to make only some of the entries of the same alarmindex out of
service. It should affect all entries with the same alarmModelIndex.

Modified example from draft-4, where an alarm clear entry is outOfService:

 alarmModelIndex                  3
   alarmModelState                  1
   alarmModelNotificationId         linkUp
   alarmModelVarbindIndex           0
   alarmModelVarbindValue           0
   alarmModelDescription            "linkUp"
   alarmModelSpecificPointer        ituAlarmEntry.3.1
   alarmModelRowStatus              notInService(2)
<------NOTE---------
   ituAlarmEventType                communicationsAlarm (2)
   ituAlarmPerceivedSeverity        cleared (1)
   ituAlarmGenericModel             alarmModelEntry.3.1

   alarmModelIndex                  3
   alarmModelState                  2
   alarmModelNotificationId         linkDown
   alarmModelVarbindIndex           2
   alarmModelVarbindValue           down (2)
   alarmModelDescription            "linkDown administratively"
   alarmModelSpecificPointer        ituAlarmEntry.3.6
   alarmModelRowStatus              active (1)
   ituAlarmEventType                communicationsAlarm (2)
   ituAlarmPerceivedSeverity        warning (6)
   ituAlarmGenericModel             alarmModelEntry.3.2

What would be the correct behaviour of the agent in my modified example
above?
best regards Stefan

Sharon

-----Original Message-----
From: Stefan Wallin [mailto:[email-masked]]
Sent: Tuesday, January 15, 2002 6:33 AM
To: Disman
Subject: alarmModelEntry notInService

Hi!