APNIC reanuda sus estadísticas; faltan 92 horas en el archivo

Resumen

La captura del JSON de WHOIS y RDAP de APNIC de las 08:38 UTC cubre el 27 de octubre, de 05:00 a 06:00 UTC; su MD5 coincide con el archivo descargado. La publicación horaria ya se había reanudado.
El archivo de octubre no contiene informes para 92 horas consecutivas, desde el 23 de octubre a las 04:00 hasta el 26 a las 23:00 UTC. El aviso del 16 de octubre sigue sin hora de cierre, duración ni lista de intervalos corregidos.

Volvió el flujo. Las horas perdidas no vinieron detrás.

A las 08:38 UTC, el JSON de APNIC cubría la hora que terminó a las 06:00 UTC del 27 de octubre. Su MD5 coincidía con el archivo descargado. El directorio mensual guardaba informes hasta las 04:00–05:00 UTC. La publicación horaria ya se había reanudado.

El archivo cuenta otra historia. El último fichero anterior al hueco corresponde al 23 de octubre, de 03:00 a 04:00 UTC. El siguiente empieza a medianoche del día 27. Entre ambos hay 92 comienzos de hora sin archivo. Regresó el informe más reciente; el calendario aún tiene cuatro días en blanco.

La cuenta sigue las reglas de publicación de APNIC. Su README dice que cada informe cubre una hora UTC semiabierta. Cuando se publica uno nuevo, sustituye al archivo actual y el anterior pasa al archivo mensual. El nombre 20261023-0300 identifica las 03:00–04:00; el siguiente debía comenzar a las 04:00. El directorio salta después a 20261027-0000. Son 92 horas sin fichero.

El aviso de servicio del 16 de octubre sitúa el inicio a las 10:00 UTC+10, es decir, las 00:00 UTC. Identifica el servicio como “Whois and RDAP stats”, atribuye el problema al procesamiento de registros, dice que las estadísticas pasan a ser incompletas desde entonces y que la generación quedó desactivada. APNIC prometió republicar los archivos afectados cuando se resolviera el problema. Los campos de hora de cierre y duración siguen vacíos.

El archivo deja ahora una pista de reparación: el fichero del 23 de octubre, 03:00–04:00, se volvió a escribir el día 27 a las 03:12 UTC. Después aparecen nuevos informes. El registro público muestra una hora reciente y un archivo antiguo republicado, pero no enumera qué intervalos se reconstruyeron, cuáles siguen incompletos ni cuáles quedarán fuera. El índice de avisos aún conserva la notificación original, sin una entrada de cierre.

En una serie temporal, ese vacío obliga a elegir cómo calcular. Un programa puede eliminar la hora ausente, interpolarla o convertirla en cero. Cada opción altera promedios y alertas. Los informes de APNIC incluyen totales de consultas, distribución por tipo y recuentos de IP de origen distintas por ASN de origen. Las marcas de tiempo y los checksums permiten verificar cada archivo; un estado de integridad y un historial de correcciones por hora explicarían la serie completa.

Un checksum certifica bytes. No lleva el libro de reparaciones.

APNIC ya tiene los ingredientes para publicar una recuperación ordenada. Cada intervalo corregido podría incluir sus límites UTC, estado, hora de primera publicación, hora de corrección, checksum vigente y checksum sustituido. Un manifiesto breve podría marcar cada hora ausente como republicada, no disponible o retenida, y enlazar el fichero correspondiente. Los investigadores conservarían la versión anterior, reconocerían la nueva y recalcularían la serie sin hacer arqueología del directorio.

Las piezas cumplen funciones distintas: el checksum confirma que la descarga coincide con los bytes publicados por APNIC; el nombre señala la hora del informe; el aviso fija el comienzo de la incompletitud el 16 de octubre a las 00:00 UTC. Un manifiesto conectaría esos datos hora por hora.

El aviso habla del generador estadístico y de ficheros estadísticos. El informe del 27 de octubre acredita que la publicación se reanudó. La siguiente actualización útil debería identificar las horas afectadas, publicar los checksums de los archivos corregidos y cerrar el aviso del día 16. El reloj volvió a la pared; el archivo todavía debe 92 líneas a sus lectores.