On 10/26/2016 3:41 PM, Kirillov, Ivan A. wrote:
> The intent is to be broader than network containment matching, though that’s the current specified use case. The thought was that if we specify network-specific operators (e.g., ISSUBNET) these cannot be re-used for similar use cases down the road.
>
> Regards,
> Ivan
>
My 2c:
reusing the same operator for different types of operations on different
types of values can make developers' lives harder. It is ideal to be
able to tell what to do just from a json value, pattern literal, and
operator (preferably just the operator!). If, for example, I have two
strings and generic "ISSUBSET" operator and still can't tell what kind
of subset operation to perform (string subset, network containment,
something else?) then my life gets more complicated. I suspect I'd have
to look up something about the cybox object in question in a table, e.g.
the "JSON path" to the value in question, to figure out a property type,
which determines operator semantics. E.g. (just to make something up here)
network-packet:from/ip
network-packet:to/ip
network-interface:ipaddr
internet-host:ipaddr
etc...
those are all IP address typed, so "ISSUBSET" is a network operation.
For all other properties, "ISSUBSET" is a string containment operation.
Now, I have to bake a whole lot of implicit CybOX knowledge into my app.
That would have to be versioned and updated. E.g. property types can
change over time, new objects added that I may not yet have support for,
etc.
JSON-LD can embed typing info into JSON objects, but that idea was
slammed pretty hard. But if the alternative is the aforementioned
tables and the associated implementation complexity and maintenance
burden, JSON-LD (or some other way of doing the same thing) starts to
look a lot more attractive.
Or, just make operators have specific simple meanings so implementations
don't have to work harder to "figure it out".
The discussion about "general" operators got me a bit worried, and I
just wanted to plant some warning signs in the road and make sure people
were thinking about this.
Andy
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php