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


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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

Subject: Ballots Closed: CybOX v2.1.1 and Normative Text on Lengths

Dear CTI,


Thank you very much for your participation in our two ballots last week.  Both had at least a simple majority of our voting members participate.


Cybox v2.1.1 Committee Specification Draft

Passed unanimously with 33 votes.  We will note this in the minutes of our full TC meeting on Thursday to proceed to the step of making the draft a candidate specification.


Normative Text on Lengths Proposal

I think in hindsight I should have included an Abstain option on this ballot, as I am not sure if I believe I know what the right answer is, but I must admit it was nice to see people’s lean by having to decide one way or the other.   The “No, there should be no normative text describing length limits.” option received the majority of votes (19) but it was clear that from the 12 votes for “Yes, the spec should have normative text describing length limits for some fields.” that we might need to come back around to this in the future.  That being said, our process has worked and we now have a path to move forward by not including length limits in the STIX 2.0 draft.


Comments for “No, there should be no normative text describing length limits.”

·         “I am voting for what makes sense right now (as of 6/12/2016). If, as people implement the MVP drafts, it turns out that some normative statements regarding string lengths make sense, we should reserve the right to course correct.  For now, I vote for no normative statements describing string lengths.”  - Mark Davidson, Soltra

·         This was never an issue with STIX 1.x, and all current issues discussed around it are theoretical at best.”  - Ivan Kirillov, Mitre Corporation

·         Shouldn't this be determined by string limitation (if any) in a given Serialization Binding Specification?”  - Pat Maroney, Integrated Networking Technologies, Inc.


Comments for “Yes, the spec should have normative text describing length limits for some fields.”

·         “Yes we should provide normative text describing length limits.  Appliances can use these lengths to make decisions on how to handle info from STIX/Cybox and developers can use this information to understand what will or will not be truncated. This can be very important when trying to actually do something with the information.”  -- Lee Vorthman, LookingGlass

·         “Yes we should provide recommendations with “should” that will drive interop tests for common use cases and practical examples that most products ‘should’ support.  For example if a router that has limited memory for regex matching and that router can ingest stix/cybox natively then knowing what is practical requirements for memory allocation for rule space is needed.  A router can always reject a rule that is too large but having recommendations from ti experts in the spec will be helpful.”  - Allan Thomson, LookingGlass

·         “As a developer knowing what might or might not be truncated could be important.”  - Ron Williams, IBM




Alex Foley

CTI Co-Secretary

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.

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