Subject: RE: [Entmib] Entity comments

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 25 Mar 2004 09:35:52 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 25 Mar 2004 12:08:40 -0800

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, March 25, 2004 6:35 AM
> Subject: RE: [Entmib] Entity comments
...
> impacted, and the cost to support the objects on an agent was not

This list really needs usageState to be internally consistent.

> 1. Prefixing the TCs with ITU prefix. The answer to this depends on where we

I'd rather not see an ITU prefix, even though I prefer that the semantics be
aligned as closely as practical with the ISO / ITU semantics.

> the mapping from OSI states.

This seems unnecessarily confusing.

> Where do people think we should be?
...

I think that differences in the underlying object models will prevent perfect
equivalence.  However, we can come pretty close to matching the semantics
of the core of X.731.  These attributes have proven useful in the many years
they've been in use.  I think the document is on the right track.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 25 Mar 2004 12:08:40 -0800

Hi -

...

...

Randy