Chassis MIB comments

[[e-mail] (Niels Ole Brunsgaard)]

Please accept my contribution to the Chassis MIB discussion.

1) I'm not quite sure why a Chassis MIB would contain 
chasEntityAdminStatus and chasEntityOperStatus. These objects
reflect functionality that is common to all devices, and not
just chassis based devices. I would think that they belong in 
the systems group of MIB II (or MIB III). 

The above also seems to be in opposition to what one can read in
the proceedings from San Diego:

-->>
The working group is chartered to define MIB objects that represent 
the mapping of logical functions of traditional network devices onto
particular physical hardware resources within the chassis. These MIB 
definitions will not address any aspect of the network functions 
comprised by a chassis box that are shared with an analogous collection
of discrete devices.
<<--

As I read the Chassis MIB, there is a one-to-one relationship between 
MIB II and chasEntityTable. One could go so far as to suggest that most 
of the chasEntityTable belongs in the systems group of MIB II. The 
chasEntityTable would only have to contain:

                  chasEntityParty
                  chasEntityCommunity
                  chasEntityIpAddress

in order to point to MIB II.

2) Jason Perreault raises a good question:

>   To what level of detail ought the MIB seek to represent the
>   physical composition of the chassis?

A popular thing among todays management stations is to show a
photographic correct drawing of the chassis. One could require
that the Chassis MIB be detailed enough to let a MS create such
a picture. If this is the case the MIB should contain information 
about contents of LCD displays, key pads, LED's, fans, connectors, etc. 

These items constitute "physical hardware resources within the chassis",
even though one can argue if there is a "mapping of logical functions 
of traditional network devices" onto these resources.

Maybe such objects should be in the PSU MIB, or in an environment MIB ?.

3) I share the concern raised by others about the possibilty to disable,
enable and change segments on the fly, by means of the chasConfigTable.
I.e changing the segment might move a device from one side of a router
to the other, making the IP address invalid. It may also disconnect
the agent from the MS all together, disallowing further management.

At the same time I realize that there is a need for doing such
configuration. Maybe we need a mechanism that allows for changing 
segment and IP address in one go. When such a set has been initiated,
the entity/device could wake up on a different segment, with a new
identity,

4) I like the idea of a chassisUptime. This solves the problem that
2 agents residing in the same chassis report different values of
chasSlotLastChange for the same slot. In general I think it would
be a good idea to state that all agents in the same enclosure shold
provide the same view of the chassis. I could easily imagine that 2 
agents would report different values for chasPhysicalChanges.

5) I like chasConfigIfIndex. For a device with 2 interfaces there
is currently no way of knowing which physical interface they map onto.

6) Would it make sense to have chasSegmentType take on the same
set of values as IfType in MIB II ?. 

7) When an entity has more than one IP address (router etc.), how
does it make them fit into the chasEntityIpAddress ?