Re: Removing PF

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

	hello.  My suggestion is, rather than strongly advocating for the
removal of pf, which your message readily conceeds has more functionality
than npf does at this time, why not marshall an effort to get the missing
features from pf into npf?  I totally understand that the work to improve
NPF's scalability and robustness is vitally important, but if you want to
get consensus on removing npf, let's now get the additional functionality
into NPF.  Once done, we can discuss removing pf again.   At the risk of
being extremely rude, although that is not my intention, if as much effort
had been put into improving  the functionality of NPF as has been put into
the effort to get pf removed, I dare say, NPF would now be up to PF in
functionality and the conversation would be easier to have.

	right now, NPF doesn't do what I need and from what I can tell in the
documentation, I'm not sure how to write the functionality into NPF.  that
leaves me with the task of  porting PF to a newer version of NetBSD on my
own, with no support from fellow NetBSD users, running an older version of
NetBSD as long as is feasible, or switching to another OS.  You say the
effort to port   modern version of PF to NetBSD is greater than writing the
additional functionality into NPF.  Yet, somehow, after years, that
functionality is not in NPF.  If it were that easy, I think it would have
been done.  And, prey tell, why is it harder to maintain a modern version
of PF than NPF?  If, for the sake of discussion, a modern version of PF were
imported and it were modified to scale with the new features of the network
stack in NetBSD, what would make it harder to maintain than NPF, which has
absolutely no market share outside of NetBSD?  If it is simply that you
don't want to do it, that's fine, but fundamentally, I don't really see
what's harder about maintaining one piece of code versus another.  The
documentation for PF is much more complete than it is for NPF, and when I
looked into the NPF source code, it looked like I would hav to grow a lot
of features in NPF to gain parity with PF.  And, once done, all those
features would have to be maintained going forward, not to mention that
there would be absolutely no testing outside of the NetBSD environment with
NPF.  And, even if the PF code in NetBSD differes from  PF under OpenBSD,
there would be enough similarity that some cross testing and patching would
be helpful.
	I know you fundamentally disagree with this analysis and I understand
you are more familiar with the specific code inn question than I am, but I
think the fundamental problem here is that the NetBSD network stack is in
flux as folks work to MP-ify it and, the truth is, any firewall
implementation in the stack is going to require a lot of effort to keep up
with those changes.  As you've noted, firewalls are hard to write and
maintain.  NPF might be a better solution than PF or IPF, but it certainly
doesn't have as many eyes on it and there are a lot of folks who know how
to use one or both of the other solutions who don't have a clue about how
NPF works or should be configured.  I think dismissing that knowledge from
the equation is a mistake and should factor heavily in the decision about
which way we should go.
	I also think Core should consider funding a project to either add the
missing functionality to NPF, along with improving the documentation,  or
funding a project to bring PF up to modern standards of functionality and
scalability.

-thanks
-Brian