Talk:Simple Network Management Protocol
From Wikipedia, the free encyclopedia
| This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
| ||||||||||||||
Introduction to SNMP, with an overview of RFCs
RFC 3410 provides a valuable introduction to the SNMP framework, and an overview of the many RFCs relating to it.
There should be a History section
Given how long SNMP has been around (32 years), there should be a History section in this article.
Resource: RFC 1067, from August 1988: https://tools.ietf.org/html/rfc1067
-- Dan Griscom (talk) 14:58, 18 March 2020 (UTC)
See also
Can someone please fix the typos in the See also section? Siimulator and one other one affected by this "dash=, " thing, I can't see how to edit — Preceding unsigned comment added by 217.169.1.237 (talk) 19:34, 5 October 2021 (UTC)
Atomic Operations
The article claims that for GetRequest and SetRequest PDUs that agent interactions are made atomically. Please provide a reference for these claims from the defining RFCs. At first blush they seem to be untrue. 149.32.192.40 (talk) 14:12, 22 May 2025 (UTC)
- Finding the reference for writes was trivial, but I couldn't find one for reads in the RFC's. I do think atomic results can actually be crucial for correctness, but my practical experience is rather limited, so I don't dare make any bolder claims :-). I've added the reference and added citation needed to the other claim. This is more visible than just a talk page section, and also alerts readers that the claim is disputed.Digital Brains (talk) 15:30, 22 May 2025 (UTC)
- Thanks for the quick response. But your reference for writes (RFC1157) is a recommendation (should) not a requirement (must.) From personal experience, not very much is atomic in SNMP. I lean toward removing the atomic claims in both cases. It's an important concept, there's nothing saying the fill of a multi object get PDU is atomic and thus time coherent. At least that I know about. Apologies if I am wrong. 149.32.192.40 (talk) 17:44, 22 May 2025 (UTC)
- Note that RFC 1157 predates RFC 2119, and that the word should, correspondingly, is also not in all caps. So I think we can't now for sure whether it's a recommendation or a requirement. I suspect I read it as prescriptive precisely because it was not in all caps. I definitely would have interpreted it as a recommendation if it was in all caps. But yeah, I agree, it doesn't look good for the claim, I agree with removing it. Digital Brains (talk) 18:47, 22 May 2025 (UTC)
- No wait, SNMPv3 does actually say it's mandatory. I'm not going to edit any more right now, but RFC 3416 page 22 says
Each of these variable assignments occurs as if simultaneously with respect to all other assignments specified in the same request.
- Digital Brains (talk) 18:53, 22 May 2025 (UTC)
- Note that RFC 1157 predates RFC 2119, and that the word should, correspondingly, is also not in all caps. So I think we can't now for sure whether it's a recommendation or a requirement. I suspect I read it as prescriptive precisely because it was not in all caps. I definitely would have interpreted it as a recommendation if it was in all caps. But yeah, I agree, it doesn't look good for the claim, I agree with removing it. Digital Brains (talk) 18:47, 22 May 2025 (UTC)
- Thanks for the quick response. But your reference for writes (RFC1157) is a recommendation (should) not a requirement (must.) From personal experience, not very much is atomic in SNMP. I lean toward removing the atomic claims in both cases. It's an important concept, there's nothing saying the fill of a multi object get PDU is atomic and thus time coherent. At least that I know about. Apologies if I am wrong. 149.32.192.40 (talk) 17:44, 22 May 2025 (UTC)
check applicability of read-write community string?
There are a couple of sentences in the main article "The read-only community applies to get requests. The read-write community string applies to set requests." This doesn't feel correct to me. This seems to imply that the read-write community string cannot be used in a GET request. If that were truly the case, it doesn't seem to make sense (to me, at least) that it be called a "read-write" community string. (I don't have references 9 or 10 on-hand to check what those original references say about it.)
My (limited) experience with SNMP devices is that they all-but-one allow the "read-write" community string to be used for a GET request. After I encountered that one device that refused my GET request while I was providing the "read-write" community string, I came here to see what information was present here, and this has led to my question. ~2025-41581-51 (talk) 15:14, 18 December 2025 (UTC)
