Résumé

  • Le rapport d’expérience d’AFRINIC de 2018 décrit un cas précis : un utilisateur final anonyme ne pouvait recevoir un /24 supplémentaire pour un second centre de données redondant, car l’utilisation de l’ensemble de ses ressources était inférieure à 90 %.
  • AFPUB-2026-IPv4-002-DRAFT02, actuellement en Last Call, permettrait de déroger au seuil lorsqu’un objectif technique démontré ne peut pas être servi en pratique par les ressources existantes. Pourtant, la règle commune se limite à exiger une justification « suffisamment documentée », et le compte rendu de la réunion refuse délibérément une liste universelle de pièces.
  • La souplesse n’oblige pas à rendre le jugement invisible. Un reçu d’exception protégé et versionné peut fixer les faits minimaux, la garde des preuves, le dialogue d’examen, les codes de motif et le recours, tout en laissant l’architecture à l’opérateur.

Un cas opérationnel, pas une fiction de politique

La première pièce du dossier précède le texte actuel. À la page huit de son rapport d’expérience de mise en œuvre présenté à AFRINIC-29, AFRINIC expose une difficulté rencontrée par ses Hostmasters.

Un membre de type End User sollicitait un nouveau /24 pour assurer la redondance d’un centre de données. Son utilisation totale était inférieure à 90 %. Selon l’interprétation alors appliquée à la Soft Landing, il ne pouvait recevoir de ressources supplémentaires et ne pouvait donc mettre en place le second centre.

Le document ne donne ni identité, ni pays, ni date de ticket, ni préfixe d’origine. Il ne montre pas la séparation électrique ou réseau, les solutions de rechange envisagées, un éventuel recours ou l’issue ultérieure. Il ne démontre pas davantage que tout second site mérite un /24.

Sa portée est plus précise. Un seuil séquentiel attend que le premier stock soit presque rempli. Une architecture redondante exige que le second domaine de panne soit disponible avant la défaillance du premier. Mesurer correctement l’usage des adresses existantes ne suffit donc pas toujours à mesurer le besoin de simultanéité.

Le projet ouvre une exception, au conditionnel

Le suivi indépendant de NOG Alliance indexe AFPUB-2026-IPv4-002-DRAFT02 sous l’étiquette plus large Under discussion. L’enregistrement d’AFRINIC-37 conserve la constatation d’un rough consensus et le passage en Last Call. La première version date du 6 mai 2026 ; la deuxième, du 16 juin, a été présentée le 24 juin. Au 23 août, il s’agit toujours d’un projet, non d’une exception mise en œuvre.

La règle ordinaire resterait inchangée. Pendant l’Exhaustion Phase, un LIR ou un End User qui demande une nouvelle allocation ou affectation IPv4 doit démontrer au moins 90 % d’utilisation de toutes les ressources IPv4 reçues auparavant. Une organisation nouvelle qui n’en possède aucune reste dispensée pour sa première demande.

Le projet ajouterait une voie d’exception. AFRINIC pourrait écarter le seuil pour un objectif technique clé démontré lorsque le stock existant ne peut pas le servir en pratique ou lorsqu’une contrainte technique pèse sur ce stock. La redondance, la haute disponibilité, les mécanismes de transition IPv6 et l’ouverture de nouveaux sites sont des exemples non limitatifs. Pour cette disposition, la demande serait traitée comme une première allocation ou affectation.

La dernière phrase porte tout le mécanisme de contrôle : la justification doit être suffisamment documentée pour qu’AFRINIC puisse en vérifier la conformité.

Ce n’est pas rien. Le simple mot redondance ne vaut pas preuve. Le demandeur doit produire des faits et AFRINIC doit les examiner. Mais la proposition ne précise pas la proposition factuelle à établir, le minimum à conserver, ni la manière dont un autre examinateur distinguera plus tard la contrainte technique de la préférence d’exploitation.

Le seuil a un nombre ; l’exception n’a pas de type

Le Consolidated Policy Manual actuel se présente comme la version 1.6. Il rend visible le seuil de 90 % et plusieurs règles générales de preuve. Un dossier peut contenir des plans d’ingénierie, de sous-réseaux, de topologie et de routage ; les prévisions doivent rester réalistes et justifiables. Les pratiques doivent s’appliquer équitablement, indépendamment notamment du lieu, de la nationalité ou de la taille. Les informations commerciales utilisées pour l’évaluation mais non requises au registre public doivent rester confidentielles.

Ces principes donnent un cadre professionnel au travail du Hostmaster. Ils ne typent pas la nouvelle exception.

Deux demandeurs peuvent afficher la même utilisation. Le premier veut une implantation dans une autre ville parce qu’un contrat commercial le préfère. Le second doit séparer deux fonctions de traduction derrière des alimentations et des chemins indépendants. Tous deux peuvent écrire haute disponibilité. Seuls les faits situés sous cette étiquette permettent de déterminer si les ressources existantes sont réellement inutilisables et si la contrainte est technique au sens du projet.

Une liste de champs ne rend pas ce jugement automatique. Elle conserve les éléments sur lesquels il s’est appuyé. C’est une fonction plus étroite et plus utile.

Refuser un dossier universel n’interdit pas une interface commune

L’enregistrement de la réunion AFRINIC-37 contient la question décisive : quelles pièces techniques faudrait-il fournir lorsqu’une organisation demande plusieurs sites sans atteindre 90 % ? L’auteur répond qu’aucune liste unique ne convient, car une transition IPv6 et un déploiement multisite ne produisent pas les mêmes preuves. L’évaluation serait un dialogue d’entrée et de sortie avec le personnel.

Cette prudence est justifiée. Un schéma de centre de données ne dimensionne pas nécessairement un pool de traduction. Une commande d’équipement ne prouve pas l’indépendance des domaines de panne. Une prévision de trafic ne décrit pas à elle seule la séparation des chemins.

Un autre participant soutient le principe mais craint qu’une simple invocation de la redondance permette pratiquement toute demande et rende l’exécution inégale. L’auteur refuse de cataloguer chaque cas légitime, car une telle énumération exclurait les architectures nouvelles et ferait de la politique une microgestion du personnel. Le responsable des services aux membres pose alors la limite essentielle : une contrainte technique peut justifier la dérogation ; une contrainte opérationnelle ne le peut pas.

La discussion écarte ainsi deux mauvais modèles. Le dossier exhaustif serait rigide. L’adjectif sans structure serait difficile à contrôler. Il manque une interface stable dont les valeurs resteraient propres à chaque architecture.

Les coprésidents ont constaté un rough consensus lors de la réunion et ont envoyé le texte en Last Call. L’enregistrement annonce aussi une définition de l’utilisation pendant cette phase. Le suivi neutre conserve son libellé plus large, et aucune source publique employée ici n’établit une ratification, une mise en œuvre ou un schéma d’exception par champs. Cela ne prouve pas qu’aucune définition n’a circulé ailleurs ; cela montre ce que le lecteur ne peut pas reconstruire du projet et de la réunion.

L’adverbe a déplacé la garantie dans le ticket

La présentation du projet et sa discussion placent la garantie dans la formule « suffisamment documentée ». Le besoin technique doit être démontré ; les ressources existantes doivent être impropres à le servir en pratique ; AFRINIC doit pouvoir vérifier le lien.

La règle recherchée peut se lire ainsi :

fonction technique → impossibilité pratique avec le stock existant → tranche IPv4 supplémentaire

Chaque flèche demande une preuve. Quelle fonction ? Quels blocs existants ont été examinés ? Pourquoi la réutilisation, la renumérotation, un changement d’agrégation ou un autre emplacement sont-ils impraticables ? Quel site ou domaine de panne reçoit la nouvelle tranche ? Combien de temps les ressources doivent-elles coexister ? Quel fait réfuterait le récit ?

Sans réponses stables, la garantie reste enfermée dans les échanges du ticket. Le demandeur du jour peut comprendre la décision. Son successeur, un auditeur ou l’auteur d’un recours retrouvera peut-être seulement un résultat entouré de pièces hétérogènes.

Discrétion, motifs et réexamen ont des fonctions distinctes

L’enregistrement de la réunion décrit l’examen comme un dialogue, non comme un dossier universel. Il n’établit ni la finalité d’une décision ni un droit juridique particulier au recours. L’appréciation professionnelle, les motifs conservés et toute voie applicable de correction ou de réexamen sont donc des choix distincts.

Cette controverse sépare trois fonctions. La discrétion est l’espace d’interprétation lorsque les faits ne se réduisent pas à un test automatique. Le motif est la trace de l’usage de cette discrétion. Le recours est le moyen de vérifier le rattachement du motif aux faits et à la règle.

Préserver la première fonction ne commande pas de supprimer les deux autres. Sans décision structurée, une correction ou un réexamen répète simplement la conversation à un autre étage. Le demandeur doit savoir si l’échec porte sur l’architecture, l’impossibilité de réemploi, la taille demandée, la qualité de la preuve, la classification ou la version de la règle.

Un exemple multi-PoP ne crée pas un droit automatique

La présentation du projet emploie un déploiement 464XLAT multi-PoP comme cas motivant. C’est un scénario de conception, non l’audit d’un membre, un droit automatique à de nouvelles adresses ou une topologie universelle. Sa portée est plus étroite : une fonction technique peut devoir exister simultanément dans plusieurs domaines de panne avant que l’utilisation agrégée n’atteigne un seuil séquentiel.

L’architecture 464XLAT décrite dans le RFC 6877 combine une traduction avec état dans le cœur et une traduction sans état en bordure afin de fournir une connectivité IPv4 limitée sur un réseau IPv6-only. Ce RFC est Informational. Il n’impose ni quatre PoP, ni deux équipements par site, ni une taille fixe de préfixe public.

