On Dec 18,  4:51am, Martin Husemann wrote:
} On Thu, Jul 28, 2005 at 01:13:16AM +0200, Marcin Jessa wrote:
} 
} > I really like to know that too and if there is any work done on ALTQ
} > integration with pf.
} 
} Nothing realy happened for a far too long time - but stay tuned, I plan
} to collect all the loose ends ASAP and push this issue further.

     I think I have commented on this before.  However, what I would
like to see is something akin to the way Cisco's IOS works.  Under IOS,
you define an access-list then you assign it to various places.  I.e.
first you create an access-list:

access-list 100 deny ...
access-list 100 permit ...
access-list 100 permit ...
etc.

Note that under IOS, there is an implicit deny all at the end, so
anything that isn't explicitly permitted is denied.  I'm not wedded to
this particular detail, so I don't care which way NetBSD goes on this
issue.  After the list is created (you can create as many as you want),
you assign particular tasks to it (i.e. filtering inbound {or outbound}
packets on an interface, determining QOS treatment, determing whether a
packet should have IPSec applied, determining whether a packet should
have NAT applied, determing if a packet should cause a dynamic PPP
connection to be established, etc. (there are many other things such as
controlling SNMP access that probably aren't applicable to NetBSD):

interface f0
  access class 100 in
  access clase 101 out
...

     I think integrating pf and ALTQ is vary much the wrong thing to
do.  This would make ALTQ only usable with pf.  Using the above idea,
we seperate packet classification from treatment.  This would allow any
packet classification engine (i.e. pf, ipfilter) to be used with any
packet treatment.  Giving flexibility like this seems to me to be the
right way to go and to me would be the NetBSD way to do it.

}-- End of excerpt from Martin Husemann