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: Re: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.


Under the proposed structure, how would a consumer differentiate between a timestamp (e.g., “this report was produced at XYZ”) vs. a time range with an unbounded end (e.g., “this indicator is valid from now until eternity”)? If I understand the proposal correctly, there would be no way for a consumer to decide whether "2015-03-01T13:00:00Z” is a timestamp or a time range.

Personally, I think we should be explicit about which fields are timestamps and which fields are time ranges (at least in the spec). 

Which fields don’t fall cleanly into either category?

Thank you.
-Mark

From: <cti@lists.oasis-open.org> on behalf of "Barnum, Sean D." <sbarnum@mitre.org>
Date: Tuesday, February 2, 2016 at 10:49 AM
To: "Wunder, John A." <jwunder@mitre.org>, OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: Re: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.

I would agree in principle though I believe there are some time fields that may not fall cleanly into one camp or the other (sometimes they are discrete and sometimes a range).
Personally I like Pat’s proposal below. Using the range would potentially allow us to remove the precision field as well as really it is just asserting a range by specifying a floor and scope.

sean

From: <cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date: Tuesday, February 2, 2016 at 7:26 AM
To: OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: Re: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.

IMO Pat’s proposal is a good approach to represent ranges, I would just want to clearly define which fields are ranges and which are atomic times. I think it will be very hard on consumers if they might get either for any given field.

John

From: <cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry@soltra.com>
Date: Tuesday, February 2, 2016 at 5:39 AM
To: Patrick Maroney <Pmaroney@Specere.org>, OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.

I would prefer this to be a separate TimeRange object if at all possible. If there are places we require a timerange, then lets create something that works there.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com

 

 

From:cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Patrick Maroney
Sent: Tuesday, 2 February 2016 3:36 PM
To: OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.

 

We are reaching final consensus on our CTI TimeStamp deliberations. This is a proposal to add a simple ISO 8601 Standard extension to the CTI TC TimeStamp specification that enables _expression_ of both "Absolute Time" and "Time Range" .

 

Proposal: 

 

 (1) Adopt the ISO 8601 <start>/<end> construct.  

 

(2) All of the constraints we are placing on the CTI Timestamp format remain intact:*

 

"Absolute Time":   "2015-03-01T13:00:00Z"

"Time Range":       "2015-03-01T13:00:00Z/2016-05-11T15:30:00Z"

 

(3) Parsing of the ISO 8601 <start>/<end> construct should be straightforward  (i.e., using  standard date-time libraries that support ISO 8601, regex).

 

*Note : This proposal only argues for the narrow adoption of the "/" Separator and would not allow any of the other ISO 8601 "Time Range "shortcuts" (e.g., "2014-2015", "2015-11-13/15", "2015-02-15/03-14").

 

There is significant benefit for use cases where there is a very real need to express events, actions, observables, COAs, etc. in time ranges.  For example- statutory incident/intrusion reporting deadline requirements (measured increasingly for many in hours/days) guarantee a need express and revise events in time ranges while investigations gather evidence and more accurately establish the sequence of events and timelines.  There are also many relationships that are more effectively expressed in time ranges, vs. fixed points in time.

 

Hopefully you see the value in adding this ISO 8601 capability to "our thing".

 

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

 



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