Zusammenfassung

  • Ein ITU-T-Studiengruppenleiter konnte einen offiziellen Delegierten bevollmächtigen; im IETF hatte dessen Meinung dennoch dasselbe Gewicht wie die jedes anderen Teilnehmers der Arbeitsgruppe.
  • Genehmigung, Zustellung, öffentliches Archiv und benannte Zuständigkeit machten eine Liaison nachvollziehbar, belegten aber weder Zustimmung noch Konsens, Veröffentlichung oder Implementierung.

Ein Vertreter betritt die Sitzung mit einem lückenlosen Mandat. Der Leiter der Studiengruppe hat ihn ermächtigt, die Liste wurde an die vorgesehenen Empfänger geschickt, und er kann berechtigt erklären, wofür seine Institution steht. Dennoch entscheidet er nicht für den Raum.

Genau diese Trennung formulierte RFC 3356. Die Meinung eines offiziellen ITU-T-Delegierten erhielt in einer IETF-Arbeitsgruppe dasselbe Gewicht wie die Meinung jedes anderen Teilnehmers. Das Mandat beantwortete, wessen Position vorgetragen wurde. Es brachte keine zusätzliche Stimme und kein Vetorecht in das Verfahren des Empfängers.

Der im August 2002 als Informationsdokument veröffentlichte RFC löste RFC 2436 ab. Große Teile waren gemeinsamer Text mit dem im November 2001 vom TSAG verabschiedeten Ergänzungsband 3 der ITU-T-Reihe A. Zusammenarbeit war nötig, weil Signalisierung, Nummerierung, Sicherheit, Routing, Management, Leistung und Zugang in beiden Arbeitsprogrammen auftauchten.

Die institutionellen Maschinen unterschieden sich jedoch. Das IETF arbeitete in Arbeitsgruppen, vor allem über offene öffentliche Mailinglisten, gegliedert in Areas und begleitet vom IESG. Das ITU-T organisierte Fragen, Arbeitsgruppen, Studiengruppen und Berichterstatter und stützte sich stärker auf Sitzungen. Zusammenarbeit konnte daher nicht bedeuten, ein einziges Verfahren mit zwei Logos zu versehen.

Zunächst musste Überschneidung sichtbar werden. Eine Studiengruppe sollte Ziel und erwartetes Ergebnis einer Zusammenarbeit in ihrem Arbeitsplan benennen. Eine IETF-Arbeitsgruppe sollte die Beziehung in ihrer Charta festhalten. So wurde aus thematischer Nähe noch keine gemeinsame Zuständigkeit.

Die NewWork-Liste bildete einen Frühwarnkanal. Entwürfe neuer oder geänderter Arbeitsgruppen-Chartas sowie BOF-Ankündigungen wurden an einen Verteiler des ITU-T weitergeleitet. Da eine IETF-Charta innerhalb von zwei Wochen vorankommen konnte, war laufende Beobachtung nötig. Aktualisierungen des ITU-T-Arbeitsprogramms sollten in Gegenrichtung fließen.

Eine Warnung schuf Zeit zur Reaktion. Sie reservierte kein Thema, hielt kein fremdes Verfahren an und verlieh kein Veto. Aufmerksamkeit und Autorität blieben getrennt.

Für offizielle Vertretung kam eine Mandatskette hinzu. IETF-Teilnehmer konnten nach Zustimmung ihrer Arbeitsgruppe oder Area als ISOC-Delegierte an ITU-T-Sitzungen teilnehmen; der IAB-Vorsitzende übermittelte die Anmeldung. Umgekehrt konnte ein Studiengruppenleiter Mitglieder ermächtigen, offiziell über Tätigkeiten einer Studien- oder Berichterstattergruppe zu sprechen.

Diese Kette schützte die Herkunft der Aussage. Sie verhinderte, dass eine Privatmeinung als institutionelle Position erschien. Beim IETF trat die Position dennoch in die bestehende offene Diskussion und Konsensbildung ein. Herkunftsautorität wurde nicht zu Empfängerautorität.

Außerhalb von Sitzungen galt dieselbe Regel. Informelle Gespräche zwischen Fachleuten waren erwünscht. Eine formelle Mitteilung musste ausdrücklich genehmigt und als Botschaft der betreffenden Studiengruppe, Arbeitsgruppe, Berichterstattergruppe oder Area gekennzeichnet sein.

Eine ITU-T-Mitteilung an das IETF ging an Vorsitzende und Area Directors, in Kopie an eine besondere Annahmestelle für Liaison-Erklärungen, wurde auf einer öffentlichen Seite veröffentlicht und einer verantwortlichen Person zugewiesen. Damit waren Zustellung, Öffentlichkeit und Bearbeitungspflicht belegbar.

Zustimmung war damit nicht belegt. Eine archivierte Stellungnahme konnte offen, umstritten, nur teilweise beantwortet oder später überholt sein. Ein benannter Bearbeiter ist ein Verantwortungsnachweis, kein Beschluss.

Auch Dokumente behielten ihren Status. Bevor ein IETF-Entwurf als ISOC-Beitrag an das ITU-T ging, musste die Arbeitsgruppe gegenseitiges Interesse, Nutzen und korrekte Statusbeschreibung bestätigen; anschließend genehmigten Area Directors die Weitergabe. Genehmigt wurde der Transfer zur Prüfung, nicht der Entwurf als Standard.

In Gegenrichtung musste ein ITU-T-Entwurf Entwicklungsstand, Kontakte und zugehörige Studiengruppe nennen. Das Format eines Internet-Drafts machte ihn nicht zu IETF-Konsens. 2002 war ein Internet-Draft zudem ein vorläufiges Dokument, das nach sechs Monaten auslief.

Deshalb bevorzugte RFC 3356 vollständige Dokumentation durch eine Organisation und einen Verweis durch die andere. Gemeinsamer Text wurde wegen unterschiedlicher Genehmigungs- und Änderungsverfahren nicht empfohlen. Ein Verweis verband Spezifikationen, ohne Pflege und Änderungshoheit zu vermischen.

RFC 2026 regelte IETF-Verweise auf externe offene Standards; ITU-T-Empfehlung A.5 regelte die andere Seite. Selbst gemeinsame Formulierungen in RFC 3356 und Ergänzungsband 3 gehörten weiterhin zu getrennten Publikations- und Ablösungsketten.

Später präzisierten RFC 4052, RFC 4053 und RFC 4691 die Verwaltung von Beziehungen, den Umgang mit Liaison-Erklärungen und die Rolle von Vertretern. RFC 6756 ersetzte RFC 3356 im Jahr 2012 und bewahrte sowohl die Gleichgewichtung als auch die getrennte Dokumentpflege.

Die Quellen beweisen nicht, dass jede reale Liaison fehlerfrei funktionierte. Sie berichten hier keinen konkreten Streit und keine Implementierung. Sie liefern vielmehr ein Beweismodell: Person, Mandat, Mitteilung, Zustellung, Bearbeitung, Konsens, Publikation und laufender Code benötigen eigene Nachweise.

Der Delegierte sprach für eine Institution. Gerade deshalb musste die Arbeitsgruppe ihre Entscheidung selbst treffen und dokumentieren.

Sources