Re- Re- Re- Comments on Cha

[eah <[e-mail]>]

                       Subject:                               Time:5:46 PM
  OFFICE MEMO          Re: Re: Re- Comments on Chassis Mib    Date:6/30/93
>>	- 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?

Since the change from a one:many mapping to a many:many mapping
between physical locations and modules, we lost the ability to
definitely determine a location based solely on the module.  As a
result, I took a second look at the relationships between 
locations, modules, resources, and entities and came up with the
following:

One view of a chassis can be as a collection of physical locations
and resources.  The relationship between a resource and a
location is one:one.  A m#004#odule can be considered as a physical
collection of resources.  An entity can be considered as a logical
collection of resources.  The relationship between the collection
of resources that make up a module and that module cannot change.
The relationship between resources that make up an entity at any
given instant, and that entity may change.

This is consistent with our description of resources as "building
blocks" .

Taking this view seems to make resources the logical choice for
setting up the relationship between entities and locations, thus
the reason for a resource to location table.  Without providing
a resource to location relationship (either through th
resourceToLocationTable#004##004##004#, the chasPhyConfigTable or the chasLogConfigTable),
there would be no way to definitely
determine the location of a given resource or the location(s)
of a given entity.

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

I agree with getting rid of the chasPhyConfigTable and the
chasLogConfigTable, however, I still think we need the
chasResourceToLocationTable for the reasons I mentioned above.

> 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.

Are these read-only/read-write views of the entire mib tree supported
by the entity?  If so, could this present a potential security
breach?

> 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.

Are you proposing to add a table like this to the chassis mib?

> 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?

I don't think so.  I only suggested identifying the dst party and context
where this information is accessible.  If the manager doesn't already
have access to this context, and doesn't have the authority to create
it, he/she is denied access.  What may happen, however, is that some
the manager may be denied some information that he/she should
have access to.  In fact, I'm more concerned about moving potentially
protected information out of an entity into the chassis mib and then
exporting it.  What perhaps needs to be established is some "security"
relationship between users who may have access to the chassis mib
but may not have access to certain information maintained by entities
within the chassis, and vice-versa.  Anyone have any ideas on how to
go about doing this?

        Ed Heiner