RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues
"Sharon Chisholm" <schishol@nortelnetworks.com> Fri, 13 February 2004 22:01 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09571 for <entmib-archive@lists.ietf.org>; Fri, 13 Feb 2004 17:01:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlMz-0000JE-MB; Fri, 13 Feb 2004 17:01:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlMC-0008Vd-43 for entmib@optimus.ietf.org; Fri, 13 Feb 2004 17:00:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09483 for <entmib@ietf.org>; Fri, 13 Feb 2004 17:00:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlM9-0001cp-00 for entmib@ietf.org; Fri, 13 Feb 2004 17:00:17 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlLH-0001Xi-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:59:24 -0500
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ArlKa-0001Q4-00 for entmib@ietf.org; Fri, 13 Feb 2004 16:58:40 -0500
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1DLw9n21202 for <entmib@ietf.org>; Fri, 13 Feb 2004 16:58:09 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8RAX>; Fri, 13 Feb 2004 16:58:10 -0500
Message-ID: <3549C09B853DD5119B540002A52CDD340A2A7110@zcard0ka.ca.nortel.com>
From: Sharon Chisholm <schishol@nortelnetworks.com>
To: entmib@ietf.org
Subject: RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm State Issues
Date: Fri, 13 Feb 2004 16:58:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: entmib-admin@ietf.org
Errors-To: entmib-admin@ietf.org
X-BeenThere: entmib@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=unsubscribe>
List-Id: IETF Entity MIB WG <entmib.ietf.org>
List-Post: <mailto:entmib@ietf.org>
List-Help: <mailto:entmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=subscribe>
Hi All we need to do is refer to the definitions in the Alarm MIB and we should be good. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, February 13, 2004 12:51 AM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org 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:rt+entity-state@rt.psg.com] >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 [kzm@cisco.com] > >"> '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 [j.schoenwaelder@iu-bremen.de] > >"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 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib
- [Entmib] FW: [psg.com #310] AutoReply: Alarm Stat… Sharon Chisholm
- Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm … David T. Perkins
- RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm … Sharon Chisholm
- RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm … Sharon Chisholm
- Re: [Entmib] FW: [psg.com #310] AutoReply: Alarm … Juergen Schoenwaelder
- RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm … Sharon Chisholm
- RE: [Entmib] FW: [psg.com #310] AutoReply: Alarm … Sharon Chisholm