RE: [Entmib] Comments on draft-ietf-entmib-state-02.txt

["Sharon Chisholm" <[e-mail]>]

Hi

Thanks Keith for the detailed review. I have created issues 307-312 to
capture the individual issues you have raised. 

Here's my initial thoughts on one of the items.

-----------------
307: 'notSupported' is semantically wrong 

There are three issues here

1. The name 'notSupported'

A term like 'notReportable' might be more accurate. Depending on point
307-3, I could go either way.

2. Compliance of implementations that list all values as 'notSupported'

Interesting question. It was felt we needed this enumeration to cover the
case when certain status could not be reported. Otherwise you end up with
holes. I suppose we either allow the case where people just list
'notSupported' for all states for all entities, or we put something in the
compliance statement indicating that at least one state should have a value
other than 'notSupported'. Again, I could go either way.

3. Description in TC versus Object.

The intention is that these TCs could be used in other MIBs so we were
trying to not pollute them with any Entity specific concept. As a result,
there is quite a bit of description in objects themselves. That having been
said, moving text to each TC to the effect of "A value of 'notApplicable'
means that this resource is unable to report [this] state." This doesn't
really affect this MIB, but would make for better consistency across other
MIBs using these TCs.

--------------

Sharon 

-----Original Message-----
From: Keith McCloghrie [mailto:[e-mail]] 
Sent: Monday, January 12, 2004 4:41 PM
To: [e-mail]
Subject: [Entmib] 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.
> 

_______________________________________________
Entmib mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/entmib

_______________________________________________
Entmib mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/entmib