RFC 1452

Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework

📅 published April 1993, from ietf

okay bestie, RFC 1452 is here and it's giving coexistence 💖✨

Okay so the title block is RFC 1452, published in April 1993 by the Network Working Group 🎀. The title is Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework 🦋. The four authors are J. Case from SNMP Research, Inc., K. McCloghrie from Hughes LAN Systems, M. Rose from Dover Beach Consulting, Inc., and S. Waldbusser from Carnegie Mellon University 🫶. It's an IAB standards track protocol 💅. The title block doesn't list anything it obsoletes or updates, so there's no drama there 🌸.

Status of this Memo ✨

This RFC is an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬. For the current standardization state and status of this protocol, go check the "IAB Official Protocol Standards" 📑. Distribution of this memo is unlimited 🌈.

Table of Contents 📑

1 Introduction ..........................................    2
2 Management Information ................................    3
2.1 Object Definitions ..................................    3
2.2 Trap Definitions ....................................    6
2.3 Compliance Statements ...............................    7
2.4 Capabilities Statements .............................    7
3 Protocol Operations ...................................    8
3.1 Proxy Agent Behavior ................................    8
3.1.1 SNMPv2 -> SNMPv1 ..................................    8
3.1.2 SNMPv1 -> SNMPv2 ..................................    8
3.2 Bi-lingual Manager Behavior .........................   10
4 Acknowledgements ......................................   11
5 References ............................................   15
6 Security Considerations ...............................   17
7 Authors' Addresses ....................................   17

1. Introduction 🧚

Okay so the whole point of this doc is to explain how version 2 of the Internet-standard Network Management Framework, called the SNMP version 2 framework (SNMPv2) [1], and the original Internet-standard Network Management Framework (SNMPv1) get along 🫶💅. SNMPv1 is made up of three documents:

  • RFC 1155 [2] defines the Structure of Management Information (SMI), which covers the mechanisms for describing and naming objects for the purpose of management 🧚
  • RFC 1212 [3] defines a more concise description mechanism, and it's wholly consistent with the SMI ✨
  • RFC 1157 [4] defines the Simple Network Management Protocol (SNMP), which is the protocol used for network access to managed objects 🦋

2. Management Information ✨

okay so the SNMPv2 way of describing collections of managed objects is basically a proper superset of the approach in the Internet-standard Network Management Framework 💖 both approaches use ASN.1 [5] as the base for a formal descriptive notation. ngl, the SNMPv2 approach mostly just codifies what people were already doing for defining MIB modules, based on tons of experience with the current framework 🫶

the SNMPv2 documents that deal with information modules are:

  • Structure of Management Information for SNMPv2 [6], which defines concise notations for describing information modules, managed objects and notifications;
  • Textual Conventions for SNMPv2 [7], which defines a concise notation for describing textual conventions, and also defines some initial conventions; and,
  • Conformance Statements for SNMPv2 [8], which defines concise notation for describing compliance and capabilities statements.

the next sections cover three areas: MIB modules, compliance statements, and capabilities statements 🎀

MIB modules defined using the current framework can keep being used with the SNMPv2 protocol 🌸 however, for the MIB modules to conform to the SNMPv2 framework, the following changes are required:

2.1. Object Definitions

in general, converting a MIB module doesn't require deprecating the objects inside it 🙈 deprecation should only happen if the semantics of an object truly changes.

  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 or EXPORTs statement.
  3. For any descriptor which contains the hyphen character, the hyphen character is removed.
  4. 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.
  5. 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.
  6. For any object with a SYNTAX clause value of Counter, the object must have the value of its SYNTAX clause changed to Counter32.
  7. For any object with a SYNTAX clause value of Gauge, the object must have the value of its SYNTAX clause changed to Gauge32.
  8. 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.
  9. For any columnar object which is used solely for instance identification in a conceptual row, the object must have the value of its MAX-ACCESS clause set to "not-accessible", unless all columnar objects of the conceptual row are used for instance identification, in which case, the MAX-ACCESS clause for one of them must be something other than "not-accessible".
  10. For all objects, if the value of the STATUS clause is "mandatory", the value must be replaced with "current".
  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 replacing 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 an extension.

