Subject: Alarm MIB Issues List

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 25 Nov 2001 19:39:31 -0500

hi

It's been a while since we've sent out an issues list,
so I've restarted the numbering. This is the list of
open or recently solved issues. 

I'll go back and make sure I did not miss any, but as
I promised Randy to get something out this weekend, I
figured I should send what I had.

Alarm#1 TimeFilter as index to Active Alarm Table
 Does this make sense?
 Action Dan - investigate

Alarm#2 Cleared Alarm Table (closed)
  Added to -03 version

Alarm#3 Resource Identifier for Application
  Randy indicated that what is in -03 isn't
  the best choice. "RFC 2287's sysApplRunIndex is 
  probably the closest thing to what you want
  that will fit in an integer if what you're interested in is
  "application" rather than "process"."

Alarm#4 Relation to Event MIB
  I must admit to not having finished reading the thread yet.

Alarm#5 EngineId versus ContextEngineId
  The Notification Log MIB discussion pertains to the alarm MIB
  as well.

Alarm#6 Telcordia
  Action Dave Perkins - Investigate availability and usefulness.

Alarm#7 Alarm Example Errors (closed)
  Fixed in -03

Alarm#8 Matching Notifications (closed)
  The question was raised in London as to whether using notification OID
  plus one offset and value pair was sufficient for modelling alarm
  states. Sharon sent an email on Sept 10th summarizing her analysis
  concluding that it provided pretty good modelling.

Alarm#9 Example showing relation to Condition and Arc MIB
  Currently missing from -03

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 26 Nov 2001 13:50:52 +0200

Hi Sharon,

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.

In any case, it looks like the variable alarmActiveTime is redundant,
and may be taken out.

Regards,

Dan

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 26 Nov 2001 09:56:48 -0800

HI,

The problem, which has been voiced several times, it that a manager
wants to find out BOTH added alarms and removed alarms. Timefilter
does not work for this. A log works FANTASTIC for this.
Timefilter is used to show changes after a time value.

>> Alarm#1 TimeFilter as index to Active Alarm Table
Regards,
/david t. perkins

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 26 Nov 2001 20:15:41 +0200

There is a cleared alarm table now that complements the
alarmActiveTable.

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]]
> Sent: Monday, November 26, 2001 7:57 PM
> To: Romascanu, Dan (Dan); Sharon Chisholm; [email-masked]
> Subject: RE: Alarm MIB Issues List
> 
> 
> HI,
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 27 Nov 2001 18:59:07 +0200

I have no problem with this solution. I would suggest that we add this
index to both alarmActiveTable and alarmClearTable, and take out
alarmActiveTime and alarmClearTime.

Dan

> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2001 3:21 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Alarm MIB Issues List
> 
> 
> 
> >>>>> 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
> 
> 
>

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 27 Nov 2001 15:00:50 -0800 (PST)

Hi -

> Date: Tue, 27 Nov 2001 18:59:07 +0200
> Message-ID: <[email-masked]>
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Juergen Schoenwaelder" <[email-masked]>,
>         <[email-masked]>
> Cc: <[email-masked]>
> 
...

If we use the same object as part of the indexing of both
tables, we need to be especially careful in the wording of
the DESCRIPTION.  In the case of the alarmActiveTable, its
value would represent the time at which the alarm became
active, but in the case of the alarmClearTable, the value
would represent the time at which the alarm was cleared.

 ------------------------------------------------------
 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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 28 Nov 2001 08:17:21 +0200

> would represent the time at which the alarm was cleared.

My (badly formulated) intention was to propose two objects with similar
syntax, and not the same object as index in both tables. 

Dan