a. The keywords are not permitted at all.
b. "in/out" is permitted but "converted" to "src/dst" wherever needed for
the member sets, that is all types but hash:net,iface.
Solution "b.", as you put it above, is what I have implied with my
question yesterday.
Solution a. is completely acceptable for me. It can nicely be documented,
there's no chance for misunderstanding.
Solution b. is also acceptable but it's more controversial: if "in/out" is
accepted with list:set type, then it's very hard to explain why it's *not*
allowed with every type, when actually "in/out" is allowed then for every
type of member sets of list:set type of sets. So solution b. implies that
"in/out" is then a general synonym of "src/dst" and should be allowed
everywhere. Therefore I'm not really happy with solution b. but I can
stomach it.
There is a flip side to that particular coin - I could argue that since
in/out *is* allowed to be used in hash:net,iface, why can't it be used
in list:set where I could have hash:net,iface type sets accepted as
members? You are imposing an unnecessary restriction where none is needed.
Also, don't forget that this may be OK with someone, like yourself, who
is comfortable interchanging in/out with src/dst quite easily, but for
people like myself, where I have to scratch my head and think "god, what
the hell was the substitution for 'in' now?" before specifying src/dst,
this is not as straight-forward as you might think.
So, to conclude: "solution b." is a good compromise - one I will be
quite happy with. If src/dst is used together with in/out (in
list:sets!), you leave the end user to decide what is more appropriate
for each case as list:set could have hash:net,iface as well as other
type of sets as members and in this case that is OK to be allowed (one
cannot guess what will be entered in advance as members of that
list:set, so it makes perfect sense to leave that decision to the end user).
Do you see other possibilities, which produce result independent of the
allowed syntax?
No, not without you being on my case. For list:set types, as it is kind
of a "unique" set (as it could have different types of sets as members)
I think "solution b." is quite acceptable.
--
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
