Subject: Re: summary of issues I've raised with the Alarm MIB

From: Randy Presuhn <[email-masked]>
Date: Fri, 25 Jan 2002 17:36:27 -0800 (PST)

Hi -

> Message-Id: <[email-masked]>
> Date: Fri, 25 Jan 2002 16:36:41 -0800
> To: Randy Presuhn <[email-masked]>, [email-masked]
> From: "David T. Perkins" <[email-masked]>
> Subject: Re: summary of issues I've raised with the Alarm MIB
> In-Reply-To: <[email-masked]>
...
> Exception 2 says that in the special case, you can make the column
> "read-only". I don't see how you got "accessible-for-notify" out
> of it.
...

I read the "i.e." as an "e.g.", given the history of how
accessible-for-notify was added.  I understand your argument
now, essentially interpreting the "lack of permission" as
"prohibition."

 ------------------------------------------------------
 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: "Sharon Chisholm" <[email-masked]>
Date: Mon, 28 Jan 2002 07:35:45 -0500

hi

Some of this is already covered in the open issues list.
I should be sending out an updated version of that 
later today. I'll add the delta issues and proposed 
solution at that time

David> * Change indices to not-accessible or accessible-for-notify as
David>   appropriate.  This necessitates small changes in object
David>   groups, as well.

New Alarm#16

David> * Add MODULE-IDENTITY macros where needed

I'll add them.

New Alarm #17

David> * How can alarmActiveTable and alarmClearTable share an index
David>   from alarmActiveTable given that when an alarm is cleared it
David>   is moved to alarmClearTable and the corresponding entry in
David>   alarmActiveTable is removed?

New Alarm #18

Well, I guess the alarmActiveIndex does not exist when it is being used
in the clear table. I've seen this sort of thing done before, but 
strictly speaking, should alarmActiveIndex be instantiated to reuse it?
If this is the case, then I would suggest creating a duplicate object
that shares the same value.

Dave> * Need clarification on how alarmModelVarbindIndex works

This is the issue of SNMPv1 traps versus SNMPv2 traps. I'll add some
clarifying text.

New Alarm #19

Dave> * Small change:  move alarmNotifications from { alarmMIB 2 } to
Dave>   { alarmMIB 0 } do you don't have to have { alarmNotifications 0 1 }
Dave>   but can instead just have { alarmNotifications 1 }.
Dave>   I realize this is cosmetic.

New Alarm #20

thanks for the input,

Sharon