I think having a bundle with a mandatory ID, that we ourselves recommend people don't use for anything, is very confusing.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown 
"Wunder, John A." ---05/31/2016 01:53:33 PM---All, Like we talked about on the call, “bundle” is getting very close. You can see the current defin
From: "Wunder, John A." <jwunder@mitre.org>
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 05/31/2016 01:53 PM
Subject: [cti-stix] Finalizing Bundle
Sent by: <cti-stix@lists.oasis-open.org>
All,
Like we talked about on the call, “bundle” is getting very close. You can see the current definition here: https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.c9oxowopqs2.
As I see it, we just have two major open questions:
- 1. Should we include an “id” field? If it’s included, should it be required? I’ve been seeing pretty decent consensus that it should be added.
2. Should we include a “most_restrictive_marking” field? Is it an array? What is the definition, and how does it work across the marking types? We had general consensus to include this field on the working calls but since then further questions about how exactly it should work have come up.
My opinions on these two items are:
- 1. We should just include the ID field, and make it clear on the definition for “bundle” that it CAN be used for tracking but that consumers absolutely don’t need to track it. We also should require it…as a matter of principle, I don’t think there should be any optional ID fields in STIX. If something has an ID, it should be required.
2. I don’t really understand this topic enough, but I will say that in order to include it we need to have a much better definition for how it should work. I’m including it so long as the people who want to have it can propose a definition that is workable, unambiguous, and easy for people to implement. I’m also happy leaving it off: the people that need it can define it as a custom field in their implementations and then others don’t need to figure it out.
Thoughts? Maybe we can also finish this topic off by Friday as well?
John