Resumen

  • Un informe de la Secretaría de APNIC de 2019 dice que Resource Quality Assurance pasó a llamarse Resource Quality Check para evitar falsas expectativas y responsabilidad legal. El cambio delimita lo que una observación puede demostrar.
  • APNIC puede comprobar una vista de la tabla global de rutas, vigilar recursos no delegados e investigar señales operativas. No puede garantizar la conducta de cada red autónoma, lista de reputación o proveedor de geolocalización.
  • El resultado útil no es una etiqueta de «calidad», sino una observación que conserva fecha, fuente, clase de punto de vista, condición probada, exclusiones y motivo para volver a medir.

Cuando una palabra asigna demasiado poder

En septiembre de 2019, la Secretaría de APNIC dejó constancia de una decisión poco espectacular y muy importante. El proyecto Resource Quality Assurance, RQA, había sido rebautizado como Resource Quality Check, RQC. El motivo publicado era evitar falsas expectativas y responsabilidad legal. El mismo informe señalaba que se había redactado documentación de descargo y que NetOX incorporaba una sección RQC. Informe de la Secretaría de APNIC

No era solo una cuestión de estilo. El proyecto pretendía detectar problemas operativos de bloques concretos: filtrado de rutas, inclusión en listas negras de correo y de otros servicios, historial de enrutamiento y errores de geolocalización. Todos afectan al uso, pero ninguno pertenece por completo a una única autoridad. El registro decide el estado de delegación. Otros operadores deciden qué rutas aceptan. Los servicios de reputación y geolocalización mantienen datos propios.

El informe de actividad presentado en APNIC 49 confirmó la continuidad del nombre: describió RQC como «anteriormente RQA», enumeró las mismas clases de señales y dijo que las funciones estaban incluidas en NetOX. Ambos documentos son de APNIC, por lo que no constituyen corroboración institucional independiente. Sí demuestran que la frontera semántica fue intencionada. Informe de actividad de APNIC 49

«Control» nombra una acción. Permite preguntar cuándo se realizó, desde dónde y con qué datos. «Aseguramiento» puede sugerir un estado que acompaña al bloque. Para mantener ese estado, APNIC necesitaría gobernar sistemas que no le pertenecen.

El objetivo general y la prueba concreta

La página actual de servicios de registro conserva la expresión Resource Quality Assurance y afirma que RQA evalúa el espacio asignado a APNIC antes de distribuirlo a los Miembros. En la navegación de esa misma página aparece Resource Quality Check. La captura demuestra que ambas expresiones coexisten, pero no permite fechar su redacción ni atribuir una intención a quien las mantuvo. Servicios de registro de recursos

La página específica de RQC acota mejor la promesa. Parte del deseo razonable de recibir recursos enrutables y enseguida advierte que la política de APNIC no garantiza la enrutabilidad global. APNIC actúa para reducir problemas. Luego separa dos épocas: la evaluación de bloques IPv4 /8 recibidos de IANA antes de 2011, y actividades continuas como vigilar el uso de recursos APNIC no delegados y consultar la tabla global de rutas desde el router de APNIC al efectuar una delegación. Si el recurso sigue anunciado, APNIC dice que no lo delegará. Resource Quality Check

Esa decisión evita una colisión evidente. Ver una ruta antigua en el momento de entregar el bloque es razón suficiente para detenerse. Sin embargo, el dato responde a una pregunta delimitada: ¿qué veía el router de APNIC en ese momento? No certifica lo que verán mañana todos los pares, clientes, recolectores de rutas, cortafuegos o aplicaciones.

La FAQ sitúa el resto del trabajo. Los RIR no controlan cómo los operadores administran, enrutan o filtran las direcciones; ninguna organización puede garantizar por sí sola la enrutabilidad en toda Internet. APNIC recomienda separar los síntomas: entrega de correo, acceso a sitios, estructura de red, anuncio, proveedores ascendentes, trayectos de ida y vuelta. Sugiere RIS y looking glasses. Si una red bloquea las direcciones, el titular debe pedirle que retire el filtro. No puede devolver el bloque a APNIC solo porque aparezca un problema de alcance. FAQ sobre calidad de recursos

No hay necesariamente contradicción. La página general expresa una finalidad; RQC documenta acciones dentro del alcance del registro; la FAQ reconoce decisiones ajenas. El problema surge cuando los tres niveles se condensan en una palabra sin contexto y el lector interpreta «calidad» como una característica estable del número.

Las pruebas históricas llevaban fecha por una razón

La página de pruebas de alcance describe un método aplicado con RIPE NCC. Ambas organizaciones anunciaban prefijos piloto de bloques nuevos, comparaban su distribución con prefijos ordinarios, publicaban informes diarios de visibilidad y ofrecían objetivos que respondían a ping y herramientas para probar desde los prefijos. Las diferencias podían señalar ISP que aún filtraban el bloque.

