Thanks for starting on this, Karel.
I like that we are scoping rules to roles. This is going to be important, especially as we have services like HBase that need to inherit rules from services like Zookeeper. If we can have composability, it would be a plus.
I'd recommend a couple things.
1. let's focus on rules themselves, noting not all rules are ingress, nor TCP
For example, I've noticed people want to specify rules relative to a group as opposed to just cidr. For example, this issue addressed a concern from BackType who want to scope rules to a source group (or role) and port range: http://code.google.com/p/jclouds/issues/detail?id=606 In jclouds, there is a IpPermission class that might be helpful when modeling with a fluent class IpPermissions that may be helpful as well.
2. I like the simple syntax of the properties. It would be nice to use something simple to presume TCP and also ingress, but also parse if the rule is egress or another protocol.
3. A role will have multiple rules associated with it, so we should consider the impact of this on serialization into properties, etc. similar to the comma separating cidr.
4. We should figure out how or whether to address composability
I have to run, but I hope this is helpful!