RFC 1909

RFC 1909: An Administrative Infrastructure for SNMPv2 💖

Part 1 of 4 🎀

• Network Working Group
• Request for Comments: 1909
• Editor: K. McCloghrie, Cisco Systems, Inc.
• Category: Experimental
• Date: February 1996
• Obsoletes / Updates: this document doesn't list anything it obsoletes or updates 🦋

---

Status of This Memo ✨

okay so this memo defines an Experimental Protocol for the Internet community. it does not specify an Internet standard of any kind 🙈 discussion and suggestions for improvement are literally requested, so feel free to weigh in. and distribution of this memo is unlimited 🌈

---

Table of Contents 🧚

   1. Introduction ................................................    2
   2. Overview ....................................................    2
   2.1 Contexts ...................................................    3
   2.2 Authorization: Access Rights and MIB Views .................    3
   2.3 Authentication and Privacy .................................    4
   2.4 Access Control .............................................    5
   2.5 Security Models ............................................    5
   2.6 Proxy ......................................................    5
   3. Elements of the Model .......................................    7
   3.1 SNMPv2 Entity ..............................................    7
   3.2 SNMPv2 Agent ...............................................    7
   3.3 SNMPv2 Manager .............................................    8
   3.4 SNMPv2 Dual-Role Entity ....................................    8
   3.5 View Subtree and Families ..................................    9
   3.6 MIB View ...................................................    9
   3.7 SNMPv2 Context .............................................   10
   3.7.1 Local SNMPv2 Context .....................................   11
   3.7.2 Proxy SNMPv2 Context .....................................   11
   3.8 SNMPv2 PDUs and Operations .................................   12
   3.8.1 The Report-PDU ...........................................   12
   3.9 SNMPv2 Access Control Policy ...............................   13
   4. Security Considerations .....................................   13
   5. Editor's Address ............................................   14
   6. Acknowledgements ............................................   14
   7. References ..................................................   14
   Appendix A Disambiguating the SNMPv2 Protocol Definition .......   16
   Appendix B Who Sends Inform-Requests?  .........................   17
   Appendix B.1 Management Philosophy .............................   17
   Appendix B.2 The Danger of Trap Storms .........................   17
   Appendix B.3 Inform-Requests ...................................   18

---

1. Introduction 💅

okay so a management system is basically a squad of parts: several (potentially many) nodes, each with a processing entity called an agent that has access to management instrumentation 🫶 then there's at least one management station, and a management protocol that carries management information between the agents and the stations. all of it runs under an administrative framework that defines authentication, authorization, access control, and privacy policies 🔥

management stations run management applications that monitor and control managed elements. managed elements are things like hosts, routers, terminal servers, etc., and they get monitored and controlled through access to their management information ✨

this document, An Administrative Infrastructure for SNMPv2, is here to define an administrative framework that makes management actually effective across a variety of configurations and environments 👑 the SNMPv2 framework is fully described in [1-6]. and it's derived from the original Internet-standard Network Management Framework (SNMPv1), which is made up 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.

for info on coexistence between SNMPv1 and SNMPv2, check out [10] 🌸

---

2. Overview 🦋

a management domain usually holds a large amount of management information 😭 each individual item of management information is an instance of a managed object type. a related set of managed object types gets defined in a Management Information Base (MIB) module, and there are lots of these modules out there. for each managed object type, a MIB module defines not only the semantics and syntax of that type, but also the method of identifying an individual instance, so that multiple instances of the same type can be told apart 🧚

2.1. Contexts 🌈

there are typically tons of instances of each managed object type within a management domain. for simplicity, the way instances get identified in the MIB module does not let each instance be distinguished across the entire set of instances in the domain. instead, it lets each instance be identified only within some scope, or "context", and there are multiple contexts in the domain. a context is often a physical device or maybe a logical device, but it can also cover multiple devices, a subset of a single device, or even a subset of multiple devices 💖 so to pin down one item of management information anywhere in the domain, you need its context plus its object type plus its instance. it's like a whole identity situation 🙈

for example, the managed object type ifDescr [11] is defined as the description of a network interface. to identify the description of device-X's first network interface, you need three pieces of info: device-X (the context), ifDescr (the managed object type), and "1" (the instance) ✨

