Zusammenfassung

  • draft-ietf-netmod-yang-next-agreement-00 teilt YANG-Next-Themen in Aufnahme, mögliche Prüfung, Verschiebung über die nächste Version hinaus und bereits erfolgte oder vorgeschlagene Schließung ein.
  • Diese Einteilung ist ein Klassifizierungsbeleg der Revision 00. Weder eine Kategorie noch ein geschlossenes GitHub-Issue oder WG Document belegen allein endgültige Aufnahme, normative Bedeutung, Kompatibilität, Machbarkeit, Werkzeugreife oder Einführung.

Ein geordnetes Backlog kann wie ein beschlossener Bauplan aussehen. Sobald eine Karte in „aufnehmen“ liegt, wird sie zur Roadmap. Sobald sie geschlossen ist, gilt das technische Problem als erledigt. Genau diese Umdeutung macht die Lektüre des YANG Next Agreement riskant.

Der Entwurf definiert nicht YANG 2.0. Er überführt den Issue-Bestand von netmod-wg/yang-next in ein Arbeitsgruppendokument und schafft vier Wege, auf denen über Umfang und Gestalt einer künftigen Sprachversion gesprochen werden kann. Seine unmittelbare Leistung ist die Begrenzung der Fragen, nicht deren normative Beantwortung.

Dokumentstatus ist kein Ergebnisstatus

Im Datatracker steht Revision 00 als aktiver Internet-Draft der NETMOD Working Group, zuletzt aktualisiert am 23. Juni 2026. Der WG state lautet WG Document, der IESG state I-D Exists; das strukturierte Feld Intended RFC status ist leer. Im Dokumentkopf steht dagegen Intended status: Informational, mit Ablauf am 25. Dezember 2026.

Beide Beobachtungen gehören in die Akte. Sie dürfen nicht zu einer behaupteten IETF-Genehmigung verschmolzen werden. WG Document bezeichnet das anerkannte Gefäß der Gruppenarbeit. I-D Exists bestätigt die Existenz des Entwurfs. Der Kopf nennt eine beabsichtigte Behandlung des Textes. Keine dieser Angaben stimmt über jede Tabellenzeile ab.

Der Entwurf sagt selbst, dass er Diskussion und möglichst Einigung über Umfang und Form der nächsten YANG-Version ermöglichen soll. Er verfolgt nicht das Ziel, als RFC veröffentlicht zu werden; ein GitHub-Dashboard könnte die Issues später wieder verfolgen. Die Karte ist ein Mittel zur Konsenssuche, nicht ihr Endprotokoll.

Vier Wege schützen vor ungeplantem Sprachwachstum

Der Tracker enthielt laut Revision 00 ungefähr 125 offene und 35 geschlossene Issues. Größe, Komplexität, Bedeutung und Kompatibilitätswirkung unterscheiden sich erheblich. Wenn allein verfügbare Autoren bestimmen, welche Idee umgesetzt wird, kann Beitragsenergie an die Stelle eines gemeinsamen Ziels treten.

Der erste Weg enthält Änderungen, die nach Auffassung der Autoren in eine künftige Version gehören. Der zweite hält prüfenswerte Ideen bei ausreichendem Interesse. Der dritte verschiebt Arbeit aus der nächsten Version, ohne sie dauerhaft auszuschließen. Der vierte umfasst Themen, die beendet sind oder beendet werden sollen.

Die größte Wirkung liegt im expliziten „nicht jetzt“. Eine minimale erste Spezifikation hält den gemeinsamen Kern klein genug für überprüfbare Experimente. Spätere Entscheidungen bleiben dort, wo bessere Informationen verfügbar sein werden. Vertagung ist kein technisches Widerlegen.

Auch der stärkste Weg bleibt ein Vorschlag. Abschnitt 2 spricht davon, was die Autoren für notwendig halten. Manche Klarstellungen könnten nach Prüfung gar keine Änderung erfordern. Appendix Issue 152 enthält eine andere Klassifizierung. Die Tabelle ist daher selbst Gegenstand der Konsensarbeit.

Geschlossen beschreibt keinen einheitlichen Grund

