object identifier tree, without associating any class or attribute
information with this node. This may be useful to group definitions
in a subtree of related management information, or to uniquely define
an SMIng `identity’ to be referenced in attributes of type Pointer.
The `node’ statement gets two arguments: a lower-case node identifier
and a statement block that holds detailed node information in an
obligatory order.
See the `nodeStatement’ rule of the grammar (Section 5) for the
formal syntax of the `node’ statement.
4.2.1. The node’s oid Statement
The node’s `oid’ statement, which must be present, gets one argument
which specifies the object identifier value that is assigned to this
node.
4.2.2. The node’s represents Statement
The node’s `represents’ statement, which need not be present, makes
this node represent an SMIng identity, so that objects of type
Pointer can reference that identity. The statement gets one argument
which specifies the identity name.
4.2.3 The node’s status Statement
The node’s `status’ statement, which must be present, gets one
argument which is used to specify whether this node definition is
current or historic. The value `current’ means that the definition
is current and valid. The value `obsolete’ means the definition is
obsolete and should not be implemented and/or can be removed if
previously implemented. While the value `deprecated’ also indicates
an obsolete definition, it permits new/continued implementation in
order to foster interoperability with older/existing implementations.
4.2.4. The node’s description Statement
The node’s `description’ statement, which need not be present, gets
one argument which is used to specify a high-level textual
description of this node.
It is RECOMMENDED to include all semantics and purposes of this node.
4.2.5. The node’s reference Statement
The node’s `reference’ statement, which need not be present, gets one
argument which is used to specify a textual cross-reference to some
other document, either another module which defines related
definitions, or some other document which provides additional
information relevant to this node.
4.2.6. Usage Examples
node iso { oid 1; status current; };
node org { oid iso.3; status current; };
node dod { oid org.6; status current; };
node internet { oid dod.1; status current; };
node zeroDotZero {
oid 0.0;
represents NMRG-SMING::null;
status current;
description "A null value used for pointers.";
};
4.3. The scalars Statement
The `scalars’ statement is used to define the mapping of one or more
classes to a group of SNMP scalar managed objects organized under a
common parent node. The `scalars’ statement gets two arguments: a
lower-case scalar group identifier and a statement block that holds
detailed mapping information of this scalar group in an obligatory
order.
See the `scalarsStatement’ rule of the grammar (Section 5) for the
formal syntax of the `scalars’ statement.
4.3.1. The scalars’ oid Statement
The scalars’ `oid’ statement, which must be present, gets one
argument which specifies the object identifier value that is assigned
to the common parent node of this scalar group.
4.3.2. The scalars’ object Statement
The scalars’ `object’ statement, which must be present at least once,
makes this scalar group contain a given scalar object. It gets two
arguments: the name of the scalar object to be defined and a
statement block that holds additional detailed information in an
obligatory order.
4.3.2.1. The object’s implements Statement
The `implements’ statement, which must be present, is used to specify
a single leaf attribute of a class that is implemented by this scalar
object. The type of this attribute must be a simple type, i.e., not
a class.
4.3.2.2. The object’s subid Statement
The `subid’ statement, which need not be present, is used to specify
the sub-identifier that identifies the scalar object within this
scalar group, i.e., the object identifier of the scalar object is the
concatenation of the values of this scalar group’s oid statement and
of this subid statement.
If this statement is omitted, the sub-identifier is the one of the
previous object statement within this scalar group plus 1. If the
containing object statement is the first one within the containing
scalar group and the subid statement is omitted, the sub-identifier
is 1.
4.3.2.3. The object’s status Statement
The object’s `status’ statement, which need not be present, gets one
argument which is used to specify whether this scalar object
definition is current or historic. The value `current’ means that
the definition is current and valid. The value `obsolete’ means the
definition is obsolete and should not be implemented and/or can be
removed if previously implemented. While the value `deprecated’ also
indicates an obsolete definition, it permits new/continued
implementation in order to foster interoperability with
older/existing implementations.
Scalar objects SHOULD NOT be defined as `current’ if the implemented
attribute definition is `deprecated’ or `obsolete’. Similarly, they
SHOULD NOT be defined as `deprecated’ if the implemented attribute is
`obsolete’. Nevertheless, subsequent revisions of used class
definitions cannot be avoided, but SHOULD be taken into account in
subsequent revisions of the local module.
Note that it is RECOMMENDED to omit the status statement which means
that the status is inherited from the containing scalars statement.
However, if the status of a scalar object varies from the containing
scalar group, it has to be expressed explicitly, e.g., if the
implemented attribute has been deprecated or obsoleted.
4.3.2.4. The object’s description Statement
The object’s `description’ statement, which need not be present, gets
one argument which is used to specify a high-level textual
description of this scalar object.
Note that in contrast to other definitions this description statement
is not mandatory and it is RECOMMENDED to omit it, if the object is
fully described by the description of the implemented attribute.
4.3.2.5. The object’s reference Statement
The object’s `reference’ statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related
definitions, or some other document which provides additional
information relevant to this scalar object.
It is RECOMMENDED to omit this statement, if the object’s references
are fully described by the implemented attribute.
4.3.3. The scalars’ status Statement
The scalars’ `status’ statement, which must be present, gets one
argument which is used to specify whether this scalar group
definition is current or historic. The value `current’ means that
the definition is current and valid. The value `obsolete’ means the
definition is obsolete and should not be implemented and/or can be
removed if previously implemented. While the value `deprecated’ also
indicates an obsolete definition, it permits new/continued
implementation in order to foster interoperability with
older/existing implementations.
4.3.4. The scalars’ description Statement
The scalars’ `description’ statement, which must be present, gets one
argument which is used to specify a high-level textual description of
this scalar group.
It is RECOMMENDED to include all semantic definitions necessary for
the implementation of this scalar group.
4.3.5. The scalars’ reference Statement
The scalars’ `reference’ statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related
definitions, or some other document which provides additional
information relevant to this scalars statement.
4.3.6. Usage Example
scalars ip {
oid mib-2.4;
object ipForwarding { implements Ip.forwarding; };
object ipDefaultTTL { implements Ip.defaultTTL; };
// ...
status current;
description
"This scalar group implements the Ip class.";
};
4.4. The table Statement
The `table’ statement is used to define the mapping of one or more
classes to a single SNMP table of columnar managed objects. The
`table’ statement gets two arguments: a lower-case table identifier
and a statement block that holds detailed mapping information of this
table in an obligatory order.
See the `tableStatement’ rule of the grammar (Section 5) for the
formal syntax of the `table’ statement.
4.4.1. The table’s oid Statement
The table’s `oid’ statement, which must be present, gets one argument
which specifies the object identifier value that is assigned to this
table’s node.
4.4.2. Table Indexing Statements
SNMP table mappings offers five methods to supply table indexing
information: ordinary tables, table augmentations, sparse table
augmentations, table expansions, and reordered tables use different
statements to denote their indexing information. Each table
definition must contain exactly one of the following indexing
statements.
4.4.2.1. The table’s index Statement for Table Indexing
The table’s `index’ statement, which is used to supply table indexing
information of base tables, gets one argument that specifies a
comma-separated list of objects, that are used for table indexing,
enclosed in parenthesis.
The elements of the `unique’ statement of the implemented class(es)
and their order should be regarded as a hint for the index elements
of the table.
In case of modules that should be compatible on the SNMP protocol
level to SMIv2 versions of the module, an optional `implied’ keyword
may be added in front of the list to indicate a compact encoding of
the last object in the list. See Section 2.2 for details.
4.4.2.2. The table’s augments Statement for Table Indexing
The table’s `augments’ statement, which is used to supply table
indexing information of tables that augment a base table, gets one
argument that specifies the identifier of the table to be augmented.
Note that a table augmentation cannot itself be augmented. Anyhow, a
base table may be augmented by multiple table augmentations.
A table augmentation makes instances of subordinate columnar objects
identified according to the index specification of the base table
corresponding to the table named in the `augments’ statement.
Further, instances of subordinate columnar objects of a table
augmentation exist according to the same semantics as instances of
subordinate columnar objects of the base table being augmented. As
such, note that creation of a base table row implies the
correspondent creation of any table row augmentations. Table
augmentations MUST NOT be used in table row creation and deletion
operations.
4.4.2.3. The table’s extends Statement for Table Indexing
The table’s `extends’ statement, which is used to supply table
indexing information of tables that sparsely augment a base table,
gets one argument that specifies the identifier of the table to be
sparsely augmented. Note that a sparse table augmentation cannot
itself be augmented. Anyhow, a base table may be augmented by
multiple table augmentations, sparsely or not.
A sparse table augmentation makes instances of subordinate columnar
objects identified, if present, according to the index specification
of the base table corresponding to the table named in the `extends’
statement. Further, instances of subordinate columnar objects of a
sparse table augmentation exist according to the semantics as
instances of subordinate columnar objects of the base table and the
(non-formal) rules that confine the sparse relationship. As such,
note that creation of a sparse table row augmentation may be implied
by the creation of a base table row as well as done by an explicit
creation. However, if a base table row gets deleted, any dependent
sparse table row augmentations get also deleted implicitly.
4.4.2.4. The table’s reorders Statement for Table Indexing
The table’s `reorders’ statement is used to supply table indexing
information of tables, that contain exactly the same index objects of
a base table but in a different order. It gets at least two
arguments. The first one specifies the identifier of the base table.
The second one specifies a comma-separated list of exactly those
object identifiers of the base table’s `index’ statement, but in the
order to be used in this table. Note that a reordered table cannot
itself be reordered. Anyhow, a base table may be used for multiple
reordered tables.
Under some circumstances, an optional `implied’ keyword may be added
in front of the list to indicate a compact encoding of the last
object in the list. See Section 2.2 for details.
Instances of subordinate columnar objects of a reordered table exist
according to the same semantics as instances of subordinate columnar
objects of the base table. As such, note that creation of a base
table row implies the correspondent creation of any related reordered
table row. Reordered tables MUST NOT be used in table row creation
and deletion operations.
4.4.2.5. The table’s expands Statement for Table Indexing
The table’s `expands’ statement is used to supply table indexing
information of table expansions. Table expansions use exactly the
same index objects of another table together with additional indexing
objects. Thus, the `expands’ statement gets at least two arguments.
The first one specifies the identifier of the base table. The second
one specifies a comma-separated list of the additional object
identifiers used for indexing. Note that an expanded table may
itself be expanded, and base tables may be used for multiple table
expansions.
Under some circumstances, an optional `implied’ keyword may be added
in front of the list to indicate a compact encoding of the last
object in the list. See Section 2.2 for details.
4.4.3. The table’s create Statement
The table’s `create’ statement, which need not be present, gets no
argument. If the `create’ statement is present, table row creation
(and deletion) is possible.
4.4.4. The table’s object Statement
The table’s `object’ statement, which must be present at least once,
makes this table contain a given columnar object. It gets two
arguments: the name of the columnar object to be defined and a
statement block that holds additional detailed information in an
obligatory order.
4.4.4.1. The object’s implements Statement
The `implements’ statement, which must be present, is used to specify
a single leaf attribute of a class that is implemented by this
columnar object. The type of this attribute must be a simple type,
i.e., not a class.
4.4.4.2. The object’s subid Statement
The `subid’ statement, which need not be present, is used to specify
the sub-identifier that identifies the columnar object within this
table, i.e., the object identifier of the columnar object is the
concatenation of the values of this table’s oid statement and of this
subid statement.
If this statement is omitted, the sub-identifier is the one of the
previous object statement within this table plus 1. If the
containing object statement is the first one within the containing
table and the subid statement is omitted, the sub-identifier is 1.
4.4.4.3. The object’s status Statement
The object’s `status’ statement, which need not be present, gets one
argument which is used to specify whether this columnar object
definition is current or historic. The value `current’ means that
the definition is current and valid. The value `obsolete’ means the
definition is obsolete and should not be implemented and/or can be
removed if previously implemented. While the value `deprecated’ also
indicates an obsolete definition, it permits new/continued
implementation in order to foster interoperability with
older/existing implementations.
Columnar objects SHOULD NOT be defined as `current’ if the
implemented attribute definition is `deprecated’ or `obsolete’.
Similarly, they SHOULD NOT be defined as `deprecated’ if the
implemented attribute is `obsolete’. Nevertheless, subsequent
revisions of used class definitions cannot be avoided, but SHOULD be
taken into account in subsequent revisions of the local module.
Note that it is RECOMMENDED to omit the status statement which means
that the status is inherited from the containing table statement.
However, if the status of a columnar object varies from the
containing table, it has to be expressed explicitly, e.g., if the
implemented attribute has been deprecated or obsoleted.
4.4.4.4. The object’s description Statement
The object’s `description’ statement, which need not be present, gets
one argument which is used to specify a high-level textual
description of this columnar object.
Note that in contrast to other definitions this description statement
is not mandatory and it is RECOMMENDED to omit it, if the object is
fully described by the description of the implemented attribute.
4.4.4.5. The object’s reference Statement
The object’s `reference’ statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related
definitions, or some other document which provides additional
information relevant to this columnar object.
It is RECOMMENDED to omit this statement, if the object’s references
are fully described by the implemented attribute.
4.4.5. The table’s status Statement
The table’s `status’ statement, which must be present, gets one
argument which is used to specify whether this table definition is
current or historic. The value `current’ means that the definition
is current and valid. The value `obsolete’ means the definition is
obsolete and should not be implemented and/or can be removed if
previously implemented. While the value `deprecated’ also indicates
an obsolete definition, it permits new/continued implementation in
order to foster interoperability with older/existing implementations.
4.4.6. The table’s description Statement
The table’s `description’ statement, which must be present, gets one
argument which is used to specify a high-level textual description of
this table.
It is RECOMMENDED to include all semantic definitions necessary for
the implementation of this table.
4.4.7. The table’s reference Statement
The table’s `reference’ statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related
definitions, or some other document which provides additional
information relevant to this table statement.
4.4.8. Usage Example
table ifTable {
oid interfaces.2;
index (ifIndex);
object ifIndex { implements Interface.index; };
object ifDescr { implements Interface.description; };
// ...
status current;
description
"This table implements the Interface class.";
};
4.5. The notification Statement
The `notification’ statement is used to map events defined within
classes to SNMP notifications. The `notification’ statement gets two
arguments: a lower-case notification identifier and a statement block
that holds detailed notification information in an obligatory order.
See the `notificationStatement’ rule of the grammar (Section 5) for
the formal syntax of the `notification’ statement.
4.5.1. The notification’s oid Statement
The notification’s `oid’ statement, which must be present, gets one
argument which specifies the object identifier value that is assigned
to this notification.
4.5.2. The notification’s signals Statement
The notification’s `signals’ statement, which must be present,
denotes the event that is signaled by this notification. The
statement gets two arguments: the event to be signaled (in the
qualified form `Class.event’) and a statement block that holds
detailed information on the objects transmitted with this
notification in an obligatory order.
4.5.2.1. The signals’ object Statement
The signals’ `object’ statement, which can be present zero, one or
multiple times, makes a single instance of a class attribute be
contained in this notification. It gets one argument: the specific
class attribute. The namespace of attributes not specified by
qualified names is the namespace of the event’s class specified in
the `signals’ statement.
4.5.3. The notification’s status Statement
The notification’s `status’ statement, which must be present, gets
one argument which is used to specify whether this notification
definition is current or historic. The value `current’ means that
the definition is current and valid. The value `obsolete’ means the
definition is obsolete and should not be implemented and/or can be
removed if previously implemented. While the value `deprecated’ also
indicates an obsolete definition, it permits new/continued
implementation in order to foster interoperability with
older/existing implementations.
4.5.4. The notification’s description Statement
The notification’s `description’ statement, which need not be
present, gets one argument which is used to specify a high-level
textual description of this notification.
It is RECOMMENDED to include all semantics and purposes of this
notification.
4.5.5. The notification’s reference Statement
The notification’s `reference’ statement, which need not be present,
gets one argument which is used to specify a textual cross-reference
to some other document, either another module which defines related
definitions, or some other document which provides additional
information relevant to this notification statement.
4.5.6. Usage Example
notification linkDown {
oid snmpTraps.3;
signals Interface.linkDown {
object ifIndex;
object ifAdminStatus;
object ifOperStatus;
};
status current;
description
"This notification signals the linkDown event
of the Interface class.";
};
4.6. The group Statement
The `group’ statement is used to define a group of arbitrary nodes in
the object identifier tree. It gets two arguments: a lower-case
group identifier and a statement block that holds detailed group
information in an obligatory order.
Note that the primary application of groups are compliance
statements, although they might be referred in other formal or
informal documents.
See the `groupStatement’ rule of the grammar (Section 5) for the
formal syntax of the `group’ statement.
4.6.1. The group’s oid Statement
The group’s `oid’ statement, which must be present, gets one argument
which specifies the object identifier value that is assigned to this
group.
4.6.2. The group’s members Statement
The group’s `members’ statement, which must be present, gets one
argument which specifies the list of nodes by their identifiers to be
contained in this group. The list of nodes has to be comma-separated
and enclosed in parenthesis.
4.6.3. The group’s status Statement
The group’s `status’ statement, which must be present, gets one
argument which is used to specify whether this group definition is
current or historic. The value `current’ means that the definition
is current and valid. The value `obsolete’ means the definition is
obsolete and the group should no longer be used. While the value
`deprecated’ also indicates an obsolete definition, it permits
new/continued use of this group.
4.6.4. The group’s description Statement
The group’s `description’ statement, which must be present, gets one
argument which is used to specify a high-level textual description of
this group. It is RECOMMENDED to include any relation to other
groups.
4.6.5. The group’s reference Statement
The group’s `reference’ statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related