okay the main thing to know here: each context has (at least) one globally-unique identification within the management domain. the same item of management information can also exist in multiple contexts 💜 so an item of management information can end up with multiple globally-unique identifications, either because it exists in multiple contexts, and/or because each of those contexts has multiple globally-unique identifications. main character energy 👑

2.2. Authorization: Access Rights and MIB Views 🎀

for security reasons, it's often super valuable to be able to restrict the access rights of some management applications to only a subset of the management information in the domain 🔒 to make that happen, access to a context goes through a "MIB view", which details a specific set of managed object types (and optionally, the specific instances of those object types) within that context. for a given context, there will typically always be one MIB view that gives access to all the management information in that context, and often there'll be other MIB views that each contain some subset of it. so by giving a management application access rights in terms of the particular (subset) MIB view it can use for that context, you restrict it in exactly the way you want 🫶

because managed object types (and their instances) are identified through the tree-like naming structure of ISO's OBJECT IDENTIFIERs [12, 1], it's convenient to define a MIB view as the combination of a set of "view subtrees", where each view subtree is a sub-tree within the managed object naming tree 🌳 a simple MIB view (like all managed objects within the Internet Network Management Framework) can be a single view subtree, while more complicated MIB views (like all information relevant to a particular network interface) can be the union of multiple view subtrees 🍓

now, any set of managed objects can be described by the union of some number of view subtrees, but situations can come up that would need a very large number of them 😵 for example, this could happen when you specify all the columns in one conceptual row of a MIB table, because they'd show up in separate subtrees, one per column, each with a very similar format. since the formats are similar, the required set of subtrees can easily be aggregated into one structure. this structure is named a "family of view subtrees" after the set of subtrees it conceptually represents. and a family of view subtrees can either be included in or excluded from a MIB view 💅

on top of restricting access by identifying (sub-)sets of management information, it's also valuable to restrict the requests allowed on the management information within a particular context 🚫 for example, one management application might be prohibited from write-access to a particular context, while another might be allowed to perform any type of operation 🌸

2.3. Authentication and Privacy 🔐

enforcing access rights means you need the ability not only to identify the entity on whose behalf a request is generated, but also to authenticate that identification 🪪 another security capability that's (optionally) provided is protecting the data within an SNMPv2 operation from disclosure (aka encrypting it). this is especially useful when sensitive data, like passwords or security keys, gets accessed via SNMPv2 requests 🙈

recommendations for which algorithms are best for authentication and privacy are subject to change ngl. that can happen as new research results on the vulnerability of various algorithms get published, and/or with the prevailing status of export control and patent issues. so it's valuable to let these algorithms be specified as parameters, which means new algorithms can be accommodated over time 🔄 one type of algorithm that may become useful in the future is the set of algorithms associated with asymmetric (public key) cryptography 🗝️

note that not all accesses via SNMPv2 requests need to be secure! 😭 there are purposes where insecure access is actually required. one example is a management application learning about devices it has no previous knowledge of. another example is performing any synchronization the security algorithms need before they can be used to communicate securely. this need for insecure access is handled by defining one of the authentication algorithms as providing no authentication, and similarly, one of the privacy algorithms as providing no protection against disclosure. (the combo of these two insecure algorithms is sometimes referred to as "noAuth/noPriv" 🙃)

2.4. Access Control 🛡️

an access control policy specifies the types of SNMPv2 requests and associated MIB views that are authorized for a particular identity (the one on whose behalf a request is generated) when using a particular level of security to access a particular context ✨ it's the rulebook, bestie 📖

2.5. Security Models 🔑

a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions. it does that in two ways:

1. by defining the security parameters associated with a communication, including the authentication and privacy algorithms and the security keys (if any) used.
2. by defining how entities on whose behalf requests are generated are identified. 🫶

okay that's the foundation, bestie 🌈💖✨

3. bestie, it also says how contexts get identified 🗂️
4. and how an access control policy gets worked out whenever management information is about to be accessed 🔑

2.6. Proxy 🎀

