+1 for option 2, rename the allow/deny action names eventually.
Thanks for explaining the current situation.
Historically, ATS has the same action names ("allow" and "deny") in the
remap.config ACL and ip_allow.yaml, but different behaviors.
I understand option 1 has the advantage of consistency with actions in
remap.config and ip_allow.yaml. However, it requires to change the behavior
of actions of remap.cofig ACL. That means it possibly be a trap of upgrading
ATS, espacially, if `deny` action is in the remap.config and not all methods
are listed up. If we rename the actions like option 2, the new ATS can detect
the old configs and warn to admins to take action if needed. Thus, renaming
seems better.
— Masaori
— Masaori
On Tue, Jul 23, 2024 at 2:44 AM Brian Neradt <brian.ner...@gmail.com> wrote:
>
> Hi dev@trafficserver.apache.org,
>
> We're processing through ACL filter action names for 10.x. For context, for
> 9.x and before, these are how actions behave for ip_allow.yaml rules and
> remap.config ACL filters:
>
> * ip_allow.yaml: These rules currently support allow and deny actions.
> allow specifies an allow list of methods for requests, with all other
> requests of different methods being denied. deny species a deny list of
> methods, with all other requests of different methods being allowed. For
> instance, an allow action ip_allow.yaml rule for GET and HEAD methods will
> allow GET and HEAD requests, but deny all other methods, such as POST,
> PUSH, etc.
> * remap.config: Remap ACLs support allow and deny actions as well, but
> these actions add to the allow list or add to the deny list for lower level
> ACL filters or ip_allow.yaml rules. For instance, a deny ACL rule for POST
> will add the denial of POST requests while allowing all other request
> method filtering to be handled by other applicable remap filters or
> ip_allow.yaml rules.
>
> For 10.x, we plan to rename the latter ACL behavior to add_allow and
> add_deny to clarify their behavior and to disambiguate them from the
> ip_allow.yaml rule actions that previously had the same name. There is a
> compatibility configuration, which will be on by default, which makes it so
> that the allow and deny actions will still function as they did in 9.x.
> Thus, 9.x remap.config ACLs will, by default, behave the same in 10.x.
>
> 10.x adds functionality to ACL filters such that they will support actions
> that do behave like ip_allow.yaml allow and deny rules. That is, a user can
> specify an ACL filter that will have an allow list of, say, GET and HEAD,
> such that only GET and HEAD requests are allowed while all other methods
> are denied, with no other filter actions or ip_allow.yaml rules being
> inspected. In this way, the ACL filter will behave like an allow
> ip_allow.yaml rule for GET and HEAD.
>
> So the question for vote is: for this new 10.x behavior, how should we name
> the ACL actions that will behave like ip_allow.yaml allow and deny actions?
> The options are:
>
> * *Keep the allow and deny action names for these filters*. These actions
> will behave identically to the ip_allow.yaml actions: that is, they will
> specify allow or deny lists, with requests of methods outside of those
> lists being denied or allowed, respectively. (Again, to make this explicit
> twice, by default ATS 10 will behave in compatibility mode in which the
> allow and deny actions will act like add_allow and add_deny, just as they
> did in 9.x. The question here is for non-compatibility mode for 10.x and
> for the default 11.x behavior) The advantage of keeping allow/deny ACL
> actions the same name as the ip_allow.yaml rule actions is that they will
> in fact behave the same and those "allow" and "deny" actions are pretty
> intuitive for ip_allow.yaml. That is, they allow or deny a list of methods.
> The disadvantage is that someone not reading the release notes in 11.x,
> say, after we remove the compatibility mode, will suddenly have their allow
> and deny rules behaving differently and this will surprise them. And, since
> we are re-using those names, ATS will not be able to warn the user of the
> misuse of the old action because it won't be able to tell the difference
> between an unintentional upgrade from 9.x allow/deny from an intentional
> use of the new allow/deny semantic.
> * The second option is to *rename these new actions* and not keep the old
> "allow" and "deny" action names at all. For consistency, since these
> actions will behave the same as the ip_allow.yaml actions that are
> currently allow and deny, we should rename those as well. The rename can be
> open to discussion, and doesn't have to hold up this vote. The vote is
> whether to keep the same name, or to rename. But, just to give some ideas
> of what this can look like, they can be renamed to "set_allow" and
> "set_deny", or "allow_only" and "deny_only", or "allow_these" and
> "deny_these". The advantage of the rename is that we will be able to mark
> the old "allow" and "deny" actions as forbidden and warn the user that they
> need to consciously choose either add_allow/add_deny or the new action
> names we decide upon using. The disadvantage is that the "allow" and "deny"
> actions are pretty clear and simple in their meanings, especially in
> ip_allow.yaml, and we would be giving that up via the rename. Arguably, if
> there weren't a compatibility issue, we would choose allow/add_allow and
> deny/add_deny. If that's the case, an interlocutor could reason that giving
> people a full release to transition is enough time to reuse original names
> capturing the semantic which otherwise makes sense.
>
> I hope that I am presenting the tradeoffs of the two options fairly, but
> naturally feel free to add comments along with your vote.
>
> Concisely, can you please vote on one of the following naming options for
> these new ACL filter action behaviors which will function like allow/deny
> ip_allow.yaml rule actions?
>
> 1. Keep the allow/deny action names.
> 2. Rename the allow/deny action names.
>
> Thank you!
>
> Brian
> --
> "Come to Me, all who are weary and heavy-laden, and I will
> give you rest. Take My yoke upon you and learn from Me, for
> I am gentle and humble in heart, and you will find rest for
> your souls. For My yoke is easy and My burden is light."
>
> ~ Matthew 11:28-30
