As per Relevance of the word conformance, we have this rfc below:
Network Working Group J.
Request for Comments: 1444 SNMP Research, Inc
K.
Hughes LAN
M.
Dover Beach Consulting, Inc
S.
Carnegie Mellon
April 1993
Conformance
for version 2 of
Simple Network Management Protocol (SNMPv2)
Status of this
This RFC specifes an IAB standards track protocol for
Internet community, and requests discussion and
for improvements. Please refer to the current edition of
"IAB Official Protocol Standards" for the
state and status of this protocol. Distribution of this
is unlimited
Table of
1 Introduction .......................................... 2
1.1 A Note on Terminology ............................... 2
2 Definitions ........................................... 3
3.1 The OBJECT-GROUP macro .............................. 3
3.2 The MODULE-COMPLIANCE macro ......................... 4
3.3 The AGENT-CAPABILITIES macro ........................ 7
3 Mapping of the OBJECT-GROUP macro ..................... 10
3.1 Mapping of the OBJECTS clause ....................... 10
3.2 Mapping of the STATUS clause ........................ 10
3.3 Mapping of the DESCRIPTION clause ................... 10
3.4 Mapping of the REFERENCE clause ..................... 11
3.5 Mapping of the OBJECT-GROUP value ................... 11
3.6 Usage Example ....................................... 12
4 Mapping of the MODULE-COMPLIANCE macro ................ 13
4.1 Mapping of the STATUS clause ........................ 13
4.2 Mapping of the DESCRIPTION clause ................... 13
4.3 Mapping of the REFERENCE clause ..................... 13
4.4 Mapping of the MODULE clause ........................ 13
4.4.1 Mapping of the MANDATORY-GROUPS clause ............ 14
4.4.2 Mapping of the GROUP clause ....................... 14
4.4.3 Mapping of the OBJECT clause ...................... 14
Case, McCloghrie, Rose & Waldbusser [Page i
RFC 1444 Conformance Statements for SNMPv2 April 1993
4.4.3.1 Mapping of the SYNTAX clause .................... 15
4.4.3.2 Mapping of the WRITE-SYNTAX clause .............. 15
4.4.3.3 Mapping of the MIN-ACCESS clause ................ 15
4.4.3.4 Mapping of the DESCRIPTION clause ............... 16
4.5 Mapping of the MODULE-COMPLIANCE value .............. 16
4.6 Usage Example ....................................... 17
5 Mapping of the AGENT-CAPABILITIES macro ............... 19
5.1 Mapping of the PRODUCT-RELEASE clause ............... 20
5.2 Mapping of the STATUS clause ........................ 20
5.3 Mapping of the DESCRIPTION clause ................... 20
5.4 Mapping of the REFERENCE clause ..................... 20
5.5 Mapping of the SUPPORTS clause ...................... 20
5.5.1 Mapping of the INCLUDES clause .................... 21
5.5.2 Mapping of the VARIATION clause ................... 21
5.5.2.1 Mapping of the SYNTAX clause .................... 21
5.5.2.2 Mapping of the WRITE-SYNTAX clause .............. 21
5.5.2.3 Mapping of the ACCESS clause .................... 22
5.5.2.4 Mapping of the CREATION-REQUIRES clause ......... 22
5.5.2.5 Mapping of the DEFVAL clause .................... 23
5.5.2.6 Mapping of the DESCRIPTION clause ............... 23
5.6 Mapping of the AGENT-CAPABILITIES value ............. 23
5.7 Usage Example ....................................... 24
6 Extending an Information Module ....................... 26
6.1 Conformance Groups .................................. 26
6.2 Compliance Definitions .............................. 26
6.3 Capabilities Definitions ............................ 26
7 Acknowledgements ...................................... 27
8 References ............................................ 31
9 Security Considerations ............................... 32
10 Authors' Addresses ................................... 32
Case, McCloghrie, Rose & Waldbusser [Page 1]
RFC 1444 Conformance Statements for SNMPv2 April 1993
1.
A network management system contains: several (
many) nodes, each with a processing entity, termed an agent
which has access to management instrumentation; at least
management station; and, a management protocol, used to
management information between the agents and
stations. Operations of the protocol are carried out under
administrative framework which defines both authentication
authorization policies
Network management stations execute management
which monitor and control network elements. Network
are devices such as hosts, routers, terminal servers, etc.,
which are monitored and controlled through access to
management information
Management information is viewed as a collection of
objects, residing in a virtual information store, termed
Management Information Base (MIB). Collections of
objects are defined in MIB modules. These modules are
using a subset of OSI's Abstract Syntax Notation One (ASN.1)
[1], termed the Structure of Management Information (SMI) [2].
It may be useful to define the acceptable lower-bounds
implementation, along with the actual level of
achieved. It is the purpose of this document to define
notation used for these purposes
1.1. A Note on
For the purpose of exposition, the original Internet-
Network Management Framework, as described in RFCs 1155, 1157,
and 1212, is termed the SNMP version 1 framework (SNMPv1).
The current framework is termed the SNMP version 2
(SNMPv2).
Case, McCloghrie, Rose & Waldbusser [Page 2]
RFC 1444 Conformance Statements for SNMPv2 April 1993
2.
SNMPv2-CONF DEFINITIONS ::=
-- definitions for conformance
OBJECT-GROUP MACRO ::=
TYPE NOTATION ::=
"STATUS"
"DESCRIPTION"
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER
ObjectsPart ::=
"OBJECTS" "{" Objects "}"
Objects ::=
| Objects ","
Object ::=
value(Name ObjectName
Status ::=
"current
| "obsolete
ReferPart ::=
"REFERENCE"
|
-- uses the NVT ASCII character
Text ::= """" string """"
Case, McCloghrie, Rose & Waldbusser [Page 3]
RFC 1444 Conformance Statements for SNMPv2 April 1993
-- definitions for compliance
MODULE-COMPLIANCE MACRO ::=
TYPE NOTATION ::=
"STATUS"
"DESCRIPTION"
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER
Status ::=
"current
| "obsolete
ReferPart ::=
"REFERENCE"
|
ModulePart ::=
|
Modules ::=
| Modules
Module ::=
-- name of module --
"MODULE"
ModuleName ::=
modulereference
-- must not be empty unless
-- in MIB
|
ModuleIdentifier ::=
value(ModuleID OBJECT IDENTIFIER
|
MandatoryPart ::=
"MANDATORY-GROUPS" "{" Groups "}"
|
Case, McCloghrie, Rose & Waldbusser [Page 4]
RFC 1444 Conformance Statements for SNMPv2 April 1993
Groups ::=
| Groups ","
Group ::=
value(Group OBJECT IDENTIFIER
CompliancePart ::=
|
Compliances ::=
| Compliances
Compliance ::=
|
ComplianceGroup ::=
"GROUP" value(Name OBJECT IDENTIFIER
"DESCRIPTION"
Object ::=
"OBJECT" value(Name ObjectName
"DESCRIPTION"
-- must be a refinement for object's SYNTAX
SyntaxPart ::=
"SYNTAX" type(SYNTAX
|
-- must be a refinement for object's SYNTAX
WriteSyntaxPart ::=
"WRITE-SYNTAX" type(WriteSYNTAX
|
AccessPart ::=
"MIN-ACCESS"
|
Access ::=
"not-accessible
| "read-only
| "read-write
Case, McCloghrie, Rose & Waldbusser [Page 5]
RFC 1444 Conformance Statements for SNMPv2 April 1993
| "read-create
-- uses the NVT ASCII character
Text ::= """" string """"
Case, McCloghrie, Rose & Waldbusser [Page 6]
RFC 1444 Conformance Statements for SNMPv2 April 1993
-- definitions for capabilities
AGENT-CAPABILITIES MACRO ::=
TYPE NOTATION ::=
"PRODUCT-RELEASE"
"STATUS"
"DESCRIPTION"
VALUE NOTATION ::=
-- agent's sysObjectID [3] or snmpORID [4]
value(VALUE OBJECT IDENTIFIER
Status ::=
"current
| "obsolete
ReferPart ::=
"REFERENCE"
|
ModulePart ::=
|
Modules ::=
| Modules
Module ::=
-- name of module --
"SUPPORTS"
"INCLUDES" "{" Groups "}"
ModuleName ::=
identifier
ModuleIdentifier ::=
value(ModuleID OBJECT IDENTIFIER
|
Groups ::=
| Groups ","
Group ::=
Case, McCloghrie, Rose & Waldbusser [Page 7]
RFC 1444 Conformance Statements for SNMPv2 April 1993
value(Name OBJECT IDENTIFIER
VariationPart ::=
|
Variations ::=
| Variations
Variation ::=
"VARIATION" value(Name ObjectName
"DESCRIPTION"
-- must be a refinement for object's SYNTAX
SyntaxPart ::=
"SYNTAX" type(SYNTAX
|
-- must be a refinement for object's SYNTAX
WriteSyntaxPart ::=
"WRITE-SYNTAX" type(WriteSYNTAX
|
AccessPart ::=
"ACCESS"
|
Access ::=
"not-implemented
| "read-only
| "read-write
| "read-create
-- following is for backward-compatibility
| "write-only
CreationPart ::=
"CREATION-REQUIRES" "{" Cells "}"
|
Cells ::=
Case, McCloghrie, Rose & Waldbusser [Page 8]
RFC 1444 Conformance Statements for SNMPv2 April 1993
| Cells ","
Cell ::=
value(Cell ObjectName
DefValPart ::=
"DEFVAL" "{" value(Defval ObjectSyntax) "}"
|
-- uses the NVT ASCII character
Text ::= """" string """"
Case, McCloghrie, Rose & Waldbusser [Page 9]
RFC 1444 Conformance Statements for SNMPv2 April 1993
3. Mapping of the OBJECT-GROUP
For conformance purposes, it is useful to define a
of related managed objects. The OBJECT-GROUP macro is used
define each such collection of related objects. It should
noted that the expansion of the OBJECT-GROUP macro
something which conceptually happens during implementation
not during run-time
To "implement" an object, a SNMPv2 entity acting in an
role must return a reasonably accurate value for
protocol retrieval operations; similarly, if the object
writable, then in response to a management protocol
operation, a SNMPv2 entity must accordingly be able
reasonably influence the underlying managed entity. If
SNMPv2 entity acting in an agent role can not implement
object, the management protocol provides for the SNMPv2
to return an exception or error, e.g, noSuchObject [6].
no circumstances shall a SNMPv2 entity return a value
objects which it does not implement -- it must always
the appropriate exception or error, as described in
protocol specification [6].
3.1. Mapping of the OBJECTS
The OBJECTS clause which must be present, is used to name
object contained in the conformance group. Each of the
objects must be defined in the same information module as
OBJECT-GROUP macro appears, and must have a MAX-ACCESS
value of "read-only", "read-write", or "read-create".
3.2. Mapping of the STATUS
The STATUS clause, which must be present, indicates
this definition is current or historic
The values "current", and "obsolete" are self-explanatory
3.3. Mapping of the DESCRIPTION
The DESCRIPTION clause, which must be present, contains
textual definition of that group, along with a description
Case, McCloghrie, Rose & Waldbusser [Page 10]
RFC 1444 Conformance Statements for SNMPv2 April 1993
any relations to other groups. Note that generic
requirements should not be stated in this clause. However
implementation relationships between this group and
groups may be defined in this clause
3.4. Mapping of the REFERENCE
The REFERENCE clause, which need not be present, contains
textual cross-reference to a group defined in some
information module. This is useful when de-osifying a
module produced by some other organization
3.5. Mapping of the OBJECT-GROUP
The value of an invocation of the OBJECT-GROUP macro is
name of the group, which is an OBJECT IDENTIFIER,
administratively assigned name
Case, McCloghrie, Rose & Waldbusser [Page 11]
RFC 1444 Conformance Statements for SNMPv2 April 1993
3.6. Usage
Consider how the system group from MIB-II [3] might
described
systemGroup OBJECT-
OBJECTS { sysDescr, sysObjectID, sysUpTime
sysContact, sysName, sysLocation
sysServices }
STATUS
"The system group defines objects which are
to all managed systems."
::= { mibIIGroups 1 }
According to this invocation, the conformance group
{ mibIIGroups 1 }
contains 7 objects
Case, McCloghrie, Rose & Waldbusser [Page 12]
RFC 1444 Conformance Statements for SNMPv2 April 1993
4. Mapping of the MODULE-COMPLIANCE
The MODULE-COMPLIANCE macro is used to convey a minimum set
requirements with respect to implementation of one or more
modules. It should be noted that the expansion of
MODULE-COMPLIANCE macro is something which
happens during implementation and not during run-time
A requirement on all "standard" MIB modules is that
corresponding MODULE-COMPLIANCE specification is also defined
either in the same information module or in a
information module
4.1. Mapping of the STATUS
The STATUS clause, which must be present, indicates
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
foster interoperability with older implementations
4.2. Mapping of the DESCRIPTION
The DESCRIPTION clause, which must be present, contains
textual definition of this compliance statement and
embody any information which would otherwise be
in any ASN.1 commentary annotations associated with
statement
4.3. Mapping of the REFERENCE
The REFERENCE clause, which need not be present, contains
textual cross-reference to a compliance statement defined
some other information module
4.4. Mapping of the MODULE
The MODULE clause, which must be present, is repeatedly
to name each MIB module for which compliance requirements
Case, McCloghrie, Rose & Waldbusser [Page 13]
RFC 1444 Conformance Statements for SNMPv2 April 1993
being specified. Each MIB module is named by its module name
and optionally, by its associated OBJECT IDENTIFIER as well
The module name can be omitted when the MODULE-
invocation occurs inside a MIB module, to refer to
encompassing MIB module
4.4.1. Mapping of the MANDATORY-GROUPS
The MANDATORY-GROUPS clause, which need not be present,
the one or more groups within the correspondent MIB
which are unconditionally mandatory for implementation. If
SNMPv2 entity acting in an agent role claims compliance to
MIB module, then it must implement each and every
within each conformance group listed. That is, if a SNMPv
entity returns a noSuchObject exception in response to
management protocol get operation [5] for any object
any mandatory conformance group for every MIB view, then
SNMPv2 entity is not a conformant implementation of the
module
4.4.2. Mapping of the GROUP
The GROUP clause which need not be present, is repeatedly
to name each MIB group which is conditionally mandatory
unconditionally optional for compliance to the MIB module.
MIB group named in a GROUP clause must be absent from
correspondent MANDATORY-GROUPS clause
Conditionally mandatory groups include those which
mandatory only if a particular protocol is implemented,
only if another group is implemented. A GROUP clause'
DESCRIPTION specifies the conditions under which the group
conditionally mandatory
A MIB group which is named in neither a MANDATORY-
clause nor a GROUP clause, is unconditionally optional
compliance to the MIB module
4.4.3. Mapping of the OBJECT
The OBJECT clause which need not be present, is
used to name each MIB object for which compliance has
Case, McCloghrie, Rose & Waldbusser [Page 14]
RFC 1444 Conformance Statements for SNMPv2 April 1993
refined requirement with respect to the MIB module definition
The MIB object must be present in one of the
groups named in the correspondent MANDATORY-GROUPS clause
GROUP clauses
4.4.3.1. Mapping of the SYNTAX
The SYNTAX clause, which need not be present, is used
provide a refined SYNTAX for the object named in
correspondent OBJECT clause. Note that if this clause and
WRITE-SYNTAX clause are both present, then this clause
applies when instances of the object named in
correspondent OBJECT clause are read
Consult Section 10 of [2] for more information on
syntax
4.4.3.2. Mapping of the WRITE-SYNTAX
The WRITE-SYNTAX clause, which need not be present, is used
provide a refined SYNTAX for the object named in
correspondent OBJECT clause when instances of that object
written
Consult Section 10 of [2] for more information on
syntax
4.4.3.3. Mapping of the MIN-ACCESS
The MIN-ACCESS clause, which need not be present, is used
define the minimal level of access for the object named in
correspondent OBJECT clause. If this clause is absent,
minimal level of access is the same as the maximal
specified in the correspondent invocation of the OBJECT-
macro. If present, this clause must not specify a
level of access than is specified in the
invocation of the OBJECT-TYPE macro
The level of access for certain types of objects is
according to their syntax definition. These types are
conceptual tables and rows, auxiliary objects, and
with the syntax of Counter32, Counter64, or certain types
Case, McCloghrie, Rose & Waldbusser [Page 15]
RFC 1444 Conformance Statements for SNMPv2 April 1993
textual conventions (e.g., RowStatus [6]). A MIN-
clause should not be present for such objects
An implementation is compliant if the level of access
provides is greater or equal to the minimal level in
MODULE-COMPLIANCE macro and less or equal to the maximal
in the OBJECT-TYPE macro
4.4.3.4. Mapping of the DESCRIPTION
The DESCRIPTION clause must be present for each use of
GROUP or OBJECT clause. For an OBJECT clause, it contains
textual description of the refined compliance requirement
For a GROUP clause, it contains a textual description of
conditions under which the group is conditionally mandatory
unconditionally optional
4.5. Mapping of the MODULE-COMPLIANCE
The value of an invocation of the MODULE-COMPLIANCE macro
an OBJECT IDENTIFIER. As such, this value may
authoritatively used when referring to the
statement embodied by that invocation of the macro
Case, McCloghrie, Rose & Waldbusser [Page 16]
RFC 1444 Conformance Statements for SNMPv2 April 1993
4.6. Usage
Consider how a compliance statement might be included at
end of the MIB-II document [3], assuming that
groups were defined therein
OBJECT IDENTIFIER ::= { mibIIConformance 1 }
mibIIGroups OBJECT IDENTIFIER ::= { mibIIConformance 2 }
mibIICompliance MODULE-
STATUS
"The compliance statement for SNMPv2
residing on systems which implement the
suite of protocols."
MODULE -- compliance to the containing MIB
MANDATORY-GROUPS { systemGroup, snmpGroup }
GROUP
"The interfaces group is mandatory for
with network interfaces."
GROUP
"The ip group is mandatory for systems
implement IP."
GROUP
"The icmp group is mandatory for systems
implement ICMP."
GROUP
"The tcp group is mandatory for systems
implement TCP."
OBJECT
MIN-ACCESS read-
"A compliant system need not
write-access to this object."
GROUP
Case, McCloghrie, Rose & Waldbusser [Page 17]
RFC 1444 Conformance Statements for SNMPv2 April 1993
"The udp group is mandatory for systems
implement UDP."
GROUP
"The egp group is mandatory for systems
implement EGP."
::= { mibIICompliances 1 }
According to this invocation, to claim alignment with
compliance statement
{ mibIICompliances 1 }
a system must implement RFC1213's systemGroup and
conformance groups. If the system implements any
interfaces, then RFC1213's interfacesGroup conformance
must be implemented. Further, if the system implements any
the IP, ICMP, TCP, UDP, or EGP protocols, then
correspondent conformance group in RFC1213 must
implemented, if compliance is to be claimed. Finally
although RFC1213 specifies that it makes "protocol sense"
the tcpConnState object to be writable, this
allows the system to permit only read-only access and
claim compliance
Case, McCloghrie, Rose & Waldbusser [Page 18]
RFC 1444 Conformance Statements for SNMPv2 April 1993
5. Mapping of the AGENT-CAPABILITIES
The AGENT-CAPABILITIES macro is used to convey
capabilities present in a SNMPv2 entity acting in an
role. It should be noted that the expansion of the AGENT
CAPABILITIES macro is something which conceptually
during implementation and not during run-time
When a MIB module is written, it is divided into units
conformance termed groups. If a SNMPv2 entity acting in
agent role claims to implement a group, then it must
each and every object within that group. Of course,
whatever reason, a SNMPv2 entity might implement only a
of the groups within a MIB module. In addition,
definition of some MIB objects leave some aspects of
definition to the discretion of an implementor
Practical experience has demonstrated a need for
describing the capabilities of an agent with respect to one
more MIB modules. The AGENT-CAPABILITIES macro allows
agent implementor to describe the precise level of
which an agent claims in regards to a MIB group, and to
that description to the value of sysObjectID [3]
with the agent, or to the value of an instance of the
object in the snmpORTable [4]. In particular, some
may have restricted or augmented syntax or access-levels
If the AGENT-CAPABILITIES invocation is given to
management-station implementor, then that implementor
build management applications which optimize themselves
communicating with a particular agent. For example,
management-station can maintain a database of
invocations. When a management-station interacts with
agent, it retrieves the agent's sysObjectID [3]. Based
this, it consults the database. If an entry is found,
the management application can optimize its
accordingly
Note that this binding to sysObjectID may not always
to define all MIB objects to which an agent can
access. In particular, this situation occurs where the
dynamically learns of the objects it supports. In
cases, the snmpORID column of snmpORTable [4]
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
or variations with respect to OBJECT-TYPE macros in
modules, NOT with respect to MODULE-COMPLIANCE macros
compliance statements
5.1. Mapping of the PRODUCT-RELEASE
The PRODUCT-RELEASE clause, which must be present, contains
textual description of the product release which includes
agent
5.2. Mapping of the STATUS
The STATUS clause, which must be present, indicates
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
foster interoperability with older implementations
5.3. Mapping of the DESCRIPTION
The DESCRIPTION clause, which must be present, contains
textual description of this agent
5.4. Mapping of the REFERENCE
The REFERENCE clause, which need not be present, contains
textual cross-reference to a capability statement defined
some other information module
5.5. Mapping of the SUPPORTS
The SUPPORTS clause, which need not be present, is
used to name each MIB module for which the agent claims
complete or partial implementation. Each MIB module is
by its module name, and optionally, by its associated
IDENTIFIER as well
Case, McCloghrie, Rose & Waldbusser [Page 20]
RFC 1444 Conformance Statements for SNMPv2 April 1993
5.5.1. Mapping of the INCLUDES
The INCLUDES clause, which must be present for each use of
SUPPORTS clause, is used to name each MIB group
with the SUPPORT clause, which the agent claims to implement
5.5.2. Mapping of the VARIATION
The VARIATION clause, which need not be present, is
used to name each MIB object which the agent implements
some variant or refined fashion with respect to
correspondent invocation of the OBJECT-TYPE macro
Note that the variation concept is meant for
implementation restrictions, e.g., if the variation for
object depends on the values of other objects, then
should be noted in the appropriate DESCRIPTION clause
5.5.2.1. Mapping of the SYNTAX
The SYNTAX clause, which need not be present, is used
provide a refined SYNTAX for the object named in
correspondent VARIATION clause. Note that if this clause
a WRITE-SYNTAX clause are both present, then this clause
applies when instances of the object named in
correspondent VARIATION clause are read
Consult Section 10 of [2] for more information on
syntax
5.5.2.2. Mapping of the WRITE-SYNTAX
The WRITE-SYNTAX clause, which need not be present, is used
provide a refined SYNTAX for the object named in
correspondent VARIATION clause when instances of that
are written
Consult Section 10 of [2] for more information on
syntax
Case, McCloghrie, Rose & Waldbusser [Page 21]
RFC 1444 Conformance Statements for SNMPv2 April 1993
5.5.2.3. Mapping of the ACCESS
The ACCESS clause, which need not be present, is used
indicate the agent provides less than the maximal level
access to the object named in the correspondent
clause
The value "not-implemented" indicates the agent does
implement the object, and in the ordering of possible
is equivalent to "not-accessible".
The value "write-only" is provided solely for
compatibility, and shall not be used for newly-defined
types. In the ordering of possible values, "write-only"
less than "not-accessible".
5.5.2.4. Mapping of the CREATION-REQUIRES
The CREATION-REQUIRES clause, which need not be present,
used to name the columnar objects of a conceptual row to
values must be explicitly assigned, by a management
set operation, before the agent will allow the instance of
status column of that row to be set to `active'. (Consult
definition of RowStatus [6].)
If the conceptual row does not have a status column (i.e.,
objects corresponding to the conceptual table were
using the mechanisms in [7,8]), then the CREATION-
clause, which need not be present, is used to name
columnar objects of a conceptual row to which values must
explicitly assigned, by a management protocol set operation
before the agent will create new instances of objects in
row
This clause must not present unless the object named in
correspondent VARIATION clause is a conceptual row, i.e.,
a syntax which resolves to a SEQUENCE containing
objects. The objects named in the value of this
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
for a conceptual row, and which are columnar objects of
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
The DEFVAL clause, which need not be present, is used
provide a refined DEFVAL value for the object named in
correspondent VARIATION clause. The semantics of this
are identical to those of the OBJECT-TYPE macro's
clause
5.5.2.6. Mapping of the DESCRIPTION
The DESCRIPTION clause, which must be present for each use
the VARIATION clause, contains a textual description of
variant or refined implementation
5.6. Mapping of the AGENT-CAPABILITIES
The value of an invocation of the AGENT-CAPABILITIES macro
an OBJECT IDENTIFIER, which names the value of sysObjectID [3]
or snmpORID [4] for which this capabilities statement
valid
Case, McCloghrie, Rose & Waldbusser [Page 23]
RFC 1444 Conformance Statements for SNMPv2 April 1993
5.7. Usage
Consider how a capabilities statement for an agent might
described
exampleAgent AGENT-
PRODUCT-RELEASE "ACME Agent release 1.1 for 4BSD
STATUS
DESCRIPTION "ACME agent for 4BSD
SUPPORTS RFC1213-
INCLUDES { systemGroup, interfacesGroup
atGroup, ipGroup, icmpGroup
tcpGroup, udpGroup, snmpGroup }
VARIATION
SYNTAX INTEGER { up(1), down(2) }
DESCRIPTION "Unable to set test mode on 4BSD
VARIATION
SYNTAX INTEGER { up(1), down(2) }
DESCRIPTION "Information limited on 4BSD
VARIATION
CREATION-REQUIRES { atPhysAddress }
DESCRIPTION "Address mappings on 4BSD
both protocol and media addresses
VARIATION
SYNTAX INTEGER (255..255)
DESCRIPTION "Hard-wired on 4BSD
VARIATION
ACCESS not-
DESCRIPTION "Information not available on 4BSD
VARIATION
SYNTAX INTEGER { direct(3), indirect(4) }
WRITE-SYNTAX INTEGER { invalid(2), direct(3),
indirect(4) }
DESCRIPTION "Information limited on 4BSD
VARIATION
ACCESS read-
DESCRIPTION "Unable to set this on 4BSD
Case, McCloghrie, Rose & Waldbusser [Page 24]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SUPPORTS EVAL-
INCLUDES { functionsGroup, expressionsGroup }
VARIATION
CREATION-REQUIRES { evalString }
DESCRIPTION "Conceptual row creation supported
::= { acmeAgents 1 }
According to this invocation, an agent with a sysObjectID (
snmpORID) value
{ acmeAgents 1 }
supports two MIB modules
From MIB-II, all conformance groups except the
conformance group are supported. However, the
ipInAddrErrors is not implemented, whilst the
have a restricted syntax, and the
is available only for reading. Note that in the case of
object ipRouteType the set of values which may be read
different than the set of values which may be written
Finally, when creating a new instance in the atTable,
set-request must create an instance of atPhysAddress
From the EVAL-MIB, all the objects contained in
functionsGroup and expressionsGroup conformance groups
supported, without variation. In addition, creation of
instances in the expr table is supported
Case, McCloghrie, Rose & Waldbusser [Page 25]
RFC 1444 Conformance Statements for SNMPv2 April 1993
6. Extending an Information
As experience is gained with a published information module
it may be desirable to revise that information module
Section 10 of [2] defines the rules for extending
information module. The remainder of this section defines
conformance groups, compliance statements, and
statements may be extended
6.1. Conformance
If any non-editorial change is made to any clause of an
group then the OBJECT IDENTIFIER value associated with
object group must also be changed, along with its
descriptor
6.2. Compliance
If any non-editorial change is made to any clause of
compliance definition, then the OBJECT IDENTIFIER
associated with that compliance definition must also
changed, along with its associated descriptor
6.3. Capabilities
If any non-editorial change is made to any clause of
capabilities definition, then the OBJECT IDENTIFIER
associated with that capabilities definition must also
changed, along with its associated descriptor
Case, McCloghrie, Rose & Waldbusser [Page 26]
RFC 1444 Conformance Statements for SNMPv2 April 1993
7.
The section on compliance statements is based, in part, on
conversation with James R. Davin in December, 1990.
The section on capabilities statements is based, in part,
RFC 1303.
Finally, the comments of the SNMP version 2 working group
gratefully acknowledged
Beth Adams, Network Management
Steve Alexander, INTERACTIVE Systems
David Arneson, Cabletron
Toshiya
Fred Baker,
Jim Barnes, Xylogics, Inc
Brian
Andy Bierman, SynOptics Communications, Inc
Uri Blumenthal, IBM
Fred Bohle,
Jack
Theodore Brunner,
Stephen F. Bush, GE Information
Jeffrey D. Case, University of Tennessee,
John Chang, IBM
Szusin Chen, Sun
Robert
Chris Chiotasso, Ungermann-
Bobby A. Clay, NASA/
John Cooke,
Tracy Cox,
Juan Cruz, Datability, Inc
David Cullerot, Cabletron
Cathy Cunningham,
James R. (Chuck) Davin,
Michael Davis,
Mike Davison,
Cynthia DellaTorre,
Taso N. Devetzis,
Manual Diaz, DAVID Systems, Inc
Jon Dreyer, Sun
David Engel, Optical Data
Mike Erlinger,
Roger Fajman,
Case, McCloghrie, Rose & Waldbusser [Page 27]
RFC 1444 Conformance Statements for SNMPv2 April 1993
Daniel Fauvarque, Sun
Karen Frisa,
Shari Galitzer,
Shawn Gallagher, Digital Equipment
Richard Graveman,
Maria Greene, Xyplex, Inc
Michel Guittet,
Robert Gutierrez,
Bill Hagerty, Cabletron
Gary W. Haney, Martin Marietta Energy
Patrick Hanil, Nokia
Matt Hecht, SNMP Research, Inc
Edward A. Heiner, Jr., Synernetics Inc
Susan E. Hicks, Martin Marietta Energy
Geral Holzhauer,
John Hopprich, DAVID Systems, Inc
Jeff Hughes, Hewlett-
Robin Iddon, Axon Networks, Inc
David
Kevin M. Jackson, Concord Communications, Inc
Ole J. Jacobsen, Interop
Ronald Jacoby, Silicon Graphics, Inc
Satish Joshi, SynOptics Communications, Inc
Frank Kastenholz, FTP
Mark Kepke, Hewlett-
Ken Key, SNMP Research, Inc
Zbiginew Kielczewski,
Jongyeoi
Andrew Knutsen, The Santa Cruz
Michael L. Kornegay,
Deirdre C. Kostik,
Cheryl Krupczak, Georgia
Mark S. Lewis,
David
David Lindemulder, AT&T/
Ben Lisowski,
David Liu, Bell-Northern
John Lunny, The Wollongong
Robert C. Lushbaugh Martin, Marietta Energy
Michael Luufer,
Carl Madison, Star-Tek, Inc
Keith McCloghrie, Hughes LAN
Evan McGinnis, 3Com
Bill McKenzie, IBM
Donna McMaster, SynOptics Communications, Inc
Case, McCloghrie, Rose & Waldbusser [Page 28]
RFC 1444 Conformance Statements for SNMPv2 April 1993
John Medicke, IBM
Doug Miller,
Dave Minnich,
Mohammad Mirhakkak,
Rohit Mital,
George Mouradian, AT&T Bell
Patrick Mullaney, Cabletron
Dan Myers, 3Com
Rina Nathaniel, Rad Network Devices Ltd
Hien V. Nguyen,
Mo
Tom
William B. Norton,
Steve Onishi, Wellfleet Communications, Inc
David T. Perkins, SynOptics Communications, Inc
Carl Powell,
Ilan Raab, SynOptics Communications, Inc
Richard Ramons, AT&
Venkat D. Rangan, Metric Network Systems, Inc
Louise Reingold,
Sam Roberts, Farallon Computing, Inc
Kary Robertson, Concord Communications, Inc
Dan Romascanu, Lannet Data Communications Ltd
Marshall T. Rose, Dover Beach Consulting, Inc
Shawn A. Routhier, Epilogue Technology
Chris
Asaf Rubissa,
Jon Saperia, Digital Equipment
Michael
Mike Scanlon,
Sam Schaen,
John Seligson, Ultra Network
Paul A. Serice, Corporation for Open
Chris Shaw, Banyan
Timon
Robert Snyder, Cisco
Joo Young
Roy Spitier,
Einar Stefferud, Network Management
John Stephens, Cayman Systems, Inc
Robert L. Stewart, Xyplex, Inc. (chair
Kaj Tesink,
Dean Throop, Data
Ahmet Tuncay, France Telecom-
Maurice Turcotte, Racal
Case, McCloghrie, Rose & Waldbusser [Page 29]
RFC 1444 Conformance Statements for SNMPv2 April 1993
Warren Vik, INTERACTIVE Systems
Yannis
Steven L. Waldbusser, Carnegie Mellon
Timothy M. Walden,
Alice Wang, Sun
James Watt,
Luanne Waul,
Donald E. Westlake III, Digital Equipment
Gerry
Bert Wijnen, IBM
Peter Wilson, 3Com
Steven Wong, Digital Equipment
Randy Worzella, IBM
Daniel Woycke,
Honda
Jeff Yarnell,
Chris Young,
Kiho Yum, 3Com
Case, McCloghrie, Rose & Waldbusser [Page 30]
RFC 1444 Conformance Statements for SNMPv2 April 1993
8.
[1] Information processing systems - Open
Interconnection - Specification of Abstract
Notation One (ASN.1), International Organization
Standardization. International Standard 8824, (December
1987).
[2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Structure of Management Information for version 2 of
Simple Network Management Protocol (SNMPv2)", RFC 1442,
SNMP Research, Inc., Hughes LAN Systems, Dover
Consulting, Inc., Carnegie Mellon University, April 1993.
[3] McCloghrie, K., and Rose, M., "Management
Base for Network Management of TCP/IP-based internets
MIB-II", STD 17, RFC 1213, March 1991.
[4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Management Information Base for version 2 of the
Network Management Protocol (SNMPv2)", RFC 1450,
Research, Inc., Hughes LAN Systems, Dover
Consulting, Inc., Carnegie Mellon University, April 1993.
[5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Protocol Operations for version 2 of the Simple
Management Protocol (SNMPv2)", RFC 1448, SNMP Research
Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
Carnegie Mellon University, April 1993.
[6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Textual Conventions for version 2 of the the
Network Management Protocol (SNMPv2)", RFC 1443,
Research, Inc., Hughes LAN Systems, Dover
Consulting, Inc., Carnegie Mellon University, April 1993.
[7] Rose, M., and McCloghrie, K., "Structure
Identification of Management Information for TCP/IP-
internets", STD 16, RFC 1155, May 1990.
[8] Rose, M., and McCloghrie, K., "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
Case, McCloghrie, Rose & Waldbusser [Page 31]
RFC 1444 Conformance Statements for SNMPv2 April 1993
9. Security
Security issues are not discussed in this memo
10. Authors'
Jeffrey D.
SNMP Research, Inc
3001 Kimberlin Heights Rd
Knoxville, TN 37920-9716
Phone: +1 615 573 1434
Email: case@snmp.
Keith
Hughes LAN
1225 Charleston
Mountain View, CA 94043
Phone: +1 415 966 7934
Email: kzm@hls.
Marshall T.
Dover Beach Consulting, Inc
420 Whisman
Mountain View, CA 94043-2186
Phone: +1 415 968 1052
Email: mrose@dbc.mtview.ca.
Steven
Carnegie Mellon
4910 Forbes
Pittsburgh, PA 15213
Phone: +1 412 268 6628
Email: waldbusser@cmu.
Case, McCloghrie, Rose & Waldbusser [Page 32]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
