I would love if I could run a script as a firewall action.
this would degrade the packet forwarding performance in an unpredictable but disastrous way.
but you can log the match with custom tags, parse logs with scheduler, and fire actions as needed.
You mean like inspecting every packet with a level 7 filter does? Sometimes it's nice having the ability to do something and then allowing the engineer to make sure that it does not get triggered excessively. Rather than not allowing the engineer to have the ability to do something he might have a need to do.
there are certain "optimised" actions (like add-src/dst-to-address-list) which could have their "script" counterparts, but that doesn't mean they're the same. packet forwarding is not a thing where one want to mess with interpreted code. and running a script (executing a series of routeros commands) is actually running an interpreted code.
where i do see the quite a bit of flexibility, but it is a fundamental change how the PF code is organised. say we're just fine with a serialised code execution on a single core if it comes down to handle a flow, but that doesn't mean that cpu cycles are there to be wasted on unoptimised execution. also for me is not clear whether the script should be run in a non-blocking or blocking manner. all in all, since its just a set of interpretable code, it would be quite unpredictable whether it is to be executed parallelised or not. the result would be varying delay that could potentially affect (read: ruin) TCP throughput.
i suggested logging and parsing as a workaround, albeit it is far from perfect. but at least you'll get your messages on fw rule match in a deterministic manner, and then its up to you how those elements will be parsed and interpreted by a script or an external entity (like stuff running on syslog server) - so the desired actions could be fired.
i think this fulfils your requirements of "hands shall not be bound", but also provides enough safeguarding for the "not so creative/unexperienced" users, whose forwarding performance would be seriously degraded by running code based on firewall rule matches. and for the RouterOS developers its always a give-and-take situation, where to go, what to risk: provide a very versatile toolset where you can do anything, which can (and most probably will) result a thousands of trouble-tickets and sad faces when used inappropriately, or leave it to be solved by the excessive creativity of the few ones who actually do require it. they need to think in the dimensions of megapackets per seconds for a while, and "tinkering" does not fit into the scope no more. and there is a whole world outside of RouterOS, a lots of tools that may be used to contribute to its original functionality, we just need to think outside the box.
on the example you quoted: inspecting packets as level7 filters do. my opinion on this is a bit mixed. L7 filters offer a pretty versatile approach for packet matching, but it is not intended to be used "with every single packet". there are quite well defined guidelines - presented on regular basis on MUMs by Mikrotik folks - how L7 filters are supposed to be used, or even more harsh: shall be used. and they should not be applied to every packet. because what you get is exactly the situation i described above.
https://mum.mikrotik.com/presentations/ ... 948376.pdf
(slides 5 - 9)
(slide 13 and on)