Resumen

  • La instantánea firmada del 7 de septiembre marcó AS36887, AS36911, AS36921 y 41.204.224.0/19 como reserved; la del día 8 mostró los cuatro como allocated en Nigeria bajo un mismo identificador opaco.
  • Las fechas que reaparecen siguen en 2006. El formato de AFRINIC las define como fechas de primera asignación, no como la fecha del último cambio de estado.
  • RDAP muestra hoy los cuatro recursos activos bajo DIRECT ON PC LTD, con eventos de registro el 7 de septiembre de 2026 y una hora común de última modificación, las 14:19 UTC.
  • Ninguna superficie pública identifica si hubo corrección, restitución, reasignación, resultado de una revisión u otro acto autorizado. Un recibo de transición del estado resolvería esa laguna sin publicar el expediente privado.

Cuatro filas cambiaron juntas

El archivo extendido del 7 de septiembre fija con claridad el punto de partida. Los tres ASN y el bloque de 8.192 direcciones que comienza en 41.204.224.0 figuran como reserved. El país es ZZ; los campos de fecha y titular opaco están vacíos.

La instantánea del 8 de septiembre les da otro significado público. El país pasa a Nigeria, el estado a allocated y las cuatro filas comparten F36DCCF2. Los ASN conservan fechas del 16 de enero, 4 de agosto y 7 de noviembre de 2006. El /19 lleva el 1 de agosto de 2006.

Ahí está la trampa cronológica. Quien mire solo el archivo actual verá cuatro asignaciones antiguas. Quien compare ambos días verá una decisión o una operación actual. Ninguna lectura autoriza a llamarla una nueva asignación de septiembre.

La fecha antigua y el evento nuevo responden preguntas distintas

El README del archivo extendido define la fecha como la de asignación. La especificación de intercambio presenta el archivo como una foto del estado corriente sin detalles transaccionales ni históricos. Es una arquitectura defendible: la foto dice dónde está el registro, no reproduce todos los pasos que lo llevaron allí.

RDAP añade un segundo reloj. AS36887, AS36911, AS36921 y 41.204.224.0/19 aparecen activos a nombre de DIRECT ON PC LTD. Sus eventos de registro se produjeron a las 12:03, 12:06, 12:08 y 12:18 UTC del 7 de septiembre. Los cuatro fueron modificados por última vez a las 14:19.

La proximidad temporal hace legible el cambio del archivo del día siguiente. No explica la clase ni la autoridad de la transición. «Registration» es una etiqueta de evento de RDAP, no la motivación de una decisión.

El conjunto ya había cruzado antes

La historia muestreada muestra más de una reversión. El archivo del 1 de enero de 2021 presenta los cuatro recursos como allocated, con las mismas fechas y el mismo token. En 2022 pasan a reserved. En 2023 regresan a allocated. En 2025 vuelven a reserved, donde siguen el 7 de septiembre de 2026.

El muestreo prueba cambios repetidos en el estado publicado. No fecha el día exacto de las transiciones anteriores ni explica sus causas. El identificador opaco ayuda a agrupar filas dentro de la serie, pero AFRINIC avisa que puede variar entre versiones.

La mejor defensa está en el propio formato

Sería injusto exigir a una instantánea que funcione como un expediente. Los archivos son legibles por máquina, están firmados y usan estados definidos. RDAP expone la organización actual y eventos actuales. Mantener las fechas de 2006 puede proteger la continuidad histórica, en vez de fingir que recursos antiguos nacieron de nuevo esta semana.

Tampoco corresponde publicar comunicaciones privadas, contactos personales, cuentas o pruebas jurídicas protegidas. La petición es más acotada: cuando un conjunto de recursos escasos pasa entre dos estados públicos, el registro debería nombrar la clase de transición y la autoridad que la sostiene.

Un recibo mínimo basta

El recibo podría unir los hashes de las dos instantáneas firmadas con una referencia privada del conjunto, el estado anterior y el nuevo, la hora efectiva y la hora de publicación. Una clase general —corrección de datos, restitución, reasignación, resultado de una revisión u otro acto autorizado— sería suficiente sin revelar la prueba confidencial.

También debería decir qué autoridad se aplicó, por qué siguen siendo correctas las fechas de 2006, cómo se relacionan con los eventos RDAP de 2026, qué superficies públicas se reconciliaron y dónde aparecería una corrección posterior. Eso preservaría la línea de decisión sin convertir la transparencia en exposición.

Fuentes