Configuring a router via text CLI and configuration file editing is not very 2026. In BIRD, we are trying to catch the departing train and implement a CORECONF variant of an IETF-standardized YANG-based API. We've created a prototype but getting things right is harder than it seems. This is a report on what has already gone wrong and what is expected to fail in the future.
While a standardized API looks simple on surface, the reality is much more convoluted. There are three standards for communication, NETCONF, RESTCONF and emerging CORECONF, each of these with slightly different semantics. Lots of the YANG modules are not yet finalized and implementation specifics are leaking into them from their authors. In the best case, we end up with the implementations slightly differing in what is implemented, and being mostly compatible for automated access. Yet, the actual future may be much more dire, with the users having to cater for three different protocols and vastly diverse implementation status of the standardized API. All of that is spiced up by performance challenges.
With BIRD, we are kinda late to the party. Everybody has some API working. That brings a disadvantage on the market, but it also allows us to study the previous attempts, see possible problems and implement our API to our standards, including high performance and stability. We can also see emerging compatibility issues and there are some attempts to develop proxies and convertors to bridge the gaps.
I'm the leader of BIRD Internet Routing Daemon development team. I'm the main author of its current filter interpreter and of the multithreading subsystem, now focusing on API and interoperability.
I also love any means of public transportation and logistics, including studying their history. Sometimes, I play chess, mostly at Lichess: https://lichess.org/@/marenamat, and some day, I'll get my FIDE ELO, hopefully, if I get to play over-the-board games.
Here is my personal website: https://maria.jmq.cz/