Résumé

  • L’extension irr0 proposée ajoute six chemins de consultation, dont un objet route identifié par le préfixe et l’AS d’origine.
  • Les peering-sets, rtr-sets et filter-sets sont facultatifs. Une réponse autnum peut aussi omettre son tableau de politiques.

Un opérateur demande à son logiciel de construire un filtre. Le logiciel trouve un objet route en JSON, puis cherche la politique qui lui donne un contexte. La réponse suivante ne contient rien. À ce moment précis, « rien » peut désigner un ensemble inexistant, une classe non servie par ce serveur ou un champ facultatif absent. L’interface a rendu le premier objet plus facile à lire ; elle n’a pas résolu le statut du second.

La version 00 de RDAP Extension for Internet Routing Registry (IRR) Objects a été déposée le 29 octobre par Mahesh Aggarwal, Jasdip Singh, Andy Newton et Sasha Romijn. C’est une soumission individuelle, non une norme IETF adoptée. Son objectif est concret : faire passer des objets IRR aujourd’hui souvent lus sous forme RPSL via WHOIS dans le format structuré et le transport HTTPS de RDAP. Le format de requête RDAP existant ne définit pas ces objets IRR.

Le texte nomme six chemins : route, route-set, autnum-set, rtr-set, peering-set et filter-set. Pour une route, la clé associe préfixe et AS d’origine ; son exemple documentaire est irr0_route/192.0.2.0/24/64500. Cette précision compte. Le guide IRR d’ARIN décrit un objet route par préfixe et ASN d’origine, tandis qu’un route-set regroupe des préfixes ou d’autres route-sets. Ce dernier n’est pas une liste d’objets route. Une conversion qui efface cette différence produirait un JSON propre et une politique déformée.

La portée réelle de l’extension dépend ensuite du serveur. La section 6 laisse à l’implémentation le choix de servir les peering-sets, rtr-sets et filter-sets. La section 7 permet d’ajouter à autnum un tableau irr0_policies, lui aussi facultatif, avec des chaînes import, export et leurs variantes. Lorsque le tableau est présent, l’ordre des éléments doit être respecté. Son absence dans une réponse ne tranche pas l’existence de règles dans les données IRR sous-jacentes.

Un serveur qui fournit l’extension doit annoncer irr0 dans rdapConformance, y compris dans sa réponse d’aide. Ce signal renseigne sur une capacité générale, pas sur la couverture de chacune des six classes. La documentation RDAP de RIPE NCC énumère actuellement autnum, domain, ip et entity comme types pris en charge. La proposition ne contient ni décompte de déploiement ni essai comparant la complétude des serveurs. Le premier contrat à exiger d’un fournisseur est donc un inventaire vérifiable par classe, avec le comportement prévu lorsqu’une classe manque.

Projet IRR-RDAP · RFC 9082 · Documentation RIPE NCC · Guide ARIN