NPF and PF

[Hector <technet%netdog.org@localhost>]

A couple of years ago this bold note was added at the top of pf(4) man page:

  The NetBSD version of PF is obsolete, and its use is strongly
  discouraged.  Use npf(7) instead.

 cvs diff -r 1.12 pf.4
 ...
 $NetBSD: pf.4,v 1.13 2018/08/01 13:30:13 maxv Exp $

I am slightly concerned about the view this note might imply.

I have noticed other mailing list posts over the last year regarding
removing various obsolete network code.

I am concerned that the appearance of this note claiming PF is obsolete
and everyone should use NPF instead might be an indicator that at some
point someone might decide PF should be removed from NetBSD.

In my opinion, NPF is currently not a suitable replacement for PF.

NPF has improved some since its introduction in NetBSD 6, but it still
has some severe shortcomings compared to PF.

I have been building NetBSD routers for about 15 years, the first one
being on NetBSD 3.0.

I have some fairly advanced PF rulesets, and PF has been working very
well for me for many years.

I hope that PF will continue to be in NetBSD, despite the fact that
someone might consider it "obsolete". (I presume this to mean, nobody
has been pulling improvements over from OpenBSD for a while now.)

I would be glad to see NPF improve enough to be a clear successor to
PF, but it is not at that point now.

I would like to hear thoughts from others who have used NPF and PF on
a router.

My use cases depend on PF.  NPF is incapable of doing some things which
I currently do with PF.  If there are any plans or thoughts to remove PF
from NetBSD, I would be greatly concerned. In fact, I would like to see
PF be maintained so it is not considered "obsolete". I might be able
to work on this, if I were given some guidance.

I would be glad to enumerate some of the shortcomings of NPF, in a
follow-up message, and why I consider it to be in some ways a regression
from PF, if anyone is interested.