Résumé

  • AFPUB-2026-v6-001-DRAFT02 soumettrait toute demande IPv4 initiale ou additionnelle pendant l’épuisement à une condition IPv6 : détenir ou demander simultanément de l’espace IPv6, satisfaire les critères applicables et fournir un plan de déploiement cohérent.
  • Pour les réseaux transportant du trafic, le projet fixe des seuils IPv6 de 25 %, 50 % et 75 % aux mois 12, 24 et 48 sur les vingt-cinq principales destinations IPv4 externes compatibles. Pour les réseaux hébergeant des services, applications ou contenus, il exige des taux de 25 %, 75 % et 95 % d’enregistrements AAAA disponibles et joignables sur Internet aux mêmes échéances.
  • Le texte ne définit ni l’objet « destination », ni le dénominateur du pourcentage, ni le protocole de preuve, ni le traitement des dépendances externes, de la conformité partielle, du retard justifié, de la confidentialité, de la correction ou du recours. Il appelle pourtant l’échec une violation de politique.
  • La meilleure défense du projet est intelligible : AFRINIC distribue les dernières ressources IPv4 générales et peut demander au bénéficiaire d’engager un travail IPv6 réel plutôt que de détenir passivement un préfixe. Cette défense ne suffit pas. Un teneur de registre peut administrer étroitement un stock rare; il ne reçoit pas pour autant mandat de punir un choix d’architecture ou un résultat dépendant de tiers.
  • Une condition de stock rare ne peut être légitime que si elle est prospective, objective, étroite, limitée aux éléments que le demandeur contrôle, accompagnée de preuve, notification, correction, continuité et recours indépendant, et sans effet sur les ressources déjà détenues. D2 ne remplit pas ce test.

Le 14 juin 2026, Jordi Palet Martinez, de The IPv6 Company, a soumis la version 2.0 d’AFPUB-2026-v6-001. Elle propose d’ajouter à la période d’épuisement d’AFRINIC une condition qui paraît, à première lecture, être un marché simple : qui demande encore de l’IPv4 doit aussi montrer qu’il déploie IPv6. Mais le marché n’est simple qu’au moment de l’entrée. Si le demandeur n’a pas d’espace IPv6, il doit en demander simultanément; s’il en détient déjà ou vient d’en demander, il doit satisfaire les critères d’allocation ou d’assignation pertinents et présenter un plan de déploiement et d’adressage « cohérent ».

Ensuite commence une surveillance de résultats qui dure jusqu’à quarante-huit mois.

Pour un réseau qui transporte du trafic, le plan doit divulguer les vingt-cinq principales destinations réelles du trafic IPv4 et montrer une proportion croissante de trafic IPv6 vers les destinations externes compatibles : 25 % au douzième mois, 50 % au vingt-quatrième et 75 % au quarante-huitième. Pour un réseau qui héberge des services, applications ou contenus, les seuils sont de 25 %, 75 % et 95 % d’enregistrements AAAA disponibles et de services joignables depuis Internet en IPv6 aux mêmes dates. Le texte ne présente pas ces chiffres comme de simples objectifs d’apprentissage.

Il dit que l’échec du plan constitue une violation de politique.

C’est ici que le projet franchit une frontière institutionnelle. AFRINIC tient les registres de numéros, coordonne leur unicité, évalue des demandes dans le cadre des règles adoptées et maintient des services nécessaires à l’exactitude et à la continuité. Ce rôle n’emporte aucun mandat souverain sur l’architecture des réseaux. Il n’autorise pas AFRINIC à choisir entre double pile, traduction, maintien d’IPv4 ou autre séquence opérationnelle; encore moins à convertir un résultat pluriannuel de trafic, façonné par des clients et des fournisseurs extérieurs, en faute.

L’enjeu n’est donc pas de savoir si IPv6 fonctionne ni si son déploiement peut être utile. Il est de savoir si la rareté d’un stock transforme un coordinateur en régulateur de la stratégie technique. Elle ne le fait pas.

L’intérêt pratique est immédiat. Une petite entreprise qui a des clients prêts à être raccordés peut avoir un besoin IPv4 conforme aux règles de Soft Landing tout en dépendant de terminaux anciens, d’un amont encore imparfaitement compatible, de contenus externes, d’équipements clients ou d’applications qu’elle ne contrôle pas. Si son accès à l’IPv4 additionnel dépend d’une statistique IPv6 mal définie, ce ne sont plus seulement son besoin et ses propres actes qui sont examinés. La conduite de tiers, la qualité de sa télémétrie et l’interprétation d’un Hostmaster deviennent des déterminants de sa capacité de croissance.

AFRINIC ne vérifie alors plus seulement un dossier de ressource rare : elle juge un résultat d’exploitation.

Ce que D2 ajoute réellement

La règle actuelle visée, la section 5.4.4 du manuel consolidé, indique qu’il n’existe pas de limite explicite au nombre de demandes IPv4 additionnelles qu’un LIR ou un utilisateur final peut présenter pendant l’épuisement. D2 n’abolit pas formellement cette possibilité. Il greffe une chaîne IPv6 sur chaque demande initiale ou supplémentaire. Le déclencheur est donc prospectif : les détenteurs existants qui ne demandent pas davantage d’IPv4 ne sont pas décrits comme immédiatement soumis aux jalons. Cette limite de champ est importante, car elle interdit d’écrire que le projet lance un audit automatique de tous les titulaires.

Elle ne résout pourtant pas le problème d’autorité. Pour un titulaire IPv6 qui revient demander de l’IPv4, le personnel d’AFRINIC lit D2 comme une revue rétrospective de son besoin IPv6 et de l’usage qu’il en a fait. Un acte nouveau — la demande IPv4 — rouvre donc l’examen d’un parcours technique antérieur et déclenche une obligation qui continue après la décision d’allocation. La ressource rare sert de levier : le demandeur ne reçoit pas seulement une quantité sous conditions objectives; il entre dans une trajectoire d’architecture surveillée.

La séquence comporte six opérations distinctes. Premièrement, l’absence d’IPv6 impose une demande simultanée. Deuxièmement, l’espace détenu ou demandé doit satisfaire les critères IPv6 applicables. Troisièmement, le demandeur remet un plan de déploiement et d’adressage renvoyant aux exigences actuelles de déploiement et d’annonce du manuel. Quatrièmement, s’il transporte du trafic, il divulgue ses vingt-cinq principales destinations IPv4 et poursuit les trois seuils. Cinquièmement, s’il héberge des services, il poursuit les trois seuils AAAA et de joignabilité. Sixièmement, l’échec est désigné comme violation.

Le texte construit ainsi un pont entre entrée dans le stock IPv4, comportement technique futur, production de données et langage disciplinaire.

Il existe en outre une incohérence textuelle non résolue. La disposition normative annonce une modification de la section 5.4.4, alors que les métadonnées de l’étude d’impact citent les sections 6.4.4, 6.5.1.1.1 à 6.5.1.1.4 et 6.8.2.2.d sans mentionner 5.4.4. Il n’est pas possible, à partir du dossier publié, de déterminer laquelle des deux listes est erronée. Cette divergence ne prouve pas à elle seule que la règle serait inapplicable. Elle montre que l’objet exact de la modification n’est pas stabilisé au point où l’on pourrait raisonnablement attacher une faute à son inexécution.

Des pourcentages sans objet stable

La difficulté centrale ne tient pas à l’arithmétique des seuils. Les nombres sont clairs. Leur objet ne l’est pas. D2 ne dit pas si la part de trafic doit être calculée en octets, paquets, flux, sessions, utilisateurs, destinations ou selon une autre unité. Chacun de ces dénominateurs décrit une réalité différente. Un service massif peut dominer les octets tout en représentant peu de destinations; une multitude de petites sessions peut dominer les flux sans dominer la capacité; une mesure par utilisateur peut réagir au parc de terminaux plutôt qu’à l’architecture du réseau.

La formule « vingt-cinq principales destinations » est tout aussi indéterminée. Une destination peut être une adresse IP, un préfixe, un ASN, un domaine, une application, un fournisseur de contenu ou un service. Le classement change selon l’unité et selon la fenêtre d’observation. Les destinations dynamiques exigent une normalisation que le projet ne décrit pas. Le texte ne précise pas davantage comment vérifier qu’une destination externe est « IPv6-enabled », comment compter une destination qui offre IPv6 de manière partielle, ni comment traiter un changement dans le classement pendant la période observée.

Le volet hébergement n’est pas plus auto-exécutoire. La présence d’un enregistrement AAAA et la joignabilité depuis Internet semblent vérifiables, mais le dénominateur reste inconnu. Quelle est la liste des services? Compte-t-on les noms, les applications, les protocoles, les instances ou les clients? Comment traiter les alias, l’anycast, plusieurs adresses pour un même nom, une joignabilité partielle ou des résultats différents selon le point de mesure? Sans inventaire défini et sans points de contrôle publiés, 95 % au mois 48 est un chiffre précis appliqué à une collection inconnue.

Cette indétermination produit deux erreurs opposées. La première serait d’interpréter les jalons comme une courbe linéaire mensuelle. Le projet ne le dit pas : il fixe des points aux mois 12, 24 et 48. La seconde serait d’inventer une définition charitable au moment de l’application. Un Hostmaster pourrait choisir une mesure qui paraît praticable, mais cette improvisation ne guérit pas le texte. Elle déplace la norme de la politique publique vers la discrétion administrative, avec des résultats potentiellement différents pour deux réseaux comparables.

La mesure APNIC ne répond pas à la question du demandeur

Le problème exposé par D2 s’appuie sur des chiffres arrondis de capacité IPv6 : 44 % dans le monde et 6 % en Afrique. Les séries régionales d’APNIC Labs permettent de retrouver ces ordres de grandeur au 14 juin 2026. La valeur brute mondiale est de 43,822740 % et la valeur brute africaine de 5,869934 %; l’arrondi ordinaire donne bien 44 % et 6 %. Plusieurs séries lissées aboutissent aussi aux mêmes entiers. Le titre statistique est donc plausible, mais sa reproduction exacte ne vient pas du projet lui-même.

D2 ne fournit ni date d’observation, ni fenêtre de moyenne, ni requête précise. Les données APNIC distinguent notamment valeurs brutes et lissages sur plusieurs périodes. Le projet affirme aussi que huit pays africains dépassent 20 %, que quinze se trouvent entre 10 % et 19 % et que quinze restent sous 1 %, sans publier la liste datée des pays, l’univers retenu ou la série utilisée. Ces groupes doivent rester des affirmations de l’auteur; il n’est pas possible de les auditer à partir de sa prose seule.

Surtout, « IPv6 capable » chez APNIC ne signifie ni part d’espace IPv6 alloué, ni nombre de réseaux configurés, ni pourcentage de tous les octets ou paquets qui circulent en IPv6. La mesure observe si des terminaux échantillonnés peuvent récupérer un objet disponible uniquement en IPv6 dans une expérience fondée sur la publicité, puis agrège les résultats avec pondération. C’est un indicateur de capacité des points terminaux observés à l’échelle d’une population. Ce n’est pas une preuve qu’un demandeur individuel contrôle tous les facteurs qui déterminent son trafic.

Le passage d’une mesure régionale à une obligation individuelle est ainsi doublement fragile. Une moyenne de population peut documenter un retard général sans fournir un critère de faute pour une entreprise. Et même si la mesure régionale était parfaitement reproduite, elle ne définirait ni les vingt-cinq destinations du demandeur, ni son dénominateur, ni la part de responsabilité imputable à ses propres décisions. Une statistique utile au diagnostic ne devient pas, par simple citation, un instrument équitable d’adjudication.

Qui contrôle le résultat observé?

La bonne unité de responsabilité est l’acte contrôlé par le demandeur. Il peut demander un préfixe IPv6, élaborer son plan d’adressage, configurer ses équipements, publier des enregistrements DNS pour ses propres services, activer une architecture qu’il exploite, tenir des journaux et répondre à une demande de preuve raisonnable. Il ne peut pas forcer les équipements de ses clients à accepter IPv6, imposer un calendrier à un fournisseur amont, modifier un contenu externe, corriger le produit d’un vendeur ni décider comment une destination tierce sera atteinte.

Cette distinction n’est pas abstraite. À AFRINIC-37, des participants ont averti que les clients ne pouvaient pas être contraints d’adopter, que tous les opérateurs ne disposaient pas de NetFlow, que les objectifs de trafic pouvaient encourager la manipulation et qu’une période de grâce pouvait être nécessaire pour les premières demandes IPv4. Après la réunion, une objection a décrit le cas d’un jeune réseau rural reliant des écoles, dépourvu d’outils d’analyse du trafic et déjà confronté à d’importantes barrières d’entrée. Il s’agit de positions attribuées, non de statistiques générales sur tous les petits réseaux.

Elles identifient cependant exactement le défaut de conception : celui qui supporte la conséquence ne contrôle pas nécessairement le résultat mesuré.

Le personnel d’AFRINIC a lui-même averti que les petits opérateurs et les WISP pourraient être touchés de manière disproportionnée lorsque la compatibilité des appareils, les réalités commerciales ou la préparation technique retardent IPv6 malgré un besoin IPv4 réel. Il a relevé que le terme « cohérent » n’était pas défini et que manquaient la validation des vingt-cinq principales destinations, la preuve acceptable, le traitement de la conformité partielle et celui des délais justifiés. Le danger n’est donc pas une hypothèse greffée sur un texte silencieux; il se trouve dans l’évaluation institutionnelle jointe au projet.

À cette dépendance s’ajoute une asymétrie de capacité administrative. La collecte de flux, la conservation de données, l’inventaire DNS, les tests de joignabilité, la préparation du plan et la réponse aux demandes de preuve ont une composante fixe. Une grande entreprise peut répartir ce travail sur davantage de clients et mobiliser plus facilement des spécialistes. Un petit opérateur ne peut pas miniaturiser une procédure au même rythme que son chiffre d’affaires ou sa base d’abonnés. La même exigence formelle devient ainsi régressive. Le dossier ne permet pas d’en chiffrer le coût; il permet d’en identifier le mécanisme.

La preuve peut devenir une nouvelle surface de risque

Demander les principales destinations et les flux qui les établissent n’est pas un geste documentaire neutre. Ces éléments peuvent révéler la composition de la clientèle, une concentration de contenus, des modèles de transit ou des dépendances commerciales. Il s’agit ici d’une inférence à partir de la nature des données demandées, non d’un incident de confidentialité rapporté. Or ni D2 ni l’évaluation publiée ne précisent minimisation, conservation, agrégation, accès ou protection de ces informations.

Un dispositif complet devrait dire quelle preuve est strictement nécessaire, qui peut la consulter, combien de temps elle est conservée, sous quelle forme elle est agrégée et comment le demandeur conteste une lecture erronée. En l’absence de ces règles, l’opérateur fait face à un choix malsain : remettre une intelligence commerciale fine à l’institution ou risquer que sa preuve soit jugée insuffisante. Le registre s’épaissit encore, car il ne conserve plus seulement les éléments indispensables à l’unicité et à l’exactitude des numéros; il collecte une vue sur le fonctionnement économique du réseau.

Le choix du pourcentage crée aussi un risque d’optimisation de la mesure plutôt que du service. Si la conformité porte sur une part mal définie du trafic, un opérateur rationnel cherchera à comprendre ce qui entre dans le compteur. La politique peut ainsi récompenser le déplacement de ce qui est visible, le choix d’une fenêtre favorable ou la présentation d’un sous-ensemble, sans garantir une architecture plus résiliente. Ce risque de manipulation a été soulevé pendant la réunion. Il ne prouve pas qu’un opérateur trichera; il montre qu’une norme imprécise fabrique de mauvaises incitations.

Une violation sans chemin déterminé

Le mot le plus lourd de D2 est « violation ». Il relie un résultat technique futur à l’univers contractuel du Registration Service Agreement. Le RSA définit les politiques adoptées de manière à inclure celles qui entrent en vigueur pendant la durée de l’accord et oblige les membres à s’y conformer. Il permet des demandes d’information et des revues d’utilisation; un défaut de coopération peut conduire, selon ses clauses générales, à la retenue de ressources, à la révocation, à des conséquences pour de futures allocations, à la fermeture d’un LIR ou à la résiliation.

Il serait cependant faux d’écrire qu’un seuil manqué entraîne automatiquement une révocation. D2 ne le dit pas. Le RSA prévoit, pour la résiliation liée à un manquement, des particularités écrites, une invitation à justifier la situation ou à y remédier, un délai de trente jours pour répondre et des preuves des mesures correctives. Il contient également une clause d’appel et une voie de revue par le Board pour les décisions d’un registre d’attribution. Le projet ne relie pas sa nouvelle violation à une conséquence déterminée de ce système.

L’incertitude est donc substantielle : un échec entraîne-t-il seulement le refus de la demande IPv4 en cours, une enquête de conformité, une conséquence sur un service existant ou une autre mesure? Quel standard de preuve s’applique? Qui rédige les motifs? Le recours suspend-il l’effet de la décision? Quelle continuité est garantie pendant le désaccord? Aucun de ces points n’est défini. Le résultat est un terme disciplinaire doté d’une force potentielle mais privé de chaîne d’application.

L’évaluation juridique publiée n’apporte pas de réponse. Elle se résume à « No legal issue » et la partie opérationnelle n’identifie aucune modification contractuelle. Cette phrase prouve ce qu’AFRINIC a publié, non que les questions de preuve, de confidentialité, de dépendance, de remède et de recours ont reçu une analyse indépendante. Une conclusion institutionnelle non motivée ne peut servir de fondement à un pouvoir nouveau. Plus la conséquence possible touche des réseaux en fonctionnement, plus la raison, la preuve et la contestation doivent être explicites.

La procédure a correctement refusé de fermer le débat

La chronologie montre que les lacunes ne sont pas apparues après coup. Avant le projet, un échange du 15 octobre 2025 avait déjà envisagé de lier l’IPv4 additionnel à un déploiement IPv6 achevé; il s’agissait d’un antécédent de discussion, pas d’un acte. La première version a été publiée le 22 mai 2026 et annoncée sur la liste RPD le 28 mai. La discussion s’est immédiatement portée sur la différence entre détenir ou annoncer IPv6 et le déployer réellement, puis sur la façon de mesurer ce déploiement.

En réponse à cette objection, l’auteur a avancé puis défendu les seuils de 25 %, 50 % et 75 % sur douze, vingt-quatre et quarante-huit mois, en indiquant qu’une violation pouvait engager les termes du RSA. Du 28 au 30 mai, des participants ont soulevé l’exemption d’une première demande, le coût pour les petits opérateurs, le périmètre du rôle, la formation, l’infrastructure et les dépendances d’écosystème. L’auteur a contesté les objections de coût et de mandat.

D2, soumis le 14 juin, a ajouté les vingt-cinq destinations, le volet des services hébergés et le langage de violation. Le personnel a achevé son évaluation le 20 juin; AFRINIC a annoncé la nouvelle version le 22 juin. Deux jours plus tard, à AFRINIC-37, les participants ont débattu de télémétrie, de contrôle des clients, de l’entrée des petites entreprises et des incitations créées par la mesure. Les coprésidents ont constaté que les préoccupations restaient non résolues, n’ont pas trouvé de consensus et ont renvoyé le texte sur la liste.

Le 8 juillet, les échanges ont conservé l’objection du jeune réseau rural, tandis que l’auteur maintenait qu’IPv6 et une surveillance élémentaire ne devaient pas être facultatifs. Au 9 août 2026, l’index d’AFRINIC indiquait toujours que D2 était en discussion. Le projet n’était ni une politique adoptée, ni une règle ratifiée par le Board, ni une obligation contractuelle en vigueur. Son statut ouvert n’est pas un détail de présentation : il interdit de traiter ses seuils comme une trajectoire certaine.

La meilleure défense, présentée sans raccourci

La défense la plus solide part de la rareté. AFRINIC ne distribue pas une ressource illimitée; elle rationne son dernier stock IPv4 général. Une entreprise qui sollicite ce bénéfice peut raisonnablement être invitée à préparer l’avenir plutôt qu’à prolonger passivement sa dépendance. La règle est prospective, puisqu’elle s’attache à une demande nouvelle. Elle ne retire pas immédiatement des ressources aux détenteurs qui ne reviennent pas au guichet. Ses délais de douze, vingt-quatre et quarante-huit mois laissent du temps pour un déploiement réel.

Cette défense insiste aussi sur la différence entre possession et usage. Exiger seulement une allocation IPv6 pourrait créer une conformité de papier. Une obligation de déploiement, fondée sur le trafic propre du demandeur et sur ses services, cherche au contraire une réalité observable. Le manuel actuel lie déjà l’IPv4 du stock libre à des critères de besoin et d’utilisation, et les critères IPv6 initiaux cités envisagent déploiement ou annonce sur douze mois. L’auteur affirme que des réseaux plus petits peuvent être plus faciles à migrer et que 464XLAT peut coûter moins que CGNAT.

Si ces conditions se vérifient pour un opérateur, l’effort IPv6 pourrait réduire une partie de sa dépendance future.

Une comparaison bornée renforce l’intuition sans valider D2. ARIN réserve un /10 spécifique et attribue des /24 pour des besoins immédiats liés au déploiement IPv6. Ce précédent montre qu’un registre peut relier un petit stock IPv4 dédié à une finalité IPv6. Il ne montre pas qu’il peut attacher à toutes les demandes ordinaires d’IPv4 une obligation de performance sur quatre ans. Le comparateur est plus étroit, porte sur un réservoir dédié et vise un besoin immédiat; il n’est pas l’équivalent du dispositif proposé par AFRINIC.

La défense doit donc être prise au sérieux à son point le plus fort : un stock rare peut être offert selon une condition prospective clairement annoncée, et une preuve d’action réelle peut être plus informative qu’un préfixe dormant. Elle échoue toutefois sur deux limites. La première est interne : le projet ne définit pas ce qu’il mesure, comment il le prouve ni comment il traite les dépendances. La seconde est constitutionnelle : même parfaitement mesuré, un résultat général d’architecture n’appartient pas au mandat obligatoire d’un registre de numéros.

Le test du registre mince

Une règle obligatoire du registre doit répondre à une question rigoureuse : protège-t-elle directement l’unicité, l’exactitude des enregistrements, la preuve de contrôle, la sécurité des assertions, la notification, la correction ou la continuité opérationnelle? Les éléments de D2 qui exigent une identité exacte du demandeur, une demande IPv6 valide et un plan vérifiable peuvent se rattacher à l’administration prospective d’un stock. Les parts de trafic vers des destinations externes et les ratios d’hébergement sur quatre ans ne protègent pas l’unicité d’un numéro.

Ils gouvernent la manière dont l’opérateur construit et fait évoluer son réseau.

La différence est décisive. Un registre peut refuser une demande si le demandeur ne prouve pas son identité, son contrôle, son besoin dans la limite d’une règle de stock ou la cohérence factuelle des informations fournies. Il peut corriger une entrée inexacte, notifier un conflit et conserver un historique auditable. Il ne peut pas transformer sa maîtrise d’une base de données en droit de décider quels protocoles doivent porter quelle part de trafic chez un opérateur. La rareté resserre cette responsabilité; elle ne l’élargit pas en souveraineté.

Ce que pourrait être une condition licite de stock rare

Le contreprojet le plus proche de l’objectif de D2 commencerait par conserver la demande simultanée d’IPv6 ou l’exigence de détention pour celui qui sollicite de l’IPv4 rare. Il demanderait un plan limité aux actifs et services que l’entreprise contrôle. L’échéancier de preuve, publié avant toute application, définirait l’unité de destination, le dénominateur, la période d’observation, l’échantillonnage, la taille minimale, la validation et la correction. Les données commerciales seraient minimisées et protégées.

Plusieurs voies de preuve équivalentes éviteraient de transformer la possession d’un outil de flux en condition implicite d’accès. Une entreprise pourrait documenter son trafic, l’activation de préfixes clients, l’inventaire et la joignabilité de ses propres services ou une architecture de traduction. Les jalons numériques pourraient fonctionner comme des refuges de conformité réfutables pendant une période d’évaluation, plutôt que comme des seuils absolus attachés à un mot de faute.

Les délais imputables aux amonts, aux équipements clients, aux contenus externes ou à des achats hors du contrôle du demandeur seraient exclus ou ajustés sur preuve.

Pour une première demande ou une jeune entreprise, une période de grâce accompagnée de formation et d’un plan daté limiterait la barrière fixe sans créer d’exemption permanente. Toute conclusion défavorable devrait être écrite, identifier les éléments retenus, donner accès à la preuve, permettre une correction, ouvrir un délai de remède et nommer une voie de recours indépendante. Les résultats agrégés pourraient être publiés après douze et vingt-quatre mois selon la taille de l’opérateur, la méthode de preuve et l’issue — réussite, correction, appel — sans révéler les destinations commerciales.

Ce modèle serait plus déterminé que D2, mais la correction technique ne règle pas tout. Les mesures doivent rester des moyens volontaires ou des refuges liés à la seule demande future. Elles ne peuvent devenir un pouvoir de punir le choix d’architecture. La conséquence proportionnée d’un défaut sur une condition prospective clairement écrite ne peut porter, au plus, que sur la demande nouvelle examinée après notification et correction. Elle ne doit jamais atteindre les ressources existantes ni interrompre les services nécessaires à la continuité.

Le verdict

D2 pose une question valable avec un instrument illégitime. Il est raisonnable de demander si un demandeur de la dernière ressource IPv4 prépare réellement son réseau à fonctionner avec moins d’IPv4. Il est déraisonnable de confier à AFRINIC un pouvoir pluriannuel sur les résultats d’architecture, surtout lorsque l’unité de mesure, la preuve, la dépendance, le remède et le recours sont absents.

Le texte ne doit donc pas être réparé seulement par un meilleur glossaire de métriques. Même un pourcentage parfaitement défini ne donnerait pas à AFRINIC le mandat de punir une entreprise parce que ses clients, ses contenus externes ou sa propre stratégie technique n’atteignent pas un résultat IPv6 prescrit. La règle correcte est plus étroite : l’accès à un stock rare peut avoir des conditions prospectives, objectives et transparentes, limitées à ce que le demandeur décide et contrôle.

Le registre peut exiger une preuve proportionnée de ces conditions, notifier les défauts, permettre leur correction et refuser la demande nouvelle selon des raisons écrites et révisables.

Il ne peut pas transformer un écart d’architecture en violation générale. Il ne peut pas attacher ce mot aux ressources déjà intégrées dans des réseaux en fonctionnement. Il ne peut pas utiliser un dossier de trafic comme un instrument de contrôle commercial. Il ne peut pas substituer une réunion à une autorité souveraine inexistante. La continuité, l’exactitude et la possibilité d’un recours indépendant ne sont pas des concessions après la sanction; elles sont les limites constitutives du rôle d’AFRINIC.