Subject: RE: Alarm MIB WG last call

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Apr 2002 20:20:10 +0300

Tammy,
See below.

> 
> Your response here really surprises me!  If this Alarm MIB 
> work disregards ITU requirements than why are there so many 
> e-mails discussing support for ITU alarm codes?  Just forget 
> about that then and make up your own.
> 
The ITU Alarm MIB defines information specific to the Alarm model defined in ITU M.3100, X.733, X.736. 

This is actually a quote from the draft. It augments the basic Alarm MIB. The problem with the current discussion about probableCause is that we tried to exceed the initial goal and come with a more generic probableCause macro. Still the ITU alarms have priority in this context.

> I never have pushed to make the ARC MIB mandatory.   But, I 
> believe if an application requires both the ARC MIB and the 
> Alarm MIB then the addition of the ARC MIB should not break 
> the Alarm MIB.  The way the Alarm MIB is designed currently, 
> addition of the ARC MIB breaks it.
> 
I agree that the ARC MIB should not break the Alarm MIB. I fail to see how it does break it. On the other hand we should not impose implementation assumptions on the Alarm MIB because of requirements to fit in the ARC MIB.

> I proposed a fix of having 2 timestamps in the active alarm 
> table rather than one :  One time stamp (the time the alarm 
> was reported) be the one to use for indexing and a second 
> time stamp (the time the error occured).

This is exactly the type of requirement that looks artificial for some implementations. It implies the capability of having both accurate values registered by an Alarm MIB agent. I understand the requirement, but this looks to me beyond the goal of the Alarm MIB. 

Regards,

Dan

---

From: Tammy Ferris <[email-masked]>
Date: Thu, 18 Apr 2002 18:36:36 -0500

Dan,
re your following comments:
****
I agree that the ARC MIB should not break the Alarm MIB. I fail to see how it does break it. On the other hand we should not impose implementation assumptions on the Alarm MIB because of requirements to fit in the ARC MIB.

> time stamp (the time the error occurred).

*****
I am not imposing a requirement for 2 timestamps.  And I don't understand your point "On the other hand we should not impose implementation assumptions on the Alarm MIB because of requirements to fit in the ARC MIB."

I see the fundamental problem as follows:
The alarm model supported by the Alarm MIB appears to assume a requirement to be able to query for alarms that have been added to the active alarm table subsequent to the last manager query so that the manager does not have to read the whole table to get updated.

The Alarm MIB seems to propose to meet this requirement by indexing on the timestamp for the time the error occurred.

In analyzing this in combination with ARC, it can be seen that the currently proposed solution does not meet the original requirement as intended.  This is because the declaration of the alarm does not always coincide with the occurance of the error.

This proposed solution does not work for certain ARCed errors.  Even without ARC, I think it is a bit risky to assume that agent implementations don't support other ways of suppressing alarm declarations that could have the same effect.  For example, an error with a long integration
period.

To complicate things further (even if you may consider this outside scope I think it helps illustrate the point), what about systems that support alarm escalation and de-escalation.  Using this MIB, such a system may indicate a clear for a minor condition followed but a raise for
the same condition but only now with the severity code of major yet the same error timestamp. In this scenario, will a typical management system using this MIB, miss this updated information?

I understand that the time the error occurred does help to uniquely identify a specific occurrence of an alarm and I also understand that there might be cases where it is nice to have the table sorted in time of occurrence order, but I am worried that  the management application may
miss critical alarm information by assuming that it can rely upon looking only at those alarms information with time of occurrence happening after xxx time.

I proposed two timestamps as a possible MIB solution to discuss to meet a perceived alarm management requirement not as a requirement unto itself.  If you have a better solution to fixing this problem, I am open to that.  Maybe requiring that strictly monotonically increasing
identifiers have to be unique within a table and dropping the time of error occurrence from the index?

I don't understand how my proposal is counter to the goal of the Alarm MIB. .Maybe it would be worth restating the goal of the Alarm MIB.  What do you think is the goal of the Alarm MIB?  How is what I was proposing counter to that?

Regards,
Tammy

Tammy Lehtinen Ferris
[email-masked]
+1 (763)557-1681
Merkita Incorporated
www.merkita.com