Résumé
AFPUB-2026-IPv4-003-DRAFT01ferait de la provenance historique d’un espace récupéré une règle d’orientation de l’inventaire IPv4 rare. Tout bloc passerait d’abord par leRecovered Pool, puis serait renvoyé vers la catégorie de son pool source. En cas d’incertitude raisonnable non levée, le défaut serait lePre-Softlanding Pool.Cette classification ne serait pas une simple annotation. Le pool de destination déterminerait les conditions de délégation susceptibles de s’appliquer ensuite, influencerait les soldes publiés et pourrait peser sur le report d’une demande, le moment d’un épuisement, l’alimentation d’une future liste d’attente et une restriction de transfert volontaire de 24 mois.
La preuve minimale devrait être un reçu public, respectueux de la confidentialité, reliant l’événement de récupération, les classes de preuves examinées, le résultat de certitude, la décision sur les blocs partiels, le pool de destination et les soldes avant et après. Des totaux mensuels ne suffisent pas à reproduire une classification particulière.
Le projet reste
Under Discussion. Les sources vérifiées n’établissent ni consensus, ni ratification, ni mise en œuvre, ni inventaire réel à quatre pools, ni bloc déjà classé. L’enjeu est de définir la trace probante requise si la règle devait devenir opérationnelle, non de juger une pratique existante.
Un passage temporaire qui décide de la suite
Le texte de la proposition modifierait la section 5.4 du CPM et distinguerait quatre catégories : Soft-Landing Pool, Policy-Reserved Pool, Pre-Softlanding Pool et Recovered Pool. Chacune devrait être suivie séparément, avec des mouvements auditables et publiquement rapportables.
Le Recovered Pool n’est pas présenté comme une destination ordinaire. Il reçoit temporairement les adresses IPv4 retournées, révoquées, récupérées ou reprises d’une autre manière par AFRINIC. Le personnel devrait ensuite retracer la catégorie du pool source et y renvoyer l’espace.
Cette règle donne à la provenance un effet opérationnel. Elle ne sert pas seulement à raconter d’où vient le bloc. Elle oriente l’inventaire vers un pool dont les conditions ultérieures peuvent différer. Le classement devient donc une décision sur l’application future de la politique.
La catégorie source ne doit pas être assimilée à un titre juridique. Dans le projet, elle fonctionne comme une propriété historique de l’inventaire : le contexte administratif dans lequel le bloc avait été prélevé ou affecté avant sa récupération. La preuve nécessaire porte sur cette lignée, non sur une prétention de propriété.
Le statut impose le conditionnel
La page des propositions en cours présente AFPUB-2026-IPv4-003-DRAFT01, intitulée « Dynamic IPv4 Pools Exhaustion Management Framework », comme Under Discussion. Il s’agit de la version 1.0, soumise le 8 juin 2026.
Aucune des deux sources ne prouve un consensus, une ratification ou une mise en œuvre. Elles ne montrent pas davantage un solde réel, une classification accomplie, un report de demande, une liste d’attente active, un transfert ou un litige de provenance.
L’analyse doit donc tester l’architecture probante du projet. Elle ne peut attribuer à AFRINIC aucun événement opérationnel que le dossier ne contient pas. Le bloc d’ouverture est l’objet abstrait de la règle proposée, non un préfixe réellement traité.
La règle de provenance en quatre opérations
Le chemin proposé peut être décomposé sans l’élargir à toute la politique IPv4.
- Un espace récupéré entre dans le
Recovered Pool. - AFRINIC recherche la catégorie du pool dont cet espace provenait.
- La partie dont l’origine est traçable est renvoyée vers cette catégorie, proportionnellement s’il s’agit d’un bloc partiel.
- Si l’origine ne peut être établie avec une certitude raisonnable, la partie concernée va par défaut au
Pre-Softlanding Pool.
Chaque classification devrait être documentée et annoncée publiquement. Mais une annonce peut nommer un volume et une destination sans montrer les preuves admises, la répartition d’un bloc partiel ni la réconciliation avec les soldes avant et après.
« Certitude raisonnable » doit produire un résultat reproductible
Le défaut vers le Pre-Softlanding Pool a une vertu apparente : l’incertitude ne suspend pas indéfiniment le traitement. Mais sa légitimité opérationnelle dépend de la manière dont l’incertitude est établie et consignée.
Une formule comme « origine non retrouvée » est trop pauvre. Elle ne permet pas de distinguer une archive absente, une référence contradictoire, une chaîne interrompue, une correspondance seulement partielle ou une preuve datée mais insuffisamment précise.
Le reçu n’a pas besoin de publier des dossiers confidentiels. Il doit néanmoins indiquer les classes de preuves examinées, leurs dates, le résultat de la comparaison et la raison pour laquelle elles atteignent — ou n’atteignent pas — le seuil de certitude raisonnable.
Le cas difficile du bloc partiel
La classification proportionnelle est le point où une simple provenance narrative devient une opération d’inventaire. Un préfixe récupéré peut contenir des plages dont la lignée est traçable différemment. Le volume total ne suffit alors plus.
Le reçu doit montrer la correspondance entre préfixes ou plages et catégories sources. Sans cette table, une annonce pourrait déclarer qu’une fraction va au Policy-Reserved Pool et une autre au Pre-Softlanding Pool, sans permettre de vérifier que les fractions couvrent exactement l’espace traité.
Trois contrôles deviennent nécessaires : absence de chevauchement, absence de trou inexpliqué et égalité entre le volume récupéré et la somme des volumes classés. Le défaut d’incertitude doit s’appliquer à la partie non prouvée, non effacer la provenance démontrée du reste.
| Segment traité | Origine revendiquée | Niveau de preuve | Destination proposée | Contrôle de volume |
|---|---|---|---|---|
| Partie A | Catégorie source traçable | Certitude raisonnable atteinte | Pool source correspondant | Préfixe ou plage bornée |
| Partie B | Catégorie source différente | Certitude raisonnable atteinte | Autre pool correspondant | Sans chevauchement avec A |
| Partie C | Origine indéterminée | Seuil non atteint, motif publié | Pre-Softlanding Pool |
Solde exact du bloc récupéré |
Ce tableau est un modèle de preuve, non la description d’un cas réel. Aucun bloc partiel effectivement classé n’est établi par les sources.
Le reçu public minimal
Le bon objet n’est ni un long rapport narratif ni un simple total mensuel. C’est un reçu compact, attribuable à un événement, capable de rejoindre l’inventaire publié sans exposer ce qui doit rester confidentiel.
| Champ du reçu | Contenu nécessaire | Question vérifiée |
|---|---|---|
| Version et statut | AFPUB-2026-IPv4-003-DRAFT01, version applicable, statut au jour de la décision |
Sous quelle règle le classement est-il effectué ? |
| Événement de récupération | Type d’événement, référence publique possible, date d’effet | Quel événement fait entrer l’espace dans le Recovered Pool ? |
| Préfixe et volume | Préfixe, plage ou représentation équivalente ; nombre d’adresses | Quel inventaire est traité ? |
| Référence antérieure | Référence de délégation ou d’affectation antérieure, publiée de façon compatible avec la confidentialité | Quelle lignée est recherchée ? |
| Catégorie source revendiquée | Pool source proposé pour chaque partie | Quelle destination historique est alléguée ? |
| Classes de preuves et dates | Types de documents ou enregistrements examinés, périodes couvertes | Sur quoi repose l’analyse ? |
| Résultat de certitude | Atteint, non atteint ou partiel, avec motif | Pourquoi la règle ordinaire ou le défaut s’applique-t-il ? |
| Correspondance partielle | Préfixes ou plages reliés à chaque résultat | Comment le bloc est-il réparti ? |
| Pool de destination | Catégorie finale pour chaque partie | Quel solde doit changer ? |
| Décideur et horodatage | Fonction organisationnelle, date et heure de décision | Qui assume la décision et quand ? |
| Annonce publique | Référence stable vers l’avis | Où le mouvement est-il déclaré ? |
| Soldes avant et après | Solde de chaque pool touché, même unité et même instant de clôture | Le mouvement se réconcilie-t-il ? |
| Restriction en aval | Régime susceptible de suivre la future délégation | Quelle conséquence doit rester attachée à l’origine ? |
| Contestation et correction | Délai, canal, état et version corrigée | Comment une erreur alléguée est-elle traitée sans effacer l’original ? |
La réconciliation avant et après est la charnière
Une classification ne devient opérationnellement significative qu’au moment où elle modifie les soldes. Le reçu doit donc fermer deux mouvements : l’entrée dans le Recovered Pool, puis la sortie vers le ou les pools de destination.
Pour un bloc intégralement traçable, le volume ajouté temporairement au Recovered Pool devrait correspondre au volume retiré lors de la classification. Le pool source retenu devrait augmenter du même volume, sous réserve d’une représentation cohérente des unités.
Pour un bloc partiel, la somme des sorties vers les différents pools devrait égaler le volume retiré du Recovered Pool. Une part placée par défaut dans le Pre-Softlanding Pool devrait être identifiable comme le résidu dont la provenance n’a pas atteint la certitude raisonnable.
Des soldes agrégés peuvent être exacts tout en masquant l’événement. Si plusieurs mouvements sont regroupés, le lecteur ne sait pas quel classement explique quelle variation. Le reçu événementiel permet de sommer les mouvements et de rejoindre le rapport mensuel.
Pourquoi le pool de destination compte en aval
Le Pre-Softlanding Pool aurait normalement un maximum de /18, un minimum de /24, une justification sur douze mois et 80 % d’utilisation antérieure. Une extension jusqu’à /16 serait possible sous preuves supplémentaires.
Une demande impossible à satisfaire dans ce pool serait automatiquement reportée vers le Soft-Landing Pool, avec trace et notification du demandeur. Le volume attribué au Pre-Softlanding Pool peut donc affecter le moment où une demande est satisfaite ici, reportée là ou confrontée à un solde insuffisant.
Lorsque les deux pools principaux atteindraient zéro, le projet prévoit des délégations par une liste d’attente post-épuisement alimentée uniquement par le Recovered Pool. Le moment déclaré de cet épuisement dépendrait des mouvements correctement réconciliés.
Le projet prévoit aussi une restriction de transfert volontaire de 24 mois pour les délégations issues du Pre-Softlanding Pool, puis de la liste d’attente, hors fusions, acquisitions et reprises. La provenance de l’espace délégué devrait donc rester attachée à la délégation future.
Une provenance perdue peut changer la règle sans aucune malveillance
Il suffit d’une lignée incomplète. Une référence antérieure peut couvrir un agrégat plus large que le bloc récupéré. Une réécriture peut conserver le volume mais perdre la catégorie source. Un rapprochement peut être possible pour une partie seulement.
Dans chacun de ces cas, le défaut vers le Pre-Softlanding Pool peut être appliqué conformément au projet, mais produire un résultat différent de celui qu’aurait donné une provenance complète. La question est alors de rendre visible l’incertitude qui a orienté le bloc.
Aucune manipulation n’est nécessaire. La fragmentation documentaire, les changements de format ou des agrégats publiés sans événements suffisent à rendre la classification impossible à reproduire. Le risque vient de la perte de lignée, non d’une intention supposée.
Les rapports mensuels ne remplacent pas les reçus
Le projet envisage des rapports mensuels couvrant la longueur de la file, les adresses disponibles, l’attente moyenne et l’espace récupéré traité. Ces indicateurs éclaireraient l’état général du mécanisme s’il était adopté.
Ils ne répondent toutefois pas à la question de provenance. Un total d’espace traité ne montre pas quelles parts ont été renvoyées vers quel pool, quel seuil de certitude a été appliqué ni quelles corrections ont modifié les soldes.
Le rapport mensuel devrait donc être la somme vérifiable des reçus, et non une source concurrente. Les totaux doivent se réconcilier avec les événements individuels, tandis que les événements doivent renvoyer à la période de rapport où leurs effets apparaissent.
Contestation, correction et conservation de l’original
Une classification peut être contestée sans qu’un litige réel soit établi aujourd’hui. Le projet gagnerait à prévoir le traitement d’une preuve apparue après l’annonce, d’une erreur de volume ou d’une correspondance partielle révisée.
La correction ne devrait pas écraser le reçu initial. Elle devrait créer une nouvelle version, expliquer le motif, montrer les soldes corrigés et indiquer si une conséquence en aval a déjà été déclenchée.
Les estimations de durée restent des affirmations d’auteur
Le texte avance des estimations concernant la durée des pools, le volume récupéré et des demandes successives. Les éléments vérifiés ne comprennent pas les données de calcul sous-jacentes.
Le test décisif
Avant qu’une classification ne modifie un solde, quatre réponses devraient être publiques : quel espace a été récupéré, quelle provenance a été retenue, pourquoi le seuil de certitude a été atteint ou non, et comment les soldes se réconcilient.
Pour un bloc partiel, une cinquième réponse s’ajoute : quelles plages exactes suivent chaque lignée. Pour une correction, une sixième devient nécessaire : quelle version remplace la précédente sans l’effacer.
La proposition fait de la provenance une règle d’orientation. Sa solidité dépendra moins de l’existence abstraite de quatre pools que de la capacité à prouver chaque passage entre eux. Le reçu est l’unité minimale de cette preuve.
Sources
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
