💾 Archived View for gmi.noulin.net › rfc › rfc2982.gmi captured on 2023-06-16 at 23:28:44. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Keywords: MIB, management information base, Distributed Management Expression
Network Working Group R. Kavasseri
Request for Comments: 2982 (Editor of this version)
Category: Standards Track B. Stewart
(Author of previous version)
Cisco Systems, Inc.
October 2000
Distributed Management Expression MIB
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used for managing
expressions of MIB objects. The results of these expressions become
MIB objects usable like any other MIB object, such as for the test
condition for declaring an event.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Table of Contents
1 The SNMP Management Framework ............................... 2
2 Overview .................................................... 3
2.1 Usage ..................................................... 4
2.2 Persistence ............................................... 4
2.3 Operation ................................................. 4
2.3.1 Sampling ................................................ 5
2.3.2 Wildcards ............................................... 5
2.3.3 Evaluation .............................................. 5
2.3.4 Value Identification .................................... 6
2.4 Subsets ................................................... 6
2.4.1 No Wildcards ............................................ 6
Kavasseri & Stewart Standards Track [Page 1]
RFC 2982 Distributed Management Expression MIB October 2000
2.4.2 No Deltas ............................................... 7
2.5 Structure ................................................. 7
2.5.1 Resource ................................................ 7
2.5.2 Definition .............................................. 7
2.5.3 Value ................................................... 8
2.6 Examples .................................................. 8
2.6.1 Wildcarding ............................................. 8
2.6.2 Calculation and Conditional ............................. 10
3 Definitions ................................................. 12
4 Intellectual Property ....................................... 36
5 Acknowledgements ............................................ 37
6 References .................................................. 37
7 Security Considerations ..................................... 38
8 Author's Address ............................................ 40
9 Editor's Address ............................................ 40
10 Full Copyright Statement ................................... 41
1. The SNMP Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 2571 [RFC2571].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in
STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
1215 [RFC1215]. The second version, called SMIv2, is described
in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
STD 58, RFC 2580 [RFC2580].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [RFC1157]. A second version of
the SNMP message protocol, which is not an Internet standards
track protocol, is called SNMPv2c and described in RFC 1901
[RFC1901] and RFC 1906 [RFC1906]. The third version of the
message protocol is called SNMPv3 and described in RFC 1906
[RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [RFC1157]. A second set of
protocol operations and associated PDU formats is described in
RFC 1905 [RFC1905].
Kavasseri & Stewart Standards Track [Page 2]
RFC 2982 Distributed Management Expression MIB October 2000
o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
2. Overview
Users of MIBs often desire MIB objects that MIB designers have not
provided. Furthermore, such needs vary from one management
philosophy to another. Rather than fill more and more MIBs with
standardized objects, the Expression MIB supports externally defined
expressions of existing MIB objects.
In the Expression MIB the results of an evaluated expression are MIB
objects that may be used like any other MIB objects. These custom-
defined objects are thus usable anywhere any other MIB object can be
used. For example, they can be used by a management application
directly or referenced from another MIB, such as the Event MIB
[MIBEventMIB]. They can even be used by the Expression MIB itself,
forming expressions of expressions.
The Expression MIB is instrumentation for a relatively powerful,
complex, high-level application, considerably different from simple
instrumentation for a communication driver or a protocol. The MIB is
appropriate in a relatively powerful, resource-rich managed system
and not necessarily in a severely limited environment.
Nevertheless, due to dependencies from the Event MIB [RFC2981] and
the need to support as low-end a system as possible, the Expression
MIB can be somewhat stripped down for lower-power, lower-resource
implementations, as described in the Subsets section, below.
Kavasseri & Stewart Standards Track [Page 3]
RFC 2982 Distributed Management Expression MIB October 2000
Implementation of the Expression MIB in a managed system led to the
addition of objects that may not have been necessary in an
application environment with complete knowledge of compiled MIB
definitions. This is appropriate since implementation must be
possible within typical managed systems with some constraints on
system resources.
2.1. Usage
On managed systems that can afford the overhead, the Expression MIB
is a way to create new, customized MIB objects for monitoring.
Although these can save some network traffic and overhead on
management systems, that is often not a good tradeoff for objects
that are simply to be recorded or displayed.
An example of a use of the Expression MIB would be to provide custom
objects for the Event MIB [RFC2981]. A complex expression can
evaluate to a rate of flow or a boolean and thus be subject to
testing as an event trigger, resulting in an SNMP notification.
Without these capabilities such monitoring would be limited to the
objects in predefined MIBs. The Expression MIB thus supports
powerful tools for the network manager faced with the monitoring of
large, complex systems that can support a significant level of self
management.
2.2. Persistence
Although like most MIBs this one has no explicit controls for the
persistence of the values set in configuring an expression, a robust,
polite implementation would certainly not force its managing
applications to reconfigure it whenever it resets.
Again, as with most MIBs, it is implementation specific how a system
provides and manages such persistence. To speculate, one could
imagine, for example, that persistence depended on the context in
which the expression was configured, or perhaps system-specific
characteristics of the expression's owner. Or perhaps everything in
a MIB such as this one, which is clearly aimed at persistent
configuration, is automatically part of a system's other persistent
configuration.
2.3. Operation
Most of the operation of the MIB is described or implied in the
object definitions but a few highlights bear mentioning here.
Kavasseri & Stewart Standards Track [Page 4]
RFC 2982 Distributed Management Expression MIB October 2000
2.3.1. Sampling
The MIB supports three types of object sampling for the MIB objects
that make up the expression: absolute, delta, and changed.
Absolute samples are simply the value of the MIB object at the time
it is sampled.
Absolute samples are not sufficient for expressions of counters, as
counters have meaning only as a delta (difference) from one sample to
the next. Thus objects may be sampled as deltas. Delta sampling
requires the application to maintain state for the value at the last
sample, and to do continuous sampling whether or not anyone is
looking at the results. It thus creates constant overhead.
Changed sampling is a simple fallout of delta sampling where rather
than a difference the result is a boolean indicating whether or not
the object changed value since the last sample.
2.3.2. Wildcards
Wildcards allow the application of a single expression to multiple
instances of the same MIB object. The definer of the expression
indicates this choice and provides a partial object identifier, with
some or all of the instance portion left off. The application then
does the equivalent of GetNext to obtain the object values, thus
discovering the instances.
All wildcarded objects in an expression must have the same semantics
for the missing portion of their object identifiers. Otherwise, any
successful evaluation of the wildcarded expression would be the
result of the accidental matching of the wildcarded portion of the
object identifiers in the expression. Such an evaluation will likely
produce results which are not meaningful.
The expression can be evaluated only for those instances where all
the objects in the expression are available with the same value for
the wildcarded portion of the instance.
2.3.3. Evaluation
There are two important aspects of evaluation that may not be
obvious: what objects and when.
What objects get used in the evaluation depends on the type of
request and whether or not the expression contains wildcarded
objects. If the request was a Get, that locks down the instances to
Kavasseri & Stewart Standards Track [Page 5]
RFC 2982 Distributed Management Expression MIB October 2000
be used. If the request was a GetNext or GetBulk, the application
must work its way up to the next full set of objects for the
expression.
Evaluation of expressions happens at two possible times, depending on
the sampling method (delta or absolute) used to evaluate the
expression.
If there are no delta or change values in an expression, the
evaluation occurs on demand, i.e. when a requester attempts to read
the value of the expression. In this case all requesters get a
freshly calculated value.
For expressions with delta or change values, evaluation goes on
continuously, every sample period. In this case requesters get the
value as of the last sample period. For any given sample period of a
given expression, only those instances exist that provided a full set
of object values. It may be possible that a delta expression which
was evaluated successfully for one sample period may not be
successfully evaluated in the next sample period. This may, for
example, be due to missing instances for some or all of the objects
in the expression. In such cases, the value from the previous sample
period (with the successful evaluation) must not be carried forward
to the next sample period (with the failed evaluation).
2.3.4. Value Identification
Values resulting from expression evaluation are identified with a
combination of the object identifier (OID) for the data type from
expValueTable (such as expValueCounter32Val), the expression owner,
the expression name, and an OID fragment.
The OID fragment is not an entire OID beginning with iso.dod.org
(1.3.6). Rather it begins with 0.0. The remainder is either another
0 when there is no wildcarding or the instance that satisfied the
wildcard if there is wildcarding.
2.4. Subsets
To pare down the Expression MIBs complexity and use of resources an
implementor can leave out various parts.
2.4.1. No Wildcards
Leaving out wildcarding significantly reduces the complexity of
retrieving values to evaluate expressions and the processing required
to do so. Such an implementation would allow expressions made up of
Kavasseri & Stewart Standards Track [Page 6]
RFC 2982 Distributed Management Expression MIB October 2000
individual MIB objects but would not be suitable for expressions
applied across large tables as each instance in the table would
require a separate expression definition.
Furthermore it would not be suitable for tables with arbitrary,
dynamic instances, as expressions definitions could not predict what
instance values to use.
An implementation without wildcards might be useful for a self-
managing system with small tables or few dynamic instances, or one
that can do calculations only for a few key objects.
2.4.2. No Deltas
Leaving out delta processing significantly reduces state that must be
kept and the burden of ongoing processing even when no one is looking
at the results. Unfortunately it also makes expressions on counters
unusable, as counters have meaning only as deltas.
An implementation without deltas might be useful for a severely
limited, self-managing system that has no need for expressions or
events on counters. Although conceivable, such systems would be
rare.
2.5. Structure
The MIB has the following sections:
o Resource -- management of the MIB's use of system resources.
o Definition -- definition of expressions.
o Value -- values of evaluated expressions.
2.5.1. Resource
The resource section has objects to manage resource usage by
wildcarded delta expressions, a potential major consumer of CPU and
memory.
2.5.2. Definition
The definition section contains the tables that define expressions.
The expression table, indexed by expression owner and expression
name, contains those parameters that apply to the entire expression,
such as the expression itself, the data type of the result, and the
sampling interval if it contains delta or change values.
Kavasseri & Stewart Standards Track [Page 7]
RFC 2982 Distributed Management Expression MIB October 2000
The object table, indexed by expression owner, expression name and
object index within each expression, contains the parameters that
apply to the individual objects that go into the expression,
including the object identifier, sample type, discontinuity
indicator, and such.
2.5.3. Value
The value section contains the values of evaluated expressions.
The value table, indexed by expression owner, expression name and
instance fragment contains a "discriminated union" of evaluated
expression results. For a given expression only one of the columns
is instantiated, depending on the result data type for the
expression. The instance fragment is a constant or the final section
of the object identifier that filled in a wildcard.
2.6. Examples
The examples refer to tables and objects defined below in the MIB
itself. They may well make more sense after reading those
definitions.
2.6.1. Wildcarding
An expression may use wildcarded MIB objects that result in multiple
values for the expression. To specify a wildcarded MIB object a
management application leaves off part or all of the instance portion
of the object identifier, and sets expObjectWildcard to true(1) for
that object. For our example we'll use a counter of total blessings
from a table of people. Another table, indexed by town and person
has blessings just from that town.
So the index clauses are:
personEntry OBJECT-TYPE
...
INDEX { personIndex }
And:
townPersonEntry OBJECT-TYPE
...
INDEX { townIndex, personIndex }
Kavasseri & Stewart Standards Track [Page 8]
RFC 2982 Distributed Management Expression MIB October 2000
In our friendly application we may have entered our expression as:
100 * townPersonBlessings.976.* / personBlessings.*
What goes in expExpression is:
100*$1/$2
For example purposes we'll use some slightly far-fetched OIDs. The
People MIB is 1.3.6.1.99.7 and the Town MIB is 1.3.6.1.99.11, so for
our two counters the OIDs are:
personBlessings 1.3.6.1.99.7.1.3.1.4
townPersonBlessings 1.3.6.1.99.11.1.2.1.9
The rule for wildcards is that all the wildcarded parts have to match
exactly. In this case that means we have to hardwire the town and
only the personIndex can be wildcarded. So our values for
expObjectID are:
1.3.6.1.99.7.1.3.1.4
1.3.6.1.99.11.1.2.1.9.976
We're hardwired to townIndex 976 and personIndex is allowed to vary.
The value of expExpressionPrefix can be either of those two counter
OIDs (including the instance fragment in the second case), since
either of them takes you to a MIB definition where you can look at
the INDEX clause and figure out what's been left off. What's been
left off doesn't have to work out to be the same object, but it does
have to work out to be the same values (semantics) for the result to
make sense. Note that the managed system can not typically check
such semantics and if given nonsense will return nonsense.
If we have people numbered 6, 19, and 42 in town number 976, the
successive values of expValueInstance will be:
0.0.6
0.0.19
0.0.42
So there will be three values in expValueTable, with those OIDs as
the expValueInstance part of their indexing.
Kavasseri & Stewart Standards Track [Page 9]
RFC 2982 Distributed Management Expression MIB October 2000
2.6.2. Calculation and Conditional
The following formula for line utilization of a half-duplex link is
adapted from [PracPersp].
utilization = (ifInOctets + ifOutOctets) * 800 / seconds / ifSpeed
The expression results in the percentage line utilization per second.
The total octets are multiplied by 8 to get bits and 100 to scale up
the percentage as an integer.
The following Expression MIB object values implement this as an
expression for all ifIndexes that directly represent actual hardware.
Since the octet counters are Counter32 values, they must be delta
sampled to be meaningful. The sample period is 6 seconds but for
accuracy and independence is calculated as a delta of sysUpTime.
The expObjectTable entry for ifInOctets has an expObjectConditional
that checks for being a hardware interface. Only one object in the
expression needs that check associated, since it applies to the whole
expression. Since ifConnectorPresent is a TruthValue with values of
1 or 2 rather than 0 and non-zero, it must also be in an expression
rather than used directly for the conditional.
The interface-specific discontinuity indicator is supplied only for
ifInOctets since invalidating that sample will invalidate an attempt
at evaluation, effectively invalidating ifOutOctets as well
(correctly, because it has the same indicator).
For notational clarity, in the rest of this document, a string in
quotes as part of the object instance indicates the value that would
actually be one subidentifier per byte. The objects all belong to
owner "me".
Also for clarity OIDs are expressed as the object descriptor and
instance. In fact they must be supplied numerically, with all
subidentifiers in place before the part for the particular object and
instance.
What the user would set in expExpressionTable:
expExpression.2."me".4."hard" = "$1==1"
expExpressionValueType.2."me".4."hard" = unsigned32
expExpressionRowStatus.2."me"4."hard" = 'active'
Kavasseri & Stewart Standards Track [Page 10]
RFC 2982 Distributed Management Expression MIB October 2000
expExpression.2."me".4."util" = "($1+$2)*800/$4/$3"
expExpressionValueType.2."me".4."util" = integer32
expExpressionDeltaInterval.2."me".4."util" = 6
expExpressionRowStatus.2."me"4."util" = 'active'
What the user would set in expObjectTable:
expObjectID.2."me".4."hard".1 = ifConnectorPresent
expObjectWildcard.2."me".4."hard".1 = 'true'
expObjectSampleType.2."me".4."hard".1 = 'absoluteValue'
expObjectRowStatus.2."me".4."hard".1 = 'active'
expObjectID.2."me".4."util".1 = ifInOctets
expObjectWildcard.2."me".4."util".1 = 'true'
expObjectSampleType.2."me".4."util".1 = 'deltaValue'
expObjectConditional.2."me".4."util".1 =
expValueUnsigned32Val.4."hard".0.0
expObjectConditionalWildcard.2."me".4."util".1 = 'true'
expObjectDiscontinuityID.2."me".4."util".1 =
ifCounterDiscontinuityTime
expObjectDiscontinuityIDWildcard.2."me".4."util".1 = 'true'
expObjectRowStatus.2."me".4."util".1 = 'active'
expObjectID.2."me".4."util".2 = ifOutOctets
expObjectWildcard.2."me".4."util".2 = 'true'
expObjectSampleType.2."me".4."util".2 = 'deltaValue'
expObjectRowStatus.2."me".4."util".2 = 'active'
expObjectID.2."me".4."util".3 = ifSpeed
expObjectWildcard.2."me".4."util".3 = 'true'
expObjectSampleType.2."me".4."util".3 = 'absoluteValue'
expObjectRowStatus.2."me".4."util".3 = 'active'
expObjectID.2."me".4."util".4 = sysUpTime.0
expObjectWildcard.2."me".4."util".4 = 'false'
expObjectSampleType.2."me".4."util".4 = 'deltaValue'
expObjectRowStatus.2."me".4."util".4 = 'active'
These settings will result in populating one column of expValueTable:
expValueInteger32Val.2."me".4."util".0.0.?
The subidentifier represented by "?" above represents one
subidentifier that takes on a value of ifIndex and identifies a row
for each ifIndex value where ifConnectorPresent is 'true' and the
interface was present for two samples to provide a delta.
Kavasseri & Stewart Standards Track [Page 11]
RFC 2982 Distributed Management Expression MIB October 2000
This value could in turn be used as an event threshold [RFC2981] to
watch for overutilization of all hardware network connections.
3. Definitions
DISMAN-EXPRESSION-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
Integer32, Gauge32, Unsigned32,
Counter32, Counter64, IpAddress,
TimeTicks, mib-2, zeroDotZero FROM SNMPv2-SMI
RowStatus, TruthValue, TimeStamp FROM SNMPv2-TC
sysUpTime FROM SNMPv2-MIB
SnmpAdminString FROM SNMP-FRAMEWORK-MIB
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
dismanExpressionMIB MODULE-IDENTITY
LAST-UPDATED "200010160000Z" -- 16 October 2000
ORGANIZATION "IETF Distributed Management Working Group"
CONTACT-INFO "Ramanathan Kavasseri
Cisco Systems, Inc.
170 West Tasman Drive,
San Jose CA 95134-1706.
Phone: +1 408 527 2446
Email: ramk@cisco.com"
DESCRIPTION
"The MIB module for defining expressions of MIB objects for
management purposes."
-- Revision History
REVISION "200010160000Z" -- 16 October 2000
DESCRIPTION "This is the initial version of this MIB.
Published as RFC 2982"
::= { mib-2 90 }
dismanExpressionMIBObjects OBJECT IDENTIFIER ::=
{ dismanExpressionMIB 1 }
expResource OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 1 }
expDefine OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 2 }
expValue OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 3 }
--
-- Resource Control
--
Kavasseri & Stewart Standards Track [Page 12]
RFC 2982 Distributed Management Expression MIB October 2000
expResourceDeltaMinimum OBJECT-TYPE
SYNTAX Integer32 (-1 | 1..600)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The minimum expExpressionDeltaInterval this system will
accept. A system may use the larger values of this minimum to
lessen the impact of constantly computing deltas. For larger
delta sampling intervals the system samples less often and
suffers less overhead. This object provides a way to enforce
such lower overhead for all expressions created after it is
set.
The value -1 indicates that expResourceDeltaMinimum is
irrelevant as the system will not accept 'deltaValue' as a
value for expObjectSampleType.
Unless explicitly resource limited, a system's value for
this object should be 1, allowing as small as a 1 second
interval for ongoing delta sampling.
Changing this value will not invalidate an existing setting
of expObjectSampleType."
::= { expResource 1 }
expResourceDeltaWildcardInstanceMaximum OBJECT-TYPE
SYNTAX Unsigned32
UNITS "instances"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"For every instance of a deltaValue object, one dynamic instance
entry is needed for holding the instance value from the previous
sample, i.e. to maintain state.
This object limits maximum number of dynamic instance entries
this system will support for wildcarded delta objects in
expressions. For a given delta expression, the number of
dynamic instances is the number of values that meet all criteria
to exist times the number of delta values in the expression.
A value of 0 indicates no preset limit, that is, the limit
is dynamic based on system operation and resources.
Unless explicitly resource limited, a system's value for
this object should be 0.
Kavasseri & Stewart Standards Track [Page 13]
RFC 2982 Distributed Management Expression MIB October 2000
Changing this value will not eliminate or inhibit existing delta
wildcard instance objects but will prevent the creation of more
such objects.
An attempt to allocate beyond the limit results in expErrorCode
being tooManyWildcardValues for that evaluation attempt."
::= { expResource 2 }
expResourceDeltaWildcardInstances OBJECT-TYPE
SYNTAX Gauge32
UNITS "instances"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of currently active instance entries as
defined for expResourceDeltaWildcardInstanceMaximum."
::= { expResource 3 }
expResourceDeltaWildcardInstancesHigh OBJECT-TYPE
SYNTAX Gauge32
UNITS "instances"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The highest value of expResourceDeltaWildcardInstances
that has occurred since initialization of the managed
system."
::= { expResource 4 }
expResourceDeltaWildcardInstanceResourceLacks OBJECT-TYPE
SYNTAX Counter32
UNITS "instances"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times this system could not evaluate an
expression because that would have created a value instance in
excess of expResourceDeltaWildcardInstanceMaximum."
::= { expResource 5 }
--
-- Definition
--
-- Expression Definition Table
--
expExpressionTable OBJECT-TYPE
Kavasseri & Stewart Standards Track [Page 14]
RFC 2982 Distributed Management Expression MIB October 2000
SYNTAX SEQUENCE OF ExpExpressionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of expression definitions."
::= { expDefine 1 }
expExpressionEntry OBJECT-TYPE
SYNTAX ExpExpressionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a single expression. New expressions
can be created using expExpressionRowStatus.
To create an expression first create the named entry in this
table. Then use expExpressionName to populate expObjectTable.
For expression evaluation to succeed all related entries in
expExpressionTable and expObjectTable must be 'active'. If
these conditions are not met the corresponding values in
expValue simply are not instantiated.
Deleting an entry deletes all related entries in expObjectTable
and expErrorTable.
Because of the relationships among the multiple tables for an
expression (expExpressionTable, expObjectTable, and
expValueTable) and the SNMP rules for independence in setting
object values, it is necessary to do final error checking when
an expression is evaluated, that is, when one of its instances
in expValueTable is read or a delta interval expires. Earlier
checking need not be done and an implementation may not impose
any ordering on the creation of objects related to an
expression.
To maintain security of MIB information, when creating a new row in
this table, the managed system must record the security credentials
of the requester. These security credentials are the parameters
necessary as inputs to isAccessAllowed from the Architecture for
Describing SNMP Management Frameworks. When obtaining the objects
that make up the expression, the system must (conceptually) use
isAccessAllowed to ensure that it does not violate security.
The evaluation of the expression takes place under the
security credentials of the creator of its expExpressionEntry.
Values of read-write objects in this table may be changed
Kavasseri & Stewart Standards Track [Page 15]
RFC 2982 Distributed Management Expression MIB October 2000
at any time."
INDEX { expExpressionOwner, expExpressionName }
::= { expExpressionTable 1 }
ExpExpressionEntry ::= SEQUENCE {
expExpressionOwner SnmpAdminString,
expExpressionName SnmpAdminString,
expExpression OCTET STRING,
expExpressionValueType INTEGER,
expExpressionComment SnmpAdminString,
expExpressionDeltaInterval Integer32,
expExpressionPrefix OBJECT IDENTIFIER,
expExpressionErrors Counter32,
expExpressionEntryStatus RowStatus
}
expExpressionOwner OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The owner of this entry. The exact semantics of this
string are subject to the security policy defined by the
security administrator."
::= { expExpressionEntry 1 }
expExpressionName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The name of the expression. This is locally unique, within
the scope of an expExpressionOwner."
::= { expExpressionEntry 2 }
expExpression OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (1..1024))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The expression to be evaluated. This object is the same
as a DisplayString (RFC 1903) except for its maximum length.
Except for the variable names the expression is in ANSI C
syntax. Only the subset of ANSI C operators and functions
listed here is allowed.
Variables are expressed as a dollar sign ('