Re: [PATCH] AND and OR ACLs v15

Amos,

    I do not think it makes sense for the two of us to argue about this
further. This is a design decision, with pros and cons on both sides,
and no way to logically prove the other side wrong. Our opinions differ,
and each of us feels strong enough about this issue to defend their
view. We can do another round of arguments (and I certainly have
ammunition to dispute all of your latest assertions!), but I doubt
either of us will change his position after another round.

Unfortunately, I only got one private comment about this so far
(supporting my point of view). If there is still not enough public
discussion to form a different consensus, I will use your +0 vote to
commit the latest version (where all equally named ACL lines are ORed,
like they are today) in a few days.

>> If we want to play it safe at the expense of folks who know what they
>> are doing, we can prohibit multiple lines for all-of ACLs on the grounds
>> that they are "too confusing for admins". I do not think we should do
>> that though. It feels very wrong to cripple a powerful optional tool
>> just because somebody will misuse it. However, we may want to do that
>> when we add an "=" acl:
>>
>> acl good = (a or b) and !c
>
> Indeed, it would a huge effort to alter every single config out there
> and all the documentation ... Safe_ports ACL has been documented for
> over 20 years as multi-line single *set* of port numbers.

No change of old configs and documentation would be needed. I did not
suggest an "=" ACL as a mandatory replacement of existing ACLs. An "="
ACL is just a more natural way to define short but complex conditions
(as opposed to long lists of simple, repeated conditions -- something
current ACLs do well enough). However, I do not want to hijack this
thread with the detailed discussion about another new ACL.

Cheers,

Alex.
Received on Tue May 21 2013 - 14:59:22 MDT