Re- Re- Re- Comments on Cha
eah <eah@pau.synnet.com> Wed, 30 June 1993 22:55 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16327; 30 Jun 93 18:55 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa16318; 30 Jun 93 18:55 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA06332; Wed, 30 Jun 93 18:25:45 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 30 Jun 1993 18:25:43 EDT
Errors-To: owner-chassismib@CS.UTK.EDU
Received: from pau.synnet.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA06320; Wed, 30 Jun 93 18:25:41 -0400
Received: from mailgate.synnet.com by pau.synnet.COM (5.64/1.34) id AA03962; Wed, 30 Jun 93 18:22:34 -0400 (EDT)
Message-Id: <9306302222.AA03962@pau.synnet.COM>
Date: Wed, 30 Jun 1993 18:27:52 -0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: eah <eah@pau.synnet.com>
Subject: Re- Re- Re- Comments on Cha
To: arneson@ctron.com
Cc: chassismib@cs.utk.edu
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