[Entmib] Thoughts on Issues 308, 309, 310, 312

"Sharon Chisholm" <schishol@nortelnetworks.com> Tue, 13 January 2004 10:15 UTC

Received: from optimus.ietf.org ([]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04302 for <entmib-archive@lists.ietf.org>; Tue, 13 Jan 2004 05:15:31 -0500 (EST)
Received: from localhost.localdomain ([] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgLZd-0006mz-S5; Tue, 13 Jan 2004 05:15:01 -0500
Received: from odin.ietf.org ([] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgLYu-0006lT-A5 for entmib@optimus.ietf.org; Tue, 13 Jan 2004 05:14:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04246 for <entmib@ietf.org>; Tue, 13 Jan 2004 05:14:12 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1AgLYq-0004Cu-00 for entmib@ietf.org; Tue, 13 Jan 2004 05:14:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgLX0-00049l-00 for entmib@ietf.org; Tue, 13 Jan 2004 05:12:18 -0500
Received: from zcars0m9.nortelnetworks.com ([]) by ietf-mx with esmtp (Exim 4.12) id 1AgLWA-00046q-00 for entmib@ietf.org; Tue, 13 Jan 2004 05:11:26 -0500
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com []) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0DAAuq06870 for <entmib@ietf.org>; Tue, 13 Jan 2004 05:10:56 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <ZL73D3T1>; Tue, 13 Jan 2004 05:10:56 -0500
Message-ID: <3549C09B853DD5119B540002A52CDD3409C6728E@zcard0ka.ca.nortel.com>
From: Sharon Chisholm <schishol@nortelnetworks.com>
To: entmib@ietf.org
Date: Tue, 13 Jan 2004 05:10:53 -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.1 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Entmib] Thoughts on Issues 308, 309, 310, 312
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>

308: Shutting Down Admin State

Two issues

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

312: Locked Admin State

The question was whether this should be a physical lock instead of a logical

By physical lock do you mean like something that requires a physical key? I
think a logical lock, in that case, is both more reportable as well as more

309: Operational State Names and Concepts

Two issues

1. 'enabled' and 'disabled' bad name choice

Perhaps, but they don't really bother be enough to warrant the change from
the OSI names.

2. Predetermining operability before administrative unlocking

If there are know error conditions against an entity, then a lot of
implementations can tell that it won't be operational if administratively
unlocked. I'm sure there are some implementations that can't do this, and
I'm sure that even for implementations that can there would be cases when
this can't be accurately predicted due to undetected problems or the impact
of known problems being underestimated. I would suggest some text indicating
something of this sort would be useful.

310: Alarm State Issues

Two issues

1. 'underRepair' is an operState, not an AlarmState

Well, in this context the idea being that the value of this object is not
reliable. We could remove this object I suppose, but I think I'd rather just
see text added to this effect.

2. Severity of Alarms

The question was whether the severity of the alarms are influenced by other
state attributes. The answer is that it is explicitly states in section 2.1
that all of the state objects in this MIB are raw state, so therefore not
affected by other states. What you are referring to is computed state which
would be nice to get to but we need to walk first.

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada

Entmib mailing list