Résumé

  • La page de l’API de registre de LACNIC indique que Postman contient la documentation v3 la plus actuelle, tout en décrivant localement la modification et la suppression d’un ROA à l’adresse /rpki/roas/{serialNumber}.
  • La collection publiée emploie une autre unité : GET, création et PUT portent sur la liste d’une organisation, et le PUT remplace la liste existante. Les exemples publics examinés ne montrent ni version de base, ni précondition, ni différence projetée.
  • Un état désiré complet peut simplifier l’automatisation et permettre une application atomique. Il devient vérifiable lorsqu’il transporte l’identité de l’état lu, un aperçu des ajouts et retraits, puis un résultat unique et une filiation de correction.

Il faut lire une documentation d’API comme un opérateur, pas comme un catalogue. Sur la page de l’API de registre, LACNIC conseille de consulter Postman pour disposer de la documentation la plus actuelle de la version 3. La route de production /lacnic/v3/info conduit elle aussi vers ce document publié. L’ordre de confiance paraît donc établi.

Le tableau de la page décrit pourtant les ROA autrement. La création et la consultation passent par /rpki/roas. Pour modifier ou supprimer, il ajoute /{serialNumber}. La grammaire est celle d’un enregistrement isolé : le client identifie l’objet, agit sur lui et ne formule aucune volonté à propos de ses voisins.

Dans la collection API Registro v3 Prod, la grammaire change. GET et POST utilisent /lacnic/v3/rpki/roas/{organizationId}. Le PUT vise la même adresse et annonce le remplacement de la liste existante par une version mise à jour. Pour révoquer, le client envoie une liste à /lacnic/v3/rpki/roas-delete/{organizationId}.

Le passage du numéro de série à l’organisation transforme le périmètre de l’action. Un élément devient une collection. Cette collection peut être un très bon objet d’automatisation, à condition que la documentation dise comment elle se rattache au présent.

Le mérite d’un état désiré complet

Une interface déclarative réduit le nombre de transitions intermédiaires. Le client lit la liste, calcule l’état voulu et soumet cet état en une fois. Le serveur peut valider l’ensemble, refuser un ensemble incohérent et effectuer une écriture atomique. Une succession de commandes élémentaires, au contraire, peut s’arrêter après deux réussites et un échec, laissant au client le soin de réparer un état partiel.

Le remplacement complet facilite aussi les reprises. Si la première requête a abouti mais que la réponse s’est perdue, renvoyer exactement la même liste peut conduire au même résultat. Cette propriété convient aux systèmes IPAM, aux tâches de réconciliation et aux outils de sécurité du routage qui comparent régulièrement le registre à une source d’intention interne.

Il serait donc trop facile de présenter le PUT collectif comme une faute. LACNIC peut sérialiser les écritures d’une organisation, comparer une révision invisible dans l’exemple, conserver des journaux protégés, calculer une différence ou fournir un contrôle supplémentaire à l’utilisateur authentifié. Aucun compte n’a été utilisé pendant cette enquête. Aucun ROA n’a été créé, modifié ou révoqué. Les documents publics ne permettent pas de conclure que ces protections n’existent pas.

Ils permettent une conclusion plus précise : le lecteur public ne voit pas la précondition du remplacement. Il sait ce qu’il doit envoyer, mais pas comment le service détermine que cette liste repose encore sur l’état courant.

Une absence dans le payload peut devenir une suppression

Dans une opération adressée par numéro de série, l’absence des autres objets n’a pas de signification. Dans un état complet, elle en a une. Si un ROA récent ne figure pas dans la représentation, le serveur doit savoir si le client veut le retirer ou s’il ne l’a jamais vu.

Deux programmes autorisés suffisent pour faire apparaître la question. Le premier lit la liste et prépare l’ajout d’un préfixe. Le second avait lu plus tôt et prépare une correction de maxLength sur un autre ROA. Chacun construit une liste cohérente. Le premier écrit. Lorsque le second soumet ensuite son état plus ancien, le service peut rejeter, fusionner, sérialiser ou remplacer. Chaque politique est possible ; les exemples examinés ne nomment pas celle qui gouverne.

