Here are the topics we need some in-depth review on currently to make more progress. These are in rough order of priority. Also, there are other topics as well, this list is for people who want to review something that’s nearing finalization.
If you’re interested in early development on campaign, TTP, i18n, or other topics see Slack and the mailing list.
Also, as Bret said on the call…if anyone else has the time or bandwidth to “adopt” sections (perhaps Indicator or the Indicator Type vocab?) and move them forward let us know. I can walk you through the process we use and make sure you’re comfortable
Current Status: Awaiting Unanimous Consent
Requested Action: Review the draft text for the timestamp and timestamp precision sections. If you have any objections, please make them by 12 May, 2016 end-of-day UTC (~7pm ET), otherwise we’ll move this text forward to draft.
Current Status: Awaiting ballot
Requested Action: Review the (unmodified) draft text. Pat made some suggestions, but the vote is for the text as-is that calls out UUIDv4 specifically. Vote on the ballot when it’s opened.
Current Status: Objection to Unanimous Consent
Requested Action: Review the draft text and Eric Burger’s response. We talked about this topic on the call, and general consensus was that we don’t really need a formal registry of extension fields at this time. We could have some kind of informal
registry via e-mail to the cti-users list, if the community seems interested as we get to that point, but that we don’t need anything formal. As such, the language as-is seemed fine to most people. I would ask that you take the next 2 days to review this (through
12 May, end of day UTC/COB ET) and, if we don’t hear any further objections, we’ll motion to hold a ballot (having failed unanimous consent) to move it to draft status.
Current Status: Review prior to motion to move to draft
Requested Action: Review the draft text for the identifier field on STIX TLOs, and how it’s used for references. Provide suggested updates. Also, consider whether the
_ref suffix is valuable for reference fields or if those fields would be better named without that suffix or with a different suffix (i.e. Do you prefer created_by_ref, created_by, created_by_id, or something else). We’ll work through this over
the next few days until it settles down, then move to draft preferably late this week.
Current Status: Review/Normative Text
Requested Action: Review the draft text and suggest updates, it still needs some work to become good normative text. Review the open questions at the top to ensure that we’ve addressed them. Comment on which examples might be moved to an appendix/separate
document to save room in the main specification. We’ll try to push this text forward over the next few days so that we have finalized normative text to motion/vote on either late this week or early next week.
Current Status: Development
1. Discuss having an ID field on bundle. General discussion on the call seemed to lean towards yes, but there was not a lot of consensus.
2. Discuss approaches for data markings on bundle. General discussion on the call seemed to lean towards a consensus of not having default markings but having a most restrictive marking field, is that acceptable?
See other e-mails for more info on package/bundle.