OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [cti-stix] STIX, Topics to Review, 10 May

I have reviewed the text.

I would like to clarify one thing – my does my non-objection mean that the text is “good enough”, but can still change a bit in the future? I view the text as good enough, but I have enough presentation/editorial comments that I wouldn’t consider the text “final”. As long as the text can still change (without changing spirit/intent), I’m happy to offer a non-objection.

Timestamp/Timestamp Precision
I have no objections to the content, and made some comments on presentation.

I’m not sure what’s going on with the Version 4/5 UUIDs. I would object to this being marked “good enough” because of the ambiguity.  That said, the current text is not that far away from something I wouldn’t object to. (Is this superseded by the existing ballot)

Custom Properties 
I have thought about this some more, and I’d like to object to the “x_” structure. Eric’s messages caused me to dig deeper and discover an entire RFC devoted to this topic (!!!) [1]. The thing is 9 pages long so just go read it :). Basically, I’ve been convinced that the approach laid out in RFC 6648 is the correct approach and that we should follow it.

This is a non-objection, but I think the narrative should be changed a bit (comment made in the doc); I also think we’ll want to fine-tune some of the normative text.

IDs & References
No objections, I do think terminology could be improved.

No objections, I do think there are a number of editorial changes that could be made to improve clarity. However, I would like to hold off on those while we write the rest of the document (I.e., I don’t want to spend time perfecting one small part at the expense of getting other parts to “good enough”).

I would like to see a workflow or two identified where bundle is used. No objections, however.

Thank you.

[1] https://tools.ietf.org/html/rfc6648

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Tuesday, May 10, 2016 at 12:41 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] STIX, Topics to Review, 10 May

Hey all,

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 with it.

Thanks everyone,


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
Requested Actions:
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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]