On the contrary, I think it was clearly a very intentional and deliberate decision to not add complexity (it is, after all, "Simple" Network Management Protocol

On the contrary, I think it was clearly a very intentional and deliberate decision to not add complexity (it is, after all, "Simple" Network Management Protocol) to the transport layer of SNMP. At the very least, the people involved certainly had alternative transports in consideration rather than a mistaken view of TCP vs UDP alone. Additional transport requirements were just not relevant to the use cases of SNMP. Select excerpts from RFC 1157: > Consistent with the goal of minimizing complexity of the management agent, the exchange of SNMP messages requires only an unreliable datagram service, and every message is entirely and independently represented by a single transport datagram. While this document specifies the exchange of messages via the UDP protocol [11], the mechanisms of the SNMP are generally suitable for use with a wide variety of transport services. From this, the authors intentionally kept things within a single datagram across any unreliable datagram service - UDP was just an obvious choice to define for the needs. > In the text that follows, the term transport address is used. In the case of the UDP, a transport address consists of an IP address along with a UDP port. Other transport services may be used to support the SNMP. In these cases, the definition of a transport address should be made accordingly. They continued to account for and allow for how other generic transport protocols could be used (at the time, not as many), rather than assume they only had the options of TCP or UDP. > In cases where an unreliable datagram service is being used, the RequestID also provides a simple means of identifying messages duplicated by the network. This shows other portions of SNMP did account for which specific features may need to be built on top of a minimal transport protocol and only added those to the specific PDUs which needed it. E.g. for this request based PDUs used by Get/GetNext/GetBulk etc they intentionally added an ID to handle message duplication, just not to every PDU, like traps, because it was unnecessary. > A limited number of unsolicited messages (traps) guide the timing and focus of the polling. Limiting the number of unsolicited messages is consistent with the goal of simplicity and minimizing the amount of traffic generated by the network management function. This shows the design of traps was heavily focused around simplicity and minimization of traffic, not based on what TCP or UDP could specifically offer. In fact, you won't find a mention of "checksum" or "hash" anywhere either in the RFC - UDP just had it as extra cruft on top of that generic "unreliable datagram service" they were designing against! . SNMPv3 did eventually add TCP as an option for traps a couple decades later, and hardly anyone ever opted to use it since as there really isn't much benefit from other transports for the use case. More have used the TLS option, but even more have just relied on the minimal, purpose defined encryption and HMACs added instead. Thanks for this discussion by the way, there is nothing more I love working with or talking about than network protocol design and history :).