Zusammenfassung

  • Am 14. September erschien Revision 00-01 der vorgeschlagenen IETF-Charta für Agent Communication Protocols. Sie befindet sich weiterhin in der internen Prüfung durch Steering Group/IAB und steht auf der IESG-Telechat-Agenda für den 17. September; Agentproto ist noch keine eingesetzte Arbeitsgruppe.
  • Neu ist die Koordination mit einschlägigen Standardisierungs- und Open-Source-Vorhaben außerhalb der IETF, um Betriebspraxis zu verstehen und unnötige Abweichungen zu vermeiden.
  • Der Satz davor weist Entscheidungen über Änderungen an Protokollen anderer IETF-Arbeitsgruppen ausdrücklich den jeweils zuständigen Gruppen zu. Externe Erkenntnis und interne Entscheidungszuständigkeit laufen auf getrennten Bahnen.
  • Daniel Kade schlägt einen zweigleisigen Koordinationsbeleg vor. Er ist weder Bestandteil der vorgeschlagenen Charta noch eine Vorgabe des IESG.

Eine neue Verbindung mit eingebauter Zuständigkeitsgrenze

Die Fassung 00-01 beschreibt drei parallele Vorhaben: ein Grundprotokoll für Dialoge zwischen Nutzern, Agenten und Werkzeugen, eine Referenzarchitektur sowie ein Informationsdokument über Anwendungsfälle und Anforderungen.

Am Ende dieser Aufgabenbeschreibung regeln zwei aufeinanderfolgende Sätze Abhängigkeiten. Braucht Agentproto eine Änderung oder Erweiterung eines Protokolls, das eine andere IETF-Arbeitsgruppe spezifiziert hat, soll die Frage dieser Gruppe vorgelegt werden. Sie entscheidet, wie damit umzugehen ist. Technische Nähe hebt die bisherige Änderungszuständigkeit nicht auf.

Der nächste Satz wurde mit 00-01 eingefügt. Die mögliche neue Arbeitsgruppe soll sich auch mit einschlägigen Standardisierungs- und Open-Source-Aktivitäten außerhalb der IETF abstimmen, vorhandene Implementierungspraxis verstehen und vermeidbare Divergenz verhindern.

Das ist keine bloße Höflichkeitsklausel. Laufender Code kann eine unhaltbare Annahme sichtbar machen. Ein Interoperabilitätstest kann zeigen, dass zwei saubere Entwürfe gemeinsam scheitern. Eine externe Spezifikation kann bereits Bausteine für Identität, Autorisierung oder Verschlüsselung verwalten. Solche Erkenntnisse gehören in die technische Beurteilung.

Sie bringen ihre Entscheidungsbefugnis jedoch nicht mit. Ein externes Projekt kann IETF-Konsens nicht allein durch Teilnahme erzeugen. Umgekehrt verleiht eine IETF-Entscheidung keine Kontrolle über Repository, Lizenz oder Zeitplan eines externen Projekts. Koordination wird belastbar, wenn beide Seiten ihren eigenen Beschluss fassen können.

Der Status bleibt ein Vorschlag in Prüfung

Der Datatracker-Eintrag führt das Dokument weiterhin unter Start Chartering/Rechartering (Internal Steering Group/IAB Review). Außerdem ist es für den IESG-Telechat am 17. September angesetzt. Das belegt einen Prüfungsschritt, nicht dessen Ausgang.

Gegenüber 00-00 enthält die neue Fassung vier sichtbare Änderungen. In der Agentendefinition fällt intelligent weg. Der Sicherheitsabschnitt nennt nun auch den Datenaustausch mit Nutzern. Ein Grammatikfehler wird behoben. Hinzu kommt der Satz über externe Koordination.

Die Historie und das Ballot-Protokoll zeigen davorliegende Fragen. Am 10. September fragt ein Kommentar nach Zusammenarbeit mit Nicht-IETF-Gruppen. Ein weiterer spricht den Schutz von Nutzerdaten und zusätzliche Fortschrittsmeilensteine an. Am 13. September wird ein Meilenstein für die Einreichung des Dialogprotokolls als Proposed Standard im März 2028 ergänzt; 00-01 folgt am nächsten Tag.

Chronologie und textliche Entsprechung sind beobachtbar. Eine eindeutige Ursache ist es nicht. Die geprüften öffentlichen Seiten enthalten keine zeilenweise Disposition, die Kommentar, Entscheider, Änderung und Begründung verknüpft. Deshalb darf aus „danach geändert“ nicht „dadurch geändert“ werden.

