RE: Module Index on Module Table.

[{3COM/PDD/PeteW}@pdd.3mail.3com.com]

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Chassis MIB
Subject:  RE: Module Index on Module Table.
Date: 1993-04-20 14:15
Priority: 
Fixed Font: 0001
Message ID: B15ADD5A
Conversation ID: B15ADD5A

------------------------------------------------------------------------------

From Dave
>Pete Wilson and I have a couple differences of opinion that need to be
>resolved.  I will edit in that which the working group deems as best.
>
>Module table:
>	- Pete recommends indexing this by physical location type and location
>	index.  I have edited the MIB indexing this table by a single unique
>	module index.  This is carried foward into the other tables that
>	use modules.
>
>	- Pete also had the resource table indexed by module, resource
>	I defined a resource table indexed by a single unique resource index
>	and used this value in physical config tables and logical config
>	tables.  This mapping seems to make it easier for me to read anyway
>	once again the working groups word is that which I will implement.

I'd like to expand on my reasons for wanting the 'real' index to the table 
rather than the simplification Dave suggests. This is an extract from a mail 
I sent to Dave...

. There are several reasons I don't like this single index:
.
. 1) Understandability. There is a 'real-life' way of identifying a
. module which uses the location type and location index, ie "Power
. Supply 2", The "module in slot 7". This index is simply 2 integers.
. You propose replacing this natural index with an artificial index,
. which causes problems. If nothing else this makes examples more complex.
.
. 2) coding problems on agent and manager. You're replacing the natural
. index of type.n with a single number. This means an extra mapping
. function at both ends which is unnecessary complicates the code, I
. know its simple but it does cause problems. Both agent and manager
. have to store the mapping, the manager probably in a database, which
. slows down access.
.
. All you save by having a single integer in place of the double index
. is an OID level in a PDU, which with ASN1 encoding will be a single
. byte per OID. The overhead (SNMPv1) is that you have to create a new
. MIB object in the agent, store it, provide translation functions, all
. of which are unnecessary. In SNMPv2 it's worse because you can share
. the location type variable with the location description table. I
. contend that the pain of using a single index is greater all around
. than using the two indices.
.
. As far as implementation is concerned, if you are worried about
. storage or overhead then consider the following. A particular chassis
. has 4 location types:
.           PSU Bay, Fan Tray, BackPlane, Modular Slot.
. Of these there are at most, say, 10 instances. Now for this
. implementation I can decode the location type and instance into  single
. byte using 'index = locationType<<4+locationIndex'.
.
. This kind of implementation detail should be hidden from the MIB, the
. MIB should use the most natural way of indexing the table and let the
. implementations do the optimising.

The single integer does not simplify all agents or managers, it complicates 
them by adding a level of indirection at both ends. Some implementations may 
be made easier but others more difficult. The best approach is to provide 
the most obvious and easy to understand index, that being location type and 
instance.

Pete