Re: [Entmib] Entity comments

"Randy Presuhn" <> Thu, 25 March 2004 20:09 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA17340 for <>; Thu, 25 Mar 2004 15:09:44 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1B6bAD-0007wt-Hu for; Thu, 25 Mar 2004 15:09:17 -0500
Received: (from exim@localhost) by (8.12.8/8.12.8/Submit) id i2PK9HTJ030474 for; Thu, 25 Mar 2004 15:09:17 -0500
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1B6bAB-0007v1-OP; Thu, 25 Mar 2004 15:09:15 -0500
Received: from ([] by with esmtp (Exim 4.20) id 1B6b8c-00077q-CA for; Thu, 25 Mar 2004 15:07:38 -0500
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA17063 for <>; Thu, 25 Mar 2004 15:07:34 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1B6b8Z-00045X-00 for; Thu, 25 Mar 2004 15:07:35 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6b7d-00042L-00 for; Thu, 25 Mar 2004 15:06:38 -0500
Received: from ([]) by ietf-mx with esmtp (Exim 4.12) id 1B6b72-0003zE-00 for; Thu, 25 Mar 2004 15:06:00 -0500
Received: from ([] helo=oemcomputer) by with smtp (Exim 3.33 #1) id 1B6b72-0000qk-00 for; Thu, 25 Mar 2004 12:06:00 -0800
Message-ID: <004501c412a4$f73e2c80$7f1afea9@oemcomputer>
From: Randy Presuhn <>
References: <>
Subject: Re: [Entmib] Entity comments
Date: Thu, 25 Mar 2004 12:08:40 -0800
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
X-Spam-Status: No, hits=0.0 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: <>, <>

Hi -

> From: "Sharon Chisholm" <>
> To: <>
> Sent: Thursday, March 25, 2004 6:35 AM
> Subject: RE: [Entmib] Entity comments
> <Dave>
> 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.
> </Dave>

This list really needs usageState to be internally consistent.

> So, in the beginning we evaluated our options for creating states and agreed
> there was value in leverage the OSI (X.731) state work rather than
> re-inventing the wheel, but as Dave indicated we said we would make
> modifications as we deemed appropriate. We have done this, mainly through
> only picking the states we thought were useful, the addition of enumerations
> to the states and additional descriptions of their application to our
> problem domain.
> Where we have ended up is we are somewhere in between the using the OSI
> states and doing our own thing, perhaps leaning more towards the OSI side.
> The positioning in this spectrum has affected the proposed resolutions to a
> number of issues around naming. Even though these don't affect functionality
> at all, people seem to feel strongly about them. (Yes, there are other
> issues which do affect functionality, but that's not what I'm talking about
> here). Here are the high level issues
> 1. Prefixing the TCs with ITU prefix. The answer to this depends on where we
> are in that spectrum.

I'd rather not see an ITU prefix, even though I prefer that the semantics be
aligned as closely as practical with the ISO / ITU semantics.

> 2. Renaming state values. While I don't really see the value in changing the
> name of the state values, if that is consensus, then that it what we should
> do. If we do go down this path, we will have to add a section that describes
> the mapping from OSI states.

This seems unnecessarily confusing.

> Where do people think we should be?

I think that differences in the underlying object models will prevent perfect
equivalence.  However, we can come pretty close to matching the semantics
of the core of X.731.  These attributes have proven useful in the many years
they've been in use.  I think the document is on the right track.


Entmib mailing list