Resumen

  • Usuarios de BIRD querían una API estándar, no programas que interpretaran la línea de comandos.
  • El hueco que Maria Matejka señaló está entre varios componentes Linux: falta una forma común de presentar sus modelos de configuración.

Los protocolos pueden multiplicarse y el trabajo de integración seguir intacto. Maria Matejka, líder del equipo BIRD en CZ.NIC, llegó a esa conclusión desde una petición práctica: los usuarios de BIRD querían una API estándar para dejar atrás las herramientas que traducían su CLI a JSON. En su charla de RIPE 93, el problema acabó siendo mayor que elegir una sintaxis.

NETCONF lleva cerca de dos décadas en escena y define operaciones sobre datos XML. Su transporte por SSH tiene una especificación propia. RESTCONF ofrece una interfaz HTTP de estilo REST. CORECONF propone CoAP y CBOR para dispositivos con recursos limitados. Los tres caminos utilizan modelos YANG; cada componente del router conserva su propio árbol de datos.

Matejka puso como ejemplo un equipo Linux con BIRD, NetworkManager y systemd. Cada componente conoce su función y su propio árbol de datos. Quien administra el router ve una sola máquina y espera un punto de configuración que refleje ese conjunto. La charla dice que la composición de esos árboles no estaba especificada en el diseño presentado. Matejka mencionó analizadores y codificadores basados en YANG como posibles piezas para un proxy futuro.

Los documentos del IETF delimitan las capas. El RFC 6241 especifica las operaciones NETCONF y su representación XML; el RFC 6242 describe el transporte SSH. El RFC 8040 define RESTCONF sobre HTTP. YANG modela los datos; los RFC 7951 y 9254 especifican codificaciones JSON y CBOR. Esas reglas describen cómo representar y transportar datos estructurados. Los fabricantes y operadores aún tienen que definir cómo reunir los modelos de los componentes en un único modelo de administración.

CORECONF tampoco ha llegado a una norma publicada. Datatracker clasifica la versión 21 como un Internet-Draft expirado, con última revisión en marzo de 2026. La página conserva un hito del grupo de trabajo para presentar el documento a la IESG en noviembre de 2026. La fecha importa a quien elige CoAP y CBOR; el estado actual sigue siendo “expirado”.

El router todavía necesita una decisión sobre el modelo común. El fabricante puede construir un proxy y responsabilizarse de unir los componentes; el operador puede conectar las API por su cuenta. En ambos casos, alguien fija qué árbol manda y cómo se conserva el significado cuando los datos pasan de una representación a otra.

La charla de RIPE 93 y la ficha actual del borrador no incluyen una prueba interoperable de un punto de acceso que combine BIRD, NetworkManager y systemd; esa prueba permitiría saber si la composición pendiente bloquea ya un despliegue o sigue siendo una tarea de diseño.

Fuentes primarias: sesión y transcripción de RIPE 93 · transcripción oficial · equipo BIRD · RFC 6241 · RFC 6242 · RFC 8040 · RFC 7950 · RFC 7951 · RFC 9254 · estado del borrador CORECONF.