OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] Patterning Operators - CONTAINS


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]