Subject: RE: more requirements statements

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Fri, 23 Mar 2001 23:24:00 -0500

Tammy:

		Some clarifications:
		*	Per our Wednesday discussion, 
		Alarm/Condition Severity assignment (AlarmMapping/Condition
severity Profiles)
		are a concept.  We agreed that it is implementation specific
and would not be standardized.
		It is shown in picture that the function existed in the
devices, either pre-determined as
		system default or a vendor specific capability.
		Therefore, I would not make items 1-4 as requirements.

		*	The Condition severity profile is for assigning
condition severity level.  One may want
		to assign different levels to the condition type (e.g. LOS)
to different type of interfaces.

		 On the other hand, AlarmMappingProfile provides a network
administrator a mechanism 
		to remap the severity level based on his/her criteria.  It
is a view (subset) of active alarms 
		presented to the network administrators
		(The escalating or descalating may be applicable here but
not to the condition MIB)

		These two profiles are different and independant.

Anni

> ----------
> From: 	Tammy Ferris[SMTP:[email-masked]]
> Sent: 	Friday, March 23, 2001 5:54 PM
> To: 	disman
> Subject: 	more requirements statements
> 
> 
> Sharon asked me if I could write up requirements we
> discussed relating to severity in Minneapolis.
> 
> Here is my first shot at these.  Please feel free to respond
> with comments/questions/concerns and support/non-support of
> these requirements.
> 
> 1) Alarm/Condition Severity assignments must be
> configurable.  When not configured (no assoc. row in table),
> system defaults will be used but not entered in the
> configuration table (for scalability).
> 
> 2) Alarm/Condition Severity assignments must be configurable
> for each Alarm/Condition per table (type of resource) or per
> row (instance of resource).
> 3) Alarm/Condition Severities shall be able to be modified
> during the life of an Alarm/Condition by either the agent or
> the manager.  In other words, the ability to escalate and
> de-escalate Alarms/Conditions must be supported.
> 4) Alarm/Condition Severities modified during the life of an
> Alarm/Condition must take effect immediately and active
> tables updated accordingly.
> 
> Some discussions were had on the following but not yet
> resolved:
> 1) How to share configuration of severity between
> Alarms/Conditions.... there was even some discussion as to
> whether or not to share but a definite leaning toward
> sharing.
> 2)  Handling of stuck Alarms.
> 
> Sharon - did I cover what you expected?
> Tammy
>

---

From: Tammy Ferris <[email-masked]>
Date: Tue, 27 Mar 2001 10:46:19 -0600

An-Ni,
See comments in-line below.
Tammy

>                 Therefore, I would not make items 1-4 as requirements.

****
I agree with you that the how the default values get assigned does not need to
be addressed and can be implementation specific, as we discussed.

None of my requirements address that.  If they read that way, they need to be
fixed.
****

> to different type of interfaces.

***
Agreed.
****

> not to the condition MIB)

***
We introduced the idea (ITU standards and Telcordia requirements support this
already and I believe Lucent sells equipment to my client that support this) of
a profile to administratively allow a manager change the severity.  What do you
propose should happen to an existing condition, for example, when an operator
decides that AIS should be a warning condition instead of a critical condition?
Or are you saying that an adminstrator should not be able to change default
conditions?

Further, as Sharon pointed out, the concept of escalation and de-escalation is
also used in the RMON MIB.  From my point of view, this is common practice in
many systems that support alarm management and therefore should be discussed and
addressed by this working group.

Whether or not to remap a severity with the alarm mapper was still being
discussed as I understood it.
***

>                 These two profiles are different and independant.

**
Of this, I made no comment.  I think it needs some work to determine whether or
not to make them independent and I believe we left this as an open item.
***