Zusammenfassung

  • Die IESG teilte am 28. August mit, dass Security Dispatch beendet ist, seine Mailingliste geschlossen wird und die Funktion in DISPATCH für ART, SEC und die Nicht-Transport-Themen von WIT aufgeht.
  • Der Zusammenschluss braucht eine Übergabe auf Vorschlagsebene: bearbeitete Version, alter Thread, Ergebniswortlaut, Konsensstatus, Befugnisklasse, Ziel, nächster Akteur und Bedingung für eine erneute Befassung.

Der Eingang zieht um, Sicherheitsarbeit bleibt möglich

Die Abschlussmitteilung nennt Christopher Inacio und Deb Cooley als IESG-Kontakte. Sie betont zugleich, dass die Security Area weiterhin neue Ideen zum Dispatch ermuntert. Geschlossen werden die eigenständige Gruppe und ihre Liste, nicht der Weg für neue Sicherheitsarbeit.

Der Nachfolger war bereits formal vorbereitet. Am 2. Juli genehmigte die IESG die aktuelle DISPATCH-Charta. Sie umfasst Vorschläge aus ART, SEC und den nicht transportbezogenen Teilen von WIT. Schon am 30. Juni fand ein gemeinsames Interimstreffen statt; beim IETF 126 folgte eine einheitliche DISPATCH-Sitzung.

Die Bündelung ist plausibel. Ein Vorschlag zu Identität, E-Mail oder Webanwendungen kann mehrere Fachgebiete berühren. Ein gemeinsamer Eingang erspart dem Einreicher, die interne Zuständigkeitskarte vor der ersten fachlichen Prüfung richtig erraten zu müssen.

DISPATCH erteilt jedoch keine Normgenehmigung. Die Charta erlaubt die Weiterleitung an eine bestehende Arbeitsgruppe, die Empfehlung eines BoF, die Vorbereitung einer neuen WG-Charta, einen Hinweis auf mögliches AD-Sponsoring, die Einrichtung einer Diskussionsliste sowie Aufschub oder Ablehnung. Diese Hinweise sind nicht bindend. Können die Vorsitzenden keinen Konsens feststellen, ist eine Rückmeldung nicht garantiert. Abgesehen von engen administrativen Dokumenten mit Zustimmung der zuständigen Area Directors bearbeitet die Gruppe keine Dokumente bis zum Abschluss.

Die sechs Juni-Ergebnisse haben sechs Bedeutungen

Am gemeinsamen Interimstreffen nahmen rund fünfzig Personen teil. Anschließend veröffentlichten die Vorsitzenden sechs Einzelergebnisse und baten um Widerspruch, falls ihre Feststellung des Rough Consensus falsch sei.

Bei einem Vorschlag erwog der Einreicher den Independent Submission Editor; ausdrücklich war dies ein möglicher eigener Weg und keine Dispatch-Handlung. Zwei Punkte wurden nicht präsentiert. Für einen sah die IETF keine Aktion. Bei einem weiteren gab es vorerst keine IETF-Aktion; zuvor sollten mehr unabhängige Implementierungsinteressenten und ein Diskussionsort entstehen. Ein fünfter Punkt wurde zum DAWN-BoF und dessen Organisationsarbeit verwiesen.

„Nicht präsentiert“ ist keine technische Ablehnung. „Derzeit keine Aktion“ ist kein dauerhaftes Verbot. Die Empfehlung eines BoF gründet keine WG. Werden diese Zustände nach dem Zusammenschluss nur noch als „von SECDISPATCH behandelt“ bezeichnet, erhält ein Ratschlag rückwirkend falsche Autorität.

RFC 7957 trennt die Rollen: Eine DISPATCH-artige WG bewertet neue Arbeit und sucht einen Ort, schließt die Arbeit aber nicht ab. Sie kann festhalten, warum etwas nicht verfolgt wurde. In Grenzfällen entscheiden die zuständigen Area Directors und Vorsitzenden über das Forum. RFC 2418 erlaubt dem Area Director nach Beratung mit der Gruppe eine Neuausrichtung, neue Vorsitzende oder die Auflösung und lässt eine Berufung an die IESG zu.

Ein Register überträgt Status, nicht Anspruch

Zum Recherchezeitpunkt blieb das öffentliche SECDISPATCH-Archiv erreichbar und zeigte 1.699 Nachrichten. Das garantiert keine ewige Verfügbarkeit und belegt keinen Verlust. Offen bleibt die Verbindung zwischen altem Befund und heutigem Zustand.

Jede materiell behandelte Vorlage braucht eine Zeile mit stabiler Identität, Internet-Draft-Version, letztem relevantem Thread, Sitzung, Ergebniswortlaut, Konsensstatus und Befugnisklasse. Hinzu kommen Ziel, nächster Handlungsträger, Rückkehrbedingung, Status am Übergabestichtag, fortbestehendes Archiv und spätere DISPATCH-Einträge. Eine Korrektur muss alten Wert, Datum und verantwortliche Stelle erhalten.

Das schafft kein Recht auf Sitzungszeit oder erneute Behandlung. Es verhindert, dass Vorsitzendenzusammenfassung, Rough Consensus, AD-Entscheidung und selbst gewählter Publikationsweg ineinanderfallen.

Die Abschlussmitteilung verweist auf die falsche RFC

Laut Mitteilung bleiben neue Ideen „gemäß RFC7975“ willkommen. RFC 7975 beschreibt jedoch eine Request-Routing-Redirection-Schnittstelle für gekoppelte Content Delivery Networks. Die genehmigte DISPATCH-Charta verweist auf RFC 7957, die Best Current Practice zu DISPATCH-artigen Gruppen.

Es gibt keinen Beleg, dass der Zahlendreher den Zusammenschluss oder ein Ergebnis veränderte. Als dauerhaftes Wegweiser-Dokument sollte die Mitteilung dennoch berichtigt oder annotiert werden.

Die Quellen belegen weder einen gestrandeten Vorschlag noch künftigen Archivverlust, Bindungswirkung alter Hinweise oder einen Anspruch auf erneute Anhörung. Dass auf der geprüften IETF-126-Materialseite keine Minuten sichtbar waren, beweist nicht das Fehlen anderer Ergebnisaufzeichnungen. Das Register ist Daniel Kades Empfehlung, keine angekündigte IETF-Verpflichtung.

Quellen