Re: rfc: delay SNMPv3 engineID probe til needed by default?

>>>>> On Thu, 14 Apr 2005 17:01:27 +0100, Dave Shield <D.T.Shield@csc.liv.ac.uk> said:

>> The question is, what should the default behaviour be?
>> Always delay the probe ... [or] allow a failed probe to
>> successfully return, and set up to retry the probe when needed.

Dave> Either of those two would be acceptable.

IMHO,

1) I agree the current code is non-optimal and always has been.
2) I didn't write it ;-) I think, actually, it might have been Joe
Marzot
3) The motivation at the time, if I recall, was simplicity. IE, it
was going to take less code and we were on a tight schedule. You
know how it goes "we can fix that later". Well, you know how it
goes "later =~ 5 years" or so now?
4) I don't think changing the behavior will break many applications
(starting a session to do a probe is *never* something we've said
the library should be used for, so if they're doing that they're
both odd and a small case).
5) thus, I would choose one of:
a) have the new behaviour to probe later with a new flag to probe immed.
b) have the new behaviour to have a new flag to probe later
c) leave as existing

Obviously c is what we're trying to avoid, b is probably safer but I
think we should do a because I doubt it'll affect anyone and if it
does it'll be 1) experts and 2) 1-2 people at most I'd think. We
could always revert it later if I'm wrong.

The backwards compatibility goal is not absolute in my mind, it's we
shouldn't break existing behavior when it affects a ton of people or
even a sufficient (intentionally vague) number of people. I don't
think this falls into that category.

--
Wes Hardaker
Sparta, Inc.


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders