Re: Re- Comments on Chassis Mib

Steve Horowitz <> Wed, 30 June 1993 22:23 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa15828; 30 Jun 93 18:23 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa15823; 30 Jun 93 18:23 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA05065; Wed, 30 Jun 93 18:06:28 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 30 Jun 1993 18:06:27 EDT
Errors-To: owner-chassismib@CS.UTK.EDU
Received: from by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA05055; Wed, 30 Jun 93 18:06:25 -0400
Received: from teach.stealth ([]) by (4.1/SMI-4.0) id AA22416; Wed, 30 Jun 93 18:05:29 EDT
Received: by teach.stealth (4.1/SMI-4.1) id AA26757; Wed, 30 Jun 93 18:07:50 EDT
Date: Wed, 30 Jun 93 18:07:50 EDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Horowitz <>
Message-Id: <9306302207.AA26757@teach.stealth>
Subject: Re: Re- Comments on Chassis Mib

In response to and

Without going into the technical details for the proposed 
changes, I agree philosphically with eah's contention that
multiple modules can be located within one slot and that
should be supported naturally by the chassis MIB.

-- Steve 

eah's mail extract:

	The actual mib, however, really only supports a one:many
mapping for physical
>location to physical module.  The current chasModuleTable only allows a
>reference to one physical location, but many modules may refer to the same
>physical location.  The question is do we need a many:many mapping between
>physical locations and physical modules. I think we do.
>	Consider the hypothetical case of a chassis which supports half slot modules
>(where two half slot modules may occupy the same slot simultaneously), single
>slot modules, and dual slot modules.  If we use the current mib to represent a
>chassis containing each of these modules, we need two different location types,
>a single slot location type (for the half slot and single slot modules), and a
>dual slot location type for the dual slot modules.  We also need to be able to
>determine what "type" a >

>location is based on what type of module occupies it, rather than being able to
>determine it in advance.  On the other hand, if the mapping is represented as
>many:many, the chassis locations can be described in terms of the more natural,
>single slot location type.