Résumé

  • La résolution 200605.27 constitue bien la trace d’une ratification inscrite au registre du conseil d’AFRINIC en mai 2006 et d’une instruction de mise en œuvre. Elle ne clôt pourtant pas le dossier : le compte rendu d’AFRINIC-4 parle encore d’une proposition discutée le 17 mai et d’un consensus pour avancer, les archives situent un dernier appel du 13 au 28 novembre, puis une autre résolution, 200611.34, consigne une ratification distincte. Ces pièces doivent rester côte à côte, sans réconciliation inventée.
  • Le dispositif retenu organisait des choix d’émission, pas une commande adressée aux réseaux : numéro sur quatre octets seulement sur demande à partir du 1er janvier 2007, inversion du choix par défaut le 1er janvier 2009, puis suppression de la distinction d’allocation le 1er janvier 2010. La valeur pratique de cette séquence dépendait de routeurs, logiciels, filtres, bases et pairs effectivement compatibles.
  • La négociation de capacité BGP, le substitut AS_TRANS et des attributs additionnels de chemin permettaient à des locuteurs anciens et nouveaux de coexister progressivement. Cette passerelle limitait le besoin d’une bascule générale, sans supprimer les pertes possibles lors de l’agrégation, les incohérences de chemin, les erreurs de largeur de champ ni la confusion entre les notations asdot et asplain.
  • Les traces postérieures confirment à la fois l’avancement et la friction : bloc amont enregistré par l’IANA en novembre 2006, rappel de la transition en 2008, formulaire simplifié en 2011, annonce de systèmes compatibles en 2012, mais aussi échanges de numéros dus à du matériel incompatible. Une mise en œuvre défendable se prouve donc de bout en bout, de l’inventaire à la route observée et jusqu’aux exceptions.
  • AFRINIC intervenait ici comme teneur privé d’un registre unique et comme coordinateur technique. Elle pouvait modifier ses valeurs par défaut, tenir des écritures cohérentes et publier des preuves ; elle ne devenait ni propriétaire des numéros ou des réseaux, ni législateur, régulateur, police, procureur, juge ou autorité de confiscation. L’adoption réelle appartenait au code compatible et aux opérateurs capables de l’exécuter.

Deux ratifications dans un dossier qui ne se laisse pas réduire à une date

La formule « la résolution 200605.27 a approuvé la transition » est exacte dans une acception documentaire étroite. La page du conseil d’AFRINIC pour 2006 consigne cette résolution comme une ratification de quatre politiques, dont le passage des ASN sur deux octets aux ASN sur quatre octets, et charge le personnel de les mettre en œuvre. L’erreur commencerait au mot « donc » : donc le processus était achevé, donc le système fonctionnait, donc chaque opérateur était prêt, donc l’institution avait acquis une autorité générale. Aucun de ces prolongements n’est établi par l’inscription au registre du conseil.

Le reste des archives empêche précisément cette lecture linéaire. Le compte rendu d’AFRINIC-4, réunion tenue le 17 mai 2006, présente encore la proposition comme un sujet de discussion. Il fait état d’échanges limités mais favorables et note un consensus pour aller de l’avant. L’archive de la politique reprend le consensus du 17 mai, tout en consignant un dernier appel du 13 au 28 novembre. La même page du conseil qui porte la résolution de mai enregistre séparément la résolution 200611.34 comme ratification de la politique relative aux ASN sur quatre octets.

Enfin, le rapport d’AFRINIC-5 indique que le conseil avait approuvé la politique quelques jours avant cette réunion de fin novembre et début décembre, et que les numéros concernés seraient disponibles au 1er janvier 2007.

Il ne s’agit pas de choisir la pièce la plus commode. Le registre de mai prouve un acte enregistré en mai ; le compte rendu de la réunion prouve ce que ses rédacteurs ont consigné sur la discussion et le consensus ; l’historique de la politique prouve les dates qu’il affiche ; la résolution de novembre prouve un second acte portant le mot de ratification ; le rapport d’AFRINIC-5 corrobore une approbation proche de la réunion. Les sources disponibles n’expliquent pas pourquoi deux résolutions emploient un langage de ratification.

