Re: [PATCH v2 3/3] ipset: change 'iface' part in hash:net,iface set

[Mr Dash Four <mr.dash.four@googlemail.com>]

> 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.