bugzilla-daemon at netfilter.org
2017-Mar-23 08:20 UTC
[Bug 1137] New: Element "flow tables" should not be syntactically unique...
https://bugzilla.netfilter.org/show_bug.cgi?id=1137
Bug ID: 1137
Summary: Element "flow tables" should not be syntactically
unique...
Product: nftables
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P5
Component: kernel
Assignee: pablo at netfilter.org
Reporter: rwhite at pobox.com
So this doesn't rate a bug, but it did confuse me.
Flow tables are always named, but they don't conform to the way sets, maps,
and
dictionaries work in terms of "add" and "delete" and all
that.
They are also "flow tables" instead of one word like "flows"
or "throttle" or
something.
It seems weird to just have these break the syntactic expectations.
I think, long-term, that picking a one word designation like "rate" or
"gauge"
and making them syntactically similar to sets with a type and flags at the
table level, and using @name syntax or having them be unnamed in place, would
make much more sense.
It's especially confusing since "list map tablename mapname" and
"list flow
table tablename flowname" are so similar in function but have a different
word
count and are not orthogonal to add and delete and clear etc.
So if they were just like sets this would be so much less confusing.
table ip example {
gauge dhcp_throttle {
type ipv4_addr . inet_service
flags whatever, whateverelse
}
On 03/22/17 16:25, Pablo Neira Ayuso wrote:> This would provide a way to restore flow table between reboots, so we
> could even per populate them with elements.
chain dhcp_traffic {
gauge { ip saddr limit over 200/day } drop
gauge @dhcp_throttle { ip saddr . udp dport limit 3/second } accept
}
}
On 03/22/17 16:25, Pablo Neira Ayuso wrote:
> This would resolve the inconsistency, yes.
> I would still stick to 'flow table' instead of 'gauge'. I
was never
> comfortable with the fact that we overload 'table' with more
semantics
> (given we already have tables in nf_tables).
On 03/22/17 16:50, neal.p.murphy wrote:> Instead of gauge, would meter, track, watch, or measure work better (and be
a little more self-documenting)?
--
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170323/72223089/attachment.html>
Apparently Analagous Threads
- modifying bandwidth
- [949] branches/wxruby2/wxwidgets_282: Changes in Gauge API 2.6->2.8, remove comment cruft in header
- as.Date(Inf) displays as 'NA' but is actually 'Inf'
- [1124] trunk/wxruby2/samples/bigdemo/wxGauge.rbw: Use Wx::Timer instead of evt_idle to drive Gauge sample, to avoid 100%
- Function that is giving me a headache- any help appreciated (automatic read )
