Re: REMINDER: [Entmib] WG Last Call: Entity State MIB

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Feb 05, 2004 at 04:11:40PM -0500, Margaret Wasserman wrote:
 
> Just a reminder that we are currently in WG Last Call for the
> Entity State MIB.  Please review this document before Friday
> and send your feedback (positive or negative) to the list.

I could not get email out during the weekend. Anyway, here is what I
wrote down on this subject...

I have reviewed <draft-ietf-entmib-state-02.txt> and I like the
approach, as I have already said before. Below are some review
comments to take into account. Most are just editorial while some
might require some further discussion/thinking.

1) Change the end of the abstract from

	provide information about the state of the entity.

   to the following:

	provide information about the state of physical entities.

   Rationale: This MIB is specific to physical entities and since the
   ENTITY-MIB also has the concept of logical entities, I think it is
   better to more precise.

2) Description of StandByStatus, change

	"... but is will be immediately ..." 

   to the following:

	"... but will be immediately ..."

3) Description of entStateLastChanged, change 

   DESCRIPTION "The value of this object is the date and
               time when state/status of the entity
               last changed, or zero."

   to the following:

   DESCRIPTION "The value of this object is the date and
               time when state/status of the entity
               last changed, or '0000000000000000'H."

4) Description of entStateAdmin. I believe the following two sentences
   are kind of a contradiction:

             [...] This object can not
             be administratively set to 'notSupported'. For
             entities that do not support administrative state,
             changing the value of this object to something other
             than 'notSupported' is not permitted.  A value of
             'inconsistentValue' will be returned in either case.

   With the text in the second paragraph of the description clause, I
   think this can be fixed by just removing a sentence without loosing
   anything:

             [...] This object can not
             be administratively set to 'notSupported'. A value of
             'inconsistentValue' will be returned in either case.

5) Several description clauses refer to "entities within its
   containment hierarchy" followed by a sentence which limits this to
   the entities "having a value of entPhysicalContainedIn that refers
   to this entity". This somehow excludes transitive containment. Is
   this by intention or accident? I mean, if I have C contained in B
   contained in A, then A still provides indirect service to C.

6) AlarmStatus TC: I do not really understand the alarmOutStanding
   bit.  It seems like this is set whenever one of critical, major,
   minor, warning and indeterminate is set. But if this is true, I
   think the bit is not really terrible useful.

   Perhaps the bit has some other meaning. If so, please clarify.

7) The MIB did not compile because you once use
   entStateNotificationGroup and once you use
   entStateNotificationsGroup (see the plural s). Pick one.

8) I was surprised to read the entStateUsage description which says
   the UsageState is strictly bound to the containment relationship
   between entities.

   In general, the containment hierarchy is made up of containers and
   leafs. The entStateUsage description basically says that the
   UsageState is only interesting for containers since leafs are
   always busy. I found this interesting since the other objects do
   not make this distinction and some of them seem to particularly
   useful for leafs (e.g. interfaces). Perhaps it makes sense to
   define for each entState* column how it applies to containers and
   how it applies to leafs. For example, what does it mean to
   lock/unlock a container? (I believe entStateAdmin is more defined
   for leafs rather than containers.)

9) I am wondering why both notifications contain the entStateAlarm
   value, especially entStateOperEnabled notification. This surely is
   not wrong, but I am wondering what the rationale for including the
   entStateAlarm is (and for excluding other objects).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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