[Entmib] Entity comments
"David T. Perkins" <dperkins@dsperkins.com> Thu, 25 March 2004 07: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 CAA21658 for <entmib-archive@lists.ietf.org>; Thu, 25 Mar 2004 02:01:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OrM-0001jD-Gh; Thu, 25 Mar 2004 02:01:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OrF-0001g8-Hs for entmib@optimus.ietf.org; Thu, 25 Mar 2004 02:00:53 -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 CAA20966 for <entmib@ietf.org>; Thu, 25 Mar 2004 02:00:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OrB-0001lq-00 for entmib@ietf.org; Thu, 25 Mar 2004 02:00:49 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6OqK-0001gQ-00 for entmib@ietf.org; Thu, 25 Mar 2004 01:59:57 -0500
Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OpY-0001bJ-00 for entmib@ietf.org; Thu, 25 Mar 2004 01:59:09 -0500
Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i2P6x3b00674 for <entmib@ietf.org>; Wed, 24 Mar 2004 22:59:03 -0800
Message-Id: <5.2.0.9.2.20040324145446.02343138@127.0.0.1>
X-Sender: dperkins@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 24 Mar 2004 22:58:57 -0800
To: entmib@ietf.org
From: "David T. Perkins" <dperkins@dsperkins.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_3 autolearn=no version=2.60
Subject: [Entmib] Entity comments
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, In general, it has seemed to me that in the beginning and at the last few ENITITY MIB WG meetings that the consensus desire was to have a simple extension to the entity physical table with the following: adminState - to indicate the administrative state of a physical component, and allow change operState - to indicate the operational state of a physical component backupState - to indicate if a physical component was backing up another physical component alarmStatus - to indicate current fault conditions (if any) were present on a physical component A small minority wanted to base the definitions on X.731 definitions. However, the majority felt that was OK only if the above needs were not impacted, and the cost to support the objects on an agent was not significantly impacted. To me, the resulting definitions have not met the rough consensus needs. In addition, the document (and its yet to be sent out update) is not internally consistent. The entity state document is quite small, and I can provide a complete replacement, if the WG wants one. However, to follow the process, here are responses to the outstanding issues. I believe that these might be difficult to evaluate due to the missing context. But here it goes... #306 & #325: descriptor naming and OID tree Please, lets follow current standard layout as determined by Bert #307: not-supported is wrong I agree with Keith and Juergen. Either "unknown" or "unavailable" is fine with me. However, what is a BIG problem is the text in the DESCRIPTION clauses using the term "unreportable". This is wrong. That is, the term "unreportable" MUST be removed from the DESCRIPTION clauses and a semantically correct term must be used. #308 & 312: admin state enum values I agree with Keith and Juergen. Also, a radical approach is to remove the object altogether. However, if the object is kept, then I suggest the following enum values: up - action(to set to up) and state(is administratively up) down - action(to force set to down) and state(is administratively down) gracedown - action(to gracefully set to down) shuttingdown - state(in process of gracefully shutting down) testing - state(in test mode. requires other specific means to put in a test mode) (and if it's not obvious, then I can provide a state diagram, like that found for RowStatus TC) #309 & #332: Oper State enum names I agree with Keith. I also have problems with the values being semantically different from ifOperStatus. And, to really simplify, I suggest that the standby status object be removed, and it's values be combined. The resulting enum values would be: unknown - state unknown up - working OK down - not working (a failure) downDueToAdmin - not working since turned off and cannot tell if could work if administratively turned on downDueToContained - not working due to contained component testing - in a test mode coldStandby - backing up a component, and may be able to provide service after some initialization activity hotStandby - backing up a component, and will be able to immediately provide service without need for initialization NOTE: in X.731, the value of operState is independent of the value of adminState. However, for many real-world physical devices, one cannot determine the operState without "turning on" the component. So the above is a compromise. That is, if a component operState follows adminState (like as done by ifOperStatus), then value 'downDueToAdmin' would be used (when appropriate). And if independent, then 'down' would be used (when appropriate). #310: Alarm Status values The resolution must include a value when the operState value is 'testing'. The resulting BITs should be something like: unknown - status unknown (if set, then no other bits may be set) underRepair - item under repair underTest - item being tested critial - one or more critical fault conditions present major - one or more major fault conditions present minor - one or more minor fault conditions present warning - one or more warning fault conditions present indeterminate - one or more indeterminate fault conditions present Note: when 'underRepair' or 'underTest' BITs are set, then the manager should probably "discount" the importance of any outstanding fault conditions #311 - Initial DateTime value I agree with Keith and Juergen. #312: (see #308 above) #322: TC Names I agree with Andy and Juergen. And believe that the prefix should be EntPhys (that is not just Entity)! #325: (see #306 above) #326: Too many objects I agree with andy. The Usage object provides no additional info (that is, its value can be determined by looking at other objects in the EntPhysical table), and should be removed. The standby object can be deleted, and its values folded into oper State. #327: Editorial edits I agree with Juergen that the document needs language fixes. In addition to what he points out, I believe the following modifications are needed: a) The term "report" must be replaced with an appropriate one through out the document b) X.731 needs to be removed from the REFERENCE clauses, and X.731 needs to be changed from a normative reference to an informative reference c) X.721 and X.732 need to be added as informative references d) the alarm MIB needs to be changed from an normative reference to an informative reference #328: Definition of "contained in" I agree with Juergen that this needs to be well defined. And I previously specified a definition that I believe is sufficient. #329: Problems with usage state Remove the object. See #326 above. #330: Notification varbinds This needs review and update after update of enum values for operState. #332: Standby State issues See #326 and #309 above. #333: Relationship with alarm MIB The reported problem was not address. Said another way, the Entity State MIB SHOULD NOT depend on the support of the Alarm MIB. And the Alarm MIB RFC should be an informative and NOT a normative reference. #334: Table index Description The SMI (RFC 2578, last para of section 7.7) requires a description of the index. Also, I would add text explaining that typically instances with physical class of chassis, backplane, container and stack do not have status instances, where typically instances powerSupply, fan, sensor, module, and port do have status instances. However, they may not support modification of admin state. #335a: Clarification of notification generation The resolution didn't add clarity. That is, can multiple notifications be generated for a single event. (I think so, but I'm not sure that other reviewers noticed this.) #335b: Need for notification on change of Standby state From my previous experience, each protection switch was an important event and thus a notification is appropriate. Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib
- [Entmib] Entity comments David T. Perkins
- RE: [Entmib] Entity comments Sharon Chisholm
- RE: [Entmib] Entity comments Wijnen, Bert (Bert)
- Re: [Entmib] Entity comments Randy Presuhn