Im geschlossenen Bereich stehen bereits geschlossene GitHub-Issues, offene Issues mit Schließungsvorschlag, Duplikate, Missverständnisse der Sprache, als schädlich eingeschätzte Änderungen und Fragen, die zu Protokollen statt zur Sprache gehören. Auch geringe Priorität, hohe Komplexität oder ein besserer Workaround können ausschlaggebend sein.

Diese Fälle haben unterschiedliche technische Bedeutung. Ein Duplikat verschiebt die Diskussion. Eine Protokollfrage wechselt die Zuständigkeit. Ein Vorschlag zur Schließung ist noch kein Chair-Urteil. Ein wegen YANG-1.1-Kompatibilität geschlossenes Thema kann unter YANG 2.0 neu bewertet werden. Der Entwurf nennt ausdrücklich bereits geschlossene Issues, die wegen geänderter Umstände in anderen Listen wiederkehren.

Ein belastbarer Beleg muss deshalb Issue-ID, Zeitpunkt, Diskussion, Position in der genauen Draft-Revision, Begründung und spätere WG-Bewertung verbinden. Ein einzelnes closed bewahrt nur Workflow-Zustand.

Konsens beginnt mit nachvollziehbaren Einwänden

Die NETMOD-Protokolle zeigen die Vorgeschichte. Auf IETF 120 bestand Interesse, aber noch keine Klarheit, ob YANG 1.1, 1.2 oder 2.0 das Ziel sein sollte. Der Chair verlangte Motivation und Ziele und hielt fest, dass Git den Konsensprozess nicht ersetzt. Auf IETF 121 hatte ein offen rekrutiertes, selbst ausgewähltes Team die Issues bewertet. Das Ergebnis sollte zur WG zurückkehren. Ein zusammenfassender Draft sollte buy-in für eine Richtung suchen, nicht bereits vorhandenes Einvernehmen bescheinigen.

RFC 7282 verlangt für rough consensus mehr als sichtbare Unterstützung. Begründete Einwände müssen gefunden, verstanden und behandelt werden. Für jedes Issue braucht es daher den diskutierten Text, die Einwände, die Antworten und eine abgegrenzte Bewertung der Chairs.

Sieben Belegstufen

Zuerst kommt der Inventarbeleg: Issue, Autor, Beispiel, Zustand und Zeit. Dann der Klassifizierungsbeleg: Position in Revision 00, Grund und Alternative. Drittens folgt der Konsensbeleg aus Mailingliste, Sitzung, Einwänden, Antworten und Chair-Bewertung. Viertens folgt der normative Beleg mit genauem Text einer späteren Spezifikation.

Fünftens muss Kompatibilität an Grammatik, Semantik, Modulen, Erweiterungen, Deviations, Clients und Servern geprüft werden. Sechstens folgen unabhängige Parser, Compiler, Negativtests und Interoperabilität. Siebtens belegen gestufte Einführung, Beobachtung, Rollback und Ergebnis den Betrieb.

Revision 00 ist vor allem auf der zweiten Stufe stark. Das ist nützlich, aber kein Ersatz für die folgenden fünf.

Der YANG-2.0-Draft behandelt die Sprache. Module versioning behandelt Revisionen und Verzweigungen, schema comparison Differenzen, module filename Repository-Namen und YANG Packages die Zusammensetzung. Das Vier-Wege-Dokument definiert diese Mechanismen nicht; sie beweisen umgekehrt keinen Konsens über seine Einteilung.

Hersteller sollten „aufnehmen“ als Start einer Machbarkeitsprüfung lesen. Tool-Betreuer brauchen Versuchszweige und Korpora. Betreiber sollten beobachten, nicht migrieren. In Heng Lus Rahmen gehört die Kategorie zur symbolischen Ebene der Koordination. Die Realitätsebene beginnt, wenn genauer Text kompiliert, unabhängige Werkzeuge übereinstimmen und Betreiber Folgen beobachten und rückgängig machen können.

Quellen

Dokument und Verlauf: YANG Next Agreement Revision 00, Datatracker, Historie.

Prozess und Kontext: NETMOD-Protokoll IETF 120, NETMOD-Protokoll IETF 121, RFC 7282, RFC 7950, YANG-2.0-Draft Revision 00.

Deutungsrahmen: Minimum Initial Specification, On Reality Layers, Running Code Primary.