Resumen

  • Los archivos de AFRINIC del 10, 11, 12 y 13 de septiembre de 2026 contienen 128 objetos de transferencia semánticamente iguales una vez normalizado el orden de las claves JSON.
  • La fecha de producción y el final del intervalo cubierto avanzan cada día, pero el valor máximo de transfer_date sigue siendo el 18 de junio de 2026.
  • Esto no demuestra que falte una operación. Demuestra que la vigencia del archivo y la vigencia de sus eventos son afirmaciones distintas y necesitan un recibo que explique su enlace.

Una publicación nueva puede repetir exactamente el mismo libro de hechos. El registro acumulativo de transferencias de AFRINIC ofrece cuatro ejemplos consecutivos.

Los archivos diarios correspondientes al 10, 11, 12 y 13 de septiembre identifican a AFRINIC como productor, declaran la versión 4.0 del formato y usan un desplazamiento UTC de dos horas. En cada uno, production_date se mueve al día de la publicación. También lo hace records_interval.end_date, mientras el inicio del intervalo permanece en el 1 de enero de 2018.

Lo que no se mueve es la población interna. Los cuatro archivos contienen 128 objetos: 101 de tipo MERGER_ACQUISITION y 27 de tipo RESOURCE_TRANSFER. Si se ordenan de forma canónica las claves de cada objeto y se compara el conjunto con multiplicidad, las transferencias son idénticas. Los hashes binarios son diferentes porque cambian las horas del envoltorio y el orden serializado de algunos miembros. Un cambio de bytes, por tanto, no equivale a un nuevo hecho registral.

La última fecha de transferencia es 2026-06-18T15:48:49Z. Ese objeto describe una anotación por fusión o adquisición entre Global Internet Company y Hormuud Telecom Somalia INC, con AFRINIC como RIR de origen y de destino y SO como código de país de ambas organizaciones. Reúne AS37326, una franja IPv4 y otra IPv6. Aquí sólo sirve para fijar el máximo temporal visible. El archivo no prueba que esa operación sufriera una demora, una impugnación o un error.

La defensa más sólida es que no hubo una novedad que publicar

Un registro acumulativo no debe fabricar movimientos para que su fecha de evento parezca reciente. Es perfectamente posible que el perímetro público haya pasado semanas sin incorporar otra transferencia. También puede tener sentido producir el archivo a diario aunque no cambie: una copia actual permite comprobar que el servicio generador sigue funcionando y conserva una estructura consumible.

El esquema separa parte de esta lógica. Define production_date como la fecha y hora de producción del archivo. Describe records_interval como el periodo cuyos registros cubre el archivo. Y reserva transfer_date para la fecha de la transferencia. La existencia de tres campos evita una falsa equivalencia, pero no termina de documentar el proceso.

¿El final del intervalo certifica que todas las entradas autorizadas fueron consultadas hasta ese instante? ¿Es simplemente un reflejo de la ejecución del generador? Cuando el conjunto queda estable, ¿avanzó un cursor de ingestión y no se aceptó ningún objeto, o se volvió a emitir la copia anterior? Si mañana se corrige una transferencia de 2021, ¿aparecerá como corrección, como llegada tardía o como supuesto evento nuevo?

No contestar públicamente esas preguntas no equivale a ocultar una transferencia. Sólo limita la inferencia que puede hacerse a partir del sello temporal.

Actualidad del contenedor y actualidad del contenido

Los sistemas automatizados suelen tomar el campo más cómodo como prueba general de frescura. El final de cobertura del 13 de septiembre permite decir que el contenedor se produjo entonces. No permite decir que el evento más reciente ocurrió cerca de esa fecha, ni que cada realidad transferible posterior al 18 de junio ya fue representada.

Tampoco cabe deducir lo contrario. El máximo del 18 de junio no demuestra que el mercado se congeló, que exista una cola de expedientes o que una política haya fracasado. El archivo publica operaciones ejecutadas conforme a su alcance. No muestra solicitudes privadas, expedientes retirados, rechazos, diligencia pendiente ni decisiones todavía sin ejecución. Sus observaciones advierten además que el informe no pretende aportar toda la información relacionada con una transferencia.

La unidad 128 requiere igual cautela. Son objetos del formato, no necesariamente contratos, organizaciones distintas ni transacciones económicas independientes. Un objeto puede agrupar ASN, IPv4 e IPv6. La distribución por año —13 en 2018, 19 en 2019, 20 en 2020, 22 en 2021, 28 en 2022, ocho en 2023, cinco en 2024, nueve en 2025 y cuatro en 2026— describe el inventario publicado, no el valor ni la liquidez del mercado.

La guía de AFRINIC promete publicar las transferencias ejecutadas e identificar cedente, recurso, receptor, fecha y tipo. Esa visibilidad ayuda a mantener coherente la historia registral. Para que también sirva como evidencia temporal, necesita decir qué acredita la fecha móvil del archivo.

Un recibo sin revelar expedientes

El recibo de cobertura puede ser breve: versión del esquema, hora de producción, final de cobertura declarado, fecha máxima de evento, número de objetos y hash canónico del conjunto. Debería enlazar con el hash anterior y clasificar por separado objetos añadidos, corregidos, retirados de la representación pública o incorporados tardíamente.

La pieza decisiva sería el cursor de la fuente autorizada. Si ese cursor avanza y no entra ningún objeto, el recibo puede declarar “comprobado hasta este punto; cero novedades aceptadas”. Si se modifica un dato antiguo, la diferencia queda etiquetada como corrección. No hace falta revelar solicitudes, contratos, correspondencia ni pruebas comerciales privadas.

Los cuatro archivos observados son coherentes: no contienen un conteo cambiante ni una fecha de evento contradictoria. Su enseñanza es más precisa. Un archivo actual y un evento actual son dos objetos de evidencia. AFRINIC ya publica ambos relojes; falta una unión que explique qué asegura el que avanza.

Fuentes