Comments on draft-ietf-entmib-state-02.txt

I was asked to post these comments:

Keith.

> the MIB still needs work:
> 
>   the term 'shuttingDown' suggests that the action of shutting down is
>   in progress, which of course is an operational condition, not an admin
>   state.  A term more reflective of what the AdminState DESCRIPTION appears
>   to define would be 'noNewUsage'.  In any case, this concept of 'usage'
>   is almost always a higher-level usage (e.g., a new ATM connection on an
>   ATM interface, a new Unix login on a cpu module, etc.) and thus don't
>   belong at the physical layer (i.e., don't apply to entPhysicalIndex).
> 
>   'notSupported' is semantically wrong, because a compliant implementation
>   obviously supports the MIB, but it can return 'notSupported' for
>   every object in the MIB.  Presumably, the intended semantics is that
>   the agent would return the right value if only it knew the right value;
>   i.e., 'unknown' is the desired semantics.  Also, why is each definition
>   of 'notSupported' defined in an object's DESCRIPTION, not in the TC's
>   DESCRIPTION ?
> 
>   '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.
> 
>   the entities to which this MIB applies are physical entities, and thus
>   it seems natural to apply the term 'locked' in a physcial sense, rather 
>   than a logical sense, i.e., 'locked' is not the right term to use for 
>   administratively disabling a device, because if a device had a physical
>   lock, then its adminState should not be 'locked' if/when its physical lock
>   could be unlocked, and vice versa.
> 
>   'underRepair' is an operState, not an AlarmState.
> 
>   from what perspective are the alarms classified as critical/major/minor/etc.
>   e.g., does a particular fault have the same alarm status in 'coldStandby'
>   as it does in 'hotStandby' or in 'providingService' ??  (hint: the answer
>   is no!!).
> 
>   should the MIB define DateAndTimeOrZero ?  What does zero mean ?
>  
>   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.
>