Subject: RE: Alarm MIB Issues List

From: Randy Presuhn <[email-masked]>
Date: Mon, 26 Nov 2001 15:47:36 -0800 (PST)

Hi -

(I've re-ordered Dan's message to make my reply a
bit easier to read.)

> Subject: RE: Alarm MIB Issues List
> Date: Mon, 26 Nov 2001 13:50:52 +0200
> Message-ID: <[email-masked]>
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Sharon Chisholm" <[email-masked]>, <[email-masked]>
...
> > Alarm#1 TimeFilter as index to Active Alarm Table
> >  Does this make sense?
> >  Action Dan - investigate
...
> In any case, it looks like the variable alarmActiveTime is redundant,
> and may be taken out.
...

Agreed.

> I think that there is a need for the TimeFilter index in the
> AlarmActiveTable. The reason this index exists is for an application to
> be capable to perform a query on the table and retrieve only the alarms
> that were recorded in the table in the last T time interval. It does not
> save anything in the agent data structure, but it allows for a more
> economic retrieval of the data.
> 
> The alternative would be to make alarmActiveDateAndTime an index in the
> table, which would replace the question 'what new alarms showed up in
> the last 24 hours?' by the question 'what new alarms showed up since
> 1:48 PM yesterday?'. However, this would mandate DateAndTime capability
> on the agent.
...

There are some not-so-subtle differences between TimeFilter
as defined in RFC 2021 and a DateAndTime index.

    1) TimeFilter, based on sysUptime, has annoying behaviour
       if the SNMP subsystem is either long-running or gets
       re-initialized.  The DESCRIPTION for this index covers
       some of these issues, but the DESCRIPTION of TimeFilter
       requires the entire table to be purged on a sysUpTime wrap.

    2) TimeFilter's DESCRIPTION results in a new conceptual
       row any time *any* attribute in the table changes.
       Depending on the operational scenario in mind, this
       may be a bug or a feature.  With the DateAndTime index,
       presumably only alarm creation time would matter.

    3) The DESCRIPTION of TimeFilter makes it sound like it
       would enable the retrieval of deleted rows, but I doubt
       that that's really what it's supposed to do.  Word from
       an RMON expert would be appreciated.

    4) For naive mib browsers, a DateAndTime index would
       probably be better-behaved.

I tend to prefer a DateAndTime index as being easier to
understand and no more difficult to implement, even
though it would result in longer object identifiers.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Nov 2001 14:20:53 +0100

>>>>> Randy Presuhn writes:

Randy> There are some not-so-subtle differences between TimeFilter as
Randy> defined in RFC 2021 and a DateAndTime index.

[...]

Randy> I tend to prefer a DateAndTime index as being easier to
Randy> understand and no more difficult to implement, even though it
Randy> would result in longer object identifiers.

I agree with you.

/js