Entity comments

HI,

In general, it has seemed to me that in the beginning and at the last few
ENITITY MIB WG meetings that the consensus desire was to have a simple
extension to the entity physical table with the following:
  adminState - to indicate the administrative state of a physical
               component, and allow change
  operState - to indicate the operational state of a physical component
  backupState - to indicate if a physical component was backing up
                  another physical component
  alarmStatus - to indicate current fault conditions (if any) were
                  present on a physical component
A small minority wanted to base the definitions on X.731 definitions.
However, the majority felt that was OK only if the above needs were not
impacted, and the cost to support the objects on an agent was not
significantly impacted.

To me, the resulting definitions have not met the rough consensus
needs. In addition, the document (and its yet to be sent out
update) is not internally consistent.

The entity state document is quite small, and I can provide a complete replacement, if the WG wants one. However, to follow the process, here
are responses to the outstanding issues. I believe that these might
be difficult to evaluate due to the missing context. But here it goes...

#306 & #325: descriptor naming and OID tree
  Please, lets follow current standard layout as determined by Bert

#307: not-supported is wrong
  I agree with Keith and Juergen. Either "unknown" or "unavailable"
  is fine with me.
  However, what is a BIG problem is the text in the DESCRIPTION
  clauses using the term "unreportable". This is wrong. That is,
  the term "unreportable" MUST be removed from the DESCRIPTION
  clauses and a semantically correct term must be used.

#308 & 312: admin state enum values
  I agree with Keith and Juergen.  Also, a radical approach is
  to remove the object altogether. However, if the object is kept,
  then I suggest the following enum values:
    up - action(to set to up) and state(is administratively up)
    down - action(to force set to down) and state(is administratively down)
    gracedown - action(to gracefully set to down)
    shuttingdown - state(in process of gracefully shutting down)
    testing - state(in test mode. requires other specific means to
                  put in a test mode)
  (and if it's not obvious, then I can provide a state diagram, like
   that found for RowStatus TC)

#309 & #332: Oper State enum names
  I agree with Keith. I also have problems with the values being
  semantically different from ifOperStatus. And, to really simplify,
  I suggest that the standby status object be removed, and it's
  values be combined. The resulting enum values would be:
    unknown - state unknown
    up - working OK
    down - not working (a failure)
    downDueToAdmin - not working since turned off and cannot tell if
                          could work if administratively turned on
    downDueToContained - not working due to contained component
    testing - in a test mode
    coldStandby - backing up a component, and may be able to provide
                      service after some initialization activity
    hotStandby - backing up a component, and will be able to immediately
                      provide service without need for initialization 
  NOTE: in X.731, the value of operState is independent of the value
    of adminState. However, for many real-world physical devices,
    one cannot determine the operState without "turning on" the
    component. So the above is a compromise. That is, if a component
    operState follows adminState (like as done by ifOperStatus),
    then value 'downDueToAdmin' would be used (when appropriate).
    And if independent, then 'down' would be used (when appropriate).  

#310: Alarm Status values
  The resolution must include a value when the operState value is
  'testing'. The resulting BITs should be something like:
      unknown - status unknown (if set, then no other bits may be set)
      underRepair - item under repair
      underTest - item being tested
      critial - one or more critical fault conditions present
      major - one or more major fault conditions present
      minor - one or more minor fault conditions present
      warning - one or more warning fault conditions present
      indeterminate - one or more indeterminate fault conditions present   
  Note: when 'underRepair' or 'underTest' BITs are set, then
      the manager should probably "discount" the importance
      of any outstanding fault conditions

#311 - Initial DateTime value
   I agree with Keith and Juergen.

#312: (see #308 above)

#322: TC Names
   I agree with Andy and Juergen. And believe that the prefix
   should be EntPhys (that is not just Entity)!

#325: (see #306 above)

#326: Too many objects
  I agree with andy.
  The Usage object provides no additional info (that is, its value
  can be determined by looking at other objects in the EntPhysical table),
  and should be removed. The standby object can be deleted, and its
  values folded into oper State.

#327: Editorial edits
  I agree with Juergen that the document needs language fixes.
  In addition to what he points out, I believe the following
  modifications are needed:
    a) The term "report" must be replaced with an appropriate
       one through out the document
    b) X.731 needs to be removed from the REFERENCE clauses,
       and X.731 needs to be changed from a normative reference
       to an informative reference
    c) X.721 and X.732 need to be added as informative references
    d) the alarm MIB needs to be changed from an normative reference
       to an informative reference

#328: Definition of "contained in"
  I agree with Juergen that this needs to be well defined.
  And I previously specified a definition that I believe
  is sufficient.

#329: Problems with usage state
  Remove the object. See #326 above.

#330: Notification varbinds
  This needs review and update after update of enum values for
  operState. 

#332: Standby State issues
  See #326 and #309 above.

#333: Relationship with alarm MIB
  The reported problem was not address. Said another way,
  the Entity State MIB SHOULD NOT depend on the support of
  the Alarm MIB. And the Alarm MIB RFC should be an informative
  and NOT a normative reference.

#334: Table index Description
  The SMI (RFC 2578, last para of section 7.7) requires a description
  of the index. Also, I would add text explaining that typically
  instances with physical class of chassis, backplane, container
  and stack do not have status instances, where typically instances
  powerSupply, fan, sensor, module, and port do have status instances.
  However, they may not support modification of admin state.

#335a: Clarification of notification generation
  The resolution didn't add clarity. That is, can multiple
  notifications be generated for a single event. (I think so,
  but I'm not sure that other reviewers noticed this.)

#335b: Need for notification on change of Standby state
  From my previous experience, each protection switch was an
  important event and thus a notification is appropriate.

Regards,
/david t. perkins