finally, when encountering common errors in SNMPv1 MIB modules 😭

  1. For any object with a SYNTAX clause value of an enumerated INTEGER, if a named-number enumeration is present with a value of zero, the value of the STATUS clause of that object is changed to "obsolete".
  2. 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".
  3. 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.

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 happen when the information module undergoes review 🧚

2.4. Capabilities Statements

in the current framework, the informational document [9] uses the MODULE-CONFORMANCE macro to describe an agent's capabilities with respect to one or more MIB modules. converting that description for use with the SNMPv2 framework needs 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.

3. Protocol Operations ✨

okay so bestie, the SNMPv2 docs that deal with protocol operations are two of them 💅

  • Protocol Operations for SNMPv2 [10], which defines the syntax and semantics of the operations conveyed by the protocol; and,
  • Transport Mappings for SNMPv2 [11], which defines how the protocol operations get carried over different transport services.

this section covers 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. let's go!!

3.1. Proxy Agent Behavior 🌸

to get 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 as a proxy agent. it's giving main character energy 👑

3.1.1. SNMPv2 -> SNMPv1 🎀

when a SNMPv2 entity acting in a manager role sends requests to a SNMPv1 entity acting in an agent role, the proxy agent handles them like this:

  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 0, and sets the tag of the PDU to GetNextRequest-PDU.

3.1.2. SNMPv1 -> SNMPv2 🦋

when a SNMPv1 entity acting in an agent role sends responses back to a SNMPv2 entity acting in a manager role, here's the drama 😭

  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 may not change this field. This lets the SNMPv2 entity acting in a manager role 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 GetBulkRequestPDU, the proxy agent must propagate such a response. 💀

  1. If a Trap-PDU is received, then it is mapped into a SNMPv2-Trap-PDU. This is done by prepending two new bindings onto the variable-bindings field: sysUpTime.0 [12], which takes its value from the timestamp field of the Trap-PDU; and snmpTrapOID.0 [13], which is calculated like this: if the value of the 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 [13] is used. (For example, if the value of the generic-trap field is coldStart, then the coldStart trap [13] is used.) Then, one new binding is appended onto the variable-bindings field: snmpTrapEnterpriseOID.0 [13], which takes its value from the enterprise field of the Trap-PDU. To figure out where the SNMPv2-Trap-PDU goes, the proxy agent applies the procedures defined in Section 4.2.6 of [10], with one exception: no check is made to see if the instances associated with this trap are present in the proxy agent's view. 🧚

3.2. Bi-lingual Manager Behavior 💖

to get 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. 🍓

for transparency toward management applications, the entity acting in a manager role must map operations as if it were acting as a proxy agent. ✨

4. Acknowledgements 🫶

the comments of the SNMP version 2 working group are gratefully acknowledged, bestie, thank you all 🌈

  • Beth Adams, Network Management Forum
  • Steve Alexander, INTERACTIVE Systems Corporation
  • David Arneson, Cabletron Systems
  • Toshiya Asaba
  • Fred Baker, ACC
  • Jim Barnes, Xylogics, Inc.
  • Brian Bataille
  • Andy Bierman, SynOptics Communications, Inc.
  • Uri Blumenthal, IBM Corporation
  • Fred Bohle, Interlink
  • Jack Brown
  • Theodore Brunner, Bellcore
  • Stephen F. Bush, GE Information Services
  • Jeffrey D. Case, University of Tennessee, Knoxville
  • John Chang, IBM Corporation
  • Szusin Chen, Sun Microsystems
  • Robert Ching
  • Chris Chiotasso, Ungermann-Bass
  • Bobby A. Clay, NASA/Boeing
  • John Cooke, Chipcom
  • Tracy Cox, Bellcore
  • Juan Cruz, Datability, Inc.
  • David Cullerot, Cabletron Systems
  • Cathy Cunningham, Microcom
  • James R. (Chuck) Davin, Bellcore
  • Michael Davis, Clearpoint
  • Mike Davison, FiberCom
  • Cynthia DellaTorre, MITRE
  • Taso N. Devetzis, Bellcore
  • Manual Diaz, DAVID Systems, Inc.
  • Jon Dreyer, Sun Microsystems
  • David Engel, Optical Data Systems
  • Mike Erlinger, Lexcel
  • Roger Fajman, NIH
  • Daniel Fauvarque, Sun Microsystems
  • Karen Frisa, CMU
  • Shari Galitzer, MITRE
  • Shawn Gallagher, Digital Equipment Corporation
  • Richard Graveman, Bellcore
  • Maria Greene, Xyplex, Inc.
  • Michel Guittet, Apple
  • Robert Gutierrez, NASA
  • Bill Hagerty, Cabletron Systems
  • Gary W. Haney, Martin Marietta Energy Systems
  • Patrick Hanil, Nokia Telecommunications
  • Matt Hecht, SNMP Research, Inc.
  • Edward A. Heiner, Jr., Synernetics Inc.
  • Susan E. Hicks, Martin Marietta Energy Systems
  • Geral Holzhauer, Apple
  • John Hopprich, DAVID Systems, Inc.
  • Jeff Hughes, Hewlett-Packard
  • Robin Iddon, Axon Networks, Inc.
  • David Itusak
  • Kevin M. Jackson, Concord Communications, Inc.
  • Ole J. Jacobsen, Interop Company
  • Ronald Jacoby, Silicon Graphics, Inc.
  • Satish Joshi, SynOptics Communications, Inc.
  • Frank Kastenholz, FTP Software
  • Mark Kepke, Hewlett-Packard
  • Ken Key, SNMP Research, Inc.
  • Zbiginew Kielczewski, Eicon
  • Jongyeoi Kim
  • Andrew Knutsen, The Santa Cruz Operation
  • Michael L. Kornegay, VisiSoft
  • Deirdre C. Kostik, Bellcore
  • Cheryl Krupczak, Georgia Tech
  • Mark S. Lewis, Telebit
  • David Lin
  • David Lindemulder, AT&T/NCR
  • Ben Lisowski, Sprint
  • David Liu, Bell-Northern Research
  • John Lunny, The Wollongong Group
  • Robert C. Lushbaugh Martin, Marietta Energy Systems
  • Michael Luufer, BBN
  • Carl Madison, Star-Tek, Inc.
  • Keith McCloghrie, Hughes LAN Systems
  • Evan McGinnis, 3Com Corporation
  • Bill McKenzie, IBM Corporation
  • Donna McMaster, SynOptics Communications, Inc.
  • John Medicke, IBM Corporation
  • Doug Miller, Telebit
  • Dave Minnich, FiberCom
  • Mohammad Mirhakkak, MITRE
  • Rohit Mital, Protools
  • George Mouradian, AT&T Bell Labs
  • Patrick Mullaney, Cabletron Systems
  • Dan Myers, 3Com Corporation
  • Rina Nathaniel, Rad Network Devices Ltd.
  • Hien V. Nguyen, Sprint
  • Mo Nikain
  • Tom Nisbet
  • William B. Norton, MERIT
  • Steve Onishi, Wellfleet Communications, Inc.
  • David T. Perkins, SynOptics Communications, Inc.
  • Carl Powell, BBN
  • Ilan Raab, SynOptics Communications, Inc.
  • Richard Ramons, AT&T
  • Venkat D. Rangan, Metric Network Systems, Inc.
  • Louise Reingold, Sprint
  • Sam Roberts, Farallon Computing, Inc.
  • Kary Robertson, Concord Communications, Inc.
  • Dan Romascanu, Lannet Data Communications Ltd.
  • Marshall T. Rose, Dover Beach Consulting, Inc.
  • Shawn A. Routhier, Epilogue Technology Corporation
  • Chris Rozman
  • Asaf Rubissa, Fibronics
  • Jon Saperia, Digital Equipment Corporation
  • Michael Sapich
  • Mike Scanlon, Interlan
  • Sam Schaen, MITRE
  • John Seligson, Ultra Network Technologies
  • Paul A. Serice, Corporation for Open Systems
  • Chris Shaw, Banyan Systems
  • Timon Sloane
  • Robert Snyder, Cisco Systems
  • Joo Young Song
  • Roy Spitier, Sprint
  • Einar Stefferud, Network Management Associates
  • John Stephens, Cayman Systems, Inc.
  • Robert L. Stewart, Xyplex, Inc. (chair)
  • Kaj Tesink, Bellcore
  • Dean Throop, Data General
  • Ahmet Tuncay, France Telecom-CNET
  • Maurice Turcotte, Racal Datacom
  • Warren Vik, INTERACTIVE Systems Corporation
  • Yannis Viniotis
  • Steven L. Waldbusser, Carnegie Mellon Universitty
  • Timothy M. Walden, ACC
  • Alice Wang, Sun Microsystems
  • James Watt, Newbridge
  • Luanne Waul, Timeplex
  • Donald E. Westlake III, Digital Equipment Corporation
  • Gerry White
  • Bert Wijnen, IBM Corporation
  • Peter Wilson, 3Com Corporation
  • Steven Wong, Digital Equipment Corporation
  • Randy Worzella, IBM Corporation
  • Daniel Woycke, MITRE
  • Honda Wu
  • Jeff Yarnell, Protools
  • Chris Young, Cabletron
  • Kiho Yum, 3Com Corporation

5. References ✨

okay bestie, this is the reading list 📚💅 every single one of these is a source the RFC leans on, so I'm keeping every author, title, number, org and date exactly as written, no cap 🫶

  • [1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Introduction to version 2 of the Internet-standard Network Management Framework", RFC 1441, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. 🌸
  • [2] Rose, M., and McCloghrie, K., "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990. 💖
  • [3] Rose, M., and McCloghrie, K., "Concise MIB Definitions", STD 16, RFC 1212, March 1991. ✨
  • [4] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. 🦋
  • [5] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). 🧚
  • [6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. 🎀
  • [7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Textual Conventions for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. 💜
  • [8] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Conformance Statements for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. 🌈
  • [9] McCloghrie, K., and Rose, M., "A Convention for Describing SNMP-based Agents", RFC 1303, Hughes LAN Systems, Dover Beach Consulting, Inc., February 1992. ⭐
  • [10] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. 🍓
  • [11] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1449, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. 🫶
  • [12] McCloghrie, K., and Rose, M., "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. 👑
  • [13] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1450, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. 🔥

6. Security Considerations 💀

okay this part is lowkey dramatic bestie 😭 but the RFC is super chill about it: security issues are not discussed in this memo. no cap, that's the whole section. 🙈

7. Authors' Addresses 🎀

these are the lovely people who wrote it, with their contact details kept exactly as they were 💖

Jeffrey D. Case SNMP Research, Inc. 3001 Kimberlin Heights Rd. Knoxville, TN 37920-9716 US

Phone: +1 615 573 1434 Email: case@snmp.com

Keith McCloghrie Hughes LAN Systems 1225 Charleston Road Mountain View, CA 94043 US

Phone: +1 415 966 7934 Email: kzm@hls.com

Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 US

Phone: +1 415 968 1052 Email: mrose@dbc.mtview.ca.us

Steven Waldbusser Carnegie Mellon University 4910 Forbes Ave Pittsburgh, PA 15213 US

Phone: +1 412 268 6628 Email: waldbusser@cmu.edu

🦋 that's the end of the doc bestie, you made it 👑✨

📦 where this page comes from