HI, 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).) Regards, /david t. perkins On Wed, 24 Aug 2005, Thomas Anders wrote: > David T. Perkins wrote: > > I would hope for the following changes for USM: > > 1) with no users configured, you should be able to recieve > > both noAuthNoPriv TRAPs and INFORMs (but maybe > > the output should be marked) > > 2) on authNoPriv TRAPs and INFORMs, if there is a > > problem (user doesn't exist, authentication failure, > > "out of window" when not doing engineID (and clock) > > discovery) then I believe that the notification > > should still be outputted (but marked with the > > failure) reason > > 3) on authPriv and a failure, an output should still > > be done, but with an error indication that the > > message content is not available. (there is still > > available the values from UsmSecurityParameters. > > Thanks a lot for your valuable, detailed suggestions. While this surely > needs further thinking and discussion (Wes?), my initial concerns are: > > - (How) can this fit into the current architecture where an incoming > message is (AFAIK) considered to either pass or fail the security checks > (and to be dropped in the latter case), but not "pass/fail with comments"? > - Your suggestions focus on "output", but how to deal with traphandlers > then? We currently handle logging and traphandlers very similar and we > even have a fixed format for handing notifications to traphandlers, so > they cannot be easily "marked" w/o breaking compatibility, AFAICS. > > > My initial $0.02, > +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 > ------------------------------------------------------- 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
