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

"Sharon Chisholm" <> Tue, 13 January 2004 08:27 UTC

Received: from ([]) by (8.9.1a/8.9.1a) with ESMTP id DAA01223 for <>; Tue, 13 Jan 2004 03:27:34 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1AgJt6-0003Ms-RU; Tue, 13 Jan 2004 03:27:00 -0500
Received: from ([] by with esmtp (Exim 4.20) id 1AgJsG-0003LQ-9t for; Tue, 13 Jan 2004 03:26:08 -0500
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id DAA01196 for <>; Tue, 13 Jan 2004 03:26:06 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1AgJsE-0000kA-00 for; Tue, 13 Jan 2004 03:26:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgJqU-0000i6-00 for; Tue, 13 Jan 2004 03:24:19 -0500
Received: from ([]) by ietf-mx with esmtp (Exim 4.12) id 1AgJox-0000cp-00 for; Tue, 13 Jan 2004 03:22:43 -0500
Received: from ( []) by (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0D8MCe00626 for <>; Tue, 13 Jan 2004 03:22:12 -0500 (EST)
Received: by with Internet Mail Service (5.5.2653.19) id <ZL73D3KG>; Tue, 13 Jan 2004 03:22:12 -0500
Message-ID: <>
From: Sharon Chisholm <>
Subject: RE: [Entmib] Comments on draft-ietf-entmib-state-02.txt
Date: Tue, 13 Jan 2004 03:22:12 -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
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: IETF Entity MIB WG <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


Thanks Keith for the detailed review. I have created issues 307-312 to
capture the individual issues you have raised. 

Here's my initial thoughts on one of the items.

307: 'notSupported' is semantically wrong 

There are three issues here

1. The name 'notSupported'

A term like 'notReportable' might be more accurate. Depending on point
307-3, I could go either way.

2. Compliance of implementations that list all values as 'notSupported'

Interesting question. It was felt we needed this enumeration to cover the
case when certain status could not be reported. Otherwise you end up with
holes. I suppose we either allow the case where people just list
'notSupported' for all states for all entities, or we put something in the
compliance statement indicating that at least one state should have a value
other than 'notSupported'. Again, I could go either way.

3. Description in TC versus Object.

The intention is that these TCs could be used in other MIBs so we were
trying to not pollute them with any Entity specific concept. As a result,
there is quite a bit of description in objects themselves. That having been
said, moving text to each TC to the effect of "A value of 'notApplicable'
means that this resource is unable to report [this] state." This doesn't
really affect this MIB, but would make for better consistency across other
MIBs using these TCs.



-----Original Message-----
From: Keith McCloghrie [] 
Sent: Monday, January 12, 2004 4:41 PM
Subject: [Entmib] Comments on draft-ietf-entmib-state-02.txt

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
>   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
>   I'd look for the knob by which I could issue the enable command to
>   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
>   could be unlocked, and vice versa.
>   'underRepair' is an operState, not an AlarmState.
>   from what perspective are the alarms classified as
>   e.g., does a particular fault have the same alarm status in
>   as it does in 'hotStandby' or in 'providingService' ??  (hint: the
>   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
>   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,
>   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

Entmib mailing list