Design proposal for a better ACL language

[Daniel Franke]

> 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.