Un nom qui prouve qui peut le créer, rien de plus

Résumé

AFPUB-2026-ASN-001-DRAFT02 exigerait que tout nouvel AS-SET créé chez AFRINIC porte un nom hiérarchique enraciné dans un ASN et que son créateur satisfasse l’authentification associée à cet ASN. Cette règle peut protéger une propriété étroite du registre : qui a démontré le contrôle nécessaire pour créer un nom sous cette racine. Elle ne certifie ni les membres du set, ni le filtre qui les consomme, ni l’identité juridique ou économique d’un réseau, et elle ne donne à AFRINIC aucun pouvoir souverain sur le routage.
Le texte préserverait les noms plats existants : aucun renommage obligatoire, maintien de leur usage et possibilité de les modifier. Mais il obligerait aussi AFRINIC à traiter des exceptions au cas par cas, notamment la restauration d’un objet plat supprimé par erreur. Le personnel a averti que cette voie pourrait devenir une faille opérationnelle. Au 9 août 2026, deux pages officielles donnaient en outre des statuts différents et aucune adoption ni mise en production n’était établie. Un projet, un consensus, une décision du Board, une analyse du personnel ou un RSA ne crée pas la réalité opérationnelle et ne fabrique aucune souveraineté.

Analyse

La fonction étroite se trouve au seuil de création

La question posée par AFPUB-2026-ASN-001-DRAFT02 intervient avant le filtrage des routes. Elle ne commence ni lorsqu’un routeur charge une politique, ni lorsqu’un outil développe les membres d’un AS-SET, mais lorsqu’une personne demande à la base AFRINIC de créer l’objet. C’est à cet instant que le teneur du registre peut encore appliquer un test objectif : le nom demandé est-il enraciné dans un ASN, et le demandeur détient-il les éléments d’authentification associés à cette racine ?

Cette vérification appartient au registre parce qu’elle porte sur l’exactitude du registre lui-même. Elle ne porte pas sur la conduite générale du réseau. Elle n’autorise pas AFRINIC à juger un modèle commercial, un choix de peering, une clientèle, une implantation géographique ou une politique de filtrage. Elle ne transforme pas une inscription en propriété créée par l’institution. Elle maintient seulement une relation vérifiable entre un nom nouvellement admis et la preuve de contrôle fournie au point d’admission.

Le fonctionnement décrit par AFRINIC permet d’associer un objet à des éléments d’authentification de mainteneur. Un mot de passe ou un mécanisme PGP peut démontrer que le demandeur est autorisé à agir sous ce mainteneur. Il ne démontre pas, à lui seul, qu’un libellé plat commençant par AS- appartient à un réseau déterminé. Un demandeur peut donc être correctement authentifié pour effectuer une opération sans que le nom choisi établisse une relation avec un ASN précis. L’autorisation d’écrire un objet et la preuve que sa racine correspond au contrôle d’un ASN sont deux propriétés distinctes.

Pour une équipe réseau, la différence se matérialiserait dans un geste ordinaire. Lorsqu’elle ouvre un nouvel ensemble destiné à ses clients, elle ne pourrait plus choisir un nom plat disponible et présenter seulement les références de son mainteneur. Elle devrait former un nom tel que AS64500:AS-CLIENTS, puis satisfaire l’authentification liée à AS64500. La personne qui prépare le set et celle qui détient ces droits peuvent être différentes. Avant même d’examiner les membres, l’organisation devrait donc résoudre une question interne et vérifiable : qui contrôle la possibilité de créer sous cette racine ?

Cette question étroite répond à une faiblesse précise des bases IRR autonomes. Plusieurs d’entre elles peuvent accepter le même nom plat, avec des mainteneurs et des membres différents. Si un consommateur interroge plusieurs sources ou perd le contexte de la source voulue, un homonyme peut produire une expansion inattendue, voire vide selon le comportement de l’outil. Le promoteur de la proposition décrit ce mécanisme.

Les éléments disponibles le rendent plausible et documentent l’existence de collisions, mais ils ne fournissent ni inventaire daté propre à AFRINIC, ni dénominateur, ni série d’incidents permettant de mesurer la fréquence du dommage opérationnel.

Cette incertitude quantitative ne réduit pas la validité du principe. L’absence d’un taux d’incident n’efface pas le besoin de savoir qui peut créer un nom sous une racine ASN. Elle interdit simplement de transformer un mécanisme démontré en promesse chiffrée ou universelle. Le contrôle proposé résout une classe de défauts à l’entrée du registre ; il ne permet pas d’affirmer combien d’incidents il évitera.

La solution ne rend pas un libellé humain mondialement unique par décret. Elle construit un nom dont la première composante renvoie à une ressource attribuée et dont le contrôle peut être testé par le teneur du registre. Toute nouvelle création d’AS-SET devrait être hiérarchique. Le premier composant serait AS suivi d’un numéro de système autonome contrôlé par le créateur authentifié ; le deuxième serait un nom d’AS-SET commençant par AS-. Des composants ultérieurs pourraient être des ASN ou d’autres noms d’AS-SET.

Le RFC 2622 fournit la grammaire et la logique des descendants. Le mainteneur du parent immédiat autorise la création d’un enfant. Une fois le premier set créé sous la racine ASN, son propre mainteneur peut donc contrôler l’ouverture d’un niveau plus profond. La hiérarchie n’est pas seulement graphique : elle forme une chaîne de délégation technique. Chaque étape rattache la création du nom à un parent identifiable plutôt qu’à la seule disponibilité d’un libellé plat.

Le prédicat appliqué au premier niveau est alors simple : le demandeur satisfait-il l’authentification enregistrée pour l’ASN qui ouvre le nom ? Si la réponse est non, la création doit échouer. Si elle est oui, le registre peut inscrire l’objet sous cette racine. La garantie s’arrête exactement là où s’arrête le test. Elle établit une preuve de contrôle nominal à la création dans une base donnée ; elle ne valide ni chaque membre du set, ni la source choisie par un consommateur, ni le filtre finalement installé, ni la réalité juridique ou opérationnelle au-delà de ce que le test observe.

Cette limite n’est pas une réserve rhétorique. Elle est constitutive de la fonction du registre. AFRINIC peut tenir un enregistrement plus exact parce qu’elle exige une preuve étroite. Elle ne devient pas propriétaire de l’ASN, auteur du réseau, juge de sa légitimité ou souverain du routage. Une adresse ou un ASN n’existe pas opérationnellement parce qu’une base l’a béni ; la base reste utile lorsqu’elle reflète fidèlement un contrôle et une réalité que les réseaux font vivre.

Une spécification n’est pas une souveraineté

Trois couches doivent être distinguées sans attribuer à aucune une souveraineté qu’elle ne possède. La première est la spécification. Depuis 1999, le RFC 2622 définit la grammaire RPSL des noms de sets hiérarchiques, les deux-points qui séparent leurs composants et l’autorisation transmise par le mainteneur du parent. Il explique comment un espace de noms peut être partitionné. Il ne décide pas qu’un registre particulier doit refuser les noms plats : les procédures d’enregistrement sont explicitement hors de son champ.

La deuxième couche est la procédure interne d’AFRINIC. La proposition de James Bensley cherche à ajouter une section 7.8 aux règles d’AFRINIC. L’auteur peut soumettre et réviser le texte ; il ne peut pas l’adopter seul. Le groupe de travail, les étapes de consensus, le Board et les autres organes produisent les actes internes que prévoit le dispositif d’AFRINIC. Mais aucune de ces opérations ne crée une législature, un peuple ou une souveraineté. Une réunion peut coordonner. Un consensus peut exprimer l’accord de ceux qui participent. Un Board peut administrer une société.

Aucun ne transforme une règle interne en autorité politique sur des réseaux qui existent, routent et contractent dans le monde réel.

Le personnel se situe dans la même limite. Il peut interpréter les effets techniques annoncés, estimer la faisabilité, identifier les systèmes à modifier et préparer une mise en œuvre. Son analyse constitue une preuve attribuée de ce qu’AFRINIC prévoit ou estime. Elle ne fabrique ni adoption, ni vérité opérationnelle, ni compétence souveraine. Le fait qu’une équipe possède l’accès nécessaire pour modifier un serveur ne lui donne pas un droit de gouvernement sur les réseaux desservis par ce serveur.

La troisième couche est le code qui accepte ou refuse effectivement la création. Pour l’équipe qui soumet AS64500:AS-CLIENTS, la règle ne devient observable que lorsque chaque chemin donne la même réponse. Le serveur WHOIS, l’interface IRR de MyAFRINIC, les formulaires et les interfaces de programmation devraient vérifier la syntaxe, la racine ASN et l’authentification correspondante de façon identique. La casse, les niveaux imbriqués, les suppressions et les restaurations devraient recevoir des décisions cohérentes quel que soit le canal.

Un formulaire qui refuse un nom plat alors qu’une autre entrée l’accepte ne ferait qu’afficher une protection incomplète.

La primauté du code en fonctionnement ne signifie pas qu’un logiciel devient souverain à la place d’une institution. Elle signifie que la réalité opérationnelle ne naît pas d’une déclaration. Un texte peut annoncer une validation ; seul le comportement reproductible des chemins de création permet de constater que cette validation existe. Et même alors, le code n’acquiert pas un mandat général : il exécute un prédicat étroit sur un objet précis.

L’évaluation du personnel identifie six systèmes. WHOIS et l’interface IRR de MyAFRINIC nécessiteraient des changements directs. RDAP refléterait les données WHOIS. NetSuite, NMRP et RPKI ne demanderaient pas de changement selon cette analyse. Cette répartition — deux systèmes modifiés directement, un reflet et trois annoncés sans modification — confirme la mesure exacte du projet. Il vise l’admission et la représentation d’un type d’objet ; il n’est pas présenté comme une refonte de toutes les infrastructures liées aux ressources Internet.

Le calendrier annoncé souligne la distance entre une estimation et un fait. Le personnel a jugé la mise en œuvre réalisable, mais l’a placée après MyAFRINIC v2, dont la date alors attendue était le 15 novembre 2026. Au 9 août, cette échéance se trouvait encore 98 jours plus tard, et le travail relatif à la politique devait seulement être priorisé ensuite. Il s’agit d’une prévision attribuée au personnel, non d’une livraison. Sans règle consolidée, note de version et résultats d’essais couvrant chaque chemin de création, la chaîne de contrôle demeure décrite sur le papier plutôt que démontrée dans le service.

Un RSA ne comble pas cet écart et ne change pas la nature de l’institution. Un contrat de service peut définir des obligations entre ses parties. Il ne transforme pas AFRINIC en État, ne lui donne aucune juridiction universelle et ne fait pas de son registre l’auteur de la réalité opérationnelle. Ni la signature d’un contrat, ni la répétition d’une procédure, ni l’ancienneté d’une pratique ne convertissent une coopération utile en souveraineté.

Les pages officielles prouvent leur propre contradiction, pas davantage

À la date d’observation, l’index officiel des propositions courantes classait DRAFT02 « Under Discussion ». La page de la proposition affichait séparément « Last Call » et signalait une présentation à AF37 le 24 juin 2026. Les pages examinées n’expliquaient pas cet écart. Ces documents sont des preuves attribuées de ce qu’affichent deux surfaces d’AFRINIC. Ils ne donnent pas le droit de choisir l’étiquette la plus avancée, d’effacer la contradiction ou d’en déduire une adoption.

La chronologie documente des étapes, pas une souveraineté croissante. DRAFT01 a été soumise le 15 mai 2026. DRAFT02 a suivi le 8 juin, soit 24 jours plus tard, après des retours de la liste de discussion ; cette version a notamment ajouté l’exception explicite de restauration. Le personnel a daté son évaluation du 15 juin, sept jours après DRAFT02. La présentation à AF37 est intervenue neuf jours plus tard. Cette cadence montre un projet révisé, évalué et présenté. Elle ne prouve ni ratification, ni incorporation définitive aux règles, ni activation dans les systèmes.

Au 9 août, aucune annonce officielle d’adoption, aucun texte final intégré, aucune note de livraison ni aucun test de production examiné n’établissait l’entrée en vigueur. L’équipe réseau ne pouvait donc pas déduire d’une étiquette de page que sa prochaine demande de nom plat serait rejetée. Il faut écrire que le texte « exigerait » les nouveaux noms hiérarchiques, qu’il « donnerait » au mainteneur authentifié le contrôle du premier enfant et qu’AFRINIC « devrait » modifier ses validations s’il était adopté.

Ces distinctions préservent à la fois les faits et la doctrine. Une proposition n’est pas une exécution. Une ratification interne, si elle intervient, n’est pas une souveraineté. Une exécution uniforme, si elle intervient, prouve seulement que le teneur du registre applique une règle de création dans ses propres systèmes. Elle ne donne pas à AFRINIC le pouvoir de déclarer irréels des réseaux, des routes, des contrats ou des contrôles qui existent en dehors de cette vérification.

L’héritage appartient à la réalité qu’il faut décrire

DRAFT02 tracerait une frontière temporelle. Les créations futures seraient soumises à la hiérarchie. Les objets déjà présents ne seraient pas forcés de changer de nom. Le texte apporte trois protections distinctes : aucun renommage obligatoire, poursuite de l’usage des noms plats existants et maintien de leur modification sans que l’édition déclenche un renommage.

Cette non-rétroactivité ne doit pas être présentée comme une faveur accordée par un souverain. Elle reconnaît une réalité opérationnelle installée. Le registre ne voit qu’une partie des références, des générateurs, des caches, des accords de peering et des procédures qui dépendent d’un nom. Parce que l’enregistrement doit décrire cette réalité plutôt que prétendre la recréer, un changement d’exigence pour les entrées futures ne justifie pas de casser ce qui fonctionne déjà.

Reprenons l’équipe qui prépare un nouveau nom hiérarchique. Elle peut aussi maintenir depuis longtemps un AS-SET plat cité dans des générateurs de politique, des configurations, des fiches de peering, des procédures internes ou des échanges bilatéraux. DRAFT02 ne lui demanderait pas de le renommer. Elle pourrait encore modifier cet objet, tandis que ses consommateurs continueraient de le rechercher sous le même libellé. Dans son travail quotidien, deux régimes cohabiteraient donc : une preuve plus forte exigée pour le prochain nom et la continuité du précédent.

Les consommateurs ne régénèrent pas tous leurs filtres au même moment ; certains gardent des caches et d’autres recopient un nom dans des systèmes qui n’ont aucune relation directe avec AFRINIC. Imposer une migration générale pourrait casser des dépendances invisibles au détenteur comme au registre. La couche commune doit rester minimale : améliorer le prédicat de création futur sans s’arroger le pouvoir de réécrire rétroactivement chaque usage local.

Le prix technique est connu dans sa nature, mais non dans son ampleur. Les noms plats homonymes resteraient consultables et utilisables. L’ambiguïté que la nouvelle règle cherche à réduire ne serait pas nettoyée ; elle cesserait seulement de croître par la voie ordinaire des nouvelles créations AFRINIC. Aucun inventaire arrêté à une date précise, aucune comparaison normalisée entre bases et aucune série d’incidents ne quantifient cet héritage. Il serait donc injustifié de promettre sa disparition rapide ou d’affirmer qu’il est négligeable.

Le principe directeur ne balance pas entre deux légitimités concurrentes. Il fixe deux devoirs complémentaires du teneur de registre : protéger l’unicité et la preuve de contrôle pour les nouvelles écritures ; préserver l’exactitude face à la continuité opérationnelle déjà déployée. La non-rétroactivité n’accorde pas à l’ancien nom une vérité supérieure. Elle empêche simplement le registre de transformer une nouvelle convention en pouvoir de rupture sur la réalité existante.

La suppression révèle la limite de la discrétion

La frontière devient plus délicate si l’équipe supprime son ancien objet plat, puis découvre qu’un processus ou un partenaire le cherche encore. Tant que l’objet existait, elle pouvait l’utiliser et le modifier. Après la suppression, une demande portant sur le même libellé ressemble, pour la règle ordinaire, à une création plate neuve et devrait être refusée. DRAFT02 impose pourtant des exceptions au cas par cas, en citant précisément la restauration d’un AS-SET plat supprimé par erreur.

L’opérateur ne présente alors plus seulement un objet et des éléments d’authentification. Il demande que son geste antérieur soit reconnu comme une erreur et que le retour du nom soit traité comme une continuation. AFRINIC ne vérifie plus seulement la forme hiérarchique et le contrôle d’une racine. Elle doit qualifier le passé : s’agit-il du retour du même objet ou de l’admission nouvelle d’un nom que la règle ordinaire interdit ?

L’intention de préserver une dépendance existante ne donne pas naissance à un pouvoir discrétionnaire légitime. Une faute humaine, une automatisation mal configurée ou un incident administratif peuvent rendre nécessaire une correction. Mais la correction doit rester attachée à des faits vérifiables. Le registre ne peut pas convertir ce besoin en faculté de décider qui mérite une exception, encore moins en mécanisme de faveur, de punition ou de jugement politique.

Le personnel d’AFRINIC a lui-même signalé le danger, dans son rôle d’évaluateur technique. Son analyse avertit que le rappel ou la restauration pourrait devenir une faille opérationnelle et compromettre l’objectif. Elle suggère de documenter la raison de chaque exception. Cette attribution ne prouve pas qu’un abus se produira. Elle montre qu’AFRINIC identifie dans son propre projet un canal capable de dissoudre la règle déterministe.

Les documents disponibles ne disent pas qui déciderait, selon quel seuil de preuve, dans quel délai ou sous quelle forme de contrôle. Ils ne précisent pas si le mainteneur devrait être identique, si la suppression devrait être manifestement accidentelle, si l’historique de création serait conservé, si le contenu pourrait changer pendant la restauration ni si une décision serait contestable. Ils n’établissent pas davantage si le motif serait public, audité périodiquement ou seulement conservé par l’administration.

Ces inconnues n’accordent aucun bénéfice de légitimité à l’administration. Elles marquent une lacune. Dans une couche commune limitée à l’exactitude, à l’unicité et à la preuve de contrôle, une exception doit elle-même être traduite en prédicats objectifs : existence antérieure du même objet, continuité du contrôleur, traçabilité de la suppression, conservation de l’historique et correspondance de l’identité restaurée. Si ces faits ne peuvent être vérifiés, le registre ne doit pas inventer une autorité de dérogation.

La distinction est décisive. Corriger une écriture afin que le registre reflète la même réalité n’est pas gouverner. Accorder un nom neuf parce qu’un décideur juge le demandeur digne d’exception serait gouverner par discrétion. La première fonction peut appartenir à un teneur de registre si elle est déterministe et auditable. La seconde excède son mandat.

Les comparaisons régionales n’accordent aucun mandat à AFRINIC

Les autres registres ne sont ni des autorités sur AFRINIC ni des sources de légitimité politique. Leurs documents servent uniquement de preuves comparatives attribuées. APNIC établit qu’une restriction prospective peut être déployée tout en préservant les objets existants : sa proposition 151 est officiellement indiquée comme mise en œuvre en 2023. RIPE NCC documente une limite plus fermée : depuis le déploiement de la version 1.105 en décembre 2022, les anciens objets plats pouvaient encore être modifiés ou supprimés, mais un nom supprimé ne pouvait pas être recréé.

Ces cas isolent les conséquences de deux choix techniques. APNIC montre qu’il est possible de renforcer les créations futures sans migration générale. RIPE ferme le canal de restauration, ce qui rend la règle plus nette mais fait supporter au détenteur et à ses consommateurs le coût d’une suppression accidentelle devenue irréversible. AFRINIC propose une soupape. La question n’est pas quel registre possède l’autorité morale d’être imité. Elle est de savoir si le retour d’un nom peut être vérifié comme continuité du même état sans instaurer une permission discrétionnaire.

LACNIC et ARIN bornent toute prétention de fermeture mondiale. Les documents officiels de LACNIC examinés montrent l’usage de noms hiérarchiques enracinés dans un ASN, sans suffire à vérifier une interdiction complète sur chaque interface. Chez ARIN, une consultation de 2025 a porté sur la restriction des nouvelles créations non hiérarchiques. Une proposition a été rejetée comme hors du champ de la politique des ressources numériques, le besoin a été redirigé vers le canal des services, puis la fonctionnalité a été placée dans une liste de travaux futurs à prioriser. Aucune livraison n’était établie au 9 août 2026.

Dans les sources vérifiées, APNIC et RIPE NCC sont ainsi les deux comparateurs pour lesquels une restriction comparable est directement documentée comme déployée. Ce décompte ne signifie pas que LACNIC n’applique aucun contrôle. Il montre seulement pourquoi l’affirmation selon laquelle une mise en œuvre AFRINIC mettrait fin au « squattage » dans les cinq grands registres serait trop large : ARIN n’avait pas annoncé de déploiement, l’étendue de l’exécution LACNIC restait à confirmer, les bases tierces demeureraient autonomes et les noms plats historiques survivraient.

Aucun alignement entre registres ne crée de souveraineté collective. Cinq organisations privées appliquant la même convention resteraient cinq teneurs de registres coordonnés autour d’une propriété utile. La répétition d’un test peut renforcer l’interopérabilité ; elle ne transforme pas ce test en juridiction sur les réseaux.

Le consommateur garde sa propre décision

La meilleure objection à la proposition rappelle qu’un opérateur soigneux dispose déjà d’un autre repère : le nom de la source. Il peut choisir les bases interrogées, fixer leur ordre de confiance et conserver un identifiant qualifié. La fiche de Google dans PeeringDB, par exemple, associe l’ASN 15169 à RADB::AS-GOOGLE. Cette forme indique à la fois l’objet et la base où le chercher. Correctement préservé, ce contexte réduit une partie de l’ambiguïté sans nouvelle règle AFRINIC.

L’objection devient plus forte lorsqu’on dresse la liste de ce que DRAFT02 ne change pas. Le texte ne répare pas les objets périmés, ne choisit pas l’ordre des sources d’un résolveur et ne détermine pas comment un générateur doit réagir à une expansion vide. Il ne couvre pas les route-sets ni les autres types de sets RPSL. Il ne contraint pas les IRR tiers. Il ne crée aucun ROA et ne modifie pas la validation d’origine dans la RPKI. La non-rétroactivité signifie en outre que les opérateurs devront continuer à qualifier les sources, vérifier les changements et protéger leurs générateurs.

Cette objection atteint les promesses trop larges, mais pas le mécanisme étroit. La qualification de source agit lors de la consommation et dépend de chaque opérateur. L’authentification de la racine agit avant la consommation : elle empêche qu’un objet neuf apparaisse sous un ASN dans AFRINIC sans l’autorisation attendue. L’une réduit le risque de choisir le mauvais homonyme ; l’autre réduit la possibilité d’en créer certains. Les contrôles se complètent sans que l’un donne à l’autre un pouvoir supérieur.

Cette séparation incarne la coordination minimale. AFRINIC vérifie ce qui appartient à son écriture : syntaxe, racine et preuve de contrôle. Le réseau consommateur reste libre de choisir ses sources, de développer le set, d’évaluer les membres et d’installer ou non un filtre. L’opérateur n’exerce pas sa liberté parce que le registre la lui délègue ; cette décision n’est jamais entrée dans le mandat du registre.

Le coût du nouveau contrôle reste peu quantifié. Les équipes devraient adapter certains modèles et scripts, gérer les deux-points et les niveaux imbriqués, puis organiser l’accès à l’authentification de l’ASN racine. Le personnel parle d’une courbe d’apprentissage mineure et d’éventuelles mises à jour d’outillage ; cette appréciation est une estimation attribuée, ni une enquête auprès des membres, ni une mesure monétaire. Une grande organisation pourrait absorber plus facilement ces ajustements. Un petit opérateur pourrait apprécier une règle stable tout en supportant un coût initial proportionnellement plus lourd.

Trois gestes, trois limites du registre

Pour créer un nouvel AS-SET, l’équipe devrait produire un nom hiérarchique et satisfaire l’authentification attachée à la racine. Elle gagnerait un signal plus fort pour ce nom, à condition que toutes les interfaces appliquent le même test. AFRINIC pourrait refuser une écriture qui ne satisfait pas ce prédicat. Elle ne pourrait pas en tirer un verdict général sur le demandeur ou son réseau.

Pour continuer à utiliser un objet plat ancien, l’équipe n’aurait pas à migrer ses références. Le registre préserverait ainsi l’exactitude face à une réalité installée qu’il n’a pas créée et ne contrôle pas entièrement. Pour restaurer le même objet après suppression, l’équipe quitterait le terrain d’un prédicat déjà défini et rencontrerait une lacune : aucun test complet de continuité n’est publié.

Chacun de ces gestes distribue différemment le risque. Pour les nouveaux objets, la possibilité d’employer sans autorisation une racine ASN dans AFRINIC diminuerait ; l’attention se déplacerait vers les échecs d’authentification, les incohérences d’implémentation et les exceptions. Pour les anciens objets, l’absence de migration épargnerait un risque de rupture aux détenteurs, mais laisserait l’ambiguïté aux consommateurs. Pour les bases externes, rien ne changerait directement.

La fragmentation interne peut devenir visible dès la création. La personne qui prépare les filtres n’administre pas toujours l’objet ASN ; une automatisation ancienne peut supposer que tous les noms sont plats ; un outil peut mal traiter les deux-points ou les niveaux imbriqués. Le personnel estime que l’effet resterait limité, mais aucune enquête ne mesure la manière dont les droits et les outils sont réellement répartis parmi les membres.

La suppression expose le risque le plus difficile à inverser. Tant que le nom plat existe, son titulaire peut continuer à l’utiliser et le modifier. Une fois supprimé, la voie ordinaire du nouveau régime ne lui permettrait plus de le recréer. Une opération de nettoyage banale pourrait convertir une continuité acquise en demande d’exception. Cette dépendance à une faveur administrative serait précisément le défaut à éviter. La protection des suppressions, la conservation de l’historique et la définition préalable d’une preuve de restauration deviennent donc essentielles.

Pour le consommateur, la discipline ne disparaît pas. Un nouvel AS-SET hiérarchique d’AFRINIC permettrait raisonnablement d’inférer que son premier objet a été créé par une partie capable de satisfaire l’authentification de l’ASN racine. Le consommateur devrait encore choisir sa source, actualiser ses données, examiner les membres et décider comment réagir à une erreur. La RPKI répond, dans son propre champ, à la question de l’origine cryptographiquement autorisée pour un préfixe ; DRAFT02 ne modifie pas cette couche.

Le registre utile reste un registre étroit

Le jugement institutionnel ne dépend pas d’une confiance accordée à AFRINIC, à son processus ou à ses dirigeants. Il dépend de preuves observables et de la conformité du mécanisme à la fonction limitée du registre. Quatre éléments permettraient de constater le changement annoncé : une clarification du statut procédural ; un texte définitif dont le champ reste AS-SET et nouvelles créations ; une application identique dans WHOIS, MyAFRINIC et toutes les interfaces ; enfin, une règle de restauration assez précise pour vérifier la continuité du même objet sans ouvrir un pouvoir de faveur.

Ces preuves correspondent aux trois moments vécus par l’équipe. La création doit recevoir un refus ou une acceptation reproductible. La modification de l’ancien objet doit préserver la continuité promise. La restauration doit relier le nom demandé à un passé attesté. Si l’un de ces résultats dépend du canal employé, d’une préférence personnelle ou de raisons invisibles, le texte et le service raconteront deux règles différentes.

La valeur du projet tient à sa juste taille. Une racine ASN, l’authentification de son mainteneur et la délégation par le parent formeraient une chaîne de contrôle testable pour les nouveaux AS-SET d’AFRINIC. Cette chaîne améliore l’exactitude et la preuve de contrôle par rapport à un nom plat dont la relation à un ASN n’est pas encodée. C’est la fonction étroite du teneur de registre : protéger la qualité de l’écriture commune.

Cette valeur s’arrête avant toute prétention de souveraineté. Le mécanisme ne démontre pas une unicité mondiale, ne répare pas les noms plats installés, ne certifie pas la justesse des politiques de routage et ne donne aucun droit sur les réseaux. Il ne permet ni punition, ni pouvoir coercitif discrétionnaire, ni verdict politique. Il ne fait pas de l’inscription la source de propriété ou d’existence. Le registre décrit une preuve limitée ; il ne crée pas la réalité qu’elle aide à coordonner.

Au 9 août 2026, la conclusion factuelle reste conditionnelle parce que l’adoption et l’exécution n’étaient pas établies. La conclusion doctrinale, elle, ne l’est pas. Si le projet est adopté puis appliqué uniformément, AFRINIC accomplira correctement une tâche de teneur de registre en améliorant la preuve prospective de contrôle à la création des noms. Si AFRINIC transforme cette tâche en pouvoir de décider la légitimité d’un réseau, elle sortira immédiatement de son mandat. Ni le consensus, ni le Board, ni le personnel, ni le RSA ne peuvent franchir cette frontière à sa place.