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
