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

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 12 Feb 2004 14:46:42 -0500

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

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

_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Feb 2004 14:48:03 +0100

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Feb 2004 14:48:03 +0100

/js