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 92 14:23:43 EDT
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