Comments on the latest draft

[{3COM/PDD/PeteW}@pdd.3mail.3com.com]

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Chassis MIB
Subject:  Comments on the latest draft
Date: 1993-06-03 11:12
Priority: 
Message ID: D7FC9577
Conversation ID: D7FC9577

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

Comments on the latest Chassis MIB draft.

I think the main part of the chassis MIB is basically correct now. My
main comments are concerned with the power supply and environment
tables. I'm not sure Daves revamped these yet, so I'll comment anyway!

I'll cover the major PSU/Environment comments first.

1) The ChasPowerSupplyTable is no longer required. A power supply is a
module and so will have an entry in the module table. The only
information in this table not also present in the module table are:
            chasPowerSupplyHealthText,
            chasPowerSupplyWarnings,
            chasPowerSupplyFailures.
If these are useful then aren't they useful for any module?

2) The chasPowerSupplyOutputTable nneds to be modified. In the new
model each type of output can be considered a resource of a
particular module. For example suppose there are two PSU modules each
of which have a 12V and 5V output. The model will map this as:

   Module Table              Resource Table                 Entity Table
   ======================================================================
   PSU Module 1 <------- PSU Module 1, Resource 1 -------->  5V PSU Entity
   PSU Module 1 <------- PSU Module 1, Resource 2 --------> 12V PSU Entity
   PSU Module 1 <------- PSU Module 1, Resource 1 -------->  5V PSU Entity
   PSU Module 1 <------- PSU Module 1, Resource 2 --------> 12V PSU Entity

The information in the output table then is extra information for the supply
resources. As such the index on this table should change to be the same
as the resource table (locationType, instance, resourceId).

Another advantage is that the output resource is now identified by
it's location which it was not before. If a supply failed to deliver
correct voltage and there were several 5V resources there was no way to
know which had failed.

3) Sensor Table.
A sensor is also a resource of the chassis. This table needs to change
in a similar way to the power supply output table. The indices should
be locationType, instance and resource. This has the advantage again
that if there are multiple sensors of a particular type, a specific
sensor can be identified by its location.  This also removed the need
for the OID to identify the sensor type (chasEnvironSensor).

Sensors are an interesting chassis concept for the model. Every
resource should map to some entity, but individual entities are only
required to distinguish a particular agent or context. To map sensors
in a chassis simply provide a 'chassis' entity that contains all the
sensors and specifies that they are visible through the same view that
contains the chassis MIB.

ie
   Module Table              Resource Table                 Entity Table
   ======================================================================
   modularSlot.1 <---------------- 1 ----------------------> chassis
   modularSlot.2 <---------------- 1 ----------------------> chassis
   modularSlot.2 <---------------- 2 ----------------------> chassis
   ...

The value to use for chasEntityObjectId for the entity representing
'chassis' things is chasEntity.

I'll send suggested updated table text seperately.

=====================================================================
Now the minor points on the main part of the MIB:

1) As pointed out by someone else, chasPowerSupply is defined twice.
The definition under chasChassisEntities should be changed ot
something like
         chasPowerSource OBJECT IDENTIFIER ...

2) chasMonitors entity type should probably be singluar (chasMonitor).

3) Definitions for chasPowerSource, chasChassis and chasMonitors
should be ::= { chasChassisEntities ... }, not chasChassisTypes.

4) In the location table sequence declaration:
        ChasPhyLocation ::= SEQUENCE {
                ...
                chasPhyLocationName
                ...
should be 'chasPhyLocationDescr', or change the OBJECT-TYPE name.

5) In the modules table
* chasModuleTable DESCRIPTION clause contains a supurfluous 'from'
* SEQUENCE declares chasModuleFwVersion, this should be
  chasModuleSwVersion to be consistent with the OBJECT-TYPE macro
* The DESCRIPTION of chasModuleLocationType requires the
  addition of 'in' after 'location' in the first sentence.
* In the declaration of chasModuleType, 'chasLocationUnknown' should
  be chasModuleUnknown.
* chasModuleAdminStatus contains a value of 'programLoad (5)'. Setting this
  value is probably insufficient to effect a load. It is likely that a
  filename and or server address will be required. It might be useful
  to define a seperate 'system load' table.
* If 'programLoad' is included in the chasModuleAdminStatus then
  chasModuleOperStatus should include a 'loading' state.

6) The chasEntityTable
* needs input on party, context, community usage. We have the issues
  someone raised with regards importing Party and Context in SNMPv1
  implementations.
* chasEntityAdminStatus, programLoad value. Same comment as the module 
table.
  I think that more information will be required.
* In chasEntityParty, I can find no definition for chasEntityNoParty.
  (I think it was in a previous draft). Also the comment says that a
  party is identified by an OBJECT IDENTIFIER rather than a 'Party'.
* Need a chasEntityNoContext value for chasEntityContext if using SNMPv1.

7) The chasPhyResourceTable table currently includes one OBJECT
IDENTIFIER, chasPhyResType. The description of this object says that
this identifies the 'type' of the resource. It also says that this
object can contain the type of an entity to which this resource may be
assigned. Unfortunately these to functions are mutually exclusive. Example:
A repeater port can be assigned to a repeater, a group of repeater
ports can be assigned to a repeater. The values for the resource type
and the type of entity to which that resource may be assigned are:

a) chasPhyResType = chas8023RptrPort   entity type is chas8023Repeater
b) chasPhyResType = chas8023RptrGroup  entity type is chas8023Repeater

An additional object is required to carry this information, for example:

          chasPhyResEntityAssignmentType OBJECT-TYPE
              SYNTAX OBJECT IDENTIFIER
              ACCESS read-only
              STATUS mandatory
              DESCRIPTION
              "Some implementations of the chassis MIB allow a resource to
              be moved between entities through management. For example a
              repeater module may be moved to different repeaters. This
              object acts as a 'hint' to the management card to indicate
              to which type of entity this resource may be assigned. If
              used then the value of this field can be matched to
              entities via the chasEntityObjectID object.

              Note that a value in this column does not mean that this
              resource _can_ be successfully assigned to a particular
              entity, merely that such an assignment is legal. A request
              to change assignment can be rejected due to local 
considerations
              such as insufficient resource."
              ::= { chasPhyResourceEntry ?? }

Also the part of the description of chasPhyResType that refers to
import of value from RFC1204 is incorrect and should be removed.

8) Minor points in chasPhyResourceTable.
* DESCRIPTION of chasPhyResLocationType needs 'by' to be added between
  'defined' and 'location'.
* Ditto for chasPhyResLocation.
* The DESCRIPTION clause of chasPhyResAssignment is incorrect. A
  correct form might be:
                      "The physical module resource is
                      assigned to a specific entity.  This object
                      defines the entity to which this resource is
                      currently assigned.

                      Notice, not all implementations may support this
                      object as read-write.  If read-write is supported
                      assignment may still fail due to a number of
                      reasons such as insufficient resources, invalid
                      configuration."

9) chasLogResourceTable. Suggest the following variable name changes
for consistency with the chasPhyResourceTable:
    chasLogResourceEntity            --->  chasLogResEntity
    chasLogResourceEntitySubIndex    --->  chasLogResEntitySubIndex
    chasLogResourceLocation          --->  chasLogResLocation
    chasLogResourceID                --->  chasLogResIndex