Résumé

  • Un Internet-Draft individuel daté du 29 octobre propose six chemins RDAP pour les données de l’Internet Routing Registry ; trois types de SET et les champs de politique restent facultatifs.
  • La réponse d’aide RDAP publiée en direct par RIPE NCC n’annonce pas irr0, l’identifiant de l’extension. Pour quitter Whois, les opérateurs ont besoin d’une preuve de couverture serveur par serveur.

Le panneau de sortie porte un astérisque

À RIPE 93, un opérateur a présenté la prise en charge des objets de routage des RIR comme la dernière fonction qui lui manquait avant de ranger Whois. C’est une lourde attente pour six nouveaux noms de chemin.

Le 29 octobre, Datatracker a publié draft-aggarwal-regext-rdap-irr-00. Mahesh Aggarwal, de RIPE NCC, et Jasdip Singh, d’ARIN, figurent parmi les quatre auteurs. Le texte propose d’accéder aux données de l’Internet Routing Registry (IRR) par RDAP : du JSON structuré sur HTTPS, à côté des données d’enregistrement déjà servies par RDAP.

La proposition est précise. Elle nomme six chemins : irr0_route, irr0_routeSet, irr0_autnumSet, irr0_rtrSet, irr0_peeringSet et irr0_filterSet. Une requête de route associe un préfixe et un ASN d’origine. Les objets SET peuvent exposer leurs membres sous forme de tableau. Une réponse autnum peut inclure, dans l’ordre, des politiques d’import et d’export, y compris des formes multiprotocole et import-via ou export-via.

La réserve est dans le même texte. La prise en charge de peering-set, rtr-set et filter-set est facultative, au choix de l’implémentation. Le membre irr0_policies l’est aussi. Un client peut donc maîtriser le nouveau vocabulaire et découvrir qu’un serveur ne répond pas pour l’objet dont son filtre a besoin. Six chemins sur papier ne font pas six portes en service.

Cette différence compte, car un IRR n’est pas seulement un écran de recherche. ARIN indique que son IRR est séparé de ses données Whois publiques. Les détenteurs de ressources y soumettent des objets RPSL ; d’autres IRR les récupèrent pour les décisions de routage de leurs réseaux. ARIN propose NRTM, des fichiers téléchargeables et Whois sur le port 43. Pour son propre flux NRTM, ARIN parle d’objets « autorisés » et décrit les contrôles d’enregistrement et d’accord associés. Une migration doit préserver ces détails opérationnels, pas seulement envelopper des chaînes dans du JSON.

La documentation RDAP de RIPE Database ne liste actuellement que quatre types : autnum, domain, ip et entity. Sa réponse /help en direct annonce plusieurs extensions, mais pas irr0. Cela décrit un seul serveur, pas les autres RIR. La distance entre un brouillon et un point d’accès en production est déjà visible.

Le statut du texte est tout aussi net. Datatracker le classe comme Internet-Draft individuel, précise qu’il n’est pas approuvé par l’IETF et qu’il n’a aucun statut formel dans le processus de normalisation. Son état IESG est I-D Exists. La prochaine épreuve n’est pas un schéma plus séduisant : ce sont les preuves d’implémentation.

La migration se joue classe par classe

Le brouillon fait un travail utile : il traduit des notions RPSL de routes et de SET en objets RDAP, propose des chemins stables et transporte des politiques sous forme de champs ordonnés. Les logiciels peuvent ainsi éviter de jongler avec un analyseur RPSL différent pour chaque source. Mais la conversion doit conserver le sens de l’objet. Une chaîne de politique de routage est une déclaration ; ce n’est pas une observation BGP. Un objet route renvoyé ne prouve pas qu’un réseau annonce cette route ou l’accepte.

Les champs facultatifs repoussent aussi une décision vers chaque serveur. Un RIR choisira quelles familles SET et quelles données de politique il expose. Cette souplesse facilite un déploiement par étapes, mais interdit de traiter irr0 comme un label universel de complétude. Le brouillon demande à un serveur compatible d’annoncer irr0 dans rdapConformance, y compris dans sa réponse d’aide. Un client peut vérifier cette annonce ; il doit encore tester chaque classe utilisée par ses filtres et son automatisation.

La section sur la vie privée du brouillon rappelle que ces recherches peuvent concerner les personnes représentées dans les données de registre. Un format JSON commun ne décide pas des coordonnées qu’un serveur doit exposer. L’implémentation doit rendre cette limite visible.

Le tableau de migration doit rester ennuyeux et exact : l’aide annonce-t-elle irr0 ? Quelles classes répondent ? Les listes de membres et les politiques ordonnées sont-elles conservées ? Que renvoie le serveur quand une classe manque ? Les événements d’enregistrement et de modification sont-ils présents ? L’opérateur peut-il comparer la réponse à l’objet RPSL et au flux miroir existants ?

Le brouillon ne fournit pas de matrice de couverture déployée entre les RIR. Une matrice versionnée, appuyée sur des requêtes à chaque service participant et sur des comparaisons champ par champ avec la sortie RPSL, changerait le constat.

À RIPE 93, l’opérateur avait raison de demander à ses pairs de vérifier les objets réellement utilisés. C’est là que le travail commence. « Nous avons RDAP » répond à la question du transport. La sortie de Whois attend que l’enregistrement lui-même arrive intact.

Sources