Résumé

  • prop-167-v002 demandait deux produits : des statistiques publiques horaires sur WHOIS/RDAP et une vue MyAPNIC des requêtes visant les ressources de chaque titulaire.
  • La Résolution 2025-32 a approuvé la publication publique. Elle a jugé la fonction MyAPNIC non réalisable à ce moment-là, au regard du coût, des ressources nécessaires et de préoccupations potentielles de confidentialité.
  • La première branche est effectivement en service : les archives commencent le 30 juin 2026 et le JSON courant contient des données séparées pour RDAP et WHOIS.
  • Le statut unique Implemented peut être exact pour le périmètre approuvé tout en restant incomplet comme mémoire de la proposition communautaire. Il lui manque une projection par sortie.

APNIC ne demande pas au lecteur de croire sur parole à l’aboutissement de la première branche. Son répertoire public livre un fichier JSON courant, une somme de contrôle et des archives annuelles. Le dossier de juin 2026 commence le 30 juin et présente des fichiers horaires de 03 h à 23 h. L’objet courant distingue RDAP et WHOIS, précise une fenêtre d’une heure et distribue les requêtes par type et par ASN.

L’artefact rejoint la date institutionnelle. La page canonique de prop-167 inscrit 30 June 2026 | Implementation Complete et affiche Implemented comme état actuel. Pour la publication agrégée, le passage de la décision au produit est donc visible.

Mais le texte arrivé au consensus contenait deux résultats attendus, pas un seul. Les minutes du Conseil exécutif les ont séparés :

Sortie Décision de l’EC le 4 décembre 2025 État public vérifiable en août 2026
Statistiques publiques, horaires et lisibles par machine sur WHOIS/RDAP Approuvées par la Résolution 2025-32 JSON courant et fichiers horaires archivés
Consultation, dans MyAPNIC, des requêtes visant les ressources du titulaire Fonction jugée non réalisable à ce moment-là pour les motifs publiés Aucun document vérifié n’établit une décision ultérieure ou sa mise en œuvre

La deuxième ligne ne contredit pas la première. Elle ne prouve pas non plus un échec dissimulé. Elle constitue une décision explicite, datée et limitée. C’est précisément ce détail que le statut au niveau de la proposition ne conserve pas.

Deux visibilités, deux surfaces techniques

Publié le 21 août 2025, prop-167-v002 avançait deux chiffres. D’après les données internes citées par ses auteurs, APNIC aurait répondu à environ 5,5 milliards de requêtes de répertoire entre le 1er avril et le 30 juin 2025 ; certaines heures auraient amené plus de 365 000 adresses IP distinctes sur RDAP. Ces nombres appartiennent à la proposition et à la provenance interne qu’elle mentionne. Ils ne constituent ni une mesure reproduite ici ni l’identification d’un usage abusif.

La première réponse proposée était collective. APNIC publierait chaque heure le volume de requêtes WHOIS et RDAP, au format JSON ou CSV, avec le service, le type et la méthode de requête. Les données devaient aussi présenter au moins les mille premiers ASN sources et le nombre d’adresses IP sources par ASN.

La seconde réponse était individuelle et authentifiée. Dans MyAPNIC, un titulaire pourrait voir combien de fois ses propres adresses ou ASN avaient été interrogés, ventilés par type et, si possible, par ASN source. Cette fonction devait unir le compte, les ressources détenues et des événements de requête plus fins que le fichier public.

L’étude d’impact rendait la différence opérationnelle. Pour le flux public, elle évoquait une méthode d’extraction et de publication, offerte en best-effort et sans SLA. Pour l’amendement MyAPNIC, elle signalait, si la fonction était possible, un volume important de travaux de journalisation dans les systèmes WHOIS sous-jacents.

Le consensus atteint le 11 septembre 2025 à APNIC 60 portait donc sur un texte à deux produits. La période de derniers commentaires s’est achevée le 14 octobre. Cette étape fixe le contenu communautaire ; elle ne supprime pas l’étape d’approbation prévue par APNIC.

L’approbation n’a pas été une formalité globale

Le Policy Development Process place l’EC entre le consensus maintenu et l’exécution par le Secrétariat. Il serait donc inexact d’affirmer que le consensus rendait les deux produits automatiquement exécutoires ou que l’EC n’avait aucun rôle de périmètre.

La Résolution 2025-32 a approuvé l’adoption de v002 « with respect to » la publication de statistiques en temps réel ou quasi réel sur les services de répertoire. Elle a ensuite cité la fonction MyAPNIC et indiqué que son coût, les ressources nécessaires et les préoccupations potentielles de confidentialité l’emportaient sur le bénéfice immédiat. L’EC ne la considérait pas réalisable à ce moment-là. La résolution a été adoptée à l’unanimité.

Chaque fragment borne l’interprétation. With respect to désigne la partie approuvée. Les trois motifs sont ceux de l’EC ; aucun élément fourni ne permet de les réduire à un prétexte. At this time attache la conclusion au 4 décembre 2025 : ce n’est ni une promesse de retour ni une interdiction définitive.

Cette précision protège les différentes autorités. La communauté conserve le texte débattu. L’EC conserve sa décision de faisabilité. Le Secrétariat reçoit un périmètre exécutable. Une page de suivi devrait projeter ces trois états, non les fondre rétroactivement.

