[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Addition to MIB guidelines
Dave
Thanks for bringing this up and starting a discussion
with MIB doctors. I have not read it yet, but will do
over the next few days.
I hope it will NOT delay your reviews of the hubmib
documents. Pls give them prioroity over these additional
MIB review guidelines.
Bert
> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of David T. Perkins
> Sent: Tuesday, September 13, 2005 01:40
> To: mreview@ops.ietf.org
> Subject: 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
>
>