Elles n’autorisent ni à transformer celle de mai en simple brouillon, ni à effacer celle de novembre comme doublon, ni à inventer entre les deux un mécanisme juridique ou procédural qui n’est pas documenté.

Cette tension est déjà un résultat d’audit. Elle montre pourquoi une chronologie digne de confiance doit distinguer la présentation d’une proposition, le consensus rapporté en réunion, le dernier appel, la décision du conseil et l’ordre adressé aux équipes. Si un système d’information ne conserve qu’un champ « date d’approbation », la donnée force une réponse unique là où les archives en imposent plusieurs. La perte n’est pas cosmétique : elle empêche ensuite de savoir quelle version du texte guidait une modification de formulaire, une réservation d’inventaire ou une réponse faite à un opérateur.

Une seconde divergence, plus petite mais révélatrice, apparaît dans les métadonnées de l’archive. La page donne le 22 septembre 2005 pour AAFPUB-2005-ASN-001, tandis que son historique dit que la proposition fut publiée pour la première fois sur la liste le 9 décembre 2005. Là encore, il faut garder les deux assertions comme des métadonnées distinctes. Une date en tête de page et une date de première diffusion ne sont pas automatiquement synonymes ; aucune hypothèse ne doit les harmoniser en silence.

La bonne formulation est donc sobre : une ratification et une instruction de mise en œuvre figurent au registre du conseil sous le numéro 200605.27, mais la chaîne procédurale conservée se poursuit jusqu’à un dernier appel de novembre et une ratification distincte, 200611.34. On peut parler d’incohérence documentaire ou d’une piste d’approbation en deux temps. On ne peut pas raconter une clôture nette en mai. Cette réserve ne diminue pas l’importance de la décision ; elle en précise la preuve.

Un calendrier de valeurs par défaut, non un ordre donné aux routeurs

Le cœur opérationnel du choix résidait dans trois étapes. À compter du 1er janvier 2007, un demandeur pouvait obtenir un ASN appartenant à la partie utilisable seulement avec quatre octets s’il le demandait expressément ; la réponse par défaut restait un numéro représentable sur deux octets. Au 1er janvier 2009, la présomption changeait de côté : un ASN sur quatre octets devenait le choix normal, tandis qu’un numéro limité à deux octets exigeait une demande spécifique. À partir du 1er janvier 2010, la distinction d’allocation devait disparaître au profit d’un ensemble indifférencié sur quatre octets.

La première phase ouvrait une voie d’expérimentation sans placer immédiatement tout nouveau demandeur devant un risque de compatibilité. Elle donnait aux opérateurs volontaires la possibilité de vérifier leurs équipements, leurs pairs et leurs processus. La deuxième utilisait l’inversion du défaut comme un signal plus fort : l’espace élargi devenait le chemin ordinaire, mais une exception restait possible pour une contrainte documentée. La troisième cessait de réserver deux catégories d’émission. Le texte précisait que ce calendrier n’entraînait aucun autre changement de la politique d’allocation des ASN.

Il faut prendre cette clause au sérieux et ne pas convertir une réforme de largeur et de valeur par défaut en révision de règles d’admissibilité qui appartiennent à un autre sujet.

Les bornes numériques permettent de mesurer le changement sans mythologie. Deux octets représentent des valeurs de 0 à 65 535. La partie que la politique ne pouvait traiter qu’en quatre octets allait de 65 536 à 4 294 967 295, dans un espace total représentable de 0 à 4 294 967 295. Cela ne signifie pas que chaque entier y était librement attribuable : des réservations de protocole ou de registre subsistaient. Surtout, élargir un champ n’est pas créer un titre de propriété. Un identifiant unique permet la coordination ; il ne confère ni possession de la route, ni juridiction sur l’équipement qui l’annonce.

Ces dates gouvernaient le comportement du registre face à une demande. Elles ne pouvaient pas reprogrammer un routeur, agrandir un champ de base de données, corriger un filtre ou persuader un pair de mettre à jour son logiciel. Le 1er janvier 2010 marque donc la fin planifiée d’une distinction dans l’allocation, non une certification universelle. Assimiler l’échéance à une preuve d’achèvement reviendrait à prendre le calendrier du chantier pour le procès-verbal de réception de chaque composant.

