Résumé

  • La RFC 9083 rattache le tableau notices au service RDAP ou à l’ensemble de la réponse, et non au réseau IP, à l’ASN ou à l’organisation consultée.
  • Les avis actuellement servis par ARIN renvoient à ses conditions d’utilisation et à son mécanisme de signalement des inexactitudes. Ils n’exposent pas la politique d’interconnexion, de transit ou de filtrage du titulaire.
  • Une analyse reproductible conserve séparément l’empreinte des avis et celle de l’objet d’enregistrement, puis mobilise des données BGP ou des déclarations d’opérateur pour toute conclusion opérationnelle.

Un message du guichet

Une réponse RDAP d’ARIN peut afficher, au niveau supérieur, des avis intitulés « Terms of Service », « Whois Inaccuracy Reporting » et « Copyright Notice ». Le premier contient un lien vers les conditions Whois d’ARIN avec la relation terms-of-service; le deuxième renvoie vers la procédure de signalement avec la relation inaccuracy-report.

La RFC 9083 tranche leur portée. Les avis renseignent sur le service qui fournit les données RDAP ou sur la réponse entière. Les remarks, en revanche, concernent la classe d’objet qui les contient. La norme précise aussi que les avis n’apparaissent qu’au sommet de la réponse. Déplacer un avis dans une fiche réseau comme s’il s’agissait d’un attribut de l’objet altère donc le sens des données.

Le vocabulaire opérationnel des conditions d’utilisation ne change rien à cette attribution. ARIN parle en tant qu’opérateur du registre. Le lecteur accepte des règles relatives à la consultation et à la réutilisation des données. L’organisation associée au bloc d’adresses n’est pas, par cette seule présence, l’auteur de l’avis.

Des conditions pour l’utilisateur des données

Les conditions Whois d’ARIN encadrent l’accès au service, les usages admis, certaines restrictions de redistribution, les garanties, la responsabilité et le règlement des différends. Pour un chercheur, ce contexte est essentiel : il accompagne la collecte et peut limiter la manière de partager un jeu de données dérivé.

Il ne s’agit cependant pas de la politique d’exploitation du réseau enregistré. Les achats de transit, les critères de peering, les filtres de préfixes, la sécurité du routage, les règles d’acceptation des clients et la réponse aux incidents relèvent d’autres acteurs et d’autres preuves. Le lien terms-of-service ne démontre ni qu’une route est acceptée, ni qu’un opérateur transporte le trafic d’un tiers.

Il faut donc distinguer trois rôles : ARIN administre le service; le demandeur utilise les données sous certaines conditions; l’objet RDAP décrit des informations de registre. Même si une même entreprise intervient ailleurs dans plusieurs rôles, l’avis ne prouve pas cette réunion.

Un canal de correction n’est pas un constat d’erreur

Le lien de signalement pose un autre risque d’interprétation. ARIN l’insère dans les réponses ordinaires afin que tout lecteur puisse indiquer une anomalie présumée. Sa documentation distingue la correction de son propre dossier du signalement concernant le dossier d’autrui; dans ce dernier cas, le personnel d’ARIN examine la demande et agit si l’inexactitude est confirmée.

La présence générique du lien ne signifie donc ni qu’un signalement existe, ni que le dossier affiché est faux. C’est une fonction du service, comparable à un lien « signaler une erreur » présent sur toutes les pages. L’utiliser comme indice défavorable contre l’organisation consultée fabriquerait un événement absent de la source.

Lorsqu’une divergence est réelle, la bonne méthode consiste à conserver la requête, la réponse, le champ contesté et la source de comparaison. Une conclusion ultérieure doit s’appuyer sur la réponse d’ARIN au cas précis ou sur une donnée corrigée.

Deux empreintes pour une même réponse

Une capture défendable sépare l’objet et les avis. Pour les avis, elle enregistre l’ordre, le titre, les chaînes de description, la cible du lien, sa relation et son type de média. Elle ajoute l’URL de requête, l’heure de collecte et la date d’effet visible sur les pages liées.

Cette séparation évite les fausses alertes. L’année du copyright peut changer sans modification du réseau. ARIN peut réviser les conditions du service sans action du titulaire. À l’inverse, un objet d’enregistrement peut évoluer alors que les avis restent identiques. Les deux couches coexistent dans le même JSON, mais elles n’ont ni le même propriétaire ni le même mécanisme de changement.

La limite du routage

La RFC 4271 définit une route BGP par des destinations associées à des attributs de chemin et propagées entre locuteurs BGP au moyen de messages UPDATE. Aucun avis RDAP ne contient cet état. Il ne montre ni annonce, ni retrait, ni chemin d’AS, ni sélection de route, ni circulation de paquets.

RDAP reste utile pour situer un bloc ou un ASN dans le registre. Mais une affirmation sur le routage en direct exige des observations contemporaines, et une affirmation sur le transit commercial exige un contrat ou une déclaration fiable des parties. Le contexte du service ne peut emprunter l’autorité de ces sources absentes.

Sources et autorité

La distinction protocolaire figure dans la RFC 9083, section 4.3 : https://www.rfc-editor.org/rfc/rfc9083.html#section-4.3 . La réponse ARIN examinée est https://rdap.arin.net/registry/ip/8.8.8.8 . Les conditions sont publiées à https://www.arin.net/resources/registry/whois/tou/ et la procédure de rectification à https://www.arin.net/resources/registry/whois/inaccuracy_reporting/ . La comparaison BGP repose sur la RFC 4271, section 3.1 : https://www.rfc-editor.org/rfc/rfc4271.html#section-3.1 .