>A gentle reminder that we currently have two independnet IPsec stacks
>in the tree: the original KAME code, and a port of Sam Leffler's fast-ipsec
>(which is in turn a careful re-tuning of Angelos Keromytis' OpenBSD work).
>
>Fast-ipsec has been carefully implemented to preserve the existing
>KAME PF_KEY api.  The assumption in committing fast-ipsec was that we
>would preserve the PF_KEY api until fast-ipsec has working v6 support,
>at which point I assume we cut over to fast-ipsec).
>
>(I beleive I stated here that, all along, an eventual goal for
>fast-ipsec is to make its impact on non-IPsec traffic negligible (at
>least when no SPD rules are present) so that we can confgure it on
>by. default. That implicitly less means the IP portion of the KAME
>stack has, at best, second-best status.)
>
>Anyway ...  if we go down that route, then during the transition
>period, changes to the PF_KEY API have to be synchronized across both
>IPsec implementations.  Ad-hoc changes to the PF_KEY api (or abi) in
>one will likely break the other.
>
>Can we agree to not do that?

	i don't understand why sys/netipsec has to have another PF_KEY
	implementation.  could you tell me why?

itojun