doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc1904.txt b/doc/rfc/rfc1904.txt
new file mode 100644
index 0000000..3752748
--- /dev/null
+++ b/doc/rfc/rfc1904.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group                               SNMPv2 Working Group
+Request for Comments: 1904                                       J. Case
+Obsoletes: 1444                                      SNMP Research, Inc.
+Category: Standards Track                                  K. McCloghrie
+                                                     Cisco Systems, Inc.
+                                                                 M. Rose
+                                            Dover Beach Consulting, Inc.
+                                                           S. Waldbusser
+                                          International Network Services
+                                                            January 1996
+
+
+              Conformance Statements for Version 2 of the
+              Simple Network Management Protocol (SNMPv2)
+
+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.
+
+Table of Contents
+
+   1. Introduction ................................................    2
+   1.1 A Note on Terminology ......................................    3
+   2. Definitions .................................................    3
+   2.1 The OBJECT-GROUP macro .....................................    3
+   2.2 The NOTIFICATION-GROUP macro ...............................    4
+   2.3 The MODULE-COMPLIANCE macro ................................    5
+   2.4 The AGENT-CAPABILITIES macro ...............................    7
+   3. Mapping of the OBJECT-GROUP macro ...........................    9
+   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 ............................   10
+   3.5 Mapping of the OBJECT-GROUP value ..........................   10
+   3.6 Usage Example ..............................................   11
+   4. Mapping of the NOTIFICATION-GROUP macro .....................   11
+   4.1 Mapping of the NOTIFICATIONS clause ........................   11
+   4.2 Mapping of the STATUS clause ...............................   11
+   4.3 Mapping of the DESCRIPTION clause ..........................   12
+   4.4 Mapping of the REFERENCE clause ............................   12
+   4.5 Mapping of the NOTIFICATION-GROUP value ....................   12
+   4.6 Usage Example ..............................................   12
+   5. Mapping of the MODULE-COMPLIANCE macro ......................   12
+   5.1 Mapping of the STATUS clause ...............................   13
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 1]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+   5.2 Mapping of the DESCRIPTION clause ..........................   13
+   5.3 Mapping of the REFERENCE clause ............................   13
+   5.4 Mapping of the MODULE clause ...............................   13
+   5.4.1 Mapping of the MANDATORY-GROUPS clause ...................   13
+   5.4.2 Mapping of the GROUP clause ..............................   14
+   5.4.3 Mapping of the OBJECT clause .............................   14
+   5.4.3.1 Mapping of the SYNTAX clause ...........................   14
+   5.4.3.2 Mapping of the WRITE-SYNTAX clause .....................   15
+   5.4.3.3 Mapping of the MIN-ACCESS clause .......................   15
+   5.4.4 Mapping of the DESCRIPTION clause ........................   15
+   5.5 Mapping of the MODULE-COMPLIANCE value .....................   15
+   5.6 Usage Example ..............................................   16
+   6. Mapping of the AGENT-CAPABILITIES macro .....................   16
+   6.1 Mapping of the PRODUCT-RELEASE clause ......................   17
+   6.2 Mapping of the STATUS clause ...............................   17
+   6.3 Mapping of the DESCRIPTION clause ..........................   17
+   6.4 Mapping of the REFERENCE clause ............................   17
+   6.5 Mapping of the SUPPORTS clause .............................   18
+   6.5.1 Mapping of the INCLUDES clause ...........................   18
+   6.5.2 Mapping of the VARIATION clause ..........................   18
+   6.5.2.1 Mapping of the SYNTAX clause ...........................   18
+   6.5.2.2 Mapping of the WRITE-SYNTAX clause .....................   18
+   6.5.2.3 Mapping of the ACCESS clause ...........................   19
+   6.5.2.4 Mapping of the CREATION-REQUIRES clause ................   19
+   6.5.2.5 Mapping of the DEFVAL clause ...........................   20
+   6.5.2.6 Mapping of the DESCRIPTION clause ......................   20
+   6.6 Mapping of the AGENT-CAPABILITIES value ....................   20
+   6.7 Usage Example ..............................................   20
+   7. Extending an Information Module .............................   22
+   7.1 Conformance Groups .........................................   22
+   7.2 Compliance Definitions .....................................   22
+   7.3 Capabilities Definitions ...................................   22
+   8. Security Considerations .....................................   23
+   9. Editor's Address ............................................   23
+   10. Acknowledgements ...........................................   23
+   11. References .................................................   24
+
+1.  Introduction
+
+   A management system contains:  several (potentially many) nodes, each
+   with a processing entity, termed an agent, which has access to
+   management instrumentation; at least one management station; and, a
+   management protocol, used to convey management information between
+   the agents and management stations.  Operations of the protocol are
+   carried out under an administrative framework which defines
+   authentication, authorization, access control, and privacy policies.
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 2]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+   Management stations execute management applications which monitor and
+   control managed elements.  Managed elements are devices such as
+   hosts, routers, terminal servers, etc., which are monitored and
+   controlled via access to their management information.
+
+   Management information is viewed as a collection of managed objects,
+   residing in a virtual information store, termed the Management
+   Information Base (MIB).  Collections of related objects are defined
+   in MIB modules.  These modules are written 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 of
+   implementation, along with the actual level of implementation
+   achieved.  It is the purpose of this document to define the notation
+   used for these purposes.
+
+1.1.  A Note on Terminology
+
+   For the purpose of exposition, the original Internet-standard Network
+   Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD
+   15), and 1212 (STD 16), is termed the SNMP version 1 framework
+   (SNMPv1).  The current framework is termed the SNMP version 2
+   framework (SNMPv2).
+
+2.  Definitions
+
+SNMPv2-CONF DEFINITIONS ::= BEGIN
+
+-- definitions for conformance groups
+
+OBJECT-GROUP MACRO ::=
+BEGIN
+    TYPE NOTATION ::=
+                  ObjectsPart
+                  "STATUS" Status
+                  "DESCRIPTION" Text
+                  ReferPart
+
+    VALUE NOTATION ::=
+                  value(VALUE OBJECT IDENTIFIER)
+
+    ObjectsPart ::=
+                  "OBJECTS" "{" Objects "}"
+    Objects ::=
+                  Object
+                | Objects "," Object
+    Object ::=
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 3]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+                  value(Name ObjectName)
+
+    Status ::=
+                  "current"
+                | "deprecated"
+                | "obsolete"
+
+    ReferPart ::=
+                  "REFERENCE" Text
+                | empty
+
+    -- uses the NVT ASCII character set
+    Text ::= """" string """"
+END
+
+
+-- more definitions for conformance groups
+
+NOTIFICATION-GROUP MACRO ::=
+BEGIN
+    TYPE NOTATION ::=
+                  NotificationsPart
+                  "STATUS" Status
+                  "DESCRIPTION" Text
+                  ReferPart
+
+    VALUE NOTATION ::=
+                  value(VALUE OBJECT IDENTIFIER)
+
+    NotificationsPart ::=
+                  "NOTIFICATIONS" "{" Notifications "}"
+    Notifications ::=
+                  Notification
+                | Notifications "," Notification
+    Notification ::=
+                  value(Name NotificationName)
+
+    Status ::=
+                  "current"
+                | "deprecated"
+                | "obsolete"
+
+    ReferPart ::=
+                  "REFERENCE" Text
+                | empty
+
+    -- uses the NVT ASCII character set
+    Text ::= """" string """"
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 4]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+END
+
+
+-- definitions for compliance statements
+
+MODULE-COMPLIANCE MACRO ::=
+BEGIN
+    TYPE NOTATION ::=
+                  "STATUS" Status
+                  "DESCRIPTION" Text
+                  ReferPart
+                  ModulePart
+
+    VALUE NOTATION ::=
+                  value(VALUE OBJECT IDENTIFIER)
+
+    Status ::=
+                  "current"
+                | "deprecated"
+                | "obsolete"
+
+    ReferPart ::=
+                "REFERENCE" Text
+              | empty
+
+    ModulePart ::=
+                  Modules
+                | empty
+    Modules ::=
+                  Module
+                | Modules Module
+    Module ::=
+                  -- name of module --
+                  "MODULE" ModuleName
+                  MandatoryPart
+                  CompliancePart
+
+    ModuleName ::=
+                  modulereference ModuleIdentifier
+                -- must not be empty unless contained
+                -- in MIB Module
+                | empty
+    ModuleIdentifier ::=
+                  value(ModuleID OBJECT IDENTIFIER)
+                | empty
+
+    MandatoryPart ::=
+                  "MANDATORY-GROUPS" "{" Groups "}"
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 5]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+                | empty
+
+    Groups ::=
+                  Group
+                | Groups "," Group
+    Group ::=
+                  value(Group OBJECT IDENTIFIER)
+
+    CompliancePart ::=
+                  Compliances
+                | empty
+
+    Compliances ::=
+                  Compliance
+                | Compliances Compliance
+    Compliance ::=
+                  ComplianceGroup
+                | Object
+
+    ComplianceGroup ::=
+                  "GROUP" value(Name OBJECT IDENTIFIER)
+                  "DESCRIPTION" Text
+
+    Object ::=
+                  "OBJECT" value(Name ObjectName)
+                  SyntaxPart
+                  WriteSyntaxPart
+                  AccessPart
+                  "DESCRIPTION" Text
+
+    -- must be a refinement for object's SYNTAX clause
+    SyntaxPart ::=
+                  "SYNTAX" type(SYNTAX)
+                | empty
+
+    -- must be a refinement for object's SYNTAX clause
+    WriteSyntaxPart ::=
+                  "WRITE-SYNTAX" type(WriteSYNTAX)
+                | empty
+
+    AccessPart ::=
+                  "MIN-ACCESS" Access
+                | empty
+    Access ::=
+                  "not-accessible"
+                | "accessible-for-notify"
+                | "read-only"
+                | "read-write"
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 6]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+                | "read-create"
+
+    -- uses the NVT ASCII character set
+    Text ::= """" string """"
+END
+
+
+-- definitions for capabilities statements
+
+AGENT-CAPABILITIES MACRO ::=
+BEGIN
+    TYPE NOTATION ::=
+                  "PRODUCT-RELEASE" Text
+                  "STATUS" Status
+                  "DESCRIPTION" Text
+                  ReferPart
+                  ModulePart
+
+    VALUE NOTATION ::=
+                  value(VALUE OBJECT IDENTIFIER)
+
+    Status ::=
+                  "current"
+                | "obsolete"
+
+    ReferPart ::=
+                "REFERENCE" Text
+              | empty
+
+    ModulePart ::=
+                  Modules
+                | empty
+    Modules ::=
+                  Module
+                | Modules Module
+    Module ::=
+                  -- name of module --
+                  "SUPPORTS" ModuleName
+                  "INCLUDES" "{" Groups "}"
+                  VariationPart
+
+    ModuleName ::=
+                  identifier ModuleIdentifier
+    ModuleIdentifier ::=
+                  value(ModuleID OBJECT IDENTIFIER)
+                | empty
+
+    Groups ::=
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 7]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+                  Group
+                | Groups "," Group
+    Group ::=
+                  value(Name OBJECT IDENTIFIER)
+
+    VariationPart ::=
+                  Variations
+                | empty
+    Variations ::=
+                  Variation
+                | Variations Variation
+
+    Variation ::=
+                  ObjectVariation
+                | NotificationVariation
+
+    NotificationVariation ::=
+                  "VARIATION" value(Name NotificationName)
+                  AccessPart
+                  "DESCRIPTION" Text
+
+    ObjectVariation ::=
+                  "VARIATION" value(Name ObjectName)
+                  SyntaxPart
+                  WriteSyntaxPart
+                  AccessPart
+                  CreationPart
+                  DefValPart
+                  "DESCRIPTION" Text
+
+    -- must be a refinement for object's SYNTAX clause
+    SyntaxPart ::=
+                  "SYNTAX" type(SYNTAX)
+                | empty
+
+    -- must be a refinement for object's SYNTAX clause
+    WriteSyntaxPart ::=
+                  "WRITE-SYNTAX" type(WriteSYNTAX)
+                | empty
+
+    AccessPart ::=
+                  "ACCESS" Access
+                | empty
+
+    Access ::=
+                  "not-implemented"
+                -- only "not-implemented" for notifications
+                | "accessible-for-notify"
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 8]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+                | "read-only"
+                | "read-write"
+                | "read-create"
+                -- following is for backward-compatibility only
+                | "write-only"
+
+    CreationPart ::=
+                  "CREATION-REQUIRES" "{" Cells "}"
+                | empty
+
+    Cells ::=
+                  Cell
+                | Cells "," Cell
+
+    Cell ::=
+                  value(Cell ObjectName)
+
+    DefValPart ::=
+                  "DEFVAL" "{" value(Defval ObjectSyntax) "}"
+                | empty
+
+    -- uses the NVT ASCII character set
+    Text ::= """" string """"
+END
+
+
+END
+
+3.  Mapping of the OBJECT-GROUP macro
+
+   For conformance purposes, it is useful to define a collection of
+   related managed objects.  The OBJECT-GROUP macro is used to define
+   each such collection of related objects.  It should be noted that the
+   expansion of the OBJECT-GROUP macro is something which conceptually
+   happens during implementation and not during run-time.
+
+   To "implement" an object, a SNMPv2 entity acting in an agent role
+   must return a reasonably accurate value for management protocol
+   retrieval operations; similarly, if the object is writable, then in
+   response to a management protocol set operation, a SNMPv2 entity must
+   accordingly be able to reasonably influence the underlying managed
+   entity.  If a SNMPv2 entity acting in an agent role can not implement
+   an object, the management protocol provides for the SNMPv2 entity to
+   return an exception or error, e.g, noSuchObject [4].  Under no
+   circumstances shall a SNMPv2 entity return a value for objects which
+   it does not implement -- it must always return the appropriate
+   exception or error, as described in the protocol specification [4].
+
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 9]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+3.1.  Mapping of the OBJECTS clause
+
+   The OBJECTS clause, which must be present, is used to name each
+   object contained in the conformance group.  Each of the named objects
+   must be defined in the same information module as the OBJECT-GROUP
+   macro appears, and must have a MAX-ACCESS clause value of
+   "accessible-for-notify", "read-only", "read-write", or "read-create".
+
+   It is required that every object defined in an information module
+   with a MAX-ACCESS clause other than "not-accessible" be contained in
+   at least one object group.  This avoids the common error of adding a
+   new object to an information module and forgetting to add the new
+   object to a group.
+
+3.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 the definition is obsolete, but
+   that an implementor may wish to support the group to foster
+   interoperability with older implementations.
+
+3.3.  Mapping of the DESCRIPTION clause
+
+   The DESCRIPTION clause, which must be present, contains a textual
+   definition of that group, along with a description of any relations
+   to other groups.  Note that generic compliance requirements should
+   not be stated in this clause.  However, implementation relationships
+   between this group and other groups may be defined in this clause.
+
+3.4.  Mapping of the REFERENCE clause
+
+   The REFERENCE clause, which need not be present, contains a textual
+   cross-reference to a group  defined in some other information module.
+   This is useful when de-osifying a MIB module produced by some other
+   organization.
+
+3.5.  Mapping of the OBJECT-GROUP value
+
+   The value of an invocation of the OBJECT-GROUP macro is the name of
+   the group, which is an OBJECT IDENTIFIER, an administratively
+   assigned name.
+
+
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 10]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+3.6.  Usage Example
+
+   The SNMP Group [3] is described:
+
+snmpGroup OBJECT-GROUP
+    OBJECTS { snmpInPkts,
+              snmpInBadVersions,
+              snmpInASNParseErrs,
+              snmpBadOperations,
+              snmpSilentDrops,
+              snmpProxyDrops,
+              snmpEnableAuthenTraps }
+    STATUS  current
+    DESCRIPTION
+            "A collection of objects providing basic instrumentation and
+            control of an SNMPv2 entity."
+    ::= { snmpMIBGroups 8 }
+
+
+According to this invocation, the conformance group named
+
+     { snmpMIBGroups 8 }
+
+contains 7 objects.
+
+4.  Mapping of the NOTIFICATION-GROUP macro
+
+   For conformance purposes, it is useful to define a collection of
+   notifications.  The NOTIFICATION-GROUP macro serves this purpose.  It
+   should be noted that the expansion of the NOTIFICATION-GROUP macro is
+   something which conceptually happens during implementation and not
+   during run-time.
+
+4.1.  Mapping of the NOTIFICATIONS clause
+
+   The NOTIFICATIONS clause, which must be present, is used to name each
+   notification contained in the conformance group.  Each of the named
+   notifications must be defined in the same information module as the
+   NOTIFICATION-GROUP macro appears.
+
+4.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 the definition is obsolete, but
+   that an implementor may wish to support the group to foster
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 11]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+   interoperability with older implementations.
+
+4.3.  Mapping of the DESCRIPTION clause
+
+   The DESCRIPTION clause, which must be present, contains a textual
+   definition of the group, along with a description of any relations to
+   other groups.  Note that generic compliance requirements should not
+   be stated in this clause.  However, implementation relationships
+   between this group and other groups may be defined in this clause.
+
+4.4.  Mapping of the REFERENCE clause
+
+   The REFERENCE clause, which need not be present, contains a textual
+   cross-reference to a group defined in some other information module.
+   This is useful when de-osifying a MIB module produced by some other
+   organization.
+
+4.5.  Mapping of the NOTIFICATION-GROUP value
+
+   The value of an invocation of the NOTIFICATION-GROUP macro is the
+   name of the group, which is an OBJECT IDENTIFIER, an administratively
+   assigned name.
+
+4.6.  Usage Example
+
+   The SNMP Basic Notifications Group [3] is described:
+
+snmpBasicNotificationsGroup NOTIFICATION-GROUP
+    NOTIFICATIONS { coldStart, authenticationFailure }
+    STATUS        current
+    DESCRIPTION
+            "The two notifications which an SNMPv2 entity is required to
+            implement."
+    ::= { snmpMIBGroups 7 }
+
+According to this invocation, the conformance group named
+
+     { snmpMIBGroups 1 }
+
+contains 2 notifications.
+
+5.  Mapping of the MODULE-COMPLIANCE macro
+
+   The MODULE-COMPLIANCE macro is used to convey a minimum set of
+   requirements with respect to implementation of one or more MIB
+   modules.  It should be noted that the expansion of the MODULE-
+   COMPLIANCE macro is something which conceptually happens during
+   implementation and not during run-time.
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 12]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+   A requirement on all "standard" MIB modules is that a corresponding
+   MODULE-COMPLIANCE specification is also defined, either in the same
+   information module or in a companion information module.
+
+5.1.  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 the specification is obsolete, but
+   that an implementor may wish to support that object to foster
+   interoperability with older implementations.
+
+5.2.  Mapping of the DESCRIPTION clause
+
+   The DESCRIPTION clause, which must be present, contains a textual
+   definition of this compliance statement and should embody any
+   information which would otherwise be communicated in any ASN.1
+   commentary annotations associated with the statement.
+
+5.3.  Mapping of the REFERENCE clause
+
+   The REFERENCE clause, which need not be present, contains a textual
+   cross-reference to a compliance statement defined in some other
+   information module.
+
+5.4.  Mapping of the MODULE clause
+
+   The MODULE clause, which must be present, is repeatedly used to name
+   each MIB module for which compliance requirements are 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-COMPLIANCE invocation occurs
+   inside a MIB module, to refer to the encompassing MIB module.
+
+5.4.1.  Mapping of the MANDATORY-GROUPS clause
+
+   The MANDATORY-GROUPS clause, which need not be present, names the one
+   or more object or notification groups within the correspondent MIB
+   module which are unconditionally mandatory for implementation.  If a
+   SNMPv2 entity acting in an agent role claims compliance to the MIB
+   module, then it must implement each and every object and notification
+   within each conformance group listed.  That is, if a SNMPv2 entity
+   returns a noSuchObject exception in response to a management protocol
+   get operation [4] for any object within any mandatory conformance
+   group for every MIB view, or if the SNMPv2 entity cannot generate
+   each notification listed in any conformance group under the
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 13]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+   appropriate circumstances, then that SNMPv2 entity is not a
+   conformant implementation of the MIB module.
+
+5.4.2.  Mapping of the GROUP clause
+
+   The GROUP clause, which need not be present, is repeatedly used to
+   name each object and notification group which is conditionally
+   mandatory or unconditionally optional for compliance to the MIB
+   module.  A group named in a GROUP clause must be absent from the
+   correspondent MANDATORY-GROUPS clause.
+
+   Conditionally mandatory groups include those which are mandatory only
+   if a particular protocol is implemented, or only if another group is
+   implemented.  A GROUP clause's DESCRIPTION specifies the conditions
+   under which the group is conditionally mandatory.
+
+   A group which is named in neither a MANDATORY-GROUPS clause nor a
+   GROUP clause, is unconditionally optional for compliance to the MIB
+   module.
+
+5.4.3.  Mapping of the OBJECT clause
+
+   The OBJECT clause, which need not be present, is repeatedly used to
+   name each MIB object for which compliance has a refined requirement
+   with respect to the MIB module definition.  The MIB object must be
+   present in one of the conformance groups named in the correspondent
+   MANDATORY-GROUPS clause or GROUP clauses.
+
+   By definition, each object specified in an OBJECT clause follows a
+   MODULE clause which names the information module in which that object
+   is defined.  Therefore, the use of an IMPORTS statement, to specify
+   from where such objects are imported, is redundant and is not
+   required in an information module.
+
+5.4.3.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 OBJECT
+   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 OBJECT clause are read.
+
+   Consult Section 9 of [2] for more information on refined syntax.
+
+
+
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 14]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+5.4.3.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
+   OBJECT clause when instances of that object are written.
+
+   Consult Section 9 of [2] for more information on refined syntax.
+
+5.4.3.3.  Mapping of the MIN-ACCESS clause
+
+   The MIN-ACCESS clause, which need not be present, is used to define
+   the minimal level of access for the object named in the correspondent
+   OBJECT clause.  If this clause is absent, the minimal level of access
+   is the same as the maximal level specified in the correspondent
+   invocation of the OBJECT-TYPE macro.  If present, this clause must
+   not specify a greater level of access than is specified in the
+   correspondent invocation of the OBJECT-TYPE macro.
+
+   The level of access for certain types of objects is fixed according
+   to their syntax definition.  These types include: conceptual tables
+   and rows, auxiliary objects, and objects with the syntax of
+   Counter32, Counter64 (and possibly, certain types of textual
+   conventions).  A MIN-ACCESS clause should not be present for such
+   objects.
+
+   An implementation is compliant if the level of access it provides is
+   greater or equal to the minimal level in the MODULE-COMPLIANCE macro
+   and less or equal to the maximal level in the OBJECT-TYPE macro.
+
+5.4.4.  Mapping of the DESCRIPTION clause
+
+   The DESCRIPTION clause must be present for each use of the GROUP or
+   OBJECT clause.  For an OBJECT clause, it contains a textual
+   description of the refined compliance requirement.  For a GROUP
+   clause, it contains a textual description of the conditions under
+   which the group is conditionally mandatory or unconditionally
+   optional.
+
+5.5.  Mapping of the MODULE-COMPLIANCE value
+
+   The value of an invocation of the MODULE-COMPLIANCE macro is an
+   OBJECT IDENTIFIER.  As such, this value may be authoritatively used
+   when referring to the compliance statement embodied by that
+   invocation of the macro.
+
+
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 15]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+5.6.  Usage Example
+
+   The compliance statement contained in the (hypothetical) XYZv2-MIB
+   might be:
+
+xyzMIBCompliance MODULE-COMPLIANCE
+    STATUS  current
+    DESCRIPTION
+            "The compliance statement for XYZv2 entities which implement
+            the XYZv2 MIB."
+    MODULE  -- compliance to the containing MIB module
+        MANDATORY-GROUPS { xyzSystemGroup,
+                           xyzStatsGroup, xyzTrapGroup,
+                           xyzSetGroup,
+                           xyzBasicNotificationsGroup }
+
+        GROUP   xyzV1Group
+        DESCRIPTION
+            "The xyzV1 group is mandatory only for those
+             XYZv2 entities which also implement XYZv1."
+::= { xyzMIBCompliances 1 }
+
+   According to this invocation, to claim alignment with the compliance
+   statement named
+
+     { xyzMIBCompliances 1 }
+
+   a system must implement the XYZv2-MIB's xyzSystemGroup,
+   xyzStatsGroup, xyzTrapGroup, and xyzSetGroup object conformance
+   groups, as well as the xyzBasicNotificationsGroup notifications
+   group.  Furthermore, if the XYZv2 entity also implements XYZv1, then
+   it must also support the XYZv1Group group, if compliance is to be
+   claimed.
+
+6.  Mapping of the AGENT-CAPABILITIES macro
+
+   The AGENT-CAPABILITIES macro is used to convey a set of 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
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 16]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+   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 an instance
+   of sysORID [3].  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 from the agent the values of all instances of sysORID [3].
+   Based on this, it consults the database to locate each entry matching
+   one of the retrieved values of sysORID.  Using the located entries,
+   the management application can now optimize its behavior accordingly.
+
+   Note that the AGENT-CAPABILITIES macro specifies refinements or
+   variations with respect to OBJECT-TYPE and NOTIFICATION-TYPE macros
+   in MIB modules, NOT with respect to MODULE-COMPLIANCE macros in
+   compliance statements.
+
+6.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 set of
+   capabilities.
+
+6.2.  Mapping of the STATUS clause
+
+   The STATUS clause, which must be present, indicates whether this
+   definition is current ("current") or historic ("obsolete").
+
+6.3.  Mapping of the DESCRIPTION clause
+
+   The DESCRIPTION clause, which must be present, contains a textual
+   description of this set of capabilities.
+
+6.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.
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 17]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+6.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.
+
+6.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
+   SUPPORTS clause, which the agent claims to implement.
+
+6.5.2.  Mapping of the VARIATION clause
+
+   The VARIATION clause, which need not be present, is repeatedly used
+   to name each object or notification which the agent implements in
+   some variant or refined fashion with respect to the correspondent
+   invocation of the OBJECT-TYPE or NOTIFICATION-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.
+
+   By definition, each object specified in a VARIATION clause follows a
+   SUPPORTS clause which names the information module in which that
+   object is defined.  Therefore, the use of an IMPORTS statement, to
+   specify from where such objects are imported, is redundant and is not
+   required in an information module.
+
+6.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 9 of [2] for more information on refined syntax.
+
+6.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 9 of [2] for more information on refined syntax.
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 18]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+6.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 or
+   notification named in the correspondent VARIATION clause.
+
+   The only value applicable to notifications is "not-implemented".
+
+   The value "not-implemented" indicates the agent does not implement
+   the object or notification, 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".
+
+6.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 [5].)
+
+   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 [6,7]), 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".
+
+
+
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 19]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+6.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.
+
+6.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 of the object or notification.
+
+6.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 sysORID [3] for which
+   this capabilities statement is valid.
+
+6.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             SNMPv2-MIB
+        INCLUDES         { systemGroup, snmpGroup, snmpSetGroup,
+                           snmpBasicNotificationsGroup }
+
+        VARIATION        coldStart
+            DESCRIPTION  "A coldStart trap is generated on all
+                         reboots."
+
+    SUPPORTS             IF-MIB
+        INCLUDES         { ifGeneralGroup, ifPacketGroup }
+
+        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"
+
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 20]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+    SUPPORTS             IP-MIB
+        INCLUDES         { ipGroup, icmpGroup }
+
+        VARIATION        ipDefaultTTL
+            SYNTAX       INTEGER (255..255)
+            DESCRIPTION  "Hard-wired on 4BSD"
+
+        VARIATION        ipInAddrErrors
+            ACCESS       not-implemented
+            DESCRIPTION  "Information not available on 4BSD"
+
+        VARIATION        ipNetToMediaEntry
+            CREATION-REQUIRES { ipNetToMediaPhysAddress }
+            DESCRIPTION  "Address mappings on 4BSD require
+                         both protocol and media addresses"
+
+    SUPPORTS             TCP-MIB
+        INCLUDES         { tcpGroup }
+        VARIATION        tcpConnState
+            ACCESS       read-only
+            DESCRIPTION  "Unable to set this on 4BSD"
+
+    SUPPORTS             UDP-MIB
+        INCLUDES         { udpGroup }
+
+    SUPPORTS             EVAL-MIB
+        INCLUDES         { functionsGroup, expressionsGroup }
+        VARIATION        exprEntry
+            CREATION-REQUIRES { evalString }
+            DESCRIPTION "Conceptual row creation supported"
+
+    ::= { acmeAgents 1 }
+
+   According to this invocation, an agent with a sysORID value of
+
+     { acmeAgents 1 }
+
+   supports six MIB modules.
+
+   From SNMPv2-MIB, five conformance groups are supported.
+
+   From IF-MIB, the ifGeneralGroup and ifPacketGroup groups are
+   supported.  However, the objects ifAdminStatus and ifOperStatus have
+   a restricted syntax.
+
+
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 21]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+   From IP-MIB, all objects in the ipGroup and icmpGroup are supported
+   except ipInAddrErrors, while ipDefaultTTL has a restricted range, and
+   when creating a new instance in the ipNetToMediaTable, the set-
+   request must create an instance of atPhysAddress.
+
+   From TCP-MIB, the tcpGroup is supported except that tcpConnState is
+   available only for reading.
+
+   From UDP-MIB, the udpGroup is fully supported.
+
+   From the EVAL-MIB, all the objects contained in the functionsGroup
+   and expressionsGroup conformance groups are supported, without
+   variation.  In addition, creation of new instances in the expr table
+   is supported.
+
+7.  Extending an Information Module
+
+   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 an information
+   module.  The remainder of this section defines how conformance
+   groups, compliance statements, and capabilities statements may be
+   extended.
+
+7.1.  Conformance Groups
+
+   If any non-editorial change is made to any clause of an object group
+   then the OBJECT IDENTIFIER value associated with that object group
+   must also be changed, along with its associated descriptor.
+
+7.2.  Compliance Definitions
+
+   If any non-editorial change is made to any clause of a compliance
+   definition, then the OBJECT IDENTIFIER value associated with that
+   compliance definition must also be changed, along with its associated
+   descriptor.
+
+7.3.  Capabilities Definitions
+
+   If any non-editorial change is made to any clause of a capabilities
+   definition, then the OBJECT IDENTIFIER value associated with that
+   capabilities definition must also be changed, along with its
+   associated descriptor.
+
+
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 22]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+8.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+9.  Editor's Address
+
+   Keith McCloghrie
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA  95134-1706
+   US
+
+   Phone: +1 408 526 5260
+   EMail: kzm@cisco.com
+
+10.  Acknowledgements
+
+   This document is the result of significant work by the four major
+   contributors:
+
+   Jeffrey D. Case (SNMP Research, case@snmp.com)
+   Keith McCloghrie (Cisco Systems, kzm@cisco.com)
+   Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
+   Steven Waldbusser (International Network Services, stevew@uni.ins.com)
+
+   In addition, the contributions of the SNMPv2 Working Group are
+   acknowledged.  In particular, a special thanks is extended for the
+   contributions of:
+
+     Alexander I. Alten (Novell)
+     Dave Arneson (Cabletron)
+     Uri Blumenthal (IBM)
+     Doug Book (Chipcom)
+     Kim Curran (Bell-Northern Research)
+     Jim Galvin (Trusted Information Systems)
+     Maria Greene (Ascom Timeplex)
+     Iain Hanson (Digital)
+     Dave Harrington (Cabletron)
+     Nguyen Hien (IBM)
+     Jeff Johnson (Cisco Systems)
+     Michael Kornegay (Object Quest)
+     Deirdre Kostick (AT&T Bell Labs)
+     David Levi (SNMP Research)
+     Daniel Mahoney (Cabletron)
+     Bob Natale (ACE*COMM)
+     Brian O'Keefe (Hewlett Packard)
+     Andrew Pearson (SNMP Research)
+     Dave Perkins (Peer Networks)
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 23]
+
+RFC 1904           Conformance Statements for SNMPv2        January 1996
+
+
+     Randy Presuhn (Peer Networks)
+     Aleksey Romanov (Quality Quorum)
+     Shawn Routhier (Epilogue)
+     Jon Saperia (BGS Systems)
+     Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
+     Kaj Tesink (Bellcore)
+     Glenn Waters (Bell-Northern Research)
+     Bert Wijnen (IBM)
+
+11.  References
+
+[1]  Information processing systems - Open Systems Interconnection -
+     Specification of Abstract Syntax Notation One (ASN.1),
+     International Organization for Standardization.  International
+     Standard 8824, (December, 1987).
+
+[2]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Structure of Management Information for Version 2
+     of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
+     January 1996.
+
+[3]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Management Information Base for Version 2 of the
+     Simple Network Management Protocol (SNMPv2)", RFC 1907,
+     January 1996.
+
+[4]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Protocol Operations for Version 2 of the Simple
+     Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
+
+[5]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Textual Conventions for Version 2 of the Simple
+     Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
+
+[6]  Rose, M., and K. McCloghrie, "Structure and Identification of
+     Management Information for TCP/IP-based internets", STD 16, RFC
+     1155, May 1990.
+
+[7]  Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
+     RFC 1212, March 1991.
+
+
+
+
+
+
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 24]
+