Résumé

  • prop-175-v001 décrit cinq étapes possibles : recevoir un /48, déployer, revenir, fournir de nouveau des informations de planification sensiblement identiques et subir une seconde évaluation d’un besoin connu dès la première demande.
  • Le texte appliquerait la section 9.2 d’APNIC-114 à une demande initiale. Il rend expressément inapplicable le critère de l’attribution précédente et rapporte le critère de gestion d’une attribution ultérieure à l’attribution initiale proposée.
  • Le statut reste Published to Mailing List. Les sources vérifiées ne prouvent ni consensus, ni adoption, ni mise en œuvre, ni cas réel d’attribution initiale supérieure à /48.
  • Un reçu compact peut fixer les versions, l’état de la demande, le sort de chaque critère et les tailles demandée, évaluée et approuvée sans publier le plan de réseau.

Le parcours posé par prop-175-v001 compte cinq stations. Une organisation éligible reçoit d’abord une attribution IPv6 indépendante du fournisseur de /48. Elle déploie son réseau. Elle revient avec une demande ultérieure, présente une nouvelle fois des informations de planification substantiellement identiques, puis APNIC évalue une seconde fois l’espace qui, dans l’hypothèse du texte, était déjà nécessaire et documenté au premier passage.

Il ne s’agit ni d’un dossier réel rendu public, ni d’une mesure de la pratique moyenne. La proposition dit qu’un demandeur peut devoir suivre ce chemin. Elle révèle surtout une couture documentaire : la règle initiale fixe aujourd’hui /48, tandis que l’évaluation d’un besoin supérieur se trouve dans le régime des demandes ultérieures. Le besoin peut exister avant que le bon état procédural n’existe.

Au 27 août 2026, la page APNIC nomme le texte prop-175: Needs-Based Initial IPv6 PI Assignment, attribué à Rafeeun Noby Babir. La version 1 a été publiée le 19 août sur la liste du Policy SIG pour discussion. Son statut exact est Published to Mailing List; aucune version antérieure ni Secretariat impact assessment n’est indiqué. Cette chronologie ne vaut pas consensus, adoption ou fonctionnement en production.

Réemployer un cadre conçu pour l’après

La proposition ne crée pas une nouvelle catégorie de demandeur. /48 demeure la taille minimale de l’attribution initiale IPv6 PI. Les conditions existantes d’éligibilité, d’usage, d’annonce, de suivi et de récupération restent en place. Le texte ne crée pas davantage une nouvelle catégorie de ressources et ne modifie pas la politique de transfert IPv6.

Son économie tient au réemploi de la section 9.2 d’APNIC-114 lorsque le demandeur sait déjà démontrer un besoin supérieur à /48. Ce cadre examine notamment le plan d’adressage, l’existence de plusieurs réseaux discrets, l’usage d’une attribution existante au regard des annonces et de l’agrégation, ainsi que la gestion de l’espace additionnel afin de limiter la croissance de la table de routage.

Les points de présence, campus, centres de données ou implantations géographiquement réparties ne sont que des exemples. Ils peuvent illustrer le critère existant des réseaux discrets ; ils ne deviennent pas des droits d’entrée autonomes. Cette limite évite qu’un changement de moment transforme subrepticement un changement de taille en élargissement de l’éligibilité.

Le réemploi est cohérent avec une coordination mince. APNIC n’a pas besoin d’inventer une deuxième méthodologie complète parce que l’information arrive plus tôt. Le demandeur n’a pas à fabriquer une première attribution uniquement pour pouvoir répondre à une question réservée à l’étape suivante. Mais un test écrit pour l’après contient un passé. Le déplacer ne suffit pas à produire ce passé.

Un critère devient sans objet, l’autre change de référent

La proposition traite deux incompatibilités. La première est simple : lors d’une demande initiale, aucune attribution PI précédente n’existe. Le demandeur ne peut donc pas démontrer son utilisation. L’amendement prévoit que ce critère ne s’applique pas. La valeur correcte est « non applicable », et non « satisfait ». Écrire seulement que le critère a été franchi inventerait une attribution antérieure.

La seconde incompatibilité est plus subtile. La section 9.2 demande comment l’attribution ultérieure sera gérée. Or la première demande ne comporte pas d’attribution ultérieure. prop-175-v001 prévoit donc de lire ce champ comme visant l’attribution initiale proposée. Le demandeur devrait montrer comment elle limiterait les annonces mondiales, favoriserait l’agrégation et réduirait la croissance de la table IPv6.