okay so a proxy is basically an SNMPv2 agent that answers requests for access to management information. Each request rides inside an SNMPv2 message, and that message lets you do one operation on a whole list of management information items. The cute part: you don't have to name the context, the managed object type, and the instance for every single item, because each SNMPv2 message is only about one context. So an SNMPv2 agent has to be able to handle requests for all the management information in the one or more contexts it supports 💅

When an SNMPv2 agent is responding to a request, it might be acting as a proxy for some other agent. The word "proxy" has been used super loosely over time, with a bunch of different meanings. These include (among others):

1. forwarding SNMPv2 requests on to other SNMP agents without caring which managed object types are being accessed, like forwarding an SNMPv2 request from one transport domain to another, or translating SNMPv2 requests into SNMPv1 requests;
2. translating SNMPv2 requests into operations of some non-SNMP management protocol;
3. supporting aggregated managed objects, where the value of one managed object instance depends on the values of multiple other (remote) items of management information.

Each of these scenarios can be useful. For example, aggregation can seriously cut down the bandwidth needed for big management activities 📉 However, using one single word to cover all of these different scenarios causes confusion 🙈

So this SNMPv2 administrative framework uses "proxy" with a much tighter meaning, which covers only the first item above. The difference between a "regular SNMPv2 agent" and a "proxy SNMPv2 agent" is simple:

• a proxy SNMPv2 agent is an SNMPv2 agent which forwards requests on to other agents according to the context, and irrespective of the specific managed object types being accessed;
• in contrast, an SNMPv2 agent which processes SNMPv2 requests according to the (names of the) individual managed object types and instances being accessed, is NOT a proxy SNMPv2 agent from the perspective of this administrative model. 🚫

So when an SNMPv2 agent acts as a proxy SNMPv2 agent for a particular context, the info on how to forward the request is tied to that context, but the proxy has no need of a detailed definition of the MIB view. It forwards the request no matter which managed object types are involved 🧚

In contrast, an SNMPv2 agent operating without proxy must have the detailed definition of the MIB view. And even if it needs to issue requests to other agents, that need depends on the individual managed object instances being accessed (i.e., not only on the context) 🦋

---

3. Elements of the Model 🧩

Okay, this part is the more formal, official tour of the model. Let's gooo ✨

3.1. SNMPv2 Entity 🦋

An SNMPv2 entity is an actual process that performs management operations by generating and/or responding to SNMPv2 protocol messages in the manner specified in [4]. An SNMPv2 entity takes on the identity of a particular administrative entity when it processes an SNMPv2 message.

An SNMPv2 entity is not required to process multiple protocol messages concurrently, no matter whether those messages need it to take on the identity of the same or different administrative entities. So an implementation of an SNMPv2 entity that supports more than one administrative entity doesn't need to be multi-threaded. However, there may be situations where implementors choose to use multi-threading 🧵

An SNMPv2 entity listens for incoming, unsolicited SNMPv2 messages on each transport service address it's configured to listen on. It's a local matter whether an SNMPv2 entity also listens for SNMPv2 messages on any other transport service addresses. If there's no other info on where to listen, an SNMPv2 entity must listen on the transport service addresses corresponding to the standard transport-layer "ports" [5] on its local network-layer addresses 👂

3.2. SNMPv2 Agent 🤖

An SNMPv2 agent is the operational role an SNMPv2 entity takes on when it acts in an agent role. Specifically, an SNMPv2 agent performs SNMPv2 management operations in response to received SNMPv2 protocol messages (except for inform notifications).

To be manageable, all network components need to be instrumented. SNMPv2 access to that instrumented information happens through the managed objects supported by an SNMPv2 agent in one or more contexts 💖

3.3. SNMPv2 Manager 👑

An SNMPv2 manager is the operational role an SNMPv2 entity takes on when it acts in a manager role on behalf of management applications. Specifically, an SNMPv2 manager starts SNMPv2 management operations by generating the appropriate SNMPv2 protocol messages, or when it receives and processes trap and inform notifications.

It's honestly interesting to think about managing an SNMPv2 manager. It's highly desirable that an SNMPv2 manager, just like any other networking application, be instrumented so it can be managed. That instrumentation (just like for any other networking application) is accessible via the managed objects supported by an SNMPv2 agent. So an SNMPv2 manager is no different from any other network application: it has instrumentation, but it doesn't itself have managed objects 🌸

