Zusammenfassung

  • 3GPP sollte IETF-Standards möglichst unverändert verwenden und IETF-Arbeit nicht duplizieren. Notwendige Änderungen brachte RFC 3113 zum zuständigen Working Group oder Area Director zurück.
  • Die Liaison vereinte keine Mandate. Beide Organisationen behielten eigene Regeln für IPR, Ausarbeitung, Genehmigung und Pflege; ein Liaison Manager durfte keine Ausnahme vom IETF-Verfahren gewähren.

Der Zeitplan einer Seite war kein Recht über die andere

Eine Mobilfunk-Release kann von einem Internet-Protokoll abhängen, das noch diskutiert wird. Die 3GPP kennt ihre Architektur und ihren Termin. Sie kennt auch die Kosten des Wartens. Trotzdem entsteht daraus kein Recht, den IETF-Text selbst freizugeben.

RFC 3113 beschrieb im Juni 2001 genau diese Lage. Technische Spezifikationen sollten rechtzeitig entstehen und größtmögliche Interoperabilität mit festen und mobilen Internet-Systemen erreichen. Daneben stand die Grenze: Jede Organisation arbeitet nach ihren eigenen Regeln, einschließlich geistigem Eigentum, Spezifikationsentwicklung, Genehmigung und Wartung.

Technische Abhängigkeit war keine Übertragung von Zuständigkeit. Eine RFC-Referenz machte die IETF nicht zum Eigentümer der gesamten 3GPP-Architektur. Die Zuständigkeit der IETF für ein Protokoll gab ihr umgekehrt keine allgemeine Hoheit über Mobilfunk-Releases.

Unveränderte Nutzung war der Ausgangspunkt

3GPP wollte Internet-Standards unverändert einsetzen, wenn dies machbar war, und keine IETF-Arbeit wiederholen. Damit sollte ein privater Fork verhindert werden, bei dem feste und mobile Systeme denselben Protokollnamen verwenden, aber anderes Verhalten liefern.

RFC 3113 wusste, dass Funk, Mobilität, Endgeräte und Sicherheit zusätzliche Anforderungen erzeugen konnten. Deshalb war „unverändert“ keine starre Verbotsregel. Wenn Ergänzungen oder Änderungen nötig wurden, sollte 3GPP das Anliegen in die passende IETF Working Group tragen. Ohne passende Gruppe war der Area Director die Anlaufstelle.

Die Änderung kehrte zum Prozess des Protokolls zurück. 3GPP lieferte Anforderung, Betriebskontext und Zeitdruck. Die IETF entschied nach ihrem Verfahren, was IETF-Arbeit wurde. 3GPP entschied, wie das Ergebnis in die eigene Spezifikation einging. Der Koordinator konnte den Engpass sichtbar machen, nicht beide Freigaben ersetzen.

Gerade diese dünne Schnittstelle schützte die Zuständigkeit. Hätte ein Liaison Office wegen eines Release-Termins Ausnahmen erteilen dürfen, wäre es vom Nachrichtenkanal zum unkontrollierten Gatekeeper geworden.

Funkwissen war Eingabe, nicht Vollmacht

Das Dokument zeigte auch, wo in 3GPP das Fachwissen für Radio Access, physikalischen Transport, Mobility Management, Core Network, Terminals, Anwendungen, Architektur, Sicherheit und Betrieb lag. Die Beziehung war keine Einbahnstraße vom RFC zur Mobilfunk-Spezifikation.

Eine Annahme, die im Festnetz billig ist, kann über Funk teuer sein. Handover verändert Pfad und Zustand. Begrenzte Endgeräte machen Latenz und Energie zu Protokolleigenschaften. 3GPP-Experten konnten solche Tatsachen in die IETF-Diskussion einbringen.

Fachwissen beweist Folgen. Autorität bestimmt, wer eine Änderung annehmen darf. Teilnahme, eine präzise Analyse oder ein Schreiben machen den Experten nicht zum Genehmiger einer fremden Organisation. RFC 3113 ließ Expertise wirken, ohne daraus ein Mandat abzuleiten.

Ein Liaison Manager trug Botschaften, keine Ausnahmen

Informelle Kommunikation auf Arbeitsebene und Teilnahme an Mailinglisten waren bevorzugt. Formelle Mitteilungen blieben möglich und konnten von IETF Area Directors sowie technischer 3GPP-Leitung unterstützt werden. Die Liaison half bei administrativen Fragen, die nicht leicht direkt lösbar waren.

Der entscheidende Satz verweigerte ihr Sondermacht: Sie konnte keine Ausnahme oder Sonderregel für IETF-Politik und -Verfahren schaffen.

RFC 4052 verallgemeinerte später diese Grenze. Liaison-Beziehungen sollen Doppelarbeit vermeiden, ohne eine Organisation an ihrem eigenen Mandat zu hindern. IETF-Arbeit verwendet das normale IETF-Verfahren. Ein Manager kann eine falsch adressierte Anfrage umlenken, Abhängigkeiten verfolgen und eine autorisierte Nachricht tragen; er erzeugt nicht den Konsens, den sie repräsentiert.

