Thank you to each of you who have shared your thoughts and voted. To make
things official, after a week I'm calling the vote with 4 in favor of
renaming the actions and 1 opposed. I'll finish up the draft PR and mark it
as ready for review.
On Mon, Jul 29, 2024 at 2:13 PM Matthew Williams <mat...@icloud.com.invalid>
wrote:
> I’d vote for 2. Rename them and we can make the allow/deny actions a
> syntax error so they get caught early.
>
> Something I wasn’t clear on, Can you confirm that this is planned for ATS
> 11 or 10.x - not the upcoming release of 10?
>
> Matt
>
> On 2024/07/22 17:44:27 Brian Neradt 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
> >
--
"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