To be clear, an SNMPv2 manager does not itself have managed objects. Instead, it's an associated SNMPv2 agent supporting managed objects, and that agent provides access to the SNMPv2 manager's instrumentation 🫶

3.4. SNMPv2 Dual-Role Entity 🌗

An SNMPv2 entity that sometimes acts in an agent role and sometimes acts in a manager role is called an SNMPv2 dual-role entity. An SNMPv2 dual-role entity starts requests by acting in a manager role, and it processes requests about management information accessible to it (locally or via proxy) by acting in an agent role. When it sends inform notifications, an SNMPv2 dual-role entity acts in a manager role to start an inform notification containing management information that's accessible to it when it's acting in an agent role 📣

An SNMPv2 entity that can act only in an SNMPv2 manager role is not SNMP-manageable, because there's no way to access its management instrumentation. To be SNMP-manageable, an SNMPv2 entity must be able to act in an SNMPv2 agent role so its instrumentation can be accessed. So it's highly desirable that all SNMPv2 entities be either SNMPv2 agents or SNMPv2 dual-role entities 💅

There are two categories of SNMPv2 dual-role entities: proxy SNMPv2 agents and (so-called) mid-level managers. Proxy SNMPv2 agents only forward requests/responses; they don't originate requests. Mid-level managers, on the other hand, often originate requests 🧠 (Note that the term proxy SNMPv2 agent doesn't include an SNMPv2 agent that translates SNMPv2 requests into the requests of some other management protocol; see section 2.6.)

3.5. View Subtree and Families 🌳

A view subtree is the set of all MIB object instances that have a common ASN.1 OBJECT IDENTIFIER prefix in their names. A view subtree is identified by the OBJECT IDENTIFIER value that's the longest OBJECT IDENTIFIER prefix common to all (potential) MIB object instances in that subtree 🌿

A family of view subtrees is a pairing of an OBJECT IDENTIFIER value (called the family name) together with a bitstring value (called the family mask). The family mask shows which sub-identifiers of the associated family name matter to the family's definition 🎯

For each possible managed object instance, that instance belongs to a particular view subtree family if both of the following conditions are true:

• the OBJECT IDENTIFIER name of the managed object instance contains at least as many sub-identifiers as the family name does, and
• each sub-identifier in the OBJECT IDENTIFIER name of the managed object instance matches the corresponding sub-identifier of the family name whenever the corresponding bit of the associated family mask is non-zero.

When the configured value of the family mask is all ones, the view subtree family is identical to the single view subtree identified by the family name 💜

When the configured value of the family mask is shorter than required to perform the above test, its value is implicitly extended with ones. Consequently, a view subtree family with a family mask of zero length always corresponds to a single view subtree.

bestie, the zero-length mask thing is a total plot twist 🙈

3.6. MIB View 🦄

A MIB view is a subset of the set of all instances of all object types defined according to the SMI [1] within an SNMPv2 context, subject to the following constraints:

• It is possible to specify a MIB view which contains the full set of all object instances within an SNMPv2 context.
• Each object instance within a MIB view is uniquely named by an ASN.1 OBJECT IDENTIFIER value.

So identically named instances of a particular object type must be contained within different SNMPv2 contexts. Put another way, a particular object instance name resolves within a particular SNMPv2 context to at most one object instance 🔍

A MIB view is defined as a collection of view subtree families, where each view subtree family has a type. That type decides whether the view subtree family is included in, or excluded from, the MIB view 🎀

A managed object instance is contained or not contained within the MIB view depending on which view subtree families the instance belongs to:

• If a managed object instance belongs to none of the relevant subtree families, then that instance is not in the MIB view.
• If a managed object instance belongs to exactly one of the relevant subtree families, then that instance is included in, or excluded from, the relevant MIB view according to the type of that subtree family.
• If a managed object instance belongs to more than one of the relevant subtree families, then that instance is included in, or excluded from, the relevant MIB view according to the type of one particular subtree family it belongs to. That particular subtree family is the one where, first, the associated family name has the greatest number of sub-identifiers, and, second, the associated family name is lexicographically greatest. main character energy, fr fr 🌈

3.7. SNMPv2 Context 🎀

