Zusammenfassung

  • draft-ietf-netconf-error-registries-00 schlägt zwei IANA-Register für YANG-Fehlertags und -Identitäten vor; die erste Fassung ist erkennbar unvollständig und macht aus einem Namen keinen Ursachennachweis.
  • Verlässliche Automatisierung muss Sitzung, Operation, Antragsteller, Autorisierungsentscheidung, Zielpfad, modulqualifizierte Identität, strukturierte Hinweise, Transaktion, Abhilfe, Rücklesen und Dienstwirkung erhalten.

Die Automatisierung liest invalid-value und entscheidet sich für einen neuen Versuch.

Das wirkt präzise. Der Begriff ist standardisiert und lässt sich in eine Regel schreiben. Unter RESTCONF kann dasselbe Tag jedoch mit HTTP 400, 404 oder 406 auftreten. Bei geschützten Ressourcen darf ein Server 404 mit invalid-value liefern, um nicht einmal deren Existenz zu bestätigen. Die Antwort ist richtig, gerade weil sie die zugrunde liegende Wirklichkeit nicht vollständig offenlegt.

Diese Grenze macht draft-ietf-netconf-error-registries-00 relevant. Das am 30. September 2026 veröffentlichte Dokument der NETCONF-Arbeitsgruppe schlägt eine „YANG Protocol Error List“ und ein Register für „YANG Protocol Error Identities“ vor. Implementierungen sollen eine kanonische Liste nicht länger aus mehreren RFCs zusammensuchen müssen.

Revision 00 ist ein aktiver Internet-Draft mit Standards-Track-Ziel und Ablaufdatum 3. April 2027. Sie ist weder RFC noch genehmigtes IANA-Register noch Implementierungs- oder Interoperabilitätsbericht. Die fünf Seiten eröffnen eine Governance-Fläche.

Das erste Register soll error-tag, gültige error-type- und error-severity-Werte, error-info, Beschreibung und Referenz erfassen. Das zweite soll Identitätsname, gegebenenfalls Basisidentität, Zusatzinformation und Referenz speichern. Für beide ist IETF Review vorgesehen.

Die Zentralisierung hat Nutzen. Sie verhindert Schreibvarianten, macht Erweiterungen auffindbar, verbindet einen Wert mit seiner maßgeblichen Spezifikation und schafft ein Verfahren für Aufnahme, Änderung, Ablösung und Veraltung. Das ist ein Kontrollsystem für gemeinsame Begriffe.

Revision 00 zeigt zugleich, wie genau dieses System sein muss. Die Beschreibungen der ersten drei Felder stehen noch auf TBD. Der Entwurf erklärt, der Anfangsbestand stamme aus Appendix A von RFC 6241, führt aber nur in-use, invalid-value, too-big, missing-attribute und bad-attribute auf. Der Appendix enthält danach unter anderem access-denied, resource-denied, rollback-failed, data-missing, operation-not-supported, operation-failed und malformed-message.

Auch die Identitätsliste trägt Merkmale einer ersten Fassung. filter-unsupported, insufficient-resources und no-such-subscription sind doppelt vorhanden. Aus den zitierten RFCs fehlen Einträge: RFC 8639 enthält stream-unavailable, suspension-timeout und unsupportable-volume; RFC 8641 enthält cant-exclude, no-such-subscription-resync, on-change-unsupported, on-change-sync-unsupported und sync-too-big. Als Verfahrensreferenz erscheint RFC 5226, obwohl RFC 8126 die heutige BCP-26-Ausgabe ist und ihn abgelöst hat.

Das ist kein Urteil über einen künftigen Standard. Es ist eine Beobachtung an Revision 00. Bevor Software das Register als Abhängigkeit nutzt, braucht es Eindeutigkeit, Vollständigkeit, aktuelle Verweise und klare Feldsemantik. Private Ergänzungstabellen würden die Fragmentierung nur unter anderem Namen fortsetzen.

Selbst ein makelloses Register wäre noch kein Störungsprotokoll.

RFC 6241 erlaubt mehrere <rpc-error>-Elemente in einer NETCONF-Antwort. Ein Element kann die konzeptionelle Schicht, das Protokolltag, den Schweregrad, ein modell- oder implementierungsspezifisches Anwendungstag, den XPath des betroffenen Knotens, eine lesbare Nachricht und strukturierte Zusatzdaten tragen. Diese Felder bilden keine Redundanz, sondern verschiedene Beweisachsen.

