[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Re: [cti-users] "Data Marking" syntaxes
From: "email@example.com" <firstname.lastname@example.org> on behalf of John Wunder <email@example.com>
Date: Monday, November 9, 2015 at 8:26 AM
To: "firstname.lastname@example.org" <email@example.com>
Subject: [cti-stix] Re: [cti-users] "Data Marking" syntaxes
Three comments, all of which are somewhat tangential to the actual structure you’re outlining (sorry):
1. We should consider referencing markings defined in some standard place in the document rather than having to repeat them each time. If I send 100 indicators, that’s 100 repetitions of a fairly complicated marking structure.
2. I think we need to maintain the current approach of extensibility for those fields. Handling is VERY specific to the sharing organization and what we come up with will either end up being overly broad and difficult to implement (to support many different use cases) or overly narrow and won’t work for everyone (to support just our use cases). I’m all for trying to drive to consensus on a “standard” approach (maybe MTI, maybe default, whatever) but we need to have a way for communities not using that to do something else.
3. I put up some approaches to doing field-level markings on the wiki: https://github.com/STIXProject/specifications/wiki/Idea-Exploration%3A-Data-Markings-Alternatives. It includes our current approach, an approach where the markings are embedded in the fields, an approach where the markings are next to the fields, and Pat’s approach to mark at the package level. Issuing different top level objects (or packages) has a few issues we should work through if we want to suggest that (vs. one of the other approaches, either as core STIX or as an extension capability).
[sean] I do think we need to reach consensus on the approach of applying the markings (the stuff John refers to) before we can reach any sort of firm consensus on the markings structures themselves.