okay so an SNMPv2 context is basically a collection of management information that an SNMPv2 entity can access 💅. Every context is either local or proxy, no in-between ✨

For a local SNMPv2 context, the entity that realizes it just uses its own locally-defined mechanisms to get to the info 🦋

For a proxy SNMPv2 context, the entity acts as a proxy SNMPv2 agent to access the info. Think of it as the middle person who goes and fetches stuff for you 🧚

Then there's the remote SNMPv2 context, which a manager uses to describe a context (local or proxy) that the local SNMPv2 entity doesn't realize itself. So the local entity doesn't use its own locally-defined mechanisms, and it doesn't act as a proxy agent, to reach that info. It's giving "not my problem" energy 💀

3.7.1. Local SNMPv2 Context ✨

A local context is a set of MIB objects that logically belong to one single entity inside a managed device. When an SNMPv2 entity accesses that info, it does it using locally-defined mechanisms 🌸

A device can have several of these local entities, so each local context gets a "local entity" name 🍓 Management info also changes over time, so each local context has its own temporal domain called its "local time" ⏰

This is what lets one context point at a device's current parameter values, while a different context points at what those same parameters, for that same device, will be after its next restart. Literal time-travel vibes 🕰️

3.7.2. Proxy SNMPv2 Context 🦋

A proxy relationship exists when a proxy SNMPv2 agent takes a received SNMPv2 message (a request or a response) and forwards it to another entity, going purely by the SNMPv2 context of that message. That context is called a proxy SNMPv2 context. When an SNMPv2 entity handles management requests and responses for a proxy context, it's operating as a proxy SNMPv2 agent 💜

The transparency principle, which defines how an SNMPv2 entity behaves in general, applies to proxy contexts too:

The manner in which a receiving SNMPv2 entity processes SNMPv2 protocol messages sent by another SNMPv2 entity is entirely transparent to the sending SNMPv2 entity.

Implicit in transparency is that the semantics of SNMPv2 management operations get preserved between any two SNMPv2 peers. The "as if simultaneous" semantics of a Set operation are extremely hard to guarantee if the scope spans management info living at multiple network locations 😩. Still, agents that support forwarding Set operations about info at multiple locations are not considered proxy SNMPv2 agents (see section 2.6 above) 🙌

Also implicit: during its whole interaction with a proxy SNMPv2 agent, an SNMPv2 manager gets zero info about the nature or progress of the proxy mechanisms used to handle its requests 🙈. It should seem to the manager (apart from any difference in underlying transport address) like it's talking to the proxied device directly over SNMPv2 🫶. So a timeout between the proxy agent and its proxied device should show up as a timeout between the manager and the proxy agent. And an error response from a proxied device should, as much as possible, be shown as the matching error response between the proxy agent and the manager 👑

3.8. SNMPv2 PDUs and Operations 🍓

An SNMPv2 PDU is defined in [4]. Each SNMPv2 PDU specifies one particular operation, and it's one of these:

GetBulkRequest
GetNextRequest
GetRequest
Inform
Report
Response
SNMPv2-Trap
SetRequest

3.8.1. The Report-PDU 😱

[4] says that an administrative framework which makes use of the Report-PDU must define its usage and semantics. With that framework, the Report-PDU is different from the other PDU types in [4]. It's not a protocol operation between SNMPv2 managers and agents. It's more of an error-reporting thing between SNMPv2 entities, specifically an interaction between two protocol engines 🤓

A communication between SNMPv2 entities is an SNMPv2 message. That message is formatted as a "wrapper" encapsulating a PDU, following the "Elements of Procedure" for the security model used to transmit it 🎀

When an SNMPv2 entity is processing a received communication, it might decide the message is unacceptable because of a problem with the contents of the "wrapper". In that case, an appropriate counter gets incremented and the message is discarded without further processing (and no Response-PDU gets sent) 🚫

But if an SNMPv2 entity acting in the agent role makes that call, then after incrementing the appropriate counter, it may be required to generate a Report-PDU and send it to the transport address that originated the received message 👑

If the agent can work out the value of the request-id field of the received PDU [4], it must use that same value for the request-id field of the Report-PDU. Otherwise, the value 2147483647 is used 🔢

The error-status and error-index fields of the Report-PDU are always set to zero. The variable-bindings field holds a single variable: the identity of the counter that was incremented, plus its new value 📊

There's at least one case where an agent-role entity must not send a Report-PDU: when the received message was itself tagged as a Report-PDU. Particular security models may identify other such cases ✨

3.9. SNMPv2 Access Control Policy 🔐

An SNMPv2 access policy says which types of SNMPv2 operations are authorized for a particular identity, at a particular level of security. If the operation is going to be performed on a local SNMPv2 context, the policy also lists two accessible MIB views: a read-view and a write-view. The read-view is the set of object instances the identity is authorized for when reading objects. Reading happens during retrieval operations (get, get-next, get-bulk) and when sending a notification. The write-view is the set of object instances the identity is authorized for when writing objects, which happens when processing a set operation. An identity's access rights may be different at different agents 🌈

A security model defines how an SNMPv2 access policy gets derived. The application of an SNMPv2 access control policy only happens:

• on receipt of GetRequest, GetNextRequest, GetBulkRequest, and SetRequest operations; and
• prior to transmission of SNMPv2-Trap and Inform operations.

Note that applying an SNMPv2 access control policy is never done for Response or Report operations 🙅‍♀️

4. Security Considerations 😱

Security issues are not directly discussed in this memo. Full stop, no tea spilled here, bestie 🫣

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 three major contributors:

• Keith McCloghrie (Cisco Systems, kzm@cisco.com)
• Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
• Glenn W. Waters (Bell-Northern Research Ltd., gwaters@bnr.ca)

The authors wanted to thank James M. Galvin of Trusted Information Systems, who contributed a lot to earlier work this memo is based on. They also gave a shoutout to the general contributions of the SNMPv2 Working Group members, and especially Aleksey Y. Romanov and Steven L. Waldbusser 🎉

A special thanks goes out to these contributors:

• Uri Blumenthal (IBM)
• Shawn Routhier (Epilogue)
• Barry Sheehan (IBM)
• Bert Wijnen (IBM)

7. References 📚

[1] The 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] The 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] The 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] 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] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.

[6] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, 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] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996.

[11] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Cisco Systems, FTP Software, January 1994.

[12] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987).

---

APPENDIX A - Disambiguating the SNMPv2 Protocol Definition 🪄

The descriptions in [4] of the role an SNMPv2 entity plays when it sends an Inform-Request PDU are ambiguous, bestie. The updates below clear those ambiguities up 💅

(1) Add the following sentence to section 2.1:

Further, when an SNMPv2 entity sends an inform notification, it acts in a manager role in respect to initiating the operation, but the management information contained in the inform notification is associated with that entity acting in an agent role. By convention, the inform is sent from the same transport address as the associated agent role is listening on.

(2) Tweak the last sentence of the second paragraph in section 2.3 ✨:

This type is used by one SNMPv2 entity, acting in a manager role, to notify another SNMPv2 entity, also acting in a manager role, of management information associated with the sending SNMPv2 entity acting in an agent role.

(3) Tweak the second paragraph of section 4.2 (the bit about generating Inform-Request PDUs) 🔥:

It is mandatory that all SNMPv2 entities acting in a manager role be able to generate the following PDU types: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, and Response-PDU; further, all such implementations must be able to receive the following PDU types: Response-PDU, SNMPv2-Trap-PDU, InformRequest-PDU. It is mandatory that all dual-role SNMPv2 entities must be able to generate an Inform-Request PDU.

(4) Tweak the first paragraph of section 4.2.7 💖:

An InformRequest-PDU is generated and transmitted at the request of an application in a SNMPv2 entity acting in a manager role, that wishes to notify another application (via an SNMPv2 entity also acting in a manager role) of information in a MIB view which is accessible to the sending SNMPv2 entity when acting in an agent role.

---

APPENDIX B - Who Sends Inform-Requests? 🧚

B.1. Management Philosophy 🌸

Okay so SNMP has been a whole vibe since its SGMP days, through SNMPv1, and now with SNMPv2 too. It's not just a management protocol plus a pile of MIB object definitions, bestie. It has a real philosophy of management, made up of a bunch of design strategies. And these strategies have always included the following: 💅

