Re: [Entmib] FW: [psg.com #329] AutoReply: Usage State Scope

"David T. Perkins" <dperkins@dsperkins.com> Fri, 13 February 2004 07:23 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 CAA25527 for <entmib-archive@lists.ietf.org>; Fri, 13 Feb 2004 02:23:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXfB-0006Tu-TR; Fri, 13 Feb 2004 02:23:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArXez-0006RO-GN for entmib@optimus.ietf.org; Fri, 13 Feb 2004 02:22:49 -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 CAA25464 for <entmib@ietf.org>; Fri, 13 Feb 2004 02:22:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXes-0001U7-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:22:42 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArXdv-0001Pz-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:21:44 -0500
Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArXdZ-0001M1-00 for entmib@ietf.org; Fri, 13 Feb 2004 02:21:21 -0500
Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i1D7LG311373; Thu, 12 Feb 2004 23:21:16 -0800
Message-Id: <5.2.0.9.2.20040212231949.01f905b0@127.0.0.1>
X-Sender: dperkins@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 12 Feb 2004 23:21:10 -0800
To: Sharon Chisholm <schishol@nortelnetworks.com>, entmib@ietf.org
From: "David T. Perkins" <dperkins@dsperkins.com>
Subject: Re: [Entmib] FW: [psg.com #329] AutoReply: Usage State Scope
In-Reply-To: <3549C09B853DD5119B540002A52CDD340A24445E@zcard0ka.ca.norte l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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,

I don't see a use for the usage state. As currently defined, it's
value is easily computed.

At 02:46 PM 2/12/2004 -0500, Sharon Chisholm wrote:
>The following is the proposed resolution to entstate-329. The issue will be
>considered closed with no changes made to the document.
>
>Well, this is the one object that most directly relates to its child
>component. Our definition only talks about child components in terms of
>physical entities. So, the ability of a port to 'contain' an logical
>interface isn't reported by this status. I might be convinced to change the
>definition but I think this concepts starts getting harder to describe and
>understand when we start mixing physical containment and logical to physical
>mappings. 
>
>I worry that talking about leafs and containers might confuse people. The
>current definition speaks in terms of whether something else can be
>contained in it. This is more consistent with the rest of the discussion.
>
>Sharon
>-----Original Message-----
>From: rt+entity-state@rt.psg.com [mailto:rt+entity-state@rt.psg.com] 
>Sent: Wednesday, February 11, 2004 12:59 PM
>To: Chisholm, Sharon [CAR:0S00:EXCH]
>Subject: [psg.com #329] AutoReply: Usage State Scope
>
><clip>
>
>-------------------------------------------------------------------------
>Juergen Schoenwaelder [j.schoenwaelder@iu-bremen.de]
>
>"I was surprised to read the entStateUsage description which says
>   the UsageState is strictly bound to the containment relationship
>   between entities.
>
>   In general, the containment hierarchy is made up of containers and
>   leafs. The entStateUsage description basically says that the
>   UsageState is only interesting for containers since leafs are
>   always busy. I found this interesting since the other objects do
>   not make this distinction and some of them seem to particularly
>   useful for leafs (e.g. interfaces). Perhaps it makes sense to
>   define for each entState* column how it applies to containers and
>   how it applies to leafs. For example, what does it mean to
>   lock/unlock a container? (I believe entStateAdmin is more defined
>   for leafs rather than containers.)"

Regards,
/david t. perkins 


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