[Bug 1299] add set - syntax has changed - update documentation
bugzilla-daemon at netfilter.org
bugzilla-daemon at netfilter.org
Fri Nov 16 21:44:14 CET 2018
https://bugzilla.netfilter.org/show_bug.cgi?id=1299
--- Comment #4 from James Feeney <james at nurealm.net> ---
Hmm - I suspect that you are presuming a distinction that is not specifically
expressed in the documentation, when you distinguish between "a name in the ip
family" and "a name in the inet family".
You seem to suggest that any arbitrary table name exists within the distinct
context of an address family. This would imply that I could create two
distinct tables having identical table names, but defined with respect to two
distinct address families. For instance, there could exist both an "inet
filter" table and an "ip filter" table.
Now, if that understanding is correct, this point really really needs to be
expanded in the documentation, which seems to imply that individual table names
are distinct, regardless of the address family, both by showing "family" as
optional, and where the man page reads "The IPv4/IPv6/Inet address families
handle IPv4, IPv6 or both types of packets." Here, it seems to suggest that
"Inet" is simply an equivalent to both IPv4 and IPv6.
This man page conspicuously does *not* say that "ip", "ip6", and "inet" are
distinct and that "inet" is *not* equivalent to "ip" and "ip6".
So please, if that is correct, add clarification to the man page and to the
wiki.
And, back to the problem at hand, should I then dispense with using address
family "inet", and only create distinct "ip" and "ip6" tables for "set" rules?
What is the point of the "inet" address family, if it is not equivalent to "ip"
and "ip6", with respect to table names? The "inet" address family seems to
confuse things. Or, maybe its use is only "half way" supported?
--
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/20181116/133a3778/attachment.html>
More information about the netfilter-buglog
mailing list