In some mail from itojun@iijlab.net, sie said:
> 
> >This last step seems premature.  Given that there has been lengthy delays
> >in the past with the integration of KAME work into NetBSD, I see no need
> >to start rushing now, especially when there are issues that need to be
> >resolved first.  I've seen no support, for this integration work besides
> >Jason saying that one less packet classifier in the kernel would be good.
> 
> 	by saying "KAME code" it can mean a lot of different components, so
> 	i see in your statement some over-generalizing.

I am generalising, yes, but quite deliberately doing so becaues it
is not possible to separate the components, any more, in the manner
desired.

> 	you misunderstood why there are lags between KAME IPv6 tree and NetBSD.
> 	we specifically integrate things that made RFC status, or alike,
> 	from KAME IPv6 code to NetBSD.  therefore we waited 2292bis API
> 	discussion to settle down into RFC3542, for instance.

Sometimes bugs take, IMHO, too long to get fixed in NetBSD after being
fixed in KAME.  Don't ask me for specifics, it's just my feeling after
trying to get IPSec to work with NetBSD (I think soon after 1.5 came
out?), had problems, found some things fixed in KAME but not even in
NetBSD-current.  Maybe that situation is better now, maybe it is not.
I still can find months-old IPSec in KAME code that has not made its
way into NetBSD when from my perspective, it should have but then it
is possible I just don't understand the KAME code quite well enough
to make a correct call on it.  I can understand that it is not a
quick and simple process to ensure bugs get fixed in all the platforms
you support as they are fixed in KAME's CVS but lets not rush into
making the situation a bigger problem than it already is.

The problem, for me, is not with the stability of pf (in terms of
does it crash or work) but that the integration of pf/ALTQ has not
matured enough.  You already have one testing ground for this work -
OpenBSD - so why do you need NetBSD to be yet another one?

Now, am I going to have to repeat myself again on API issues or
have you understood what I've said to date about the problems
with the current design being found in need of review and change ?

Then there are comments from Kenjiro which suggest that the work
is far from complete yet, in ALTQ, so you don't really have a
finished product yet to integrate.  Now even if you did, and this
were it, I think I would be recommending to KAME that they go away
and spend some time improving on the current design to satisfy the
requirements for integration into NetBSD.  As I've indicated in
other emails, I would he happy to support the integration of this
work when it approaches a point that I would call "finished".
I do not believe KAME is near that point and comments from Kenjiro
support that.

Even if you were to say Kenjiro is wrong (which alone would be cause
for great concern about KAME itself), my reply to you and KAME would
be that the interface you are proposing to merge is not yet of a
suitable nature for inclusion in NetBSD.  Just because it is good
enough for OpenBSD does not mean it is necessarily good enough for
NetBSD.  It is like you are trying to force the bar to be lowered
enough so that an unsuitable solution can be merged rather than
trying harder to get over the bar even though it has been raised a
little.

Now, the question is, are you interested in working with us or are
you interested in working against us ?

If you are willing to work with us then you should be prepared
to take back constructive comments that make the KAME code better
rather than trying to force down our throats something that is
generally considered to be unpalatable and come back with something
that we are all happy with.  That isn't so hard, is it ?

Cheers,
Darren
p.s. I've read your other replies and have responded, as appropriate
within this single email.