Are incident reports intended to be machine readable?

[Aaron Gable]

Hi all,

On a recent incident report, it was pointed out to me that the "CA Owner CCADB unique ID" field in incident reports is supposed to be the six-digit number which CCADB uses internally to identify CA owners.

I freely admit that I have never noticed this CCADB field before. Since I wasn't even aware of its existence, I naively assumed that the field in the incident report was referring to the "CA Owner Name", i.e. the same value requested in other CCADB submissions such as the Self-Audit Spreadsheet.

Which led me to wonder why this particular field is required. The only explanation that springs to my mind is that the incident reports are being consumed by automation of some form.

But if incident reports are being consumed by automation, that raises a whole host of other questions. For example, in that same incident report, we listed some of our action items as "Not Started", which is not one of the four officially-sanctioned values ("Ongoing", "Complete", "Delayed", or "Canceled"). Are those action item states also being parsed by machine automation? Does it mess up the automation to use a different status, or reorder the columns of a table, or format some text as an H4 instead of simply bold?

If the purpose of the incident report templates is to allow reports to be parsed by machines, it would be useful to state that up-front so that reporters know how strictly to abide by the template. If reports are not intended to be machine-readable, then I'm curious as to the purpose of that Unique ID field.

Thanks for indulging my curiosity,

Aaron

[Chris Clements]

Hi Aaron,

Which led me to wonder why this particular field is required. The only explanation that springs to my mind is that the incident reports are being consumed by automation of some form.

We’re not aware of any automation currently consuming these incident reports. 

If the purpose of the incident report templates is to allow reports to be parsed by machines, it would be useful to state that up-front so that reporters know how strictly to abide by the template. If reports are not intended to be machine-readable, then I'm curious as to the purpose of that Unique ID field.

While having these reports be machine-readable is one of our long-term goals, we’ve not yet begun that journey in earnest. Right now, the CA Owner CCADB unique ID field intends to allow us to better correlate the CA Owner and its CCADB records in anticipation of potential future CCADB integration. This future integration may also result in incident reports currently disclosed to Bugzilla migrating to a new platform designed specifically with our community’s needs in mind.

Also, we’ve encountered instances of similar CA Owner names, yet different unique IDs in the CCADB (e.g., “Saudi Data and Artificial Intelligence Authority (SDAIA)” CCADB Unique ID: A011197 compared to “Government of Saudi Arabia, NIC (SDAIA)” CCADB Unique ID: A002584). Use of the CCADB Unique ID field helps further disambiguate the involved CA Owners while promoting clean-up of CCADB data.

We appreciate the curiosity!

-Chris, on behalf of the CCADB Steering Committee

--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/CAEmnErd55Xc_UV3ndNhi13Aa2nGh74mhTJ2Kmt-5etYLv-GEoA%40mail.gmail.com.

[Aaron Gable]

Thanks for the info! I look forward to a future where at least some aspects, like action items, are machine readable and automatically tracked!

Aaron