Les fichiers ferment la branche publique

Lors d’APNIC 61, l’équipe présentait prop-167 comme en cours d’implémentation, avec une échéance à la fin du deuxième trimestre. La description retenait la mise à disposition de statistiques de répertoire dans un format lisible par machine. Les données actuelles de la Product Roadmap rattachent encore le travail aux exigences approuvées.

Les fichiers vont plus loin qu’une feuille de route. La date d’archive relie le 30 juin à une production horaire. Le JSON courant donne un objet RDAP et un objet WHOIS, chacun avec une période, des totaux, une distribution par type et des enregistrements d’ASN. C’est un résultat observable, pas une intention.

Cette observation reste bornée. Elle ne garantit pas l’absence de trous horaires, la stabilité future du schéma ou la satisfaction de toute lecture possible de v002. Elle ne transforme pas une publication best-effort en engagement de service. Elle ne permet pas non plus de recalculer le total historique de 5,5 milliards.

Elle suffit en revanche pour exclure une thèse erronée : la statistique publique ne manque pas. La question actuelle est celle de la mémoire de son périmètre.

Un résumé peut être juste et pourtant perdre l’histoire

La page de proposition rassemble la version, l’étude d’impact, un événement Endorsed by the EC, puis l’achèvement. Or la ligne d’approbation ne précise pas qu’elle portait sur la publication publique, tandis que l’autre sortie recevait une conclusion différente. Le lecteur doit ouvrir les minutes, trouver la résolution et chercher ensuite l’artefact FTP.

Le mot Implemented n’est pas forcément faux. S’il signifie « le périmètre approuvé par l’EC a été mis en œuvre », les fichiers le confirment. Il devient ambigu lorsqu’il est lu comme « tout le texte ayant obtenu le consensus est en production ». La page ne dit pas quel sens elle dérive.

Une proposition possède un identifiant unique ; ses dispositions peuvent avoir plusieurs destins. Ce problème de cardinalité apparaît dès qu’un organe approuve une partie, diffère une autre ou impose des conditions différentes. Le statut global peut rester utile pour la navigation, à condition de ne pas remplacer les états élémentaires.

La terminologie de la seconde sortie doit également rester neutre. Failed exagérerait. Abandoned effacerait le bornage temporel. La source permet seulement : non approuvée le 4 décembre 2025, non réalisable à ce moment-là pour les motifs publiés, réexamen ultérieur non établi par les documents vérifiés.

Une trace de périmètre, pas un nouveau droit aux données

Conserver cette distinction ne commande pas de construire la fonction MyAPNIC. Cela ne donne à personne un droit d’obtenir les journaux individuels, les adresses sources ou la vue privée d’un titulaire. La solution documentaire respecte les enjeux de confidentialité au lieu de les contourner.

Sous l’historique existant, APNIC pourrait afficher une ligne par sortie. Chaque ligne lierait la version exacte et le passage source au consensus, à la résolution de l’EC et à son disposition. Pour une sortie approuvée, elle pointerait vers l’artefact, le format et la première date vérifiée. Pour l’autre, elle conserverait la raison datée et tout déclencheur ultérieur de réexamen.

Élément Ce qu’il empêche de confondre
Version et empreinte du texte La proposition débattue et une version ultérieure
Identifiant de sortie Le statut de la proposition et la décision sur une disposition
Consensus et fin des commentaires L’état communautaire et l’autorité de mise en œuvre
Résolution et disposition de l’EC L’approbation globale supposée et le périmètre réel
Artefact, schéma et début vérifié L’annonce et le produit en service
État daté de la sortie non approuvée Le report, le remplacement et l’abandon définitif
Correction ou succession Une nouvelle décision et la réécriture de l’ancienne
Règle de statut global Le sens exact de Implemented

Cette projection n’est pas un second PDP. Elle rend visible ce que le PDP existant a déjà décidé. Les analyses internes, tests d’acceptation et détails de sécurité peuvent rester protégés.

Les inconnues doivent conserver leur nom

Rien dans le corpus vérifié ne montre qu’APNIC a ensuite trouvé une architecture MyAPNIC moins coûteuse ou plus protectrice. Rien n’établit non plus l’absence de travaux privés. Une mise à jour générique du portail ne suffirait pas à prouver la fonction précise demandée par v002.

Aucun cas fourni ne montre un titulaire lésé, une fuite provoquée par le flux, une violation de SLA ou un incident de sécurité. Les hypothèses de data mining ou de collecte massive appartiennent au raisonnement de la proposition ; elles ne constituent pas une accusation contre un ASN.

Enfin, les documents ne définissent pas la convention APNIC pour le statut global après une approbation partielle. Si Implemented désigne habituellement le périmètre approuvé, la proposition faite ici ne le conteste pas. Elle demande simplement d’en publier la dérivation.

La publication horaire mérite d’être reconnue comme une mise en œuvre réelle. La fonction MyAPNIC mérite d’être reconnue comme une disposition arrêtée plus tôt, selon une décision précise. La bonne mémoire institutionnelle permet à ces deux affirmations de coexister.

Sources