Chassis MIB comments

[David Perkins <[e-mail]>]

Following is a long list of comments on the chassis MIB.

/dave perkins, synoptics, 408-764-1516
-------------------------------------------------------
Notes on Chassis MIB, October 13 version.
   dtp - 10/13/92, 10/15/92


1) DisplayString and Counter must be Imported in the MIB.

2) Last of section 2, comments should be sent to the
WG ([e-mail]) and not just a subset of the
authors!

3) Quite a bit of section 5 needs to be rewritten!

4) Here is a suggested rewrite for section 5 (5.0) 

  This memo defines objects for the management of a chassis
  containing multiple slots. Each slot may contain a physical
  module. Each physical module may contain a part of a device,
  a complete device, or multiple devices. A device may be
  a network device such as a router, bridge, terminal server,
  repeater, or management card or a chassis support device
  such as a power supply or fan. This memo uses the term
  'entity' to refer to a device.

  This type of chassis often contains one or more internal
  segments through which the entities are inter-connected
  to each other.  These segments often use standard MAC and/or
  link-layer protocols even though their physical layer may be
  different to that normally used with that MAC or link-layer.
  The segments may be completely proprietary and may also
  correspond to non-network connections such as power or
  cooling.

  This MIB contains four tables: the Slot Table, the Entity
  Table, the Segment Table, and the Chassis Configuration Table.
  The remainder of this section will discuss the contents of
  these tables.

  In an effort to clarify the contents of the 4 tables the
  following example is presented.  The discussion of each table
  will refer to this example:


5) The example needs to be labled as section 5.1 and the
existing sections need to be renumbered.

6) The example needs to be made more comprehensive. Consider
the follow revision:

  5.1.  Example Chassis

  Consider a simple 8 slot chassis that contains a bridge,
  2 repeaters, a terminal server, router, and a power supply.
  The chassis is organized as follows:

    Slot  Entity  Segment  Device
      1     2        1     Bridge - one slot, two connections
      1     2        2
      3     1        1     Repeater - two slots, two connections
      4     1        1
      5     3        2     Repeater - one half a slot, one connection
      5     4        1     Terminal server - one half a slot, one conn
      6     5        1     Router - two slots, two connections on first
      6     5        2              slot and none on second slot
      7     5        0     
      8     6        0     Power supply - one slot, no connections   

7) Section 5.1 needs to be renumberd and cleaned up something
like the following:

  5.2.  The Slot Table

  The slot table that contains information about the physical
  modules in the chassis. The conceptual rows in this table
  correspond to slots in the chassis.  For those slots that
  do not contain a physical module, the table may be implemented
  to contain a conceptual row with the identity of the physical
  module set to "empty" or may be implemented to have no
  conceptual row instance.

  The example above shows an 8 slot chassis. Notice that slot
  2 is empty and all the other slots contain a physical module.
  The slot table may be implemented to have 8 conceptual
  rows (complete) or 7 rows (sparse).

  Implementation of the slot table is mandatory.


8) Section 5.2 needs to be renumbered and cleaned up something
like the following:

  5.3.  The Entity Table

  The entity table contains information about the entities in
  a chassis.  In addition it defines the means to access a MIB
  view for each such entity, if access is possible.  These may
  be addressed either by the combination of chasEntityCommunity
  and chasEntityIPAddress or by chasEntityParty.

  Using the above example the entity table will have 6
  conceptual rows, one for each entity. In the example
  the entities are 2 repeaters, a bridge, a terminal server,
  a router, and a power supply.

  Implementation of the entity table is optional.


9) Section 5.3 needs to be renumbered and cleaned up something
like the following:

  5.4.  The Segment Table

  The segment table contains information about the segments,
  contained within the chassis, and used to interconnect the
  chassis's entities.

  Using the above example this table would contain 2 conceptual
  rows, one for each segment.

  Implementation of this table is mandatory.


10) Section 5.4 needs to be renumbered and cleaned up something
like the following:

  5.5.  The Chassis Configuration Table

  The chassis configuration table contains the mapping of
  entities to segments.

  The objects, chasConfigIndexType and chasConfigIndexValue
  provide linkage from an entity's segment connection in this
  MIB to the management information contained in the entity's
  own MIB.  In particular, these objects indicate that the
  particular segment connection of the entity in the slot
  represented by this conceptual row is identified within the
  entity's MIB by the object type named by chasConfigIndexType
  having the value given by chasConfigIndexValue.

  It is an implementation specific matter whether the
  chasConfigTable is implemented to allow creation and/or
  deletion of conceptual rows.

  Using the above example the configuration table would contain
  10 conceptual rows.  One for each slot, entity, segment
  combination defined in the example above.  The first
  conceptual row would define the bridge entity in slot 1 with
  chasConfigIndexType of bridge port and chasConfigIndex value
  of 1.  The other conceptual rows would be similar defining the
  bridge port and repeater ports.

  Implemenation of this group is optional.


11) A new section needs to be added to describe the
chassis description objects. An example would be the
following:

  5.6.  Chassis Description

  The chassis description group contains information about
  the physical chassis.

  Implementation of this group is mandatory.


11) Section 5.5 needs much work to be complete. The 
approach about virtualizing a physical chassis into
a logical chassis seems interesting. However, the model
and values for the MIB objects do not seem to support it.
Several concrete examples need to be given. One needs to
show a hierachical organization of several layers and
the values of the objects at each layer. What do
segments map into with a virtual chassis? What are
the values for the following objects when a multi-level
virtual chassis is used: chasSlotModuleType,
chasSlotLastChange, chasSlotModuleVersion,
chasSlotModuleSerialNumber, chasEntityFunction,
chasEntityFunction, chasEntityObjectId,
chasEntityVersion, chasEntityAdminStatus, 
and chasEntityOperStatus? 

