Zusammenfassung

  • draft-ietf-opsawg-veloce-yang-00 sieht einen Link auf einen bestimmten Tag oder Commit statt auf den beweglichen Branch-HEAD vor. Das ist ein starker Identitätsnachweis, macht aber Merge, geschlossenes Issue oder grünen CI-Lauf nicht automatisch zum WG-Konsens.
  • Nach der Veröffentlichung folgen weitere Beweispflichten: Entscheidungsarchiv, Release-Herkunft, tatsächlich gemeldetes YANG-Library-Module-Set, repräsentative Operationen und beobachtetes Dienstergebnis.

Ein Commit kann exakt sein und trotzdem die falsche Frage beantworten.

Er beweist, welcher Zustand eines Repositorys gemeint ist. Er beweist nicht, ob die Arbeitsgruppe diesen Zustand beschlossen hat. Ein Tag kann denselben Zustand dauerhaft auffindbar machen. Er beweist nicht, ob ein Hersteller ihn ausgeliefert oder ein Router ihn geladen hat.

Diese Trennung ist der eigentliche Gegenstand von VELOCE. draft-ietf-opsawg-veloce-yang-00 schlägt vor, den YANG-Modulquelltext von der begleitenden Dokumentprosa zu trennen. Beschreibung, Referenzen, IANA-, Sicherheits- und Betriebserwägungen verbleiben im Dokument. Das Modul wird in einem Source-Code-Repository entwickelt und gepflegt.

Das passt zur technischen Form von YANG. Ein Modul ist lesbare Spezifikation und zugleich Eingabe für Parser, Validatoren und Implementierungen. Es importiert Abhängigkeiten, deklariert Revisionen, Features und möglicherweise SID-Dateien. Kleine Änderungen lassen sich als Diff genauer prüfen als in einer vollständig neu publizierten Langform.

Die eingefrorene Fassung ist ein aktiver OPSAWG-Working-Group-Internet-Draft vom 25. August 2026. Im Kopf steht „Intended status: Experimental“, während die Datatracker-Zusammenfassung keinen vorgesehenen RFC-Status ausweist. Die Historie enthält nur Revision 00. Das Dokument ist weder RFC noch abgeschlossenes Experiment oder Einsatznachweis. Die vorgeschlagenen Fristen—zwei Jahre für ein neues Modul, ein Jahr für ein inkrementelles -bis—sind Prüfgrößen, keine Ergebnisse.

Der wichtigste Mechanismus lautet: Das Modul darf nicht in das Dokument eingefügt werden. Statt auf HEAD muss der Text auf eine bestimmte getaggte Version oder einen Commit-Hash zeigen. So bleibt der Stand zum Veröffentlichungszeitpunkt abrufbar und überprüfbar.

Gegenüber einer beweglichen Branch-Adresse ist das ein Fortschritt. Reviewer, YANG Doctors, Implementierer und Auditoren können über dasselbe Objekt sprechen. Der Nachweis beantwortet sauber: Welche Bytes waren gemeint?

Gerade diese Sauberkeit darf nicht in eine weitergehende Behauptung umgedeutet werden. Ein Tag fixiert Inhalt, nicht Legitimität.

RFC 8874 stellt klar, dass Arbeit auf GitHub keinen Sonderstatus besitzt. Die Working Group kann Ergebnisse annehmen, ablehnen oder ändern. Die Repository-Kopie muss den Konsens auch nicht zu jedem Zeitpunkt vollkommen abbilden, weil Editoren ein Dokument arbeitsfähig halten müssen.

Die Oberfläche suggeriert dennoch Abschluss. Pull Request: Merged. Issue: Closed. Check: Passed. Label: has-consensus. Das sind echte Zustände, aber sie werden von Rollen mit bestimmten Rechten gesetzt. Ihre Bezeichnung erzeugt keine institutionelle Autorität.

RFC 8874 verlangt deshalb, WG-Konsensentscheidungen über die Mailingliste zu bestätigen, und legt die abschließende Bewertung bei den Chairs. RFC 2418 beschreibt rough consensus ebenfalls nicht als Mehrheitsabstimmung. Entscheidungen aus Sitzungen müssen auf der Liste überprüft werden, und der Chair beurteilt die Gesamtlage.

