* Allan: suggests paring down vocab, text to ensure people will use it correctly, leave as open
Part 5 issue: return TRUE or FALSE if you're not able to evaluate a property on a pattern
* Jason: we need to return true to avoid missing things
* JMG: one of the issues with matching on custom properties is that if you depend on TRUE to be not present, and you have someone else with the same name custom property but the same type, you have a conflict
* There really needs to be an understanding of what properties are being generated and what you're comparing against
* Agree that we need to define the behavior of this. Would propose that the pattern define whether this is true or false
* In other cases we define not present as false, but if we have other problems because a property not present means more than just not implemented
* Allan: mostly agrees with JMG...not implemented is not by default true. That would be very bad...
* This is a product choice. Tools should be able to define it. Would be strongly against a MUST. We could provide an "error" or non true/false response
* What's being suggested is inside your pattern you're required to specify how it should behave. It seems like we could do that, what would the default be? At the end of the day we need a default.
* Trey: for purposes of issuing CSD01, how about we pull this text out and create a github issue?
* ***Call for objections to push to CSD02. No objections.***
* Another question is what was implemented in the existing library
Github Issue 37 - Labels
* Allan: when was the core issue decided? The names don't matter, what we need to decide is whether there should be one property or two. Consensus was to separate the labels property into two separate properties? In that case I will change my vote; my primary question is how can you standardize on organizations using a machine-defined vs. user defined tag correctly. What will happen is that they end up mixing and vendors will end up having to merge them.
* Trey: In terms of machine processing, if I have a spec that gives me a list of defined tags, I can very easily whitelist those in my code and machine process those. I don't really understand why having a single property for this is a problem.
* Bret: My proposal was based on going back to our original idea of STIX 2.0 of having a separate labels and tags properties.
* John: The way things are is we have one property called labels.
* Chris: I'm not a developer, but I agree with Bret's judgment that having one property with a mix of labels and tags is a programmatic issue. Based on that, I was thinking this is a serious issue for developers and something that needs to be resolved. Personally, I think of labels and tags as being almost interchangeable, though I can live with whatever we call them.
* JMG: One thing that's not clear is that when we make the change, labels will become a closed vocab and tags will become open, is that correct?
* John: Not quite, labels will be an open vocab and tags will be a list of strings.
* JMG: If labels remains an open vocab, you'll have the exact same problem that a combined vocab has. Namely, being able to tell the difference between a machine generated tag and a user generated tag. This is an extremely hard data curation problem, and I'm not quite sure whether splitting the property into two is correct or not. If we made labels more restrictive (closed) it would make more sense to split them up.
* Bret: I would be fine making the types/labels a closed vocab. From a processing standpoint, if we have a generic bucket of terms that is an open vocab, you can pivot on it and do some processing on it. However, we've added terms related to processing and other functionality, so now you have no way to determine in code whether a label corresponds to a known classification or something random.
* Jason: To me property 2 is not a vocab at all, it's just a list of strings. The difference isn't whether it's machine readable, rather it has to do with the information source, whether it's trust group originated or something else. We need these properties because they capture two different concepts: one is just a tag, and one is categorizing malware, threat actors, etc.
* JMG: This is almost where namespaces are very useful so you can categorize your custom properties accordingly.
* Straw poll: 1 for addressing this issue in CSD01, 6 for pushing this out to CSD02.