Subject: RE: Notifications != alarms

From: Dan Romascanu <[email-masked]>
Date: Thu, 1 Mar 2001 19:18:55 +0200

[Dan]  Hi Juergen,

	I am having a hard time understanding what scares you in the OID
pointer. I do  not expect automated applications to use this pointer, I just
want to build a reference as part of a MIB model that can be extended. I do
not believe that we can build a MIB that covers 90% of the alarm cases
today. Even if we can build it I do not believe that we can build it
comprehensive enough to cover 90% of the alarm cases three or five years
from now. This is why I am looking for a solution that scales, and I
sincerely do not understand your resistance to it.

	Regards,

	Dan

	PS - note that I am working for a telecom company, and the ITU Alarm
MIB does cover for many of our applications. Still, there are cases (more
than 10 % :-)) when the ITU alarms do not apply, or I need to extend them
with specific information. However the generic housekeeping is the same for
all.

	D.

> -----Original Message-----
> From:	Juergen Schoenwaelder [SMTP:[email-masked]]
> Sent:	Thu March 01 2001 18:54
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: Notifications != alarms
>
>
>
> >>>>> Dan Romascanu writes:
>
> Dan> Though one may be critical about the notification design in this
> Dan> example (note that I avoid to use the term 'broken' :-)) the way
> Dan> it works is that alarmDetailsModelPointer will point to the
> Dan> temperatureAlarmMIB. In the temperatureAlarmDetailstable a
> Dan> temperatureAlarmDetrailsType will indicate that this is a
> Dan> zone2/zone3... transition. Querying the model specific current
> Dan> alarms table allows you to detect if certain threshold have been
> Dan> exceeded or not.
>
> I would prefer a model where I can understand alarms sufficiently well
> without having to have knowledge of potentially lots of alarm specific
> MIBs.
>
> Dan> I think that both of you are focusing too much in your analysis
> Dan> in the relationship with the Notification MIB, and are trying to
> Dan> build an argument around the perceived problems of this MIB,
> Dan> without looking seriously at how the modular approach in our
> Dan> proposal can provide more flexibility and is offering a stronger
> Dan> infrastructure for the different alarm types that can show up in
> Dan> real life. I suggest that you leave the Notification MIB aside,
> Dan> read our proposal until the end, and try to see how it can solve
> Dan> the problems.
>
> I prefer to work towards agreement on a single alarm model which is
> just sufficient to cover 90 % of the alarm cases rather than an
> absolutely generic model which can cover 100 % of the cases but makes
> it much harder to use in general. Having to follow pointers into alarm
> specific MIBs scares me. The ITU alarm model is IMHO really not that
> bad as a starting point since at least the telco world seems to be
> able to fit the majority of their alarms into this model...
>
> /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/>
>
>

---

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 1 Mar 2001 13:07:55 -0600

> From: Dan Romascanu [mailto:[email-masked]]

> Though one may be critical about the notification design in
> this example
> (note that I avoid to use the term 'broken' :-)) the way it
> works is that
> alarmDetailsModelPointer will point to the temperatureAlarmMIB. In the
> temperatureAlarmDetailstable a temperatureAlarmDetrailsType
> will indicate
> that this is a zone2/zone3... transition. Querying the model specific
> current alarms table allows you to detect if certain
> threshold have been
> exceeded or not.

	Dan, in one thread you complain that you might have to define some
new notifications to imlement an alarm, yet now you blithely tell me that I
should implement an entire model specific MIB to deploy my alarm?

	I change my vote - the multipart alarm MIB stinks!  Let's just work
on one alarm MIB that's good enough for everyone to use.

/|/|ike

---

From: Dan Romascanu <[email-masked]>
Date: Fri, 2 Mar 2001 12:07:12 +0200

Hi Mike,

We seem to agree. This is what the Alarm MIB did not propose new
notifications. The working paradigm is polling and this is why the main
criteria of analyzing the MIB is to see how a polling management application
gets the information about what alarms are currently set in the system n the
most efficient manner.

Regards,

Dan

> HI,
>
> It should be obvious, that as Mike says...
>
>  A deployed alarm system driven entirely by polling.
>
> This has to be supported first, because you may not receive
> a notification due to:
> 1) rate limiting of notification generation
> 2) notification filtering and/or access control
> 3) network drops
> 4) receiver overload/not available.
>
> Regards,
> /david t. perkins
>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 4 Mar 2001 12:07:59 -0500

<Mike->Dan>

</Mike->Dan>

I see the Alarm MIB + ITU Alarm MIB being sufficient, to use everyone else's
number, 90% of the time.  I don't foresee 300 separate model-specific
alarm MIBs.  I see the definition of new model-specific MIBs for major
alarm management movements.  Perhaps there would be a TL1 Alarm MIB.
Or perhaps the ITU model will be replaced by something else as the model
of choice. Separating the two out gives the flexibility to
	1. Not support the ITU components
	2. Support the ITU components
	3. Replace the ITU components with another major alarm model.

Although some of this could also be done through nicely written
compliance statements, I don't think having two documents adds that
much complexity.

Sharon

---

From: "Ayers, Mike" <[email-masked]>
Date: Mon, 5 Mar 2001 19:41:05 -0600

<Mike->Dan>

	Dan, in one thread you complain that you might have to
define some
new notifications to imlement an alarm, yet now you blithely
tell me that I
should implement an entire model specific MIB to deploy my alarm?

	I change my vote - the multipart alarm MIB stinks!
Let's just work
on one alarm MIB that's good enough for everyone to use.
</Mike->Dan>

<Sharon->Mike->Dan>

I see the Alarm MIB + ITU Alarm MIB being sufficient, to use
everyone else's
number, 90% of the time.  I don't foresee 300 separate model-specific
alarm MIBs.  I see the definition of new model-specific MIBs for major
alarm management movements.  Perhaps there would be a TL1 Alarm MIB.
Or perhaps the ITU model will be replaced by something else
as the model
of choice. Separating the two out gives the flexibility to
	1. Not support the ITU components
	2. Support the ITU components
	3. Replace the ITU components with another major alarm model.

</Sharon->Mike->Dan>

<Mike->Sharon->Mike->Dan>

	You're adding fuel to the fire.

	If there are several alarm MIBs, and support for all of them is
optional, then how is the whole mess supposed to interoperate?

	To clarify:

	I presented a simple example where alarming would be warranted, and
pointed out that the current model would not support my example.  Dan
concurred, saying that a new MIB would be needed to support the example.
You now do not contest any of that, but wish to downplay the consequences.

	Let me "upplay" those consequences:

		1.)  Those whose alarm needs differ in any way from the RFC
models (by your own estimate, 10% of the alarm using community) will be
directed to write their own alarm model subagent to handle the differences.

		2.)  Those who write their own alarm model subagent will
have to find a way to get manager applications to support it.

		3.)  Of those who do not write their own alarm model
subagents, many will find ways to hammer the existing models into some
approximation of the shape they need (remember community strings?).

	I think we can do better than this.

	I am now certain - the multi-headed alarm beast must die.

	I'm having a Highlander vision - we're all headed, slowly,
inexorably, to the Gathering in Minneapolis, where There Can Be Only One.
;-)

<Mike->Sharon->Mike->Dan>