APNIC restores 92 WHOIS/RDAP reports but leaves repairs undocumented

Summary

APNIC’s October archive now lists all 92 WHOIS/RDAP reports for 23 October 04:00 through 27 October 00:00 UTC. The reports and their MD5 sidecars carry the same displayed modification time: 29 October 10:16, APNIC’s UTC+10 listing time.
APNIC’s 16 October notice still has no end time or duration. A checksum can confirm downloaded bytes; APNIC’s published schema does not say whether the underlying logs for each hour were complete.

Ninety-two files, one timestamp

On 27 October, APNIC’s archive jumped from 23 October to 27 October, leaving 92 hourly reports absent. They are now there. The interval begins at 04:00 UTC on 23 October and ends at 00:00 UTC on 27 October: four days, 92 consecutive one-hour slots.

The directory gives the return a blunt timestamp. Every expected report and every accompanying .md5 file in that window is listed as modified on 29 October at 10:16. That is APNIC’s UTC+10 listing time. HTTP metadata for the first and last reports gives 00:16:28 UTC. I downloaded those two gzip files, checked their stated intervals, and matched each file’s MD5 against APNIC’s sidecar. The first covers 23 October 04:00–05:00 UTC; the last covers 26 October 23:00–27 October 00:00 UTC.

The current feed has kept moving. APNIC’s latest WHOIS and RDAP JSON now covers 30 October 23:00–31 October 00:00 UTC, and its sidecar matches the downloaded bytes. At the file level, the missing run has been restored and hourly publication is current.

The incident record did not move with it. APNIC’s 16 October service notice says log-processing problems made statistics incomplete from 10:00 UTC+10 onward. It says generation was disabled and affected files would be republished after the processing issue was fixed. The notice still leaves its end time and duration blank. The service-update index lists the notice, but no separate closeout for this statistics incident.

The archive now contains the 92 reports again. APNIC’s README lists each hourly report’s interval, query totals, query-type counts, distinct ASN total and per-ASN figures. The public materials include no revision ID, per-hour completeness status or recovery manifest. The two sampled MD5 sidecars match their downloaded files. A processing record is still needed to identify which logs fed each report and whether every affected interval was reconstructed.

A reproducibility check now has a clear split: the 27 October archive snapshot lacks 92 intervals; a fresh download contains them. Run the same time-series script over both folders and the chart covers different hours. Reproducing either result requires its dated archive copy; reconciling the new intervals also requires APNIC’s processing run and per-hour recovery status. The notice still has no end time for the period it said was affected from 16 October.

The archive needs a receipt, not another quiet upload

APNIC could close this neatly with an interval manifest: each affected UTC hour, its recovery status, the processing-run identifier, the current checksum and a clear end time for the incident. If a report is still incomplete, say so against that interval. Readers could then distinguish restored files from confirmed-complete statistics and reproduce the same series later.

The directory timestamp records when the files returned. A repair ledger should record the processing run and status for each interval. APNIC has put the missing hours back; the next public record should show how it produced those reports.