Subject: more requirements statements

From: Tammy Ferris <[email-masked]>
Date: Fri, 23 Mar 2001 16:54:50 -0600

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: Mon, 26 Mar 2001 17:18:58 -0600

Sharon,
Using this as a model:

     I know this work has not found a home yet, but I
     thought I would
     summarize the requirements we have seen so far:
             1) Mechanism to identify which notifications
     are alarms
             2) Mechanism to identify Raise/Clear
     relationship between
     notifications/alarms
             3) Mechanism to map from notifications into
     ITU alarm definitions
             4) Mechanism to maintain list of active alarms

     5)Mechanism for Alarm Notification Suppression (ARC,
     for example)
     6)Support of Historical Alarm Management

How about the following:
1) Mechanism to configure the severity of a condition  (severity
of cleared not allowed in this context)
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)

Is this more what you are looking for?
Tammy

Sharon Chisholm wrote:

> hi
>
> Actually I was looking for a higher-level
> description of the condition management requirement.
> Also, you mentioned something about modelling on a
> per-instance basis.  I suspect this may be beyond the
> scope, but it would be good to see it on the list and
> decide one way or the other.
>
> If you look at the requirements "email", then you can
> see the level of abstraction I am looking for. (I think)
>
> thanks,
>
> Sharon
>
> -----Original Message-----
> From: Tammy Ferris [mailto:[email-masked]]
> Sent: Friday, March 23, 2001 5:55 PM
> To: disman
> Subject: more requirements statements
>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 27 Mar 2001 12:31:12 -0500

hi

Dan> Sharon gave the example of the Entity MIB - less than fifteen variables
that
Dan> meet 95% of what is needed. Those who know (and remember) history know
that
Dan> it took years to reach this small and efficient solution. Kudos to
Keith and
Dan> Andy. I hope we can be as good as they were in making things simple,
will
Dan> not try to solve all the world problems, and will avoid trying to bring
here
Dan> all the ITU Alarms complexity (which does not solve all the world
problems
Dan> either)

Yes. I'd like to clarify my Entity MIB comment in case it came across wrong.
My
point was how easily people can be scared off even when the solution turns
out to not be complicated (I'm now quite fond of it ;-)).  I'd be afraid
that 
people would pick up the alarm work and think they needed to implement ITU 
modelling,  conditions and alarm suppression and run away and implement
proprietary solutions. It's a challenge we face moving forward to be able to
describe the complex 
solution without scaring away people interested in the simple solution.

Sharon

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 27 Mar 2001 11:21:21 -0800 (PST)

Hi -

> Message-ID: <[email-masked]>
> Date: Tue, 27 Mar 2001 11:11:11 -0600
> From: Tammy Ferris <[email-masked]>
> To: "Huynh, An-Ni (Anni)" <[email-masked]>
> CC: Sharon Chisholm <[email-masked]>,
>         disman <[email-masked]>,
>         "'Dan Romascanu'" <[email-masked]>
> Subject: Re: more requirements statements
> References: <[email-masked]>
...
> 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.
...

I appreciate the insights into the history of the
terminology and the placement of the functionality in the
ITU specifications, which we will *consider* in our work.

However, as WG chair I must draw attention to RFC 2418,
especially page 3, which states: "Participation is by
individual technical contributors, rather than by formal
representatives of organizations."

What position a National Body might have taken in another
standards organization is irrelevant to the IETF.

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

---

From: Dan Romascanu <[email-masked]>
Date: Wed, 28 Mar 2001 09:15:19 +0200

> It makes sense to me that changes in severity assignment should be
> reflected at
> the point where severity is assigned.  In your diagram, I see this
> happening in
> the Condition MIB.
> 
> You and Dan seem to think severity assignment is happening in the Alarm
> MIB.
> Likewise, I would like to understanding why you think so.  Can you provide
> more
> explaination please.
> 
	[Dan]  Hi,

	Let me try to explain my point. 

	When Sharon and I started this work, we saw as a goal building a
scalable architecture, that would allow for management of alarms on a system
that may start from a simple managed device and might extend to complex and
heterogeneous distributed systems. The main problem that we want to solve is
to determine in a fast and efficient manner what alarms are currently
existing in the system, what is their type, severity degree, relationship to
other alarms and possible notifications.

	This is the scope of the basic Alarm MIB. Atop of it one can build
more detailed structure like attaching information specific to the ITU
model, or other models.  The Condition MIB is another module that provides
information  about how and where alarms may be generated. However, it is an
optional module, while definition of severity is basic functionality, and
this is why I think it belongs in the Alarm MIB.

	Doing management of severity both in the Alarm MIB and in the
Conditions MIB seems to bring unnecessary complexity with little gain.
Supporting dynamic severity management is not an agreed goal AFAIK.

	I would like to avoid over-engineering and keep the architecture
scalable, and simple as possible. This is not because I ignore the
complexity of the problem. In real life we deal with the ITU MIB, as well as
with two other different models of alarms, related to Policy Management and
heterogeneous systems involving software applications and hardware
infrastructure. However, in an IETF standard we need to focus on building a
simple and efficient model that is simple and economic to implement in the
smaller systems and provides enough functionality and the ability to scale
for more complex ones. By using this pragmatic approach the IETF SNMP MIBs -
sometimes - succeed to be implemented by vendors and used by customers,
while most other more complex solutions fail.

	Regards,

	Dan