Zusammenfassung

  • OPSAWG übernahm VELOCE und veröffentlichte Revision 00 am 25. August 2026 als Working-Group-Dokument. Dieser Status ist kein RFC, kein BCP und keine abschließende IETF-Regel.
  • Die zugeschriebene Sitzungszusammenfassung sagt, der IANA-Zeiger sei bestätigt. Revision 00 erklärt zugleich ausdrücklich, es gebe keine IANA-Aktionen. Pull Request 49 mit Zuständen, Hashes und Genehmigungswegen war zum Recherche-Stichtag offen und nicht zusammengeführt.
  • Ein Ergebnis eines Projekttermins ersetzt keinen auf der Mailingliste bestätigten WG-Konsens. Ein Repository-Merge ersetzt weder die Entscheidung der WG noch die eines Area Director oder des IESG. Eine IANA-Zeile kann eine genehmigte Version dokumentieren, ohne ihre normative Bedeutung zu entscheiden.
  • Der Entwurf vermeidet bereits einen beweglichen Branch-Kopf: Die RFC-Referenz soll auf eine konkrete markierte Version zeigen. Offen bleibt die Verbindung von späterer Genehmigung, IANA-Abruf und -Prüfung sowie dem Konformitätsziel für Implementierungen.

Übernahme ist nicht Vorabgenehmigung jeder Folgeentscheidung

Der Abschluss des Übernahmeaufrufs vermerkt ausreichende Unterstützung und die Bitte, den individuellen Entwurf ohne weitere Änderung als draft-ietf-opsawg-veloce-yang-00 erneut einzureichen. Der Datatracker führt Revision 00 seit dem 25. August als WG-Dokument. Damit erhält die Gruppe die Verantwortung für den Text. Sie hat damit nicht schon jede spätere Frage über Registerpolitik, Abruf oder Fortführung entschieden.

VELOCE trennt die YANG-Datei vom RFC. Das RFC soll auf eine spezifische getaggte Repository-Version verweisen. Ein Hauptbranch kann sich nach Veröffentlichung ändern; ein benannter Commit oder Tag macht die damals gemeinten Bytes wiederauffindbar und prüfbar. Der Entwurf sieht ferner vor, dass ein übernommenes Modul in einem IETF-Repository aktualisiert werden kann und im RFC nur der Verweis auf die neue Version geändert wird. Diese Aufteilung beantwortet ein echtes Wartungsproblem. Für eine kleine, gründlich geprüfte Korrektur muss nicht notwendig das gesamte RFC neu ausgehandelt werden.

Sie nimmt jedoch dem RFC auch eine stillschweigende Bündelungsfunktion. Dort lagen bisher normativer Text, veröffentlichte Version, Genehmigungsakt und stabile Fundstelle zusammen. Nach der Trennung muss sichtbar werden, wer welche Bytes gewählt hat, durch welchen Akt sie aktuell wurden, wo sie wiederherstellbar sind und welche Version für eine Konformitätsbehauptung zählt.

Die Autoren haben diese Fragen vor IETF 126 selbst aufgeworfen. Eine öffentliche Zeigerdiskussion fragt, ob ein RFC auf einen Git-Tag, einen IANA-Eintrag oder ein anderes Ziel zeigen soll, was ein „neuester“ Zeiger bedeutet, welche Version Implementierer verwenden sollen und wie Konformität nach einer Änderung testbar bleibt. Das OPSAWG-Protokoll von IETF 126 bewahrt gegensätzliche Auffassungen zu GitHub, einer IETF-kontrollierten Umgebung, IANA-Veröffentlichung, Archivierung und Wiederherstellung. Die angesetzte Zeit lief aus, die Diskussion ging auf der Liste weiter. Das dokumentiert einen offenen Entwurfspunkt, nicht ein Fehlverhalten.

Die Zusammenfassung vom 25. August sagt zusätzlich, das GitHub-Repository bleibe für das Experiment erhalten, Beiträge könnten als Issue oder Pull Request erfolgen, Ansichten aus zweiwöchentlichen Treffen würden auf der Mailingliste zusammengefasst und Einwände führten vor einem Merge zu weiterer Diskussion. Sie nennt auch die bestätigte IANA-Indirektion. Gerade weil diese Aussagen nützlich sind, muss ihre Quelle richtig bezeichnet werden: Es handelt sich um eine zugeschriebene Projekttermin-Zusammenfassung, nicht um einen formellen WG-Konsensaufruf oder IESG-Beschluss. RFC 8874 gibt Arbeit in GitHub keinen Sonderstatus und verlangt, dass WG-Konsensentscheidungen auf der Mailingliste bestätigt werden. Ein Termin kann eine Lösung vorbereiten, aber diese Bestätigung nicht ersetzen.

Revision 00 selbst enthält dagegen die ausdrückliche Aussage, dass keine IANA-Aktionen vorliegen. Nach RFC 8126 dokumentiert ein expliziter No-Action-Abschnitt eine bewusste Feststellung für den betreffenden Entwurf. Er verbietet keine spätere gültige IANA-Anweisung. Er erlaubt aber nicht, die am Termin beschriebene Richtung so darzustellen, als sei sie bereits eine ausführbare Registrierung.

PR49 ist ein Vorschlag für eine Spur, nicht die bestehende Spur

