Re: [Entmib] WG LAST CALL: draft-ietf-entmib-state-05.txt

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Sep 22, 2004 at 10:13:52AM -0400, Margaret Wasserman wrote:
> 
> Sharon has updated the Entity State MIB to include the issue 
> resolutions discussed in San Diego and confirmed on the mailing list 
> in mid-August.
> 
> The new version can be found at:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-entmib-state-05.txt
> 
> This is an official WG Last Call of the Entity State MIB.  Please 
> review this document to determine if the issues have been addressed 
> properly.

I have reviewed draft-ietf-entmib-state-05.txt. I generally like the
MIB and support it going forward. Still, I did find a number of nits
that need to be addressed.

a) Section says:

     Usage state indicates whether or not the entity is in use at a
     specific instance, and if so, whether or not it currently has spare
     capacity to serve additional users. In the context of this MIB, the
     user is equivalent to an entity, so this term is substituted. This
     state refers to the ability of the entity to service other entities
     within its containment hierarchy.

   I think this can be made shorter without loosing significance:

     Usage state indicates whether or not the entity is in use at a
     specific instance, and if so, whether or not it currently has spare
     capacity to serve additional users. In the context of this MIB, the
     usage state refers to the ability of an entity to service other 
     entities within its containment hierarchy.

   But I do not feel strongly about this change. (I just found the
   term substitution a bit awkward.)

b) I suggest to replace 'status' with 'states' in the sentence below:

     In addition to those alarm status defined in
     X.731 [X.731], warning and indeterminate status are also defined to
     provide a more complete mapping to the Alarm MIB [Alarm-MIB].

c) I suggest to remove the following sentence from section 2.1:

     This raises some interesting issues not addressed
     in existing work on state management [X.731].

   Rationale: Only one issue is mentioned and not multiple and it is
   not really relevant whether X.731 addresses the same issue or not.

d) I fail to understand the following sentence in section 2.4:

     This MIB makes no effort to standardize on the behaviours and
     characteristics of the various physical classes [RFC2737], but
     rather how this information is reported. 

   My problem is that I do not really know what "this information"
   refers to. Also note that you should be using "MIB module" rather
   than MIB if you refer to the module. And since there are two
   modules, it is even unclear which one you mean.

e) I know we have beaten this horse, but still I do not really
   understand why there are actually two MIB modules. Having two MIB
   modules only has an advantage if (a) the TCs progress faster on the
   standards track than the state MIB module or (b) some other module
   uses the TCs while the state MIB itself goes to historic. I find
   both scenarios rather unrealistic and hence you argue to simply put
   the TCs into the state MIB module.

f) If we keep the TC module, we may want to follow the MIB review
   guidelines and call the module ENTITY-STATE-TC-MIB (see Appendix
   C of the MIB review guidelines ID).

g) In the ENTITY-STATE-TC module, replace

         This MIB defines a state textual conventions.

   with

         This MIB defines state textual conventions.

h) You may want to decide where you like spaces between the name of
   and enumerated number and the value or not. Right now, this is done
   differently throughout the module.

i) In the EntityOperState description, should it not be "therefore"
   instead of "there fore"?

j) The second paragraph in the description of the EntityAlarmStatus
   object seems to be garbled.

            When no bits of this attribute are set, then none
            of the value of under repair is set, the resource is
            currently being repaired, which depending on the
            implementation, may make the other values in this bit
            string unreliable.

   Note sure how to repair the beginning. Also, the notion of an
   unreliable bit might confuse readers. Perhaps you want to say that
   the other bits are not meaningful or something like that.

k) Missing final dot in the description of entStateLastChanged.

l) I suggest to move the first sentence of the second paragraph in the
   description of entStateAdmin to the beginning of the text of the
   description clause. Furthermore, I think 'notSupported' must be
   replaced by 'unknown'. So the first two paragraphs of the
   description clause would read like this:

         The administrative state for this entity. This object
	 refers to an entity's administrative permission to 
         service both other entities within its containment 
         hierarchy as well other users of its services defined 
         by means outside the scope of this MIB.

         Setting this object to 'unknown' will result
         in an 'inconsistentValue' error. For entities that
         do not support administrative state, all set
         operations will result in an 'inconsistentValue' 
         error.

   Also note the addition of the final dot.

m) You do not mention 'testing' in the description of the entStateOper
   object.

n) Description of entStateAlarm:

         "The alarm status for this entity. It does not include
          the alarms raised on child components within its
          containment hierarchy.

          Note that this differs from 'indeterminate' which
          means that that alarm state is supported and there
          are alarms against this entity, but the severity of
          some of the alarms is not known.

   I fail to see to what "this" in the beginning of the second
   paragraph refers to.

o) In the two notifications, you talk about the transition disabled ->
   enabled or enabled->disabled. Is testing->enabled not also
   possible?  Should these notifications not be generated whenever you
   transition into the enabled / disabled state, regardless what the
   previous state was? In both notification definitions, I also fail
   to understand the last sentence.

   Here is a concrete proposal for new wordings:

         "An entStateOperEnabled notification signifies that the
          SNMP entity, acting in an agent role, has detected that
          the entStateOper object for one of its entities has 
	  transitioned into the 'enabled' state.

          The entity can be identified by extracting the
          entPhysicalIndex from one of the variable bindings. The
          entStateAdmin and entStateAlarm varbinds may be examined to
          find out additional information about the administrative
          state at the time of the state transition as well to find
          out whether any alarms against the entity were pending at
          that time of the transition."

         "An entStateOperDisabled notification signifies that the
          SNMP entity, acting in an agent role, has detected that
          the entStateOper object for one of its entities has 
	  transitioned into the 'disabled' state.

          The entity can be identified by extracting the
          entPhysicalIndex from one of the variable bindings. The
          entStateAdmin and entStateAlarm varbinds may be examined to
          find out additional information about the administrative
          state at the time of the state transition as well to find
          out whether any alarms against the entity were pending at
	  that time of the transition."

   This is shorter and hopefully clearer as the current text.

p) The notification are optional. Should there be any further
   guideline under which conditions implementations should support
   them?

q) I suggest to remove the following phrase from the security
   considerations section:

   ... ranging from those running on a port to those on an entire
   device, depending on the type of entity

   I think disruption of service is good enough and says all. Note
   that even disabling a port may not even lead to disruption of
   service if there are for example backup paths that get activated
   automatically (e.g., re-computation of a spanning tree in a bridged
   LAN).

r) There is no need to import TEXTUAL-CONVENTION if the MIB modules
   are split into a TC module and one containing object/notification
   definitions.

/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