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] timestamp proposal for STIX 2.0 RC3


Eric – the original suggestion for using a numerical timestamp was that its easier. Not that its necessarily faster or slower. 

I also suggest that when you are talking about a few hundred indicators vs 10s millions then time might be a factor. How much it will influence the overall system performance is dependent on what systems are involved, how long it takes to create that content, what it takes to consume the content and then what it does with the content once consumed. Most of that system is not something STIX, as a data exchange format, should be concerned about.

Many of the systems creating or using the information in STIX will internally use a number to represent time and therefore why not use that.

Allan

On 12/5/16, 2:40 PM, ", Eric Burger on behalf of Eric Burger" <cti@lists.oasis-open.orgewb25@georgetown.edu on behalf of Eric.Burger@georgetown.edu> wrote:

    Thanks! Now back to our original program.
    
    I’ll call ‘bogus’ the argument that RFC3339 takes “a lot longer” than using epoch time. If there was an order of magnitude difference, it might make a difference. However, remember these calls are embedding in a ton of character-by-character I/O (order of ms). If something takes 2.0156ms to read or 2.0632ms to read, it’s still 2ms. In exchange for guaranteed interoperability and getting a standard answer to “how many digits will we accept to the right of the decimal point,” we are going to effectively roll our own.
    
    If we really cared about performance, why aren’t we hand crafting ASN.1 binary encoding rules? The answer is we use JSON and UTF-8 because it is a whole heck of a lot easier to implement and much more likely to result in interoperable implementations. I’d pay a 3% penalty (NOT a 4x penalty, BTW) to have something that people know, understand, and will interoperate with every syslog file generated since 2002.
    
    > On Dec 5, 2016, at 11:50 AM, Wunder, John A. <jwunder@mitre.org> wrote:
    > 
    > Hi Eric, all,
    > 
    > A couple other people had the same problem so I uploaded the attachment here: https://www.oasis-open.org/committees/download.php/59509/numerical-timestamp-prop.pdf
    > 
    > John
    > 
    > On 12/5/16, 11:47 AM, ", Eric Burger on behalf of Eric Burger" <cti@lists.oasis-open.orgewb25@georgetown.edu on behalf of Eric.Burger@georgetown.edu> wrote:
    > 
    >   The attachment came across as the ubiquitous winmail.dat. What’s the attachment supposed to be?
    > 
    >> On Dec 1, 2016, at 5:19 PM, Allan Thomson <athomson@lookingglasscyber.com> wrote:
    >> 
    >> Hi All – As discussed on the working call on Tuesday I took the action to come back with an updated proposal on how to represent timestamps numerically instead of requiring the string representation as is currently defined in STIX 2.0 RC3.
    >> 
    >> Please find attached the proposal(s).
    >> 
    >> Proposal #1 is the preferred approach but including 2 options for consideration to see if others have a different preference.
    >> 
    >> Thanks to the Greg Back from the Mitre team for doing some quick performance testing on string vs numerical based timestamp processing. I’ve included the results in the slide deck for support.
    >> 
    >> Regards
    >> 
    >> Allan
    >> <winmail.dat>
    >> ---------------------------------------------------------------------
    >> 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: winmail.dat>>



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