Los ensayos enumerados se realizaron en 2010 y 2011 sobre partes de 1/8, 14/8, 27/8 y otros espacios. La fecha, los colaboradores y el informe son parte del resultado, no adornos bibliográficos. Explican qué se observó y cuándo. La página no permite convertir ese método histórico en una descripción de cada delegación actual; RQC expone las actividades continuas por separado. Pruebas de alcance

La página «Currently Assessing» ofrece otro ejemplo prudente. Muestra quince prefijos de debogonización y, en una lista separada, informes y evaluaciones. El texto capturado no asigna una puntuación universal ni declara que esos elementos garanticen alcance global. Un prefijo en una lista es un objeto de trabajo; un informe con fecha es evidencia para una decisión concreta. Recursos en evaluación

La RFC 6441 explica por qué una prueba correcta puede envejecer. Como práctica recomendada de IETF, aconsejó retirar los filtros basados en los antiguos /8 IPv4 no asignados. Quien decidiera seguir filtrando espacio no asignado gestionado por los RIR necesitaría reglas mucho más granulares y actualizadas cada día para no bloquear tráfico legítimo. Un cambio en el registro no modifica automáticamente una copia antigua de la lista en un router remoto. RFC 6441

La misma lógica se aplica fuera de BGP. Una lista de correo puede conservar la conducta del anterior usuario. Una base de geolocalización puede tardar en ingerir la nueva información. Una aplicación puede copiar una señal de reputación. APNIC puede aportar pruebas y facilitar la corrección, pero no ordenar el calendario de todos esos sistemas.

Cinco preguntas escondidas dentro de «calidad»

Antes de emitir una etiqueta conviene descomponerla. ¿El bloque está correctamente registrado y disponible? ¿Existe una ruta inesperada en los datos examinados antes de delegarlo? ¿Las redes remotas aceptarán el anuncio previsto? ¿Los sistemas de reputación permitirán tráfico y correo? ¿Los proveedores de geolocalización describirán el uso de forma adecuada?

APNIC tiene autoridad central sobre la primera cuestión y puede observar de manera valiosa la segunda. Las demás pertenecen a sistemas distribuidos. Incluso la visibilidad de rutas cambia según el recolector y la hora. Un único indicador verde no informa qué capa se probó ni quién debe corregir un fallo.

El remedio tampoco puede ser un certificado gigantesco. Exponer topología o datos de clientes sería improporcionado. Un documento complejo puede quedar obsoleto y una puntuación pública puede convertirse en una barrera o en un incentivo para optimizar la métrica. APNIC ya publica límites y consejos razonables. RQC no debe transformarse en permiso central para usar direcciones.

Hace falta algo más pequeño: que la observación conserve el recurso, el intervalo temporal, la clase de punto de vista, la fuente, la condición probada, la conclusión admisible, las exclusiones, el actor que puede actuar y el desencadenante de una nueva prueba. No es necesario revelar pares privados.

«APNIC no observó una ruta desde su router durante el control de delegación» es más útil que «bloque limpio». La primera frase puede verificarse y no pretende resolver el correo o la geolocalización. Si después aparece un filtro lejano, no demuestra que APNIC mintió; demuestra que la conclusión nunca abarcó todas las decisiones futuras.

La limitación es parte del servicio

Esta investigación no detectó una delegación fallida, un recurso inaccesible, un filtro obsoleto, una lista negra, un error geográfico, un perjuicio a un Miembro ni una avería de NetOX. No se probó un bloque real ni una sesión del producto. Tampoco se conocen todos los controles internos de APNIC. La mención de responsabilidad legal en 2019 no convierte este análisis en opinión jurídica.

La evidencia sí muestra que APNIC identificó el riesgo de presentar una observación como promesa. Su página RQC y la FAQ asignan responsabilidades de forma defendible: el registro examina lo que puede ver y decide dentro de su función; los operadores controlan sus filtros; el titular investiga los sistemas que aún bloquean.

Alinear la redacción general con esa precisión no restaría confianza. La haría auditable. La mejor forma de preservar el cambio de 2019 es impedir que el resultado pierda su fecha y su punto de vista. Una dirección no posee calidad por naturaleza; posee una historia de observaciones que otros pueden volver a comprobar.

Fuentes

  1. APNIC: servicios de registro de recursos
  2. APNIC: Resource Quality Check
  3. APNIC: FAQ sobre calidad de recursos
  4. APNIC: Resource Reachability Testing
  5. APNIC: Currently Assessing
  6. Consejo Ejecutivo e informe de la Secretaría de APNIC, 9 de septiembre de 2019
  7. Informe de actividad presentado en APNIC 49
  8. RFC 6441 / BCP 171