Le meilleur argument en faveur de la séquence vient justement de cette modestie. Une contrainte prévisible menaçait la continuité du stock étroit. Une bascule en un jour aurait concentré le risque. Trois jalons espacés donnaient du temps aux fournisseurs et aux opérateurs, introduisaient les nouvelles valeurs d’abord sur demande, renversaient le défaut deux ans plus tard, puis mettaient fin à la séparation. Ils préservaient le stock étroit pour les incompatibilités réellement constatées et rendaient la direction du changement lisible.

Le meilleur argument contre une confiance excessive est tout aussi solide. À AFRINIC-4, certains participants jugeaient le sujet encore peu pertinent. La chronologie d’approbation s’étend au-delà de mai. Et des documents postérieurs signalent que des équipements ne suivaient toujours pas. Un petit réseau dont le routeur, le système de supervision ou le partenaire de transit ne comprend pas correctement la nouvelle valeur supporte un coût qui n’apparaît pas dans le calendrier : test en laboratoire, mise à niveau, fenêtre de maintenance, modification de filtres, renégociation d’un raccordement ou, au pire, interruption de portée.

Une institution privée ne devrait pas transformer son échéancier interne en contrainte qui impose une mise en service dangereuse.

La résolution entre ces deux positions n’est ni l’abandon du calendrier ni l’obéissance aveugle à celui-ci. C’est une transition par défauts progressifs, accompagnée de preuves de préparation par composant, d’exceptions documentées, de procédures d’échange traçables et d’un retour arrière techniquement testé. Le registre annonce ce qu’il peut émettre et ce que ses propres systèmes savent enregistrer. L’opérateur décide quand son environnement de production, ses pairs et ses outils rendent l’emploi sûr. L’interconnexion impose de vraies contraintes communes, mais elle ne transforme pas une préférence de registre en commandement public.

La passerelle BGP : coexister sans jour de bascule général

Le calendrier n’aurait été qu’une intention administrative sans mécanisme d’interopérabilité. En novembre 2005, le document technique pertinent était encore un Internet-Draft, donc un travail en cours, et non un RFC final. Il décrivait déjà une transition incrémentale : un locuteur BGP capable de traiter des numéros sur quatre octets annonçait cette capacité à son pair. La relation pouvait alors employer l’encodage adapté aux capacités effectivement négociées, au lieu d’exiger que l’ensemble de l’Internet bascule simultanément.

Lorsqu’un locuteur nouveau devait parler à un ancien locuteur limité aux valeurs sur deux octets, un ASN non représentable dans l’ancien champ pouvait apparaître sous le substitut AS_TRANS, de valeur numérique 23456, dans l’AS_PATH hérité. Le chemin plus riche n’était pas simplement jeté : un attribut optionnel transitif transportait des informations supplémentaires afin qu’un locuteur capable rencontré plus loin puisse reconstituer une plus grande partie du chemin original. Cette architecture formait une passerelle entre deux générations de mise en œuvre.

La terminologie compte parce qu’elle date la preuve. Le projet de novembre 2005 appelait ces attributs NEW_AS_PATH et NEW_AGGREGATOR. Le RFC 4893, publié en mai 2007, a ensuite normalisé le mécanisme sous les noms AS4_PATH et AS4_AGGREGATOR, avec la négociation de capacité et AS_TRANS. Employer les noms du RFC pour expliquer le mécanisme stabilisé est utile ; les projeter dans le texte de 2005 ferait toutefois disparaître l’évolution réelle du standard. Une archive honnête conserve le vocabulaire de chaque version et relie les concepts sans prétendre qu’ils avaient déjà leur désignation ultérieure.

La compatibilité était graduelle jusqu’au niveau de la relation entre pairs. Deux locuteurs capables pouvaient échanger les valeurs élargies nativement. Une session mixte passait par la représentation de transition. Deux systèmes anciens continuaient selon leur mode antérieur. Le RFC 4893 reposait aussi sur une hypothèse importante : avant qu’un système autonome n’utilise un ASN sur quatre octets, les locuteurs BGP internes à ce système devaient avoir été mis à niveau. Une attribution par le registre ne réalisait pas cette opération.

Elle ne vérifiait pas davantage tous les systèmes de supervision, scripts de configuration ou équipements à la périphérie.

