Résumé

  • ARIN classe ses objets IRR en deux familles de gestion : les objets simples, créés dans ARIN Online ou en XML, et les objets avancés, créés en RPSL ou migrés depuis IRR-email.
  • Pour un objet migré, l’interface web autorise la consultation et la suppression, pas la modification. Le remède consistant à supprimer puis recréer fait passer l’enregistrement dans une autre classe de canal.
  • La page d’ensemble et les notes de mise en œuvre ne donnent pas la même réponse sur l’accès RPSL REST aux objets créés en ligne. Sans essai authentifié, il faut conserver ce désaccord comme incertitude documentaire.
  • Un reçu minimal reliant empreinte avant action, classe, canal, résultat et empreinte du successeur rendrait la conversion vérifiable sans publier de clé API ni d’identité personnelle inutile.

Une suppression disponible là où la correction ne l’est pas

Le cas le plus instructif de la documentation IRR d’ARIN tient dans trois verbes. Un objet provenant de l’ancien service IRR-email peut être vu dans ARIN Online. Il peut aussi y être supprimé. En revanche, il ne peut pas y être modifié. Le guide renvoie l’édition vers l’API REST, tandis que les notes de mise en œuvre proposent, pour une gestion web, de supprimer l’objet et de le créer de nouveau. Guide utilisateur de l’IRR d’ARIN

Cette séquence n’est pas équivalente à une correction. Avant la suppression, l’objet porte l’histoire d’une migration. Après la recréation, il devient un objet né dans l’interface actuelle. Même si l’opérateur ressaisit le même préfixe, le même ASN d’origine et les mêmes attributs publics, le système ne le range plus sous la même filiation technique.

Il serait facile d’en faire le récit d’une défaillance. Les sources ne le permettent pas. Aucun compte ARIN, aucune clé, aucun objet réel et aucune opération authentifiée n’ont été testés. Aucun trou de publication, filtre erroné ou changement BGP n’est établi. Ce que l’on peut examiner est plus limité : la documentation fait dépendre les droits futurs du canal par lequel l’objet est entré.

Cette dépendance peut être saine. Un formulaire structuré ne sait pas nécessairement restituer toutes les expressions admises dans un objet RPSL. Autoriser une modification partielle pourrait donner l’impression d’une conservation fidèle alors que certains attributs seraient normalisés ou perdus. Refuser l’édition est alors plus prudent que produire silencieusement un objet différent.

La question n’est donc pas de réclamer un bouton supplémentaire. Elle est de savoir si la transition destructive laisse une preuve suffisante entre l’état que l’on retire et celui que l’on remet en circulation.

La classe décrit une voie d’écriture, pas la valeur de la route

La page d’ensemble actuelle d’ARIN distingue les objets « simples » et « avancés ». Les premiers proviennent d’ARIN Online ou de REST avec un document XML. Le tableau leur attribue création, consultation, modification et suppression dans ces deux environnements, mais aucun droit par REST en RPSL. Les seconds proviennent de REST/RPSL ou de la migration d’IRR-email. Ils disposent des quatre opérations en RPSL REST, d’aucune en XML REST, et seulement de la consultation et de la suppression dans l’interface web. Présentation de l’IRR d’ARIN

Les adjectifs ne constituent pas une note de qualité. Un objet « avancé » n’est pas davantage confirmé par le réseau. Un objet « simple » n’exprime pas nécessairement une politique rudimentaire. ARIN décrit des combinaisons de création, de validation et d’administration.

La nuance devient visible lorsque l’on sépare la forme publique de la voie d’écriture. ARIN indique que les résultats de recherche sont rendus en RPSL, quelle que soit la classe. Un lecteur peut donc recevoir deux objets d’apparence comparable sans connaître le formulaire ou l’encodage employés pour les gérer. Ce n’est pas une lacune en soi : l’historique d’une clé d’API n’a pas à être exposé dans une réponse publique. Mais c’est la raison pour laquelle la provenance doit être traitée comme un objet de contrôle distinct.

RFC 2622 définit RPSL comme un langage de spécification des politiques de routage et des objets des IRR. Il permet de publier une assertion structurée, pas de certifier l’état instantané du BGP. La présence d’un objet route ou route6 ne démontre ni que l’annonce est propagée, ni qu’un opérateur l’accepte, ni qu’un filtre a déjà intégré la mise à jour. RFC 2622

La classe d’objet répond donc à « comment cette assertion peut-elle être modifiée ? ». Elle ne répond pas à « que fait le réseau ? ». Maintenir cette frontière évite qu’une critique administrative ne soit transformée en alerte de routage sans preuve.

Le cloisonnement hérité peut protéger une migration

Les notes de mise en œuvre rappellent que la transition n’était pas seulement un changement d’écran. Les objets de l’ancien IRR-email ont été répartis selon leur relation avec les ressources d’ARIN et leur validation. Certains ont rejoint l’environnement faisant autorité ; d’autres se trouvent dans ARIN-NONAUTH. ARIN précise aussi que la première utilisation du web ou de REST par une organisation désactive définitivement la voie de mise à jour par IRR-email. Notes de mise en œuvre d’ARIN Online

Fermer l’ancien écrivain après l’adoption du nouveau réduit un risque évident : deux systèmes pourraient sinon appliquer des validations, des identifiants et des règles de concurrence différents au même ensemble d’objets. Une transition à sens unique clarifie l’autorité active. Marquer les objets migrés évite également de réécrire leur naissance rétrospectivement.

