Ballot Details: Approve Custom Properties (STIX 2.0-1, Section 5.1) text as working draft (CLOSED)

Ballot Question Do you accept the Custom Properties text, contained in STIX 2.0-1, Section 5.1 and duplicated below in the description, and support marking it as “working draft”?
Ballot Description Working draft status indicates that the TC generally agrees with the approach and the text as written. Editorial changes to the text may be made after text has been moved to draft status, but any substantive changes after the ballot has passed require another ballot to accept those substantive changes.

Link to text:

Full Text:

5.1. Custom Properties
The authors of this specification recognize that there will be cases where certain information exchanges can be improved by adding fields that are not specified nor reserved in this document; these fields are called Custom Properties. This section provides guidance and requirements for how producers can use Custom Properties and how consumers should interpret them in order to extend STIX in an interoperable manner.

5.1.1. Requirements
• A STIX TLO MAY have any number of Custom Properties.
• Custom Properties SHOULD start with “x_” followed by a source unique identifier (like a domain name), an underscore and then the name. For example: x_examplecom_customfield.
• Custom Property keys SHOULD have a maximum length of 30 characters.
• Custom Property keys MUST have a minimum length of 3 characters (including the prefix).
• Custom Property keys MUST have a maximum length of 256 characters.
• Custom Properties that are not prefixed with “x_” may be used in a future version of the specification for a different meaning. If compatibility with future versions of this specification is required, the “x_” prefix MUST be used.
• Custom Properties SHOULD be uniquely named when produced by the same source and SHOULD use a consistent namespace prefix (e.g., a domain name).
• Custom Properties SHOULD only be used when there is no existing field defined by the STIX specification that fulfills that need.

A consumer that receives a STIX document with one or more Custom Properties that it does not understand MAY refuse to process the document further or silently ignore non-understood properties and continue processing the document.

The reporting and logging of errors originating from the processing of Custom Properties depends heavily on the technology used to transport the STIX document and is therefore not covered in this specification.

Non-Normative: Producers of STIX documents that contain Custom Properties should be well aware of the variability of consumer behavior depending on whether or not the consumer understands the Custom Properties present in a STIX TLO. Rules for processing Custom Properties should be well defined and accessible to any consumer that would be reasonably expected to parse them.