La passerelle réduisait le risque ; elle ne l’annulait pas. Une agrégation effectuée par un ancien locuteur pouvait éliminer des informations nécessaires à une reconstruction parfaite du chemin. Des données incompatibles entre l’AS_PATH visible dans le monde ancien et l’attribut de chemin sur quatre octets pouvaient brouiller la détection de boucle ou ouvrir un risque de routage et de sécurité. La présence d’AS_TRANS pouvait être normale à une frontière de compatibilité ou devenir un symptôme à examiner si elle persistait là où tous les locuteurs étaient censés être capables.

Les usages périphériques méritaient la même attention. Des filtres pouvaient avoir été écrits avec une hypothèse de seize bits. Des conventions de communautés pouvaient incorporer un ASN étroit dans un champ ou dans une syntaxe. Les outils de collecte, les générateurs de configuration et les tableaux de bord pouvaient valider une longueur plutôt qu’une valeur. Le RFC signalait l’emploi de communautés étendues spécifiques aux ASN sur quatre octets pour des usages comparables. Ce détail illustre une règle plus large : changer le format d’un identifiant traverse une chaîne de dépendances que la seule session BGP ne révèle pas.

La transition devait donc être observée comme une condition d’exploitation continue. Un test réussi dans un laboratoire prouvait une combinaison de versions et de scénarios. Il ne garantissait pas chaque voisinage de production. Une annonce reçue prouvait une certaine portée à un moment donné. Elle ne validait pas tous les chemins de repli. Une reconstitution correcte du chemin dans un cas simple ne réfutait pas le risque d’agrégation.

L’exigence raisonnable était une progression mesurée : négociation de capacité constatée, scénarios mixtes testés, mises à jour brutes conservées, filtres examinés, et solution de repli définie avant l’encastrement de la valeur dans des configurations difficiles à défaire.

Quand un même numéro devient deux identités apparentes

Le protocole n’était qu’une des surfaces de compatibilité. Les écritures pouvaient échouer même quand les paquets circulaient. Le texte initial employait des exemples en notation asdot : la valeur décimale 65 546 pouvait ainsi s’afficher 1.10. Un autre outil pouvait présenter 65546 en asplain. Le RFC 5396 a retenu plus tard la représentation décimale asplain pour tous les ASN, précisément parce que la coexistence de notations nourrissait la confusion opérationnelle.

Ce choix, postérieur à la décision de 2006, fournit une règle de normalisation ultérieure ; il ne doit pas être réécrit dans les archives comme si la politique originale l’avait toujours appliqué.

Le danger est concret. Un moteur de recherche peut ne pas retrouver 1.10 lorsqu’un ticket mentionne 65546. Un système de facturation peut créer deux fiches. Un filtre peut viser la chaîne affichée au lieu de l’entier. Un registre WHOIS et un collecteur de routes peuvent sembler en désaccord alors qu’ils décrivent la même valeur. À l’inverse, une conversion fautive peut faire croire à une identité commune qui n’existe pas. Le contrôle robuste consiste à stocker l’entier canonique sur 32 bits indépendamment de sa présentation, à conserver la notation originale comme pièce historique et à tester l’aller-retour entre chaque forme acceptée.

La largeur du champ crée un deuxième risque. Une base, une API ou un outil de supervision conçu pour seize bits peut rejeter une valeur élevée, la tronquer, la faire déborder ou, plus dangereusement, l’enregistrer silencieusement sous un autre nombre. Un formulaire web qui accepte la saisie ne prouve pas que la base en aval la conserve. Une base qui la conserve ne prouve pas que son export, son moteur de recherche, son API et son client la restituent. Chaque interface doit être inventoriée ; les valeurs aux limites doivent être testées ; toute écriture avec perte doit être refusée et journalisée.

Il faut donc distinguer au moins quatre surfaces de préparation. Premièrement, le registre : inventaire disponible, moteur d’allocation, formulaire, schéma WHOIS, statistiques déléguées, documentation et assistance. Deuxièmement, le protocole : capacités annoncées, comportement avec AS_TRANS, conservation et reconstruction du chemin, agrégation et communautés. Troisièmement, l’environnement de l’opérateur : versions de routeurs et de logiciels, filtres, supervision, approvisionnement, tickets, rapports et procédures de retour.

Quatrièmement, la concordance des preuves : même entier canonique, dates explicables, relation entre demande, décision, publication et route observée.

L’annonce qu’un registre prend en charge toute la plage dans son moteur d’allocation et dans WHOIS est une assertion testable et utile. Elle ne devient pas, par propagation, une attestation des équipements des membres, de leurs systèmes NMS, de leurs formulaires clients ou de bases externes. Cette distinction protège à la fois le registre et l’opérateur : chacun rend compte de la surface qu’il contrôle, et personne ne transforme sa réussite locale en preuve universelle.

De l’inventaire amont aux échanges : les traces d’une mise en œuvre inégale

Le 29 novembre 2006, le registre de l’IANA consigne le bloc 327680–328703 comme attribué à AFRINIC. Cette écriture fournit un point de contrôle amont avant la première phase prévue pour janvier. Elle ne dit pas quand eut lieu la première attribution en aval, quand le premier numéro fut annoncé dans le routage, ni si tous les systèmes africains étaient prêts. Sa fonction probatoire est plus précise : une quantité identifiable a été enregistrée à une date donnée au niveau amont, ce qui permet de rapprocher ensuite l’inventaire local des volumes disponibles, assignés, réservés ou traités en exception.

Le rapport de réunion d’AFRINIC-9, en 2008, montre comment l’organisation présentait alors la transition, la correspondance des ensembles et l’inversion du défaut prévue pour 2009. Ce rappel entre la première et la deuxième étape est une trace d’activité : il indique que le calendrier était encore communiqué et traduit en consignes d’émission. Il ne certifie pas chaque routeur ni chaque base de données. Sa juste place est celle d’un jalon intermédiaire à comparer aux modifications de systèmes et aux demandes réelles.

Le rapport annuel 2012 d’AFRINIC ajoute des faits plus révélateurs encore. Il indique que l’option permettant de choisir entre ASN sur 16 ou 32 bits avait été retirée du formulaire en 2011 et que les allocations provenaient dès lors d’un ensemble commun sur 32 bits. Si la politique visait l’indifférenciation dès 2010, cette modification de formulaire en 2011 rappelle que les différentes couches de mise en œuvre n’avancent pas nécessairement le même jour. Cela ne démontre pas l’échec de la phase 2010 ; cela démontre qu’un audit doit dater séparément la règle d’allocation, le comportement du formulaire et celui du moteur.

Une annonce publique sur la liste RPD, datée du 11 mai 2012, affirmait que les systèmes d’AFRINIC prenaient en charge un ensemble indifférencié ainsi que la représentation asplain définie par le RFC 5396. C’est la preuve d’une affirmation publique à cette date. Ce n’est ni la date certaine du premier fonctionnement de chacun des composants, ni une validation indépendante, ni la preuve de la compatibilité de tous les opérateurs. Un auditeur devrait chercher les ordres de changement, les résultats de test et les écritures avant et après la mise en service pour transformer l’annonce en chaîne démontrable.

Le même rapport annuel recense 145 ASN attribués en 2012, dont six sur 32 bits, et décrit des échanges au cas par cas lorsque certains équipements étaient incompatibles : des ASN 32 bits de valeur élevée étaient remplacés par des ASN 32 bits de valeur plus basse. Cette précision est importante. Elle ne permet pas de dire que tout le calendrier avait échoué ; six attributions montrent au contraire une utilisation réelle. Mais les échanges réfutent l’idée d’une compatibilité acquise partout dès 2010.

Ils montrent aussi qu’une distinction purement administrative — « l’ensemble est désormais commun » — doit cohabiter avec une gestion opérationnelle des exceptions.

En 2014, la NRO rapportait plus largement, à l’échelle de plusieurs registres, que des routeurs incompatibles avaient conduit certains clients à rendre ou échanger des ASN sur quatre octets contre des ASN sur deux octets. Ce témoignage comparatif confirme que la friction ne se limitait pas à une hypothèse de laboratoire. Il ne permet pas d’attribuer chaque échange à AFRINIC, et il ne donne à la NRO aucune autorité publique. Il sert à borner la confiance : une conception interopérable sur le papier et un calendrier de registre peuvent encore rencontrer un parc installé hétérogène.

