Zusammenfassung

  • DAWN war am 27. August 2026 weiterhin eine Proposed Group. Die erste Charta 00-00 befand sich in der internen IESG/IAB-Prüfung; die Abstimmung betraf nur die Bereitschaft zur externen Prüfung.
  • NETCONF war bereits Active, doch 20-02 blieb ein Recharter-Vorschlag. Datatracker bezeichnete Version 20 ausdrücklich als aktuell genehmigte Charta.
  • RFC 2418 trennt Ausarbeitung, interne und öffentliche Prüfung, IESG-Genehmigung sowie Erfassung und Bekanntgabe durch das Sekretariat. Erst diese Entscheidungskette schafft oder ändert den institutionellen Auftrag.
  • Auch eine genehmigte Charta erlaubt die Bearbeitung eines Problemraums. Sie adoptiert keinen bestimmten Internet-Draft, belegt keinen technischen Konsens, genehmigt keinen RFC und erzwingt keine Einführung.

Der neueste Text und der geltende Text sind zwei Objekte

Eine Charta hat eine Textgeschichte und eine Wirkungsgeschichte. Die Textgeschichte zählt Fassungen und Änderungen. Die Wirkungsgeschichte zählt Entscheidungen, die einer Fassung institutionelle Geltung geben oder diese beenden. Ein Diff kann die erste Geschichte zuverlässig zeigen; die zweite braucht einen zurechenbaren Beschluss.

Bei einer Gründung ist die genehmigte Charta bis zu diesem Beschluss ausdrücklich nicht vorhanden. Ausführliche Ziele, Vorsitzende, Listen und Termine ändern das nicht. Bei einem Recharter existieren dagegen Gruppe und Auftrag schon. Die bisher genehmigte Fassung bleibt maßgeblich, während die mögliche Nachfolgerin geprüft wird.

Ein einzelner latest-Verweis macht deshalb zwei entgegengesetzte Fehler. Er erfindet für DAWN einen noch nicht geschaffenen Auftrag und lässt für NETCONF die genehmigte Version 20 vorzeitig verschwinden. Ein belastbares Register hält den neuesten Vorschlag und die aktuell genehmigte Charta getrennt; vor einer Erstgründung ist der zweite Wert bewusst leer.

Die Verwechslung lenkt Aufmerksamkeit. Ein scheinbar genehmigtes Thema erhält Sitzungszeit, Editoren und Prototypen. Individuelle Drafts wirken wie eine Auswahl der Arbeitsgruppe. Nachbargruppen oder externe Normungsorganisationen weichen aus. Unternehmen sprechen von einer IETF-Richtung, obwohl erst ein Antrag vorliegt. Wird der Text später verkleinert, verschwinden die bereits gebildeten Abhängigkeiten nicht mit dem Statusetikett.

DAWN hatte einen prüfbaren Antrag

Die DAWN-Seite trug die Überschrift „Proposed WG Discovery of Agents With Names“. Der Gruppenstatus lautete Proposed, die Charta charter-ietf-dawn-00-00, der Verfahrensstand Start Chartering/Rechartering (Internal Steering Group/IAB Review).

Der Antrag beschrieb die Ermittlung von KI-Agenten und Ressourcen, lokale, organisationsinterne und organisationsübergreifende Umgebungen, mögliche Mechanismen, vorgesehene Vorsitzende, Ergebnisse, Termine und ausdrückliche Ausschlüsse. Diese Konkretheit machte eine ernsthafte Prüfung möglich. Sie setzte den Antrag nicht selbst in Kraft.

Die Abstimmungsseite stellte eine begrenzte Frage: „Is this charter ready for external review?“ Éric Vyncke hatte Yes eingetragen, Mohamed Boucadair Block; die übrigen aufgeführten Mitglieder standen auf No Record. Die Zusammenfassung sah genügend Positionen für diesen Schritt, sobald der Block gelöst wäre.

Boucadair unterstützte die Arbeit grundsätzlich, verlangte jedoch klarere Auslöser und Betriebsmodelle für Discovery, eine Trennung lokaler und organisationsübergreifender Fälle, belastbare Vertrauensgrenzen sowie eine Antwort auf die Frage, ob ein einziges Protokoll den Umfang tragen könne. Das war ein substanzieller Einwand gegen den vorgeschlagenen Zuschnitt. Es war weder eine endgültige Ablehnung von DAWN noch ein dauerndes persönliches Vetorecht.

Auch Yes bedeutet nur eine Antwort auf die gestellte Frage. Wer „bereit für externe Prüfung“ als „Arbeitsgruppe genehmigt“ wiedergibt, entfernt das Entscheidungsobjekt. Die Historie dokumentierte 00-00, die Eröffnung der Abstimmung und den Wechsel in die interne Prüfung am 24. August sowie den Block am 25. August. Einen Gründungsbeschluss dokumentierte sie nicht.

