dwm answers

[David Arneson <[e-mail]>]

> From: [e-mail] (Dave Minnich)
> Message-Id: <[e-mail]>
> 
> A few editorial changes, and some questions:
> 
All changes noted and implemented thank you.

> 
> In addition I have some questions.  
> 
> 1) Is the chasPhysicalChanges object really of any use?  It seems too general
>    to do much good.  Is there some rationale I'm missing here?
Perhaps the description is a bit general.  The goal was to provide a
single point that a network management station could poll to determine
if something has changed in the chassis.  Physical changes should reflect
changes to the contents of slots.  Notice this directly changes the contents
of the entity table as well.
> 
> 2) Is a "slot" intended to map onto a physical slot in a chassis?  If so, I
>    assume that there is no restriction on number of segments per slot, the
>    types of those segments, and multiple entities on a given segment (by my
>    reading these should just fall out in the chasConfigTable.  True?
> 
Yes a slot should map to physical slots in the chassis.  Perhaps this should
be added to the description.  Yes the chasConfigTable is the simple
expression of what segments are used by what entities in what slot.

> 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.

> David W. Minnich               INTERNET: [e-mail]
> FiberCom, Inc.                 UUCP: ...!uunet!fibercom!dwm   
> P.O. Box 11966                 PHONE: [phone] ext. 347
> Roanoke, VA  24022-1966        FAX: [phone]
> 
/David Arneson ([e-mail])