Ces traces racontent donc un résultat plus riche qu’un verdict binaire. Le stock amont était enregistré avant le lancement. Le calendrier fut rappelé. Des systèmes et des formulaires évoluèrent. Des ASN sur quatre octets furent effectivement attribués. En même temps, la notation dut être unifiée et des incompatibilités imposèrent des échanges. La transition a existé, mais comme processus négocié entre inventaire, code et exploitation, non comme conséquence instantanée d’une résolution.

Ce qu’un dossier d’implémentation doit permettre de refaire

Le test décisif n’est pas de savoir si une institution affirme avoir appliqué sa politique. Il est de demander si un tiers compétent peut reconstruire le parcours complet sans dépendre de cette conclusion. Le dossier commence par le texte exact de la proposition, sa référence, sa version, ses métadonnées de publication et une copie datée ou une empreinte conservée. Il comprend ensuite l’ordre documentaire : agenda et rapport d’AFRINIC-4, résultat de consensus, dates du dernier appel, résolutions 200605.27 et 200611.34, avec une note explicite sur leur discordance.

La couche suivante porte sur le travail interne vérifiable : ordres de modification ou journaux de changement pour le formulaire, le moteur d’allocation, le schéma WHOIS, les statistiques déléguées, la documentation publique et les procédures d’assistance. À cette couche doit se raccorder l’inventaire amont, notamment le bloc 327680–328703 inscrit le 29 novembre 2006, réconcilié avec les quantités locales disponibles, attribuées, réservées et sorties sur exception. L’équation n’a de valeur que si chaque ajustement est daté et expliqué.

Chaque attribution exige ensuite son propre fil : demande initiale, préférence exprimée, valeur par défaut en vigueur à la date, entier décimal attribué, forme d’affichage historique, horodatage du ticket et rôle opérationnel responsable. Le choix d’un numéro étroit en 2009 ne signifie pas la même chose que le même choix en 2007 : après l’inversion du défaut, il devrait être rattaché à une demande particulière. Le dossier doit permettre de répondre à cette question sans reconstruire l’intention à partir du seul numéro final.

La préparation de l’opérateur ne se réduit pas à une case cochée. Il faut les versions de routeur et de logiciel, le résultat des négociations de capacité, des essais en laboratoire ou sur un périmètre limité, l’examen des filtres, communautés et outils, la compatibilité des pairs et un plan de retour. Le dossier public ou partageable relie ensuite le ticket à l’objet WHOIS ou aut-num, à l’entrée de statistiques déléguées et aux observations de routage pertinentes. L’absence d’une route ne prouve pas automatiquement l’invalidité d’une attribution : un identifiant peut être valablement enregistré sans être observé à cet instant.

Toute divergence doit cependant recevoir un statut et une explication.

L’exception est le point où la qualité du registre se voit le mieux. Un retour ou un échange doit relier l’ancien ASN au nouveau, exposer la raison, identifier les systèmes affectés, conserver l’autorisation, dater la modification des écritures publiques, vérifier la migration des routes et fermer le ticket avec des preuves. Effacer l’ancien enregistrement pour donner l’apparence d’une histoire sans accroc détruirait précisément l’information nécessaire à la continuité technique et contractuelle.

La méthode de continuité défendue par NRS apporte ici une discipline utile : vérifier les données de registre disponibles, en conserver des copies datées, comparer l’organisation, les dates et les contacts, et considérer toute conclusion comme valable à un moment donné. Appliquée à cette transition, elle conduit à capturer non seulement l’état courant, mais la succession des états de la politique, de l’inventaire, de l’attribution et de l’échange. NRS fournit une méthode de vigilance et de représentation de membres autorisés ; il ne se substitue ni au registre, ni à WHOIS ou RDAP, ni aux opérations de routage.

La méthode éditoriale des « dossiers d’allocation » de BTW complète cette approche en exigeant une piste de la demande à l’évaluation, de la décision à l’inventaire, puis à l’écriture publique. Elle est pertinente ici sans importer d’autres controverses : le simple rapprochement de ces étapes suffit à repérer les trous de preuve. L’analyse de LARUS, tournée vers l’opérateur, rappelle pourquoi ces trous comptent. Une décision de coordination apparemment administrative peut modifier silencieusement un formulaire, un filtre ou une condition d’interconnexion et produire un coût de continuité bien réel.

