Re: Chassis MIB comments

["David L. Arneson ([e-mail])" <[e-mail]>]

> From: [e-mail] (Keith McCloghrie)
> 
> 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 :-).
>
OK rather than get hung up on a small issue how about the following 
additions to the document:

Section 5.4 which discusses the configuration table:
	It is an implementation specific matter as to wether the objects in
	this table are implemented as read-write or read-only.

Also add something similar to the description of chasConfigStatus. 

> 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 ?
>
I will expand the description in section 5.2 to add a discussion on
MIB views and access entities.  Something similar to the above.

In reading the The above statement.  Perhaps it would be benificial to
redefine chasEntityTimeStamp from a time stamp as presently defined to
chasEntityTime "sysUpTime for this entity".
 
> 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.
>
I think that pretty much sums up the problem.  In addition isn't the
information also available on device it's self.  For that matter isn't
going to the device for the information the best answer?  Lets consider
a single bridge entity that encompasses two different modules.  I submit
that getting specific interface information about the bridge at the chassis
level could be very difficult.
 
> 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.
>
I have to agree with Keith, at least in part.  I belive that there maybe
instances where there maybe more than one chassis MIB resident in a chassis.
Let's consider a single chassis that has been logically divided.  Then
there could be a second agent (sub agent) that would implement it's own
view of a chassis MIB.  The first agent would have knowledge of what modules
reside in he entire chassis.  This agent would also have knowledge of
entities in his view.  However only the sub agent would have knowledge of
the entities that reside on the modules in his view.

So yes you should only have one correct view of sysUpTime for each entity.
However it maybe possible to have multiple logical chassises within a single
physical chassis.

Have I totally confused everybody?

> Re: Power Supply MIB
> 
> This working group is also preparing a Power Supply MIB, but as a separate
> document.  (right, Bob ?)
>
If I remember correctly Jeff Case assigned somebody the job of condensing
the various MIBs that are currently implemented by the members.
Since I need to come up with a power supply MIB for our usage I will
happly take this condensed list of objects and format a MIB and submit
it for approval.  Our power supply people should be providing me with
some additional information on the more intelligent power supplies.

I think a seperate document would be the best format.
 
> Keith.
> 
> PS. Are there any other outstanding issues that I should have commented on ?

I shall attempt to allocate some time the first part of the week to start
condensing the various comments made.  Hopefully by say tuesday I can have
another document.  From what I'm hearing I think we maybe able to submit
this revision as an internet draft.

/David Arneson ([e-mail])