Re: dwm answers
Manu Kaycee <kaycee@ctron.com> Tue, 11 August 1992 18:25 UTC
Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA17077; Tue, 11 Aug 92 14:25:27 -0400
Received: from nic.near.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA17073; Tue, 11 Aug 92 14:25:19 -0400
Received: from [134.141.2.2] by nic.near.net id aa03790; 11 Aug 92 14:25 EDT
Received: from cardinals.ctron by ctron.com (4.1/SMI-4.1) id AA29657; Tue, 11 Aug 92 14:23:42 EDT
Received: from vishnu.ctron by cardinals.ctron (4.1/SMI-4.1) id AA24693; Tue, 11 Aug 92 14:23:43 EDT
Date: Tue, 11 Aug 1992 14:23:43 -0400
From: Manu Kaycee <kaycee@ctron.com>
Message-Id: <9208111823.AA24693@cardinals.ctron>
To: arneson@ctron.com, chassismib@cs.utk.edu, dwm@fibercom.com
Subject: Re: dwm answers
Cc: kaycee@ctron.com
arneson@ctron.com (David Arneson) writes in response to dwm@fibercom.com (Dave Minnich): > > 3) [excerpted from pages 19 and 20] > > "Support for creating or invalidating instances of this object will > > normally be subject to the hardware limitations of the board in the > > referenced slot. When supported, the creation (invalidation) of > > instances may have the implicit side-effect of removing (creating) > > other instances of this object." > > To me, the above says that the creation of an instance may imply the > > deletion of some other instance, and vice versa. Is this the intended > > meaning? If so, what was the assumption that prompted this? I can think > > of cases where the opposite would be true (i.e creating an instance implies > > the creation of another instance). Some clarification would be helpful. > > > The description of chasConfigStatus was written by Keith (I assume). So > perhaps Keith can correct me if my reading is incorrect. I read this as > providing the ability to disable a segment on a given entity. Now the > problem with that is in may not be possible to disable a given segment. > It may also be possible to change other segments by changing a different > segment. > > My view of all this is that disable of a segment at this level can very > dangerous. This is why the statement concerning hardware limitations. > In fact I feel this should be read as implement this as read-write if > you can support it. Otherwise use SMP to state that you implement this > as read-only. Dave A. and I have discussed this, and we agree. To take this discussion a step further, disabling a segment on an entity should ensure that that certain entity does not transmit and/or receive traffic on/off that segment. This means that the applicable, pertinent interface should also be disabled. Another point to note is that the three indexes (indices) for chasConfigTable are read-write. It seems to me that they should suffice as read-only, and do not have to be read-write. But, we should let Keith add the appropriate perspective to this thread. /Manu. kaycee@ctron.com
- dwm answers David Arneson
- Re: dwm answers Manu Kaycee