La règle commune ne devrait donc pas choisir le produit ou la topologie. Elle peut demander quelle fonction et quel domaine de panne utilisent la nouvelle ressource, pourquoi le stock actuel ne convient pas et comment le besoin a été dimensionné. L’opérateur garde le placement, le protocole de redondance et le routage.

Une spécification minimale est étroite, pas vague

La Minimum Initial Specification de Lu Heng distingue les faits déterministes qui doivent être communs pour coordonner, des décisions futures qui peuvent rester chez ceux qui exploitent le réseau.

La conservation d’un stock IPv4 fini relève bien d’AFRINIC. La vérification du besoin, l’unicité, l’exactitude du registre et l’application équitable nécessitent une règle partagée. Le fournisseur du centre de données, la plateforme NAT64, le routage interne et l’ordre du chantier ne deviennent pas pour autant des invariants du registre.

La synthèse pratique est plus courte qu’un manuel de conception et plus forte qu’un adjectif : définir les champs communs à toute décision ; laisser l’opérateur les renseigner avec les preuves adaptées ; protéger les pièces sensibles ; ne publier que la version du schéma et des agrégats respectueux de la confidentialité.

Une couche commune vague n’est pas légère. Elle oblige chaque Hostmaster et chaque demandeur à inventer sa propre spécification. Une interface minimale rend la partie commune explicite et laisse le reste local.

Le reçu d’exception en dix-huit champs

Voici l’interface minimale proposée par cet article. Elle ne décrit pas un formulaire AFRINIC existant.

  1. Identifiant de demande ou de ticket. Relier une seule demande, ses pièces, son dialogue et son résultat.
  2. Identité de la règle. Conserver la politique, le projet ou la version d’implémentation et le paragraphe appliqué.
  3. Demandeur et type de requête. Distinguer LIR et End User, allocation et affectation, première demande et demande supplémentaire.
  4. Référence ordinaire. Figer le portefeuille et le calcul exact des 90 % qui s’appliqueraient sans dérogation.
  5. Classe d’exception. Nommer redondance, haute disponibilité, transition IPv6, nouveau site ou autre objectif technique.
  6. Unités fonctionnelles. Identifier sites, PoP ou fonctions dans le dossier protégé, avec des libellés anonymisés pour toute sortie publique.
  7. Tranches demandées. Rattacher chaque préfixe ou quantité au site ou à la fonction correspondante.
  8. Fenêtre de simultanéité. Expliquer pourquoi les fonctions doivent être déployées ensemble et combien de temps les stocks coexistent.
  9. Relation d’impraticabilité. Décrire la raison topologique, de routage, de traduction ou de domaine de panne qui empêche l’usage du stock existant.
  10. Plan d’adressage. Conserver l’usage actuel et prévu de chaque tranche, son unité et son horizon.
  11. Analyse de l’espace inutilisé. Inventorier les réserves et expliquer le rejet du réemploi, de la renumérotation ou d’un autre placement.
  12. Garde des preuves. Lister fichiers, empreintes, responsable, limite d’accès et durée de conservation sans publier la topologie confidentielle.
  13. Historique du dialogue. Ajouter les questions, réponses et horodatages sans écraser le raisonnement antérieur.
  14. Classification et motifs. Consigner le caractère technique, opérationnel ou mixte avec des codes stables et une explication.
  15. Décision et conditions. Enregistrer approbation ou refus, taille accordée, conditions, échéance et réexamen.
  16. Correction et recours. Relier notification, canal de rectification factuelle, délai et voie de recours applicable.
  17. Remplacement de version. Pointer vers la règle ultérieure qui modifie le test tout en gardant celle utilisée le jour de la décision.
  18. Agrégats publics. Publier volumes, classes, plages de traitement, résultats et corrections sans identifier le membre ni son réseau.

Ces champs ne décident pas seuls si une architecture à quatre PoP est réelle. Ils rendent l’appréciation reproductible. Un second examinateur voit le même portefeuille, la même contrainte et la même question restée ouverte. Le membre corrige une erreur sans réécrire l’historique. AFRINIC peut détecter une différence inexpliquée entre classes, tailles de membres ou étapes d’examen.

Nommer ce qui reste avant d’ouvrir la dérogation

L’orientation du projet est défendable. Un second domaine de panne ne devrait pas attendre que le premier soit presque rempli : ce serait construire la redondance après l’incident. Le dossier de 2018 montre que cette séquence a déjà posé une difficulté concrète à AFRINIC.

Le projet maintient aussi une contrainte nécessaire. L’objectif technique doit être démontré, non simplement annoncé. La faiblesse n’est pas le jugement professionnel ; c’est l’absence d’une description commune de ce qui subsiste après ce jugement.

« Suffisamment documenté » peut ouvrir le dialogue. La formule ne peut être l’archive durable d’une exception portant sur une ressource rare. Avant toute mise en œuvre, AFRINIC devrait publier les champs minimaux, la règle de protection des pièces et les codes de motif. Le registre pourrait alors conserver le pool sans dessiner le réseau, et l’opérateur dessiner le réseau sans inventer sa propre norme de preuve.

Sources