Very Computer

Hi,

We are currently developing a SNMP agent for our application servers.
We have a table in the MIB, which has two strings as the fields of the
table and these also form the index.

For example: consider the fields to be: ApplicationPluginType,
ApplicationPluginPath. Now we do not have any control on the length of
ApplicationPluginPath (it is basically the complete path to the
plugin). We noticed that RFC 1905 states that "SNMPv2 limits OBJECT
IDENTIFIER values to a maximum of 128 sub-identifiers, where each
sub-identifier has a maximum value of 2**32- 1.".

As a result, we are running in to problems using ApplicationPluginPath
as part of the index. Since the index is basically an OID. Basically
as long as one uses fields with datatypes like IpAddress, Integer etc.
in the index, one does not need to worry a lot about the index size
(for example since the IPAddress would mean four sub-identifiers being
added to the index).

We are planning to add another column to our table say
ApplicationPluginIndex which would be of type Integer and would be the
only index field. Basically this would help us overcome the index
length restriction. We would auto-generate a unique value for this
index for each row in the table.

Is this bad design? Is there some other approach which is typically
taken to solve such problems?

Any input on this is highly appreciated.

Thanks,
Paresh.

Hi Paresh-

Yes, long strings used for table indexing can become cumbersome.  Using an
"arbitrary integer" index scheme is a reasonable solution to your immediate
concern.

Please review the SYSAPPL-MIB (RFC 2287), especially the
sysApplInstallElmtTable- the sysApplInstallElmtPath seems similar to your
ApplicationPluginPath object.

Its a good design practice to first review standards track mib modules for
management objects that apply to what you want to manage.  This way you can take
advantage of well known management object definitions instead of (re-)inventing
your own.

Its entirely possible to extend the information your system reports within its
implementation of the sysApplInstallElmtTable with a similarily indexed table
defined within your enterprise namespace.

Regards,

Mark