Re: [PATCH v2 3/3] ipset: change 'iface' part in hash:net,iface set
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Solution "b.", as you put it above, is what I have implied with my question yesterday.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 a. is completely acceptable for me. It can nicely be documented, there's no chance for misunderstanding.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.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.
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
[Netfitler Users] [LARTC] [Bugtraq] [Yosemite Forum] [Photo]