Subject: Updated Alarm MIB Issues

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 4 May 2002 13:05:55 -0400

hi

Here's an update on the issues list:

Alarm #26 Extensibility of alarmActiveEntry
  "In the overview, it would be nice to add a description regarding the
  extensibility of
  the AlarmActiveEntry.  I think this is an important feature."
  Solution:
  Add text to section 4.1.1 explaining that more information can be
  stored for an active alarm by defining a table extension of
alarmActiveEntry.

Alarm #27 Resource Type
  "Section 4.1.4, it is not clear to me how it can be know what type of
  resource the alarm
  is for.  It would be nice to have a description of this."
  Solution: 
  Add text explaining that the consumer of the resourceID does
  not necessarily need to know the type of the resource in the resource ID,
  but if they want to know this, it can be derived by examining the content
  of the resource ID - 1.3.6.1.2.1.2.2.1.1.something is an interface for
  example.

Alarm #31 Duplicate Probable causes
  Solution:
    remove: fireDetected (266)
            floodDetected (267)
            configurationOrCustomizationError(260)
            underlyingResourceUnavailable(287)
  and possibly 
  toxicGas (133) & toxicLeakDetected (286)

Alarm #33 Disman Immortality
  Text in the IANA considerations section suggests we'll still be
  around for IETF 34523421, held in the Mars colonies.
  Solution:
  Change text to the following:
  "Over time, there will be a need to add new IANAItuProbableCause
enumerated 
   values for new probable causes. The Internet
   Assigned Number Authority (IANA) is responsible for the assignment of
   all Internet numbers, including various SNMP-related numbers, and
   specifically, new IANAItuProbableCause values. Values of 
   IANAItuProbableCause less than 255 are reserved for causes
   that correspond to ITU probable cause.

   The following shall be used as the initial values, but the latest
   values for these textual conventions should be obtained from IANA:"

Alarm #35 AlarmState Notification varbinds
  "While we're on the topic of these two notifications, I
   think that alarmActiveResourceId is not particularly useful
   without alarmActiveContextName, alarmActiveEngineAddressType,
   alarmActiveEngineAddress, and alarmActiveEngineID."  

Alarm #36 Varbinds to alarmActiveState notifications
  Using explicit varbinds if model, state and name or using
alarmActiveModelPointer
  Option 1) varbind alarmListName, alarmModelIndex, alarmModelState
  Option 2) varbind alarmActiveModelPointer          

Alarm #37 Gauge32 versus Counter32 for ituALarmActiveStats*Current (closed)
  Solution:
  Keep the current data types, but improve the descriptions of both the
*Current
  and *Total objects. Rename *Total to *s - i.e.,
ituAlarmActiveStatsWarningTotal
  changed to ituAlarmActiveStatsWarnings

Alarm #38 Description of object alarmModelVarbindIndex 
  Option 1) Change "For SNMPv1 traps, a 1 indicates the first varbind. For
  NOTIFICATION-TYPE," to "For v1Traps,For v2Traps and Informs, a 1 indicates

  the first varbind. ". 
  Option 2) Alternatively, always treat it like v2 traps

Alarm #39 Description of alarmActiveVariableTable
  Should this table be renamed to alarmActiveVarbindTable?
  Solution: No, probably not.

Alarm #40 Identify where to find resource identifier in notification
  Option 1) Document how knowledge of the given notifications is assumed
  Option 2) Add Sharon's suggestion which allows raise/clear correlation 
            in most cases
  Option 3) Add Randy's suggestion which allows algorithmic determination
            of resourceId from notification varbinds in most cases.

Alarm #41 Example of listName use is required
  Solution:
    Incorporate Randy's suggested text for alarm #47
    Add some additional clarifying text as required.

Alarm #42 TrendIndicator enumerations
  Should the following two be added:
       indeterminate - for when you can't determine the trend
       noneActive - for when you can determine there are currently
                 no outstanding alarms for the instance

Alarm #43 Timestamp Description & Do we need two timestamps
  Change text to:
  'The time that the error information was added to the alarm table. 
  The time when the error occurred may be retrieved from a different 
  source, e.g. from the variable bindings of the notification if a 
  distributed system using notifications for alarm generation is 
  being implemented'.
  Does this then require sysUptime and trapOID to be stored in 
    alarmActiveVariableTable, even for v1 traps?

Alarm #44 Probable Cause corrections from ITU Study group 4

Alarm #45 RMON example misleading

Alarm #46 Minor error in 6.1 Alarms Based on linkUp/linkDown Notification
(closed)
   alarmActiveModelPointer          alarmModelEntry.3 <<<<<<<<<<<<<< missing
index 

Alarm #47 Security Issues, ASCII Art Changes
   Solution:
     Use Randy's updated ASCII art and suggested text changes. 

Alarm #48 Mechanical/Editorial Update
  51.1 The copyright notice between the "Status of this Memo" and
  the "Abstract" sections is missing.
  51.2 Since this is the product of the working group, it would be
  good to include the working group mailing list in the
  CONTACT-INFO.
  51.3 the "Intellectual Property" section (per RFC 2026 clause 10.4,
  especially (D)) is missing.
  51.4 In the security considerations, the "sensitive" objects should
  be listed.
  51.5 The title of section 8 should probably be "Authors' Addresses",
  unless Sharon and Dan are moving in together.  :-)  A phone
  number for Sharon would also be nice.
  51.6 the "References" section should be split into normative
  and non-normative references, per
  draft-rfc-editor-rfc2223bis-02.txt
  51.7 The Copyright date (section 11) needs to be adjusted.

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

---

From: Tammy Ferris <[email-masked]>
Date: Tue, 07 May 2002 11:29:54 -0500

Sharon,
In reference to #43, I like your proposed text, and would like similar text for
alarmClearDateAndTime.  As I understood, these are related.  Something along the
lines of:
DESCRIPTION
          "The local date and time when the error information was cleared from
the active alarm table.
          Implementations MUST include the offset from UTC,
          if available.  Implementation in environments in which
          the UTC offset is not available is NOT RECOMMENDED."

In terms of your question for #43, I am not sure I clearly understand the impact
of not having sysUptime and trapOID in the alarmActiveVariableTable.  Could
these be added via extensability as needed?

In one of my previous e-mails, I raised the following point:

     I have a problem with the definition of Fault as a "lasting" error or
     warning
     "condition".  What is meant by lasting is not clear nor what is meant
     by condition. In
     addition, the ITU has used the term Fault for "errors" that are
     entering into the
     persistency function and are therefor, by definition, not persistent
     (if that is what was
     meant by lasting). Since the term fault is only used in the definition
     section, I would
     propose that the term Fault be removed and the definition of Alarm be
     modified to
     "Persistent indication of an Error".

Can you clarify what action, if any, is being proposed for this?  I did not see
it in your summary.

Thanks,
Tammy

Tammy Lehtinen Ferris
[email-masked]
+1 763 577 5946
Merkita Incorporated
www.merkita.com