Bob Stewart's Comments on Draft (not as co-chair)

[Bob Stewart <[e-mail]>]

Comments on 13 October 1992 working group draft of Chassis MIB.

Page 10 - the well-known values for chasSlotModuleType.  In other MIBs, such
as the Character MIB, such values are dropped a level in the OID tree with an
intermediate value like "wellKnownModuleTypes".  Then if new well-known ones
are added, you don't end up with gaps between them caused by being mixed in
with real objects.

Page 10 and others - chasSlotModuleDescr, chasSlotModuleVersion, and other
DisplayStrings are limited to 32 characters.  Other MIBs typically have
somewhat larger limits, with MIB-II having 255.  Although 255 may be too
large, by its example, 32 seems too small.  Perhaps it should be something
like 127?

Page 13 - chasEntityFunction is rather a problem.  The information is good to
have, but the limited list concerns me.  It is not good to assume that we know
all the right types to go in here.  On the other hand, I don't particularly
want to see this become a list of object identifiers.  Maybe it should go away
and leave such determination to the entity's own MIB.  How do we expect this
object to be used?  Why do we NEED it?  It may be covered sufficiently by
chasEntityDescr.  

Page 14 - what is the purpose of chasEntityAdminStatus value reset(4)?  How is
it different from disable(3) or programLoad(5)?

Page 15 - the chasEntityOperStatus values warning(6), nonFatalError(7), and
fatalError(8) are not sufficiently defined to have meaning that is independent
of implementations, especially given the statement that the chassis may not be
functional, which sounds like only the latter.  Are they to refer to an
occurance detected during the reset process, the program load process, or
normal operation?  Are they transitional?

Page 16 - chasEntityArgument seems too implementation specific.  As an OCTET
STRING, an NMS would have to either handle it as uniterpreted numbers,
requiring the human to have implementation knowledge, or have implementation
knowledge itself.  This would be slightly better if the field were a
DisplayString, but its existence is still questionable.

Page 17 - chasEntityNoParty, same comment as for other well-known types.

Page 17 - chasEntityIpAddress is massively IP-centric.  Is that acceptable or
should we make this a more general transport address, perhaps with a type?

Page 20 - the config section deserves a header comment.

Page 20 - should chasPhysicalChanges have a time associated with it?  It has
one indirectly for slot changes (chasSlotLastChange), but not for entity or
other changes.  Perhaps the right answer would be to add chasEntityLastChange
to the entity group (not in the table, as it would be lost with a deleted
entry).  This would imply that any implementation-specific reasons to
increment the counter would probably have their own time mechanism.

Page 23 - chasConfigIndexTypeUnknown, same comment on well-known values.

Page 24 - chasConfigIndexValue, should it be valid to have a value of zero
here for a known type when either the index value is unknown or can not be
expressed as an integer?

			[end of comments]