Résumé

  • Dans la suggestion 2026.4, Richard Laager décrit une réattribution détaillée depuis son NET vers une autre organisation. Sa clé API côté parent ne pouvait pas lire l’enfant par identifiant, alors qu’elle pouvait le supprimer et le récupérer par sa plage d’adresses; la clé de l’organisation destinataire pouvait faire la lecture par identifiant.
  • Le 30 mars 2026, ARIN a décidé que les autres outils de consultation et ses projets futurs rendaient un changement des permissions API inutile à ce stade. La proposition a été close avec l’accord de son auteur.

La commande de suppression répondait. La commande de lecture, adressée à l’identifiant même de l’objet, se heurtait à une interdiction. Richard Laager a décrit cette séquence dans la suggestion ARIN 2026.4 : créer une réattribution détaillée à partir de son réseau, au profit d’une autre organisation, puis appeler GET sur l’identifiant du NET enfant avec sa clé API de parent. L’API rejetait la requête pour défaut de droit. Il disait pourtant pouvoir supprimer ce NET, le retrouver avec mostSpecificNet en fournissant ses deux bornes d’adresse et lire les mêmes données publiques dans Whois sans s’authentifier.

La réattribution détaillée crée une relation à deux faces. Le guide de gestion d’ARIN explique que l’organisation destinataire possède son propre Org ID et peut gérer les adresses réattribuées. Le titulaire direct conserve la possibilité de reprendre la réattribution. Pour les objets IRR et le DNS inverse, les deux parties partagent des capacités de gestion. Ces droits ne se réduisent pas à un seul propriétaire ni à une autorisation identique sur tous les champs. La question de Laager porte sur un droit plus étroit : récupérer un enregistrement qu’il a créé et qu’il peut encore effacer.

Son relevé d’accès a quatre lignes. La clé de l’organisation destinataire obtient le NET par identifiant. La clé du parent reçoit un refus sur cette même adresse API. La clé du parent obtient l’objet en cherchant la plage exacte par mostSpecificNet. Enfin, une requête Whois anonyme donne l’information par identifiant ou par adresse. Le contenu n’était donc pas gardé comme un secret. C’est la combinaison identité du demandeur–point d’entrée qui décidait si la lecture réussissait.

La documentation Reg-RWS donne à ces opérations des adresses distinctes. GET /rest/net/NETHANDLE renvoie la charge NET. GET /rest/net/mostSpecificNet/STARTIP/ENDIP choisit le NET le plus spécifique sur une plage. DELETE /rest/net/NETHANDLE lance une demande suivie par ticket pour retirer une réattribution ou une réallocation. PUT /rest/net/NETHANDLE modifie l’objet avec une charge fournie. Le fait qu’un appel par plage réussisse ne fait pas réussir automatiquement le GET par identifiant dans un outil de provisionnement. Il faut coder les deux chemins et vérifier que leurs réponses désignent bien le même enfant.

Ce surcroît de travail arrive au mauvais endroit. Un système qui crée des réattributions conserve naturellement l’identifiant NET retourné par ARIN. À la prochaine synchronisation, il veut relire cet identifiant, comparer l’état enregistré à l’état voulu et corriger un écart. Si la lecture échoue, il doit garder aussi les bornes de la plage, lancer un second type de recherche, contrôler l’identifiant, le parent et le destinataire du résultat, puis réconcilier les données. Whois peut aider une personne à enquêter; il n’a pas la même provenance qu’une réponse authentifiée de l’API de provisionnement.

La capacité de suppression rend la tentation du « supprimer puis recréer » particulièrement mauvaise : une opération destructive ne sert pas de commande de lecture.

Laager proposait deux changements. Le premier était d’ouvrir la lecture GET des NET. Le second consistait à permettre au titulaire du parent de modifier par PUT un enfant direct, puisqu’il pouvait selon lui le supprimer et le recréer. ARIN n’a adopté ni l’un ni l’autre. Les deux méritent des analyses distinctes. La consultation d’un enregistrement public et la modification du nom de réseau, des contacts ou des commentaires publics — les champs que décrit le guide des modifications — n’engagent pas le même contrôle.

Le 30 mars, ARIN a répondu qu’après examen des autres outils de récupération et de projets futurs, elle estimait les permissions actuelles suffisantes pour le moment. La demande a été close avec l’accord de Laager. Le texte de réponse annonce une décision de ne pas changer le contrôle, pas une correction du GET par identifiant. ARIN préfère que l’utilisateur passe par les chemins qui fonctionnent déjà.

Ce choix a un prix précis : chaque intégration côté parent doit savoir que le même NET peut être visible par plage et inaccessible par identifiant. Elle doit aussi distinguer un refus de lecture d’une disparition de l’enregistrement. Sans cette distinction, un automatisme risque de traiter un objet existant comme absent. Le paradoxe se résume en une phrase que tout responsable d’exploitation peut comprendre : le parent conservait, dans le cas signalé, le pouvoir d’enlever l’enfant, mais pas celui d’en lire directement la fiche par son numéro.

Une trace de production actuelle utilisant les clés des deux organisations et les appels documentés établirait si ce refus survit à la réponse de mars. Le dossier public établit le scénario rapporté et la décision d’ARIN. Il suffit déjà à montrer où la complexité de la lecture a été déposée : dans le logiciel du client.

Suggestion 2026.4 et réponse d’ARIN · Méthodes Reg-RWS · Gestion des ressources · Modifications NET