In some email I received from Jason R Thorpe, sie wrote:
[...]
> 	(4) Provides a good starting point for synthesis of rules
> 	    into native object code for very fast rule processing.
> 	    This is a project that I've already started working on.

There are a number of other implementations of this already.  I believe
one was presented at BSDcon by Bill Fumerola, there's another in the "next"
version of IP Filter...be interesting to see how they all stack up.

> The (not yet fully implemetned) ZPC packet logging facility uses a
> format that can be read with tcpdump(8) (the reason it's not fully
> implemented yet is because I need to extend the pcap save file format
> just a bit, and need to get in touch with the tcpdump.org folks about
> this).

So what you're really saying is that it can't be read with tcpdump but
you want to extend the libpcap save file format just for your logging.
Sounds like the Microsoft approach - embrace and extend except - that
you will give out patches even if they aren't wanted.

[...]
> The ZPC also has a way to load arbitrary packet processing methods
> into a filtering point and to apply them to a packet using filter
> rules.  This can be used to implement "return ICMP error" or "return
> TCP RST" types of packet blocking (see ipf.conf(5), look for
> "return-rst", or to implement NAT.  The method feature is similar
> in concept to the "call" mentioned in IP Filter's documentation,
> although IP Filter does not appear to completely implement the
> feature.

I hope this feature is disabled when securelevel > -1.  There were
numerous (and loud) complaints on icb about this feature in IPFilter
and the implications thereof.  I thought I'd mention this in case it
has been forgotten "in transit".

Darren