Chassis MIB comments

[[e-mail] (Keith McCloghrie)]

Hi,

My apologies (especially to David) that I've been on vacation, and am
just about getting caught up.  Here are my comments regarding the
mailing-list discussions of the last few weeks.  (I also have some other
comments on the MIB, based on my own reading of it, after not having
looked at it for a while, but I'll put those in another message).

Re: chasConfigStatus 

The wording of the DESCRIPTION was intended to accomodate a card with,
for example, one switchable connection to a backplane segment such that 
if that chasConfigStatus for its connection to one segment was activated,
then it automatically de-activates its connection to another segment;
thus the wording about the creation of new instances causing the
deletion of others.  (Note also, that cards may not be switchable or
such switching might only be compatible with a subset of the backplane 
segments; thus the wording about hardware limitations.)

As reagrds read-only/read-write.  I think they should be read-write,
but compliance should allow read-only.  We can include text in the 
DESCRIPTION to reflect this compliance issue (unless and until SMP 
is adopted :-).

Re: chasEntityFunction

David's question (to me) to define "concentrator" versus "repeater" was
a good question.  If somebody can suggest un-ambiguous definitions
of these, I'd be happy to have them separated out again.

Re: chasEntityParty, and chasEntityCommunity/chasEntityIpAddress

These specify the MIB view and the transport address for contacting the
agent for this entity.  This is not necessarily (one of) that entity's
IP addresses (since the agent might be on a different card).  In fact,
when using SNMP parties, chasEntityIpAddress would not be used.

Re: most of chasEntityTable belongs in the systems group of MIB II.

There is obviously some confusion here.  I'm sure we could do with some
additional text in section 5.2 of the Overview discussing this MIB's
assumption that there is another MIB view (either in the same or 
different agent, as indicated by chasEntityParty or 
chasEntityCommunity/chasEntityIpAddress) which contains the entity's
MIB.  The Chassis MIB contains only a subset of that entity's MIB
stored in this chasEntityTabler.  So, yes, most of the chasEntityTable
information does come from the system group of MIB-II, but it is the
system group of the underlying entity's MIB, not the system group of
the Chassis MIB (which would, naturally, contain system-group information
about the Chassis itself).  In fact, I would argue that chasType is
redundant since it is a duplicate of the value of sysObjectId in the
same MIB view.  In contrast, the chasEntityTable's system-group-like
information, while being duplicate values of the underlying MIB view's
system-group, is useful to have here specifically because all this
information is then contained in the same MIB view (e.g., a single
SNMP GetRequest can retrieve, for example all the sysUpTime values of 
all the entities in the chassis - a powerful feature !!).  Anybody got
any suggestions about what other frequently accessed MIB objects
we could promote and duplicate in the chasEntityTable, and thereby
reduce the amount of SNMP traffic needed to manage as chassis ?

Re: chasSegmentType taking the same set of values as ifType 

A nice idea, but unfortunately we all wish ifType had been defined as 
an OBJECT IDENTIFIER.  Making chasSegmentType an INTEGER would be a
mistake.

Re: chasConfigIfIndex

As somebody mentioned, having this would be extremely useful in knowing	
which entry in the entity's underlying MIB view represents the connection
to the backplane segment.  There are two problems with it: for some
entities, the backplane segment connection will not be an "interface",
in particular, repeaters have "ports", not "interfaces".  Second, it's
not altogether clear to me whether this information would be available
to the Chassis's agent.  So, while I can envisage a generalization to 
cover the port/interface issue, I'm still not sure whether it's
practical.  If somebody can suggest a way to make it practical, I'd
very much like to keep it; if not, we need to delete impractical stuff.

Re: LEDs/etc.

I agree with David that these are not specific to a chassis, and belong
in another MIB.  The only way I could justify to have them here (e.g.,
in the chasSlotTable) would be the same reason I used above to justify 
the system-group-like stuff in the chasEntityTable, BUT they're not
even in another MIB (yet), so I think we should at least defer this
from the Chassis MIB.

Re: chasUpTime

The only way I can see this could work is if the chassis has a non-volatile
clock which continues to tick even when the chassis's "network management
subsystem" (i.e., its agent) is reset.  I don't believe we can assume that
(note that SNMP Security with its need for clocks which don't run backwards
determined it could not be required).  Without a non-volatile clock, when
the agent resets, it loses track of how long since the last power-up. 
Is it the inverse case which is of concern, where the agent continues to
run even when power is lost to the chassis ??  (Is this inverse case even
possible ?)

Regarding another comment on chasUpTime, where somebody stated a problem
of "2 agents reporting different values of chasSlotLastChange": my model
is that there is only one agent in the chassis which implements the
Chassis MIB, so there can NOT be "2 agents reporting different values 
of chasSlotLastChange".  Perhaps, this again indicates some confusion
and suggests we need text in the Overview to say that only one agent
in a chassis implements this MIB.

Re: Power Supply MIB

This working group is also preparing a Power Supply MIB, but as a separate
document.  (right, Bob ?)

Keith.

PS. Are there any other outstanding issues that I should have commented on ?