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>
Possibly Parallel 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 )