[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Addition to MIB guidelines
HI,
While going through a MIB review last week I noticed that
while the MIB review guidelines contained some guidance
on definitions for tables and rows, didn't seem to be
complete.
Below is some "unpolished" text for merging into
the text of section 4.6.4:
The contents of the DESCRIPTION clauses for
Table and Row objects
-------------------------------------------
One of the most difficult parts in understanding
the definitions in a MIB module both for adding
support in managed systems and for creating
management applications is determining
1) how many rows will be in a table
2) what causes rows to be added and removed
from tables
3) what are the relationships between rows
in a table with rows in other tables
In general, rows in tables are added and removed
due to management configuration operations,
operations of the subsystem being managed,
presence of physical components,
or via management action operations.
The relationship between an operation and
the addition or removal of a row in a
table can be direct or indirect. For example,
an SNMP SET operation (or CLI command) could
be used to create a new instance in a
a specific table. This is a direct operation.
However, if on creation of a row in, say,
table A, rows are created in other tables,
say, table B and C, the additions in B and C
are indirect. Typically, there are more
indirect removals of rows than additions.
This occurs when rows in, say, table D
depend on the existence of rows in, say,
table A.
The SNMP SMI allows definitions to refer to
other definitions. Unfortunately, the
MIB module language defined by the SMI
is rather weak in mechanisms to express
inter-row references. Also, the SMI is
weak in mechanisms to describe "referential
integrity". That is, a reference may
require that the target (a row) exist,
and if so, a target cannot be deleted
when it has references. There are several
terms that are used to describe referential
integrity, such as "strong" to mean
restrictions exist in creating references
and deleting targets of references,
or "weak" to mean that references
can identify targets that do not exist and
targets can be deleted that have references.
Because the mechanisms in the MIB module
language are weak for describing when rows
are added and removed, and for describing
references and identification of rows,
this information must be specified in
DESCRIPTION clauses. The best approach is
to follow a consistent pattern of specifying
this information in the DESCRIPTION clauses
of tables and rows.
In particular, the DESCRIPTION clause for a
table must include the following:
1) a short description of what the table
2) a short description of how many
rows are in the table. As previously
mentioned, rows are added due to
different operations. Thus, a description
may look like any of the following:
a) configuration based. For example,
"the number of rows is the
number of configured users" describes
the number of entries in the USM table
defined in RFC 3414.
b) operation based. For example,
"the number of rows is the number
of TCP connections (in any state)
that presently exist" describes the
the TCP connection table defined
in RFC 1213 (and most recently in
RFC 4022).
c) physical (and virtual) component based.
For example, "the number of rows is the
number of managed 'physical' components
in the system" describes the physical
entity table defined in RFC 4133.
NOTE: these examples are very simple, and
should be "completely obvious" to
experts. However, many tables are
complex, and determining the number
of rows can be difficult. Getting
an understanding of the number of
rows is a key piece of data for
the designers of access routines
of SNMP agents, and designers
of management applications.
Scaling is important!
The DESCRIPTION clause for a row must
must include the following:
1) how rows are added and deleted from
the table. This can include:
a) direct SNMP operations - this means
via SET operation(s) to columnar
objects in the table. If a column
is used to guide creation or deletion,
such as a RowStatus column, it must
be identified in the row definition.
(There are many examples.)
b) indirect SNMP operations - this means
via SET operation(s) to other table(s).
This is the case where rows in, say,
table B, have an existence relationship
with rows in, say, table A. A one-to-one
relationship is indicated with the
AUGMENTS clause.
c) other management operations - this means
that while rows cannot be added or removed
via SNMP operations, that they are
added or removed via other management
operations
d) physical operations on the device - this
means that physical operation must be done
on the device, such as adding or removing
a component. Note that physical components
may be virtualized, and, if so, this includes
creating or deleting a virtual component.
e) system operation - this means that rows are
added and removed by the operation of the
managed subsystem. Note, that is includes
the design pattern found in many MIB modules
that have two tables. The first is a
"control table", where rows are added and
and removed via direct SNMP operations.
The second table has rows added when
events described by the control table
occur (that is, via system operation).
Note that such tables maybe resource
limited, and, if so, system operation
may remove (or replace) rows based on
policy (which may be "hard coded" or
"parameterized" with configuration).
f) hybrid - this includes a mixture of the
above operations. The most typical is that
rows are added and removed via system operation,
but may also be removed via management
operations (SNMP or other management interfaces).
For example, the rows in the TCP connect
table are added only via system operation
(they cannot be added via management operation),
but they can be removed via both system
and management operation.
2) The relationship with other tables. This should be
covered in #1. Note that the SMI requires the
DESCRIPTION clause for a row to describe index
objects that are not columns in the table.
3) Alternative ways to identify rows in the table.
Some tables contain columnar objects whose
value may also uniquely identify a row in
the table. It is critical for this to be
made clearly visible so that MIB designers,
and both agent and management developers
understand this capability and implementation
requirement. An example of such a table is
protocolDirTable defined in RFC 2021. The
table is indexed by objects protocolDirID and
protocolDirParameters, and has object
protocolDirLocalIndex that also uniquely
identifies rows in the table.
4) A list of reference columnar objects in the table.
By specifying a list in the row's DESCRIPTION
clause, it becomes much easier to locate
inter-table references. An example is
object snmpNotifyTag in table snmpNotifyTable
defined in RFC 3413, which selects rows in
table snmpTargetAddrTable.
In many MIB modules, much of information specified
above is contained in definitions, or found in the
commentary section of the containing document. However,
few have the information consistently in the table
and row definitions. Clearly, consistency helps to
avoid missing and ambiguous definitions, which
leads to increased chance of interoperability.
Regards,
/david t. perkins