Re: [Entmib] Entity comments

Hi -

> From: "Sharon Chisholm" <schishol@nortelnetworks.com>
> To: <entmib@ietf.org>
> Sent: Thursday, March 25, 2004 6:35 AM
> Subject: RE: [Entmib] Entity comments
...
> <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>

This list really needs usageState to be internally consistent.

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

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.

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

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

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