Re: Chassis MIB Draft

[[e-mail] (Dave Minnich)]

A few editorial changes, and some questions:

Editorial changes:

[from page 7]
>    -- The Slot Table
>
>    -- It is an implementation specific matter if this table is dense.  If the
>    -- table is dense and the slot is empty then chasSlotBoardType should have
>    -- the value chasSlotEmpty.  In addition the values of chasSlotDescr,
>    -- chasSlotVersion and chasSlotBoardSn should be set to null.

The names chasSlotBoardType, chasSlotDescr, chasSlotVersion, and
chasSlotBoardSn are not the same as the names listed below.


[from page 9]
>          chasSlotModuleDescr  OBJECT-TYPE
>              SYNTAX  DisplayString (SIZE (0..32))
>              ACCESS  read-only
>              STATUS  mandatory
>              DESCRIPTION
>                      "A vendor's textual description of the module
>                      plugged into the slot."

To be consistent, we should include a sentence in the above description like:
	"If not realized this value should be set to a NULL string."


[from page 11]
>                              Function  Power
>                                 other  0
>                              repeater  1   -- e.g. Ethernet repeater,
>                                            --      or FDDI concentrator
>                                bridge  2
>                                router  3
>                        terminalServer  4
>                            management  5
>                              services  6   -- e.g. MIB Walk tools etc
>                                   mau  7
>                                 power  8
>
>                     For example, an entity performing both bridging and
>                     routing functions would have a value of 24 (2^3 +
>                     2^4)."

Given the description which precedes it, I believe the above should read:
	 "... value of 12 (2^2 + 2^3)."


[a couple of nits from pages 12 and 13]
>          chasEntityAdminStatus OBJECT-TYPE
>              SYNTAX  INTEGER {
>                  enable(2),
>                  disable(3),
>              DESCRIPTION
>                      "Provides the state of the given entity.  A entity
>                      is activated by writing a value of enabled(2).
							  ^^^^^^^
Should this be "enable" to match above?

>
>                      The entity may be de-activated by writing a value
>                      of disabled(3).  In a disabled state, a entity
			  ^^^^^^^^
Should this be "disable" to match above?


[from page 17]
>                      For example, for am Ethernet segment this object
					^^
Methinks this should be "an".


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?

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?

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.

--dave
-- 
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]