RE: FW: [psg.com #310] AutoReply: Alarm State Issues
"Sharon Chisholm" <[email protected]> Sun, 15 Feb 2004 14:51:56 -0500
| Newsgroups | gmane.ietf.entmib |
|---|---|
| Message-ID | <[email protected]> |
The following is the proposed resolution to entstate-310. The issue will be
considered closed pending the proposed edit being done.
In the description of AlarmStatus replace
"
"Represents the possible values of alarm status.
When no bits of this attribute are set, then none of the
status conditions described below are present. When the
value of under repair is set, the resource is currently
being repaired.
When the value of 'critical' is set, one or more critical
alarms are active against the resource. When the value of
'major' is set, one or more major alarms are active against
the resource. When the value of 'minor' is set, one or more
minor alarms are active against the resource. When the
value of 'warning' is set, one or more warning alarms are
active against the resource. When the value of
'indeterminate' is set, one or more alarms of
indeterminate severity are active against the resource.
When the value of 'alarmOutstanding' is set, one or more
alarms is active against the resource. The fault may or may
not be disabling. "
With
"
"Represents the possible values of alarm status. An Alarm
[ALARM-MIB]
is a persistent indication of an error or warning condition.
When no bits of this attribute are set, then none of the
status conditions described below are present. When the
value of under repair is set, the resource is currently
being repaired, which depending on the implementation,
may make the other values in this bit string unreliable.
When the value of 'critical' is set, one or more critical
alarms are active against the resource. When the value of
'major' is set, one or more major alarms are active against
the resource. When the value of 'minor' is set, one or more
minor alarms are active against the resource. When the
value of 'warning' is set, one or more warning alarms are
active against the resource. When the value of
'indeterminate' is set, one or more alarms whose of
perceived severity cannot be determined are active against
this resource.
When the value of 'alarmOutstanding' is set, one or more
alarms is active against the resource. The fault may or may
not be disabling. This bit provides a high-level summary that
can be used to determine whether or not to examine the rest of
the values. "
An explanation on the difference between raw and computed state, as defined
in section 2.1 was previously provided in relation to the severity of alarms
issue. No change appears to be necessary on that particular issue.
Sharon
-----Original Message-----
From: David T. Perkins [mailto:[email protected]]
Sent: Friday, February 13, 2004 12:51 AM
To: Chisholm, Sharon [CAR:0S00:EXCH]; [email protected]
Subject: Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues
HI,
The Alarm Status (not state) brings up the unsettled definition of what is
"an alarm" and what is "clearing an alarm". The definition
of an alarm MUST be specified for the TC and object to be useful. Or another
term must be used (and, of course, that term must be
well defined).
I suggest that the term "alarm" be replaced by "fault". And the following be
used for the TC and object definitions:
FaultStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The fault status, which is a bit string.
When all the bits are zero, then no faults are present.
The bit 'unavailable(0)' indicates that the fault status
is unknown. When set, all bits other than 'underRepair(1)'
must be zero. The 'underRepair(1)' indicates that the
an item is under repair.
The following bits are one when one or more faults of
the perceived severity exist. The value is zero for
a bit when there is no existing fault of the perceived
severity. The bits and faults are:
'critical(2)'
'major(3)'
'minor(4)'
'warning(5)'
'indeterminate(6)' (the perceived severity cannot
be determined)
The entity may continue to operate while a fault
condition exists."
SYNTAX BITS
{
unavailable(0),
underRepair(1),
critical(2),
major(3),
minor(4),
-- The following are not defined in X.733
warning(6),
indeterminate(7)
}
entStateFault OBJECT-TYPE
SYNTAX FaultStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The fault status for this entity. It does not include
the faults raised on entities within its
containment hierarchy. These are entities that
specify this entity as the value for object
entPhysicalContainedIn directly and indirectly."
::= { entStateEntry 5 }
At 02:44 PM 2/11/2004 -0500, Sharon Chisholm wrote:
>The following is the proposed resolution to entstate-310. The issue
>will be considered closed pending the proposed edit being done.
>
>In the description of AlarmStatus replace
>
>" When the
> value of under repair is set, the resource is currently
> being repaired."
>
>With
>
>" When the
> value of under repair is set, the resource is currently
> being repaired, which depending on the implementation,
> may make the other values in this bit string unreliable."
>
>
>And replace
>
>"
> When the value of 'alarmOutstanding' is set, one or more
> alarms is active against the resource. The fault may or may
> not be disabling. "
>
>With
>
>"
> When the value of 'alarmOutstanding' is set, one or more
> alarms is active against the resource. The fault may or may
> not be disabling. This bit provides a high-level summary that
> can be used to determine whether or not to examine the rest of
> the values."
>
>
>An explanation on the difference between raw and computed state, as
>defined in section 2.1 was previously provided in relation to the
>severity of alarms issue. No change appears to be necessary on that
>particular issue.
>
>Sharon
>
>
>-----Original Message-----
>From: entity-state [mailto:[email protected]]
>Sent: Tuesday, January 13, 2004 2:58 AM
>To: Chisholm, Sharon [CAR:0S00:EXCH]
>Subject: [psg.com #310] AutoReply: Alarm State Issues
>
><clip>
>
>-----------------------------------------------------------------------
>--
>Keith McCloghrie [[email protected]]
>
>"> 'underRepair' is an operState, not an AlarmState.
>>
>> from what perspective are the alarms classified as
>critical/major/minor/etc.
>> e.g., does a particular fault have the same alarm status
>in 'coldStandby'
>> as it does in 'hotStandby' or in 'providingService' ?? (hint: the
>answer
>> is no!!).
>"
>
>
>
>Juergen Schoenwaelder [[email protected]]
>
>"6) AlarmStatus TC: I do not really understand the alarmOutStanding
>bit. It seems like this is set whenever one of critical, major, minor,
>warning and indeterminate is set. But if this is true, I think the bit
>is not really terrible useful.
>
>Perhaps the bit has some other meaning. If so, please clarify."
Regards,
/david t. perkins