📄 rfc1444.txt
字号:
Case, McCloghrie, Rose & Waldbusser [Page 16]
RFC 1444 Conformance Statements for SNMPv2 April 1993
4.6. Usage Example
Consider how a compliance statement might be included at the
end of the MIB-II document [3], assuming that conformance
groups were defined therein:
mibIICompliances
OBJECT IDENTIFIER ::= { mibIIConformance 1 }
mibIIGroups OBJECT IDENTIFIER ::= { mibIIConformance 2 }
mibIICompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities
residing on systems which implement the Internet
suite of protocols."
MODULE -- compliance to the containing MIB module
MANDATORY-GROUPS { systemGroup, snmpGroup }
GROUP interfacesGroup
DESCRIPTION
"The interfaces group is mandatory for systems
with network interfaces."
GROUP ipGroup
DESCRIPTION
"The ip group is mandatory for systems which
implement IP."
GROUP icmpGroup
DESCRIPTION
"The icmp group is mandatory for systems which
implement ICMP."
GROUP tcpGroup
DESCRIPTION
"The tcp group is mandatory for systems which
implement TCP."
OBJECT tcpConnState
MIN-ACCESS read-only
DESCRIPTION
"A compliant system need not allow
write-access to this object."
GROUP udpGroup
Case, McCloghrie, Rose & Waldbusser [Page 17]
RFC 1444 Conformance Statements for SNMPv2 April 1993
DESCRIPTION
"The udp group is mandatory for systems which
implement UDP."
GROUP egpGroup
DESCRIPTION
"The egp group is mandatory for systems which
implement EGP."
::= { mibIICompliances 1 }
According to this invocation, to claim alignment with the
compliance statement named
{ mibIICompliances 1 }
a system must implement RFC1213's systemGroup and snmpGroup
conformance groups. If the system implements any network
interfaces, then RFC1213's interfacesGroup conformance group
must be implemented. Further, if the system implements any of
the IP, ICMP, TCP, UDP, or EGP protocols, then the
correspondent conformance group in RFC1213 must be
implemented, if compliance is to be claimed. Finally,
although RFC1213 specifies that it makes "protocol sense" for
the tcpConnState object to be writable, this specification
allows the system to permit only read-only access and still
claim compliance.
Case, McCloghrie, Rose & Waldbusser [Page 18]
RFC 1444 Conformance Statements for SNMPv2 April 1993
5. Mapping of the AGENT-CAPABILITIES macro
The AGENT-CAPABILITIES macro is used to convey the
capabilities present in a SNMPv2 entity acting in an agent
role. It should be noted that the expansion of the AGENT-
CAPABILITIES macro is something which conceptually happens
during implementation and not during run-time.
When a MIB module is written, it is divided into units of
conformance termed groups. If a SNMPv2 entity acting in an
agent role claims to implement a group, then it must implement
each and every object within that group. Of course, for
whatever reason, a SNMPv2 entity might implement only a subset
of the groups within a MIB module. In addition, the
definition of some MIB objects leave some aspects of the
definition to the discretion of an implementor.
Practical experience has demonstrated a need for concisely
describing the capabilities of an agent with respect to one or
more MIB modules. The AGENT-CAPABILITIES macro allows an
agent implementor to describe the precise level of support
which an agent claims in regards to a MIB group, and to bind
that description to the value of sysObjectID [3] associated
with the agent, or to the value of an instance of the snmpORID
object in the snmpORTable [4]. In particular, some objects
may have restricted or augmented syntax or access-levels.
If the AGENT-CAPABILITIES invocation is given to a
management-station implementor, then that implementor can
build management applications which optimize themselves when
communicating with a particular agent. For example, the
management-station can maintain a database of these
invocations. When a management-station interacts with an
agent, it retrieves the agent's sysObjectID [3]. Based on
this, it consults the database. If an entry is found, then
the management application can optimize its behavior
accordingly.
Note that this binding to sysObjectID may not always suffice
to define all MIB objects to which an agent can provide
access. In particular, this situation occurs where the agent
dynamically learns of the objects it supports. In these
cases, the snmpORID column of snmpORTable [4] contains
information which should be used in addition to sysObjectID.
Case, McCloghrie, Rose & Waldbusser [Page 19]
RFC 1444 Conformance Statements for SNMPv2 April 1993
Note that the AGENT-CAPABILITIES macro specifies refinements
or variations with respect to OBJECT-TYPE macros in MIB
modules, NOT with respect to MODULE-COMPLIANCE macros in
compliance statements.
5.1. Mapping of the PRODUCT-RELEASE clause
The PRODUCT-RELEASE clause, which must be present, contains a
textual description of the product release which includes this
agent.
5.2. Mapping of the STATUS clause
The STATUS clause, which must be present, indicates whether
this definition is current or historic.
The values "current", and "obsolete" are self-explanatory.
The "deprecated" value indicates that that object is obsolete,
but that an implementor may wish to support that object to
foster interoperability with older implementations.
5.3. Mapping of the DESCRIPTION clause
The DESCRIPTION clause, which must be present, contains a
textual description of this agent.
5.4. Mapping of the REFERENCE clause
The REFERENCE clause, which need not be present, contains a
textual cross-reference to a capability statement defined in
some other information module.
5.5. Mapping of the SUPPORTS clause
The SUPPORTS clause, which need not be present, is repeatedly
used to name each MIB module for which the agent claims a
complete or partial implementation. Each MIB module is named
by its module name, and optionally, by its associated OBJECT
IDENTIFIER as well.
Case, McCloghrie, Rose & Waldbusser [Page 20]
RFC 1444 Conformance Statements for SNMPv2 April 1993
5.5.1. Mapping of the INCLUDES clause
The INCLUDES clause, which must be present for each use of the
SUPPORTS clause, is used to name each MIB group associated
with the SUPPORT clause, which the agent claims to implement.
5.5.2. Mapping of the VARIATION clause
The VARIATION clause, which need not be present, is repeatedly
used to name each MIB object which the agent implements in
some variant or refined fashion with respect to the
correspondent invocation of the OBJECT-TYPE macro.
Note that the variation concept is meant for generic
implementation restrictions, e.g., if the variation for an
object depends on the values of other objects, then this
should be noted in the appropriate DESCRIPTION clause.
5.5.2.1. Mapping of the SYNTAX clause
The SYNTAX clause, which need not be present, is used to
provide a refined SYNTAX for the object named in the
correspondent VARIATION clause. Note that if this clause and
a WRITE-SYNTAX clause are both present, then this clause only
applies when instances of the object named in the
correspondent VARIATION clause are read.
Consult Section 10 of [2] for more information on refined
syntax.
5.5.2.2. Mapping of the WRITE-SYNTAX clause
The WRITE-SYNTAX clause, which need not be present, is used to
provide a refined SYNTAX for the object named in the
correspondent VARIATION clause when instances of that object
are written.
Consult Section 10 of [2] for more information on refined
syntax.
Case, McCloghrie, Rose & Waldbusser [Page 21]
RFC 1444 Conformance Statements for SNMPv2 April 1993
5.5.2.3. Mapping of the ACCESS clause
The ACCESS clause, which need not be present, is used to
indicate the agent provides less than the maximal level of
access to the object named in the correspondent VARIATION
clause.
The value "not-implemented" indicates the agent does not
implement the object, and in the ordering of possible values
is equivalent to "not-accessible".
The value "write-only" is provided solely for backward
compatibility, and shall not be used for newly-defined object
types. In the ordering of possible values, "write-only" is
less than "not-accessible".
5.5.2.4. Mapping of the CREATION-REQUIRES clause
The CREATION-REQUIRES clause, which need not be present, is
used to name the columnar objects of a conceptual row to which
values must be explicitly assigned, by a management protocol
set operation, before the agent will allow the instance of the
status column of that row to be set to `active'. (Consult the
definition of RowStatus [6].)
If the conceptual row does not have a status column (i.e., the
objects corresponding to the conceptual table were defined
using the mechanisms in [7,8]), then the CREATION-REQUIRES
clause, which need not be present, is used to name the
columnar objects of a conceptual row to which values must be
explicitly assigned, by a management protocol set operation,
before the agent will create new instances of objects in that
row.
This clause must not present unless the object named in the
correspondent VARIATION clause is a conceptual row, i.e., has
a syntax which resolves to a SEQUENCE containing columnar
objects. The objects named in the value of this clause
usually will refer to columnar objects in that row. However,
objects unrelated to the conceptual row may also be specified.
All objects which are named in the CREATION-REQUIRES clause
for a conceptual row, and which are columnar objects of that
row, must have an access level of "read-create".
Case, McCloghrie, Rose & Waldbusser [Page 22]
RFC 1444 Conformance Statements for SNMPv2 April 1993
5.5.2.5. Mapping of the DEFVAL clause
The DEFVAL clause, which need not be present, is used to
provide a refined DEFVAL value for the object named in the
correspondent VARIATION clause. The semantics of this value
are identical to those of the OBJECT-TYPE macro's DEFVAL
clause.
5.5.2.6. Mapping of the DESCRIPTION clause
The DESCRIPTION clause, which must be present for each use of
the VARIATION clause, contains a textual description of the
variant or refined implementation.
5.6. Mapping of the AGENT-CAPABILITIES value
The value of an invocation of the AGENT-CAPABILITIES macro is
an OBJECT IDENTIFIER, which names the value of sysObjectID [3]
or snmpORID [4] for which this capabilities statement is
valid.
Case, McCloghrie, Rose & Waldbusser [Page 23]
RFC 1444 Conformance Statements for SNMPv2 April 1993
5.7. Usage Example
Consider how a capabilities statement for an agent might be
described:
exampleAgent AGENT-CAPABILITIES
PRODUCT-RELEASE "ACME Agent release 1.1 for 4BSD"
STATUS current
DESCRIPTION "ACME agent for 4BSD"
SUPPORTS RFC1213-MIB
INCLUDES { systemGroup, interfacesGroup,
atGroup, ipGroup, icmpGroup,
tcpGroup, udpGroup, snmpGroup }
VARIATION ifAdminStatus
SYNTAX INTEGER { up(1), down(2) }
DESCRIPTION "Unable to set test mode on 4BSD"
VARIATION ifOperStatus
SYNTAX INTEGER { up(1), down(2) }
DESCRIPTION "Information limited on 4BSD"
VARIATION atEntry
CREATION-REQUIRES { atPhysAddress }
DESCRIPTION "Address mappings on 4BSD require
both protocol and media addresses"
VARIATION ipDefaultTTL
SYNTAX INTEGER (255..255)
DESCRIPTION "Hard-wired on 4BSD"
VARIATION ipInAddrErrors
ACCESS not-implemented
DESCRIPTION "Information not available on 4BSD"
VARIATION ipRouteType
SYNTAX INTEGER { direct(3), indirect(4) }
WRITE-SYNTAX INTEGER { invalid(2), direct(3),
indirect(4) }
DESCRIPTION "Information limited on 4BSD"
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -