RFC 1441

Okay bestie, this is RFC 1441! 🎀 It's titled Introduction to version 2 of the Internet-standard Network Management Framework ✨ and it's from the Network Working Group, with Request for Comments: 1441 and a date of April 1993 📅

The authors are J. Case (SNMP Research, Inc.), K. McCloghrie (Hughes LAN Systems), M. Rose (Dover Beach Consulting, Inc.), and S. Waldbusser (Carnegie Mellon University) 👯‍♀️ The category is an IAB standards track protocol, and the header doesn't list anything it obsoletes or updates 🦋

---

Status of this Memo 📜

Okay so this RFC specifies an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 If you want the current standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 🔍 And distribution of this memo is unlimited 🌈

---

Table of Contents 🗂️

          1 Introduction ..........................................    2
          2 Components of the SNMPv2 Framework ....................    3
          2.1 Structure of Management Information .................    3
          2.2 Textual Conventions .................................    4
          2.3 Protocol Operations .................................    4
          2.4 Transport Mappings ..................................    4
          2.5 Protocol Instrumentation ............................    5
          2.6 Administrative Framework ............................    5
          2.7 Conformance Statements ..............................    5
          3 Acknowledgements ......................................    7
          4 References ............................................   11
          5 Security Considerations ...............................   13
          6 Authors' Addresses ....................................   13

---

1. Introduction ✨

The purpose of this doc is to give you an overview of version 2 of the Internet-standard Network Management Framework, which is called the SNMP version 2 framework (SNMPv2) 💖 It's derived from the original Internet-standard Network Management Framework (SNMPv1), and that one is made up of three documents:

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

For info on coexistence between SNMPv1 and SNMPv2, check out [4] 🧚

---

2. Components of the SNMPv2 Framework 🍓

A network management system has a few main pieces 💅 There are several (potentially many) nodes, and each one has a processing entity called an agent that has access to management instrumentation. There's also at least one management station, plus a management protocol that carries management information between the agents and the management stations 🫶 The protocol runs under an administrative framework that defines both authentication and authorization policies.

Network management stations run management applications that monitor and control network elements. Network elements are devices like hosts, routers, terminal servers, etc., and they get monitored and controlled through access to their management information 👑

---

2.1. Structure of Management Information 🏗️

Management information is seen as a collection of managed objects, living in a virtual information store called the Management Information Base (MIB) 💜 Collections of related objects are defined in MIB modules, and those modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [5]. The Structure of Management Information for SNMPv2 document [6] is the one that defines that subset 🎀

The SMI is split into three parts: module definitions, object definitions, and trap definitions 🌸

• (1) Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, concisely conveys the semantics of an information module.
• (2) Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, concisely conveys the syntax and semantics of a managed object.
• (3) Notification definitions are used when describing unsolicited transmissions of management information. An ASN.1 macro, NOTIFICATION-TYPE, concisely conveys the syntax and semantics of a notification.

---

2.2. Textual Conventions 🦋

When you're designing a MIB module, it's often handy to define new types that are similar to the ones in the SMI. Compared to an SMI type, each of these new types has a different name, a similar syntax, but a more precise semantics ✨ They're called textual conventions, and they're there for the convenience of humans reading the MIB module. The Textual Conventions for SNMPv2 document [7] defines the initial set of textual conventions that every MIB module can use 🌈

Objects defined using a textual convention are always encoded by the rules that define their primitive type 🤓 Textual conventions often have special semantics attached to them though, so an ASN.1 macro, TEXTUAL-CONVENTION, concisely conveys the syntax and semantics of a textual convention 💁‍♀️

---

2.3. Protocol Operations 📬

The management protocol handles exchanging messages that carry management information between the agents and the management stations 💌 The form of these messages is a message "wrapper" that encapsulates a Protocol Data Unit (PDU). The form and meaning of that "wrapper" is decided by an administrative framework that defines both authentication and authorization policies 🔐

The Protocol Operations for SNMPv2 document [8] defines the operations of the protocol for sending and receiving PDUs 💫

---

2.4. Transport Mappings 🚚

The management protocol, which is version 2 of the Simple Network Management Protocol, can run over a bunch of different protocol suites 🌍 The Transport Mappings for SNMPv2 document [9] defines how SNMPv2 maps onto an initial set of transport domains, and other mappings might get defined in the future 🔮

Even though several mappings are defined, the mapping onto UDP is the preferred mapping 🏆 So for the greatest level of interoperability, systems that choose to deploy other mappings should also provide proxy service to the UDP mapping. That's the iconic move for interop 😭

---

2.5. Protocol Instrumentation 🔧

The Management Information Base for SNMPv2 document [10] defines managed objects that describe the behavior of an SNMPv2 entity 🧠 The Manager-to-Manager MIB document [11] defines an initial set of managed objects that describe the behavior of an SNMPv2 entity acting in a manager role. Extensions to this MIB are expected to be defined in the future 💅

---

2.6. Administrative Framework 🛡️

The Administrative Model for SNMPv2 document [12] defines the behavior of an SNMPv2 party. A party is a conceptual, virtual execution context whose operation is restricted (for security or other purposes) to an administratively defined subset of all possible operations of a particular SNMPv2 entity 🙈

Each SNMPv2 party is associated with a single authentication protocol and a single privacy protocol 🔑 The Security Protocols for SNMPv2 document [13] defines those protocols. And the Party MIB for SNMPv2 document [14] defines managed objects that correspond to the properties associated with an SNMPv2 party 🎀

---

2.7. Conformance Statements 📋

It can be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved 👀 The Conformance Statements for SNMPv2 document [15] defines the notation used for these purposes. There are two kinds of notation:

• (1) Compliance statements are used when describing requirements for agents with respect to object definitions. An ASN.1 macro, MODULE-COMPLIANCE, concisely conveys these requirements.
• (2) Capability statements are used when describing capabilities of agents with respect to object definitions. An ASN.1 macro, AGENT-CAPABILITIES, concisely conveys these capabilities.

And finally, collections of related objects get grouped together to form a unit of conformance 🌈 An ASN.1 macro, OBJECT-GROUP, concisely conveys the syntax and semantics of a group 💖

3. Acknowledgements ✨

okay so the SNMPv2 framework is built on the work of the original SGMP crew 🫶 that's James R. (Chuck) Davin from the MIT Laboratory for Computer Science, Mark S. Fedor from Performance Systems International, Inc., Martin L. Schoffstall (also PSI), and Jeffrey D. Case. they had the vision, and it's giving legacy 👑

ever since SGMP came out in 1987, so many people have poured so much energy into the Internet-standard Network Management Framework, and it's honestly unprecedented how well it turned out 🌈 there are way too many amazing people to list here, so this is not me being rude, it's just math 💀

looking back, it's super clear that the ideas in the original architecture, the ones Chuck Davin imagined, are the foundation everything else got built on. we're hoping the SNMPv2 framework can keep building on that and actually succeed 🦋

and finally, a huge thank you to everyone in the SNMP version 2 working group whose comments were gratefully acknowledged. you're all iconic 💖

     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

4. References 📚

[1] Rose, M., and McCloghrie, K., "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.

[2] Rose, M., and McCloghrie, K., "Concise MIB Definitions", STD 16, RFC 1212, March 1991.

[3] 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.

[4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework", RFC 1452, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.

[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., "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.

[9] 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.

[10] 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.

[11] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Manager-to-Manager Management Information Base", RFC 1451, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993.

[12] Galvin, J., and McCloghrie, K., "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993.

[13] Galvin, J., and McCloghrie, K., "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN Systems, April 1993.

[14] McCloghrie, K., and Galvin, J., "Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1447, Hughes LAN Systems, Trusted Information Systems, April 1993.

[15] 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.

5. Security Considerations 🔐

okay bestie, this one is a lot. the memo itself says security issues are not discussed in this memo. 😭 zero security talk in this doc, so if you're looking for security guidance here, you're not going to find it.

Security issues are not discussed in this memo.

6. Authors' Addresses ✨

okay bestie, this is the squad list 🫶 the four people who wrote this whole SNMPv2 thing, with where to find them. Here's the vibe check:

Jeffrey D. Case 💅

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 🌸

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 🦋

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 👑

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

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

Literally the legends behind it all, so if you've got questions about the protocol, these are the people who know the tea ☕🔥 That's the whole doc, periodt 💖