Chassis MIB (Niels Ole Brunsgaard) Thu, 03 September 1992 14:32 UTC

Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA27472; Thu, 3 Sep 92 10:32:40 -0400
Received: from by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA27468; Thu, 3 Sep 92 10:32:36 -0400
Received: from mips.uucp by via EUnet with UUCP (5.64+/8+bit/IDA-1.2.8) id AA03588; Thu, 3 Sep 92 16:32:19 +0200
Received: from sony by (5.61/SMI-4.1) id AA02513; Thu, 3 Sep 92 11:02:14 +0200
Received: by (4.0/SMI-4.1) id AA17840; Thu, 3 Sep 92 10:01:58 +0100
Date: Thu, 3 Sep 92 10:01:58 +0100
From: (Niels Ole Brunsgaard)
Message-Id: <>
Subject: Chassis MIB
X-Charset: ASCII
X-Char-Esc: 29

1) Multiple instances of Chassis MIB in same chassis.

In my model of the Chassis MIB, every agent in the chassis provides a
view of the Chassis MIB. To me an important feature of Chassis MIB is 
the ability to provide the MIB view and the transport address for 
contacting the agent for each entity. If your're managing an entity in the 
chassis that has no Chassis MIB, you won't know how to contact the
agent with the Chassis MIB view. And thus you won't be able to find out
about other entities in the enclosure. Ofcourse, you could write it on
memo pad and stick it on the monitor of your MS. Then your're fine until
the Chassis MIB agent crashes, and you need chassis information to find
out what went wrong. Thus, the advantages of multiple Chassis MIB views
		1) Pointers to agents for other entities.
		2) Resiliance.

In fact, I think that both single and multiple instance implementations
could be conformant. We just need to design things so both will work.

2) MIB II objects in Chassis MIB.

To me, exporting objects from one MIB view to another MIB view is not 
the main purpose of the Chassis MIB. This only makes sense if aggregating
such objects adds new information to the MIB. I don't see that exporting
sysUpTime to the Chassis MIB adds any new information.

3) ChasUpTime

chasUpTime only makes sense if we assume multiple instances of the Chassis
MIB in one chassis. Since I've just advocated for that, I'll speak for
chasUpTime too. I think it could be implemented without a non-volatile clock.
How about defining chasUpTime as the max value of all sysUpTime's in the
chassis. If the entity with this sysUpTime resets, the other agents keep on
clocking. If there are no other agents, the chassis can be regarded as having
been powered down. The first agent to reappear establishes chasUpTime.

4) chasConfigIfIndex

I like Keith's scheme with indexType and indexValue. 

We have a chassis with multiple internal segments of various types. I beleive
that I could and would want to fill in indexType and indexValue. 

Take for example our 10BASE-X repeater. It supports the RPTR MIB and MIB-II.
The management subsystem of the repeater is modelled as a network device
connected to the network through a MIB-II interface. All SNMP traffic passes
across this virtual interface. So for each entry in the chasConfigTable, I
would need a pointer to N repeater ports and 1 MIB-II interface. Right ?.

	Niels Ole Brunsgaard

	Crays Networks (formerly Dowty Network Systems)
	Copenhagen, Denmark