[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.
Range capability totally makes sense to me. I just really don’t think that there should be fields where you can EITHER put a range or an atomic value. That kind of optionality is a recipe for incompatibilities.
If there are fields that we think need to be ranges, let’s just make them always ranges, and if people want to put a discrete value the start/stop are the same (range of 0ms). We can evaluate this on a case-by-case basis as we come to those fields, IMO
there’s no reason to go through and do it all now.
John
From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, February 2, 2016 at 1:08 PM To: Sean Barnum <sbarnum@mitre.org> Cc: Mark Davidson <mdavidson@soltra.com>, "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. Myself I would like to see a list of objects for which it is presumed ranges would be valid - to me, that would be the minority, not vice-versa. I definitely see your point for fields that MUST always be discrete. Maybe default to the general timestamp and for fields that MUST be discrete define a more limited version without ranges? Sean From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> Date: Tuesday, February 2, 2016 at 12:54 PM To: "Barnum, Sean D." <sbarnum@mitre.org> Cc: Mark Davidson <mdavidson@soltra.com>, John Wunder <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. So what happens if there is a feild where a discrete timestamp is the only thing that makes sense, but the producer puts a range in it, and everyone who consumes it does not process it properly as a result...? That is my main issue with
this being a format that can be used in any timestamp field. A piece of software needs to know how they should parse that field... as a range or not a range... because that has very broad ramifications. My understanding is that "2015-03-01T13:00:00Z” would explicitly be a discrete time and "2015-03-01T13:00:00Z/” would indicate an unbounded range starting at that time. The presence of the “/“ makes it explicitly a range. By my understanding there are really only 4 variations here:
I would think quite a few time fields do not necessarily fall as always discrete or always a range. I would say this is likely true of the majority of incident related timestamps. For example, as part of an incident investigation you discover that a registry key on a system was changed to a particular value. If you had an endpoint monitoring tool in place noticing events like registry key changes you would likely assert a discrete timestamp for when the change occurred. In other (most from what I have seen operationally) cases you don’t have visibility to determine exactly when the change was made but rather you have a point in time slice that shows the new value and a previous point in time slice that shows the old value so you know that the change occurred sometime in between. From what I have heard from operations, IR and intel folks this sort of thing where a time may be discrete and may be a range is very common. Pat, please feel free to correct me if my understanding is wrong. Cell: (609)841-5104 Email: pmaroney@specere.org --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php [attachment "graycol.gif" deleted by Jason Keirstead/CanEast/IBM] |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]