More comments

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

These are comments to the comments to my original mail.

>>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.
>>

>Yes, Keith and myself discussed multiple instances of MIB II on a per
>entity basis.  The current thoughts are that there should be an
>instance of the system group and the IF group (if not others) for
>each entity defined.  However when we last discussed it Keith was
>unsure how to best handle this.  One thought was to keep these fields
>here as well as the system group.  Perhaps Keith can fill us in
>with what he sees as the correct direction.


I'm surprised to hear that there can be multiple instances of MIB II
on a per entity basis. Could someone give an example of when this might be
the case ?.

>>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 ?.
>>

>I maintain that much of the above information is very vendor specific.
>Fans and power supplies could be include in this MIB.  One could also
>argue that a seperate MIB maybe more useful.

Before the first MIB was defined, all information was vendor specific. MIB's
provide a standardised view of specific information. The real question is: 
What information do we want to make accessible in a standardised manner. Maybe
we should go one step back and try to list the requirements before we define
managed objects. It seems to me that the what has been suggested so far fits
within the following headlines:

1) Mapping of network entities onto slots and segments. This is what
the current MIB proposal focuses on.

2) Pointer to detailed information about the entity in question. This is
obtained by chasEntityParty, chasEntityCommunity and chasEntityIpAddress.

3) Possibility to control one entity from another entities agent. Examples
of this feature is chasEntityAdminStatus, chasEntityOperStatus and the
chasConfigTable.

4) Geometrical/physical chassis layout. Not too much exists. I can only
think of chasNumSlots.

5) Access to non network devices, such as PSU, fan, etc. Only supported
if your PSU consitutes a network entity.

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

>However how much use is it if we have multiple instances of the interface
>group of MIB II?

I don't understand. This is exactly why we need chasConfigIfIndex. If there
are multiple instances of the interface group, I would expect at least
the same amount of entries in the chasConfigTable, thus being able to
determine which interface maps on to which segment.


	Niels Ole Brunsgaard.
	Dowty Network Systems A/S
	Copenhagen, Denmark