Resumen

  • La página de la API de Registro de LACNIC remite a Postman para consultar la documentación v3 más actual, mientras su propia tabla sigue describiendo modificaciones y bajas de ROA mediante una ruta por serialNumber.
  • La colección enlazada usa organizationId: obtiene y crea sobre la lista de la organización, y su PUT reemplaza la lista existente por una versión actualizada. Los ejemplos públicos revisados no muestran versión base, precondición, diferencia prevista ni vista previa.
  • Sustituir un estado completo puede ser una interfaz limpia, atómica e idempotente. La mejora mínima consiste en vincular cada lista con el estado leído, mostrar el cambio y devolver un resultado verificable sin exponer identidades ni controles internos.

Un equipo que prepara una integración suele empezar por la ruta de información. En LACNIC, la ruta de información de v3 redirige hoy a una colección Postman publicada. La página de la API de Registro refuerza esa señal: allí se indica que la documentación más actual de la versión 3 se encuentra en Postman.

Hasta ese punto, la jerarquía documental es clara. El problema aparece unas líneas más abajo, en la tabla de endpoints. Para crear y consultar ROA figura /rpki/roas. Para modificar y eliminar aparece /rpki/roas/{serialNumber}. El lector recibe el modelo de un recurso individual: identifica el registro y aplica la acción a ese registro.

La colección API Registro v3 Prod lleva a otra arquitectura pública. GET y POST operan sobre /lacnic/v3/rpki/roas/{organizationId}. PUT utiliza la misma ruta y su descripción señala que reemplaza la lista existente por una versión actualizada. La revocación aparece como POST de una lista a /lacnic/v3/rpki/roas-delete/{organizationId}.

No es una discusión sobre cuál URL se ve más elegante. En un caso, el objeto de cambio es un ROA. En el otro, el objeto de cambio es el conjunto completo de ROA de una organización.

Por qué una lista declarativa puede ser la mejor interfaz

Conviene defender el segundo modelo antes de examinarlo. Un cliente puede leer el conjunto, construir el estado deseado y enviar una única representación completa. El servidor valida coherencia global y aplica el resultado de manera atómica. No hace falta encadenar altas, cambios y bajas con el riesgo de dejar un estado intermedio si una llamada falla.

El mismo payload puede reenviarse sin inventar una operación nueva. Si el resultado ya coincide con la lista deseada, repetir el PUT puede no cambiar nada. Para plataformas IPAM, scripts de seguridad de rutas o procesos de reconciliación, esa convergencia es más simple que mantener una máquina de estados por cada entrada.

LACNIC también podría tener defensas que no aparecen en los ejemplos abiertos. El servicio puede serializar solicitudes por organización, comparar una revisión interna, rechazar una escritura obsoleta, conservar un historial protegido o entregar más información dentro de una sesión autenticada. Esta investigación no utilizó credenciales ni envió una modificación. La ausencia de un campo público no demuestra la ausencia de un control interno.

La tesis, por tanto, no es que haya ocurrido una sobreescritura. Es que quien implementa la API pública no puede aprender de los ejemplos cuál es la regla de concurrencia del reemplazo completo.

En una lista, la omisión también expresa voluntad

Cambiar un registro por número de serie reduce la intención al objeto señalado. Reemplazar una lista completa amplía esa intención: los elementos presentes deben quedar y los ausentes pueden dejar de existir. Un cliente que desconoce una entrada reciente puede convertir su ignorancia en una baja.

Piénsese en dos automatizaciones autorizadas. La primera lee la lista para añadir un prefijo nuevo. La segunda la había leído antes para corregir maxLength en otro ROA. Cada una produce un conjunto coherente respecto de su lectura. Si el servidor acepta el último conjunto sin verificar su base, la escritura más tardía podría excluir el cambio intermedio. Si el servidor compara revisiones y rechaza el estado obsoleto, el conflicto queda contenido. Los documentos revisados no indican cuál de esas conductas se aplica.

No se encontró en las solicitudes y respuestas públicas un ETag, If-Match, número de revisión, hash de la lista base o precondición equivalente. Tampoco una operación de dry-run, preview o diff. El ejemplo público de actualización no documenta cuerpo ni cabeceras de respuesta. Esa observación está limitada a la superficie abierta revisada; no autoriza a describir el funcionamiento interno.

La unidad importa porque un ROA contiene autoridad operativa, no solo metadatos. RFC 9582 define el perfil actual que vincula recursos IP con un AS de origen y permite expresar una longitud máxima. RFC 9319 muestra por qué maxLength debe usarse con cuidado: cambia el alcance de los anuncios más específicos cubiertos por la autorización.

Una creación, una reducción o una omisión puede alterar la evidencia que aplican los validadores de origen. Eso no significa que LACNIC decida qué ruta acepta cada red. Cada operador conserva esa política. Significa que el acto de registro merece una precondición visible, porque la API transforma intención organizativa en objetos destinados a terceros.

Un contrato ejecutable, no otra capa de comité

El primer cambio debería eliminar la bifurcación documental. La tabla de la web, la ruta /info y la colección Postman deben generarse desde una sola definición versionada. Si la operación actual reemplaza el conjunto de una organización, la tabla breve debe decirlo. Si todavía existe una ruta por serialNumber, su relación con la operación de conjunto debe quedar explícita.

Los metadatos de Postman registran una fecha de publicación en junio de 2023. Esa fecha no demuestra cuándo se actualizó por última vez el contenido. La colección se obtuvo bajo la etiqueta activa latest. Un integrador no debería resolver la autoridad comparando fechas ambiguas; debería poder leer el mismo identificador de contrato en todas las superficies.

El segundo cambio es una identidad de base. Antes de enviar el PUT, el cliente recibe una revisión opaca, un ETag o un hash normalizado de la lista. El reemplazo significa entonces: «aplique este estado solo si la lista vigente todavía es la que inspeccioné». Si cambió, el servidor responde con un conflicto y no muta nada.

El tercero es una diferencia explícita. Un preflight debe enumerar altas, cambios y bajas, con prefijo, AS de origen y maxLength. La desaparición de una entrada se vuelve una decisión visible. También permite detectar que una biblioteca local omitió un campo o que un proceso está a punto de restaurar una versión antigua.

El cuarto es el resultado. La aceptación o el rechazo devuelve un identificador de operación, versión de contrato, base examinada y estado resultante. Si se corrige más tarde, la nueva operación apunta a la anterior. El titular autorizado obtiene una cadena verificable; no hace falta publicar nombres personales, claves, reglas antifraude ni detalles del sistema.

Elemento Pregunta que responde
Versión de ruta y esquema ¿Qué semántica ejecutó el servidor?
Identidad de organización y lista base ¿Sobre qué estado se preparó el reemplazo?
Diferencia de alta, cambio y baja ¿Qué quiso alterar el cliente?
Preflight ¿Se detectaron validación u obsolescencia antes de escribir?
Operación y resultado atómicos ¿Se aceptó, rechazó o reintentó la transición completa?
Referencia de corrección ¿Qué decisión posterior sustituyó a cuál?

Es una solución deliberadamente delgada. No añade un órgano de aprobación ni convierte cada ROA en un expediente público. Hace que la API sea comprobable en su propia escala: un estado observado, una intención, una transición y un resultado.

LACNIC ya ofrece información para crear y corregir ROA y facilita la automatización mediante su API. Precisamente por eso conviene cerrar la diferencia. Si Postman es la puerta actual, la tabla que lleva hasta ella no debería enseñar una unidad de escritura distinta. Y si la unidad real es la lista, el contrato público debe decir qué lista se reemplaza antes de aceptar otra.

Fuentes