Re: Mib questions

[Bob Stewart <[e-mail]>]

Dave,

Nice "private" conversation we're having here.  I guess everybody else must
agree with me.  Maybe I should be deliberately provocative.  The questions you
raised seem to me like vital issues, and I'd be pleasantly surprised if we all
shared the same opinions on them.

>>Muahahahahaha.  Yes, on the basis that consistent means different but related
>>as opposed to identical.
>
>I don't quite understand this, but my question was maybe not precise enough.
>How about, the following...

I guess my answer was a bit unclear.  I forsaw the start of a religious war,
so I lapsed into foolish.

>When multiple agents in a chassis implement the MIB...
>6a) Must the value of chasNumSlot be the same for both?
>6b) Must the indices for the slots in the chassSlotTable be the same for both?
>    (i.e., can one implement them "dense" and the other implement them "sparse"?)
>6c) Can the list of devices(values for chasSlotModuleType) as seen from the
>    two different agents be different.  If there can be a difference can it
>    only be for values chasSlotUnknown?
>6d) Is it Ok for chasSlotModuleDescr, ...Version, ...SerialNumber to have
>    different values as seen from each agent.
>6e) Does this list of questions have to go on for all the objects in the
>    chassis MIB?

I would expect the values to mostly be the same.  It is after all supposed to
be the same chassis.  Values based on sysUpTime would be relative to the
individual agent.  So what does it mean if an NMS finds inconsistent values?
Uhhh, got me.  Depends on how you use them.  In the Interface Table thread,
Keith said we have to include segment mapping in the Chassis MIB because we
need a single, consistent way to number segments.  I guess I'd expect that
sort of assertion to be desirable, if not required, across everything in the
chassis.  They are supposed to be tied together in SOME way after all.

>On question 9, which is
>>>9) What are some situations the it would be appropriate to use
>>>   a "sparse" slot table?
>
>You said...
>>Any situation the implementor chooses.  You might choose to do that in a
>>2-slot chassis or one the size of Texas.
>
>What would be a situation where an implementor would choose?  It there are no
>criteria, then I would suggest in the name of interoperability that the MIB
>choose one model.

In a small system where the chassis is in fact a well defined hardware crate,
I'd probably expect to see a filled-in slot table, but not necessarily.  In a
large, amorphous chassis, I'd expect a sparse table, to save overhead.  To me
this falls in the same general category as deleting an entry with 'invalid'
status.  Why not just leave it up to the implementor?

>On question 10, which is
>>>10) Is a "logical device" a realised hardward component which has
>>>    an unchanging identity, or does it also include "personalities"
>>>    that are identified by the software that is running on the
>>>    "logical device". An example would be a File server, loadable
>>>    RMON software, Mail server, or any other "application server".
>
>Your answer seemed to me to say that a "logical device" could be contained
>on part of a physical module, a complete physical module, on on several
>physical devices. I understand that - there was a proposal, i believe,
>(which is not in the MIB that arneson sent out) that showed the mapping.

I believe the chasConfigTable covers the mapping.  A multi-slot entity would
show up as the same chasConfigEntity indexed under multiple chasConfigSlots,
and would, I suppose, include useful or repetitious chasConfigSegment values.

>I was asking another, more fundamental question, that is - what really
>is a logical device?  Is a module that has a general purpose CPU
>on it (i.e., a "host") count as THE "logical device", or can it be
>further divied so that applications running on it count as
>"logical devices". (BTW - this sort of feel like the interfaces model
>question.) 

Hmmmm.  I see.  MUST you divide up into separate entities?  I guess not, since
type is a bitmap, unless, as with a repeater, other definitions say you must.

>On the last question that I had, which asked how was an agent that implemented
>the chassis MIB to get the values for the MIB objects, you indicated
>that the "most sensible" choice was to use a backplane bus. There are
>two followups here.
>
>1) Is it OK to use a VERY simple backplane bus that can give only limited
>   information such as the IDs of the physical modules and which slots
>   have modules installed, then use configuration files for the other
>   information such as IP address?
>2) How many real live implementations are there out there that have the
>   backplane and CPU support to implement the complete set of objects
>   without use of configuration files? (We have got to ask this question.
>   If people want the responses to be confidential, then Bob or Jeff or
>   someone needs to summarize the responses.)

On part 1, what you suggest seems acceptable, but maintaining such files
correctly would be a pain.  But then who am I to judge?  Part 2 is the
question I've kept asking and not seen any answers.  If people want to make
confidential answers, I suggest they make them to Jeff, as chassis-type
products are part of Xyplex's business.

	Bob