Subject: RE: more requirements statements

From: Dan Romascanu <[email-masked]>
Date: Tue, 27 Mar 2001 11:39:34 +0200

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. 

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?

> 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 10:05:22 -0600

Dan,
I don't think I ever said that the ITU solution solves all of the worlds
problems. Please don't put those words in my mouth.

I believe that we should not disregard other industry work in the area of alarm
management in doing this work.  This includes the ITU but is not limited to the
ITU.  I think that it is extremely unwise not to consider other work in this
area.

I care about the ITU standards because they are widely deployed and understood
and contradiction to these translates to costs for my clients.

You should be aware that the term "condition" is not used in the ITU.  An-Ni
proposed this.  I have no objection because it does not contradict the ITU
models or terms as I understand them and matches with documents previously known
as US Telecom Standards/ now known as proprietary Telcordia recommendations.

I was saying we could maybe combine things (e.g. alarm mib and itu alarm mib)
because after our discussions, it looks to me like many functions are not so
different after all.  To me, it looks like we have an alarm core that is
completely independent of application. And then we have areas of extensibility
that depend on application or even on the type of condition being reported
upon.  These areas of needed extensibility also seem common while how the
extensibility needs to be done is not common.

Where severity assignment needs to occur can be debated.  My personal preference
would be to move it as far out as possible from the resource.  This is because
true urgency for resolving any given problem often needs to take into account
information not known locally to a given resource.  Since correlation is not
being supported I could argue that it should not be in the alarm mib either.  So
the question is: how do we handle severity?  Many systems today rely on severity
assignment at the time a condition occurs with the scope of know urgency local
to the resource as sufficient.  I am willing to keep it there to support those
systems and because I know that, if I need to, I can alter/override the value of
severity after the condition is considered an alarm at the NE/EM/Node Level or
at a Network Level/Inter-connected node level and so on in proprietary ways or
standard ways if the standards want to support this.

My comments have been on the models proposed by other organizations and other
people. I don't understand your comment "You seem to be transferring some of the
functions of alarms to conditions.".
Tammy