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] _ref field suffix

After consideration I think I understand your point better.

If an attribute is the object’s identifier then the field will be call <X>_id, correct? In that case its the identifier of the specific object.

Whereas <X>_ref is a reference to a different object. In which case the identifier is a different object. 

I see the distinction you are making. 

My main concern was around the term ‘reference’ being called out when its really just an identifier. 

There is no “type” in STIX for reference, correct? Its just an identifier. So why explicitly callout Reference?


From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Tuesday, May 10, 2016 at 10:41 AM
To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] _ref field suffix

John – I agree that a _ref is a reference to another object but so is an Id field. That’s my point. Both fields are references to an object that is identified by an identifier.


From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Date: Tuesday, May 10, 2016 at 10:37 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] _ref field suffix

(Renamed subject line to track this thread)

I’m against dropping it. I have a practical reason and a philosophical reason:
  1. Practical reason: I’ve written STIX code for both STIX 1 and STIX 2 and, in both cases, it’s useful to be able to programmatically determine when a field contains a reference to another object. For example, in my STIX 2.0 visualizer I just look for fields ending in _ref and treat them as a reference in the visualization. In a STIX 1.x tool, I do the same thing but try to resolve the reference otherwise. If that naming convention goes away, you’d have to hardcode the name of every reference field in the language for these more generic STIX utilities (visualization tools, etc.)
  2. Philosophical reason: “reference” is not a field type. The field’s data type is “identifier”. What the “_ref” is indicating is a semantic of the field usage: that it’s a reference to another object.

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Tuesday, May 10, 2016 at 1:29 PM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] STIX, Topics to Review, 10 May

Based on the conversation today on the working call, I would be okay with dropping the "_ref" from the ID reference property names, since that is the only place where we add a field type to a property name.

Where do people stand on this?



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On May 10, 2016, at 10:41, Wunder, John A. <jwunder@mitre.org> wrote:

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]