Incident Extension Time Precisions

["MATES, JEFFREY F GS-14 USAF AFOSI AFOSI/TSD" <jeffrey.mates@us.af.mil>]

In the Incident Working Group call today the topic of timestamp precision was 
discussed for attacker activities.  Given the fact we have avoided this before 
as a TC it was suggested that this be raised to the wider mailing list to 
determine if we should continue to avoid recording precision or include 
precision options for the three timestamps for Incident which are:

Attacker Activity: start_time (optional first time the activity occurred)
Attacker Activity: end_time (optional last time the activity occurred)
Defender Activity: timestamp (when a defender activity occurred... these are 
atomic events unlike attacker activities)

These precision fields would be optional non-negative number fields with 
proposed normative text along the lines of:

"The non-negative numeric precision that represents the precision of the time 
entries in seconds.  This defaults to 0 if it is unset.

If this field is included the <time field> supplied for attacker activities 
should be interpreted as being between the timestamp listed (inclusive) and 
the timestamp + precision (exclusive)."

The goal for this would be to allow for easier computational entries that 
could range from millisecond precision by entering .01 to a day with a value 
of 86400.  Year based precision with this can be a bit weird because of leap 
years and seconds so a qualitative approach may work better for some fields, 
although it would also make the math worse for systems computing it.  Which 
does play into why we kept punting on precision before.

So, thoughts on if Incidents should include time precisions or if it should be 
axed?

//SIGNED//

Jeffrey Mates, Civ DC3/TSD
Computer Scientist
Technical Solutions Development
jeffrey.mates@us.af.mil
410-694-4335

Attachment: smime.p7s
Description: S/MIME cryptographic signature