Comments on Chassis Mib

[eah <[e-mail]>]

                       Subject:                               Time:4:40 PM
  OFFICE MEMO          Comments on Chassis Mib                Date:6/24/93
    Unfortunately I haven't been monitoring the activity on this list as
closely as I would have liked in the recent past.  Now that I've had the time
to review some of my accumulated mail, I'd have to answer Bob's recent query
with a 2.  Based on the comments I've read since the May 28 draft, the
following is a brief listing characteristics that one or more individuals have
expressed a desire to see that are not reflected in that draft:

    - many:many mapping for modules:entities

    - many:many mapping for entities:resources

    - resources should represent "real" (i.e., physical) resources

    - one:many mapping for modules:resources

    - assuming the mapping relationships described above:

        - given a module be able to easily determine the entity(ies) that 
        exist either completely or partially on that module

        - given an entity be able to easily determine the module(s) where 
        this entity exists

        - given a module be able to easily determine what resource(s) exist
        on that module

        - given a resource be able to easily determine on what module that
        resource exists

        - given an entity be able to easily determine the what resources(s)
        that entity uses

        - given a resource be able to easily determine what entity(ies) use
        that resource

    - solution to problems related to multiple mib views

    - some suggested changes to the power supply/environment tables

Does this list look about right?  Assuming for the most part that it is,
I'd like to add my 2 cents.  I agree that the many:many mappings are
important.  To that end, I'll throw out the following food for thought.

Consider something like the following in place of the chasPhyResourceTable
and the chasLogResourceTable:

- a chassis resource group to list all resources in the chassis

chasResourceTable
    chasResourceIndex,
    chasResourceType,
    chasResourceCount

This is very similar to the chassis resource group that was in the earlier
draft with the exception that a count is included similar to the chassis
physical location table.  

- a chassis configuration mapping group

chasModuleToEntityTable
    chasModuleToEntityModule,
    chasModuleToEntityEntity

chasEntityToModuleTable
    chasEntityToModuleEntity,
    chasEntityToModuleModule

chasModuleToResourceTable
    chasModuleToResourceModule,
    chasModuleToResourceResourceType,
    chasModuleResourceResource

chasResourceToModuleTable
    chasResourceToModuleResourceType,
    chasResourceToModuleResource,
    chasResourceToModuleModule -- not an index object

chasEntityToResourceTable
    chasEntityToResourceEntity,
    chasEntityToResourceResourceType,
    chasEntityToResourceResource

chasResourceToEntityTable
    chasResourceToEntityResourceType,
    chasResourceToEntityResource,
    chasResourceToEntityEntity

Each object in these would also be included in the index for the table,
except as noted.  I know his may be a bit much, but I believe that it supports
the many:many mappings and provides for flexible access.  The questions are: 

    Do we even want/need this much flexibility?  
    Is there a better way of coming up with it?  

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.

       Ed Heiner