This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig25358DDF06AB1F8D118EAD77
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Miles Nordin wrote:
> Keep in mind that in over two years no one has written any of the code
> rototilling ALTQ as you suggest, least of all those blocking the
> import of OpenBSD/FreeBSD ALTQ.  If you manage to redo all this, who
> will maintain it, or will it bitrot like the ALTQ we have right now?

Well, I thought there were a couple of KAME guys for that, but they seem 
to have vanished from the world.

> I think if you're going to diverge to the point of unmaintainability
> from what FreeBSD and OpenBSD has, you need two things: (1) a good
> reason for doing so, and (2) enough developer interest to keep your
> ALTQ equal/ahead of the OpenBSD/FreeBSD one.  You need both things,
> not just one or the other.  

Well, the best way would be to have ALTQ and the API in common with 
Free- and OpenBSD, for compatibility reasons, which helps getting 
relevant upstream projects (ipf, pf) to use this.

> Given the history of this problem, I think it couldn't be clearer that
> we don't have (2).  We do have Peter Postma and some others before him
> who've ported PF/ALTQ and produced something stable, but someone
> interested in rototilling ALTQ _who is also interested in DOING it and
> MAINTAINING it_, we clearly don't have.

Well, I'm very much interested in doing it, but I doubt I can do it 
alone; for the question of maintaining it, I'm not sure how that'll 
play. I don't know who the active NetBSD committers concerned with 
networking are these days, besides Peter Postma. Although I haven't seen 
him either in a while (on IRC).

> I believe we also don't have (1)---if you actually take a look at the
> PF/ALTQ API for enabling interfaces and loading queues, you will find
> that it's a totally reasonable, well-defined, even impressive API that
> can load and set things atomically using the PF ``ticket'' system, and
> although it may share code with PF it operates entirely independently
> of the PF firewall, and can be enabled and disabled independently of
> PF.  I think it's important to distinguish between rewriting something
> because it contains pieces of PF code that you want to eliminate for
> some political reason, which I would call ``purging'' not separating.
> And actual separation, where you want to use ALTQ without being forced
> to use PF.  The PF firewall is already functionally separate from
> ALTQ, even though they share some code, and I think the code sharing
> is desireable rather than a problem, to the extent the API is as good
> as something we designed ourselves, which it certainly is.

Well, you ideally do not want to be forced to compile in pf just for 
ALTQ, but sharing source is no problem, as long as that sits in the 
right place, and doesn't require pf. So basically, put the shared code 
in a different file.

Cheers,
-- 
		-- Thomas E. Spanjaard
		   tgen@netphreax.net

--------------enig25358DDF06AB1F8D118EAD77
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFDOWK46xCMwBJ+1+sRAgjVAJ4ui6owLCR9KzLARaS1hbKVllj6DgCfQu/B
u/Vsr6HPLhqK2w3aoKw2EKg=
=1fyt
-----END PGP SIGNATURE-----

--------------enig25358DDF06AB1F8D118EAD77--