--pgp-sign-Multipart_Tue_Mar_15_16:45:56_2005-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "cw" == Christian Weniger <CWeniger@gmx.de> writes:

    cw> should I use pflkm?

emphatically yes.  As someone who's used both, if you use ALTQ, you
should definitely use pflkm.

I used the PF-free branch of ALTQ in NetBSD 2.0_BETA.  It was stable,
but it is old and unmaintained.  PF/ALTQ is worlds better.

The holdup for putting PF/ALTQ in NetBSD 3.0 is that ipfilter
supporters want ALTQ to work with ipfilter.  They say the problem is
ALTQ and PF have the configuration inseparably squished into one file,
and ipfilter supporters don't want to use PF.  In my opinion the ALTQ
config is well compartmentalized---it is in a separate ``section'' of
pf.conf.  The syntax of pf.conf enforces five stanzas in the file and
forbids mingling PF rules and ALTQ rules.  pfctl can be told to load
ALTQ rules only and leave PF rules unchanged.  So ALTQ is almost as
strictly separated as being in a different file, and even with PF/ALTQ
as shipped in pflkm it's quite possible to configure ALTQ queue trees
without configuring PF.  The problem is that ipfilter still does not
support tagging packets with an ALTQ queue name, and no ipfilter
supporter has stepped up to do the work of adding that, so only PF can
classify packets for the new ALTQ.

It seems wrong to me to hold up the new ALTQ because it doesn't work
with ipfilter, because ipfilter _never_ worked with the old ALTQ
either, you were ``forced'' to use <nameless legacy ALTQ
classifier> becuase ALTQ queues and legacy-ALTQ-classifier rules were
inseparabely squished into altq.conf.  PF/ALTQ is actually _closer_ to
ipfilter integration than old ALTQ because the syntax cleanly
separates queues and classifiers using stanzas and "" queue names.  So
this is not a regression.  People who won't do work want to keep ALTQ
forked at a version that hasn't been touched in like four years.  But
there is a lot of well-considered dissent to my opinion, and by using
pflkm I can get exactly what I want and withdraw from the argument.
so, sorry for ranting, but I think it's ok to bring this up once or
twice a year while it is still broken.

--pgp-sign-Multipart_Tue_Mar_15_16:45:56_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQCVAwUAQjdXoonCBbTaW/4dAQJC1AP9FOx/X+DGDREc8cnL//JNO/SOKu3GA+88
McSH0aj651/J+JA+rgCQoFj+nmveDfT7aju4x0HslJrm4bE/sus5oYYcWrIEOIu4
pnPnqt++UoIvpMpNkF3Q8tWka9fBrgbCzzoYwLbX9L5nv3VwL4z/QZr097byIgfO
j+Mcitkp+nQ=
=4Opn
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Tue_Mar_15_16:45:56_2005-1--