On Sun, Jun 29, 2003 at 11:36:56AM +0900, itojun@iijlab.net wrote:
> 	i do read all part of your response, but i chose not to comment on each
> 	lines, as it does not seem to be productive for me.

Okay, fine.  What I don't understand is how you can fail to dispute any
of the underlying facts, nor any of the reasoning, but then assert --
quite forcefully -- that my conclusion is false.

> >I can't see how the actual facts would not be rather disturbing to just
> >about anyone who took a careful look at them -- but wishing inconvenient
> >or disturbing facts out of existence, sadly, is not a productive way to
> >deal with them, any more than calling those who point them out liars.
> 
> 	excuse me?  i apologized about the strong statement i've made a couple
> 	of minutes ago.  and you still keep blame on me on that?  i see why

Look, I accept your apology, and I thank you for making it; but that hardly
requires me to consider calling me a liar a productive method of discourse!

Similarly, I don't call ignoring inconvenient facts a productive method of
discourse.  And what I said about many NetBSD developers being unable to work
on OpenBSD because they have been expelled therefrom or denied developer
status or told not to even bother to ask for is is, indeed, factual.  The
obvious next logical step from there is that "you can just go be an OpenBSD
developer if you want to work on PF" is not really a useful thing to say when
some of those developers voice some concern about whether we would be
importing a major system component over which we have, essentialy, no control.

If you want to persuade people that what you want is the right thing to do,
you need to stop exploding at them when they dispute some of your reasoning
or point out that some of your facts aren't.  I'm glad you aren't calling me
a liar any more, and I'm also sorry that the discussion got as heated as it
did, but I think we've ended up pretty much where we started:  NetBSD
developers are concerned about replacing a major system component with one
whose canonical sources we don't really have any way to contribute to, and
there's really been no significant effort made to address that concern --
because "you can just go work on OpenBSD" simply isn't a factual statement
for many of us!

> 	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).

I understand that.  From my point of view (and, if I understand what they
have said correctly, that of a few other NetBSD developers participating
in this discussion), the only real problems are that use of PF is
currently hardcoded into the KAME code you want to import, that some of
the people working on our network stack and packet filter don't really
feel free to contribute to PF development (or, in some cases, development of
the underlying KAME code) and that PF and our existing packet filter don't 
really coexist peacefully, which means that the change you want to make is
tantamount to forcing anyone using the KAME code in question to punt our
existing packet filter.

I thought Darren's suggestion of importing a slightly older ALTQ into
NetBSD while cooperating to work on a formal API for use of other
packet filters with KAME was a pretty good one, but I can see how it might
not really appeal to you or to the other KAME developers.  Do you see any
middle ground that might work better for all involved?


-- 
 Thor Lancelot Simon	                                      tls@rek.tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud