Resumen

  • El 0,006 % se refiere a casos de consulta Whois en los que apareció un objeto NONAUTH; el 20 % se refiere a solicitudes NRTM que pidieron actualizaciones de esa fuente. No son porcentajes comparables de usuarios ni de tráfico.
  • La nueva limpieza sigue en estado “Starting”. Una decisión verificable debe indicar objetos, regla, aviso, migración y comprobación posterior antes de retirar datos.

Una respuesta y un espejo no hacen la misma pregunta

Whois atiende una consulta puntual. NRTM permite recibir cambios de una base y mantener una copia local al día. Puede que un objeto aparezca pocas veces en la primera vía y aun así sea solicitado con frecuencia por otra. No es una contradicción: son mediciones de recorridos distintos.

El 17 de julio de 2025, RIPE NCC explicó en la lista del Database WG que objetos de RIPE-NONAUTH aparecieron en cerca del 0,006 % de los casos de consulta Whois. En el mismo mensaje indicó que aproximadamente el 20 % de las solicitudes NRTM consultaban actualizaciones de NONAUTH. No publicó el intervalo medido, los denominadores absolutos ni cuántos clientes de espejo distintos había. Por tanto, no se pueden dividir, restar ni convertir los porcentajes en un indicador único de uso.

El primer número responde a una pregunta acotada: con qué frecuencia aparecieron objetos NONAUTH en las respuestas Whois observadas. No dice cuántas redes diferentes dependían de esos casos, si eran importantes para su operación o qué recibían desde un espejo local. Tampoco incluye a quien consulta solo fuentes autoritativas. RIPE NCC señala que NONAUTH se incorpora por defecto y advierte que un cliente puede confiar en información no autoritativa si no comprueba el atributo source; la opción “-s RIPE” limita la búsqueda a esa fuente.

El 20 % responde otra cosa: qué proporción de solicitudes NRTM pidió cambios de NONAUTH. No indica si las solicitudes procedían de muchos consumidores o de unos pocos sistemas automáticos, si cada petición terminó en una transferencia correcta ni si los datos se aplicaron en producción. Un mismo proceso puede consultar repetidamente; otro cliente puede obtener un archivo diario. El porcentaje no es un recuento de operadores, clientes, tráfico, espejos ni dependencias.

El motivo de depurar existe; también existe una laguna de evidencia

RIPE-NONAUTH separa desde 2018 ciertos objetos no autoritativos de recursos fuera de la región. RIPE NCC tiene un motivo legítimo para reducir información cuyo origen o vigencia actual pueden ser desconocidos. En la actualización operativa de RIPE 90, de mayo de 2025, el equipo dijo que la fuente recibía menos de cien cambios anuales y que el inventario disminuía gradualmente. Son razones para preguntar si cada objeto aún sirve; no prueban que todo lo que queda sea redundante.

La discusión de 2025 propuso reglas delimitadas, como objetos que coinciden con un ROA válido o con una ruta de otro RIR. En RIPE 91, RIPE NCC informó que había enviado algo más de 2.000 avisos a mantenedores de objetos potencialmente afectados. Recibió 33 respuestas: 23 pidieron que sus objetos no se borraran; con diez mantenedores se habló sobre el uso y el personal ayudó a crear alternativas en bases autoritativas. Es una señal concreta del trabajo de transición, no una muestra representativa de todos los consumidores. Quienes contestan pueden no parecerse a quienes no lo hacen, y las respuestas no cuentan todos los espejos activos.

En RIPE 92, Job Snijders apoyó retirar rutas con un ROA válido correspondiente o con una ruta coincidente en otra base de RIR. AMS-IX dijo que sus servidores de rutas dejaron de usar NONAUTH hace años sin quejas ni impacto operativo. Es un ejemplo útil, pero limitado a un operador y su trayectoria. RIPE NCC pidió que otros operadores aún dependientes se identificaran; las actas reflejan debate, no una votación para retirar la base.

“Starting” no equivale a un calendario de borrado

El plan de la base RIPE para el cuarto trimestre de 2026, actualizado el 17 de septiembre, dice que se propondrán nuevas limpiezas después de la discusión en la lista y en RIPE 92. El estado es “Starting”. El plan no enumera el conjunto final de objetos, la lógica de coincidencia, una fecha, un período de gracia, excepciones ni cambios a NRTM. Reducir algunos registros no equivale a cerrar la base, y no se informa que ninguna de esas etapas se haya ejecutado.

Cada regla debería venir acompañada por una instantánea fechada, tipos de objeto, definición de coincidencia y número afectado. Las consultas Whois y las solicitudes de actualización NRTM requieren períodos y denominadores separados. Si los registros lo permiten, se podría publicar un recuento agregado, respetuoso de la privacidad, de consumidores distintos; no se debe deducir ese recuento de las peticiones. También conviene separar mantenedores avisados, respuestas, migraciones completadas y casos sin alternativa.

No hace falta crear un programa permanente de telemetría. Hace falta un recibo versionado para un cambio que modifica el camino de los datos: regla, aviso, alternativa, período de gracia, prueba en un grupo acotado y condición que detenga la ampliación si el comportamiento difiere de lo esperado. Retirar duplicados exactos es una decisión distinta de retirar todo lo cubierto por un ROA; apagar NRTM sería otra más. Llamar “uso” a las tres cosas juntas ocultaría la diferencia que debe guiar la decisión.

Fuentes