Subject: Alarm MIB - Issues 25 - 35

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 17 Apr 2002 08:13:33 -0400

Alarm #25 Relation to RFC3014 (Closed)
  There was concern that the Alarm MIB references RFC3014
  which could cause problems if the notification log MIB
  was modified to address some issues. In -06, the 
  replacement of alarmActiveLogIndex with alarmActiveLogPointer
  eliminates the technical dependency. There are other references,
  but these were viewed as being appropriate.

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."

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."

Alarm #28 Typo alarmModeNotifiationId -> alarmModelNotificationId (Closed)

Alarm #29 MAX-ACCESS in alarmModelTable should be read-create (Closed)

Alarm #30 MAX-ACCESS of alarmActiveSpecificPointer to be read-only (Closed)

Alarm #31 Duplicate Probable causes
  fire (120) & fireDetected (266)
  flood (121) & floodDetected (267)
  configurationOrCustomisationError (160) &
  configurationOrCustomizationError(260)
  underlayingResourceUnavailable (166) & underlyingResourceUnavailable(287)
  and possibly 
  toxicGas (133) & toxicLeakDetected (286)

Alarm #32 Description of alarmActiveDateAndTime (Closed)
  Change "when the alarm occurred" to "when the error occurred"

Alarm #33 Disman Immortality
  Text in the IANA considerations section suggests we'll still be
  around for IETF 34523421, held in the Mars colonies.

Alarm #34 Monotonically Increasing -> Strictly Monastically Increasing
(Closed)

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."

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 19 Apr 2002 18:17:43 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> From: "Sharon Chisholm" <[email-masked]>
> To: [email-masked]
> Subject: Alarm MIB - Issues 25 - 35
> Date: Wed, 17 Apr 2002 08:13:33 -0400
...
> Alarm #34 Monotonically Increasing -> Strictly Monastically Increasing
...

Are we to be fruitful and multiply?  :-)

 ------------------------------------------------------
 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, 22 Apr 2002 07:42:23 -0400

hi

Yes. Spell checkers are great for accidentally spicing up
an email.

Alarm #34 Monotonically Increasing -> Strictly Monotonically Increasing

thanks,

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]]
Sent: Friday, April 19, 2002 9:18 PM
To: [email-masked]
Subject: Re: Alarm MIB - Issues 25 - 35

Hi -

> Message-ID:
<[email-masked]>
...
...