Subject: RE: Some Notes from Alarm Discussions

From: Dan Romascanu <[email-masked]>
Date: Mon, 26 Mar 2001 20:07:29 +0200

> Open Issues
> n) Should you be able to support the ITU Alarm MIB completely
>    independently of the Alarm MIB?
> 
	[Dan]  I do not see how this could work. If the model is defined in
the Alarm MIB, how can we uniquely define the identity of an alarm, and
point to its conditions, for an ituAlarm in the absence of the generic Alarm
MIB. After the discussions last week I became even more convinced that the
modular approach for generic Alarm MIB, and model-specific Alarm MIBs like
the ITU MIB is better architectured. 

	Regards,

	Dan

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 27 Mar 2001 07:49:29 -0500

hi

This is still an open issue.  I am working
with Tammy to update the requirements list
with condition management.  Once this is done
and we fully understand what the requirement
is, then we can decide whether or not it is 
within scope.

Sharon

-----Original Message-----
From: Dan Romascanu [mailto:[email-masked]]
Sent: Tuesday, March 27, 2001 5:03 AM
To: 'Tammy Ferris'; Chisholm, Sharon [CAR:5K32:EXCH]
Cc: [email-masked]
Subject: RE: Some Notes from Alarm Discussions

Hi,

Are 'conditions that are not alarmed' part of the scope of the Alarm MIB?

I think that they are not. My reluctant agreement to support conditions is
based to the fact that looking at conditions on the Alarm MIB interface
helps to understand what is the subsystem source, location, etc. of a
current pending alarm.
 
I do not think that everybody agrees with this. 

Regards,

Dan

> -----Original Message-----
> From:	Tammy Ferris [SMTP:[email-masked]]
> Sent:	Tue March 27 2001 1:04
> To:	Sharon Chisholm
> Cc:	[email-masked]
> Subject:	Re: Some Notes from Alarm Discussions
> 
> 
> Sharon,
> 
> Per your statement:
> Conditions include non-alarm information and are not
> persistent for the duration of the problem.
> 
> 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
> 
>

---

From: Dan Romascanu <[email-masked]>
Date: Fri, 30 Mar 2001 10:11:57 +0200

> Okay Dan,
> I would like to understand better your last point as I am not convinced
> yet.
> Can you further explain what you mean by "we manage conditions because we
> want
> to
> better understand the context, location and transition of current alarms"
> Thanks,
> Tammy
> 
	[Dan]  Okay, Okay, Tammy :-)

	The scope of this work is Alarm management. Conditions are not
specifically defined as part of the goals, and they should be included in
the work only if they help in managing alarms. The need to proof the case
for conditions is yours.

	I did become convinced during the discussions that there is a role
for some of the conditions objects - this is related to localizing alarms
source in a distributed system - including the physical and logical context
localization. I also think that the transition table in the MIB proposals
from An-Ni and Dave may be useful. 

	However, on small systems we might not need all these stuff - as
localization could be derived directly from the current alarms tables and
OIDs of the variables sent in the notifications (like ifIndex for an alarm
corresponding to LinkDown) [Dan]  . This is why I would like to make this
module separate, and not mandatory for all systems.

	I am not sure that I convinced you, but I hope that I explained
better my point.

	Regards,

	Dan

---

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

Hi -

> Message-ID: <[email-masked]>
> From: Dan Romascanu <[email-masked]>
> To: "'Tammy Ferris'" <[email-masked]>,
>         Dan Romascanu
> 	 <[email-masked]>
> Cc: Sharon Chisholm <[email-masked]>, [email-masked]
> Date: Fri, 30 Mar 2001 10:11:57 +0200
> List-Id: IETF disman Working Group mailing list <[email-masked]>
...
> module separate, and not mandatory for all systems.
...

I agree that support for the "arc" and "condition" modules
should be independent of the "active alarm" module.  I thought
that we had informally agreed to this in Minneapolis, both
among the active contributors and in the WG session.

It's unrealistic to think that we could make anything mandatory
for ALL systems, and introducing artificial dependencies between
modules would take us even farther afield.

 -------------------------------------------------------
 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.
 -------------------------------------------------------