Re: [Entmib] FW: [psg.com #309] AutoReply: Operational State Names and Concepts

HI,

First, 
implementing this object to match the semantics of X.731 will be difficult
(if not impossible) if the hardware was not designed this way. And
for some hardware (such as a power supplys) it may not be economically
feasible to implement. (On a power supply, it may "disabled" by
disconnecting the input power. If so, you cannot determine if
it is working (that is, delivering output power within it's
rated range) unless you supply input power. You could fake the
oper state value by saving the last value of oper state when admin
state was "unlocked" and returning it while the admin state is "locked".)

Because of this issue, I believe that a new value needs to be added,
such as "disabledDue2Admin". Also, the other values for object
IF-MIB::ifOperStatus should be added. These values are:
      testing(3),   -- in some test mode
      unknown(4),   -- status can not be determined
                              -- for some reason.
      dormant(5),
      notPresent(6),    -- some component is missing
      lowerLayerDown(7) -- down due to state of
                                  -- lower-layer interface(s)
But "lowerLayerDown" which be renamed to "containedNotEnabled".

Secondly, I would name the terms "up" and "down" instead of
"enabled" and "disabled", since enabled/disabled seem to be
admin status and not operational state!

Thirdly, the relationship between values of contained entities
needs to be defined. (Object IF-MIB::ifOperStatus supports this.)    

At 02:17 PM 2/11/2004 -0500, Sharon Chisholm wrote:
>The following is the proposed resolution to entstate-309. The issue will be
>considered closed pending the proposed edit being done.
>
>Add the following text to entStateOper 
>
>"Note that some implementations may not be able to accurately report
>entStateOper while the entStateAdmin object has a value other than
>'unlocked'.  In these cases, this object MUST have a value of
>'notReportable'."
>
>Sharon
>
>-----Original Message-----
>From: entity-state [mailto:rt+entity-state@rt.psg.com] 
>Sent: Tuesday, January 13, 2004 2:57 AM
>To: Chisholm, Sharon [CAR:0S00:EXCH]
>Subject: [psg.com #309] AutoReply: Operational State Names and Concepts
><clip>
>
>-------------------------------------------------------------------------
>Keith McCloghrie [kzm@cisco.com]
>
>"'enabled' and 'disabled' to me imply that an admin state, i.e., if
>>   I saw an operState of 'disabled', or a entStateOperDisabled
>notification,
>>   I'd look for the knob by which I could issue the enable command to
>enable
>>   it again.
>
>>   for most things, I believe you have to turn them on to see if they
>work;
>>   if they don't work, you can turn them off again, and label
>them "inoperable",
>>   but what that means is that they were inoperable the last time they
>were
>>   turned on, and it doesn't necessarily mean they are still
>inoperable, e.g.,
>>   if something was inoperable the last time it was turned on and has
>just
>>   been repaired, but not yet turned on again, is it still
>inoperable ??
>>   That is, neither 'disabled' nor 'inoperable' is the right term for
>> operState.
>
>"
Regards,
/david t. perkins 

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