Zusammenfassung

  • BIRD-Nutzer wollten die CLI nicht länger über externe JSON-Übersetzer anbinden; jede solche Verbindung braucht eigene Regeln für die Darstellung.
  • Matejkas Beispiel führt zur Kernfrage der Router-API: Wer legt fest, ob ein IPv6-Wert als 16 Bytes oder als Text maßgeblich ist?

BIRD-Nutzer griffen auf Werkzeuge zurück, die die Kommandozeile auslasen und ihre Ausgabe nach JSON umwandelten. Damit lag die Übersetzung außerhalb des Routing-Daemons: Ein Management-Client musste erst BIRDs Ausgabe verstehen und sie in sein eigenes Datenformat überführen. Maria Matejka beschrieb auf der RIPE 93 den Wunsch nach einer standardisierten API. Die Forderung kam aus einem konkreten Arbeitsablauf, nicht aus einer Vorliebe für ein neues Protokoll.

Ihre drei Wege beantworten unterschiedliche Client-Fragen. NETCONF hält für Konfigurationsvorgänge eine SSH-Sitzung offen. RESTCONF überträgt Anfragen per HTTP und ist für Browser ohne dauerhaft offene Sitzung gedacht. CORECONF verwendet CoAP und CBOR für eingeschränkte Geräte. YANG beschreibt die zugrunde liegende Datenstruktur; Transport und Codierung sagen noch nicht, welches Modell im Router verbindlich ist.

Dort setzt Matejkas Linux-Beispiel an. BIRD, NetworkManager und systemd übernehmen verschiedene Aufgaben und verwalten eigene Datenbäume. Für den Betreiber ist es ein Router, dessen Zustand zusammengehört. Für einen Integrator sind es mehrere Modelle, die in einem Endpunkt zusammenfinden sollen. Die Designfrage lautet deshalb: Welche Datenansicht erhält der Kunde, und wer führt die Modelle zusammen?

Eine IPv6-Adresse zeigt, warum diese Entscheidung Auswirkungen hat. Intern kann sie aus 16 Bytes bestehen; eine API kann sie als Text darstellen. Matejka fragte, welche Darstellung im YANG-Datenspeicher und in den nativen Strukturen der Programme die Quelle der Wahrheit ist. Ein Proxy muss die Schemata kennen und festhalten, welches Modell ein Feld besitzt. Ein JSON- oder XML-Übersetzer allein kann diese Zuständigkeit nicht festlegen. YANG-basierte Parser und Encoder könnten die Abbildung eines künftigen Proxys stützen.

Der Stand von CORECONF setzt einen Termin auf diese Auswahl: Am 31. Oktober 2026 führte der IETF Datatracker Entwurf 21 als abgelaufenen Internet-Draft, zuletzt geändert am 2. März. Der Arbeitsgruppen-Meilenstein zur Vorlage beim IESG lag im November. Das ist ein konkreter Punkt für Teams, die CoAP und CBOR prüfen; die Eigentümerschaft des gemeinsamen Routermodells bleibt daneben bestehen.

Die Quellen lassen die Betriebsfrage offen, wer in einem gemeinsamen Endpunkt Werte aus allen Komponenten zusammenführt. Ein Interoperabilitätstest, der BIRD, NetworkManager und systemd liest, eine begrenzte Änderung ausführt und für jedes Feld Herkunft und maßgebliches Modell zeigt, würde diese Frage entscheidbar machen.

Primärquellen: RIPE-93-Sitzung · offizielles Transkript · BIRD-Team · RFC 6241 · RFC 6242 · RFC 8040 · RFC 7950 · RFC 7951 · RFC 9254 · CORECONF-Entwurfsstatus.