On 10.04, Pablo Neira Ayuso wrote: > On Fri, Apr 10, 2015 at 01:05:33AM +0100, Patrick McHardy wrote: > > On 10.04, Pablo Neira Ayuso wrote: > > > On Fri, Apr 10, 2015 at 12:45:05AM +0100, Patrick McHardy wrote: > > > [...]: > > > > I want this decision to be made based on what users actually need and > > > > on what they need it for. Not basically pull in everything from iptables > > > > in one go without even thinking about it. > > > > > > > > As a middle ground, I think I could agree to adding the xt compat > > > > framework, but only allow selective extensions to be used where we > > > > are sure we need them. > > > > > > The framework fully supports this, imposing an artificial limitation > > > makes no sense to me at all. > > > > I'm aware that its technically possible, the question is a different one. > > Then, if it's technically possible with the existing kernel framework > (and exposed to userspace), there is basically no way that we can > limit what userspace can do with this. I'm repeating myself. We'll have iptables in the nft ruleset. We can't get rid of it because we don't understand it and we don't want to understand it. This is the major difference to translating on every load. Once its in the nft ruleset, it stays there. We loose control. We can't transform it anymore. Its an opaque blob. > > > Admit it, there is no way we can control what users will do in the > > > future. The only way out is to move forward in an evolutionary > > > fashion. > > > > Right. But this is not evolutionary. It pulls everything we have in > > iptables in nftables in one big dump. Its the opposite of evolution. > > An evolutionary process would be to grow things as they are needed, > > which is what I'm suggesting. > > No. Evolution is to extend things from what you already have, and let > just things extinct by providing better alternatives. So we're evolving nft into supporting iptables in order to extinct it? That makes absolutely no sense. I agree that we need to provide a way to move people over smoothly. But I'm absolutely against doing this without even considering the consequences and arguing about it on this level. It starts with a problem statement *why* we would want to do this. And this is to provide access to features we do not support so far. This implies its about features we actually do want to support at all, and excludes features we do already support. This means selectively enabling the remaining ones is what makes sense, and even that is a hard call for the reasons stated above. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
