Resumen

  • El Internet-Draft individual del 29 de octubre propone seis rutas RDAP para datos de Internet Routing Registry; tres tipos SET y los campos de política siguen siendo opcionales.
  • La respuesta de ayuda RDAP de RIPE NCC no anuncia irr0, el identificador de la extensión. Antes de retirar Whois, cada operador necesita una comprobación de cobertura por servidor.

La salida todavía tiene letra pequeña

En RIPE 93, un operador describió el soporte de objetos de enrutamiento de los RIR como la última función que esperaba para dejar Whois. Seis nombres nuevos de rutas no bastan para garantizar esa salida.

Datatracker publicó el 29 de octubre draft-aggarwal-regext-rdap-irr-00. Entre sus cuatro autores figuran Mahesh Aggarwal, de RIPE NCC, y Jasdip Singh, de ARIN. El documento plantea consultar datos de Internet Routing Registry (IRR) por RDAP: JSON estructurado sobre HTTPS, junto a la información de registro que RDAP ya entrega.

La propuesta enumera seis rutas: irr0_route, irr0_routeSet, irr0_autnumSet, irr0_rtrSet, irr0_peeringSet y irr0_filterSet. Una consulta de ruta combina un prefijo y el ASN de origen. Los objetos SET pueden devolver sus miembros como listas. Una respuesta autnum puede incluir políticas ordenadas de importación y exportación, también en formas multiprotocolo y import-via o export-via.

La letra pequeña llega en la misma propuesta: cada implementación puede decidir si ofrece peering-set, rtr-set y filter-set. El campo irr0_policies también es opcional. Así, un cliente puede entender la nueva interfaz y descubrir que el servidor no publica justo el objeto que consume su filtro. Seis rutas dibujadas no equivalen a seis servicios disponibles.

ARIN explica por qué importa la diferencia. Su IRR está separado de la información Whois pública. Los titulares envían objetos RPSL y otras bases IRR los recuperan para decisiones de enrutamiento. ARIN publica consultas mediante NRTM, archivos descargables y Whois por el puerto 43. Para su propio flujo NRTM, ARIN denomina “autorizados” a ciertos objetos y describe las comprobaciones de registro y acuerdo que respaldan esa clasificación. Migrar significa conservar esos detalles operativos, no solo envolver texto en JSON.

La documentación actual de RIPE Database enumera cuatro tipos RDAP: autnum, domain, ip y entity. La respuesta viva de /help anuncia varias extensiones, pero no irr0. Esa observación solo describe a RIPE; basta, aun así, para mostrar la distancia entre una propuesta y un servicio implementado.

Datatracker clasifica el documento como Internet-Draft individual. No lo respalda el IETF, carece de estado formal en el proceso de estándares y muestra el estado IESG I-D Exists. El siguiente paso útil son pruebas de implementación, no otro dibujo de arquitectura.

JSON resuelve solo la mitad

El borrador hace un trabajo concreto: asigna nombres de ruta estables, representa objetos RPSL de rutas y SET como objetos RDAP y transporta políticas en campos ordenados. Eso puede librar al software de mantener distintos analizadores para cada fuente. Pero la conversión debe conservar el significado. Una cadena de política declara una intención; no observa BGP. Una respuesta de objeto route tampoco demuestra que una red anuncie o acepte esa ruta.

La opcionalidad traslada decisiones a cada servidor. Un RIR decide qué familias SET y qué datos de política entrega. Esa libertad permite desplegar por etapas, pero impide tomar irr0 como sello universal de integridad. El borrador exige que un servidor que implemente la extensión la anuncie en rdapConformance, incluso en su respuesta de ayuda. El cliente puede comprobar ese anuncio; luego debe probar las clases que usan sus filtros y automatizaciones.

La sección de privacidad señala otra decisión local: estas consultas pueden afectar a personas incluidas en los registros. Un formato JSON común no determina qué datos de contacto publica un servidor. La implementación debe hacer visible ese límite.

La ficha de migración debería contestar preguntas precisas: ¿la respuesta de ayuda anuncia irr0? ¿Qué clases responden? ¿Se conservan las listas de miembros, el orden de las políticas y los eventos de alta y cambio? ¿Qué recibe el cliente ante una clase ausente? ¿Puede comparar la respuesta con el objeto RPSL y el flujo espejo actuales?

El borrador todavía no incluye una matriz de cobertura desplegada entre RIR. Una matriz versionada con consultas a cada servicio participante y comparación de campos contra su respuesta RPSL cambiaría la evaluación.

En RIPE 93, un operador pidió a sus colegas revisar los objetos que usan cada día. Esa es la prueba correcta. “Tenemos RDAP” responde cómo viaja la consulta. Whois solo puede salir cuando también llega intacto el registro que importa.

Fuentes