Zusammenfassung
- RFC 10035 ergänzt die YANG Library um die schreibgeschützte Liste
augmented-by. Ein Managementserver kann damit angeben, welche Module desselben Module-Sets ein anderes Modul direkt um Schemaknoten erweitern. - Die Liste schließt eine Entdeckungslücke, nicht die gesamte Entscheidungskette. Sie berechnet keine transitive Abhängigkeit, belegt keine Aktualität und Kompatibilität und erteilt keine Freigabe für eine Änderung.
Drei Module zeigen, was „direkt“ bedeutet
Das Beispiel mit A, B und C ist klein, aber für Automatisierung entscheidend. A stellt den Basisknoten bereit. B erweitert ihn um einen Container. C erweitert wiederum den Container aus B um ein Blatt. Bei A erscheint B unter augmented-by, bei B erscheint C. C gilt nicht als direkter Erweiterer von A, obwohl sein XPath innerhalb des von A ausgehenden Baums liegt.
Das ist kein Datenverlust, sondern die definierte Reichweite. Maßgeblich ist das Modul, dem der unmittelbare Elternknoten des neu eingefügten Knotens gehört. Die Verbindung von C zu A ist indirekt und muss von einer Anwendung berechnet werden. Wer den vollständigen Rückwärtsabschluss oder die Auswirkungen auf einen bestimmten Pfad braucht, muss den Graphen beziehungsweise den Schemabaum selbst durchsuchen.
Die Trennung verhindert, dass unterschiedliche Beziehungen zu einem unscharfen „hängt ab von“ verschmelzen. Definitionen zu importieren, ein Submodul einzubinden, Knoten zu ergänzen oder Eigenschaften durch eine Deviation zu verändern, sind verschiedene Vorgänge. Ein Katalog oder Testsystem sollte festhalten, welche Kante gemeldet und welche abgeleitet wurde.
Die Veröffentlichung ergänzt RFC 8525 an einer engen Stelle
Der RFC Editor veröffentlichte RFC 10035 im August 2026 als Standards-Track-Dokument des IETF. Das enthaltene Modul ietf-yang-library-augmentedby trägt das Revisionsdatum 26. August 2026. Bei der IANA wurden Modulname, XML-Namensraum und das Präfix yanglib-aug registriert.
RFC 8525 lässt einen Server bereits Datastores, Module-Sets, Revisionen, Features, Import-only-Module und Deviations beschreiben. Über Deviations war damit eine Art Rückwärtsbeziehung sichtbar. Bei Augments musste ein Client jedoch die betreffenden Modelldateien beschaffen und gemeinsam auswerten, um herauszufinden, wer ein Basismodul erweitert.
RFC 10035 setzt augmented-by unter jeden Moduleintrag im NMDA-Baum der YANG Library. Die Liste wird außerdem im veralteten modules-state-Baum angeboten, um die ältere, mit RFC 7895 verbundene Form zu bedienen. Inventar-, Telemetrie- und Katalogsysteme müssen daher nicht mehr jede Datei laden, nur um diese erste Rückwärtskante zu finden.
Der Gewinn bleibt bewusst begrenzt. Der Server veröffentlicht eine Tatsache, die er beim Zusammenstellen seines unterstützten Schemas kennt. Er kennt damit nicht automatisch jeden Geschäftsprozess, der von einem hinzugefügten Knoten abhängt.
Das Module-Set bildet die Beweisgrenze
Ein Wert in augmented-by verweist auf einen Modulnamen im selben Module-Set. Basismodul und Erweiterer müssen dort vorhanden sein. Der Erweiterer darf kein reiner Import-only-Eintrag sein. Zudem darf die Referenz weder direkt noch indirekt auf das erweiterte Modul zurückführen.
Diese Bedingungen sichern die Struktur. Ein Server soll keine Kante mit einem außerhalb liegenden Endpunkt melden und kein nur für Definitionen vorhandenes Modul als aktive Schemaänderung ausgeben. Sie beweisen aber nicht, dass der Sammler das richtige Module-Set gelesen hat. RFC 8525 kann mehrere Datastores und Schemaauswahlen beschreiben. Softwareaktivierung, Gerätetausch oder Onboarding eines Moduls können deren Inhalt ändern.
Ein belastbarer Nachweis benötigt deshalb Geräte- und Endpoint-Identität, authentisierten Principal, Datastore, Schema- oder Module-Set-Auswahl, Content-ID, Revisionen und Abrufzeit. RFC 10035 weist darauf hin, dass die Rückwärtsdaten die Bibliotheksinstanz vergrößern und beim Onboarding aktualisiert werden sollen. Eine formal richtige Kante aus einem alten Cache ist trotzdem veraltet.
Ein Inventareintrag ist kein Kompatibilitätsurteil
augmented-by sagt, dass ein Modul dem Schema eines anderen direkt Knoten hinzufügt. Die Aussage bedeutet nicht, dass ein bestimmter Client die Knoten versteht, sie ignorieren darf oder dass eine neue Revision ihre Semantik erhält. Sie beweist auch nicht, dass entsprechende Daten im maßgeblichen Datastore vorhanden sind.
Ein Katalog kann anhand der Kante Modelle nachladen. Ein Telemetrieparser kann Felder außerhalb der Basisdatei entdecken. Eine Testplattform kann ihre Prüffläche erweitern. Trotzdem muss sie Revisionen, Features, Deviations, Imports und Zielpfade untersuchen und die Ergebnisse den tatsächlichen Verbrauchern zuordnen.
Besonders bei einer Entfernung ist das wichtig. Wenn A auf B verweist, warnt der Eintrag davor, dass B A verändert. Er erlaubt nicht, B nach einem Blick auf A abzuschalten. Andere Module können B direkt erweitern, Konfigurationen können von B eingeführte Knoten enthalten und Abonnements können diese Daten nutzen. Eine Freigabe braucht den vollständigen Graphen im konkreten Betriebszustand.
Schreibgeschützt heißt nicht folgenlos offen
Die neuen Knoten sind Betriebsmetadaten, keine beschreibbare Konfiguration. Eine Abfrage verändert das Geräteverhalten nicht. Die Zusammensetzung des Schemas kann dennoch Hersteller- oder Domänenmodule, aktivierte Fähigkeiten und zusätzliche Datenflächen sichtbar machen.
Deshalb verweist RFC 10035 auf sichere YANG-Managementprotokolle, gegenseitige Authentisierung und Zugriffskontrolle wie NACM. Authentisierung klärt, welcher Endpoint geantwortet hat. Autorisierung bestimmt, welchen Ausschnitt ein Benutzer lesen darf. Beides garantiert nicht, dass ein anderer Principal, Datastore oder späterer Zustand dieselbe Bibliothek liefert.
Automatisierung muss diese Sichtbedingungen mitführen. Der Vergleich eines privilegierten mit einem eingeschränkten Abruf kann ein Verschwinden vortäuschen, das lediglich aus Zugriffspolitik entsteht. Abwesenheit ist nur bei bekanntem Umfang und bekannter Berechtigung belastbar.
Implementierungen belegen Machbarkeit, nicht den gesamten Bestand
Der IESG-Bericht nennt vier Implementierungen und eine Validierung bei einem IETF-Hackathon. Das zeigt, dass der Mechanismus implementierbar und abfragbar ist. Es weist nicht nach, welche Version auf jedem verwalteten Gerät läuft oder ob jeder Server die Liste bei einer Schemaänderung atomar aktualisiert.
Ein Betriebstest sollte mit bekannten Modulen beginnen. Nach der Aktivierung eines direkten Erweiterers ist zu prüfen, ob beide Module im selben Set stehen, ob das Basismodul den Erweiterer nennt und ob sich die Content-ID erwartungsgemäß ändert. Ein Zweischritt-Fall muss anschließend beide direkten Kanten liefern, ohne die Kette fälschlich abzuflachen.
Auch Negativtests sind nötig. Ein Import-only-Modul darf nicht als aktiver Erweiterer erscheinen. Zyklen müssen in der Validierung scheitern oder von robusten Clients sicher behandelt werden. Ein veralteter Sammler darf keine Änderung freigeben. Ein gesperrter Nutzer darf die Kompositionsdaten nicht auf einem Nebenweg erhalten.
Entdeckung, Analyse und Ausführung haben verschiedene Eigentümer
Der Server ist für die von ihm veröffentlichte Schemazusammensetzung zuständig. Der Client verantwortet den daraus berechneten Graphen. Der Service Owner verantwortet die Ausführung und das akzeptierte Betriebsrisiko.
RFC 10035 verbessert die Übergabe, weil nicht mehr jeder Verbraucher eine elementare Kante aus sämtlichen Modelldateien rekonstruieren muss. Eine gemeinsame Entdeckungsinformation ist aber keine zentrale Änderungsfreigabe. Der Server kennt nicht alle Workloads, die Graphenplattform nicht das Wartungsfenster und ein Standardregister nicht den Aktualisierungszustand eines konkreten Geräts.
Die prüfbare Kette führt vom authentisierten Endpoint, Datastore, Schema und der Content-ID über Revisionen und direkte Kanten zum berechneten Abschluss, zu betroffenen Pfaden und Verbrauchern und schließlich zu Kandidatenänderung, Tests, Rollback und beobachtetem Ergebnis. Die erste Kante ist verlässlicher geworden; der Rest der Verantwortung bleibt verteilt.
Quellen
- RFC 10035 — YANG Library: Addition of the augmented-by List
- RFC 8525 — YANG Library
- RFC 7950 — The YANG 1.1 Data Modeling Language
- RFC 8342 — Network Management Datastore Architecture
- RFC 8341 — Network Configuration Access Control Model
- RFC 6241 — NETCONF
- RFC 8040 — RESTCONF
- IETF Datatracker — Dokumentakte zu augmented-by
- IESG-Bericht — augmented-by
- IETF-Ankündigung — RFC 10035
- IANA — YANG Parameters
- IANA — XML Registry
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
