[Entmib] Comments on draft-ietf-entmib-state-02.txt

Keith McCloghrie <kzm@cisco.com> Mon, 12 January 2004 21:45 UTC

Received: from optimus.ietf.org ([]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23441 for <entmib-archive@lists.ietf.org>; Mon, 12 Jan 2004 16:45:30 -0500 (EST)
Received: from localhost.localdomain ([] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9rp-0006sl-DQ; Mon, 12 Jan 2004 16:45:01 -0500
Received: from odin.ietf.org ([] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9rk-0006sR-9C for entmib@optimus.ietf.org; Mon, 12 Jan 2004 16:44:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23418 for <entmib@ietf.org>; Mon, 12 Jan 2004 16:44:53 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9ri-0003mO-00 for entmib@ietf.org; Mon, 12 Jan 2004 16:44:54 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9qC-0003cm-00 for entmib@ietf.org; Mon, 12 Jan 2004 16:43:21 -0500
Received: from sj-iport-5.cisco.com ([]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9ol-0003Uh-00 for entmib@ietf.org; Mon, 12 Jan 2004 16:41:51 -0500
Received: from sj-core-1.cisco.com ( by sj-iport-5.cisco.com with ESMTP; 12 Jan 2004 13:41:38 -0800
Received: from cisco.com (cypher.cisco.com []) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0CLfIGN022817 for <entmib@ietf.org>; Mon, 12 Jan 2004 13:41:19 -0800 (PST)
Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA08000 for entmib@ietf.org; Mon, 12 Jan 2004 13:41:18 -0800 (PST)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200401122141.NAA08000@cisco.com>
To: entmib@ietf.org
Date: Mon, 12 Jan 2004 13:41:18 -0800
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Entmib] Comments on draft-ietf-entmib-state-02.txt
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>
Content-Transfer-Encoding: 7bit

I was asked to post these comments:


> the MIB still needs work:
>   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).
>   'notSupported' is semantically wrong, because a compliant implementation
>   obviously supports the MIB, but it can return 'notSupported' for
>   every object in the MIB.  Presumably, the intended semantics is that
>   the agent would return the right value if only it knew the right value;
>   i.e., 'unknown' is the desired semantics.  Also, why is each definition
>   of 'notSupported' defined in an object's DESCRIPTION, not in the TC's
>   'enabled' and 'disabled' to me imply that an admin state, i.e., if
>   I saw an operState of 'disabled', or a entStateOperDisabled notification,
>   I'd look for the knob by which I could issue the enable command to enable
>   it again.
>   the entities to which this MIB applies are physical entities, and thus
>   it seems natural to apply the term 'locked' in a physcial sense, rather 
>   than a logical sense, i.e., 'locked' is not the right term to use for 
>   administratively disabling a device, because if a device had a physical
>   lock, then its adminState should not be 'locked' if/when its physical lock
>   could be unlocked, and vice versa.
>   '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!!).
>   should the MIB define DateAndTimeOrZero ?  What does zero mean ?
>   for most things, I believe you have to turn them on to see if they work;
>   if they don't work, you can turn them off again, and label them "inoperable",
>   but what that means is that they were inoperable the last time they were
>   turned on, and it doesn't necessarily mean they are still inoperable, e.g.,
>   if something was inoperable the last time it was turned on and has just
>   been repaired, but not yet turned on again, is it still inoperable ??
>   That is, neither 'disabled' nor 'inoperable' is the right term for operState.

Entmib mailing list