RFC 8640 zeigt die Hierarchie bei Subscriptions. filter-unsupported wird dem breiten Tag invalid-value zugeordnet, insufficient-resources dem Tag resource-denied, on-change-unsupported dem Tag operation-not-supported, sync-too-big dem Tag too-big und unchanging-selection dem Tag operation-failed. Die genauere Identität steht modulqualifiziert im error-app-tag, etwa ietf-subscribed-notifications:no-such-subscription.

Auch dieser Name hängt von der Operation ab. Die zulässige Basisidentität unterscheidet sich danach, ob eine Subscription eingerichtet, geändert, gelöscht, beendet oder neu synchronisiert werden sollte. Bei Einrichtung und Änderung kann error-info Parameterhinweise für einen später erfolgreichen Versuch liefern. Wer RPC, Modul und Hinweise verwirft, reduziert strukturierte Evidenz auf ein Wort.

unchanging-selection zeigt die gewollte Verdichtung besonders klar. Nach RFC 8641 darf die Identität erscheinen, wenn eine Auswahl nicht vorhandene Daten oder Daten ohne Leseberechtigung bezeichnet. Sie kann auch nach einer Berechtigungsänderung gelten, die zuvor sichtbare Updates unsichtbar macht. Pfadkorrektur, Rechtegewinn und Neuaufbau eines Filters sind unterschiedliche Maßnahmen. Das Protokoll fasst die Fälle zusammen, um Abstraktion und Vertraulichkeit zu bewahren.

no-such-subscription schützt dieselbe Grenze. RFC 8639 deckt damit einen nicht existierenden Bezeichner, eine Subscription eines anderen Teilnehmers oder eine konfigurierte Subscription ab, für die die RPC nicht gilt. Der sichere Bescheid lautet: Diese Operation kann mit diesem Bezeichner nicht handeln. Er ist keine Abfrage des internen Bestands.

insufficient-resources verdichtet eine andere Unsicherheit. Der Publisher kann die verlangte Subscription nicht erzeugen, doch der Name verrät nicht, ob Arbeitsspeicher, CPU, Bandbreite, Queue, Implementierungsgrenze oder Quote fehlen. Er benennt weder Besitzer noch Dauer der Knappheit noch einen vernünftigen Wiederholungszeitpunkt.

Ein Register besitzt Autorität über Namen, nicht über Ereignisse.

Der kleinste brauchbare Beleg beginnt vor dem Fehler: Protokoll und Sitzung, RPC, Request-ID, authentisierte Identität und Autorisierungsentscheidung. Er enthält Datastore und Pfad, breites Tag, modulqualifizierte Identität und Basis, error-info, Server- und Modulrevision und Transaktionsergebnis. Nach einem Eingriff folgen genehmigte Änderung, Rücklesen des Zustands und beobachtetes Dienstergebnis.

Diese Kette verhindert falsche Gleichsetzungen. 404 beweist keine Nichtexistenz. Eine spezifische Identität beweist keine physische Ursache. Ein angenommener Folgeaufruf beweist keine Zustandsänderung. Eine bestätigte Zustandsänderung beweist keine Diensterholung.

Heng Lus Prinzip der minimalen Anfangsspezifikation verteilt Verantwortung passend. Der Standard definiert das kleinste interoperable Vokabular und Erweiterungsregeln. Die spätere Entscheidung verbleibt bei dem Akteur mit den späteren Fakten: Server, Betrieb und Service Owner. Das Register lokalisiert Begriffs-Governance, nicht die Kausalentscheidung eines Vorfalls.

Die Trennung der Realitätsschichten ist ebenso wichtig. operation-failed ist ein Symbol. Fehlender Knoten, entzogene Berechtigung, erschöpfte Queue und unzulässiger Parameter sind unterschiedliche Realitäten. Das Symbol darf sie absichtlich gemeinsam abdecken. Wer es zur Realität selbst erklärt, erzeugt falsche Gewissheit.

Der Vorrang laufenden Codes verlangt schließlich einen eigenen Beleg für die Abhilfe. Ein Retry ist keine Erholung, weil die API ihn annimmt. Auch ein erfolgreicher Write genügt nicht. Erst Rücklesen und beobachteter Dienst machen aus einer angeordneten Maßnahme eine betriebliche Tatsache.

Quellen