RE: [Entmib] FW: [psg.com #308] AutoReply: Shutting Down Admin St ate
"Sharon Chisholm" <schishol@nortelnetworks.com> Sun, 15 February 2004 23:44 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 SAA02399 for <entmib-archive@lists.ietf.org>; Sun, 15 Feb 2004 18:44: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 1AsVvd-0007Os-21; Sun, 15 Feb 2004 18:44:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsVvQ-0007Nt-6l for entmib@optimus.ietf.org; Sun, 15 Feb 2004 18:43:48 -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 SAA02361 for <entmib@ietf.org>; Sun, 15 Feb 2004 18:43:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsVvN-0006VD-00 for entmib@ietf.org; Sun, 15 Feb 2004 18:43:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsVuO-0006R9-00 for entmib@ietf.org; Sun, 15 Feb 2004 18:42:45 -0500
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AsVtP-0006LI-00 for entmib@ietf.org; Sun, 15 Feb 2004 18:41:43 -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 i1FNf7g08587 for <entmib@ietf.org>; Sun, 15 Feb 2004 18:41:08 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNH8ZBW>; Sun, 15 Feb 2004 18:41:07 -0500
Message-ID: <3549C09B853DD5119B540002A52CDD340A2A72A0@zcard0ka.ca.nortel.com>
From: Sharon Chisholm <schishol@nortelnetworks.com>
To: entmib@ietf.org
Subject: RE: [Entmib] FW: [psg.com #308] AutoReply: Shutting Down Admin St ate
Date: Sun, 15 Feb 2004 18:41:07 -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 I'm distilling two things from this email 1. It would be good to better understand the relationship between the admin state and the usage state to ensure there are no issues 2. There is discussion again about containment, which should be explained by the text in section 2.1 Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, February 12, 2004 4:50 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: Re: [Entmib] FW: [psg.com #308] AutoReply: Shutting Down Admin State HI, I also find several problems with the current definition of the value "shuttingDown" for AdminState. First, the definition of usageState was radically changed in the current draft of the document. From the DESCRIPTION clause of object entStateUsage (with comments in "<...>"): " <text cut> Note that in the context of a physical entity, this <this is sort of silly to say "in the context of a physical entity", since this MIB module is describing physical entities> object refers to an entity's ability to service more physical entities in a containment hierarchy. A value of 'idle' means this entity is able to contain other entities but that no other entity is currently contained within this entity, as would have been demonstrated by a value of entPhysicalContainedIn that referenced this entity. A value of 'active' means that at least one entity is contained within this entity and therefore has a value of entPhysicalContainedIn that references this entity, but that it could handle more. A value of 'busy' means that the entity is unable to handle any additional entities being contained in it, as demonstrated by having a value of entPhysicalContainedIn that refers to this entity. Some entities will exhibit only a subset of the usage state values. Entities that are unable to ever service any entities within a containment hierarchy will always have a usage state of 'busy'. Some entities will only ever be able to support one entity within its containment hierarchy and will therefore only exhibit values of 'idle' and 'busy'." Given the above, I don't know how to apply the value of "shuttingDown". But first, let's look at the values. Secondly, the X.731 document models the admin characteristic as with a 3 state diagram. The states are "unlocked", "shutting down", and "locked". The "shutting down" state is meant to represent a graceful shutdown of an "object". The event "shutdown" is a state transition from "unlocked" to "shutting down". Another transition occurs from state "shutting down" to "lock" when event "the last user quits" occurs. Now, if I were to model this in SNMP's SMI, I would have an "action/state" object with values: locked - a state and action unlocked - a state and action shutDown - an action (a write only value) (on a SET with no error, a read would return either value "locked" or "shuttingDown") shuttingDown - a state (a read only value) However, given the change of definition of the meaning of usage state, I'm a little confused as to how to "update" the TC (and object type) definitions. In general, I'm not sure that there is a need for a "graceful" and "force" administrative shutdown action values. If "graceful" shutdown is added, then I suggest that the value of "shuttingDown" be return until the value of "operState" is no longer "enabled". This removes the confusing "user" terminology. (See section 3.1.13 of RFC 2863) Thirdly, object IF-MIB::ifAdminStatus has a value of "testing". I don't know it maps to values for AdminState. This was not covered in the document. Finally, neither the IF MIB document nor X.731 describe the relationship between the admin values and admin (and oper) values of "contained" objects. And thus, this document does not cover this topic. It can be one of: 1) there is no relationship 2) the relationship is implementation defined 3) there is no relationship between admin values, but there is a weak relationship between oper values (more on this in message about #309 (oper state values)) At 01:59 PM 2/11/2004 -0500, Sharon Chisholm wrote: >The following is the proposed resolution to entstate-308. The issue >will be considered closed with no changes made to the document. > >The following explanations were provided and no questions were raised. > >" >1. Is shutting down really more an operational state? > >The state refers more to whether your administrative model allows >systems to be shut down gracefully or not. The idea being that if it >does, you would still have the options to bring it down less >gracefully. We have allowed in the description of the object for >systems that don't support this value for the state. > >2. Would 'noNewUsage' be a better term. > >Well, except that the idea is that once all the existing 'users' are >gone, the system will shut down. The term 'noNewUsage' does not really >reflect that." > >Sharon > > >-----Original Message----- >From: entity-state [mailto:rt+entity-state@rt.psg.com] >Sent: Tuesday, January 13, 2004 2:55 AM >To: Chisholm, Sharon [CAR:0S00:EXCH] >Subject: [psg.com #308] AutoReply: Shutting Down Admin State ><clip> > >----------------------------------------------------------------------- >-- >Keith McCloghrie [kzm@cisco.com] > >" > >the term 'shuttingDown' suggests that the action of shutting down is >> in progress, which of course is an operational condition, not an >admin >> state. A term more reflective of what the AdminState DESCRIPTION >appears >> to define would be 'noNewUsage'. In any case, this concept >of 'usage' >> is almost always a higher-level usage (e.g., a new ATM connection >on an >> ATM interface, a new Unix login on a cpu module, etc.) and thus >don't >> belong at the physical layer (i.e., don't apply to >> entPhysicalIndex). >" Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib
- RE: [Entmib] FW: [psg.com #308] AutoReply: Shutti… Sharon Chisholm
- RE: [Entmib] FW: [psg.com #308] AutoReply: Shutti… Sharon Chisholm
- RE: [Entmib] FW: [psg.com #308] AutoReply: Shutti… Sharon Chisholm
- RE: [Entmib] FW: [psg.com #308] AutoReply: Shutti… Sharon Chisholm