David T. Perkins wrote:
I believe the interface to the notification handler needs to
be extended to include a "status". The current code "throws
away" information, which is never a good thing. I believe
that even when SNMP messages contain "ASN.1 parse errors",
that the notification handler should be told and provide
with the information that could be obtained.
What I've gone through illustrates a management philosophy,
which is that most problems are due to misconfigurations,
and that systems should be designed so that it is easy to
determine a misconfiguration and then to fix it. (Of course
the distinctions between misconfigurations, different
interpretations of specifications resulting in different
behaviors, and coding bugs are difficult to determine
at the beginning (but later on the fingers know).)
Aren't there also security considerations involved? Dropping "bad"
packets as early as possible (as we currently do) isn't all that bad, is
it? (C'mon, Wes, this must have been a buzzword for you.)
+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
