cti-stix — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
Re: [cti-stix] Timestamps - Proposal
That is the approach we outlined and agreed to.
How is that bad form?
We need to be able to track issues from identification through discussion to solution proposal to consensus being reached to actually incorporating the changes within a release. And have a traceable record of all of this.
Github issue trackers are designed for just this sort of process.
I think the point is that the issues should have ideally been created back when the discussion on this started rather than just capturing everything after the fact.
sean
From: " [email protected] " < [email protected]
> on behalf of "Jordan, Bret" < [email protected]
>
Date: Thursday, December 3, 2015 at 2:38 PM
To: John Wunder < [email protected]
>
Cc: " [email protected] " < [email protected]
>
Subject: Re: [cti-stix] Timestamps - Proposal
We should NOT use Github Issues for things we have decided on. That is bad form.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards
Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Dec 3, 2015, at 12:19, Wunder, John A. < [email protected]
> wrote:
So it appears that we have rough consensus and IMO can move on without a vote.
How do we document this? Should I add an issue & a comment w/ the accepted solution?
On Dec 1, 2015, at 4:55 PM, Struse, Richard < [email protected]
> wrote:
+1. Microseconds are enough. Let's move on.
From : Jordan, Bret [ mailto:[email protected] ]
Sent : Tuesday, December 01, 2015 04:54 PM Eastern Standard Time
To : Terry MacDonald < [email protected]
>
Cc : [email protected] < [email protected] >; Patrick Maroney < [email protected] >;
[email protected] < [email protected]
>
Subject : Re: [cti-stix] Timestamps - Proposal
This is generally why we decided to place some table stakes in the ground and call it good. The proposal on the floor is for microsecond level precision, meaning 6 sub-second digits (most modern tools can and do support this, older tools may be limited).
We can debate esoteric requirements and corner cases forever. I would much rather get STIX 2.0 out the door and if we need to add something like nano seconds later, we can do that. People that can only do millisecond level precision should just
zero out the last three digits. And given jitter in NTP it does not really matter that they are zeroed because your accuracy is only to about a second anyway.
The way this would look is like:
{
"timestamp": "2015-12-01T14:52:12.123456-06:00"
}
or
{
"timestamp": "2015-12-01T14:00:00.000000-06:00",
"timestamp-precision": "hour"
}
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards
Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Dec 1, 2015, at 14:28, Terry MacDonald < [email protected]
> wrote:
I'm sure millisecond will be good enough for now.
We will never be able to cover every governments exact specific requirements, so I don't think we should start. I'm sure that the EU, China, Japan, Australia and NZ all have their own requirements in this space, and all we can expect to do is cover the main
80%. We get into trouble trying to shoehorn the last 20% in.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA An FS-ISAC and DTCC Company
+61 (407) 203 206
[email protected]
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]