Re: [IntelMQ-dev] IEP04: The choice of the UUID-format, Re: IEP04: The choice of the UUID-format

-- moto kawasaki moto@kawasaki3.org From: Sebastian Wagner wagner@cert.at Subject: Re: [IntelMQ-dev] IEP04: The choice of the UUID-format,Re: [IntelMQ-dev] IEP04: The choice of the UUID-format Date: Tue, 7 Sep 2021 17:34:40 +0200 > Dear Moto, > > First of all, thanks for providing feedback! > > On 9/7/21 2:40 AM, moto kawasaki wrote: >> Regarding IEP004, I'd second the current proposal and Variant >> AIL. That is natural and easy to understand. > Thanks. >> But don't we need to have a timestamp in the meta-data ? >> I mean something like this; >> >> { >> "format": "intelmq", >> "version": 1, >> "type": "event", >> "meta": { >> "intelmq:uuid": "<event-uuid-1>", >> "intelmq:uuid_org": "<org-uuid-1>", >> "intelmq:timestamp": "<creation time of this message>", <== here >> : > Every IntelMQ message should already have a /time.source/ field in the > payload, so I'm not sure if it's necessary to have it in the metadata as > well explicitly. And that overlaps with the next topic: >> With this timestamp, we don't need to consider a time-sortable UUID >> but just use UUID-whatever. > Not necessarily. Events are usually identified in User-Interfaces and > databases by an ID, a numeric one or alphanumeric. I'm just thinking of > MISP, which shows numeric IDs in the event lists. For IntelMQ similar > interfaces exist (https://github.com/Intevation/intelmq-fody/) as well > as plain databases. If the data is already automatically time-sortable > by the primary identifier, the usability could benefit. In same cases > the performance could increase as well. >> If you've already discussed and decided not to have it, please ignore >> and receive my apology to rehash old discussion. > > No, we haven't discussed that yet :) > > best regards > Sebastian > > -- > // Sebastian Wagner wagner@cert.at - T: +43 676 898 298 7201 > // CERT Austria - https://www.cert.at/ > // Eine Initiative der nic.at GmbH - https://www.nic.at/ > // Firmenbuchnummer 172568b, LG Salzburg >