Hi, On Tue, 16.03.2010 at 07:37:42 +0001, Jason McIntyre <j...@kerhand.co.uk> wrote: > On Mon, Mar 15, 2010 at 10:35:23PM +0100, Toni Mueller wrote: > > An optimizer (or any other such device) which is on by default and > > claims to not change semantics, should imho be transparent to the user, > > but this one isn't. If you have other uses of disabling the optimizer > > except for debugging pf, I'd really like to hear. > > sorry, you've lost me with the optimiser stuff ;) why are you discussing > that?
ok, I'll try again: matteo pointed me to an article which says that the problem can be bypassed by using an option to pfctl that disables the optimiser, which is enabled by default. I think that any device that automatically works on the user's input should not alter the documented semantics of what the user input, and on which the user relies. On the contrary, such devices should imho be transparent to the user, but obviously, this optimiser isn't because its use is not orthogonal to the other options of 'pfctl'. Also (I didn't mention this before), since the use of tables is advocated in about any docs (counting statements on this list in for this purpose) that I've read so far, with the optimiser being on by default, using '-R' alone should presently be impossible in the majority of real-world use cases. Therefore I advocate changing the documentation or the implementation to highlight this case of non-orthogonality. Better now? -- Kind regards, --Toni++
