RE: FW: [psg.com #309] AutoReply: Operational State Name s and Concepts

The following is the proposed resolution to entstate-309. The issue will be
considered closed pending the proposed edit being done.

[Note that this text may be influenced by the resolution of other issues.]

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

Related to the additional points that Dave brought up. We just need to make
sure we provide sufficient guidance for how to report status if available,
or if it is not. I think we've covered the case where entities can't report.
Section 3.1 already covers the relationship between this MIB and the
interfaces MIB. I'm still not convinced that 'enabled' is that different
than 'up.

As for the other states: I swear we've discussed this already, but I can't
find it. Personally, I like the cleanness of a two state operational state
where additional information is found in supplemental objects, but I'm sure
we can agree on a compromise. So, we already have 'unknown'.
'lowerLayerDown' is a computed state so out of scope.  'notPresent' can
easily be computed via inventory information. 'dormant' could be considered
comparable to the usage object in some ways. That leaves us with 'testing'.
We could add that one.

Add the following enumeration to OperState  
    testing (4)

And he following text to the OperState Description

"A value of 'testing' means the resource is currently being tested 
and cannot there fore report whether it is operational or not."

Sharon

-----Original Message-----
From: David T. Perkins [mailto:[email protected]] 
Sent: Thursday, February 12, 2004 5:13 PM
To: Chisholm, Sharon [CAR:0S00:EXCH]; [email protected]
Subject: 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:[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.
>
>"
Regards,
/david t. perkins