[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Applying data markings
A few comments from me:
* Overall, I like the design and I think it is in the right ballpark. I have some comments (below), but overall I'd be on board with using this as our foundation for STIX 2.0 data markings and moving on to other topics, as long as we recognize that things might change as a result of prototyping and other decisions (but hopefully not too much!)
* I really like "override markings of the same type" and I consider this a key benefit of the proposal. We've had conversations about the 'more restrictive' marking applying, but there's no guarantee that markings can be objectively identified as more or less restrictive. This is a very straightforward way of determining which marking(s) apply.
* I'd like some clarity on what it means to process a data marking, but that can be sorted out later when this gets worked into a specification.
* I don't like the two modes of marking - Level 1 has markings as a property of the marked object, and Level 2 has the marked object as a property of the marking. That said, I recognize this may be a necessity that can't be worked around, especially if we desire the ability to mark information whose representation is under our control (in STIX 1.x, CIQ, OVAL, et al would fall under this category - in STIX 2.0 I'm not clear which items are in this category).
* When this gets worked into the spec, I'd prefer to avoid making Data Markings a dimension for negotiating interoperability. Said another way, I don't want two otherwise compatible STIX implementations to be incompatible because they support different levels of Data Markings. I'm not sure we'll ever get to the point where you can just plug together two products that say "STIX" on the label, but IMO we should move as far in that direction as possible. Rich's idea of MTI/optional looks like it would accomplish my goal.
* This is a personal preference: Level 1 Markings and Level 2 Markings could instead be called "Data Markings" and "Field Level Data Markings". IMO this would make it more clear to a reader what each thing is, and make it clear that Level 2 is effectively an extension of Level 1. Then the conformance clause could read like "Data Markings MUST be implemented. Field Level Data Markings MAY be implemented" or some such. That said, this is personal preference and my opinion on the design is not contingent on this comment being accepted.
TBH, most of my questions/comments can probably be captured as "open questions" in the proposal's wiki page. John, I'm happy to make those edits myself if you'd like (Let me know offline or in slack; no need to reply on-list for that).
Thank you. -Mark
P.S. - I like the idea of establishing a naming convention, can we add that topic to the discussion queue?
P.P.S. - Right now STIX and TAXII are capturing rough consensus decisions differently. STIX is using the GitHub issue trackers and TAXII is using TAXIIProject.github.io. In hopes of not spawning another discussion thread, I'll raise this in the slack channel
and see if we can reach a unification proposal to bring back to the list. (Note: Let me know if you want a slack invite)
From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Friday, December 4, 2015 12:03 AM To: Struse, Richard Cc: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings I should rephrase as my statement was not clear, I am not sold yet on the way layer 2 markings are being proposed. But that could mean I just do yet fully understand John's vision for them. I am going to try and schedule a call with John tomorrow to
walk through it.
Bret
Sent from my Commodore 64
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]