Subject: RE: Alarm MIB WG last call

From: Randy Presuhn <[email-masked]>
Date: Wed, 3 Apr 2002 09:41:49 -0800 (PST)

Hi -

> Subject: RE: Alarm MIB WG last call
> Date: Wed, 3 Apr 2002 18:10:30 +0300
> Message-ID: <[email-masked]>
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "David T. Perkins" <[email-masked]>,
>         "Randy Presuhn" <[email-masked]>, <[email-masked]>
> 
> I find this argument in-sufficient. It includes a reference to a
> non-chartered work (AFAIK) and a conditional ('could result in the
> I-D being broken').  RFC 3014 is a standards track document at PS.
> Answering in same conditional mode, IF a replacement work will be
> chartered, and IF this will indeed replace RFC 3014, the next versions
> of the Alarm MIB COULD refer this replacement. Until then my opinion
> is that the references in the I-D are valid.
>

As a technical contributor, I shared Dave Perkin's concern
about making the linkage between the alarm MIB and RFC 3014
tighter than would be architecturally necessary.  One of the
important changes between the -05- and -06- drafts is the
replacement of alarmActiveLogIndex  with alarmActiveLogPointer.

I think this change has eliminated any technical dependency
on the indexing structure of the log MIB.  The only
other normative reference to 3014 is in the DESCRIPTION of
alarmListName, and I really don't see how this ("The name of
the list of alarms.  This SHOULD be the same as nlmLogName
if the Notification Log MIB [RFC3014] is supported.") could
be a problem.

 ------------------------------------------------------
 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: Tammy Ferris <[email-masked]>
Date: Thu, 11 Apr 2002 10:49:32 -0500

Sharon, Dan, Randy, and all,

I realize that last call is probably over in relation to the Alarm mib; therefore you may
choose to ignore my comments below.  I have only just now had some time to look at this.
On the assumption that you would like to hear the comments anyway, I have included them.

I commend the editors for the progress that has been made. I know how difficult it can
sometimes be to get something standardized.

I have tried to put my comments into a priority order with my greatest concerns first.
1) I question the wisdom of doing the last call on this MIB without having other alarm
management functions adequately addressed such as alarm correlation and alarm suppression
and also going for last call.  While it looks to me that the MIB is well designed for the
functionality it is intended to provide, I am not sure that it provides all the necessary
functions. It also concerns me that agent behaviors in declaring/clearing/etc errors is
not discussed.  Further, I had hoped that this MIB would cover transient as well as
persistent "errors" (using your terminology).  Assuming all of this was discussed and
these constraints are satisfactory to everybody else, the remaining comments are in the
context of the given constraints and have quick remedies.

2)  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".  (Note: I actually would prefer an Alarm to be
defined as an indication of trouble or something along those lines... my proposed
correction is assuming that there is no negotiation on whether or not an alarm can be
based on a transient condition) The definition for Alarm Raise would become: " The initial
detection of the error indicated by an alarm or any number of alarm states later entered,
except clear. A Notification SHOULD be sent on alarm raise." The definition for Alarm
Clear would become: "The detection that the error indicated by an alarm no longer exists.
A Notification SHOULD be sent on alarm clear."

3) In the overview, it would be nice to add a description regarding the extensibility of
the AlarmActiveEntry.  I think this is an important feature.

4) 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.

Regards,
Tammy

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