Subject: RE: Comments on the Analysis of Alarm MIBs

From: Dan Romascanu <[email-masked]>
Date: Wed, 28 Feb 2001 14:58:05 +0200

[Dan]  Hi An-Ni,

> Hi.
>
> Some general comments:
>
> *	There is a need to identify and manage conditions in a network
> device.  We need a mechanism
> 	to find out what conditions/alarms are still active, what
> conditions/alarms are fixed (retired).
> 	A list of retired alarms is important.
	[Dan]  Why? You are making assumptions and assertions, with little
argumentation. The main problem that I have with many elements in your
proposal is that you have chosen a new set of requirements, without a full
argumentation about what is the problem and if it needs a solution in the
standards space.

	Is 'retired' synonym with cleared?

	Why is it important that a managed system keeps a record of the
problems that were solved? How long? What if the fix of the problem is not
at the level of the managed system, but at the level of a system higher in
the hierarchy - like fix a topology problem that caused to alarm conditions
in a device?

> *	For managing the conditions the following data is required, and they
> are not necessary ITU-T specific:
> 	-- Location of condition:  physical or logical location of the
> entity.
> 	   (Not the SNMPengineID, snmpContextName)
> 	   The goals is to be able to identify which node, which shelf,
> which circuit pack and/or even which port.
> 	   We have our own format to identify the location, but it is
> preferrable to have common format.
>
	[Dan]  The Entity MIB may be a good solution for the physical
entities.

> *	The need to have a general alarm notification:
> 	 There are plenty of alarm types that has no notification defined.
> That is why the general alarm
> 	notifications are proposed.  Then, we don't need to define a new
> trap/notification for each new alarm
> 	type in the future.
> 	If a system choose to support the general alarm notification, I
> would think the implementation should
> 	be able to ensure that no duplicated notifications are emitted.
> e.g. the linkDownTrap can be mapped
> 	to the general alarm notification.
>
	[Dan]  There are always notifications in place wherever the MIB
authors considered necessary that they are needed. Why not relate the alarms
to the existing notifications, as in our proposal? The general alarm
notification either risks to duplicate the number of traps, or requires a
parallel number of objects to turn the notifications off.

	[Dan]  Regards,

	Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Feb 2001 14:26:12 +0100

>>>>> Dan Romascanu writes:

>> device.  We need a mechanism to find out what conditions/alarms are
>> still active, what conditions/alarms are fixed (retired).  A list
>> of retired alarms is important.

Dan> 	[Dan] Why? You are making assumptions and assertions, with
Dan> little argumentation. The main problem that I have with many
Dan> elements in your proposal is that you have chosen a new set of
Dan> requirements, without a full argumentation about what is the
Dan> problem and if it needs a solution in the standards space.

For what it is worth: I tend to agree with Dave Perkins that a history
of recent alarms is important.

I would like to be able to check which alarms occured while I was
sleeping or while something strange went on in my network. I prefer to
be able to do this without having to collect this data constantly from
all devices in my network just in case I need it.

I think we are getting closer to actually figure out what the
(differences in the) requirements are. I think that is progress and I
thank Dave Perkins for his comparison and for starting this thread.

/js

--
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>