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

Reply via email to