Dave Shield wrote:
That describes how things currently work, yes.
But it relies on knowing the remote engineIDs in advance.
That's not too much of a problem when you've got a small
number of trap generators, and the engineIDs are stable.
But it doesn't scale very well to a large network, where
a single trap receiver might be working with hundreds or
thousands of nodes. And it *definitely* doesn't work
very well with the "random engineID" approach that the
Net-SNMP library uses.
Isn't this already solved today by using SNMPv3 INFORMs instead of
TRAPs? The single trap^H^H^H^Hnotification receiver is supposed to
*have* a persistent engineID and the notification generators just need
to be configured appropriately once. Not to mention the additional
benefit of INFORMs vs. TRAPs. Am I missing the problem here?
+Thomas
--
Thomas Anders (thomas.anders at blue-cable.de)
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders