Chassis MIB

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

1) chasConfigTable

How exactly does this table work ?. I see (at least) 2 implementations.

	a) The table contains only those relationships that actually exist. 
	Rows are created/deleted by a set of chasConfigStatus.

	b) The table contains all valid relationships. chasConfigStatus
	indicates which are currently in use and which are not.

Option b) makes visible all potential configurations. Using a), how 
would a manager know if a specific slot was able to attach to a specific
segment ?.

In either case, why are chasConfigSlot, chasConfigEntity and chasConfigSegment 
read-write and not read-only ?. Using option b), these objects are determined
by the HW present in the chassis. Using option a), these objects are set
implicitly when the manager creates a row by setting chasConfigStatus to 
valid(1).

Am I missing something ?.

2) Double segment attachments.

Someone pointed out the problem of having one specific slot host 2
connections to the same segment. This is a severe limitation
on switched ethernet and on ATM. On these medias, a single entity could
increase the bandwidth of its network connection by having multiple
connections to the same network.

This is a severe limitation. We just can't design a MIB with such an
obvious flaw. 

3) chasConfigIndexType
 
Imagine a combined repeater/bridge entity that takes up one slot and
attaches to one segment. Thus it has one entry in the chasConfigTable.
Does chasConfigIndexType point to an interface or a repeater port in 
this case ? It seems to me that there should be an instance of 
chasConfigIndexType for each function defined in chasEntityFunction.

4) chasConfigIndexValue

If the entity in question is a repeater with multiple ports per
segment (fairly typical I guess), which port instance does
chasConfigIndexValue reference ?.



	Niels Ole Brunsgaard
	Cray Networks A/S
	Copenhagen, Denmark.