5.1.2. Examples
"x_acmeinc_scoring": {
"impact": "high",
"probability": "low"
Ballot Options
VOTING CLOSED: Friday, 20 May 2016 @ 1:00 pm EDT
Yes 25 83.333
No 5 16.667
Abstain 1
Open Date Friday, 13 May 2016 @ 1:00 pm EDT
Close Date Friday, 20 May 2016 @ 1:00 pm EDT
Ballot Type Official, as defined by organization policies and procedures

Voting Statistics

Number of votes cast (excluding abstentions) 30
Eligible members who have voted 31 of 54 57.407%
Eligible members who have not voted 23 of 54 42.593%

Voting Summary by Option

Options with highest number of votes are bold
Option # Votes % of Total
Yes 25 83.333%
No 5 16.667%
Abstain 1

Voting Details

Voter Name Company Vote * Time (UTC) Comments
* Baker, Jonathan Mitre Corporation Yes 2016-05-16 13:06:00
* Brown, Iain United Kingdom Cabinet Office Yes 2016-05-15 17:48:00
* Butt, Michael Soltra Yes 2016-05-16 17:03:00
* Chernin, Aharon Soltra Yes 2016-05-17 13:09:00 1
* Darley, Trey Soltra Yes 2016-05-19 11:41:00
* Ginn, Jane Cyber Threat Intelligence Network, Inc. (C... Yes 2016-05-13 18:34:00
* Gurney, John-Mark New Context Services, Inc. Yes 2016-05-13 18:32:00 1
* Jordan, Bret Blue Coat Systems, Inc. Yes 2016-05-13 17:09:00
* Kakumaru, Takahiro NEC Corporation Yes 2016-05-17 23:44:00
* Katz, Gary US Department of Defense (DoD) Yes 2016-05-16 17:43:00
* Keirstead, Jason IBM Yes 2016-05-19 17:28:00 1
* Kelley, Sarah Center for Internet Security (CIS) Yes 2016-05-19 13:32:00
* MacDonald, Terry Individual Yes 2016-05-18 23:30:00 1
* Maroney, Patrick Integrated Networking Technologies, Inc. Yes 2016-05-16 17:14:00 1
* Masuoka, Ryusuke Fujitsu Limited Yes 2016-05-17 06:37:00
* Moler, James New Context Services, Inc. Yes 2016-05-13 19:31:00
* Peloquin, Joey Citrix Systems Yes 2016-05-17 18:20:00
* Piazza, Richard Mitre Corporation Yes 2016-05-13 17:31:00
* Riedel, Daniel New Context Services, Inc. Yes 2016-05-19 15:01:00
* Struse, Richard DHS Office of Cybersecurity and Communicat... Yes 2016-05-13 19:09:00
* Suarez, Natalie Soltra Yes 2016-05-18 17:27:00
* Terada, Masato Hitachi, Ltd. Yes 2016-05-20 07:23:00
* Thompson, Dean Australia and New Zealand Banking Group (A... Yes 2016-05-17 13:52:00 1
* Thomson, Allan LookingGlass Yes 2016-05-13 17:04:00
* Wunder, John Mitre Corporation Yes 2016-05-13 17:12:00
* Clancy, Mark Soltra No 2016-05-18 22:16:00 1
* Foley, Alexander Bank of America No 2016-05-16 19:22:00 1
* Maxwell, Kyle VeriSign No 2016-05-13 17:08:00 1
* Pepin, Michael Soltra No 2016-05-18 18:06:00
* Schmoker, Ben ThreatConnect, Inc. No 2016-05-17 13:00:00 1
* Mates, Jeffrey US Department of Defense (DoD) Abstain 2016-05-16 19:44:00
* Baikalov, Igor Securonix --
* Barnum, Sean Mitre Corporation --
* Beekman, Jeff Soltra --
* Butts, Brad U.S. Bank --
* Coderre, Robert VeriSign --
* Davidson, Mark Soltra --
* Davidson, Ron Check Point Software Technologies --
* DePeppe, Doug Cyber Threat Intelligence Network, Inc. (C... --
* Dye, Daniel Soltra --
* Eilken, David Financial Services Information Sharing and... --
* Jones, Elysa Individual --
* Keckler, Raymond Soltra --
* Khan, Ali Soltra --
* Kiehl, Chris Soltra --
* Kirillov, Ivan Mitre Corporation --
* Patrick, Paul FireEye, Inc. --
* Pumo, Beth Kaiser Permanente --
* Storms, Andrew New Context Services, Inc. --
* Taylor, Chris United Kingdom Cabinet Office --
* Taylor, Marlon DHS Office of Cybersecurity and Communicat... --
* Thomson, Laurie United Kingdom Cabinet Office --
* Verma, Jyoti Cisco Systems --
* Williams, Ron IBM --

Voter Comments

Submitter Vote Comment
Thompson, Dean
Australia and New Zealand Banking Group (A...
Yes I support the concept but would like to look more into the registry concept.
Gurney, John-Mark
New Context Services, Inc.
Yes In the future when we are not rev'ing the spec every 6 months, a registry makes sense.

Also, as I believe we are forcing strict version numbers (you can't parse a 2.0 as 2.1), the issue that RFC6648 has w/ the x_ being de facto standard is not an issue here.
MacDonald, Terry
Yes I would prefer that the 'x_' be mandatory, but the inclusion of a source unique identifier stay as a SHOULD. I am on the fence about a registry. The fact is that there will always be some local use cases that require custom objects within a community. Not all of them will want their custom objects recorded in a central registry (especially government types).
Maroney, Patrick
Integrated Networking Technologies, Inc.
Yes Supporting this, but interested in exploring the concept of a Registry as suggested by Kyle Maxwell and John-Mark Gurney.
Chernin, Aharon
Yes Support the concept, also support a registry.
Keirstead, Jason
Yes I accept as a working draft and added suggested changes to clear up the normative text.
Schmoker, Ben
ThreatConnect, Inc.
No Nay, as it runs counter to the principles of a parsable standard.

Understand if the intent is to be similar to "X-headers" in HTTP

I'd worry that the proposed implementation allows producers to define a "de-facto standard" for add'l fields, which must be parsed by each recipient, at the mercy of the expectations of each producer for format and content
Maxwell, Kyle
No I do not agree with the second point (`SHOULD start with "x_") as per RFC 6648. A simple registry would be a better solution.
Foley, Alexander
Bank of America
No I think I'm with Kyle Maxwell on this one... it seems that we're bucking thirty years of wisdom by using x_ whereas any system could simply evaluate a parameter against known keys to determine that a parameter is a custom property.

I think there's a 100% probability we aren't going to have the complete list of parameters that STIX ends up with, and we'll avoid backward compatibility associated with renaming if we remove the second point.

Of course, I know the language says SHOULD and we don't have to follow it, I'm just not sure we should codify that point.
Clancy, Mark
No This will lead to chaos. We have the same problem now in 1.x and proposing this WITHOUT defining implementation requirements will cause the same result. Every custom roll your own extension will break interoperability. Maybe the system doesn't blow up when it gets STIX with "X_Because_IWantedTo" custom properties, but automation will not cascade between operators or different implementations so we #fail on the objective of a standard.

I would be in favor of a "registry process" perhaps with some review/approval /coordination of/with the CTI, but that just seems to me to be a short cut way to do a revision of the standard. Maybe that is more timely approach and a compromise, but we have to recognize that is inherently a compromise too albeit a better one than roll your own changes like the proposed would inevitably lead too.

An alternate I have considered is doing "de facto" stuff like this using marking syntax WITHIN an defined/existing payload field like say Descriptions. So any UI or automated processing that wants to use it has to look in the payload for the instruction/property, but if a system did not do this it would just see text. If it is something we want in the structure of the message then we revise STIX.


This of course is also problematic, but at least people who don't play (implement the extended property) can still see the extension somewhere in their solution they already handle things.