doc: Add RFC documents

1 files changed, 1710 insertions, 0 deletions

diff --git a/doc/rfc/rfc2580.txt b/doc/rfc/rfc2580.txt
new file mode 100644
index 0000000..7334b41
--- /dev/null
+++ b/doc/rfc/rfc2580.txt
@@ -0,0 +1,1710 @@
+
+
+
+
+
+Network Working Group                 Editors of this version:
+Request for Comments: 2580                                 K. McCloghrie
+STD: 58                                                    Cisco Systems
+Obsoletes: 1904                                               D. Perkins
+Category: Standards Track                                       SNMPinfo
+                                                        J. Schoenwaelder
+                                                         TU Braunschweig
+                                      Authors of previous version:
+                                                                 J. Case
+                                                           SNMP Research
+                                                           K. McCloghrie
+                                                           Cisco Systems
+                                                                 M. Rose
+                                                  First Virtual Holdings
+                                                           S. Waldbusser
+                                          International Network Services
+                                                              April 1999
+
+
+
+                    Conformance Statements for SMIv2
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+
+Table of Contents
+
+   1 Introduction .....................................................3
+   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 ...............................10
+   3.1 Mapping of the OBJECTS clause .................................10
+   3.2 Mapping of the STATUS clause ..................................11
+   3.3 Mapping of the DESCRIPTION clause .............................11
+   3.4 Mapping of the REFERENCE clause ...............................11
+
+
+
+McCloghrie, et al.          Standards Track                     [Page 1]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+   3.5 Mapping of the OBJECT-GROUP value .............................11
+   3.6 Usage Example .................................................12
+   4 Mapping of the NOTIFICATION-GROUP macro .........................12
+   4.1 Mapping of the NOTIFICATIONS clause ...........................12
+   4.2 Mapping of the STATUS clause ..................................13
+   4.3 Mapping of the DESCRIPTION clause .............................13
+   4.4 Mapping of the REFERENCE clause ...............................13
+   4.5 Mapping of the NOTIFICATION-GROUP value .......................13
+   4.6 Usage Example .................................................13
+   5 Mapping of the MODULE-COMPLIANCE macro ..........................14
+   5.1 Mapping of the STATUS clause ..................................14
+   5.2 Mapping of the DESCRIPTION clause .............................14
+   5.3 Mapping of the REFERENCE clause ...............................15
+   5.4 Mapping of the MODULE clause ..................................15
+   5.4.1 Mapping of the MANDATORY-GROUPS clause ......................15
+   5.4.2 Mapping of the GROUP clause .................................15
+   5.4.3 Mapping of the OBJECT clause ................................16
+   5.4.3.1 Mapping of the SYNTAX clause ..............................16
+   5.4.3.2 Mapping of the WRITE-SYNTAX clause ........................16
+   5.4.3.3 Mapping of the MIN-ACCESS clause ..........................16
+   5.4.4 Mapping of the DESCRIPTION clause ...........................17
+   5.5 Mapping of the MODULE-COMPLIANCE value ........................17
+   5.6 Usage Example .................................................17
+   6 Mapping of the AGENT-CAPABILITIES macro .........................19
+   6.1 Mapping of the PRODUCT-RELEASE clause .........................19
+   6.2 Mapping of the STATUS clause ..................................19
+   6.3 Mapping of the DESCRIPTION clause .............................20
+   6.4 Mapping of the REFERENCE clause ...............................20
+   6.5 Mapping of the SUPPORTS clause ................................20
+   6.5.1 Mapping of the INCLUDES clause ..............................20
+   6.5.2 Mapping of the VARIATION clause .............................20
+   6.5.2.1 Mapping of the SYNTAX clause ..............................21
+   6.5.2.2 Mapping of the WRITE-SYNTAX clause ........................21
+   6.5.2.3 Mapping of the ACCESS clause ..............................21
+   6.5.2.4 Mapping of the CREATION-REQUIRES clause ...................22
+   6.5.2.5 Mapping of the DEFVAL clause ..............................22
+   6.5.2.6 Mapping of the DESCRIPTION clause .........................22
+   6.6 Mapping of the AGENT-CAPABILITIES value .......................22
+   6.7 Usage Example .................................................23
+   7 Extending an Information Module .................................25
+   7.1 Conformance Groups ............................................25
+   7.2 Compliance Definitions ........................................26
+   7.3 Capabilities Definitions ......................................26
+   8 Security Considerations .........................................27
+   9 Editors' Addresses ..............................................27
+   10 References .....................................................28
+   11 Full Copyright Statement .......................................29
+
+
+McCloghrie, et al.          Standards Track                     [Page 2]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+1.  Introduction
+
+   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 an adapted subset of
+   OSI's Abstract Syntax Notation One, ASN.1 (1988) [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 Structure of Management
+   Information, as described in RFCs 1156 (STD 16), 1212 (STD 16), and
+   RFC 1215, is termed the SMI version 1 (SMIv1).  The current version
+   of the Structure of Management Information is termed SMI version 2
+   (SMIv2).
+
+2.  Definitions
+
+SNMPv2-CONF DEFINITIONS ::= BEGIN
+
+IMPORTS ObjectName, NotificationName, ObjectSyntax
+                                               FROM SNMPv2-SMI;
+
+-- 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 ::=
+
+
+McCloghrie, et al.          Standards Track                     [Page 3]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+                  value(ObjectName)
+
+    Status ::=
+                  "current"
+                | "deprecated"
+                | "obsolete"
+
+    ReferPart ::=
+                  "REFERENCE" Text
+                | empty
+
+    -- a character string as defined in [2]
+    Text ::= value(IA5String)
+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(NotificationName)
+
+    Status ::=
+                  "current"
+                | "deprecated"
+                | "obsolete"
+
+    ReferPart ::=
+                  "REFERENCE" Text
+                | empty
+
+    -- a character string as defined in [2]
+    Text ::= value(IA5String)
+END
+
+
+McCloghrie, et al.          Standards Track                     [Page 4]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+-- 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
+    Modules ::=
+                  Module
+                | Modules Module
+    Module ::=
+                  -- name of module --
+                  "MODULE" ModuleName
+                  MandatoryPart
+                  CompliancePart
+
+    ModuleName ::=
+                  -- identifier must start with uppercase letter
+                  identifier ModuleIdentifier
+                  -- must not be empty unless contained
+                  -- in MIB Module
+                | empty
+    ModuleIdentifier ::=
+                  value(OBJECT IDENTIFIER)
+                | empty
+
+    MandatoryPart ::=
+                  "MANDATORY-GROUPS" "{" Groups "}"
+                | empty
+
+    Groups ::=
+
+
+McCloghrie, et al.          Standards Track                     [Page 5]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+                  Group
+                | Groups "," Group
+    Group ::=
+                  value(OBJECT IDENTIFIER)
+
+    CompliancePart ::=
+                  Compliances
+                | empty
+
+    Compliances ::=
+                  Compliance
+                | Compliances Compliance
+    Compliance ::=
+                  ComplianceGroup
+                | Object
+
+    ComplianceGroup ::=
+                  "GROUP" value(OBJECT IDENTIFIER)
+                  "DESCRIPTION" Text
+
+    Object ::=
+                  "OBJECT" value(ObjectName)
+                  SyntaxPart
+                  WriteSyntaxPart
+                  AccessPart
+                  "DESCRIPTION" Text
+
+    -- must be a refinement for object's SYNTAX clause
+    SyntaxPart ::= "SYNTAX" Syntax
+                | empty
+
+    -- must be a refinement for object's SYNTAX clause
+    WriteSyntaxPart ::= "WRITE-SYNTAX" Syntax
+                | empty
+
+    Syntax ::=    -- Must be one of the following:
+                       -- a base type (or its refinement),
+                       -- a textual convention (or its refinement), or
+                       -- a BITS pseudo-type
+                  type
+                | "BITS" "{" NamedBits "}"
+
+    NamedBits ::= NamedBit
+                | NamedBits "," NamedBit
+
+    NamedBit ::= identifier "(" number ")" -- number is nonnegative
+
+    AccessPart ::=
+
+
+McCloghrie, et al.          Standards Track                     [Page 6]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+                  "MIN-ACCESS" Access
+                | empty
+    Access ::=
+                  "not-accessible"
+                | "accessible-for-notify"
+                | "read-only"
+                | "read-write"
+                | "read-create"
+
+    -- a character string as defined in [2]
+    Text ::= value(IA5String)
+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 ::=
+
+
+McCloghrie, et al.          Standards Track                     [Page 7]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+                  -- identifier must start with uppercase letter
+                  identifier ModuleIdentifier
+    ModuleIdentifier ::=
+                  value(OBJECT IDENTIFIER)
+                | empty
+
+    Groups ::=
+                  Group
+                | Groups "," Group
+    Group ::=
+                  value(OBJECT IDENTIFIER)
+
+    VariationPart ::=
+                  Variations
+                | empty
+    Variations ::=
+                  Variation
+                | Variations Variation
+
+    Variation ::=
+                  ObjectVariation
+                | NotificationVariation
+
+    NotificationVariation ::=
+                  "VARIATION" value(NotificationName)
+                  AccessPart
+                  "DESCRIPTION" Text
+
+    ObjectVariation ::=
+                  "VARIATION" value(ObjectName)
+                  SyntaxPart
+                  WriteSyntaxPart
+                  AccessPart
+                  CreationPart
+                  DefValPart
+                  "DESCRIPTION" Text
+
+    -- must be a refinement for object's SYNTAX clause
+    SyntaxPart ::= "SYNTAX" Syntax
+                | empty
+
+    WriteSyntaxPart ::= "WRITE-SYNTAX" Syntax
+                | empty
+
+    Syntax ::=    -- Must be one of the following:
+                       -- a base type (or its refinement),
+                       -- a textual convention (or its refinement), or
+                       -- a BITS pseudo-type
+
+
+McCloghrie, et al.          Standards Track                     [Page 8]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+                  type
+                | "BITS" "{" NamedBits "}"
+
+    NamedBits ::= NamedBit
+                | NamedBits "," NamedBit
+
+    NamedBit ::= identifier "(" number ")" -- number is nonnegative
+
+    AccessPart ::=
+                  "ACCESS" Access
+                | empty
+
+    Access ::=
+                  "not-implemented"
+                -- only "not-implemented" for notifications
+                | "accessible-for-notify"
+                | "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(ObjectName)
+
+    DefValPart ::= "DEFVAL" "{" Defvalue "}"
+                | empty
+
+    Defvalue ::=  -- must be valid for the object's syntax
+                  -- in this macro's SYNTAX clause, if present,
+                  -- or if not, in object's OBJECT-TYPE macro
+                  value(ObjectSyntax)
+                | "{" BitsValue "}"
+
+    BitsValue ::= BitNames
+                | empty
+
+    BitNames ::=  BitName
+                | BitNames "," BitName
+
+    BitName ::= identifier
+
+
+
+McCloghrie, et al.          Standards Track                     [Page 9]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+    -- a character string as defined in [2]
+    Text ::= value(IA5String)
+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, an agent 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, an agent must accordingly be able to reasonably influence
+   the underlying managed entity.  If an agent can not implement an
+   object, the management protocol provides for it to return an
+   exception or error, e.g, noSuchObject [4].  Under no circumstances
+   shall an agent 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].
+
+   Note that the OBJECT-GROUP macro itself provides no conformance
+   information.  Rather, conformance information is specified through
+   the inclusion of defined groups in a MODULE-COMPLIANCE macro.
+
+3.1.  Mapping of the OBJECTS clause
+
+   The OBJECTS clause, which must be present, is used to specify each
+   object contained in the conformance group.  Each of the specified
+   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.
+
+
+
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 10]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+3.2.  Mapping of the STATUS clause
+
+   The STATUS clause, which must be present, indicates whether this
+   definition is current or historic.
+
+   The value "current" means that the definition is current and valid.
+   The value "obsolete" means the definition is obsolete and the group
+   should no longer be used for defining conformance.  While the value
+   "deprecated" also indicates an obsolete definition, it permits
+   new/continued use of conformance definitions using this group.
+
+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 some other document, either another information
+   module which defines a related assignment, or some other document
+   which provides additional information relevant to this definition.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 11]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+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 agent."
+      ::= { 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 specify
+   each notification contained in the conformance group.  Each of the
+   specified notifications must be defined in the same information
+   module as the NOTIFICATION-GROUP macro appears.
+
+   It is required that every notification defined in an information
+   module be contained in at least one notification group.
+
+
+
+
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 12]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+4.2.  Mapping of the STATUS clause
+
+   The STATUS clause, which must be present, indicates whether this
+   definition is current or historic.
+
+   The value "current" means that the definition is current and valid.
+   The value "obsolete" means the definition is obsolete and this group
+   should no longer be used for defining conformance.  While the value
+   "deprecated" also indicates an obsolete definition, it permits
+   new/continued use of conformance definitions using this group.
+
+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 some other document, either another information
+   module which defines a related assignment, or some other document
+   which provides additional information relevant to this definition.
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 13]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+   snmpBasicNotificationsGroup NOTIFICATION-GROUP
+       NOTIFICATIONS { coldStart, authenticationFailure }
+       STATUS        current
+       DESCRIPTION
+               "The two notifications which an agent is required to
+               implement."
+      ::= { snmpMIBGroups 7 }
+
+   According to this invocation, the conformance group named
+
+        { snmpMIBGroups 7 }
+
+   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.
+
+   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 value "current" means that the definition is current and valid.
+   The value "obsolete" means the definition is obsolete, and this
+   MODULE-COMPLIANCE specification no longer specifies a valid
+   definition of conformance.  While the value "deprecated" also
+   indicates an obsolete definition, it permits new/continued use of the
+   MODULE-COMPLIANCE specification.
+
+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.
+
+
+
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 14]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+5.3.  Mapping of the REFERENCE clause
+
+   The REFERENCE clause, which need not be present, contains a textual
+   cross-reference to some other document, either another information
+   module which defines a related assignment, or some other document
+   which provides additional information relevant to this definition.
+
+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 an
+   agent claims compliance to the MIB module, then it must implement
+   each and every object and notification within each conformance group
+   listed.  That is, if an agent returns a noSuchObject exception in
+   response to a management protocol get operation [4] for any object
+   within any mandatory conformance group for every possible MIB view,
+   or if the agent cannot generate each notification listed in any
+   conformance group under the appropriate circumstances, then that
+   agent 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 for compliance to the MIB module.  The GROUP clause can
+   also be used to name unconditionally optional groups.  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.
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 15]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+5.4.3.  Mapping of the OBJECT clause
+
+   The OBJECT clause, which need not be present, is repeatedly used to
+   specify 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.
+
+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
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 16]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+   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.
+
+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 }
+
+
+McCloghrie, et al.          Standards Track                    [Page 17]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 18]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+6.  Mapping of the AGENT-CAPABILITIES macro
+
+   The AGENT-CAPABILITIES macro is used to convey a set of capabilities
+   present in an agent.  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 an agent claims to implement a group, then it must
+   implement each and every object, or each and every notification,
+   within that group.  Of course, for whatever reason, an agent might
+   implement only a subset of the groups within a MIB module.  In
+   addition, the definition of some MIB objects/notifications 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 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
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 19]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+   definition is current or historic.
+
+   The value "current" means that the definition is current and valid.
+   The value "obsolete" means the definition is obsolete and this
+   capabilities statement is no longer in use.
+
+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 some other document, either another information
+   module which defines a related assignment, or some other document
+   which provides additional information relevant to this definition.
+
+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 registered by the
+   MODULE-IDENTITY macro, see [2]) as well.
+
+6.5.1.  Mapping of the INCLUDES clause
+
+   The INCLUDES clause, which must follow each and every 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
+
+
+McCloghrie, et al.          Standards Track                    [Page 20]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+   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.
+
+   Note that for enumerated INTEGERs and for the BITS construct, the
+   changes allowed when updating a MIB module include the addition of
+   enumerations and/or changing the labels of existing enumerations (see
+   Section 10.2 of [2]).  This type of change can cause problems for an
+   AGENT-CAPABILITIES macro written against the old revision of a MIB
+   module.  One way to avoid such problems is to explicitly list all
+   objects having an enumerated syntax in a VARIATION clause, even when
+   all enumerations are currently supported.
+
+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.
+
+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".
+
+
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 21]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+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 be 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".
+
+6.5.2.5.  Mapping of the DEFVAL clause
+
+   The DEFVAL clause, which need not be present, is used to provide a
+   alternate 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.
+
+
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 22]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+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."
+
+       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
+
+
+McCloghrie, et al.          Standards Track                    [Page 23]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+               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, evalStatus }
+               DESCRIPTION  "Conceptual row creation is supported."
+
+       ::= { acmeAgents 1 }
+
+
+   According to this invocation, an agent with a sysORID value of
+
+        { acmeAgents 1 }
+
+   supports objects defined in 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.
+
+   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 ipNetToMediaPhysAddress.
+
+   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, and requires both of the objects:  evalString and
+   evalStatus, to be assigned a value.
+
+
+
+
+
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 24]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+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
+
+   It may be desirable to revise the definition of a conformance group
+   (an OBJECT-GROUP or a NOTIFICATION-GROUP) after experience is gained
+   with it.  However, conformance groups can be referenced by compliance
+   and/or capabilities definitions.  Therefore, a change to a
+   conformance group is not allowed if it has the potential to cause a
+   reference to the group's original definition to be different from a
+   reference to the updated definition.  Such changes can only be
+   accommodated by defining a new conformance group with a new
+   descriptor and a new OBJECT IDENTIFIER value.
+
+   The following revisions are allowed:
+
+(1)  A STATUS clause value of "current" may be revised as "deprecated"
+     or "obsolete".  Similarly, a STATUS clause value of "deprecated"
+     may be revised as "obsolete".  When making such a change, the
+     DESCRIPTION clause should be updated to explain the rationale.
+
+(2)  A REFERENCE clause may be added or updated.
+
+(3)  Clarifications and additional information may be included in the
+     DESCRIPTION clause.
+
+(4)  Any editorial change.
+
+   It is not necessary to change the STATUS value of a conformance group
+   when the status of a member of the group is changed.
+
+7.2.  Compliance Definitions
+
+   It may be desirable to revise the definition of a compliance
+   definition (MODULE-COMPLIANCE) after experience is gained with it.
+   However, changes are not allowed if they cause the requirements
+   specified by the original definition to be different from the
+   requirements of the updated definition.  Such changes can only be
+   accommodated by defining a new compliance definition with a new
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 25]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+   descriptor and a new OBJECT IDENTIFIER value.
+
+   The following revisions are allowed:
+
+(1)  A STATUS clause value of "current" may be revised as "deprecated"
+     or "obsolete".  Similarly, a STATUS clause value of "deprecated"
+     may be revised as "obsolete".  When making such a change, the
+     DESCRIPTION clause should be updated to explain the rationale.
+
+(2)  A REFERENCE clause may be added or updated.
+
+(3)  Clarifications and additional information may be included in the
+     DESCRIPTION clause(s).
+
+(4)  Any editorial change.
+
+   It is not necessary to change the STATUS value of a compliance
+   definition due to a change in the STATUS value of a definition it
+   references.
+
+7.3.  Capabilities Definitions
+
+   It may be desirable to revise the definition of a capabilities
+   definition (AGENT-CAPABILITIES) after experience is gained with it.
+   However, changes are not allowed if they cause the capabilities
+   specified by the original specification to be different from the
+   capabilities of the updated specification.  Such changes can only be
+   accommodated by defining a new capabilities definition with a new
+   descriptor and a new OBJECT IDENTIFIER value.
+
+   The following revisions are allowed:
+
+(1)  A STATUS clause value of "current" may be revised as "obsolete".
+     When making such a change, the DESCRIPTION clause should be updated
+     to explain the rationale.
+
+(2)  A REFERENCE clause may be added or updated.
+
+(3)  Clarifications and additional information may be included in the
+     DESCRIPTION clause(s).
+
+(4)  Any editorial change.
+
+   It is not necessary to change the STATUS value of a capabilities
+   definition due to a change in the STATUS value of a definition it
+   references.
+
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 26]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+8.  Security Considerations
+
+   This document defines the means to define conformance requirements
+   for implementing on documents describing management information.
+   This method of defining conformance requirements has no security
+   impact on the Internet.
+
+
+9.  Editors' Addresses
+
+   Keith McCloghrie
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA  95134-1706
+   USA
+   Phone: +1 408 526 5260
+   EMail: kzm@cisco.com
+
+   David Perkins
+   SNMPinfo
+   3763 Benton Street
+   Santa Clara, CA 95051
+   USA
+   Phone: +1 408 221-8702
+   Email: dperkins@snmpinfo.com
+
+   Juergen Schoenwaelder
+   TU Braunschweig
+   Bueltenweg 74/75
+   38106 Braunschweig
+   Germany
+   Phone: +49 531 391-3283
+   EMail: schoenw@ibr.cs.tu-bs.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 27]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+10.  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]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
+     and S. Waldbusser, "Structure of Management Information Version 2
+     (SMIv2)", STD 58, RFC 2578, April 1999.
+
+[3]  The 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]  The 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]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
+     and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
+     RFC 2579, April 1999.
+
+[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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 28]
+
+
+
+
+
+RFC 2580            Conformance Statements for SMIv2          April 1999
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCloghrie, et al.          Standards Track                    [Page 29]
+