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?