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

On Thu, Feb 12, 2004 at 02:46:42PM -0500, Sharon Chisholm wrote:
> 
> 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.

I did not propose to use the terms leaf and container - I just tried
to explain my issue and I obviously did not a good job. My point is
that some of the objects and descriptions seem to apply to the function
of a physical entity while others apply to strictly the containment
feature. Lets take for example an entity of class "container" and
an entity of class "port". I think the interpretation of UsageState 
or OperState is totally different for these two entities.

For a container entity, UsageState active means there are still slots
available where I can plug something in. For a port, the entStateUsage
is according to the description busy, regardless of the port's
functional usage state. So this usage state is purely oriented on
the containment hierarchy.

If I look at the entStateOper of a container and a port entity, then
for the container the state enabled probably means that the container 
is active and able to host plugins. A port, from a pure containment
point of view, it should probably be disabled since it can't host
other components. However, from a functional point of view, the
port state is probably coupled to the interface state realized by
that port.

In short: I think the interpretation of the states for the various
entity classes needs to be clarified. (I think Dave also wrote something
in that direction.) Without guidance from the spec, implementations
will just not use the same model and fail to interoperate.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany