RE: [Entmib] Entity comments

"Sharon Chisholm" <schishol@nortelnetworks.com> Thu, 25 March 2004 14:40 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 JAA25142 for <entmib-archive@lists.ietf.org>; Thu, 25 Mar 2004 09:40:47 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W1r-0005rc-2H; Thu, 25 Mar 2004 09:40:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6W1L-0005m5-Ne for entmib@optimus.ietf.org; Thu, 25 Mar 2004 09:39:47 -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 JAA25014 for <entmib@ietf.org>; Thu, 25 Mar 2004 09:39:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6W1F-0002RQ-00 for entmib@ietf.org; Thu, 25 Mar 2004 09:39:41 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6W0E-0002Fy-00 for entmib@ietf.org; Thu, 25 Mar 2004 09:38:39 -0500
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1B6Vy4-0001h7-00 for entmib@ietf.org; Thu, 25 Mar 2004 09:36:24 -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 i2PEZqR09088 for <entmib@ietf.org>; Thu, 25 Mar 2004 09:35:52 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <GXT6J0B7>; Thu, 25 Mar 2004 09:35:53 -0500
Message-ID: <3549C09B853DD5119B540002A52CDD340A9D2E92@zcard0ka.ca.nortel.com>
From: "Sharon Chisholm" <schishol@nortelnetworks.com>
To: entmib@ietf.org
Subject: RE: [Entmib] Entity comments
Date: Thu, 25 Mar 2004 09:35:52 -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

Ok, I this isn't really response to Dave's email so much as leveraging his
summary of events to step back and have a high-level discussion which
affects a number of issues.  

I think I'll open a new issue to track this. I think if we get consensus on
this, a number of other issues fall out of that.

<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>

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.

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.

Where do people think we should be?

Sharon

_______________________________________________
Entmib mailing list
Entmib@ietf.org
https://www1.ietf.org/mailman/listinfo/entmib