Ein ordnungsgemäßer Merge kann also vor der abschließenden Konsensquittung liegen. Editoren dürfen viele Änderungen eigenständig handhaben; bei einer Designfrage mit Folgen für Implementierung oder Interoperabilität kann der Chair das Warten auf eine Konsensbewertung verlangen.

Der belastbare Nachweis verbindet vier Identitäten: die technische Frage, die akzeptierte Lösung, die eingegrenzte Konsensfeststellung und den Commit, der sie umsetzt. Werden Entscheidung und Code nur getrennt archiviert, bleibt ihre Übereinstimmung eine Annahme.

Continuous Integration liefert einen anderen, wertvollen Beleg. RFC 8874 nennt Dokument-Builds, Prüfung formaler Sprachen und Tests. VELOCE empfiehlt YANG-Validierung und eine containerisierte Umgebung, die lokal reproduziert werden kann.

Grün bedeutet, dass benannte Prüfungen auf benannten Eingaben erfolgreich waren. Der Umfang hängt von Commit, Validatorversion, Importen, Features, Konfiguration, Container und Testkorpus ab. Nicht geschriebene Tests bestehen dadurch nicht, und identisches Verhalten verschiedener Produkte folgt daraus ebenfalls nicht.

Die Lösung ist nicht weniger Automatisierung, sondern ein sichtbarer Nenner. Ein Validierungsmanifest sollte Werkzeuge, Versionen, Abhängigkeiten, Optionen und Ausnahmen festhalten.

Auch die Veröffentlichung beantwortet nur eine weitere Frage. Ein RFC kann exakt das geprüfte Modulobjekt nennen. Er baut jedoch kein Herstellerpaket und aktiviert keinen Datastore. Dazwischen liegen Repository-Verwahrung, Release-Erzeugung, Signatur, Abhängigkeitsauswahl, Herstellerintegration, Image-Bau, Rollout und lokale Aktivierung.

Die Governance-Historie braucht ebenfalls eigene Verwahrung. RFC 8874 weist darauf hin, dass Git-Replikation Repository-Inhalte gut schützt, während Issues, PR-Diskussionen, Reviews und Wikis leichter verloren gehen. Externer Dienstausfall und kompromittierte privilegierte Konten bleiben Risiken. RFC 8875 ergänzt Verwaltung und Sicherung.

Wer den Commit behält, aber den Grund seiner Annahme verliert, besitzt das Ergebnis ohne vollständigen Autoritätsnachweis.

Der erste Laufzeitbeleg kommt vom Server. RFC 8525 lässt YANG Library die Module-Sets von Datastores samt Revisionen, Features und Deviations melden. Damit kann ein Betreiber prüfen, ob das Gerät überhaupt den veröffentlichten Schemakontext behauptet.

Selbst eine Übereinstimmung ist kein Funktionsbeweis. YANG Library ist eine Serveraussage über Schema. Repräsentative NETCONF- oder RESTCONF-Operationen, Zustands-Readback und unabhängige Dienstbeobachtung bleiben nötig.

Die Running-Code-Perspektive ordnet diese Ebenen, statt eine gegen die andere auszuspielen. Tag: Repository. Konsens: Entscheidung. RFC: Veröffentlichung. Geladenes Schema und Verhalten: Betrieb.

Das Prinzip der minimalen Anfangsspezifikation bietet eine konstruktive Umsetzung. Gemeinsam festgelegt werden müssen nur die nötigen Verbindungen: exaktes Objekt, reproduzierbare Validierung, auffindbare Entscheidung und unveränderliche Veröffentlichungsreferenz. Werkzeuge und Lieferketten dürfen lokal variieren; freiwillige Übernahme und Interoperabilität liefern die spätere Bestätigung.

Auch Repräsentation bleibt ein technisches Prozessrisiko. Wer jedes Issue verfolgt, ist eine selbst ausgewählte Gruppe. Andere Fachleute lesen nur die Mailingliste. Eine lebhafte Oberfläche ist kein Mandat. Die Rückbindung an Liste und Chairs schützt daher die Breite des Verfahrens.

VELOCE ist erfolgreich, wenn es Wartung beschleunigt, ohne fünf Quittungen in eine zu pressen. „Fertig“ muss künftig präzisiert werden: Quellobjekt, WG-Entscheidung, Veröffentlichung, Produkt oder laufender Dienst.

Quellen