I fail to see how your answer addresses my point above, which I raised
in response to the restriction imposed by "solution a." of not allowing
in/out in a list:set where there could be hash:net,iface members
registered.
My answer stated the conditions which any solution must satisfy.
Which wasn't what I asked originally, was it Jozsef? Even if that was
the case and I did ask you that, I fail to see how "solution b" isn't
enforcing what you have just written above.
On the contrary, with regards the result being "the same", there is no
difference between "solution a." and "solution b." - I think we can both
agree with that, right? Regardless of whether in/out or src/dst has been
used in a list:set, it will produce the same number of results - I have
never stated, nor implied otherwise! Where do you get that from?
So, the difference then, is that "solution a" places a restriction on
the use of in/out in a set (i.e. prohibits it) where hash:net,iface
members can be registered and it is exactly what I asked you to justify?
Let me repeat that again, for your own benefit: How do you justify the
restriction your "solution a." places when someone is forced (by your
own words, not mine!) to use src/dst only (and not in/out, in addition
to src/dst) when hash:net,iface set needs to be registered as a member
of list:set, given your "unhappiness" expressed by yourself just a few
days earlier (see more on the semantics of that below) that same
restriction imposes, and also given that regardless of whether in/out or
src/dst is used, the "end result", i.e. the number of matches produced
will *not* be any different and dependant on the options used in that
list:set?
You know very well that by allowing in/out alongside src/dst in a
list:set this *will* produce the same members match - that was your
previous objection for not allowing in/out to be used alongside src/dst
in list:set, until I found you this solution and then you swiftly moved
the goalposts, again!
The goal - for me - is the same from the very beginning: an alternate
syntax must be what it is: just an alternative. The result cannot depend
on which syntax is used.
And how is that any different from what I have just written above?
I don't favour b. Ugly like hell, a. were much cleaner.
You couldn't make this up! I mean, really Jozsef?
In a couple of hours yesterday, you went from:
"Solution b. is also acceptable but it's more controversial", then
"Therefore I'm not really happy with solution b. but I can stomach it",
I don't have to like a solution. This one is controversial. Originally I
came up with it, but I don't like it.
No. What you have "come up with" was that initially this same solution was:
1. "acceptable, but controversial"; then
2. "I am not happy, but I can stomach it"; followed a few hours later by
3. "I do not favour it, ugly like hell";
All this, given your initial reaction of that same restriction being, at
best undesirable, at worse unacceptable.
Let me ask you this then: Do you think all of the answers I listed above
are consistent?
and finally, the above answer, not to mention that you started all of
this with you being "unhappy" with users being "forced" to use src/dst
only on list:set types.
Here is my paragraph you might think of:
"You must handle the case of the list:set type: how should then the new
"in", "out" be interpreted? Or should those be rejected? But then it'd
mean that if someone used a hash:net,iface type as a member of list:set,
then he is forced to use "src", "dst" only."
I asked questions. Did I write I was unhappy if only src/dst were allowed?
No. The only thing I stated was that the case of list:set types must be
handled. Something really doesn't work in the communication between us if
my sentences above misled you.
Jozsef, I don't really need any lessons, particularly from you, on the
semantics of the English language! Let's make that clear once and for
all, OK?
Your last sentence you quoted above: "...but then it'd mean that if
someone used a hash:net,iface type as a member of list:set, then he is
forced to use 'src', 'dst' only." clearly indicates, or at least implies
to anyone with a basic grasp of the English language, that this action
(using src/dst only for hash:net,iface in a list:set) is, at best
undesirable, at worse unacceptable.
It is certainly exactly the opposite of what you have stated since
yesterday as I quoted in 1, 2 and 3 above, which is what I call a
classic case of someone making a full circle - from start to finish,
unless you think that all of the 4 answers you have provided mean the
same thing. Do you? =-O
In other words - you have gone full circle - twice - in a space of just a
couple of days. I see that "debating" with you is becoming a bit of a
pointless exercise.
It's a mutual feeling then. I repeat again and again, that where two
syntaxes are allowed (the subject is an iptables rule) then the result
must not depend on which one is used.
I haven't disagreed with that point at all. Again, allowing in/out as
well as src/dst in a list:set won't produce "different results"
depending on whether one uses either of these values! Where do you get
that from?
Let me repeat that so it is clear - they won't, but if you know any
different I am all eyes/ears etc.
So better close it down: send your patches according to solution a, that
is the "in/out" keywords are allowed only with hash:net,iface type of sets
alone and rejected with a proper error message when attempted to use with
any other set type.
I would like to see why do you think the use of in/out should be
restricted in list:set types, given the fact that there could be
hash:net,iface members registered in that type of set?
Why should I (and I am sure I am not going to be the only one) have to
scratch my head and think what is corresponding to 'src' and 'dst' every
time I place a hash:net,iface set member in a list:set and why I can't
make use of in or out, in addition to src/dst in that list:set?
--
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
