Résumé

  • La documentation publique de l’API NIR d’APNIC montre une requête asynchrone vers /nir-delegations/asn, mais la présente comme une délégation issue du pool du NIR, pas comme la preuve de la réforme ultérieure de délégation directe.
  • Les documents du Conseil exécutif ont fait passer le projet des mises à jour du registre et de l’API, en septembre 2024, aux tests finaux en décembre ; la fiche actuelle, classée en 2025, conserve pourtant un objectif et un journal de modifications vides.
  • Un reçu de mise en service pourrait relier la version du schéma, la date de bascule, les NIR participants, la migration des anciens enregistrements et les contrôles Whois/RDAP, sans publier les dossiers des membres.

Dans un registre, le verbe « réussir » est moins précis qu’il n’en a l’air. Une tâche peut être marquée SUCCESSFUL parce qu’un traitement asynchrone s’est achevé. Ce statut ne répond pas automatiquement aux questions qui intéressent l’opérateur ou l’auditeur : quelle réserve a fourni l’ASN, quelle version des règles a été appliquée, quelle organisation a approuvé l’éligibilité, et quels objets ont finalement été projetés dans Whois et RDAP ?

La documentation de l’API NIR d’APNIC donne une bonne réponse à la question pratique. Elle explique que les NIR peuvent gérer les informations d’enregistrement de leurs sous-comptes. Son tutoriel demande des coordonnées destinées à nourrir l’enregistrement dans Whois et RDAP, puis montre un appel à /nir-delegations/asn. La réponse n’est pas l’objet final, mais un lien vers une tâche. Un second appel permet d’en constater l’état. La documentation commune prévoit aussi une Idempotency-Key, afin qu’une requête répétée après une rupture de connexion ne crée pas deux opérations.

Ce sont des choix de conception raisonnables. Ils rendent l’automatisation plus sûre et la reprise plus prévisible. Mais ils décrivent une interface, non la généalogie de la règle exécutée derrière cette interface.

Le mot « direct » change la question

Le tutoriel dit que les ressources sont déléguées depuis les « pool delegations » du NIR. La feuille de route emploie un autre vocabulaire. Le projet « NIR ASN Direct Assignments » doit permettre une délégation directe d’ASN aux titulaires de comptes NIR, la fonction étant développée dans le registre puis exposée dans MyAPNIC et l’API NIR. Son résultat attendu est une meilleure cohérence et une meilleure validité des données.

Il est possible que le même point d’API serve aujourd’hui les deux modèles. Il est possible que son adresse ait été conservée tandis que le choix du pool et la logique du registre changeaient en arrière-plan. Il est également possible que la documentation de test illustre encore l’ancien parcours. Les sources disponibles ne permettent pas de choisir entre ces explications. Elles ne prouvent ni un échec ni une absence de déploiement ; elles montrent seulement qu’une URL ne porte pas à elle seule l’histoire de ses sémantiques.

Cette prudence n’est pas une subtilité terminologique. Dans l’ancien modèle de confédération, certains NIR détenaient de grands blocs avant de les subdiviser. APNIC a expliqué en 2019 que, pour les adresses IPv4, les allocations et affectations réalisées depuis 2004 venaient du pool régional commun et étaient inscrites directement dans le registre APNIC. Les blocs historiques n’ont pas disparu pour autant. Leur réconciliation a ensuite corrigé des dates, des identités de titulaires et des transferts manquants.

Cette histoire concerne l’IPv4, pas le nouveau parcours ASN. Elle indique néanmoins pourquoi « direct » doit être défini pour chaque mécanisme. Le terme peut désigner la provenance de la ressource, l’écriture dans le registre central, la disparition d’une double saisie, ou encore la relation de service avec le demandeur. Confondre ces plans produirait un récit plus simple que le système réel.

La progression existe, la mise en service reste sans ancre

Les documents publics permettent de suivre le chantier jusqu’à un point avancé. En septembre 2024, le Conseil exécutif faisait état de mises à jour du registre central et de l’API NIR en cours. En décembre, « NIR ASN direct assignments » était en phase finale d’assurance qualité. Le dossier diffusé en février 2025 le rangeait encore parmi les travaux en cours.

La fiche actuelle de la feuille de route place l’initiative en 2025. Elle cite ARMS et MyAPNIC, reprend l’objectif de cohérence des données et décrit la future exposition par l’API. Mais son champ de cible est vide et son journal de modifications aussi. Le rapport annuel 2025 indique que les cibles trimestrielles de la feuille de route ont été atteintes. Lorsqu’il illustre les livraisons du registre, il mentionne la nouvelle autorisation Whois, les objets RPKI Signed Checklist et la preuve de concept de la réarchitecture RDAP. Il ne nomme pas ce projet ASN.

L’absence d’une ligne n’est pas une décision. On ne peut pas en déduire une annulation. Un journal vide ne signifie pas que les équipes n’ont conservé aucune trace interne. Et la présence d’une documentation sous un domaine de test ne prouve pas qu’une opération donnée a modifié la production. La conclusion correcte est plus circonscrite : aucun document public capturé ne relie le projet arrivé aux tests finaux à une version de production, à une date de bascule et à un périmètre d’adoption.

