Re- Comments on Chassis Mib

[eah <[e-mail]>]

                       Subject:                               Time:6:58 PM
  OFFICE MEMO          Re: Comments on Chassis Mib            Date:6/29/93
	This is going to be a rather long comment, so I apologize in advance for
the length.

	I've been going over the current draft, and noticed something that I believe
actually existed before this draft.  The text of the draft on page 4 states:

	"A chassis can be thought of as a hierarchical relationship of one or more
"physical locations", each physical location containing one or more physical
modules, and where a physical module, or combinations of physical modules,
might perform one or more network device functions.  The relationship between
physical location and physical module can be many to many."

	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.

	Based on the above, and the comments from Dave Arneson and Mahendra J. Kaycee
regarding the mappings I mentioned in my previous comments, below are some
suggested changes to the current (June 24) draft:

	- Remove chasModuleLocationTypeIndex and chasModuleLocation from the
chasModuleTable into a separate table, and re-instate the unique
chasModuleIndex for each module:

		chasModuleTable
			chasModuleIndex
			chasModuleType
			chasModuleFwVersion
			chasModuleHwVersion
			chasModuleSerialNumber
			chasModuleDescription
			chasModuleLastChangeTime
			chasModuleAdminStatus
			chasModuleOperStatus

	- Add the following table to the chasPhysical group:

		chasModuleToLocationTable
			chasModuleToLocationModuleIndex
			chasModuleToLocationTypeIndex
			chasModuleToLocationLocation

	- Add the following table to the chasEntity group:

		chasEntityToModuleTable
			chasEntityToModuleEntity
			chasEntityToModuleModule

	- Change the chasResourceTable definition of chasResourceIndex to refer to a
resource type as opposed to a specific resource, and add a chasResourceCount
object to that table (basically handle this table similarly to the way the
physical location table is handled so that there is one entry per "resource
type"):

		chasResourceTable
			chasResourceIndex
			chasResourceType
			chasResourceCount

	- Add the following tables to the chasResource group:

		chasResourceToLocationTable
			chasResourceToLocationResourceTypeIndex
			chasResourceToLocationResource
			chasResourceToLocationLocationTypeIndex
			chasResourceToLocationLocation

		chasModuleToResourceTable
			chasModuleToResourceModule
			chasModuleToResourceTypeIndex
			chasModuleToResourceResource

		chasEntityToResourceTable
			chasEntityToResourceEntity
			chasEntityToResourceTypeIndex
			chasEntityToResourceResource

	- Change the chasPhyConfigTable to include a chasPhyConfigModuleID , and
change the chasPhyConfigResourceID into two objects -
chasPhyConfigResourceTypeIndex, and chasPhyConfigResourceIndex:

		chasPhyConfigTable
			chasPhyConfigLocationTypeIndex
			chasPhyConfigLocationIndex
			chasPhyConfigModuleID
			chasPhyConfigResourceTypeIndex
			chasPhyConfigResourceIndex
			chasPhyConfigEntityID

	- Change the chasLogConfigTable to include a chasLogConfigModuleID, and change
the chasLogConfigResourceID into two objects - chasLogConfigResourceTypeIndex
and chasLogConfigResourceIndex:

		chasLogConfigTable
			chasLogConfigEntityID
			chasLogConfigResourceTypeIndex
			chasLogConfigResourceIndex
			chasLogConfigModuleID
			chasLogConfigLocationTypeIndex
			chasLogConfigLocationIndex


>>As for the problem with multiple mib views, personally I would prefer to 
>>have a "single entry point" to some entity's mib which allowed me
>>to see what views are available for that particular entity.  I would 
>>much rather see something along those lines, than have every view for 
>>every entity included in the chassis mib.
>
>How do you like the MIB view table that I currently have in the draft?>
>
>       Ed Heiner
>
>/David  Arneson

I guesss what I was trying to say was rather than having a table of information
about views for each entity, simply provide a single transport domain/transport
address/community combination for V1 implementations that provides access to
the view information for the V1 entity, or a single transport domain/transport
address/dstParty/context combination for V2 implementations that could provide
access to the context and view tables for the particular V2 entity.  IMHO,
having a whole table provides little benefit, since the entries don't actually
identify what's available to each view (the management application still has to
query the specific entity to determine what mib subtrees/objects are available
to a given view).


    Ed Heiner