Résumé

  • La version 1 de prop-173 créerait une politique distincte pour les consultations ordinaires, affichée dans WHOIS, RDAP et les interfaces Web. Elle reste au stade de la discussion sur la liste Policy SIG.
  • Le document central aurait une version, une date d’effet, un historique et des archives, mais la réponse ne serait tenue d’indiquer que l’adresse de la politique actuelle. Il manque un reçu très court reliant le résultat à la version exacte des règles.

Clarifier le contrat ordinaire est une bonne idée

Une recherche ponctuelle n’est pas un miroir de base de données. C’est le mérite initial du texte : APNIC dispose déjà d’un accord pour l’accès Whois en masse, alors qu’un opérateur, un chercheur ou une équipe de sécurité qui interroge un objet isolé ne sait pas toujours quelles règles encadrent la conservation, la combinaison ou la republication du résultat. Utiliser le contrat du vrac comme réponse implicite à toutes les situations crée plus d’ambiguïté qu’il n’en résout.

La fiche officielle de prop-173 indique que la version 1 a été publiée sur la liste du Policy SIG le 17 août 2026. Son statut est « Published to Mailing List ». Dans le dossier examiné, il n’y a ni étude d’impact du Secrétariat, ni constat de consensus, ni adoption, ni avis de mise en œuvre. Le conditionnel n’est donc pas une précaution de style : c’est l’état institutionnel du texte.

Le projet de version 1 couvrirait les personnes et les systèmes qui accèdent aux données faisant autorité chez APNIC par WHOIS, RDAP, recherche Web ou API équivalente. Les données renvoyées vers un autre registre resteraient soumises à la source qui fait autorité. Les téléchargements importants, les miroirs et les bases de substitution resteraient soumis au régime d’accès en masse.

Cette architecture défend à la fois l’utilité et la retenue. Le texte autoriserait les usages opérationnels à faible volume, le dépannage, l’étude des politiques de routage, le traitement des abus et la recherche technique. Il viserait notamment la prospection, les listes commerciales, la collecte systématique, le contournement des limites et la revente de la donnée comme produit autonome. Il prévoirait aussi une voie de réexamen pour l’utilisateur qui estime avoir été bloqué par erreur.

La politique répond ainsi à une question légitime : quel comportement APNIC accepte-t-elle lorsqu’une requête ordinaire devient une accumulation ? Le problème étudié ici vient après cette réponse. Une règle peut être parfaitement claire aujourd’hui et néanmoins devenir impossible à rattacher demain au résultat qu’elle encadrait hier.

Deux horloges qui ne se rejoignent pas

La section consacrée aux avis prévoit un message dans chaque interface. WHOIS dirait que les données du service d’annuaire sont soumises à la politique et que la requête ou l’usage vaut acceptation. RDAP contiendrait un avis identifiant la politique, un lien de relation terms-of-service, une mention de propriété intellectuelle et l’adresse de la politique courante. L’interface Web afficherait également le lien avant ou au moment de fournir les données.

Le projet impose ensuite une adresse HTTPS stable, maintenue et sans redirection. Plus loin, il exige que la politique elle-même porte un numéro de version, une date d’effet, un historique des révisions et les versions antérieures. Les modifications devraient faire l’objet d’un préavis public raisonnable ; un changement matériel affaiblissant les protections devrait repasser par la consultation communautaire.

Ce dispositif mérite d’être défendu. Une seule page maintenable évite de recopier de longues clauses dans des protocoles différents. L’historique rend visibles les modifications. L’adresse stable diminue le risque de liens morts et la notification préalable réduit la surprise. Un reçu de version doit compléter ces garanties, non les remplacer.

Car le temps de la réponse et celui du document restent séparés. La liste des champs demandés pour WHOIS et RDAP ne comprend ni numéro de version applicable, ni date d’effet, ni empreinte du contenu. Elle comprend « l’adresse de la politique courante ». Une réponse archivée avant une modification continuera donc d’ouvrir une page qui présente éventuellement le texte nouveau.

On pourra parfois reconstruire la situation. Si le client a conservé une heure fiable et si les archives délimitent exactement les périodes, il sera possible de retrouver la version probable. Mais cette preuve vient alors d’un journal extérieur à la réponse. Le résultat n’est pas faux ; il est dépourvu de la clé qui le relie au texte invoqué lors de sa production.

Le témoin RDAP actuel est utile mais limité

La réponse RDAP d’APNIC pour 1.1.1.1, capturée pour cette analyse, contient déjà un avis « Terms and Conditions » et un lien dont la relation est terms-of-service. Elle comporte aussi un avis sur la source et un lien vers le signalement des inexactitudes. Elle ne donne pas de version de la politique, de date d’effet de celle-ci ni d’empreinte du document.

Ce témoin ne prouve pas que prop-173 est appliquée. Il ne décrit pas non plus toutes les réponses, tous les serveurs ou l’interface WHOIS. Il montre seulement une distinction concrète : la structure peut transporter une destination de conditions sans transporter l’identité temporelle des conditions.

La norme le permet. RFC 9083 définit les avis RDAP comme des informations portant sur le service ou la réponse entière. Leur description est obligatoire et ils peuvent contenir des liens. APNIC dispose donc d’un emplacement technique pour un reçu léger, même si la norme n’impose aucun champ propre à sa politique. Respecter RDAP ne résout pas automatiquement la gouvernance des versions.

Ni registre de droits ni jugement juridique

L’accord d’accès en masse limite la reproduction, le stockage, la transmission et la remise en masse à des tiers. Il explique pourquoi une condition d’usage peut compter longtemps après la requête. Il n’est pourtant pas la bonne réponse pour l’utilisateur ordinaire, précisément parce que prop-173 veut séparer ces deux situations.

Un reçu de conditions ne serait pas non plus un registre des droits. Il ne dirait pas qui détient un droit sur chaque valeur, si une donnée a été fournie par un membre ou copiée d’un autre registre, ni si une clause est juridiquement valable. Il répondrait à une seule question probatoire : quel texte le service disait-il applicable à cette réponse ?

La déclaration de confidentialité d’APNIC rappelle que les services Whois et RDAP s’inscrivent dans un traitement de données de registre et de contacts. Associer une version ne rend pas un usage légitime. Cela évite seulement que la règle invoquée se déplace pendant que le résultat conservé reste immobile.

Le processus d’élaboration des politiques repose sur la discussion ouverte et le consensus. Le bon moment pour ajouter cette jonction est donc maintenant, tant que le texte est une proposition. Il n’est pas nécessaire de contester son objectif ni de transformer une amélioration précise en procès du système entier.

La limite des preuves

Aucun document examiné ne montre un utilisateur sanctionné sous la mauvaise version. Aucun ne prouve une modification cachée, une panne, une perte de routage ou un litige. APNIC peut disposer d’excellents journaux internes et d’une procédure de déploiement capable de reconstituer l’état exact. L’observation publique est plus modeste : la proposition n’exige pas que cette preuve accompagne la réponse.

Sources

Cette analyse s’appuie sur la fiche de prop-173, le texte de la version 1, l’accord Whois en masse, le témoin RDAP, la déclaration de confidentialité, le processus de politique et RFC 9083. Ces sources décrivent un projet et une forme de réponse, pas un litige lié à une règle mise en œuvre.