On 07/02/2008, Giuseppe Modugno <[EMAIL PROTECTED]> wrote:
> Here it is an example (it's not true).
>
> Suppose my company produces DVD recorders, DVD players,
> audio/video mixers, and so on. Each product has a RS232 for remote
> control purpose....
OK
> and each product can be associated to a MIB.
No - forget about the MIBs for now.
Concentrate on the information that you're looking to model.
> Parameters for DVD records DVDREC2000 could be: record (on, off); time; input
> (front, rear); inputType (scart, composite,...);
Presumably each individual DVD recorder can only have one instance
of each of these elements? (Different recorders will presumably have
different values)
> a table with programs to record at a certain times; ...
A distinct table for each recorder, I presume?
> Parameters for DVD players DVDPLA2000 could be: play (on, off); output (front,
> rear); videoOutput (composite, component, scart...)
How much of this (if anything) is common between DVD recorders and
DVD players?
> The MIB for my company should be:
... left until you've finished the analysis of the information structure :-)
> What is the MIB (or MIBs) I should give to the user in order to manage the
> entire kit with a SNMP manager? The only solution is to make a different set
> of
> MIBs for each combination of devices.
No.
I'd say that for the example above, you probably need one or two MIBs,
containing three MIB tables. Or maybe one/three MIBs, with four tables.
But I'll come on to that in a moment.
Consider the DVD players first.
> Parameters for DVD players DVDPLA2000 could be:
> play (on, off); output (front,rear); videoOutput (composite, component,
> scart...)
I'm assuming here that each player will have a single value for each of these
settings (play, output, videoOutput, etc)
This could be modelled using a simple table:
dvdPlayerTable
dvdPlayerEntry
dvdPlayerIndex
dvdPlayerStatus (on, off)
dvdPlayerOutputLocation (front, rear)
dvdPlayerOutputVType (composite, component, scart)
Each individual player would be represented by one line in this table.
If a box has several DVD players attached to it, then it would have
multiple rows in the dvdPlayerTable. If it only comes with a single
DVD player, then there would only be one row in the table. And if
it doesn't have a DVD player at all, then this table would be empty.
> Parameters for DVD records DVDREC2000 could be:
> record (on, off); time; input (front, rear); inputType (scart, composite,...);
Those could be handled similarly:
dvdRecorderTable
dvdRecorderEntry
dvdRecorderIndex
dvdRecorderStatus
dvdRecorderTime
dvdRecorderInputLocation
dvdRecorderInputType
again, with one row per attached device.
> a table with programs to record at a certain times;
That would typically be handled by a "table-within-a-table" approach:
dvdTimerTable
dvdTimerEntry
dvdTimerIndex
dvdTimerStart
dvdTimerFinish
indexed by the pair (dvdRecorderIndex, dvdTimerIndex).
Note that this would actually be defined as a completely
separate table (not as a child of the main dvdRecorderTable).
It's the use of a shared index object that sets it up as a
table-within-a-table.
Those three tables would be sufficient to monitor/manage
any combination of attached DVD devices.
Now I know this is just a simple example, but my immediate
reaction was that the "parameters" analysis was woefully thin.
In reality, you would need to think about:
- all the "current settings" information that you might
want to retrieve from these boxes
(read-only columns in the table)
- all the "control" operations that you might want
to perform on these boxes, and the values these might accept
(read-write/read-create columns)
Also, if there was some overlap between the Player and Recorder
tables (such as the location/type of the connectors), then it might
be worth pulling these out into a separate table:
dvdTable
dvdEntry
dvdIndex
dvdConnectorLocation (front, rear)
dvdConnectorType (composite, component, scart)
These columns could then be omitted from the Player/Recorder
tables. In addition, these two tables would typically then also
be indexed by the shared 'dvdIndex' value, rather than having
separate index objects. This means that the Player/Recorder
tables would then (sparsely) AUGMENT the main DVD Table,
rather than being completely independent.
> Each product has a RS232 for remote control purpose...
Similarly, you might consider whether you need an rs232Table,
to monitor and/or manage the characteristics of the serial port(s)
and/or remote control settings (technology/speed/frequencies/etc),
which might be independent of the type of device connected
via that port.
There's no One Right Way to design this.
But you need to start by thinking about how you will want
to manage these boxes (control operations and management
tasks), and the information you would need to work with to do this,
Only *after* you've done this analysis, can you start thinking
about how to structure the MIB(s).
All very hand-waving I know, but I hope this has been vaguely
helpful.
Dave
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