(1) The impact of adding an SNMP agent to a system should be minimal, so that both: a) it's doable even in the smallest/cheapest of systems, and b) the operational role and performance of a system is not compromised by the inclusion of an SNMP agent. This promotes widespread development, which allows ubiquitous deployment of manageable systems. 🦋

(2) Every system (potentially) incorporates an SNMP agent 🌈. Managers, though, are super limited in number, so there's a way bigger pile of agents than managers. Therefore, overall system development/complexity/cost is optimized if the SNMP agent is allowed to be simple and any required complexity is performed by an SNMP manager. It's giving efficiency 🧚

(3) The number of unsolicited messages generated by SNMP agents is minimized. This lets a small number of SNMP managers, which are (more) directly controlled by network operators, control how much network management traffic there is. Honestly, this control matters more than any extra protocol overhead that might be incurred. Monitoring network state at any significant level of detail is done mainly by SNMP managers polling for the info they need, and unsolicited messages are saved for situations where they're necessary to properly guide an SNMP manager on the timing and focus of its polling. This strategy is sometimes called "trap-directed polling" 🎀

B.2. The Danger of Trap Storms 💀

The need for this control over network management traffic comes from the potential that the SNMP manager receiving an unsolicited message doesn't want it, no longer wants it, or already knows the information in it. That potential is hugely reduced when most messages are specific requests for information from SNMP managers and responses to those requests from SNMP agents. 🙈

The danger of not controlling network management traffic this way is the potential for a "storm" of useless traps. As a simple example of "useless", picture a building power outage where every device in the network sends a coldStart trap, even though every SNMP manager and every network operator already knows what happened. For a simple example of "storm", imagine each transmitted trap causing the sending of another one. The more problems there are in the state of the network, the bigger the risk of a storm, especially in the unstructured, heterogeneous environment typical of today's internets. 😭

While SNMP philosophy considers all of the above to be more important than any lack of reliability in unsolicited messages, some users/developers have been wary of traps because they typically use an unreliable transport protocol and because traps aren't acknowledged. But following that logic would imply that acknowledged traps would make them reliable, and that's false, bestie. No amount of retransmission will succeed if the receiver and/or the connectivity to the receiver is down. A SNMP manager can't just sit and wait and assume the network is fine just because it isn't receiving any unsolicited messages. 🫶

B.3. Inform-Requests ✨

One of the new features of SNMPv2 is the Inform-request PDU. The Inform-Request contains management information specified in terms of MIB objects for a context supported by the sender. Since by definition, an SNMPv2 manager does not itself have managed objects (see sections 3.3), the managed objects contained in the Inform-request belong to a context of an SNMPv2 agent, just like the managed objects contained in an SNMPv2-Trap. 🧚

But an Inform-request is NOT meant to change the philosophy above. It would be wrong to think of it as an "acknowledged trap", because that would make the likelihood and effect of trap storms worse. Remember the building power outage example: with regular traps, the SNMP manager's buffer just overflows when it gets messages faster than it can cope with. But if every device in the network were to send a coldStart Inform-request, then after a power outage, all of them would re-transmit their Inform-request several times unless the receiving SNMP managers send responses. In the best case, when no messages are lost or re-transmitted, there are twice as many useless messages. In the worst case, the SNMP manager can't respond at all and every message gets re-transmitted its maximum number of times. 😱

The above explains the rationale behind the definition (see Appendix A's update to section 4.2.7 of [4]) that:

An InformRequest-PDU is generated and transmitted at the request of an application in a SNMPv2 entity acting in a manager role, that wishes to notify another application (via an SNMPv2 entity also acting in a manager role) of information in a MIB view which is accessible to the sending SNMPv2 entity when acting in an agent role.

So this definition says that SNMPv2 agents do not send Inform-Requests, which has three implications (ordered by importance) 👑:

(1) the number of devices which send Inform-requests is required to be a small subset of all devices in the network;

(2) while some devices traditionally considered to be SNMP agents are perfectly capable of sending Inform-requests, overall system development/complexity/cost doesn't go up the way it would if you had to configure/re-configure every SNMPv2 agent on which Inform-requests to send where and how often; and

(3) the cost of implementing an SNMPv2 agent in the smallest/cheapest system doesn't go up either. 🌸