Ballot Details: Approve OpenC2 HTTPS Transfer Specification, v1.0, WD04 as CSD and for public review (CLOSED)
|Ballot Question||Do you approve the Specification for Transfer of OpenC2 Messages via HTTPS v1.0 Working Draft 05 and all associated artifacts as Committee Specification Draft 04, and its release for public review?|
|Ballot Description||WD 05 was discussed at the 20 March 2019 OpenC2 TC meeting and posted to OASIS on 27 March 2019. The co-chairs of the Implementation Considerations Subcommittee have determined that general consensus has been reached on the resolution of all comments to the CSD 03 / PRD 01 received during the first public review and presented it to the Technical Committee’s co-chairs.
In accordance with the OpenC2 Technical Committee’s Standing Rule 5, the co-chairs submit this ballot to the Technical Committee to authorize the release of the working draft and all associated artifacts for a second public review.
TC members are strongly encouraged to review the document during the ballot period and include their feedback as ballot comments. This will permit corrections to be made prior to publication for public review.
Per the guidance adopted at the October 2018 TC meeting, approval of this ballot includes approval for the Co-Chairs and Editors to work with OASIS staff make any changes necessary to prepare this document for Public Review.
Public document link: https://www.oasis-open.org/committees/document.php?document_id=65003&wg_abbrev=openc2
The Markdown (MD) version of the specification will be designated as authoritative.
This ballot requires a majority vote of the TC's voting members.
VOTING CLOSED: Thursday, 4 April 2019 @ 2:00 pm EDT
|Open Date||Thursday, 28 March 2019 @ 7:00 pm EDT|
|Close Date||Thursday, 4 April 2019 @ 2:00 pm EDT|
|Ballot Type||Official, as defined by organization policies and procedures|
|OpenC2 Over HTTPS Specification, WD05||Document||2019-03-28|
|Number of votes cast (excluding abstentions)||25|
|Eligible members who have voted||25 of 34||73.529%|
|Eligible members who have not voted||9 of 34||26.471%|
|Options with highest number of votes are bold|
|Option||# Votes||% of Total|
|Voter Name||Company||Vote||Time (UTC)||Comments|
|Barry, Michelle||AT&T||Yes||2019-04-02 16:07:00|
|Brule, Joe||National Security Agency||Yes||2019-03-29 14:24:00|
|Considine, Toby||University of North Carolina at Chapel Hill||Yes||2019-03-29 15:51:00|
|Everett, Alex||University of North Carolina at Chapel Hill||Yes||2019-04-03 00:30:00|
|Girard, David||Trend Micro||Yes||2019-03-31 18:55:00|
|Gurney, John-Mark||New Context Services, Inc.||Yes||2019-04-02 21:36:00|
|Hamilton, David||AT&T||Yes||2019-04-03 11:41:00|
|Hunt, Christian||New Context Services, Inc.||Yes||2019-04-02 18:09:00|
|Kemp, David||National Security Agency||Yes||2019-03-29 15:06:00|
|Lemire, David||G2||Yes||2019-04-01 17:12:00|
|Maroney, Patrick||DarkLight, Inc.||Yes||2019-03-29 17:41:00|
|Martinez, Danny||G2||Yes||2019-04-02 18:39:00|
|Mathews, Lisa||National Security Agency||Yes||2019-04-03 18:47:00|
|Meck, James||FireEye, Inc.||Yes||2019-04-03 18:42:00|
|Riedel, Daniel||New Context Services, Inc.||Yes||2019-03-29 21:02:00|
|Riley, Shawn||DarkLight, Inc.||Yes||2019-04-01 20:08:00|
|Romano, Jason||National Security Agency||Yes||2019-04-01 13:07:00|
|Skeen, Duane||Northrop Grumman||Yes||2019-03-30 20:38:00|
|Sparrell, Duncan||sFractal Consulting LLC||Yes||2019-03-29 17:57:00|
|Stair, Michael||AT&T||Yes||2019-04-02 16:39:00|
|Storms, Andrew||New Context Services, Inc.||Yes||2019-04-02 23:36:00|
|Stueve, Gerald||Fornetix||Yes||2019-04-03 01:22:00||1|
|Trost, Bill||AT&T||Yes||2019-04-03 13:17:00|
|Varner, Drew||NineFX, Inc.||Yes||2019-04-03 01:41:00|
|Berliner, Brian||Symantec Corp.||No||2019-04-03 23:03:00||1|
|Jordan, Bret||Symantec Corp.||--|
|Joyce, Ryan||DarkLight, Inc.||--|
|Kakumaru, Takahiro||NEC Corporation||--|
|Ortiz, Efrain||Symantec Corp.||--|
|Patrick, Paul||FireEye, Inc.||--|
|Ricard, Chris||Financial Services Information Sharing and...||--|
|Yu, Sounil||Bank of America||--|
|Yes||Fix spelling of company name, should be Fornetix
|No||This spec currently requires that ALL OpenC2 Commands MUST include an "X-Request-ID" header with every command. However, this header is only used as a tracing header, and since there is no actual way that the header value can be used with any other OpenC2 command, I cannot in good conscience force the Consumer that my company supports to REQUIRE an API to include the "X-Request-ID" header. As such, our Consumers will not be spec compliant, since they will be written to work work with non-compliant Producers that do not actually supply this tracing header with every request. When our Consumer receives a request that DOES NOT include the "X-Request-ID" header, it will generate a UUID and return the generated UUID in the response header as required by the spec. Further, when our Consumer receives a request that DOES include the "X-Request-ID" header, it will use it as specified by this spec. As such, our Consumer will work correctly with compliant Producers (which apparently must always specify this tracing header). I feel it is unfortunate that we are requiring a tracing header to be always supplied even when the spec does not have a use for it (beyond tracing, which is by design an optional capability in operational environments).