Subject: Updated Alarm MIB Issues 1-15

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 20 Jan 2002 16:47:59 -0500

hi

Version -05 is in progress and we can send it out when we close
off on the remaining issues.

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

Alarm #4 - Relation to Event MIB

  Add the following text to -05

  x.y Relationship with the Event MIB 

  During the work and discussions in the Working Group, the issue of the
  relationship between the MIB modules and the Event MIB [RFC...] was
  raised. There is no direct relation or dependency between the Alarm MIB
  and the Event MIB. Some common terms (like 'event') are being used in
  both MIB modules, and the user is directed to the sections that define
  terminology in the two documents for clarification.

Alarm#12 Time Zone in DataAndTime

  Add the following to -05

  Implementations MUST include the offset from UTC,
   if available.  Implementation in environments in which
   the UTC offset is not available is NOT RECOMMENDED.

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#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#14 alarmRaise notification inconsistent with terminology

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

Alarm#15 RowStatus and Not in service

  There may be an issue here, I'm still catching up on the email.

Sharon