chassis mib implementation ...

Paul Farah <> Thu, 06 January 1994 21:18 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa14777; 6 Jan 94 16:18 EST
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa14773; 6 Jan 94 16:18 EST
Received: from localhost by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id PAA28565; Thu, 6 Jan 1994 15:53:35 -0500
X-Resent-To: chassismib@CS.UTK.EDU ; Thu, 6 Jan 1994 15:53:34 EST
Errors-to: owner-chassismib@CS.UTK.EDU
Received: from by CS.UTK.EDU with SMTP (8.6.4/2.8s-UTK) id PAA28558; Thu, 6 Jan 1994 15:53:32 -0500
Received: from by with SMTP id AA26316 (5.67a/IDA-1.5 for <>); Thu, 6 Jan 1994 12:52:31 -0800
Received: from by with SMTP id AA27918 (5.67a/IDA-1.5); Thu, 6 Jan 1994 12:55:45 -0800
Received: by (4.1/SMI-4.1) id AA01738; Thu, 6 Jan 94 12:55:18 PST
Date: Thu, 6 Jan 94 12:55:18 PST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul Farah <>
Message-Id: <>
Subject: chassis mib implementation ...

> We (Digital) have implemented a "chassis MIB" in our DEChub900 product.

  Thanks for the info.

  We currently have a hierarchical mib defined for our wide-area multiplexer.
  It defines Shelf/Slot/Card ... objects for the mux.
  My interest in the chassis mib is for the next generation of our agent,
  which is being defined at this time.  

  I noticed that the two versions of the mib (January 92 and June 93)
  are edited by different people and are really different.  I guess you have
  implemented the January 92 version.

> Standardizing on objects which allow backplane LAN-hopping, port-switching,
> etc. seems to me to be very difficult.

  I agree that it is difficult to model these in a generic way. 
  We have some thoughts about that as it applies to our product. 
  When (and if) the WG gets going again we could attack some of these issues.
  Sometimes the timing makes all the difference in what gets accomplished.

  I guess not hearing from other people indicates that nobody else has
  implemented the mib yet.  I hope this changes.

Paul F.