also lists certain predefined symbols that must not be imported.
The general requirement is that if an external symbol other than a
predefined ASN.1 type or the BITS construct is used, then it MUST be
mentioned in the module’s IMPORTS statement. The words "external
object" in the first paragraph of that section may give the
impression that such symbols are limited to those that refer to
object definitions, but that is not the case, as subsequent
paragraphs should make clear.
Note that exemptions to this general requirement are granted by RFC
2580 Sections 5.4.3 and 6.5.2 for descriptors of objects appearing in
the OBJECT clause of a MODULE-COMPLIANCE statement or in the
VARIATION clause of an AGENT-CAPABILITIES statement. Some MIB
compilers also grant exemptions to descriptors of notifications
appearing in a VARIATION clause and to descriptors of object groups
and notification groups referenced by a MANDATORY-GROUPS clause, a
GROUP clause, or an INCLUDES clause, although RFC 2580 (through
apparent oversight) does not mention those cases. The exemptions are
sometimes seen as unhelpful because they make IMPORTS rules more
complicated and inter-module dependencies less obvious than they
otherwise would be. External symbols referenced by compliance
statements and capabilities statements MAY therefore be listed in the
IMPORTS statement; if this is done, it SHOULD be done consistently.
Finally, even though it is not forbidden by the SMI, it is considered
poor style to import symbols that are not used, and standards-track
MIB modules SHOULD NOT do so.
4.5. MODULE-IDENTITY Invocation
RFC 2578 Section 3 requires that all SMIv2 MIB modules start with
exactly one invocation of the MODULE-IDENTITY macro. This invocation
MUST appear immediately after the IMPORTS statement.
RFC 2578 Section 5 describes how the various clauses are used. The
following additional guidelines apply to all MIB modules over which
the IETF has change control:
- If the module was developed by an IETF working group, then the
ORGANIZATION clause MUST provide the full name of the working
group, and the CONTACT-INFO clause MUST include working group
mailing list information. The CONTACT-INFO clause SHOULD also
provide a pointer to the working group’s web page.
- A REVISION clause MUST be present for each revision of the MIB
module, and the UTC time of the most recent REVISION clause MUST
match that of the LAST-UPDATED clause. The DESCRIPTION clause
associated with each revision MUST state in which RFC that revision
appeared and SHOULD provide a list of all significant changes.
When a MIB module is revised, UTC times in all REVISION clauses
SHOULD be updated to use four-digit year notation.
- The value assigned to the MODULE-IDENTITY descriptor MUST be unique
and (for IETF standards-track MIB modules) SHOULD reside under the
mgmt subtree [RFC2578]. Most often it will be an IANA-assigned
value directly under mib-2 [RFC2578], although for media-specific
MIB modules that extend the IF-MIB [RFC2863] it is customary to use
an IANA-assigned value under transmission [RFC2578]. In the past,
some IETF working groups have made their own assignments from
subtrees delegated to them by IANA, but that practice has proven
problematic and is NOT RECOMMENDED.
While a MIB module is under development, the RFC number in which it
will eventually be published is usually unknown and must be filled in
by the RFC Editor prior to publication. An appropriate form for the
REVISION clause applying to a version under development would be
something along the following lines:
REVISION "200212132358Z" -- December 13, 2002
DESCRIPTION "Initial version, published as RFC yyyy."
-- RFC Ed.: replace yyyy with actual RFC number & remove this note
Note that after RFC publication, a REVISION clause is present only
for published versions of a MIB module and not for interim versions
that existed only as Internet-Drafts. Thus, a draft version of a MIB
module MUST contain just one new REVISION clause that covers all
changes since the last published version (if any).
When the initial version of a MIB module is under development, the
value assigned to the MODULE-IDENTITY descriptor will be unknown if
an IANA-assigned value is used, because the assignment is made just
prior to publication as an RFC. The accepted form for the MODULE-
IDENTITY statement in draft versions of such a module is something
along the following lines:
<descriptor> MODULE-IDENTITY
[ ... ]
::= { <subtree> XXX }
-- RFC Ed.: replace XXX with IANA-assigned number & remove this note
where <descriptor> is whatever descriptor has been selected for the
module and <subtree> is the subtree under which the module is to be
registered (e.g., mib-2 or transmission). Note that XXX must be
temporarily replaced by a number in order for the module to compile.
Note well: prior to official assignment by the IANA, a draft
document MUST use a placeholder (such as "XXX" above) rather than an
actual number. If trial implementations are desired during the
development process, then an assignment under the ’experimental’
subtree may be obtained from the IANA (cf. Section 4.3).
4.6. Textual Conventions and Object Definitions
4.6.1. Usage of Data Types
4.6.1.1. INTEGER, Integer32, Gauge32, and Unsigned32
The 32-bit integer data types INTEGER, Integer32, Gauge32, and
Unsigned32 are described in RFC 2578 Section 2 and further elaborated
in RFC 2578 Sections 7.1.1, 7.1.7, and 7.1.11. The following
guidelines apply when selecting one of these data types for an object
definition or a textual convention:
- For integer-valued enumerations:
- INTEGER is REQUIRED; - Integer32, Unsigned32, and Gauge32 MUST
NOT be used.
Note that RFC 2578 recommends (but does not require) that integer-
valued enumerations start at 1 and be numbered contiguously. This
recommendation SHOULD be followed unless there is a valid reason to
do otherwise, e.g., to match values of external data or to indicate
special cases, and any such special-case usage SHOULD be clearly
documented. For an example, see the InetAddressType TC [RFC4001].
Although the SMI allows DEFVAL clauses for integer-valued
enumerations to specify the default value either by label or by
numeric value, the label form is preferred since all the examples in
RFC 2578 are of that form and some tools do not accept the numeric
form.
- If the value range is between -2147483648..2147483647 (inclusive)
and negative values are possible, then:
- Integer32 is RECOMMENDED;
- INTEGER is acceptable;
- Unsigned32 and Gauge32 MUST NOT be used.
- If the value range is between 0..4294967295 (inclusive) and the
value of the information being modelled may increase above the
maximum value or decrease below the minimum value, then:
- Gauge32 is RECOMMENDED;
- Unsigned32 is acceptable;
- INTEGER and Integer32 MUST NOT be used if
values greater than 2147483647 are possible.
- If the value range is between 0..4294967295 (inclusive), and values
greater than 2147483647 are possible, and the value of the
information being modelled does not increase above the maximum
value nor decrease below the minimum value, then:
- Unsigned32 is RECOMMENDED;
- Gauge32 is acceptable;
- INTEGER and Integer32 MUST NOT be used.
- If the value range is between 0..2147483647 (inclusive), and the
value of the information being modelled does not increase above the
maximum value nor decrease below the minimum value, then:
- Unsigned32 is RECOMMENDED;
- INTEGER, Integer32, and Gauge32 are acceptable.
- For integer-valued objects that appear in an INDEX clause or for
integer-valued TCs that are to be used in an index column:
- Unsigned32 with a range that excludes zero is RECOMMENDED for
most index objects. It is acceptable to include zero in the
range when it is semantically significant or when it is used as
the index value for a unique row with special properties. Such
usage SHOULD be clearly documented in the DESCRIPTION clause.
- Integer32 or INTEGER with a non-negative range is acceptable.
Again, zero SHOULD be excluded from the range except when it is
semantically significant or when it is used as the index value
for a unique row with special properties, and in such cases the
usage SHOULD be clearly documented in the DESCRIPTION clause.
- Use of Gauge32 is acceptable for index objects that have gauge
semantics.
The guidelines above combine both the usage rules for integer data
types and the INDEX rules in RFC 2578 Section 7.7 up to and including
bullet (1) plus the next-to-last paragraph on page 28.
Sometimes it will be necessary for external variables to represent
values of an index object -- e.g., ifIndex [RFC2863]. In such cases,
authors of the module containing that object SHOULD consider defining
TCs such as InterfaceIndex and/or InterfaceIndexOrZero [RFC2863].
Note that INTEGER is a predefined ASN.1 type and MUST NOT be present
in a module’s IMPORTS statement, whereas Integer32, Gauge32, and
Unsigned32 are defined by SNMPv2-SMI and MUST be imported from that
module if used.
4.6.1.2. Counter32 and Counter64
Counter32 and Counter64 have special semantics as described in RFC
2578 Sections 7.1.6 and 7.1.10, respectively. Object definitions
MUST (and textual conventions SHOULD) respect these semantics. That
means:
- It is OK to use Counter32/64 for counters that may/will be reset
when the management subsystem is re-initialized or when other
unusual/irregular events occur (e.g., counters maintained on a line
card may be reset when the line card is reset). However, if it is
possible for such other unusual/irregular events to occur, the
DESCRIPTION clause MUST state that this is so and MUST describe
those other unusual/irregular events in sufficient detail that it
is possible for a management application to determine whether a
reset has occurred since the last time the counter was polled. The
RECOMMENDED way to do this is to provide a discontinuity indicator
as described in RFC 2578 Sections 7.1.6 and 7.1.10. For an example
of such a discontinuity indicator, see the
ifCounterDiscontinuityTime object in the IF-MIB [RFC2863].
- It is NOT OK to put in the DESCRIPTION clause of a Counter32/64
that there is a requirement that on a discontinuity the counter
MUST reset to zero or to any other specific value.
- It is NOT OK to put in the DESCRIPTION clause of a Counter32/64
that there is a requirement that it MUST reset at any specific
time/event (e.g., midnight).
- It is NOT OK for one manager to request the agent to reset the
value(s) of counter(s) to zero, and Counter32/64 is the wrong
syntax for "counters" that regularly reset themselves to zero. For
the latter, it is better to define or use textual conventions such
as those in RFC 3593 [RFC3593] or RFC 3705 [RFC3705].
RFC 2578 Section 7.1.10 places a requirement on "standard" MIB
modules that the Counter64 type may be used only if the information
being modelled would wrap in less than one hour if the Counter32 type
was used instead. Now that SNMPv3 is an Internet Standard and SNMPv1
is Historic (see http://www.rfc-editor.org/rfcxx00.html for status
and [RFC3410] for rationale), there is no reason to continue
enforcing this restriction. Henceforth "standard" MIB modules MAY
use the Counter64 type when it makes sense to do so, and MUST use
Counter64 if the information being modelled would wrap in less than
one hour if the Counter32 type was used instead. Note also that
there is no longer a requirement to define Counter32 counterparts for
each Counter64 object, although one is still allowed to do so.
There also exist closely-related textual conventions
ZeroBasedCounter32 and ZeroBasedCounter64 defined in RMON2-MIB
[RFC2021] and HCNUM-TC [RFC2856], respectively.
The only difference between ZeroBasedCounter32/64 TCs and
Counter32/64 is their starting value; at time=X, where X is their
minimum-wrap-time after they were created, the behavior of
ZeroBasedCounter32/64 becomes exactly the same as Counter32/64.
Thus, the preceding paragraphs/rules apply not only to Counter32/64,
but also to ZeroBasedCounter32/64 TCs.
4.6.1.3. CounterBasedGauge64
SMIv2 unfortunately does not provide 64-bit integer base types. In
order to make up for this omission, the CounterBasedGauge64 textual
convention is defined in HCNUM-TC [RFC2856]. This TC uses Counter64
as a base type, but discards the special counter semantics, which is
allowed under the generally accepted interpretation of RFC 2579
Section 3.3. It does inherit all the syntactic restrictions of that
type, which means that it MUST NOT be subtyped and that objects
defined with it MUST NOT appear in an INDEX clause, MUST NOT have a
DEFVAL clause, and MUST have a MAX-ACCESS of read-only or
accessible-for-notify.
This TC SHOULD be used for object definitions that require a 64-bit
unsigned data type with gauge semantics. If a 64-bit unsigned data
type with different semantics is needed, then a different TC based on
Counter64 MUST be used, since one TC cannot refine another (cf. RFC
2579 Section 3.5).
4.6.1.4. OCTET STRING
The OCTET STRING type is described in RFC 2578 Section 7.1.2. It
represents arbitrary binary or textual data whose length is between 0
and 65535 octets inclusive. Objects and TCs whose SYNTAX is of this
type SHOULD have a size constraint when the actual bounds are more
restrictive than the SMI-imposed limits. This is particularly true
for index objects. Note, however, that size constraints SHOULD NOT
be imposed arbitrarily, as the SMI does not permit them to be changed
afterward.
There exist a number of standard TCs that cater to some of the more
common requirements for specialized OCTET STRING types. In
particular, SNMPv2-TC [RFC2579] contains the DisplayString,
PhysAddress, MacAddress, and DateAndTime TCs; the SNMP-FRAMEWORK-MIB
[RFC3411] contains the SnmpAdminString TC; and the SYSAPPL-MIB
[RFC2287] contains the Utf8String and LongUtf8String TCs. When a
standard TC provides the desired semantics, it SHOULD be used in an
object’s SYNTAX clause instead of OCTET STRING or an equivalent
locally-defined TC.
Note that OCTET STRING is a predefined ASN.1 type and MUST NOT be
present in a module’s IMPORTS statement.
4.6.1.5. OBJECT IDENTIFIER
The OBJECT IDENTIFIER type is described in RFC 2578 Section 7.1.3.
Its instances represent administratively assigned names. Note that
both the SMI and the SNMP protocol limit instances of this type to
128 sub-identifiers and require that each sub-identifier be within
the range 0 to 4294967295 inclusive. Subtyping is not allowed.
The purpose of OBJECT IDENTIFIER values is to provide authoritative
identification either for some type of item or for a specific
instance of some type of item. Among the items that can be
identified in this way are definitions in MIB modules created via the
MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE, and AGENT-
CAPABILITIES constructs; and via instances of objects defined in MIB
modules, protocols, languages, specifications, interface types,
hardware, and software. For some of these uses other possibilities
exist, e.g., OCTET STRING or enumerated INTEGER values. The OBJECT
IDENTIFIER type SHOULD be used instead of the alternatives when the
set of identification values needs to be independently extensible
without the need for a registry to provide centralized coordination.
There exist a number of standard TCs that cater to some of the more
common requirements for specialized OBJECT IDENTIFIER types. In
particular, SNMPv2-TC [RFC2579] contains the AutonomousType,
VariablePointer, and RowPointer TCs. When a standard TC provides the
desired semantics, it SHOULD be used in an object’s SYNTAX clause
instead of OBJECT IDENTIFIER or an equivalent locally-defined TC.
Note that OBJECT IDENTIFIER is a predefined ASN.1 type and MUST NOT
be present in a module’s IMPORTS statement.
4.6.1.6. The BITS Construct
The BITS construct is described in RFC 2578 Section 7.1.4. It
represents an enumeration of named bits. The bit positions in a TC
or object definition whose SYNTAX is of this type MUST start at 0 and
SHOULD be contiguous.
Note that the BITS construct is defined by the macros that use it and
therefore MUST NOT be present in a module’s IMPORTS statement.
4.6.1.7. IpAddress
The IpAddress type described in RFC 2578 Section 7.1.5 SHOULD NOT be
used in new MIB modules. The InetAddress/InetAddressType textual
conventions [RFC4001] SHOULD be used instead.
4.6.1.8. TimeTicks
The TimeTicks type is described in RFC 2578 Section 7.1.8. It
represents the time in hundredths of a second between two epochs,
reduced modulo 2^32. It MUST NOT be subtyped, and the DESCRIPTION
clause of any object or TC whose SYNTAX is of this type MUST identify
the reference epochs.
The TimeTicks type SHOULD NOT be used directly in definitions of
objects that are snapshots of sysUpTime [RFC3418]. The TimeStamp TC
[RFC2579] already conveys the desired semantics and SHOULD be used
instead.
4.6.1.9. TruthValue
The TruthValue TC is defined in SNMPv2-TC [RFC2579]. It is an
enumerated INTEGER type that assumes the values true(1) and false(2).
This TC SHOULD be used in the SYNTAX clause of object definitions
that require a Boolean type. MIB modules SHOULD NOT use enumerated
INTEGER types or define TCs that duplicate its semantics.
4.6.1.10. Other Data Types
There exist a number of standard TCs that cater to some of the more
common requirements for specialized data types. Some have been
mentioned above, and Appendix B contains a partial list that includes
those plus some others that are a bit more specialized. An on-line
version of that list, which is updated as new TCs are developed, can
be found at http://www.ops.ietf.org/mib-common-tcs.html.
Whenever a standard TC already conveys the desired semantics, it
SHOULD be used in an object definition instead of the corresponding
base type or a locally-defined TC. This is especially true of the
TCs defined in SNMPv2-TC [RFC2579] and SNMP-FRAMEWORK-MIB [RFC3411]
because they are Internet Standards, and so modules that refer to
them will not suffer delay in advancement on the standards track on
account of such references.
MIB module authors need to be aware that enumerated INTEGER or BITS
TCs may in some cases be extended with additional enumerated values
or additional bit positions. When an imported TC that may be
extended in this way is used to define an object that may be written
or that serves as an index in a read-create table, then the set of
values or bit positions that needs to be supported SHOULD be
specified either in the object’s DESCRIPTION clause or in an OBJECT
clause in the MIB module’s compliance statement(s). This may be done
by explicitly listing the required values or bit positions, or it may
be done by stating that an implementation may support a subset of
values or bit positions of its choosing.
4.6.2. DESCRIPTION and REFERENCE Clauses
It is hard to overemphasize the importance of an accurate and
unambiguous DESCRIPTION clause for all objects and TCs. The
DESCRIPTION clause contains the instructions that implementors will
use to implement an object, and if they are inadequate or ambiguous,
then implementation quality will suffer. Probably the single most
important job of a MIB reviewer is to ensure that DESCRIPTION clauses
are sufficiently clear and unambiguous to allow interoperable
implementations to be created.
A very common problem is to see an object definition for, say,
’stdMIBPoofpoofCounter’ with a DESCRIPTION clause that just says
"Number of poofpoofs" with no indication what a ’poofpoof’ is. In
such cases, it is strongly RECOMMENDED that there either be at least
a minimal explanation or else a REFERENCE clause to point to the
definition of a ’poofpoof’.
For read-write objects (other than columns in read-create tables that
have well-defined persistence properties), it is RECOMMENDED that the
DESCRIPTION clause specify what happens to the value after an agent
reboot. Among the possibilities are that the value remains
unchanged, that it reverts to a well-defined default value, or that
the result is implementation-dependent.
4.6.3. DISPLAY-HINT Clause
The DISPLAY-HINT clause is used in a TC to provide a nonbinding hint
to a management application as to how the value of an instance of an
object defined with the syntax in the TC might be displayed. Its
presence is optional.
Although management applications typically default to decimal format
("d") for integer TCs that are not enumerations and to a hexadecimal
format ("1x:" or "1x " or "1x_") for octet string TCs when the
DISPLAY-HINT clause is absent, it should be noted that SMIv2 does not
actually specify any defaults. MIB authors should be aware that a
clear hint is provided to applications only when the DISPLAY-HINT
clause is present.
4.6.4. Conceptual Table Definitions
RFC 2578 Sections 7.1.12 and 7.1.12.1 specify the rules for defining
conceptual tables, and RFC 2578 Sections 7.7, 7.8, and 7.8.1 specify
conceptual table indexing rules. The following guidelines apply to
such definitions:
- For conceptual rows:
- If the row is an extension of a row in some other table, then an
AUGMENTS clause MUST be used if the relationship is one-to-one,
and an INDEX clause MUST be used if the relationship is sparse.
In the latter case, the INDEX clause SHOULD be identical to that
of the original table.
- If the row is an element of an expansion table -- that is, if
multiple row instances correspond to a single row instance in
some other table -- then an INDEX clause MUST be used, and the
first-mentioned elements SHOULD be the indices of that other
table, listed in the same order.
- If objects external to the row are present in the INDEX clause,
then the conceptual row’s DESCRIPTION clause MUST specify how
those objects are used in identifying instances of its columnar
objects, and in particular MUST specify for which values of those
index objects the conceptual row may exist.
- Use of the IMPLIED keyword is NOT RECOMMENDED for any index
object that may appear in the INDEX clause of an expansion table.
Since this keyword may be associated only with the last object in
an INDEX clause, it cannot be associated with the same index
object in a primary table and an expansion table. This will
cause the sort order to be different in the primary table and any
expansion tables. As a consequence, an implementation will be
unable to reuse indexing code from the primary table in expansion
tables, and data structures meant to be extended might actually
have to be replicated. Designers who are tempted to use IMPLIED
should consider that the resulting sort order rarely meets user
expectations, particularly for strings that include both
uppercase and lowercase letters, and it does not take the user
language or locale into account.
- If dynamic row creation and/or deletion by management applications
is supported, then:
- There SHOULD be one columnar object with a SYNTAX value of
RowStatus [RFC2579] and a MAX-ACCESS value of read-create. This
object is called the status column for the conceptual row. All
other columnar objects MUST have a MAX-ACCESS value of read-
create, read-only, accessible-for-notify, or not-accessible; a
MAX-ACCESS value of read-write is not allowed.