On Thu, 2010-07-01 at 17:35 -0500, Martin Holste wrote:
I've read through them and I think they're definitely on the right track. One thing that might be good to consider would be a way to store hierarchical information. For example, the secevt class in the schema doc is really a network class as it only requires the network tuple. So, you could have a hierarchy like this:
class Net { required_fields: [ proto, srcip, dstip, srcport, dstport ], optional_fields: [ in_iface, out_iface, details ] } class NAT { required_fields: [ nat_srcip, nat_dstip, nat_srcport, nat_dstport ] } class Security { required_fields: [ verdict ], optional_fields: [ zone ] }
This implies that the class Net.NAT.Security requires proto, srcip, dstip, srcport, dstport, nat_srcip, nat_dstip, nat_srcport, nat_dstport, and verdict, but Net.Security only requires proto, srcip, dstip, srcport, dstport, and verdict.
By that token, there's no difference between Security.NAT.Net and Net.NAT.Security, so these are really more like tags than a hierarchy.
Hmm.. interesting idea, making a hierarchy of schemas. Again some more food for thought. Is there a reason you want this behaviour implied, rather than being explicit? Maybe using a different syntax would make that more obvious. When combining schemas then instead of using '.' as a separator, use '+' Net+NAT+Security This would make it obvious that you can write the schema names in any order (since this is true for the mathematical '+' sign everyone knows). Also, how would you represent this in a pattern? Right now you can assign multiple tags and any number of name-value pairs. Combining these in the way you described would only be needed in case someone wants to use the same SQL/CSV table with the nonexisting columns skipped. Or? -- Bazsi