Supprimer un test faute d’état antérieur et conserver un test en changeant son objet sont deux opérations différentes. Les autres critères resteraient inchangés. Une mention générale « évalué selon la section 9.2 » effacerait précisément la distinction que le texte cherche à rendre possible.

Élément de la section 9.2 Traitement proposé pour la demande initiale Signification probatoire
Plan justifiant un besoin supérieur à /48 Applicable Évalue le besoin documenté, pas un usage ultérieur
Plusieurs réseaux discrets Applicable Conserve le critère existant ; les exemples ne créent pas d’éligibilité
Usage de l’attribution précédente Non applicable Aucune attribution PI précédente n’existe
Gestion de l’attribution ultérieure Réinterprété Vise l’attribution initiale proposée
Autres critères Inchangés Doivent néanmoins être énumérés

Le risque est une divergence de jugement impossible à reproduire. Deux plans comparables pourraient être traités différemment si un Hostmaster laisse silencieusement vide le champ antérieur, tandis qu’un autre exige une réponse impossible, ou si chacun redirige différemment le champ relatif à l’attribution ultérieure. La perte ne se résume pas à quelques bits. Elle porte sur la possibilité d’expliquer le résultat.

La taille demandée n’est pas la taille décidée

Trois quantités doivent rester séparées : la taille demandée, celle que l’examen estime justifiée et celle qui est finalement approuvée. Aucune ne prouve à elle seule l’enregistrement effectué ou les routes ensuite annoncées. Une attribution unique plus grande peut éviter une seconde démarche dans le modèle de la proposition ; les sources ne démontrent pas qu’elle réduit nécessairement le nombre de routes ou le coût.

La même discipline vaut pour les frais. La proposition ne modifie pas le Member Fee Schedule et renvoie toute conséquence au cadre existant. Cette phrase n’établit ni neutralité tarifaire ni montant particulier. Le reçu doit indiquer la règle tarifaire consultée, puis laisser le résultat là où l’évidence s’arrête.

Le reçu minimal

APNIC peut conserver le plan détaillé dans un dossier protégé et néanmoins rendre la décision vérifiable. Un reçu destiné au demandeur, accompagné éventuellement d’une vue publique plus agrégée, devrait nommer les versions exactes d’APNIC-127 et d’APNIC-114, identifier la demande comme initiale, fixer le fondement de l’éligibilité, le minimum normal et la taille demandée.

Chaque critère de la section 9.2 devrait ensuite recevoir un état. La ligne sur l’attribution précédente porterait « non applicable au titre de l’amendement initial » avec sa raison. La ligne sur l’attribution ultérieure identifierait l’attribution initiale proposée comme objet. Les preuves peuvent être décrites par catégorie et lieu de conservation, sans exposer une topologie confidentielle.

Champ du reçu Défaillance évitée
Versions de la politique et du guide Une révision future réécrit le test historique
Identité et état initial de la demande Confusion avec une demande ultérieure
Fondement de l’éligibilité Extension implicite de ceux qui peuvent demander
Minimum et taille demandée Confusion entre plancher, plafond et droit automatique
Inventaire et sort des critères Dispense silencieuse ou réinterprétation variable
Catégories de preuve et conservation Divulgation du plan ou formule vide « preuves examinées »
Tailles demandée, évaluée, approuvée Un seul chiffre masque trois décisions
Motif de routage et d’agrégation Un objectif devient un effet prétendument observé
Référence tarifaire Une conséquence non vérifiée entre dans le dossier
Autorité, date, notification, correction Résultat sans auteur ni remède

Ce reçu ne dicte pas la topologie au Hostmaster et n’ajoute aucun comité. Il maintient la jointure entre règle, état, preuve et résultat. Si une mauvaise version est utilisée ou si « non applicable » devient « preuve absente », le demandeur dispose d’un objet précis à faire corriger.

Ce que les sources ne montrent pas

Le texte prévoit que les formulaires, le guide APNIC-114, les consignes aux Hostmasters et la documentation publique pourraient devoir évoluer. Ce sont des anticipations du proposant, pas une évaluation d’impact du Secrétariat. La page officielle affiche justement cette dernière comme indisponible.

Les sources ne donnent ni date de mise en œuvre, ni demande réelle, ni attribution initiale supérieure à /48, ni calcul de frais, ni recours, ni mesure BGP. Elles ne prouvent pas non plus que chaque demandeur actuel effectue les cinq étapes. Elles suffisent à établir un problème de portabilité des critères, pas à inventer un dommage de production.

Sources