On Mon, 2 Jul 2012, Amos Jeffries wrote:
> As you say Mr Dash Four brings up a good point about confusion. It certainly
> seems to confuse him/her, and very likely others with less documentation
> reading experience.
>
> IME the practice when this type of thing happens is good to find some
> alternative clear naming for the parameters and to deprecate the old ones.
> That allows the old names to be dropped from documented use, but kept
> supported for existing config with a warning that admin need to check the docs
> for new usage.
>
> For myself, given the man page snippet it is clear what you intended src/dst
> to be the "local" src/dst. But it is inconsistent with iptables usages of
> src/dst and will trip up anyone not reading that page. Which is not a good
> situation to be in.
>
> Having been in that situation myself I sympathize and had this same argument
> about the same scope concept with other developers several times now. We
> usually end up using some form of "local" terminology for the box internal
> details to differentiate from end-to-end scope terminology. In this case
> --iface-ip / --oface-ip would probably be the clearest contenders for your
> selection. But that is up to you.
The issue is related to the hash:net,iface type alone and only the
interface part of the type: which interface is the "source" of the packet
and which one is the "destination". (There's no problem whatsoevert to
associate "src" and "dst" to the IP addresses/port/MAC of the packets.)
Maybe ASCII art helps better to explain the different views:
- Mr Dash Four
-----------
pkt comes in ----- | machine | ----- pkt goes out
^ ----------- ^
destination source
- my view follows how the subsytem sees the interfaces
------------------
pkt comes in --- interface | ipset subsytem | interface --- pkt goes out
^ ------------------ ^
source destination
As we learned, the latter is wrong and inconsistent, moreover buggy.
"src" and "dst" are generic keywords of the set match and SET target of
iptables/ip6tables and independent of the set types. The match and target
have no idea what is "src" and "dst", the given set interprets them
according to the type.
Also, it is not possible to introduce alternate keywords just for the sake
of the hash:net,iface, because ipset supports list of sets and in that
case the underlying sub-types are practically unknown to the match/target
(and additionally can be changed anytime).
Best regards,
Jozsef
-
E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
