Andrey V. Elsukov wrote:
Does this accept the packet and untag it at the same time? Wouldn't
it make more sense to have [tag|untag] as its own operators like
[allow|deny]?
Yes, it does (but example is impractical - we don't need tagging or untagging
when packet is finally denied). We thought about making [tag|untag] as its own
actions like [allow|deny], but decided to implement it as modifiers instead,
for two primary reasons:
1) Speed. It is faster to match packet with body of only one rule than to do it
once more for the same packet in the next rule, only to take action on it.
2) Flexibility. We can use modifiers tag/untag with any possible actions, e.g.
allow, netgraph, skipto, pipe, ... - not only [allow|deny]. Imagine you have to
insert additional tagging rule for any such action looking absolutely the same?
And then consider speed of matching. Thus, it is even *looks* more beautiful to
write:
ipfw add 100 netgraph 300 tag 200 ip from host1 to host2
for tagging packet with tag 200 and then sending it to netgraph, than to write
something like:
ipfw add 100 tag 200 ip from host1 to host2
ipfw add 101 netgraph 300 ip from host1 to host2 tagged 200
I understand your rationale. OTOH I think it's a logical blunder and allows
some quite confusing rule sets. What I always liked about ipfw was the simple
and obvious logic in the statements. Over time it becomes more and more over-
loaded with more stuff and also more stuff breaking the beautiful simplicity
and clarity the original ipfw design had. ipfw rules used to read like normal
sentences and were really simple to write and understand. But then I'm just
ranting...
To be honest I would prefer to fix the rule evaluation performance problem of
ipfw rather than to clutter the original beautiful rule syntax logic.
--
Andre
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
