Subject: Updated Alarm MIB Issues 9-20

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 4 Feb 2002 08:11:31 -0500

hi

Newly Closed
-------------

Alarm#14 alarmRaise notification inconsistent with terminology

  Changed the alarmRaise notification to be alarmSet to be consistent
  with the terminology as defined.

> Alarm#13 DMTF input into probable cause
>   We have some input from DMTF as to potential additional probable
>   cause values. When these are available, the initial set of
>   probable causes can be updated.

  If we receive this input, we can include it. Otherwise, these
  additional causes can be added using IANA.

Alarm#15 RowStatus and Not in service

  Added the following text to the RowStatus Description

     ... Alarms whose alarmModelRowStatus is
     not active will not appear in either the alarmActiveTable
     or the alarmClearTable. Setting this object to notInService
     cannot be used as an alarm suppression mechanism. Entries
     that are notInService will disappear as described in RFC2579
     
     This row can not be modified or deleted while it is being 
     referenced by a value of alarmActiveModelPointer. In these
     cases, an error of resourceUnavailable will be returned to
     the manager.

Alarm#16 Access rights to table varbinds

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

Alarm#17 MODULE-IDENTITY

   Added MODULE-IDENTITY macros to both textual conventions

Alarm#19 alarmModelVarbindIndex

Dave> * Need clarification on how alarmModelVarbindIndex works

This is the issue of SNMPv1 traps versus SNMPv2 traps. I've added some
clarifying text.

Open Issues
----------

> Alarm#9 Example showing relation to Condition and Arc MIB
>   Currently missing from -04
> 
> Alarm#11 Resource Identification
>   The resource identification method in -04 uses a type and 
>   integer value pair to identify a resource. There has
>   been some support for using an OID instead. There are
>   pros and cons to each approach. 

    I'd also add the discussion of a per instance displayString 
    here as well. A display string in the active alarm table
    serves simple managers well, although it's a nightmare for
    anyone trying to do anything other than display the object.
    It might make sense to include both it and an object that 
    can be used by more complicated managers to do more interesting
    things with.

    I'm still not a fan of the OID approach, but it seems to have
    a lot of support. We may be able to produce something with
    a lot of MUSTs in that might address my concerns

Alarm#18

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?

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.

Alarm#20 OID Aesthetics

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.

Sharon