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

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: [email protected] [mailto:[email protected]] 
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 [[email protected]]

"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.)"