Re: Proposed Improvements to NPF

[Greg Troxel <gdt%lexort.com@localhost>]

This is the right place to discuss, and I believe more or less everyone
within NetBSD who is contributing to npf or interested is subscribed.
It's great to see more people wanting to improve npf.

See also doc/TODO.npf.   The projects list and the doc file may not be
100% aligned..

Random advice:

  Keep separate things separate.  You've listed three things, and I'd
  recommend doing the first, and then seeing where you/we are, and
  making a new plan -- which might well be "do item 2".   This is a
  blend of beliefs: 1) that it's easier to do two parts separately
  than the combination, and 2) "evolutionary delivery" a la Gilb, which
  is that after you make one improvement your opinions about the next
  will likely change.

  This list is a bit cantankerous, with lots of strong opinions.  First
  write down the behavior you want to implement with rationale and run
  that up the flagpole.  Next is a design sketch, and then
  code/docs/tests.


I find groups to be much trickier than they seem, and it would be great
if someone really understood the flow and aligned code/docs.   My
belief about the code, a bit beyond the docs, is:

  - there isn't any nesting of groups
  - groups are ordered
  - if a group is evaluated and no rule matches, eval continues with the
    next group
  - if a group's eval finishes and >=1 rule has matched, then that's the
    result for the entire ruleset

But if what you mean for 1, in addition to

           group "my-name" in on wm0 {
                   # List of rules, for packets received on wm0
           }

being able to write

           group "my-name" in on { wm0, wm1, vlan3 } {
                   # List of rules, for packets received on wm0
           }

then I think that's orthogonal to cleaning up overall group semantics,
and sounds sensible to me.