Re: A new table

[[e-mail] (Keith McCloghrie)]

Bob,

>                                                       ....  It seems that we
> need the principle that the Chassis MIB will contain only what is necessary to
> find out what's in the Chassis and give you the first clues you need to get to
> those systems directly.  If we do more than that we're on a slippery slope
> into the other system's entire MIB, without any principles for where to stop.
 
I half agree with you, in as much as we need to be pragmatic, and NOT
include the "details" of each entity in the Chassis MIB.  On the other
hand, I'd like to see some "pieces" of each entity's MIB in the Chassis
MIB, for two reasons:

1. In the future, I see great benefit in having the Chassis MIB contain
a "summary" of each entity's state; for the present I think it's correct
for this to be minimal (e.g., chasEntityTimeStamp - the time since it 
last rebooted.)  A minimal step in the right direction for the future
is very desirable.

2. The need for information which links the two MIBs together; in particular,
I'm thinking of being able to relate the Chassis MIB's concept of an entity's 
connection to a segment, to a particular entry in the entity MIB's ifTable 
(or for repeaters, the rptrPortTable).  For a manager to use the MIBs in 
concert, I believe this linkage is very desirable (perhaps, more than just
desirable?).  In fact, this could be classified in your "first clues" 
category.
 
So, my concern is less the "slippery slope", but more the practicality of 
implementing even this minimal amount.  One way to overcome this is to
allow some kind of "relatively vague read-only indication" (as you put it) 
such that we can get implementation experience on the feasibility.

Keith.