Auch formelle Liaison Statements besitzen eine Freigabekette. Für eine Working Group braucht es Diskussion und Chair-Zustimmung; für eine Area den Area Director; für die gesamte IETF den IETF Chair. RFC 4053 bezeichnet das Schreiben treffend als Geschäftsbrief zwischen Organisationen. Eine Bitte um Handlung ist nicht die Handlung selbst.

Offene Dokumente machten Abhängigkeiten prüfbar

RFC 3113 förderte den Austausch relevanter Entwürfe und den offenen Web-Zugang. Kontaktstellen erklärten die Dokumentstruktur der jeweils anderen Seite. So ließ sich „3GPP wartet auf IETF“ in eine konkrete Spezifikation, Revision, verantwortliche Gruppe und Frist zerlegen.

Der Status musste erhalten bleiben. Ein Internet-Draft ist keine freigegebene RFC. Eine bestimmte Draft-Version kann unveränderliche Bytes haben und dennoch später ablaufen oder ersetzt werden. Ein 3GPP Technical Report ist nicht dieselbe Kategorie wie eine Technical Specification. Eine gemeldete Abhängigkeit beweist keine Implementierung.

RFC 4691 dokumentierte die Praxis: 3GPP, 3GPP2 und OMA lieferten aktualisierte Abhängigkeitslisten; der Liaison Manager verfolgte sie und konnte einen Wunsch nach schneller RFC-Nummer an den zuständigen Area Director übermitteln. Der Kanal zeigte den Zeitdruck. Er garantierte die Veröffentlichung nicht.

Die Prinzipien blieben, die Organisationsdetails nicht

Die IETF führt 3GPP weiterhin als formelle Liaison und verweist auf RFC 3113. Ein Internet-Draft vom März 2026 schlägt ein Update vor, weil Namen, Strukturen und Dokumentzugriffe veraltet sind. Die Grundprinzipien seien weiterhin intakt: möglichst unverändert nutzen, Arbeit nicht duplizieren und Änderungsbedarf zur IETF bringen.

Der Entwurf bleibt Work in Progress. Er darf nicht als bereits genehmigter Nachfolger behandelt werden. Er belegt eine aktuelle Absicht, nicht den Abschluss des Standards-Prozesses.

Protokolle einer Koordinationssitzung desselben Monats zeigen die reale Schnittstelle: lange Austausche, übersehenes Feedback, Abhängigkeiten von unfertigen Drafts, 3GPPs Vorliebe für RFCs als normative Referenzen und Fälle ohne geplantes IETF-Update. Ein Problem sollte 3GPP selbst lösen, ein anderes brauchte eine neue IETF-Mitteilung. Kooperation bedeutete nicht ein einheitliches Ergebnis.

Geteilte Verwahrung war eine Sicherheitsfunktion

3GPP kontrollierte Architektur, Releases und eigene Spezifikationen. Working Groups, Areas und IESG kontrollierten IETF-Protokollarbeit. Die IAB kontrollierte die Beziehung; Liaison Manager kontrollierten Routing und Nachverfolgung. Editoren fixierten Referenzen, Implementierer Verhalten, Betreiber Deployment.

Kein Beleg bewies die ganze Kette. Eine 3GPP-Referenz zeigte Abhängigkeit, nicht IETF-Genehmigung des Gesamtsystems. Eine RFC zeigte Veröffentlichung, nicht Einsatz. Ein Schreiben zeigte eine Anfrage, nicht Annahme. Sitzungsnotizen zeigten Diskussion, nicht Interoperabilität. Laufender Code erhielt dadurch kein institutionelles Mandat.

Die Teilung verhinderte, dass der Termin der einen Seite das Verfahren der anderen überschreibt, dass Protokollzuständigkeit zur Herrschaft über die abhängige Architektur wächst oder dass ein privater Fork unter gemeinsamem Namen ausgeliefert wird.

RFC 3113 beseitigte Konflikte nicht. Es gab ihnen eine Adresse. Dokumente teilen, Abhängigkeiten nennen, Fachleute an den richtigen Ort bringen und Genehmigung beim verantwortlichen Träger lassen: So konnten beide Seiten ein System bauen, ohne eine gemeinsame Oberbehörde zu erfinden.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3113.txt
  2. https://www.rfc-editor.org/rfc/rfc2850.txt
  3. https://www.rfc-editor.org/rfc/rfc2026.txt
  4. https://www.rfc-editor.org/rfc/rfc4052.txt
  5. https://www.rfc-editor.org/rfc/rfc4053.txt
  6. https://www.rfc-editor.org/rfc/rfc4691.txt
  7. https://www.rfc-editor.org/rfc/rfc3131.txt
  8. https://www.ietf.org/about/liaisons/
  9. https://www.ietf.org/archive/id/draft-kes-rfc3113bis-01.html
  10. https://datatracker.ietf.org/doc/minutes-interim-2026-ietf3gpp-01-202603160445/
  11. https://wiki.ietf.org/group/iab/3gpp_liaison_relationship
  12. https://www.3gpp.org/ftp/Information/Working_Procedures/archive/2019-08-23/3GPP_WP.htm