12) Section 5.6 about multiple instances of agents
that support the chassis MIB in one chassis doesn't
seem like it nails down anything! It needs to be cleaned
up. Also, does it still apply in a virtual chassis environment?

13) As written, the MIB doesn't identify groups and specifiy
which are mandatory or optional. In the rewritten
descriptions above, I suggest one such labling.

14a) Is chasNumSlots the highest value for chasSlotIndex?

14b) May the value of chasNumSlots freely change, or must 
a change cause the chassis agent to warm (or cold) start?

15) The ASN.1 comments about the chassis slot table should
be moved to the description for the table and modified
something like the following:

  chasSlotTable  OBJECT-TYPE
      SYNTAX  SEQUENCE OF ChasSlotEntry
      ACCESS  not-accessible
      STATUS  mandatory
      DESCRIPTION
              "A table that contains information about the slots
              in this chassis.  For those slots that do not contain
              a physical module, the table may be implemented to
              contain a conceptual row with the type of the
              physical module set to 'empty' or may be implemented
              to have no conceptual row instance."
      ::= { chasSlot 2 }

16) All tables need to indicate in the description for the
row whether instances of rows in the table made be created
or delete, and if so, how this is done. For example, the
description for row for the chassis slot table should be
changed to something like the following:

  chasSlotEntry OBJECT-TYPE
      SYNTAX  ChasSlotEntry
      ACCESS  not-accessible
      STATUS  mandatory
      DESCRIPTION
              "A row in the chassis slot table.  New instances
              may not be created nor deleted with SNMP
              operations."
      INDEX  { chasSlotIndex }
      ::= { chasSlotTable 1 }

17) The description for chasSlotModuleType should be updated.
The following is a suggestion:

  chasSlotModuleType OBJECT-TYPE
      SYNTAX  OBJECT IDENTIFIER
      ACCESS  read-only
      STATUS  mandatory
      DESCRIPTION
              "The type of physical module contained into this
              slot of the chassis.  If the table is implemented
              as 'complete', a value of chasSlotEmpty is used
              to indicate an empty slot.  A value of
              chasSlotUnknown indicates that the type of
              module is unknown. Other values may be
              assigned by vendors."
      ::= { chasSlotEntry 2 }

18) The descriptions for all OID values should be given. For
example, the following is a suggested value to add for
chasSlotEmpty:

  -- Indicates that a slot is empty.
  chasSlotEmpty  OBJECT IDENTIFIER ::= { chasSlot 3 }


19) The description for chasSlotModuleSerialNumber should
have the sentence "If the slot table is implemented as dense
and the slot is empty this value will be the zero length
string." removed.

20) I suggest that the slot table always be implemented
as "complete". Another column should be added which would
have the status of the physical module in the slot. It is
added so that the values of a physical module that was
removed are still available. The status column could have
the following values: unknown(1) - information about the
slot is unknown; inserted(2) - a physical module is in the
slot and values are available; notOperational(3) - a physical
module is in the slot and values may be available; removed(4) -
a physical module was previously in the slot, but it
is now empty.

21) The Party, Community, and IpAddress should be split
from the Entity table into a parallel table. This information
may not be available even if the other columns in the
table are. There are several chassis implementations where

22) The phrase "logical networking device" needs to be
replaced by "entity" throughout the document.

23) For the object chasEntityFunction, what is the meaning
of the value "services"?

24) The object chasEntityFunction should have a value
which means "host".

25) The list of functions for chasEntityFunction seems too
short. What other functions exist in current chassis?
 
26) The column chasEntityObjectId seems useless. It identifies
an agent, not an entity, and for those entities like power
supplies, there may be no agent that has information about
them.

27) The description for chasEntityAdminStatus does not
include a description of reset(4).

28) A coorespondense is not shown how to get to each
value of chasEntityOperStatus from setting
chasEntityAdminStatus. For example, how does an entity
get into the testin(3) status?

29) The description for chasEntityOperStatus does not
include a description of invalid(2).

30) The object chasEntityArgument seems very implementation
specific. It should be tossed.

31) The description of chasEntityTimeStamp should be
modified to something like the following:

  chasEntityTimeStamp  OBJECT-TYPE
      SYNTAX  TimeTicks
      ACCESS  read-only
      STATUS  mandatory
      DESCRIPTION
              "The value of MIB-II's sysUpTime (in the agent
              supporting this chassis MIB) at which this
              entity was last (re-)initialized.  If this
              entity has not been (re-)initialized since
              this agent was last (re-)initialized, then
              this object has a zero value."
      ::= { chasEntityEntry 9 }

32) The description of object chasSegmentType needs more
elaberation to describe the standard well known segments.

33) A well known value for "unknown" for chasSegmentType
needs to be defined.

34) The start for counter chasPhysicalChanges needs to be
defined. (should probably be since the agent warm/cold
started.)

35) Why is the range for chasConfigEntity started at zero
and not one?

36) There needs to be more explaination given about creation
and deletion of instances in the chassis configuration table.

37) The object chasConfigIndexType (and chasConfigIndexValue)
have ambiguous values. (For example, consider a brouter
(router/bridge). A connection could be a bridge port and
an interface. Which should be used?) As such, they should
be removed since they are misleading (or rules must be
defined to help in choosing the value). Also, the SYNTAX
type for chasConfigIndexType should be OBJECT IDENTIFIER
and it should point to an instance, and not an object type.
The object chasConfigIndexValue is not needed at all.

39) It seems like there should be traps for insertion and
removable of physical modules from slots.

-- that's all