> I'm significantly concerned about part 3. In any transition like > this, there is a *lot* of potential for subtle bugs due to ontological > mismatches between the new and old ways of doing things. It's going > to be a defect attractor, potentially a very nasty one with security > impact (as in, what if a buggy rules transcode fails open?) and unlike > part 2 it's not one where we get a lot of insulation from the > implementor being a code-slinging wizard.
I agree that part 3 as you describe it would be very difficult and recipe for disaster. But I don't plan to do that part at all. I plan to represent the ACL rules in newly-introduced data structures and then use them directly. To apply the rules, the information we need that we'll take out of existing data structures is the contents of the packet, the association status with the sender, and the sender's rate control history. We don't have to write any new code that writes to these fields, only read from them. I looked at them before I started designing and then designed to avoid the sort of ontological mismatches that you're worried about. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel