RE: Where do we stand

{3COM/PDD/PeteW} Fri, 18 June 1993 09:06 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa01440; 18 Jun 93 5:06 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa01436; 18 Jun 93 5:06 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA28805; Fri, 18 Jun 93 04:37:55 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Fri, 18 Jun 1993 04:37:54 EDT
Errors-To: owner-chassismib@CS.UTK.EDU
Received: from gatekeeper.3Com.COM by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA28797; Fri, 18 Jun 93 04:37:50 -0400
Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA02259 (5.65c/IDA-1.4.4-910725 for <>); Fri, 18 Jun 1993 01:38:14 -0700
Received: by gw.3Com.COM id AA22886 (5.65c/IDA-1.4.4 for; Fri, 18 Jun 1993 01:38:09 -0700
Date: Fri, 18 Jun 1993 09:35:00 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: {3COM/PDD/PeteW}
Subject: RE: Where do we stand
Message-Id: <930618.014422@3Mail.3Com.COM>
Msg-Date: 1993-06-18
Msg-Time: 09:32

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Chassis MIB
Subject:  RE: Where do we stand
Date: 1993-06-18 09:27
Message ID: 40F0D9EE
Conversation ID: 40F0D9EE


I don't think (hope) we've made a decision at this point. We've only really 
had input from a couple of people, there were many more expressing opinions 
at the Columbus meeting, would any of those loke to comment. My real concern 
is for generic management applications. I know I can restrict my 
implementation is particular ways to make it possible for me to write a 
management application for my own implementation, for example if the many to 
many model is adopted I can still restrict my implementation to a many to 
one mapping and my application can know this.

My concern is for generic application, which I think these MIBs really need, 
which will have to cater for the full, general implementation of the MIB as 
applied to anyones device. I'd be very interested to hear the opinion of 
anyone writing generic applications and may want to support this MIB. Even 
with the many to one mapping it is difficult to present an easy to 
comprehend abstraction to a user.

I can see that there are benefits to the many-to-many mapping, but in some 
ways I'd prefer to keep the model simple so that people will be able to 
produce generic applications. I'd hate us to end up with a MIB that can only 
be used generically with a MIB browser!

If we do adopt a many-to-many mapping then I don't think we have the MIB 
mapping correct at the current time. It may be better to rethink the tables 
than tweak the existing ones.