Resumen

  • La documentación pública de la API NIR de APNIC enseña una llamada asíncrona a /nir-delegations/asn, aunque el propio tutorial habla de recursos procedentes de las delegaciones de pool del NIR.
  • En septiembre de 2024 seguían en curso los cambios del registro central y la API; en diciembre el proyecto de asignaciones directas de ASN para NIR estaba en control de calidad final. La ficha actual, situada en 2025, no tiene objetivo fechado ni historial de cambios.
  • APNIC podría cerrar el vacío con un recibo de despliegue que relacione el proyecto, la semántica exacta de la API, los NIR participantes, los datos migrados y las comprobaciones agregadas de Whois y RDAP.

La primera columna del expediente parece sencilla. APNIC quería permitir la delegación directa de ASN a titulares de cuentas de un Registro Nacional de Internet. Su hoja de ruta explica el motivo: mejorar la consistencia y la validez de los datos. La solución propuesta consistía en desarrollar la función dentro del registro y exponerla mediante MyAPNIC y la API NIR.

La segunda columna también parece clara. En septiembre de 2024, los informes al Consejo Ejecutivo hablaban de actualizaciones en curso tanto en el registro central como en la API NIR. En diciembre, el trabajo se encontraba en pruebas finales de calidad. El paquete de información de comienzos de 2025 seguía enumerando el proyecto entre las tareas en curso.

La tercera columna es operativa. La documentación pública de la API NIR afirma que los NIR pueden gestionar la información de registro de sus subcuentas. Un tutorial presenta una solicitud a /nir-delegations/asn, exige datos de contacto para formar las entradas de Whois y RDAP y devuelve el enlace a una tarea. La mutación se ejecuta de manera asíncrona. En el ejemplo, la consulta posterior termina con SUCCESSFUL. Las reglas generales de la API permiten incluir una Idempotency-Key para repetir una petición interrumpida sin ejecutar dos veces la misma operación.

El problema aparece al intentar unir las columnas. Ninguna comparte un identificador de lanzamiento con las otras.

Un endpoint no lleva su biografía incorporada

La existencia de una ruta de API demuestra que APNIC documenta una superficie capaz de tramitar una delegación ASN. No demuestra cuándo adquirió esa capacidad, ni qué modelo de recursos ejecuta. El matiz está dentro del propio tutorial: la acción se describe como una delegación desde los pools delegados al NIR. La hoja de ruta, en cambio, habla de delegación directa de ASN a las cuentas del NIR.

Tal vez la misma URL se mantuvo mientras APNIC cambió la lógica interna. Tal vez el tutorial todavía ilustra una modalidad previa. Tal vez “directa” se refiere únicamente a la escritura en el registro central, no a la procedencia del número. Las fuentes no permiten resolverlo. Por eso tampoco es correcto afirmar que la función no se desplegó. Lo único demostrado es que el registro público de producto no vincula la interfaz documentada con la semántica del proyecto posterior.

Esta distinción puede parecer administrativa hasta que se observa qué representa un ASN. Es el identificador de un sistema autónomo que intercambia información de encaminamiento bajo una política propia. La política vigente de APNIC permite pedirlo a APNIC o al NIR correspondiente. También exige que todo ASN asignado quede registrado públicamente en Whois de APNIC o del NIR. La solicitud, la evaluación, la procedencia del recurso y la publicación forman una sola cadena de autoridad, pero no son el mismo acto.

Una respuesta SUCCESSFUL cubre un tramo corto de esa cadena. Confirma que una tarea terminó según el servicio que la ejecutó. No señala qué versión del esquema validó la petición, qué capa aprobó la elegibilidad, de qué pool salió el ASN o si las vistas de Whois y RDAP quedaron alineadas. Un tutorial no debería convertirse en un informe de auditoría para suplir esas preguntas. Hace falta otro artefacto.

La ficha se queda entre 2024 y 2025

La hoja de ruta actual coloca “NIR ASN Direct Assignments” en 2025. Identifica al equipo de Registry, nombra ARMS y MyAPNIC y conserva la explicación del resultado esperado. Sin embargo, el campo de objetivo está vacío. El campo de historial de cambios también lo está.

El Informe Anual 2025 añade una ambigüedad distinta. APNIC declara que alcanzó los objetivos trimestrales de producto y menciona expresamente varios resultados del registro: cambios en la autorización de Whois, objetos RPKI Signed Checklist y una prueba de concepto para la nueva arquitectura de RDAP. El documento completo no nombra el proyecto de ASN para NIR.

El silencio no equivale a una cancelación. Un campo vacío tampoco prueba que no exista un historial interno. Y las páginas alojadas en un dominio de testbed no acreditan una operación en producción. Pero, después de la última constancia de pruebas finales, el lector no dispone de una nota que diga: esta versión se activó tal día, para estos NIR, con estas reglas y este tratamiento de los registros antiguos.

Las organizaciones suelen publicar por separado planes, documentación técnica y memorias anuales. Nada exige que se conviertan en un único texto. Lo que sí se necesita es una clave estable que permita relacionarlos. Sin ella, el investigador deduce que tres piezas cercanas describen la misma entrega porque sus nombres se parecen. En sistemas de registro, esa deducción es demasiado frágil.

“Directo” puede designar cuatro cosas

APNIC relató en 2019 cómo había cambiado el modelo de los NIR para las direcciones IPv4. Antes de 2004, algunos NIR recibían grandes bloques bajo un modelo de confederación y luego realizaban subdelegaciones. Después, las asignaciones y adjudicaciones se efectuaron desde el pool regional común y se reflejaron directamente en el registro de APNIC. Los bloques históricos permanecieron, y la reconciliación posterior corrigió fechas, identidades y transferencias.

Ese antecedente no es una explicación del proyecto ASN. Sirve para mostrar la carga del vocabulario. “Directo” puede referirse al pool regional, a la escritura en una base central, a la eliminación de una doble carga manual o a la relación contractual con la organización solicitante. Las cuatro dimensiones pueden moverse juntas o por separado.

El marco de los NIR mantiene esa complejidad de forma deliberada. Los NIR existen para prestar servicios en la lengua y el contexto local. Son responsables del cumplimiento de la política sobre los recursos que administran y pueden adoptar reglas locales compatibles con las regionales y globales. APNIC debe seguir admitiendo miembros directos. Una entidad que pertenece a ambas estructuras solo puede obtener servicios de recursos de una fuente cada vez.

Por tanto, una escritura directa en el registro de APNIC no tiene por qué desplazar al NIR de la evaluación del solicitante. Puede ser la automatización de una decisión tomada por el NIR. Eso mejoraría la calidad al reducir copias y retrasos, justo como pretende la hoja de ruta. Pero el cambio debe decir qué autoridad permanece en cada lado: quién decide, quién valida, quién escribe, quién corrige y quién responde cuando las proyecciones públicas discrepan.

El control de idempotencia no es control de política

La Idempotency-Key resuelve un riesgo concreto. Si la conexión cae después de enviar una solicitud, el cliente puede repetirla y recibir el mismo resultado sin crear una delegación duplicada. Es una propiedad importante en cualquier sistema que asigne un recurso único.

No resuelve los riesgos semánticos. La misma petición puede ser única y, aun así, haberse procesado con una regla antigua. El task puede terminar una sola vez y proyectar datos de contacto incoherentes. Dos NIR pueden usar versiones distintas durante una adopción escalonada. Una migración puede dejar fuera registros heredados. La idempotencia protege la ejecución frente a la repetición; no acredita que todos los participantes entiendan igual la palabra “directa”.

Por eso el recibo que falta es de lanzamiento y garantía, no solo de transacción. Debe responder qué cambió en el modelo y qué controles comprobaron el resultado. Debe poder citarse años después, cuando una transferencia, una devolución o una corrección obligue a reconstruir la autoridad vigente en la fecha original.

La revisión pública mide otra población

APNIC mantiene además un programa de revisión de delegaciones. La iniciativa incluye análisis de datos, comprobaciones aleatorias, revisión de procedimientos, exactitud de cuentas, formación y un futuro examen de los acuerdos con NIR. En el segundo trimestre de 2026, APNIC comunicó la finalización de las revisiones de JPNIC, TWNIC y KRNIC, mientras seguía trabajando con otros registros.

La descripción pública de la actividad principal es, no obstante, específica: revisa diez años de delegaciones y transferencias IPv4. No puede utilizarse como prueba independiente de que el nuevo recorrido de ASN está desplegado o produce datos válidos. Esto no significa que APNIC carezca de controles internos sobre ASN; significa que los resultados publicados de esa revisión tienen otro denominador.

Así aparecen tres tipos de evidencia que no deben confundirse. El task de API informa de una operación. El programa de revisión informa de una población IPv4. La hoja de ruta informa de una intención de producto. Falta la pieza que declare qué versión unió la intención con el endpoint y en qué ámbito.

Cómo sería un recibo útil

El documento puede ser breve. Primero, un bloque de identidad: código inmutable del proyecto, versión de API y esquema, instante de puesta en producción, alcance de servicios, estado de rollback y definición exacta de “directa”. Segundo, un bloque de adopción: NIR incluidos, despliegue simultáneo o escalonado, compatibilidad con el modelo de pools y fecha de retirada de cualquier ruta anterior.

Tercero, un bloque de migración: cohortes de ASN anteriores, subcuentas actualizadas, registros excluidos y excepciones abiertas. Cuarto, comprobaciones agregadas durante un periodo acotado: intentos, éxitos, rechazos, anulaciones y reconciliaciones; correspondencia entre la mutación central y las vistas Whois/RDAP; duplicados absorbidos por idempotencia. No hace falta publicar nombres, documentos de elegibilidad ni credenciales.

El valor del formato está en separar tres verdades. La verdad del lanzamiento identifica las reglas desplegadas. La verdad de la transacción registra qué hizo una solicitud. La verdad del estado muestra lo que el público ve hoy. Un buen registro las conecta por identificadores y fechas. No obliga al lector a usar una como sustituto de las otras.

Fuentes