Résumé

  • La version 3 d’AFPUB-2019-V4-003-DRAFT03, proposée par Anthony Ikechukwu Ubah et Taiwo Oyewande comme modification de la section 5.7 du CPM, n’a changé que les sections 5.7.3.2 et 5.7.4.3. La page officielle comporte une divergence non résolue d’un jour : l’historique des révisions date la version du 21 septembre 2020, tandis que la rubrique détaillée indique une soumission le 22 septembre.
  • La première modification a remplacé l’éligibilité immédiate prévue par la version 2 par une inéligibilité de douze mois à de nouvelles allocations ou attributions IPv4 d’AFRINIC après un transfert approuvé. Elle peut se comprendre comme un frein au recyclage de ressources issues du stock disponible, mais aucune donnée publiée dans les sources examinées ne mesure son effet dissuasif, son coût ou son bénéfice.
  • La seconde modification a inversé le sort réservé aux ressources legacy : au lieu de perdre ce statut lors du transfert, elles devaient le conserver. Cette correction supprimait une pénalité statutaire immédiate, sans résoudre la question distincte de la procédure par laquelle deux registres reconnaîtraient la transaction.
  • Les exigences visant la conformité de la source aux politiques du RIR destinataire et l’évaluation du besoin du bénéficiaire entrant n’étaient pas des nouveautés de la version 3. Elles provenaient de la version 2. Les présenter comme des corrections de septembre brouillerait précisément le problème : la troisième version a laissé intact le câblage institutionnel qui rendait la réciprocité impraticable.
  • Le constat du 13 octobre était concret. ARIN et APNIC considéraient incompatible l’obligation de conformité imposée à la source ; LACNIC signalait que sa politique n’exigeait pas de la source qu’elle se conforme à l’autre RIR ; RIPE NCC jugeait incompatible et inexécutable la procédure d’engagement auprès du registre destinataire. Le principe opératoire exposé par le personnel était plus simple : chaque RIR traite avec la partie de sa propre région, puis les registres communiquent entre eux.
  • La défense la plus solide de la proposition mérite d’être prise au sérieux : vérifier le détenteur reconnu, repérer les conflits, encadrer le besoin du destinataire, décourager les allers-retours opportunistes et coordonner les systèmes peut protéger la cohérence des enregistrements. Mais ces objectifs relèvent de contrôles différents. Les réunir sous une prétendue autorité régionale transforme une dépendance technique en pouvoir de marché.
  • La solution minimale ne demande aucune juridiction transfrontalière. Le registre source vérifie son propre client et les ressources concernées ; le registre destinataire vérifie son propre bénéficiaire ; tous deux échangent une confirmation authentifiée, fixent un instant d’effet commun et mettent à jour de manière cohérente l’enregistrement, le DNS inverse, les ROA RPKI et l’historique. AFRINIC demeure alors ce qu’il peut légitimement être : un teneur de registre et un coordinateur technique privé, non un souverain, un propriétaire des numéros ou un tribunal de droit public.

Un projet étroit qu’il faut lire avec précision

Les débats sur les transferts IPv4 se prêtent facilement aux récits trop vastes. La rareté, la valeur des adresses, la circulation entre régions et la diversité des règles des cinq RIR incitent à traiter chaque projet comme un référendum sur la propriété d’Internet. Ce n’est pas ce que permet le dossier de la version 3. L’acte étudié est beaucoup plus délimité : la publication, en septembre 2020, de la troisième version d’une proposition identifiée comme AFPUB-2019-V4-003-DRAFT03, dont Anthony Ikechukwu Ubah et Taiwo Oyewande étaient les auteurs, et l’évaluation opérationnelle qui l’a suivie le 13 octobre.

La distinction n’est pas seulement une précaution de méthode. Elle commande le résultat. L’historique officiel dit que la version 3 a mis à jour deux dispositions, et deux seulement. Si l’on attribue à cette version les changements apportés auparavant à la conformité de la source ou au besoin du destinataire, on fabrique une réponse que le texte n’a pas donnée. Si l’on importe dans l’analyse une version ultérieure, on juge la version 3 à la lumière d’un débat qu’elle n’avait pas encore incorporé.

Et si l’on transforme une évaluation de compatibilité en décision d’adoption, on confond une proposition discutée avec une règle effectivement mise en œuvre.

L’identité temporelle du document appelle elle-même une formulation prudente. Dans la rubrique détaillée de l’archive d’AFRINIC, la date de soumission est le 22 septembre 2020. Dans l’historique des révisions de la même page, la version 3 est datée du 21 septembre. Rien dans les éléments publiés ici ne tranche cette différence d’un jour. La bonne manière de l’écrire consiste donc à conserver les deux indications, non à en choisir arbitrairement une.

Cette petite divergence rappelle la nature du travail d’un registre : la précision d’un dossier tient aussi à sa capacité de montrer ce qu’il sait, ce qu’il ne sait pas et où deux champs ne concordent pas.

Le projet visait une modification de la section 5.7 du CPM. Il cherchait une forme de transfert réciproque entre la région desservie par AFRINIC et d’autres régions. Le mot « réciproque » semble, à première lecture, promettre une symétrie simple : si deux registres acceptent les transferts, une ressource pourrait passer de l’un à l’autre, dans les deux sens. Mais la réciprocité d’intention n’est pas l’interopérabilité de procédure.

Pour qu’une transaction soit reconnue des deux côtés, il faut attribuer à chaque institution les vérifications qu’elle peut réellement accomplir, définir le message qu’elle envoie à son homologue et déterminer quand leurs dossiers changent de concert.

La version 3 a corrigé deux conséquences visibles de la version 2. Elle n’a pas redessiné cette architecture. C’est précisément pourquoi son histoire est révélatrice : elle montre qu’une politique peut répondre à deux objections substantielles, tout en laissant intact le défaut qui empêche le pont de porter la circulation qu’elle annonce.

Le précédent immédiat : ce que disait vraiment la version 2

La version 2 avait été soumise le 13 août 2020. Son historique attribuait des modifications aux sections 5.7.3.1, 5.7.4.1 et 5.7.4.3. Les deux premières sont importantes pour comprendre la troisième version, mais elles ne font pas partie de sa révision. Cette chronologie empêche une erreur fréquente : qualifier de nouveautés de septembre des mécanismes qui étaient déjà inscrits dans le texte soumis en août.

La section 5.7.3.1, conservée dans la version 3, demandait que la source soit le détenteur légitime enregistré auprès d’un RIR, qu’elle se conforme aux politiques du RIR destinataire et qu’elle ne soit pas impliquée dans un conflit portant sur les ressources. Trois idées distinctes se trouvaient ainsi rassemblées. Vérifier que la personne qui offre la ressource correspond au détenteur reconnu relève directement de l’exactitude du registre. Repérer un conflit connu évite qu’un traitement routinier donne une apparence de règlement définitif à une prétention contestée.

En revanche, imposer à la source le respect des politiques d’un registre destinataire avec lequel elle peut n’avoir aucune relation revient à déplacer le centre de vérification.

La section 5.7.4.1 maintenait une évaluation fondée sur le besoin pour un transfert entrant dans la région AFRINIC. Pour un transfert sortant, elle renvoyait à la politique du RIR destinataire. Là encore, la question du besoin peut être défendue comme condition du service fourni au bénéficiaire par son propre registre. Mais elle n’est pas identique à la vérification de la source, et elle n’est pas une propriété technique universelle de la ressource. Deux bases de données peuvent devoir s’accorder sur l’identité d’un bloc, l’identité des parties et la date du changement sans pour autant partager la même doctrine d’éligibilité économique.

La version 2 avait également énoncé, dans sa section 5.7.3.2, qu’une source resterait éligible à de nouvelles allocations ou attributions IPv4 d’AFRINIC si elle respectait la politique en vigueur. La conséquence était une rééligibilité sans période d’attente particulière après le transfert. Quant à la section 5.7.4.3, elle prévoyait que les ressources IPv4 legacy transférées cesseraient d’être legacy. Ce sont ces deux choix que la version 3 allait renverser.

Les 16 et 17 septembre, la réunion AFRINIC-32 a examiné la version 2. Les minutes attribuent aux auteurs l’explication selon laquelle la réciprocité était requise. Elles consignent aussi une série de questions et d’objections : conformité aux règles d’un RIR étranger, prise de contact directe avec le RIR destinataire, existence supposée d’un modèle standard, évaluation du besoin, traitement de ressources disputées, place des ASN et statut legacy. Les minutes notent en outre que le texte publié et les descriptions orales ou les diapositives ne coïncidaient pas toujours.

Cette réunion constitue un arrière-plan chronologique, non un débat sur la version 3. La troisième version n’était pas encore le texte examiné. La proximité des dates autorise à dire que la version 3 est apparue après la discussion d’AFRINIC-32 ; elle ne permet pas d’assigner telle correction à l’intervention de telle personne, ni d’affirmer que les auteurs ont adopté une modification en réponse à une cause déterminée. Les matériaux disponibles ne comprennent pas l’ensemble des échanges de la liste de discussion ni une explication exhaustive de chaque redline par les auteurs.

L’analyse doit donc résister à la tentation d’inventer une causalité à partir du calendrier.

Première modification : une attente de douze mois pour la source

Dans la section 5.7.3.2, la version 3 a remplacé le régime de la version 2 par une inéligibilité de douze mois. Après un transfert approuvé, la source ne pourrait pas recevoir de nouvelle allocation ou attribution IPv4 d’AFRINIC pendant cette période. Le changement est substantiel. Il ne corrige toutefois ni la définition de la source, ni le choix de la politique à laquelle elle doit se conformer, ni la route administrative par laquelle le transfert est engagé.

Le meilleur argument en faveur de cette attente est facile à comprendre. Lorsqu’un registre dispose encore d’un stock qu’il distribue selon certaines conditions, il peut vouloir empêcher qu’un acteur obtienne une ressource, la transfère rapidement, puis retourne aussitôt demander une nouvelle allocation. Une période d’inéligibilité rend ce cycle moins immédiat. Elle peut protéger la crédibilité des critères d’attribution et réduire l’avantage d’une stratégie consistant à convertir sans délai un accès au stock en actif transférable.

Cette justification ne prouve pas l’efficacité de la mesure. Aucun élément ici ne quantifie le nombre de cycles redoutés, la fréquence des comportements opportunistes, la quantité de ressources qui aurait été préservée, ni la modification des incitations produite par une durée de douze mois plutôt que six, dix-huit ou vingt-quatre. Il n’est donc pas possible d’affirmer que la disposition aurait effectivement empêché un abus, ralenti une transaction précise ou protégé un volume déterminé. Il est seulement possible d’identifier le mécanisme plausible : retarder le retour de la source au service d’allocation d’AFRINIC.

Cette portée exacte compte sur le plan institutionnel. L’inéligibilité concerne un service futur offert par AFRINIC. Elle peut être formulée comme une condition prospective, transparente et limitée de ce service. Elle ne signifie pas qu’AFRINIC possède les ressources transférées, qu’il peut punir une transaction privée ou qu’il détient un pouvoir général sur l’activité économique de la source. La différence est décisive. Un prestataire privé peut annoncer qu’un usage donné de son mécanisme entraîne une période d’attente avant une nouvelle prestation.

Cette faculté contractuelle ou opérationnelle ne se transforme pas, par changement de vocabulaire, en sanction publique.

Pour rester étroite, une telle règle devrait également distinguer les situations qu’elle prétend viser. Une source qui transfère une ressource et sollicite ensuite une allocation provenant d’un stock disponible n’est pas nécessairement dans la même position qu’une source participant à une autre opération de marché. L’absence de données, de motifs individualisés ou de voie de correction pourrait faire d’une règle anticirculation un frein indifférencié à la planification des réseaux. La version 3 donne une durée ; les éléments disponibles ne donnent pas une mesure de ses résultats.

Seconde modification : conserver le statut legacy

La section 5.7.4.3 a effectué un renversement tout aussi net. Sous la version 2, une ressource IPv4 legacy aurait cessé d’être legacy après son transfert. Sous la version 3, elle devait rester legacy. Ce changement supprimait la perte automatique d’un statut historique attachée au seul fait du transfert.

Là encore, la correction répond à un problème identifiable sans qu’il soit nécessaire de lui attribuer des effets que le dossier ne montre pas. Si une ressource ancienne est reconnue dans une catégorie historique, la faire sortir automatiquement de cette catégorie lors d’un changement de détenteur ajoute une conséquence qui n’est pas requise pour mettre à jour l’identité du bénéficiaire. Préserver le statut évite que la portabilité soit conditionnée à un abandon préalable de cette caractéristique dans le registre d’origine.

Mais le mot « legacy » ne résout pas la transaction. Le maintien du statut ne dit pas comment un autre RIR traiterait la ressource, quels services il fournirait, quelles données il demanderait ou comment deux systèmes représenteraient le changement. Il ne prouve pas davantage qu’une opération a eu lieu, qu’un détenteur a conservé tous ses droits allégués ou qu’un litige de propriété a été tranché. Le registre peut conserver une étiquette et un historique ; il ne crée pas, par cette opération de classement, un titre opposable dans toutes les juridictions.

