El borrador de Sasha Romijn no decía lo que quería NRTMv4

Resumen

Sasha Romijn, desarrolladora original y mantenedora de IRRD, coescribió NRTMv4 para sincronizar espejos de registros de Internet.
Cuando IRRD y RIPE NCC construyeron implementaciones separadas, sus resultados no coincidieron. Romijn volvió al borrador y encontró que el texto expresaba otra regla.
Una persona revisora del IESG detectó después un ejemplo IPv6 que usaba route donde correspondía route6. El documento sigue en la cola del editor de RFC.

La primera sospecha de Sasha Romijn fue que RIPE NCC había entendido mal NRTMv4. Luego volvió al borrador. La diferencia estaba en el texto que ella había escrito.

Romijn es desarrolladora independiente, creó y mantiene IRRD versión 4 y es coautora de NRTMv4. El protocolo distribuye registros de Internet Routing Registry desde una base autoritativa hacia sistemas espejo. Los operadores usan esos datos para construir filtros de rutas y configurar redes; necesitan saber si la copia local está al día.

NRTMv3 separaba la descarga de un volcado de la consulta posterior de cambios. El número de serie dependía de la instancia del servidor y el protocolo ofrecía pocas señales claras sobre la sincronización. NRTMv4 organiza la distribución en archivos de instantáneas y deltas publicados por HTTPS. Un archivo de notificación firmado enumera esos archivos y sus hashes. El cliente valida la firma y comprueba cada hash antes de aceptar los datos.

El texto dejó de ser una abstracción cuando dos equipos tuvieron que implementarlo. Romijn y RIPE NCC desarrollaron sus versiones en paralelo, pero por separado. Al aparecer una discrepancia, ella creyó al principio que la implementación de RIPE estaba equivocada. IRRD había seguido la regla que ella tenía en mente; el borrador describía otra. La comparación sacó a la luz fallos de las primeras versiones antes de que una lectura local se convirtiera en costumbre.

Un ejemplo reveló el mismo problema en una escala menor. Para una dirección IPv6, el objeto RPSL debía ser route6, no route. Una persona revisora del IESG lo detectó. No hubo una avería de producción: hubo una comprobación de revisión que impidió que un ejemplo enseñara la instrucción incorrecta.

En RIPE 92, en mayo de 2026, Romijn contó cinco implementaciones interoperables. Dijo que RIPE NCC ya usaba NRTMv4 en producción y que IRRD funcionaba como cliente y servidor. La documentación actual de RIPE publica la dirección de producción del archivo de notificación y la clave pública. Al 2 de noviembre de 2026, el Datatracker del IETF sitúa el borrador -11 en la cola del editor de RFC, pendiente de aprobación final.

La prueba importante no fue que el programa de su autora arrancara. Fue que otro equipo pudo construir una lectura distinta del mismo texto y obligarla a corregirlo. En una transferencia de datos que alimenta decisiones de encaminamiento, el código independiente es un lector bastante menos diplomático que un comité.