Next for each managed object class, determine whether there can exist
multiple instances of that managed object class. If not, then for
each of its attributes, use the OBJECT-TYPE macro to make an
equivalent definition.
Otherwise, if multiple instances of the managed object class can
exist, then define a conceptual table having conceptual rows each
containing a columnar object for each of the managed object class's
attributes. If the managed object class is contained within the
containment tree of another managed object class, then the assignment
of an object type is normally required for each of the "distinguished
attributes" of the containing managed object class. If they do not
already exist within the MIB module, then they can be added via the
definition of additional columnar objects in the conceptual row
corresponding to the contained managed object class.
In defining a conceptual row, it is useful to consider the
optimization of network management operations which will act upon its
columnar objects. In particular, it is wisest to avoid defining more
columnar objects within a conceptual row, than can fit in a single
PDU. As a rule of thumb, a conceptual row should contain no more
than approximately 20 objects. Similarly, or as a way to abide by
the "20 object guideline", columnar objects should be grouped into
tables according to the expected grouping of network management
operations upon them. As such, the content of conceptual rows should
reflect typical access scenarios, e.g., they should be organized
along functional lines such as one row for statistics and another row
for parameters, or along usage lines such as commonly-needed objects
versus rarely-needed objects.
On the other hand, the definition of conceptual rows where the number
of columnar objects used as indexes outnumbers the number used to
hold information, should also be avoided. In particular, the
splitting of a managed object class's attributes into many conceptual
tables should not be used as a way to obtain the same degree of
flexibility/complexity as is often found in MIB's with a myriad of
optionals.
