Resumen

  • RIPE-81 hizo explícita la conversión entre políticas y configuración; un informe de 1993 documenta un prototipo limitado, no una adopción general.
  • El acuerdo de 1994 separó la descripción del router de su configuración; el RFC informativo de 1995 no demuestra ejecución universal.

RIPE-81 partía de una dificultad práctica: Europa no tenía un núcleo único y coordinado de enrutamiento, y cada red describía de forma distinta sus relaciones de tránsito. La propuesta de febrero de 1993 guardaba las políticas como objetos estructurados en la base de RIPE. Debían ser claras, generales, comprobables y aplicables, y traducibles entre la política y los archivos de configuración.

Traducir no equivalía a controlar a distancia. La base registraba una política declarada; un programa podía convertirla en listas de acceso de Cisco o gated; el operador podía revisar y cargar el resultado. La configuración activa, los anuncios BGP y las mediciones de tráfico eran pruebas diferentes. Una entrada no demostraba que los pasos posteriores coincidieran con ella.

El correo de Tony Bates del 22 de febrero de 1993 aporta un detalle contemporáneo. Dijo que ripe-81 aún esperaba ratificación; un prototipo básico generaba listas de acceso y un piloto «muy pequeño» del NCC utilizaba una pseudobase de datos. Mencionó también herramientas iniciales de trazado y configuración. Esto acredita una prueba limitada, no un despliegue general. Afirmar que no había generación sería incorrecto; convertir el piloto en una estadística de adopción también.

Las actas de RIPE 18 sitúan el trabajo junto al Merit Routing Registry y la transición de NSFNET. Mencionan cuatro AS en el registro Merit y una beta de Routing Policy Server. Es una instantánea de reunión, no un recuento de redes usuarias. El formato común facilitaba comparar políticas, pero no transfería al registro las decisiones sobre equipos y contratos locales.

El objeto inet-rtr iba a describir interfaces y relaciones de peering para herramientas como PRIDE. Las actas de septiembre de 1994 registran el acuerdo de no usarlo para configurar routers. Esa limitación sobre un objeto descriptivo no contradice el prototipo de listas de acceso: generar una configuración candidata y aplicarla son actos distintos.

RIPE-181 revisó la representación. RFC 1786 apareció en marzo de 1995 como documento Informational; describía objetos aut-num y route, recogía aportes de RIPE y Merit y proponía comparar políticas registradas con el enrutamiento observado. La afirmación de que una ruta no descrita no debería encaminarse expresa una norma, no prueba cumplimiento universal. Un objeto route no es un anuncio BGP; un archivo generado no es una configuración cargada; esta tampoco demuestra por sí sola qué hicieron los paquetes.

La historia actual de RIPE fecha retrospectivamente el Internet Routing Registry en 1995 y explica la separación posterior de los datos de asignación. No llena el vacío entre prototipo y uso habitual. La conclusión acotada es que RIPE hizo las políticas más portátiles y dio entradas estructuradas a herramientas, mientras los participantes delimitaban quién controlaba los equipos. “The Policy Mirror”, de Heng Lu, es una lente interpretativa, no evidencia sobre RIPE. El registro podía preparar un filtro; cada operador decidía si aplicarlo.

Fuentes