Il faut défendre ce choix avant d’en mesurer le coût. Une migration responsable conserve ce qu’elle sait de l’origine d’un enregistrement. Elle ne transforme pas une ancienne soumission par courriel en création web simplement parce qu’elle l’a importée. Si le RPSL de l’objet ne peut pas effectuer un aller-retour exact dans le formulaire, l’interdiction d’éditer protège la sémantique.

Mais une bonne frontière doit aussi expliquer sa sortie. L’utilisateur devrait pouvoir récupérer une représentation canonique de l’objet, connaître la classe et la règle qui bloquent le canal, vérifier que la recréation passera la validation avant de supprimer, puis relier explicitement le successeur au prédécesseur. Sans cela, la protection de provenance se termine paradoxalement par son effacement.

Deux opérations laissent un intervalle que l’on ne doit pas inventer

Une modification en place peut être enregistrée comme le passage d’une empreinte à une autre sous une identité persistante. Supprimer puis recréer impose deux décisions : retirer l’objet existant, puis faire accepter le nouveau. Entre les deux, la recréation peut échouer, être différée ou devenir visible à des moments différents selon les consommateurs.

Les documents étudiés ne publient aucune mesure de cet intervalle. Ils ne donnent ni nombre d’objets migrés, ni fréquence de conversion, ni distribution de délais, ni série NRTM liée à un exemple. Il serait donc abusif d’affirmer qu’un filtre a vu un objet disparaître. Il reste exact de dire qu’une paire DELETE/POST possède plus d’états intermédiaires qu’un PUT.

Le guide REST d’ARIN documente justement GET, POST, PUT et DELETE pour les objets route, route6, aut-num, as-set et route-set. PUT sert à modifier ; DELETE sert à supprimer. Les charges utiles RPSL et XML sont soumises aux permissions de la classe. Le protocole distingue ce que l’interface peut présenter comme une seule tâche humaine. API REST IRR d’ARIN

Pour l’organisation, la différence touche la maîtrise du changement. Une copie manuelle peut modifier un commentaire, un ordre ou une expression. Un validateur peut imposer une correction avant d’accepter le successeur. Réutiliser la même clé publique peut masquer le changement de classe ; en changer peut casser la lecture de continuité. Dans les deux cas, l’absence d’un lien explicite oblige un futur opérateur à reconstruire l’intention à partir de tickets ou de souvenirs.

Un désaccord documentaire qu’aucun auteur ne doit trancher seul

Le tableau actuel de la page d’ensemble refuse tout droit RPSL REST aux objets simples. Les notes de mise en œuvre, sur une page dont la liste de mises à jour va jusqu’au 17 janvier 2025, indiquent pourtant que les objets créés dans ARIN Online peuvent être consultés, mis à jour et supprimés par REST avec RPSL ou XML.

Ces deux descriptions ne se superposent pas. Il est possible qu’elles parlent de périodes, de types ou de conditions différents sans les expliciter. Il est aussi possible qu’une page ait pris du retard sur le service. Aucune de ces explications n’est démontrée. Un essai sur un seul objet ne suffirait d’ailleurs pas à établir une règle universelle.

Le billet de février 2021 consacré à l’arrivée de l’API donne une chronologie utile des limites prévues et des changements envisagés. ARIN le classe désormais dans son Vault et avertit que ces contenus historiques peuvent être périmés. Il ne faut donc pas l’utiliser comme contrat actuel. Billet historique d’ARIN sur l’API REST

La correction proportionnée est un tableau unique, versionné, qui croise classe, type d’objet, opération, canal et encodage. Le code en fonctionnement resterait la réalité opérationnelle d’un cas donné ; le tableau deviendrait l’engagement documentaire contrôlable. Jusqu’à leur alignement, la contradiction est un résultat, pas une invitation à choisir la phrase la plus commode.

Relier les états sans publier les personnes

Un reçu de conversion peut rester très étroit. Il peut contenir le type et la clé publique de l’objet, sa classe et sa provenance avant action, la version de la matrice de permissions, l’empreinte canonique de l’état retiré, l’action demandée, la catégorie d’acteur autorisé, le canal et l’encodage, le résultat, la classe et l’empreinte finales, ainsi que le lien entre suppression et recréation. Lorsque cela est fiable, une observation de publication ou un numéro de série NRTM complète la chaîne.

Il n’a pas besoin de révéler une clé API, le nom d’un salarié, des relations internes ou une topologie. ARIN peut attester l’opération qu’il contrôle sans étendre son autorité au routage. Le reçu prouve une transition de registre. Il ne prouve pas que tous les miroirs l’ont reçue, qu’un constructeur de filtres l’a consommée, ni que les paquets ont suivi une route particulière.

Le guide attribue la gestion IRR aux POC Admin, Tech et Routing, pas aux Resource POC. Cette règle de rôle s’ajoute à la classe de l’objet : être autorisé pour l’organisation ne rend pas tous les canaux disponibles. La séparation mérite d’être lisible dans l’audit, car « qui peut agir » et « par quelle représentation » ne sont pas la même information.

Les sources ne montrent ni victime ni incident. Elles montrent que, chez ARIN, l’histoire de création peut continuer à gouverner la correction. Conserver cette histoire est une discipline de registre. Demander à l’utilisateur de la supprimer pour changer d’outil, sans fil de remplacement visible, en est la limite évitable.

Sources

  1. ARIN : présentation de l’Internet Routing Registry
  2. ARIN : guide utilisateur de l’IRR
  3. ARIN : notes de mise en œuvre d’IRR Online
  4. ARIN : API REST de l’IRR
  5. ARIN Vault : chronologie de l’arrivée de l’API REST
  6. RFC 2622 : Routing Policy Specification Language