Cet effet pratique ne donne pas pour autant un pouvoir réglementaire au coordinateur.

Quelques tests simples rendent le dossier falsifiable. Le test chronologique vérifie que mai et novembre existent tous deux. Le test d’inventaire rapproche l’amont IANA et les sous-comptes locaux. Le test d’identité confirme que 1.10 et 65546 renvoient au même entier et au même objet courant. Le test de phase explique le choix par la date et la préférence. Le test de protocole confronte capacités, apparition d’AS_TRANS et reconstruction du chemin au scénario prévu. Le test de publicité compare ticket, base d’allocation, WHOIS, statistiques déléguées et routage. Le test d’exception interdit qu’un échange efface son prédécesseur.

Enfin, le test d’autorité refuse de transformer un document technique en titre, licence, jugement ou commandement souverain.

Le teneur de registre n’est pas l’auteur du réseau

Une transition réussie exige un registre unique, des sémantiques stables et une résolution prévisible des conflits. AFRINIC pouvait recevoir une portion d’inventaire amont, tenir la comptabilité des affectations, modifier la valeur proposée par défaut, publier des objets cohérents et aider aux essais. Ce rôle est indispensable : sans unicité, deux opérateurs pourraient croire qu’ils emploient le même identifiant ; sans convention de représentation, une seule valeur pourrait se fragmenter en identités apparentes ; sans traces datées, un remplacement ne pourrait être audité.

Mais l’importance du service ne change pas sa nature. Le principe du teneur de carnet privé fixe la limite : inscrire un ASN ne fait pas d’AFRINIC le propriétaire du numéro, du réseau, de la route ou de l’opérateur. Une résolution interne ne légifère pas. Une ligne WHOIS n’est ni un titre ni une licence. La capacité de coordonner n’emporte aucun pouvoir souverain, réglementaire, policier, de poursuite, de jugement, de sanction ou de confiscation. Le mot « consensus » dans un compte rendu prouve qu’un consensus a été rapporté selon cette procédure ; il ne crée pas à lui seul une légitimité de droit public.

Cette limite ne nie pas les effets matériels. Modifier le défaut d’émission peut déplacer des coûts vers les opérateurs, en particulier les plus petits qui conservent du matériel ancien : achat ou mise à niveau, temps d’ingénierie, laboratoire, fenêtre de maintenance, revue des filtres, coordination avec les pairs, retour ou échange. La bonne réponse n’est pas de feindre que le coordinateur est impuissant parce qu’il n’est pas souverain. C’est d’assortir son influence réelle d’une preuve plus exigeante, de voies d’exception et d’un périmètre étroit.

La primauté du code opérationnel résout l’apparente contradiction. La résolution pouvait régler le processus du registre. Elle ne pouvait pas apprendre à un routeur ancien à traiter un ASN sur quatre octets. La transition devenait effective là où des implémentations compatibles, des essais concluants et un déploiement consenti produisaient un routage interopérable. Ce sont les paquets correctement échangés, les chemins fidèlement reconstruits et les écritures réconciliées qui établissent l’adoption, non le seul vocabulaire d’approbation.

Le socle commun légitime demeure mince : signification stable de l’identifiant, unicité, validité déterministe, traitement des conflits, interopérabilité sur le fil, preuve portable et extension versionnée. Les choix futurs restent locaux tant qu’ils ne sont pas strictement nécessaires à l’interconnexion. Cette conception ne promet pas une liberté sans contrainte : un opérateur dépend de ses pairs et d’un espace de numérotation coordonné. Elle exige toutefois que toute contrainte commune soit rattachée à un besoin d’interopérabilité observable, et non à une prétention institutionnelle plus large.

Ainsi se comprend la véritable portée de 200605.27. La résolution est une pièce importante de la transition, mais non son acte créateur unique. Elle consigne une décision et une tâche. Le calendrier organise des valeurs par défaut. La passerelle technique rend possible une coexistence progressive. Les opérateurs réalisent l’adoption par leurs équipements et leurs accords. L’audit relie ces plans sans les confondre. Et le registre reste ce qu’il doit être : un mécanisme de coordination fiable, non un souverain caché derrière une base de données.