Chacune des pièces paraît pourtant concluante lorsqu’on la regarde seule. La fiche décrit ce qu’APNIC voulait construire. Le compte rendu renseigne un état d’avancement. Le tutoriel montre ce qu’un client peut envoyer. C’est le lecteur qui les assemble. Or un ordre chronologique n’est pas une preuve d’identité technique. Un changement de sémantique peut conserver le même endpoint ; une documentation peut précéder ou suivre le code ; un déploiement peut être progressif selon les NIR.

L’autorité se répartit au-delà de la requête

La politique APNIC autorise un demandeur à solliciter un ASN auprès d’APNIC ou de son NIR compétent. Chaque ASN attribué doit être enregistré publiquement dans la base Whois d’APNIC ou du NIR concerné. Lorsqu’un fournisseur demande un ASN pour un client, d’autres obligations apparaissent : le client doit satisfaire aux critères, le demandeur entretient l’enregistrement, et la fin de la connectivité conduit à un retour ou à un transfert selon les règles.

L’ASN relie donc plusieurs faits qui ne vivent pas au même endroit. L’éligibilité est appréciée dans une relation de service. La ressource provient d’un ensemble administré au niveau régional. La mutation est appliquée par un système. Des coordonnées alimentent des vues publiques. Le numéro devient enfin un identifiant utilisé dans le routage mondial. Réduire la double saisie entre ces couches est un vrai gain de qualité. Mais une automatisation plus courte accroît l’importance d’une preuve qui explique où la décision a été prise et où elle est devenue autoritative.

Une tâche d’API ne peut raisonnablement contenir toute cette histoire. Son état doit rester simple. SUCCESSFUL peut signifier que le traitement s’est terminé selon les règles du service. Ce qu’il ne faut pas lui demander, c’est de prouver la version réglementaire, la source du pool, la cohérence des projections publiques et le traitement des données héritées. Ces éléments relèvent d’un reçu de mise en service, non d’une réponse transactionnelle.

Une écriture centrale ne supprime pas le NIR

Le cadre APNIC des NIR explique leur fonction : fournir des services adaptés à la langue et au contexte local, tout en appliquant les politiques régionales et mondiales. Les NIR peuvent ajouter des politiques locales compatibles. APNIC doit de son côté rester ouvert à l’adhésion directe. Même lorsqu’une organisation appartient aux deux structures, elle ne peut recevoir des services de ressources que d’une seule source à la fois.

La délégation directe dans le registre d’APNIC ne signifie donc pas nécessairement une centralisation de l’évaluation. Un NIR peut continuer à examiner la demande, servir le membre et porter la responsabilité locale, tandis que son approbation devient une écriture directe dans le registre régional. C’est même une architecture séduisante : conserver la proximité et supprimer la dérive entre deux registres.

Mais il faut publier ce que « direct » déplace réellement. L’API transporte-t-elle seulement une décision NIR ? APNIC réévalue-t-il certains champs ? L’ASN vient-il encore d’une réserve associée au NIR ou du pool régional au moment de la requête ? Les anciens ASN ont-ils été migrés vers les mêmes sous-comptes ? Un déploiement par étapes a-t-il laissé plusieurs générations actives ? Il ne s’agit pas d’exiger les réponses dans un tutoriel. Il s’agit d’identifier le document où elles peuvent être vérifiées.

Le programme de revue ne fournit pas ce raccord

APNIC mène par ailleurs un programme de revue des délégations. Le périmètre public comporte l’analyse des données, des contrôles de conformité, l’exactitude des comptes et un futur examen des accords avec les NIR. En juillet 2026, APNIC indiquait que les revues de JPNIC, TWNIC et KRNIC étaient achevées, tandis que d’autres progressaient.

Ce dispositif ne permet toutefois pas de solder le statut de la fonction ASN. Sa mission principale publiée porte explicitement sur dix années de délégations et de transferts IPv4. Rien n’autorise à transformer ces résultats en mesure de la délégation directe d’ASN. L’inverse serait également abusif : ce périmètre public ne démontre pas qu’APNIC ne réalise aucun contrôle interne sur les ASN.

Le défaut est donc un défaut de raccord, pas nécessairement de contrôle. D’un côté, l’API offre un reçu de tâche. De l’autre, la revue examine une population IPv4. Entre les deux, le changement de parcours ASN ne possède pas de reçu public qui en fixe la version et le champ.

Le reçu minimal

Une réponse proportionnée tiendrait en peu de pages et ne dévoilerait aucun dossier de membre. APNIC pourrait publier, pour chaque modification importante d’un flux de registre, un identifiant immuable relié à la fiche de feuille de route. Ce reçu indiquerait la date de bascule, la version de l’API et du schéma, le sens précis de « délégation directe », l’état d’un éventuel retour arrière et le caractère global ou progressif du déploiement.

Une deuxième section décrirait la migration : cohortes d’anciens enregistrements, maintien de réserves NIR, données converties, exceptions et opérations laissées hors périmètre. Une troisième section donnerait des contrôles agrégés : requêtes tentées, réussies, rejetées, annulées et réconciliées ; concordance entre registre, Whois et RDAP ; doublons absorbés par l’idempotence ; anomalies encore ouvertes. Les identités et justificatifs resteraient privés.

Ce format préserverait trois catégories de preuve. La preuve de mise en service répond à « quelles règles ont été déployées ? ». La preuve de transaction répond à « qu’a fait cette requête ? ». L’observation du registre répond à « que contient l’état public maintenant ? ». Un système mature sait les relier, sans les confondre.

Sources