Re: More comments
"David L. Arneson (arneson@ctron.com)" <arneson@yeti.ctron.com> Tue, 18 August 1992 18:25 UTC
Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA03776; Tue, 18 Aug 92 14:25:54 -0400
Received: from nic.near.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA03772; Tue, 18 Aug 92 14:25:51 -0400
Received: from [134.141.2.2] by nic.near.net id aa03593; 18 Aug 92 14:25 EDT
Received: from yeti.ctron by ctron.com (4.1/SMI-4.1) id AA25646; Tue, 18 Aug 92 14:23:17 EDT
Received: by yeti.ctron (4.1/SMI-4.1) id AA12142; Tue, 18 Aug 92 14:24:52 EDT
Message-Id: <9208181824.AA12142@yeti.ctron>
To: Niels Ole Brunsgaard <nob@sony.dowtyns.dk>
Cc: chassismib@cs.utk.edu
Subject: Re: More comments
In-Reply-To: Your message of "Tue, 18 Aug 92 10:02:09 BST." <9208180902.AA00804@sony.dowtyns.dk>
Date: Tue, 18 Aug 1992 14:24:50 -0400
From: "David L. Arneson (arneson@ctron.com)" <arneson@yeti.ctron.com>
>>I maintain that much of the above information is very vendor specific. >>Fans and power supplies could be include in this MIB. One could also >>argue that a seperate MIB maybe more useful. > >Before the first MIB was defined, all information was vendor specific. MIB's >provide a standardised view of specific information. The real question is: >What information do we want to make accessible in a standardised manner. Maybe >we should go one step back and try to list the requirements before we define >managed objects. It seems to me that the what has been suggested so far fits >within the following headlines: > Your initial statement had reference to LCD's etc. This I view as very vendor specific. >1) Mapping of network entities onto slots and segments. This is what >the current MIB proposal focuses on. > >2) Pointer to detailed information about the entity in question. This is >obtained by chasEntityParty, chasEntityCommunity and chasEntityIpAddress. > >3) Possibility to control one entity from another entities agent. Examples >of this feature is chasEntityAdminStatus, chasEntityOperStatus and the >chasConfigTable. > >4) Geometrical/physical chassis layout. Not too much exists. I can only >think of chasNumSlots. > Please refer to the chasSlotTable. Here we find a list of what modules are plugged into which slots. This includes type of module. Are we missing something here? >5) Access to non network devices, such as PSU, fan, etc. Only supported >if your PSU consitutes a network entity. > > >From what I understand of out goals I think the chassis MIB pretty much answers the call. Is there something more that the MIB should answer? Now as concerned with chasConfigIfIndex. Having this object was initially my idea. I have been convinced that it is not need. Once again I'm feeling that it is useful. At present I guess we have 2 votes for it and 2 against. I'm uncommited at this time. How about the rest of you out there what are your feelings?
- More comments Niels Ole Brunsgaard
- Re: More comments John Seligson
- Re: Re: More comments Niels Ole Brunsgaard
- Re: More comments David L. Arneson (arneson@ctron.com)
- Re: More comments David L. Arneson (arneson@ctron.com)