Auch die Abstimmungen beim Agentproto-BoF auf der IETF 126 werden durch 00-01 nicht nachträglich vereinheitlicht. Dort betrafen Reichweite, Ergebnisse und Gruppenbildung unterschiedliche Fragen mit unterschiedlichen Grundgesamtheiten. Die Charterrevision ist ein späterer Prozessgegenstand und weiterhin kein abgeschlossenes Mandat.

Was die Liaison-Regeln tatsächlich leisten

RFC 4052 legt formelle IETF-Liaison-Beziehungen in die Verantwortung des IAB. Sie sollen so informell wie praktisch möglich bleiben und Doppelarbeit verhindern, ohne eine Organisation an ihrem eigenen Mandat zu hindern.

RFC 4691 beschreibt die Liaison-Funktion als bidirektionalen Informationskanal. Ein Liaison Manager beschafft Wissen, das IETF-Entscheidungen verbessert. Als IETF-Position darf er jedoch nur einen ermittelten Konsens vermitteln; die persönliche Auffassung erhält durch das Amt keinen institutionellen Rang.

RFC 4053 ordnet Eingang, Weiterleitung, Behandlung und Antwort auf Liaison Statements. Ein Schreiben, das die Richtung einer Arbeitsgruppe beeinflussen will, wird angemessen berücksichtigt, aber nicht wegen seines Absenders automatisch übernommen. Eine Frist erhöht möglicherweise den Zeitdruck, nicht die sachliche Entscheidungsbefugnis.

Daraus folgt nicht, dass jedes Gespräch mit einem Open-Source-Maintainer formalisiert werden muss. Öffentliche Issues, Implementierungsberichte, Interop-Veranstaltungen und individuelle Beiträge können geeigneter sein. Übertragbar ist vielmehr die Provenienzregel: Sprecher, Vertretungsstatus, Artefaktversion und Kanal müssen beim Übergang erkennbar bleiben.

Zwei Spuren in einem Koordinationsbeleg

Die Eingangsspur verzeichnet Problem, externes Artefakt, genaue Version oder Commit, verantwortliche Stelle, Datum, Kanal, Aussage und Prüfstatus. Sie unterscheidet zwischen formellem Liaison Statement, Organisationsposition, individuellem Beitrag, Implementierungsbeobachtung und unbestätigtem Bericht.

Die Entscheidungsspur nennt das betroffene Agentproto-Ergebnis, die zuständige IETF-Stelle, die öffentliche Diskussion, den Stand und die Begründung. Ein kleines Vokabular genügt: beobachtet, geprüft, übernommen, angepasst übernommen, abgelehnt, vertagt oder Maßnahme beim externen Eigentümer erbeten.

Liegt das Protokoll bei einer anderen IETF-Arbeitsgruppe, verweist der Beleg auf deren Entscheidung, statt sie zu ersetzen. Muss ein externes Projekt handeln, dokumentiert er Bitte und eigenständige Antwort, keinen Befehl. Eine ausgehende Mitteilung im Namen der IETF trägt den Konsensstand, auf dem diese Vertretung beruht.

Private Gespräche und sensible Sicherheitsdetails müssen nicht veröffentlicht werden. Sichtbar bleiben muss, wer eine Behauptung einbrachte, wer sie prüfte, wer entscheiden durfte und was offen blieb. So werden weder ein bekannter Teilnehmer zur Institution noch Beratung zur Zustimmung oder Verbreitung zum Standardbeschluss. Der Beleg ist Daniel Kades Vorschlag.

Quellen

  1. Agentproto-Charterentwurf 00-01 mit Meilensteinen
  2. Agentproto-Charterentwurf 00-00 mit Meilensteinen
  3. Historie des Agentproto-Charterentwurfs
  4. Ballot zum Agentproto-Charterentwurf
  5. Datatracker-Seite des Chartervorschlags
  6. RFC 4052 — IAB-Verfahren für IETF-Liaison-Beziehungen
  7. RFC 4053 — Umgang mit Liaison Statements
  8. RFC 4691 — Leitlinien für IETF-Liaison-Beauftragte
  9. RFC 2418 — Richtlinien und Verfahren für IETF-Arbeitsgruppen
  10. RFC 5434 — Hinweise für ein erfolgreiches BoF
  11. Lu Heng — The Multi-Stakeholder Mirage
  12. Lu Heng — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption