I would suggest staying with Option #1 as its consistent with the rest of the specification. Option #2 appears to be like it was bolted-on as an after-thought.
This situation is a lot like whether people can continue to use the previous âxâ extension scheme or forced to use the new extension scheme. I believe the same rules should apply here, where it should clearly
be noted that producer SHOULD use the new STIX Extension mechanism going forward instead of using the definition and definition_type, which has since been deprecated. That would also mean that the additional text be added that that indicates that the
extensions and definition_type/definition properties SHALL NOT co-exist; only one mechanism can be used.
Paul Patrick
From:
<cti@lists.oasis-open.org> on behalf of Rich Piazza <rpiazza@mitre.org>
Date: Wednesday, November 18, 2020 at 2:32 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Options for extending Data Markings
Hi All,
The attached document discusses the pros and cons of two options for extending data markings. There is no blocking issue here â just two alternatives that we would like to present
before we finalize the spec. Some tweaks to the spec would need to be made with either option.
The first one is based on the extension type âproperties-extensionâ. It necessitates making optional the two properties, definition and definition-type that were previously used for
new marking definitions. This option is what is currently suggested. The second option continues to use those properties, introducing a new extension type, ânew-markingâ, to the extension facility of section 7.3.
Neither is ideal. The first one makes extensions uniform across all STIX objects. However, the second is consistent with existing TLP and statement marking definitions.
Please comment if you have a preference. The editors will assume that if you donât comment, you would like to continue with option 1.
Thanks!
Rich
--
Rich Piazza
Lead Cyber Security Engineer
The MITRE Corporation
781-271-3760
