Comments on Chassis Mib

eah <> Thu, 24 June 1993 21:15 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa16453; 24 Jun 93 17:15 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa16446; 24 Jun 93 17:15 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA14858; Thu, 24 Jun 93 16:43:03 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Thu, 24 Jun 1993 16:43:01 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 AA14850; Thu, 24 Jun 93 16:42:59 -0400
Received: from by pau.synnet.COM (5.64/1.34) id AA04542; Thu, 24 Jun 93 16:39:05 -0400 (EDT)
Message-Id: <9306242039.AA04542@pau.synnet.COM>
Date: 24 Jun 93 16:43:07 U
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: eah <>
Subject: Comments on Chassis Mib

                       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


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




    chasResourceToModuleModule -- not an index object



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