Les deux modifications de la version 3 avaient donc une cohérence propre. L’une agissait sur l’accès ultérieur de la source au service d’allocation d’AFRINIC ; l’autre agissait sur la continuité d’un statut dans les données. Ni l’une ni l’autre ne redistribuait correctement les rôles entre le registre de départ et le registre d’arrivée. Elles pouvaient rendre le projet moins contestable sur deux points tout en le laissant inexécutable sur le point central.

Le câblage resté en place

Le défaut survivant apparaît lorsque l’on suit une transaction imaginaire pas à pas. Supposons qu’une source soit enregistrée auprès d’un RIR et qu’un bénéficiaire se trouve dans la région d’un autre. Le registre source connaît la relation de service de la source, l’historique de la ressource, les signaux de conflit présents dans ses dossiers et les personnes autorisées à agir sur le compte. Le registre destinataire connaît, ou peut établir, la relation avec le bénéficiaire et appliquer les conditions de son propre service entrant.

La version 3 maintenait pourtant l’exigence selon laquelle la source devait se conformer aux politiques du RIR destinataire. Elle maintenait aussi une procédure demandant à la partie transférante d’envoyer sa demande au RIR destinataire. Après approbation, ce dernier devait avertir le RIR transférant et les parties. Le texte orientait donc la source vers l’institution la moins bien placée pour vérifier sa situation primaire.

Ce déplacement n’est pas un détail de formulaire. Un RIR destinataire peut ne disposer d’aucun contrat, aucun compte, aucun historique de support et aucune méthode normale d’authentification pour une source externe. S’il tente de la contrôler directement, il doit soit reconstruire la relation détenue par son homologue, soit accepter des preuves qu’il n’administre pas habituellement. Dans les deux cas, le risque de délai, de divergence ou de responsabilité augmente. Si, au contraire, il refuse de le faire, le processus s’arrête malgré l’intention réciproque des politiques.

Une autre tension apparaissait entre le besoin et la formule permettant au bénéficiaire d’être toute partie ayant un accord avec l’expéditeur. Le personnel a lu ces dispositions comme susceptibles de se contredire en pratique dans certains cas. Un accord privé entre les parties ne suffit pas nécessairement à satisfaire un critère de besoin ; inversement, une vérification de besoin ne définit pas à elle seule qui est partie au transfert. La rédaction rapprochait deux tests sans expliquer clairement leur ordre ni leur fonction.

Le projet évoquait en outre un modèle standard dans le contexte procédural discuté autour de la version 2. Or la compatibilité ne naît pas de l’existence supposée d’un formulaire identique. Elle dépend d’un protocole partagé : quelles affirmations chaque registre est habilité à faire, comment elles sont authentifiées, quels états intermédiaires sont possibles, comment une erreur est corrigée, et à quel instant les deux livres considèrent l’opération comme effective. Un document commun peut transporter ces éléments ; il ne remplace pas leur définition.

Le 13 octobre : quatre réponses, un même problème d’allocation des rôles

L’évaluation du personnel d’AFRINIC datée du 13 octobre 2020 a rendu visible le défaut de compatibilité. Elle ne constitue pas une décision juridique universelle ; elle consigne les réponses que le personnel a attribuées aux quatre registres homologues interrogés et les difficultés d’exécution qu’il identifiait. Sa force vient de son caractère opérationnel : les institutions qui auraient dû faire fonctionner le pont n’interprétaient pas leurs procédures comme le texte l’exigeait.

ARIN et APNIC ont, selon cette évaluation, considéré incompatible la clause de conformité de la source. L’objection visait le fait qu’une source devrait répondre aux règles du registre destinataire plutôt qu’à celles du registre avec lequel elle entretenait sa relation. LACNIC a indiqué que sa propre politique n’exigeait pas que la source se conforme à l’autre RIR. La différence peut sembler subtile, mais elle est structurelle : le projet supposait une obligation croisée que le système homologue ne reconnaissait pas.

RIPE NCC a identifié l’incompatibilité de la section 5.7.5 relative à l’engagement de la procédure et l’a jugée non exécutable. Ce constat frappait le chemin même de la demande. Si la partie transférante devait s’adresser au registre destinataire, alors que le modèle de l’autre côté faisait traiter chaque partie par son propre registre, aucune reformulation périphérique sur l’attente de douze mois ou le statut legacy ne pouvait suffire.