Pull Request 49 war am Stichtag offen und nicht gemergt. Er schlägt ein Register für YANG-Datei- und Modulreferenzen vor, mit permanenten und vorgeschlagenen Zuständen, genauer URL, SHA-256, verantwortlichen Kontakten und Genehmigung über IESG oder andere festgelegte Wege. Das sind sinnvolle Trennungen: Der Hash bezeichnet Bytes, der Zustand trennt Kandidat und aktuelle Referenz, der Kontakt verortet Pflege, der Genehmigungsweg nennt die entscheidende Stelle.

Vorgeschlagene Felder sind jedoch noch keine öffentliche Registerregel. Das bestehende IANA-Register YANG Module Names folgt RFC Required und zeigt Name, Datei, Namespace, Prefix, Referenz und Hinweise. Es enthält derzeit nicht die von VELOCE vorgeschlagenen Felder für Hash, Genehmigungszustand, kontrollierenden Kontakt oder Entscheidungsbeleg. Daraus folgt nur eine nüchterne Grenze: Es gibt keinen Nachweis, dass IANA dieses neue Register eingerichtet, seine Regel akzeptiert oder eine VELOCE-Version abgerufen hat.

Die beteiligten Verben haben verschiedene Subjekte. Ein Autor reicht eine Änderung ein. Prüfer und Maintainer bearbeiten sie im Repository. Die WG bildet Konsens. Ein Area Director oder das IESG kann die im Text bestimmte Genehmigungsrolle ausüben. IANA führt eine abgegrenzte Registrierung aus. Die Registerzeile bewahrt die Identität einer Version. Tag, Merge, Konsens, Genehmigung und Eintrag können miteinander verbunden sein, doch keines dieser Ereignisse beweist automatisch die anderen.

Diese Grenze ist keine Absage an schnellere Pflege. Revision 00 verlangt schon einen festen Tag statt eines schwebenden Branchs und übernimmt Konsensverfahren. PR49 versucht, IANA mit Hashes und klaren Genehmigungswegen zu binden, nicht ihr freien Ermessensspielraum zu geben. Dass eine frühe WG-Revision einer noch offenen Detaildiskussion hinterherläuft, kann legitim sein. Unzulässig wäre lediglich, die Lücke als bereits erteilte Autorität zu behandeln.

Ein schlanker Beleg von Beschluss zu Verweis

Für jede spätere Moduländerung könnte VELOCE einen öffentlichen, verlinkten Beleg führen, der mindestens enthält:

  1. behauptete normative Wirkung und zuständige WG;
  2. Konsensaufruf auf der Liste, Öffnungs- und Schließzeit, wesentliche Einwände und Vorsitzendenentscheidung;
  3. genaue Entwurfs- oder Genehmigungsfassung, die die Registrierung verlangt, und Genehmigungsakteur;
  4. Repository-URL, unveränderlichen Commit, Tag und SHA-256;
  5. Autor, Prüfer, Merger und genehmigende Stelle als getrennte Rollen;
  6. IANA-Antragsteller, Zeitpunkt, abgerufene URL und Bytes sowie Prüfergebnis;
  7. alte und neue Registerzeile, Wirksamkeitszeit und Ablöseverbindung;
  8. Veröffentlichungs-, zuletzt genehmigte und getestete Konformitätsversion;
  9. Kompatibilität, Tests, Spiegel, Sicherung, Wiederherstellung, Rücknahme und Rückfall; sowie
  10. getrennte Belege für Implementierung und operative Übernahme.

Der Beleg schafft kein Vetorecht. Er nennt auch nicht ein konstruktives Treffen einfach Konsens, sondern verweist auf die spätere formelle Bestätigung. Ebenso macht er die IANA-Transaktion nicht zum fachlichen Urteil: Die zuständige Instanz entscheidet, ob ein Kandidat aktuell werden darf; IANA prüft und registriert das genehmigte Artefakt nach der beschlossenen Regel. Heng Lus Note 63 ist dabei ein institutionelles Denkmittel, kein Nachweis über VELOCE oder IANA. Verwahrung und Provenienz können eine Entscheidung prüfbar machen, ohne die Entscheidungsgewalt an sich zu ziehen.

Dasselbe gilt für Konformität. RFC 9907 bleibt der veröffentlichte BCP-Ausgangspunkt: Normative YANG-Aussagen werden wie normative RFC-Prosa behandelt, neue oder aktualisierte Module in IETF XML und YANG Module Names registriert. VELOCE mag eine andere Wartungsanordnung entwickeln; sie hat diese Grundlage am Stichtag nicht ersetzt. Die im RFC zitierte Version, die jüngste genehmigte, die aktuelle IANA-Zeile und die getestete Version können gleich sein, müssen es aber nicht.

Sources

  1. OPSAWG charter
  2. VELOCE Datatracker record
  3. IETF 126 OPSAWG minutes
  4. Pull request 49
  5. Heng Lu Note 63
  6. IANA YANG parameters
  7. OPSAWG VELOCE adoption result
  8. VELOCE pointer discussion
  9. 25 August VELOCE call summary
  10. draft-ietf-opsawg-veloce-yang-00
  11. RFC 8126
  12. RFC 8874
  13. RFC 8875
  14. RFC 9907