Re: Re- Comments on Chassis Mib

["David L. Arneson" <[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
>
I have at various times felt that a many to many mapping between modules
and slots is useful.  As you point out the text implies that we had
such an arrangement at one time.

>	- 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
>
Yes providing a list of resource types and the number of each type may be
the most useful way of doing this.

>	- Add the following tables to the chasResource group:
>
>		chasResourceToLocationTable
>			chasResourceToLocationResourceTypeIndex
>			chasResourceToLocationResource
>			chasResourceToLocationLocationTypeIndex
>			chasResourceToLocationLocation
>
Do we need to map resources onto physical locations?   Isn't the
mapping of ModuleToResource and EntityToResource, as specified below,
sufficient?

>		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
>
I question if the chasPhyConfigTable and the chasLogConfigTable are required
if you have the chasModuleToLocationTable, chasEntityToModuleTable,
chasModuleToResourceTable, chasEntityToResourceTable.  It seems that
we are just presenting the same information in a differnt way.

I propose that we use your tables without the chasResourceToLocationTable,
chasPhyConfigTable, chasLogConfigTable.  This I'm willing to support.

>
>>>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).
>
I think we have two differnt things here.  The MIB view table that is currently
in the draft may supplies perhaps a read-only view, and a read-write view
into the MIBs.  Yes it may indeed limit your access in other ways.

Our proprietary chassis MIB has a mapping between the entities  and the
MIB groups that are realized on that entity.  The idea was that it provided
you a place to look to determine which MIBs are supported by a given entity.
This I think answers your question.

The question I have is that if you have access to that table you then have
knowledge of all the  MIBs realized by that entity.  Suppose on the other
hand that I as a network manager do not wish user X to have access to
a given section of the MIB.  If user X is given access to this table then
he would be given knowledge of the existence of these other objects that
he is not permitted to see.  Is this a potential security leak?

>
>    Ed Heiner
>
I summary I agree with Ed's requests in location, module, resource, entity
mappings, with a few modifications.

I also feel that we need to get a better understanding of what we need in 
MIB views.  Does anybody have any additional thoughts?

/David Arneson