RE: updating dynamic tables in an agent

David Perkins (dperkins@scruznet.com)
Fri, 29 Mar 96 08:20:59 pst

Robert,

Your message describes a common misunderstanding about agents and
implementing access to management information. This misunderstanding
is called the "MIB Myth." It is the belief that an actual database
containing the values of management information, called a MIB, exists
in a managed system. Such a database is NOT required, and such an
agent implementation strategy is in most cases a burden on the processing
and main memory resources of a managed system. Better implementation
strategies exist and should be used.

SNMP's identification of management information by object identifiers,
and the retrieval of management information by GETNEXT and GETBULK
in lexi-order is deceptively simple, yet provides all the needed power
to efficiently implement SNMP-based management without a database
containing management information on a system.

Please note that the implementation job of an agent developer can be
made quite difficult (or nearly impossible) by MIB designers! This can
occur when the indexing scheme for management information does not
match the normal or "local" mechanisms found in the managed system.
It can also occur, especially for settable objects, when objects
are designed to "perform an action." Since, a MIB designer can not
restrict the variables in a SET request, an agent may be asked to
"perform" more than one action in the same request and these actions
may not both be done "simultaneously" (i.e., one result occurs if
action A1 is followed by action A2, and another result occurs if
action A2 is followed by action A1). (Note that "action objects"
should only be used to start (or initiate) actions and not used
to "complete an action". It's OK to "start toasting of the bread",
but it's not OK to "toast the bread".)

Where the implementation costs of management really skyrocket, is
when a cache is used to hold management information and the instances
and/or values of the management information are "dynamic".
(By the way, the "current" values of an agent's "management information"
can be found in three places. These are 1) in the "instrumentation",
2) in an agent's cache, and 3) on a manager.)

There is no easy solution to this problem without teamwork of the
MIB designer, developer of the interfaces to the instrumentation, and
the developer of the method routines (the code that translates the
SNMP identification of management info to local identification and
access to instrumentation). The IETF WGs, which act as the MIB designer,
are suppose to work to make sure that "right cost to implement"
MIBs are developed. If not, the SNMP community has to pay the cost
of each WG's failure to make acceptable design choices.

Please note that the example MIB module fragmens show poor MIB design
(and in your actual example, illegal MIB design, but your example
probably was a typo). (The OID value of { unixPsTable 1 } for
unixPsTableLastUpdate is illegal, and the OID value of { unixPsTable 2 }
for unixPsTableEntry is illegal.)

The example is a poor design, since it requires a particular
implementation strategy of the agent's method routines.
This type of MIB module design approach, (mixing management
implementation (i.e., an agent's method routines and instrumentation)
with architecture) can work in single vendor, single product
situations. However, such an approach DOES NOT WORK in multi-vendor or
multiple version (and products) situations. Such an approach
ensures death or infamy to its application, even though the
application may have initially enjoyed warm reviews.

Regards,
/dperkins@scruznet.com, David T. Perkins
Date: 03/29/96, Time: 08:20:59