Das DAWN-BoF bei IETF 126 hatte bereits Begriffe, Anwendungsfälle, Anforderungen und einen Chartaentwurf erörtert. Ein BoF liefert Belege für ein Problem, für Fachwissen und für Streitpunkte. Es überträgt die Gründungsentscheidung nicht von der IESG auf die Teilnehmenden.

Nach dem Stichtag kann DAWN genehmigt, geändert, zurückgegeben oder aufgegeben werden. Der datierte Befund sagt keine Variante voraus. Er verhindert lediglich, dass eine spätere Genehmigung rückwirkend aus Vorarbeiten bereits autorisierte WG-Arbeit macht.

NETCONF behielt während der Prüfung Version 20

NETCONF stand auf der anderen Seite der institutionellen Schwelle. Die Gruppenseite führte den Status Active und ein etabliertes Arbeitsfeld um NETCONF, RESTCONF, YANG, Telemetrie und Netzmanagement.

Die Chartaseite zeigte charter-ietf-netconf-20-02, zuletzt geändert am 12. August, in der internen Prüfung als Recharter. Zugleich stand dort die maßgebliche Einschränkung: Die angezeigten Informationen gehörten zu einem Vorschlag; die aktuell genehmigte Charta sei Version 20.

Damit existierten drei Identitäten nebeneinander: NETCONF als aktive Institution, Version 20 als geltender Umfang und 20-02 als Änderungsantrag. Die Prüfung des dritten Objekts setzte das zweite nicht aus.

Die NETCONF-Abstimmung fragte ebenfalls nur nach der Bereitschaft für externe Prüfung. Christopher Inacio hielt einen Block, weil Meilensteine fehlten. Mahesh Jethanandani stimmte Yes, mehrere Mitglieder No Objection. Laut Zusammenfassung konnte der Schritt nach Auflösung des Blocks passieren. Das war keine Inkraftsetzungsabstimmung.

Verlangt die IESG Änderungen, kann eine spätere Fassung zum echten Kandidaten werden. Bei Rückzug bleibt Version 20. Bei Genehmigung müssen Beschluss und Bekanntgabe die endgültige Fassung, die ersetzte Charta und den Wirkungszeitpunkt benennen. Für keine dieser Möglichkeiten muss 20-02 schon seit ihrer Veröffentlichung als geltend fingiert werden.

Eine vorgezogene Geltung kehrt zudem die Beweislast um. Vor dem Beschluss muss die Erweiterung begründen, warum neue Arbeit zu NETCONF gehört. Nachdem Sitzungen, Adoptionsaufrufe und Implementierungen auf einem Schattenumfang beruhen, sollen Prüfer erklären, warum sie eine angeblich bestehende Befugnis „entziehen“. Aus Antragsprüfung wird Bestätigung versunkener Kosten.

Beteiligung liefert Gründe, die IESG trägt die Entscheidung

Am Stichtag blieb RFC 2418 als Teil von BCP 25 die veröffentlichte Grundlage. Vorgesehene Vorsitzende und zuständiger Area Director entwickeln die Charta üblicherweise gemeinsam. Die IAB berät, die IESG genehmigt abschließend. Nach interner Prüfung wird der Vorschlag einer breiteren Community vorgelegt. Die IESG kann genehmigen, Änderungen verlangen oder die Gründung ablehnen. Erst anschließend erfasst und verkündet das Sekretariat die genehmigte Gruppe.

RFC 2418 nennt die Charta einen Vertrag zwischen IETF und Arbeitsgruppe über eine Gruppe von Aufgaben. Gemeint ist eine institutionelle Arbeitsgrenze, weder Handelsvertrag noch politische Vollmacht aller Betroffenen. Der Vertrag verbindet ein offenes Forum, Verfahrensführung und einen begrenzten Auftrag.

Die Grenze ist praktisch. Vorsitzende können Beiträge außerhalb des Umfangs vertagen, ohne Offenheit aufzugeben. Nachbargruppen können Überschneidungen erkennen. Andere Organisationen sehen, wann Abstimmung nötig ist. Mitwirkende können entscheiden, wo sie Zeit investieren. Ändern sich Voraussetzungen, bleiben Recharter, Führungswechsel oder Auflösung nachvollziehbare Optionen.

RFC 3710 verteilt die Rollen. Ein Impuls kann von Teilnehmenden oder einem Area Director kommen. Vorgesehene Vorsitzende machen daraus einen arbeitsfähigen Plan. Teilnehmende liefern Wissen, Unterstützung und Einwände. Die IAB prüft Architekturfolgen. Öffentliche Prüfung zeigt Datenschutz-, Sicherheits-, Betriebs- und Abgrenzungsfragen. Der Area Director koordiniert; die IESG verantwortet die institutionelle Entscheidung.

Dass Teilnahme keine Genehmigung ist, macht Prüfung nicht dekorativ. Ein guter Einwand kann den Umfang verkleinern, eine Liaison hinzufügen, ein Ergebnis teilen oder fehlende Reife zeigen. Beteiligung ist als Evidenz und kontrollierbarer Widerspruch legitim; sie muss nicht zu einer erfundenen Generalvollmacht aller Anwesenden aufgeblasen werden.

