Subject: Questions on disman_alarm_mib

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Tue, 30 Jan 2001 18:08:14 -0500

Hi, Sharon and Dan.
I have quite a few questions regarding the generic alarm mib.
(I'll address the ITU alarm mib separately).

Since I was not involved in the design discussion, I would appreciate
you helping me to understanding the design intent of the mib.
Thanks,

Anni Huynh
[email-masked]
+1 732 615-5402
--------------------------

3.1 Terminology:
	Alarm:  Persistent indication of a fault.   Notification should be
sent...
comments: 
*	For degugging purpose, we may want to receive alarms on
	a transient fault condition.  
*	An user may choose to suppress alarm reporting (notification) of an
	alarm condition.  But, the alarm condition shall be recorded.

******
3.4 Relation to Model Specific Alarm MIB:
Comments:
I would like to see that the  ituAlarm MIB can also be used independently on
its own, and have a rowPointer that point to the generic alarmTable.  
I might misunderstand what you mean by modular architecture.
It appears to me that in order to access an entry of  ituAlarmTable, 
one must query the model neutral alarm list in order to get a model specific
alarm. 
Am I missing something?

******
alarmDetailTable
Questions:
Is this table meant to be a log of all notifications sent from the system?
What do we need to have both alarmDetailNotificationID &
alarmDetailClearNotificationID and
alarmDetailType?
The  OID itself will tell whether is raised (linkdown) or cleared (linkup). 

******
alarmActiveTable and alarmActiveVariableTable 
The objects are also defined in the RFC3014  Notification Log MIB,
nlmLogTable and nlmLogVariableTable.
Why not having a pointer to these tables?

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 31 Jan 2001 08:30:46 -0500

hi

> -----Original Message-----
> From: Huynh, An-Ni (Anni) [mailto:[email-masked]]
> Sent: Tuesday, January 30, 2001 6:08 PM
> To: 'DISMAN WG'
> Subject: Questions on disman_alarm_mib
> Sensitivity: Confidential
>
<clip>
>	alarm condition.  But, the alarm condition shall be recorded.
I think we mean to cover both of these conditions in our definitions.

A transient fault condition is still a fault condition that lasts for
some amount of time, even if it is small.  We likely still need some
tweaking on our definitions.  

The use of the term "should" and not "must" was hoping to cover the cases
where you report the alarm, but don't send out the notification.  Perhaps
we should use the SHOULD and MUST terminology.

> one must query the model neutral alarm list in order to get a model
specific
You can access the information in the ituAlarmTable without first having
accessed the alarmDetailsTable.  The tables have the same indices, so that
allows you to go back if you want.  

Do you see a need for more independence?

> The  OID itself will tell whether is raised (linkdown) or cleared
(linkup). 
The alarmDetailsTable does not log the notifications, but rather shows the
possible alarms that might occur on the system.

Well, the relationship is obvious with linkUp and linkDown, but might not
be for other notifications - especially if the manager is not that familiar
with the product or functionality.  It is not strictly necessary, but a nice
to have.
> Why not having a pointer to these tables?
We have an object which pointed to the corresponding row in
the Notification Log - alarmActiveLogIndex.  If you're asking
why not just have the pointer instead of storing the alarms,
the answer is that the Notification Log may not be supported,
and if it is, it is possible that an active alarm may have been
flushed out of the Notification Log because it is old.

Sharon