I'll repeat what I've said here before:

pf does not solve the single biggest problem IPFilter has.

IPFilter that is currently in NetBSD is quite dated, in some respects.
The next major release of IPFilter will go some distance in making it
better and contains the foundations for making upgrades painless.
Note, however, IPFilter doesn't exist only in a constant development
model, only, rather it exists to support users on a stablising version
that might exist for some time, a model that is seemingly foreign to
some.

Some questions for KAME people...

Do you have an official interface description for how other providers
of packet classification can integrate with ALTQ or do we need to
RTFS ?

Are you prepared to commit to providing a stable API or will others
have "API of the month" issues with ALTQ/KAME updates ?

Did you give any consideration to making ALTQ able to work with 3rd
party (and I'll group pf & ipfilter in that) packet classifiers in
general or have you just decided to adopt OpenBSD's changes that
put pf specific references into ALTQ ?

Would KAME take back changes to ALTQ that made it open to supporting
packet classifiers, in general rather than a different, specific one ?

Or is KAME interested in doing such work itself ?

Kenjiro, if you are serious about external packet filters for KAME's
IPSec then shouldn't this be the logical next step in ALTQ's evolution ?
(At present I notice hard coded references to pf...)

If ALTQ is going in that direction anyway, maybe we should just wait
until the ALTQ API is decided upon and finalised for general use before
integrating the new version of ALTQ into NetBSD.  Fewer changes and
less pain for NetBSD users in general.



And just in case anyone is wondering, I don't think those behind
ALTQ ever asked or approached me about collaboration (or at least
I don't recall any such email conversation.)  The reason behind
ALTQ/pf collaboration is...well...I'm sure NetBSD'ers will have
their own suspicions without me saying anything.

Darren