Re: Removing PF

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	Hello.  What folks are saying is that they can't do things with NPF
that they're currently doing with PF or IPF.  It isn't a matter of having a
strong preference, it's that, in my case for example, I cannot make the
setups I currently use in production work with NPF.  And, worse for NPF,
when I point this out or ask for suggestions to implement the features I
need in NPF to make the switch, I'm met with silence, or, yes, NPF doesn't
currently do that.  Would I like a secure, mp-safe firewall?  Yes, but I
need one that has the functionality I currently rely on and, if it's not a
newer version of PF, then I need enough documentation, and documented
examples, to map a migration from the configurations I'm using and which
work, to ones which work in the new environment.  What's reiterated in this
conversation by, not just me, but at least two other folks who have joined
this conversation, is that we're not there yet.  For example, someone asked
about doing ftp-proxy with NPF.  Max claims it's been in NPF since 2011.
Ok, ironic that he himself didn't know about that until he looked into the
matter, but did he post a link on how to use this 8 year old feature in
NPF?  No, he did not.  If it's there, how do we use it?  Where can we read
about how to configure it?
	That's not the only example, but it's a concrete one we've seen in
this thread over the past 24 hours.  If you want to see NPF embraced, I
suggest the following:

1.  Make a list of the features missing from NPF that people want in PF and
IPF.

2.  Make a branch of the NetBSD tree and implement those features using the
NPF framework.

3.  When you have those features in and working to your satisfaction,
discussion can be taken up about merging them back into head.

	this approach means you don't have to worry about PF or IPF in your
branch and you can concentrate on getting NPF up to speed.  
When it comes time to merge the newly featureful NPF back into head, then
Core can decide if it's ready to drop support for PF and/or IPF.
those of us who are using PF or IPF know we're dealing with older
technology that has issues, but, I'll say it again, those technologies
currently do things that NPF apparently doesn't do.  You're just not going
to get many takers with a promise of less functionality, even if that less
functional alternative is more secure.  You will see this play out over and
over again in a myriad of environments.  

	For the sake of discussion, if I were to take on the effort of
importing the current version of PF and if I went so far as to do the work
to make it MP-safe, would you still object to having PF in the tree?  If
the answer is yes, then we're probably at an impass in this discussion.  

	My point is that you're not giving us a real choice here.  you're
asking us to sign on to a proposal that doesn't deliver functionality we
currently have, however flawed it may be.  I think we really do want to
achieve a common goal, the question is, how to get there?  Make NPF dance
and sing with feature parity  to PF and IPF and then we can discuss.  But,
I repeat myself.  And, as a final note, I'll add that it may be that
FreeBSD is discussing dropping PF as we are, but they haven't done it yet
and my guess is that they won't until they have a fully functional
replacement.  I think that needs to be true for us as well.

-thanks
-Brian