Ce scénario n’est pas un constat de perte de mise à jour chez LACNIC. C’est le test normal d’un contrat de remplacement. Dans les champs publics des requêtes et réponses, aucun ETag, If-Match, jeton de révision, hash de liste de base ou mécanisme équivalent n’a été trouvé. Aucun dry-run, aperçu ou diff n’y apparaît. L’exemple de mise à jour ne publie ni corps ni en-têtes de réponse permettant de raccorder la tentative à un résultat.

La portée est importante parce qu’un ROA est une autorisation, non une simple préférence d’affichage. RFC 9582 définit le profil actuel qui associe des ressources IP à un AS d’origine et peut inclure une longueur maximale. RFC 9319 explique pourquoi maxLength élargit ou restreint la couverture des annonces plus spécifiques.

Ajouter une autorisation, la resserrer ou l’omettre change les éléments que les parties utilisatrices peuvent confronter aux annonces de routes. Cela ne prouve ni la réception du ROA par un validateur ni la décision d’un routeur. LACNIC contrôle l’acte d’enregistrement ; chaque réseau garde sa politique. Le contrat doit être exact à la première frontière sans prétendre maîtriser la seconde.

Faire découler les pages d’une même définition

La correction documentaire est la plus immédiate. Le tableau du site, la destination de /info et la collection devraient être produits à partir d’une définition exécutable et versionnée. Si le PUT remplace aujourd’hui la liste d’une organisation, le résumé doit le dire. Si la route par serialNumber demeure valide, sa fonction et son éventuel statut de compatibilité doivent être nommés.

Les métadonnées Postman donnent une date de publication en juin 2023. Elles ne donnent pas une date de dernière modification vérifiée. La capture a utilisé l’étiquette active latest. Demander au lecteur de déduire l’autorité d’une date ambiguë serait fragile ; un identifiant de contrat identique sur les trois surfaces est plus fiable.

Vient ensuite l’identité de base. GET peut remettre un ETag, une révision opaque ou un hash canonique de la liste. PUT signifie alors : « remplacez seulement si l’état courant est encore celui-ci ». Si quelqu’un a écrit entre-temps, la réponse de conflit garantit qu’aucun changement n’a eu lieu. Le client relit, recompose son intention et décide au lieu d’écraser un état inconnu.

Un preflight doit rendre l’intention lisible. Il énumère les ajouts, modifications et suppressions, avec le préfixe, l’AS d’origine et maxLength. Une entrée absente cesse d’être un détail du sérialiseur ; elle devient une suppression à confirmer. Les erreurs de validation et l’obsolescence de la base apparaissent avant la mutation.

Enfin, l’opération reçoit une identité propre. Le résultat indique la version de contrat, la base acceptée, l’identité du nouvel état et l’issue atomique. Une requête réessayée après un délai d’attente peut interroger ce résultat au lieu de réécrire à l’aveugle. Une correction ultérieure pointe vers l’opération qu’elle remplace, sans effacer son explication.

Champ minimal Fonction
Version du contrat Fixer la sémantique de route et de payload
Organisation et identité de base Relier l’intention à l’état effectivement lu
Différence ajout/modification/suppression Rendre l’absence explicite
Preflight Détecter validation et conflit avant l’écriture
Identité et résultat atomiques Réconcilier succès, rejet et nouvelle tentative
Lien de correction Préserver la filiation au lieu de réécrire l’histoire

Ce dispositif ne réclame pas un journal public des personnes. Les identités de compte, les secrets, les règles antifraude et les détails de sécurité peuvent rester protégés. Le schéma et les garanties doivent être publics ; le reçu détaillé appartient à l’organisation autorisée. C’est une coordination mince : le système décrit son propre acte, puis laisse les titulaires et les réseaux conserver leurs responsabilités.

LACNIC a déjà intérêt à ce que les ROA erronés soient corrigés et à ce que cette maintenance soit automatisable. Une automatisation lisible ne doit cependant pas changer d’objet entre le panneau indicateur et la route qu’il désigne. Si le présent se gère comme une liste, cette liste doit porter la preuve du présent qu’elle entend remplacer.

Sources