On Thu, 2005-10-20 at 08:18 -0700, Wes Hardaker wrote: > Dave> Another Question: what timescale are you looking at?
> I won't let 5.3 go out the door without it. Period. Fair enough. So I presume we're looking at 5.3.pre1 being next Friday, rather than tomorrow then? Which suits me fine - I just wasn't sure what had been decided. > What's out there > now is simply bad. But I should also have the time to get it done by > 5.3, assuming I can reuse the infrastructure that we have today which > I think fits anyway. I've now managed to track down the previous discussion, and refreshed my memory of what was proposed. It looks as if we'd reached a rough consensus over augmenting the VACM access table (or something conceptually similar) with additional entries to cover trap behaviour. Does that match what you've been working towards? > Dave> I'm concerned that we might rush something in too hastily, and > Dave> be forced to live with the consequences. That's perhaps a little too vague to be useful. Let's try to be a bit more concrete. As I see it, there are three potential areas where what you do now might affect things later: a) the code used to implement this filtering b) the configure directives used to control it (locally) c) the MIB interface used to control it (remotely) I presume that when you talk about "reusing the infrastructure we have", you're mostly referring to the existing vacm-related code. Yes? That's probably the least important wrt future consequences, IMO. I would hope that we could always rip the code out and start again from scratch (if necessary). I'm probably more concerned about the other two (and particularly the MIB interface). That's probably where backwards compatibility is most likely to restrict us in the future. > Dave> Wes - is this code > Dave> that you've already got waiting to be committed, or are you > Dave> talking about developing something new? > > It's almost entirely working. I'm think I'm happy to trust your coding here. (breaking the habit of a lifetime, I know, but WTH) We can always go back and Do It Properly Later :-) What do you propose as regards b) and c) above? The other relevant question is how much granularity are you planning for the initial 5.3 release? A simple "filter incoming traps" (and leave the finer-grained handling for later), or more control right from the start? If so, what? I s'pose this probably comes down to: What is your minimum requirement for letting 5.3 out? Dave ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
