From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1908.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc1908.txt (limited to 'doc/rfc/rfc1908.txt') diff --git a/doc/rfc/rfc1908.txt b/doc/rfc/rfc1908.txt new file mode 100644 index 0000000..b925831 --- /dev/null +++ b/doc/rfc/rfc1908.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group SNMPv2 Working Group +Request for Comments: 1908 J. Case +Obsoletes: 1452 SNMP Research, Inc. +Category: Standards Track K. McCloghrie + Cisco Systems, Inc. + M. Rose + Dover Beach Consulting, Inc. + S. Waldbusser + International Network Services + January 1996 + + + Coexistence between Version 1 and Version 2 of the + Internet-standard Network Management Framework + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Table of Contents + + 1. Introduction ................................................ 2 + 2. Management Information ...................................... 2 + 2.1 Object Definitions ......................................... 3 + 2.2 Trap Definitions ........................................... 5 + 2.3 Compliance Statements ...................................... 5 + 2.4 Capabilities Statements .................................... 6 + 3 Protocol Operations .......................................... 6 + 3.1 Proxy Agent Behavior ....................................... 6 + 3.1.1 SNMPv2 -> SNMPv1 ......................................... 7 + 3.1.2 SNMPv1 -> SNMPv2 ......................................... 7 + 3.2 Bi-lingual Manager Behavior ................................ 8 + 4. Security Considerations ..................................... 8 + 5. Editor's Address ............................................ 8 + 6. Acknowledgements ............................................ 8 + 7. References .................................................. 9 + + + + + + + + + + + +SNMPv2 Working Group Standards Track [Page 1] + +RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 + + +1. Introduction + + The purpose of this document is to describe coexistence between + version 2 of the Internet-standard Network Management Framework [1- + 6], termed the SNMP version 2 framework (SNMPv2), and the original + Internet-standard Network Management Framework (SNMPv1), which + consists of these three documents: + + STD 16, RFC 1155 [7] which defines the Structure of Management + Information (SMI), the mechanisms used for describing and naming + objects for the purpose of management. + + STD 16, RFC 1212 [8] which defines a more concise description + mechanism, which is wholly consistent with the SMI. + + STD 15, RFC 1157 [9] which defines the Simple Network Management + Protocol (SNMP), the protocol used for network access to managed + objects. + +2. Management Information + + The SNMPv2 approach towards describing collections of managed objects + is nearly a proper superset of the approach defined in the Internet- + standard Network Management Framework. For example, both approaches + use ASN.1 [10] as the basis for a formal descriptive notation. + Indeed, one might note that the SNMPv2 approach largely codifies the + existing practice for defining MIB modules, based on extensive + experience with the current framework. + + The SNMPv2 documents which deal with information modules are: + + Structure of Management Information for SNMPv2 [1], which defines + concise notations for describing information modules, managed + objects and notifications; + + Textual Conventions for SNMPv2 [2], which defines a concise + notation for describing textual conventions, and also defines some + initial conventions; and, + + Conformance Statements for SNMPv2 [3], which defines concise + notation for describing compliance and capabilities statements. + + The following sections consider the three areas: MIB modules, + compliance statements, and capabilities statements. + + MIB modules defined using the current framework may continue to be + used with the SNMPv2 protocol. However, for the MIB modules to + conform to the SNMPv2 framework, the following changes are required: + + + +SNMPv2 Working Group Standards Track [Page 2] + +RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 + + +2.1. Object Definitions + + In general, conversion of a MIB module does not require the + deprecation of the objects contained therein. Only if the semantics + of an object truly changes should deprecation be performed. + +(1) The IMPORTS statement must reference SNMPv2-SMI, instead of + RFC1155-SMI and RFC-1212. + +(2) The MODULE-IDENTITY macro must be invoked immediately after any + IMPORTs statement. + +(3) For any descriptor which contains the hyphen character, the hyphen + character is removed. + +(4) For any label for a named-number enumeration which contains the + hyphen character, the hyphen character is removed. + +(5) For any object with an integer-valued SYNTAX clause, in which the + corresponding INTEGER does not have a range restriction (i.e., the + INTEGER has neither a defined set of named-number enumerations nor + an assignment of lower- and upper-bounds on its value), the object + must have the value of its SYNTAX clause changed to Integer32. + +(6) For any object with a SYNTAX clause value of an enumerated INTEGER, + the hyphen character is removed from any named-number labels which + contain the hyphen character. + +(7) For any object with a SYNTAX clause value of Counter, the object + must have the value of its SYNTAX clause changed to Counter32. + +(8) For any object with a SYNTAX clause value of Gauge, the object must + have the value of its SYNTAX clause changed to Gauge32. + +(9) For all objects, the ACCESS clause must be replaced by a MAX-ACCESS + clause. The value of the MAX-ACCESS clause is the same as that of + the ACCESS clause unless some other value makes "protocol sense" as + the maximal level of access for the object. In particular, object + types for which instances can be explicitly created by a protocol + set operation, will have a MAX-ACCESS clause of "read-create". If + the value of the ACCESS clause is "write-only", then the value of + the MAX-ACCESS clause is "read-write", and the DESCRIPTION clause + notes that reading this object will result implementation-specific + results. + +(10) For all objects, if the value of the STATUS clause is "mandatory", + the value must be replaced with "current". + + + + +SNMPv2 Working Group Standards Track [Page 3] + +RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 + + +(11) For all objects, if the value of the STATUS clause is "optional", + the value must be replaced with "obsolete". + +(12) For any object not containing a DESCRIPTION clause, the object must + have a DESCRIPTION clause defined. + +(13) For any object corresponding to a conceptual row which does not + have an INDEX clause, the object must have either an INDEX clause + or an AUGMENTS clause defined. + +(14) For any object with an INDEX clause that references an object with + a syntax of NetworkAddress, the value of the STATUS clause of both + objects is changed to "obsolete". + +(15) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER + value which is expressed as a collection of sub-identifiers, change + the value to reference a single ASN.1 identifier. + +Other changes are desirable, but not necessary: + +(1) Creation and deletion of conceptual rows is inconsistent using the + current framework. The SNMPv2 framework corrects this. As such, + if the MIB module undergoes review early in its lifetime, and it + contains conceptual tables which allow creation and deletion of + conceptual rows, then it may be worthwhile to deprecate the objects + relating to those tables and replace them with objects defined + using the new approach. + +(2) For any object with a string-valued SYNTAX clause, in which the + corresponding OCTET STRING does not have a size restriction (i.e., + the OCTET STRING has no assignment of lower- and upper-bounds on + its length), one might consider defining the bounds for the size of + the object. + +(3) For all textual conventions informally defined in the MIB module, + one might consider redefining those conventions using the TEXTUAL- + CONVENTION macro. Such a change would not necessitate deprecating + objects previously defined using an informal textual convention. + +(4) For any object which represents a measurement in some kind of + units, one might consider adding a UNITS clause to the definition + of that object. + +(5) For any conceptual row which is an extension of another conceptual + row, i.e., for which subordinate columnar objects both exist and + are identified via the same semantics as the other conceptual row, + one might consider using an AUGMENTS clause in place of the INDEX + clause for the object corresponding to the conceptual row which is + + + +SNMPv2 Working Group Standards Track [Page 4] + +RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 + + + an extension. + +Finally, when encountering common errors in SNMPv1 MIB modules: + +(1) For any non-columnar object that is instanced as if it were + immediately subordinate to a conceptual row, the value of the + STATUS clause of that object is changed to "obsolete". + +(2) For any conceptual row object that is not contained immediately + subordinate to a conceptual table, the value of the STATUS clause + of that object (and all subordinate objects) is changed to + "obsolete". + +2.2. Trap Definitions + + If a MIB module is changed to conform to the SNMPv2 framework, then + each occurrence of the TRAP-TYPE macro must be changed to a + corresponding invocation of the NOTIFICATION-TYPE macro: + + (1) The IMPORTS statement must not reference RFC-1215. + + (2) The ENTERPRISES clause must be removed. + + (3) The VARIABLES clause must be renamed to the OBJECTS clause. + + (4) The STATUS clause must be added. + + (5) The value of an invocation of the NOTIFICATION-TYPE macro is an + OBJECT IDENTIFIER, not an INTEGER, and must be changed accordingly. + Specifically, if the value of the ENTERPRISE clause is not 'snmp' + then the value of the invocation is the value of the ENTERPRISE + clause extended with two sub-identifiers, the first of which has + the value 0, and the second has the value of the invocation of the + TRAP-TYPE. + +2.3. Compliance Statements + + For those information modules which are "standard", a corresponding + invocation of the MODULE-COMPLIANCE macro must be included within the + information module (or in a companion information module), and any + commentary text in the information module which relates to compliance + must be removed. Typically this editing can occur when the + information module undergoes review. + + + + + + + + +SNMPv2 Working Group Standards Track [Page 5] + +RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 + + +2.4. Capabilities Statements + + In the current framework, the informational document [11] uses the + MODULE-CONFORMANCE macro to describe an agent's capabilities with + respect to one or more MIB modules. Converting such a description + for use with the SNMPv2 framework requires these changes: + + (1) Use the macro name AGENT-CAPABILITIES instead of MODULE- + CONFORMANCE. + + (2) The STATUS clause must be added. + + (3) For all occurrences of the CREATION-REQUIRES clause, note the + slight change in semantics, and omit this clause if appropriate. + + In order to ease the coexistence between SNMPv1 and SNMPv2, object + groups defined in an SNMPv1 MIB module may be referenced by the + INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro: + upon encountering a reference to an OBJECT IDENTIFIER subtree defined + in an SNMPv1 MIB module, all leaf objects which are subordinate to + the subtree and have a STATUS clause value of mandatory are deemed to + be INCLUDEd. (Note that this method is ambiguous when different + revisions of a SNMPv1 MIB have different sets of mandatory objects + under the same subtree; in such cases, the only solution is to + rewrite the MIB using the SNMPv2 SMI in order to define the object + groups unambiguously.) + +3. Protocol Operations + + The SNMPv2 documents which deal with protocol operations are: + + Protocol Operations for SNMPv2 [4], which defines the syntax and + semantics of the operations conveyed by the protocol; and, + + Transport Mappings for SNMPv2 [5], which defines how the protocol + operations are carried over different transport services. + + The following section considers two areas: the proxy behavior + between a SNMPv2 entity and a SNMPv1 agent; and, the behavior of + "bi-lingual" protocol entities acting in a manager role. + +3.1. Proxy Agent Behavior + + To achieve coexistence at the protocol-level, a proxy mechanism may + be used. A SNMPv2 entity acting in an agent role may be implemented + and configured to act in the role of a proxy agent. + + + + + +SNMPv2 Working Group Standards Track [Page 6] + +RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 + + +3.1.1. SNMPv2 -> SNMPv1 + + When converting requests from a SNMPv2 entity acting in a manager + role into requests sent to a SNMPv1 entity acting in an agent role: + + (1) If a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU is + received, then it is passed unaltered by the proxy agent. + + (2) If a GetBulkRequest-PDU is received, the proxy agent sets the non- + repeaters and max-repetitions fields to zero, and sets the tag of + the PDU to GetNextRequest-PDU. + +3.1.2. SNMPv1 -> SNMPv2 + + When converting responses received from a SNMPv1 entity acting in an + agent role into responses sent to a SNMPv2 entity acting in a manager + role: + +(1) If a GetResponse-PDU is received, then it is passed unaltered by + the proxy agent. Note that even though a SNMPv2 entity will never + generate a Response-PDU with a error-status field having a value of + `noSuchName', `badValue', or `readOnly', the proxy agent must not + change this field. This allows the SNMPv2 entity acting in a + manager role to interpret the response correctly. + + If a GetResponse-PDU is received with an error-status field having + a value of `tooBig', the proxy agent will remove the contents of + the variable-bindings field before propagating the response. Note + that even though a SNMPv2 entity will never generate a `tooBig' in + response to a GetBulkRequest-PDU, the proxy agent must propagate + such a response. + +(2) If a Trap-PDU is received, then it is mapped into a SNMPv2-Trap- + PDU. This is done by prepending onto the variable-bindings field + two new bindings: sysUpTime.0 [6], which takes its value from the + timestamp field of the Trap-PDU; and, snmpTrapOID.0 [6], which is + calculated thusly: if the value of generic-trap field is + `enterpriseSpecific', then the value used is the concatenation of + the enterprise field from the Trap-PDU with two additional sub- + identifiers, `0', and the value of the specific-trap field; + otherwise, the value of the corresponding trap defined in [6] is + used. (For example, if the value of the generic-trap field is + `coldStart', then the coldStart trap [6] is used.) Then, one new + binding is appended onto the variable-bindings field: + snmpTrapEnterprise.0 [6], which takes its value from the enterprise + field of the Trap-PDU. The destinations for the SNMPv2-Trap-PDU + are determined in an implementation-dependent fashion by the proxy + agent. + + + +SNMPv2 Working Group Standards Track [Page 7] + +RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 + + +3.2. Bi-lingual Manager Behavior + + To achieve coexistence at the protocol-level, a protocol entity + acting in a manager role might support both SNMPv1 and SNMPv2. When + a management application needs to contact a protocol entity acting in + an agent role, the entity acting in a manager role consults a local + database to select the correct management protocol to use. + + In order to provide transparency to management applications, the + entity acting in a manager role must map operations as if it were + acting as a proxy agent. + +4. Security Considerations + + Security issues are not discussed in this memo. + +5. Editor's Address + + Keith McCloghrie + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + US + + Phone: +1 408 526 5260 + EMail: kzm@cisco.com + +6. Acknowledgements + + This document is the result of significant work by the four major + contributors: + + Jeffrey D. Case (SNMP Research, case@snmp.com) + Keith McCloghrie (Cisco Systems, kzm@cisco.com) + Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) + Steven Waldbusser (International Network Services, stevew@uni.ins.com) + + In addition, the contributions of the SNMPv2 Working Group are + acknowledged. In particular, a special thanks is extended for the + contributions of: + + Alexander I. Alten (Novell) + Dave Arneson (Cabletron) + Uri Blumenthal (IBM) + Doug Book (Chipcom) + Kim Curran (Bell-Northern Research) + Jim Galvin (Trusted Information Systems) + Maria Greene (Ascom Timeplex) + + + +SNMPv2 Working Group Standards Track [Page 8] + +RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 + + + Iain Hanson (Digital) + Dave Harrington (Cabletron) + Nguyen Hien (IBM) + Jeff Johnson (Cisco Systems) + Michael Kornegay (Object Quest) + Deirdre Kostick (AT&T Bell Labs) + David Levi (SNMP Research) + Daniel Mahoney (Cabletron) + Bob Natale (ACE*COMM) + Brian O'Keefe (Hewlett Packard) + Andrew Pearson (SNMP Research) + Dave Perkins (Peer Networks) + Randy Presuhn (Peer Networks) + Aleksey Romanov (Quality Quorum) + Shawn Routhier (Epilogue) + Jon Saperia (BGS Systems) + Bob Stewart (Cisco Systems, bstewart@cisco.com), chair + Kaj Tesink (Bellcore) + Glenn Waters (Bell-Northern Research) + Bert Wijnen (IBM) + +7. References + +[1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Structure of Management Information for Version 2 + of the Simple Network Management Protocol (SNMPv2)", RFC 1902, + January 1996. + +[2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Textual Conventions for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1903, January 1996. + +[3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Conformance Statements for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1904, January 1996. + +[4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Protocol Operations for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1905, January 1996. + +[5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Transport Mappings for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1906, January 1996. + +[6] 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. + + + +SNMPv2 Working Group Standards Track [Page 9] + +RFC 1908 Coexistence between SNMPv1 and SNMPv2 January 1996 + + +[7] Rose, M., and K. McCloghrie, "Structure and Identification of + Management Information for TCP/IP-based internets", STD 16, RFC + 1155, May 1990. + +[8] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, + RFC 1212, March 1991. + +[9] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network + Management Protocol", STD 15, RFC 1157, SNMP Research, Performance + Systems International, MIT Laboratory for Computer Science, May + 1990. + +[10] Information processing systems - Open Systems Interconnection - + Specification of Abstract Syntax Notation One (ASN.1), + International Organization for Standardization. International + Standard 8824, (December, 1987). + +[11] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP- + based Agents", RFC 1303, Hughes LAN Systems, Dover Beach + Consulting, Inc., February 1992. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +SNMPv2 Working Group Standards Track [Page 10] + -- cgit v1.2.3