Le personnel d’AFRINIC a exposé la pratique normale en termes simples : chaque RIR traite avec la partie transférante située dans sa propre région, et les RIR communiquent entre eux. AFRINIC ne contrôlerait pas directement une source externe avec laquelle il n’avait pas de relation. Cette observation contient le schéma d’un pont viable. Elle ne demande pas que les deux politiques soient identiques en tout point. Elle demande que leurs interfaces soient compatibles et que chaque registre porte les affirmations qu’il est en mesure d’établir.

Les quatre réponses n’équivalent pas à un jugement sur la validité privée de toute transaction possible. Elles ne prouvent pas non plus que chaque désaccord entre RIR est insoluble. Elles montrent plus modestement, mais de manière suffisante, que la version 3 n’offrait pas un chemin accepté et exécutable avec chacune des quatre procédures recensées. La réciprocité annoncée restait ainsi plus large que l’interopérabilité obtenue.

Une mise en œuvre bien plus vaste qu’une entrée de base de données

L’évaluation du personnel recensait des effets possibles sur MyAFRINIC, le DNS inverse, les ROA RPKI, les journaux de transfert et les outils de gestion des demandes. Elle évoquait aussi la révision des processus, la coordination entre RIR, les contrats, les effectifs et les ressources d’ingénierie logicielle. Cette liste explique pourquoi l’emplacement d’une vérification ou l’ordre d’une notification n’est jamais purement rédactionnel.

L’enregistrement principal doit refléter le nouveau contrôle reconnu sans créer deux titulaires simultanés ni laisser l’ancien comme s’il n’avait rien cédé. Les délégations de DNS inverse doivent suivre selon une séquence qui évite une rupture inutile. Les ROA RPKI peuvent nécessiter une révocation et une création coordonnées pour que les autorisations de routage publiées ne restent pas attachées au mauvais état. Le journal du transfert doit conserver une trace intelligible. Les systèmes de tickets doivent permettre aux deux institutions de rattacher leurs actions au même dossier sans exposer indûment les parties.

Ces opérations forment la réalité technique du règlement. Le transfert commercial et le changement de contrôle opérationnel peuvent être convenus en dehors du registre. Mais si les livres, le DNS inverse, les attestations de routage et l’historique ne convergent pas, les acteurs du réseau rencontrent une réalité fragmentée. La ressource peut être routée alors que le dossier public est ancien ; un contrôle reconnu peut changer d’un côté sans changer de l’autre ; les vérifications diligentes d’un opérateur, d’un courtier ou d’un partenaire peuvent produire des réponses contradictoires.

Le registre a donc une fonction indispensable sans détenir un pouvoir souverain. Il tient un système de reconnaissance technique dont de nombreux acteurs dépendent pour réduire l’incertitude. Cette dépendance explique l’importance d’un bon protocole. Elle ne transforme pas la reconnaissance en création de propriété. Le livre doit décrire le changement de manière fiable ; il ne devient pas l’auteur du droit privé qu’il décrit.

Ce que l’évaluation financière permet — et ne permet pas — de dire

Le personnel a indiqué que les transferts entrants de ressources legacy n’augmenteraient pas le nombre de membres, tandis que les transferts sortants effectués par des membres détenteurs de ressources AFRINIC pourraient réduire ce nombre. C’était une appréciation institutionnelle des effets possibles, non la mesure d’un résultat réalisé.

La nuance est essentielle. Aucune donnée disponible ici ne montre une baisse effective des adhésions, une perte de revenu, une transaction réalisée, un prix modifié ou un coût logiciel engagé à cause de la version 3. Le projet n’est pas montré comme adopté ou mis en œuvre. On ne peut donc pas convertir une anticipation du personnel en statistique historique.

Cette anticipation révèle néanmoins un conflit d’incitations digne d’attention. Un registre financé par ses relations de service peut avoir intérêt à la continuité de sa base de membres. Une politique de sortie peut diminuer cette base, tandis qu’une ressource entrante de statut particulier peut ne pas produire l’adhésion attendue. Cela ne prouve aucune intention abusive. Cela montre pourquoi les règles de portabilité doivent être évaluées selon des critères transparents d’exactitude et de continuité, et non selon le seul avantage financier de l’intermédiaire chargé d’enregistrer le mouvement.

Le risque institutionnel est classique : celui qui tient le passage peut être tenté de définir le droit de passer en fonction de ses propres pertes. Une gouvernance saine ne suppose pas que cette tentation ait déjà produit une faute. Elle dessine une interface étroite, publie les motifs de refus et rend les délais observables afin qu’une dépendance technique ne puisse devenir un veto opaque.