Zusammenfassung

  • BBF erklärte, WT-477i2 sei von den IETF-BGP-Modulen abhängig, und bat um Information zu einem Zieltermin. Das ist ein dokumentierter Bedarf, keine IETF-Publikationszusage.
  • IDR teilte am 1. August mit, der Entwurf befinde sich in Working Group Last Call; Area-Director-Prüfung, IETF-wide Last Call und IESG-Prüfung stünden vor der RFC-Editor-Warteschlange noch aus.
  • Der zuständige Routing Area Director schrieb am 21. August, die WGLC bleibe offen. Schweigen gelte nicht als Hinweis auf Publikationsreife.
  • Der Datatracker führt Version 21 als Internet-Draft, im WG-Zustand „Waiting for Implementation“ und im IESG-Zustand „I-D Exists“, ohne Telechat-Termin.
  • Ein belastbarer Abhängigkeitsbeleg verbindet Dokument- und Versionsstände, ohne Anfrage, Review, Konsens, Warteschlange und RFC gleichzusetzen.

Der BBF-Hinweis benennt einen Bedarf, nicht die Entscheidung

Die BBF-Folgeliaison vom Dezember 2025 erklärt, dass die in WT-477i2 entwickelten YANG-Modelle vollständig vom damaligen ietf-bgp-Modul und seinen in draft-ietf-idr-bgp-model-18 genannten Abhängigkeiten abhängen. Sie reicht einen Arbeitsentwurf ein, beschreibt WT-477i2 als kurz vor der Fertigstellung und fragt nach Zielterminen für die IETF-Veröffentlichung.

Das ist eine nützliche, präzise Offenlegung. Sie sagt, welches BBF-Dokument sich auf welche IETF-Arbeit bezieht und welche Information BBF erbittet. Sie sagt nicht, dass IDR einen Termin angenommen hat, ein RFC reserviert ist oder das Modell in einem Netz betrieben wird. Eine Abhängigkeit kann sachlich zwingend sein, ohne dem abhängigen Akteur die Verfügung über den offenen Review zu geben.

Diese Grenze ist mit Zusammenarbeit vereinbar. RFC 2418 verlangt, bei überlappender Arbeit relevante externe Standardsarbeit und angemessene Liaison zu berücksichtigen. Das verhindert unnötige Doppelarbeit. Es verwandelt die Liaison aber nicht in eine Generalvollmacht, über Charter, Review und Entscheidung eines IETF-Arbeitsdokuments zu bestimmen.

IDR beantwortet die Anfrage mit einem Zustandsweg

Die IDR-Antwort ordnet den Entwurf dem Working Group Last Call zu. Danach nennt sie Area-Director-Review, IETF-weiten Last Call und umfassende IESG-Prüfung vor dem Eintritt in die RFC-Editor-Publikationswarteschlange. Interessierte Personen beim BBF werden eingeladen, sich auf der IDR-Liste mit technischem Feedback, Diskussion und ausdrücklicher Unterstützung zu beteiligen.

Damit ist Beteiligung nicht wertlos, aber richtig eingeordnet. Feedback kann Mängel zeigen oder technische Unterstützung dokumentieren. Es entscheidet nicht automatisch über Konsens, IESG-Status oder Veröffentlichung. Die Antwort sagt auch nicht, dass ein von BBF gewünschter Termin erreichbar sei. Sie verbindet die Organisationen über einen offenen Beitragsweg, nicht über eine fingierte Lieferpflicht.

Der Listeneintrag vom 21. August schärft den damaligen Status. Version 21 war eingestellt, die WGLC blieb jedoch offen. Der Area Director will positive Unterstützung und abgeschlossene Reviews sehen, wenn er Konsens beurteilt; Schweigen sei kein Anzeichen für Publikationsreife. Weil die drei IDR-Chairs Mitautoren sind, ruft der Area Director den Konsens für diese WGLC auf, während ein benannter Shepherd die Prüfung begleitet.

Das ist eine nachvollziehbare Rollenaufteilung, kein Verdachtsmoment. Sie unterscheidet Autorenschaft, Review und Entscheidung. Wer einen Status liest, darf daher nicht aus fehlender Listenpost einen Konsens machen oder aus einem externen Terminwunsch einen internen Beschluss.

Ein Internet-Draft ist kein vorgezogener RFC

Die Datatracker-Seite für Version 21 nennt sie Internet-Draft vom 14. August 2026 und weist darauf hin, dass Internet-Drafts aktualisiert, ersetzt oder obsolet werden können und nur als work in progress zitiert werden sollen. „Waiting for Implementation“, „I-D Exists“ und kein Telechat sind keine RFC-Editor-Warteschlange und keine Publikation.

Die IDR-Charter macht Entwicklung und Pflege von BGP als Interdomain-Protokoll für IPv4 und IPv6 zum vorrangigen Ziel. Sie bezeichnet Aufgabenbereich, nicht die Reife jedes einzelnen Entwurfs. RFC 2026 beschreibt Standardsstufen und verlangt eine konkrete IESG-Aktion für Proposed Standard; späteres Erfahrungswissen kann vor weiterem Fortschritt Änderungen oder Rücknahme nach sich ziehen.

Der Status muss deshalb in eigenen Zeilen stehen: BBF-Dokument samt verwiesener IETF-Version; WGLC-Eröffnung, Fortsetzung oder Schluss; abgeschlossene Prüfungen und Konsensdisposition; spätere IETF- und IESG-Akte; eine mögliche Warteschlangeneintragung; schließlich der RFC. Kein Feld kann für ein anderes sprechen. Auch ein späterer RFC würde nicht belegen, ob WT-477i2 ausgeliefert, interoperabel umgesetzt oder bei einem Betreiber aktiv ist.

Eine kleine Statusquittung genügt

Die vorgeschlagene Quittung enthält WT-477i2-Version, IETF-Entwurf und Version, Datum und Inhalt der Anfrage, WGLC-Zustand, Review- und Konsensbeleg, nachfolgende IETF/IESG-Zustände, Queue-Eintrag und RFC. Neben jeder Zeile steht ihr negativer Umfang: Abhängigkeit ist keine Zusage; offene WGLC ist weder Ablehnung noch Datumsprognose; Queue ist nicht Publikation; RFC ist nicht Einsatznachweis.

Die Quellen erlauben keine Aussage zu Betreiber-Rollout, Vendor-Support, Interoperabilität oder Geschäftswirkung. Sie erlauben ebenso wenig die Behauptung eines Streits, Vetos oder schuldhaften Verzugs. Ihre begrenzte, aber verwertbare Aussage lautet: Die Review-Kette war offen, und der angefragte Termin ist nicht als Entscheidung dokumentiert.

Quellen