summaryrefslogtreecommitdiff
path: root/cleopatre/application/spidnetsnmp/doc/rfc/smiV2/rfc2580.txt
diff options
context:
space:
mode:
Diffstat (limited to 'cleopatre/application/spidnetsnmp/doc/rfc/smiV2/rfc2580.txt')
-rw-r--r--cleopatre/application/spidnetsnmp/doc/rfc/smiV2/rfc2580.txt1710
1 files changed, 0 insertions, 1710 deletions
diff --git a/cleopatre/application/spidnetsnmp/doc/rfc/smiV2/rfc2580.txt b/cleopatre/application/spidnetsnmp/doc/rfc/smiV2/rfc2580.txt
deleted file mode 100644
index 7334b4195e..0000000000
--- a/cleopatre/application/spidnetsnmp/doc/rfc/smiV2/rfc2580.txt
+++ /dev/null
@@ -1,1710 +0,0 @@
-
-
-
-
-
-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]
-