FW: [psg.com #309] AutoReply: Operational State Names and Concept s

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

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

"