Re: Chassis MIB

[[e-mail] (Keith McCloghrie)]

> >1.
> > ... 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 sett
> >implicitly when the manager creates a row by setting chasConfigStatus to 
> >valid(1).
> >
> We have discussed this at length in the past.  The reason for read/write was
> to allow for control switching backplane segments.  It is rather vendor
> specific some can do this many can not.  You may want to check the archives
> for more information.
>
> >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. 
> >
> Yes we need to clean this up.

Note that the answer given to 1) above was wrong, since chasConfigSlot, 
chasConfigEntity and chasConfigSegment are in the INDEX clause.  
However, that may be irrelevant, sincew my answer to 2) is:
 
While I don't think double segment attachments are/will be very common,
I believe it's more than "a clean-up" to fix it.  In particular, I wonder 
whether the right solution is to have an arbitrary-integer as the only
index of the chasConfigTable.

Keith.