On Sunday, June 29, 2003, at 04:40  am, itojun@iijlab.net wrote:
>> 	i really hope this atmosphere to change.  by working on KAME project
>> 	which is trying to create a good code that benefits all BSDs) i'm
>> 	trying to do so.  KAME have made some improvements which needs PF (at
>> 	this moment), and i'm asking for permission to commit
>> 	PF-for-netbsd-current, as it is too painful to maintain local patch
>> 	myself (as said earlier i work on multiple platforms, current and
>> 	release w/kame, in parallel).
>
> 	also note that i'm not the only one who want PF on netbsd.
> 	(including Joel Wilsson)

And a whole bunch of others who have emailed me privately about it.

(this is a bit of a rant, it's 5:30 am, but here goes)

Let's not get angry at each other over this. I think both Darren and 
Thor
raise some valid points, especially about the latest (?) ALTQ having
hardcoded calls to pf.
That's not a good design, unless you really do want to merge pf and ALTQ
completely and not be able to use ALTQ separately. If I understood
Kenjiro correctly, you don't intend to do that.

On the other hand, I don't see why it's so horrible to have to configure
ALTQ through pfctl, even if you don't use pf for filtering. It doesn't
seem to be a big deal.

What would change if the new ALTQ code was imported, and pf along with 
it?
1) You would be able to choose among pf and IPFilter for packet 
filtering.
2) You would no longer be able to configure ALTQ directly, but would 
have
    to go through pfctl instead.
The first is good, the second seems like a minor problem (or feature).
So I must be missing something here, let me know what.

If I understand Darren correctly, he's worried that ALTQ won't get a
generic API that is not dependent on pf. That's reasonable, if he wants 
to
add support for ALTQ in IPFilter. Can you (itojun or Kenjiro) make that
clear? Kenjiro wrote earlier that an API wouldn't be necessary, but I
disagree. Will ALTQ once again be free from pf, ever, and if so,
in how long? If IPFilter doesn't support ALTQ right now, it doesn't 
matter
if ALTQ will depend on pf for a while - but it should not stay that way.

On Sunday, June 29, 2003, at 03:14  am, Thor Lancelot Simon wrote:
> Consequently, the suggestion that NetBSD should
> rip out a major piece of infrastructure and replace it with one
> for which meaningful development participation requires OpenBSD
> development status (as you yourself said) seems like a very poor
> idea to say the least.

I don't think anyone is suggesting that NetBSD should rip out a major
piece of infrastructure (I assume you refer to IPFilter, but it's not 
very
clear) and replace it with pf. IPFilter should of course still be 
available.
There is absolutely no reason why it shouldn't.
And you have the source to pf, you don't need OpenBSD development 
status to
work on it. Just like the OpenBSD guys don't need NetBSD development 
status
to work on e.g. uvm.

To be honest I found this statement:
"you can join openbsd project if you would like to participate PF
  development"
a bit arrogant, even if it wasn't intended that way. Many people simply
can't join the OpenBSD project, for a number of reasons
(Thor have explained some of them, but there are other, less spectacular
  ones like "I don't have time", "I want to focus on one project", etc.)
The good thing is, they don't have to do that just to improve pf.

Be nice to each other and think about a way to solve this, and I'm sure 
we
can come up with a solution we're all mostly happy with. Don't commit
anything before that, as it'll only do more harm than good.

Goodnight,
   joelw