Subject: RE: more requirements statements

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Tue, 27 Mar 2001 11:10:05 -0500

Hi, Dan, Tammy.
Comments inline.

Anni

> ----------
> From: 	Dan Romascanu[SMTP:[email-masked]]
> Sent: 	Tuesday, March 27, 2001 4:39 AM
> To: 	'Tammy Ferris'; Sharon Chisholm; disman
> Subject: 	RE: more requirements statements
> 
> 
> Hi Tammy,
> 
> You seem to be transferring some of the functions of alarms to conditions.
> This creates IMO unnecessary complexity. From a simple model, which meets
> 95% of what is needed in all practical cases, all this conditions stuff
> adds
> complexity that fills in the 5% that is left. 
[Anni]  I agree with Dan.

> Sharon gave the example of the Entity MIB - less than fifteen variables
> that
> meet 95% of what is needed. Those who know (and remember) history know
> that
> it took years to reach this small and efficient solution. Kudos to Keith
> and
> Andy. I hope we can be as good as they were in making things simple, will
> not try to solve all the world problems, and will avoid trying to bring
> here
> all the ITU Alarms complexity (which does not solve all the world problems
> either)
> 
> Specifically:
> 
> > How about the following: 
> > 1) Mechanism to configure the severity of a condition  (severity of
> > cleared not allowed in this context) 
> 	[Dan]  I do not think that we need to expose the severity of
> conditions. Severity of alarms is enough.
> 
> > 2) Mechanism to configure whether or not the condition is an alarm 
> > 3) Ability to reflect condition escalations and de-escalations accross
> > condition and alarm MIBs as a result of agent's decision to do so or
> > administrative decision to do so (i.e. change in severity or change
> > condition to be alarm condition or not) 
> > 
> 	[Dan]  Again - I do not think that this mechanism should be
> replicated both at the levels of the alarms and of the conditions. I am
> not
> sure that the mechanism of dynamic escalation is needed at all - and if it
> is needed why apply it both for alarms and for conditions?
[Anni]  Again, I agree with Dan.
Tammy, the mechanism of dynamic escalation is not needed for condition at
all.
First of all, I think the dynamic escalation/descalation of a alarm (NOT
CONDITION)
is an overkill.  Why a network admin wants to DYNAMICALLY change the 
severity level of an alarm?

Secondly, even you have a good use case that it is an important feature, it
is really
part of the active alarm module.  There, an user can map the alarm
information to 
something else.  I still think it is overkill.

> > Is this more what you are looking for? 
> 	[Dan]  Much Much More, IMO.
> 
> > Tammy 
> > 
> 	[Dan]  Regards,
> 
> 	Dan
> >  
>

---

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

An-Ni,

> > complexity that fills in the 5% that is left.

Also, ..

> something else.  I still think it is overkill.

****
I am supprised that you have a problem with this.  I would encourage you to talk
to other Lucent folks to understand this need.  In addition, I will try to
explain further here.

To be clear, dynamic allocation is not required.  Some agents do this and some
do not.  Administrative escalations/de-escalations are a different story.

In either case, the model must support the ability to reflect what the current
view of a problem is at any given time.  This is a must or severity becomes
meaningless.

If it is determined that severity is not assigned to a condition, then I can
agree that administrative severity changes do not apply to conditions.

We could not get a US consensus position in T1 that an 'alarm' in ARC did not
have a severity associated with it.  Any 'alarm' in ARC must have the minimum
information available (alarm type (e.g. LOS), time of occurance, and severity).
Alarm is the term used in ARC, but per our slice and dice, should be translated
to condition.  This is a US standards position, as such it cannot be argued
against at the ITU.  I don't know if the same is true of the IETF.
Tammy