* Ilya A. Kovalenko <[EMAIL PROTECTED]> [2007-09-19 16:30]: > 1. States handling > 1.1 Too complex (and weak documented)
you must be cofnused here. dunno. people rarely have problems in that area. > 1.2 Too restictive (without option to weak restrictions) > You cannot use PF's stateful inspection, if you're using > asymmetrical and/or dinamic routing well, that is not true as written, but there is some truth to it. It has annoyed me in the past, I plan to fix that somewhen in the future. > 3. Hard to debug ruleset typos > PF silently ignores unknown identifiers for some objects (for > example, tables and queues names), that leave undiscovered posible > typos. > > It is feature, I know, but ?ption to warn user about such possible > errors IMHO would be good idea. i thought we did that with -vv or so > 4. Defaults "keep state" & "flags S/SA" > Considering PF's stateful inspection peculiarities, I noted above, > keeping state by default is not such a good idea ... but it's okay > (no big problem to add "no state" to all or most rules). you are confused. not keeping state is stupid. parts of your mail come pretty offensive... maybe i should not have bothered at all. anyway. you know how things work: if you miss sth, you send a diff. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
