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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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


Subject: Re: [cti-stix] RE: New property names for previous label properties


Wunder, John A. wrote this message on Thu, May 17, 2018 at 17:31 +0000:
> I wanted to bump this discussion on the “labels” topic being tracked as issue 37 [1]. We discussed it on the May 8 working call [2] but unfortunately still don’t seem to be at consensus on this topic. It’s a blocker for releasing the STIX 2.1 CSD so getting to a resolution is important.
> 
> Along those lines, one other option came up on Slack recently: while we typically avoid using “classification” because of connotations for the government community (and those supporting them), the feeling maybe we should reconsider it. Given that new option, to restate the proposals:
> 
> 
>   1.  *_types (indicator_types, malware_types, threat_actor_types, etc.) for the categorizations/types, and use “labels” for user-defined tagging
>   2.  Keep these values from the vocab in “labels” (as they are now), add a new property called “tags” to capture the user-defined tagging
>   3.  Use the name “classifications” for the categorizations/types, and use “labels” for user-defined tagging
> 
> We could really use more input on these, in particular if you’re now open to different options or have not yet weighed in. I’d suggest we just list an order of preference to see if maybe there’s a compromise that gets us somewhere. My order of preference is 1, 3, 2 but any of them seem fine.

I'll say that I'm a bit worried we are working so hard to make it so
people don't have to read the specification and normative text that we
spend so much time writing.  Yes, naming things is hard.  If you don't
read the standard/spec, and make a mistake, that's on you, not on us.
There are lots of names that overlap, and mean different things in
different fields of study.  We also have the advantage that the
standard is free and open to everyone.  So the excuse that I didn't
have a copy of the standard because it costs $10k+, so I couldn't have
read it is gone.  Now it's only that I was too lazy to read it.  If you
don't understand the standard/spec, then yes, it's out problem and we
need to fix it.

That said, what ever name we pick, we can make the computers use, BUT:

I personally perfer the same name to be used for categorization/types,
because then we can make the names reserved, and custom objects can use
them, and tools can automatically handle them, etc.  If we go w/ 1,
then we have to write rules on how to convert the object type to the
*_types name, or someone has to create a hard coded table of all of
these, etc. and we completely miss out on the ability to use the field
on custom objects.

What the actual name we pick, I don't have a strong preference, I just
prefer we use the same name for all objects that need it.  Also, a
large part of this should be abstracted out by the UI.  If we have
products that let people author bad data, then it's going to be a
problem no matter what we as the writers do.

-- 
John-Mark


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