Subject: Some Notes from Alarm Discussions

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 26 Mar 2001 10:06:43 -0500

hi

Here are my notes from the off-line alarm discussions 
relating to the relationship between the problem spaces.

The (Alarm and ITU Alarm) MIBs are not trying to
solve the same problem as the (condition and ARC) MIBs.
Conditions include non-alarm information and are not
persistent for the duration of the problem.

The diagrams in the Alarm MIB slice and dice presentation
roughly describe the data flow between these two problem
spaces. Anni has an updated version which should soon be
available.

It was felt that it would be good for the MIBs to share
common ITU definitions.  The ITU alarm MIB could define
textual conventions which could then be imported by the
other MIBs.

It was felt that both sets of MIBs should define the framework,
but focus in on their portion and refer to the other set for
more details on particular items.

There was not much consensus reached on terminology, although
we have converged on the behavioural differences which should
allow us to move forward.

There was also discussion on whether or not the alarm
profiles/details/model was the same for the conditions as
it was for the active alarm.  It was felt that these would
likely have to be separate, but related.  One possibility
is that the alarmDetailsTable could optionally point to
an alarm profile defined in the conditions MIB for its
non-notification based alarm state transitions.  The feasibility
of this will be best determined when the condition's alarm profiles
are defined.  Tammy agreed to define these and share them with
the group.

Tammy also agreed to send Sharon descriptions of the new requirements
she is introducing, so that Sharon can add them to the requirements
and compliance list.

Open Issues
n) Should you be able to support the ITU Alarm MIB completely
   independently of the Alarm MIB?
n+1) What is the relationship between alarm profiles in the condition
  MIB and alarm details/model in the alarm MIB?
n+2) Which of the new requirements introduced by the conditions and
     ARC work do we want to do?

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

---

From: Tammy Ferris <[email-masked]>
Date: Mon, 26 Mar 2001 17:03:56 -0600

Sharon,

Per your statement:

I thought we agreed to:
Conditions include conditions that are not alarmed.  Conditions,
independent of whether or not they are alarmed, may or may not be
persistent (some models use the term standing conditions for persistent
conditions).  Often transient conditions that are alarmed conditions will
not be explicitly cleared (no clear notification is sent).  As long as
the condition persists, it is visable over the management interface via a
query of the active conditions table.

Tammy