Für wichtige Arbeit außerhalb der Charta gibt es Wege: Recharter, eine andere Arbeitsgruppe, Arbeit außerhalb einer WG oder eine Neugründung. Grenzachtung ist nicht Untätigkeit.

Eine Charta genehmigt Fragen, nicht Antworten

Nach der Genehmigung darf die Arbeitsgruppe Probleme innerhalb ihres Umfangs organisieren. Eine individuelle Einreichung kann untersucht werden. Adoption eines Internet-Drafts wählt eine Arbeitsgrundlage und ist kein Konsens über jeden Satz. Rough Consensus, Working Group Last Call, IESG-Prüfung und RFC-Veröffentlichung sind spätere Handlungen. Stream und Kategorie bestimmen zusätzlich den Status des veröffentlichten Dokuments.

Der Betrieb liegt noch weiter entfernt. RFC 3935 beschreibt eine IETF, die nützliche technische Dokumente entwickelt, das Internet aber weder kontrolliert noch zur Nutzung zwingen kann. Einführung braucht eine ausgewählte Fassung, Verantwortliche, Tests, Änderungsumfang, Rückfallbedingungen und Beobachtungen aus dem laufenden System.

Auch draft-ietf-procon-2418bis-04 zeigte diese Stufung. Am 27. August war das Dokument ein WG Document mit IESG-Status I-D Exists. Es würde RFC 2418 und RFC 3934 ablösen, falls es genehmigt wird. Die Bedingung gehört zum Befund.

Der Drafttext beschreibt die Charta als Bindung an einen Umfang und stellt klar, dass Draft-Adoption keinen Konsens über den Inhalt beweist. Die PROCON-Charta erlaubt die Zusammenführung einer benannten Kette von Prozess-RFCs und verlangt für weitere wesentliche Themen einen Recharter. Der Auftrag, einen Nachfolger zu erarbeiten, genehmigt ihn nicht vorab.

Der Übergabebeleg

Ein belastbarer Datensatz nennt zuerst die Handlung: INITIAL_CHARTER oder RECHARTER. Er hält Gruppenname, Kürzel, Status, Vorschlagskennung, Revision und exakten Textfingerabdruck fest. Ein unabhängiges Feld enthält die aktuell genehmigte Charta samt Fingerabdruck oder vor der Gründung einen ausdrücklichen Nullwert.

Der Umfangsteil führt neue, entfernte und beibehaltene Aufgaben, Ausschlüsse, Ergebnisse, Nachbargruppen und externe Koordination auf. Der Prüfungsteil hält Area Director, Vorsitzende, Eröffnungsdatum, genaue Abstimmungsfrage, Positionen, Blocks, Auflösungsbedingungen, IAB-Beratung, externe Bekanntmachung und Behandlung wichtiger Einwände fest.

Der Entscheidungsteil nennt IESG-Ergebnis, öffentliche Begründung, Datum, Sekretariatsmeldung, Wirkungszeit und ersetzte Charta. Genehmigung, Rückgabe zur Änderung, Fortführung der alten Charta, Rückzug, Ablehnung und Auflösung sind vollständige Ergebnisse.

Zu jeder genehmigten Charta gehören zwei Negativaussagen: Sie belegt keinen Konsens über ein bestimmtes Dokument und verlangt keine Implementierung. Diese Grenzen schwächen die Charta nicht. Sie machen ihren tatsächlichen Auftrag übertragbar, ohne ihn zu vergrößern.

Quellen

  1. IETF Datatracker: Gruppen im Chartering oder Rechartering
  2. IETF Datatracker: vorgeschlagene DAWN-Arbeitsgruppe
  3. IETF Datatracker: Abstimmung zur DAWN-Charta
  4. IETF Datatracker: Historie der DAWN-Charta
  5. IETF Datatracker: DAWN-BoF-Agenda bei IETF 126
  6. IETF Datatracker: vorgeschlagener NETCONF-Recharter
  7. IETF Datatracker: genehmigte NETCONF-Charta, Version 20
  8. IETF Datatracker: aktive NETCONF-Arbeitsgruppe
  9. IETF Datatracker: Abstimmung zur NETCONF-Charta
  10. RFC 2418: Richtlinien und Verfahren für IETF-Arbeitsgruppen
  11. RFC 3710: Charta der IESG
  12. RFC 6292: Anforderungen an Werkzeuge für WG-Chartas
  13. IETF Datatracker: Status von draft-ietf-procon-2418bis
  14. IETF Datatracker: Text von draft-ietf-procon-2418bis
  15. IETF Datatracker: PROCON-Charta
  16. RFC 3935: Auftrag der IETF
  17. RFC 9281: Beteiligte Einheiten im IETF-Standardisierungsprozess