Zusammenfassung

  • Die IETF führt öffentliche Side Meetings als inoffizielle Veranstaltungen außerhalb der formellen Agenda. Bei IETF 126 bot sie zwei hybride Räume für etwa 40 und 15 Personen an, sofern diese nicht für Leitung oder offizielle Zwecke gebraucht wurden.
  • Das Buchungswerkzeug öffnet nach der endgültigen Agenda. Das Secretariat prüft und bestätigt Anträge in Eingangsreihenfolge. Dieser Maßstab verteilt knappe Logistik mit wenig inhaltlichem Ermessen; er bewertet weder technische Güte noch Dringlichkeit oder Nachfrage.
  • In der Nachbefragung erreichten Konflikte mit der Hauptagenda 3,08 von fünf, den schwächsten Side-Meeting-Wert. Eine getrennte Organisatorenbefragung erhielt 14 Antworten von 42 Adressaten. Das ist ein Planungssignal, aber kein Nachweis eines Effekts auf ein bestimmtes Thema.
  • Ein datensparsamer Zuteilungsbeleg sollte Antrag, Alternative, Raum, Kapazität, Queue-/Erledigungsstatus, erklärte Konflikte, Anwesenheitsmethode, Aufnahmezustimmung und Korrekturen ausweisen – samt fester Kennzeichnung inoffiziell / kein Verfahrensrang durch Zuteilung.

Die Raumgröße ist der erste Zuständigkeitsvermerk

Die IETF-Seite zu Side Meetings nennt den Rahmen offen. Teilnehmer können während, vor oder nach einem IETF-Treffen öffentliche Gespräche zu Themen organisieren, die einen Teil der Community interessieren. Die IETF leistet begrenzte Unterstützung. Das Treffen bleibt inoffiziell und steht nicht auf der formellen Agenda.

Die Unterstützung ist substanziell. Der große Raum wurde mit U-Form, vierzig Plätzen, Mikrofonen, Projektion, Strom und Webex-Rechner beschrieben. Der kleinere bietet ungefähr fünfzehn Plätze, je nach Veranstaltungsort, dazu Projektion, Meeting Owl und Fernzugang. Ein frühes Thema erhält Ort, Uhrzeit, Reichweite und Sichtbarkeit.

Das kann Qualität erzeugen. Betreiber entdecken eine falsche Annahme. Sicherheitsleute verlangen ein anderes Bedrohungsmodell. Autoren erfahren, dass ein bestehendes WG-Mandat bereits passt. Ein Problem kann scheitern, bevor institutionelle Kosten wachsen. Inoffizieller Raum ist deshalb kein Raum zweiter Klasse.

Er ist dennoch keine Entscheidung. Der Raum verstärkt ein Gespräch, bestimmt aber nicht IETF-Zuständigkeit, Reife, Arbeitsbereitschaft oder Behandlung von Einwänden. Die Kalenderzelle quittiert Zugang zu einer Ressource. Eine Aussage über fachliche Anerkennung wäre eine andere Urkunde.

Eingang ist kein Vorrang

Nach Veröffentlichung der endgültigen Agenda wählt der Organisator Raum und Block. Er übermittelt Datatracker-bezogene Identität, Titel, ausführliche Beschreibung, weitere Hosts, einschlägige Areas und bei Bedarf einen externen Konferenzlink. Das Secretariat prüft, fragt nach und bestätigt nach dem Prinzip „first come, first served“.

Diese Regel vermeidet eine verdeckte Macht. Müsste Verwaltung unfertige technische Ideen nach Wert sortieren, entstünde ein nicht bestelltes Programmkomitee. Eingangszeit ist vergleichsweise prüfbar, billig und vorhersehbar. Zwischen zulässigen Anträgen verkleinert sie den Raum für Bekanntheitsbonus.

Die Regel beantwortet aber nur ihre eigene Frage. Der früheste Antrag ist nicht zwingend das dringendste Internetproblem, die beste Interoperabilitätschance, der größte Betreiberbedarf oder die breiteste Arbeitsbereitschaft. Er ist früher an dieser Schnittstelle angekommen. Das Wort „erster“ darf nicht von Zeit zu Rang wandern.

Auch die Prüfung erweitert den Gegenstand nicht. Verantwortliche Person, Beschreibung, Area und Fernzugang werden für den Betrieb gebraucht. RFC 8711 trennt administrative Unterstützung vom Standardsprozess. Ein korrekt bestätigtes Treffen kann fachlich verfrüht sein, außerhalb des IETF-Bereichs liegen oder ohne Folge enden.

Knappheit bleibt. Späte Antragsteller finden keinen Block. Area-übergreifende Themen können nie allen wichtigen Personen einen freien Termin bieten. Der kleine Raum wird voll. Gleiche Sortierung bedeutet daher nicht gleiche reale Hörbarkeit.

Die formelle Agenda bindet die knappe Aufmerksamkeit

Der Start nach der endgültigen Agenda ist sinnvoll. Organisatoren sehen WG-, RG-, BoF- und Plenarsitzungen. Sehen heißt jedoch nicht vermeiden können. Zwei Räume und eine dichte Woche lösen keine Mehrfachbindung von Fachleuten.

Die IETF-126-Nachbefragung weist für Side Meetings insgesamt 3,68 aus, für den Nutzen der Teilnehmer 3,84 und für die breitere IETF 3,85. Agenda-Konflikte fielen auf 3,08, den schlechtesten Wert. Freitext nannte eine wachsende Zahl von Side Meetings, Überschneidungen mit WG und RG sowie Raumangebot. Das Feedback ging an die für Treffen zuständige IESG.

Die Zahlen sind kein Mandat. Die Hauptbefragung bekam 406 Antworten von 1.779 Registrierten. Eine getrennte Befragung ging an 42 Organisatoren-Adressaten und erhielt 14 Antworten. Die 42 werden nicht als Zahl von Meetings ausgewiesen; mehrere Hosts können zu einem Termin gehören. Vierzehn Antworten erfassen nicht alle Konflikte, und 3,08 identifiziert kein verdrängtes Thema.

Der Mechanismus ist trotzdem plausibel. Ein Sicherheitsthema parallel zu Security verliert Prüfer. Ein Deployment-Thema parallel zu OPS verliert Betreiber. Ein Querschnittsthema findet womöglich überhaupt keinen konfliktfreien Block. Formale Offenheit des Raums schafft keine freie Aufmerksamkeit.

Das ist ein Agenda-Schatten, keine geheime Agenda. Formelle Arbeit bindet legitimerweise Personen, und informelle Gespräche ordnen sich darum. Günstige Termine sammeln eher Mitautoren, Einwände und Dokumente. Schlechte Termine hinterlassen weniger sichtbare Reife. Spätere Bewertung kann diesen Ursprung übersehen.

Auslastung ist kein Ersatz. Fünfzehn Personen füllen den kleinen Raum; zwanzig lassen den großen halb leer aussehen. Bekanntmachung, Remote-Zugang, Zeitzone, Reise und Konkurrenztermine wirken mit. Ein Raumquotient misst Ressourcennutzung, nicht Legitimität.

Offen und kostenlos ist nicht kostenlos erreichbar

Die Regeln setzen gute Grenzen. Veranstalter und Besucher müssen registriert sein. Side Meetings sollen allen Registrierten offenstehen und keine Zusatzgebühr kosten. Das Note Well gilt; inoffiziell heißt nicht regelungsfrei. Anwesenheitsdaten verlangt die IETF nicht. Werden sie erhoben, muss die Teilnahme daran freiwillig sein und der Veranstalter die Datenschutzerklärung einhalten. Aufnahmen erfordern aktive Zustimmung aller.

Das definiert Berechtigung und Verhalten, nicht alle Zugangskosten. Registrierung, Reise, Visum, Hotel, Zeitzone, Aufmerksamkeit und Kapazität bleiben. Eine Sitzung kann rechtlich offen und praktisch schwer erreichbar sein. Der Unterschied beschuldigt niemanden; er hält das Wort „offen“ bei seiner belegten Aussage.

Eine Pflichtliste wäre schädlich. Manche möchten ein frühes Thema anhören, ohne Namen oder Arbeitgeber öffentlich zu binden. Freiwillige Erhebung schützt diese Möglichkeit. Liegt konsistent erhobene Aggregation vor, kann der Beleg Bandbreiten und Vor-Ort/Fern-Anteile nennen. Ohne Daten heißt der Zustand „nicht erhoben“, nicht „kein Interesse“.

Eine einvernehmlich erstellte Aufnahme erweitert Zugang und Erinnerung. Ihr Fehlen beweist keine Geschlossenheit. Ihr Vorhandensein macht Beiträge nicht zur IETF-Position. Aufzeichnung und Autorität bleiben getrennt.

Side Meeting, BoF und WG sind getrennte Akten

RFC 2418 beschreibt Working Groups als Hauptmechanismus für IETF-Spezifikationen und Leitlinien. Die Gründung verlangt Rat und Zustimmung des Area Director, Charterarbeit, öffentliche Prüfung, IAB-Beteiligung und IESG-Genehmigung. Erst danach trägt das Secretariat die Gruppe ein.

Auch ein BoF ist kein umbenanntes Side Meeting. Der Antrag geht an einen zuständigen Area Director und muss vor der Terminierung genehmigt sein. Beschreibung und Agenda sind erforderlich. Die verfügbare Zeit ist knapp und die Entscheidung enthält ein ausdrücklich zuständiges Urteil. Nicht jeder BoF soll ein WG gründen, doch jeder folgt einem anderen Pfad.

RFC 5434 zeigt die mögliche Vorbereitung: Problemdefinition, öffentliche Liste, Aufruf zur Mitarbeit, Internet-Drafts, Gespräche mit Area Directors, kritische Masse und Charterentwurf. Ein Side Meeting kann fehlende Elemente entdecken. Es kann sie nicht vermuten.

Die Kette lautet daher: informelles Gespräch; Raum beantragt und zugeteilt oder nicht; mögliche Liste und Drafts; formeller BoF-Antrag; Entscheidung; Charterprüfung; mögliches WG; Arbeitsannahme; Rough Consensus; Veröffentlichung; Einsatz. Jeder Übergang braucht eigenen Akteur und Beleg.

RFC 7282 lehnt Kopfzählung als Wesen des Rough Consensus ab. Sachliche Einwände zählen. Wenn selbst eine formelle WG-Sitzung nicht per Füllstand entscheidet, kann ein inoffizieller Fünfzehn-Personen-Raum es erst recht nicht.

Leere Kalenderzellen haben mehrere Vergangenheiten

Der dynamische Kalender hilft bei der unmittelbaren Orientierung. Ein leeres Feld kann aber bedeuten: kein Antrag, zu spät, Rückfrage, Rückzug, offizielle Rücknahme des Raums, unpassende Dauer oder angenommene Alternative. Nichts davon ist fachliche Ablehnung.

Neutrale Statuscodes reichen, ohne private Korrespondenz zu öffnen. Bei Bestätigung sind Wunsch- und Ist-Zeit, Wunsch- und Ist-Raum, erklärte und später vermutete Konflikte zu unterscheiden. Verschiebungen, Umbenennungen und Absagen werden angehängt statt überschrieben.

Das schützt die historische Aussage. Ein Anbieter könnte später den Raum als IETF-Auswahl verkaufen. Befürworter könnten Kalendereinträge als Momentum zählen. Gegner könnten fehlenden Slot als Ablehnung deuten. Der Beleg hält alle bei derselben kleinen Wahrheit: Diese Ressource wurde nach dieser Regel zugeteilt.

Spätere Internet-Drafts, BoFs oder WGs dürfen verlinkt werden – vorwärts, mit Datum und zuständigem Akteur. Der Erfolg malt keinen früheren offiziellen Status in das Side Meeting hinein.

Der vorgeschlagene Zuteilungsbeleg

Daniel Kade schlägt eine kompakte öffentliche Karte vor, kein Merit Panel und keine bestehende IETF-Pflicht. Sie enthält stabile Antrags-ID, vom Antragsteller gelieferten Titel und Kurztext, ohnehin öffentliche Hosts, relevante Areas sowie Zeitstempel oder grobe Queue-Position. Eine signierte Sequenz kann Reihenfolge zeigen, ohne Sekundensprints zu fördern.

Dann folgt die Ressource: gewünschte Dauer und Alternativen, Wunschraum, zugeteilter Raum und Kapazität, Wunsch- und Ist-Block, Verfügbarkeitsversion. Organisatoren können offizielle Sitzungen mit überschneidender Zielgruppe per Datatracker-ID nennen. Das ist Termingeometrie, kein Vorrangantrag.

Erledigungszustände bleiben neutral: bestätigt, mit Alternative bestätigt, Information angefordert, nicht verfügbar, zurückgezogen, abgesagt, ersetzt. Gründe sind Kapazität, belegter Block, offizielle Rücknahme oder unvollständiger Antrag – keine technische Note.

Datenschutz und Aufzeichnung stehen separat: Erhebung ja/nein, freiwillig, exakt/Band/nicht verfügbar, Aufnahmezustimmung und Zugriffsstatus. Eine Namensliste wird nicht zum Prestigeinstrument.

Die feste Zeile lautet: Öffentliches Side Meeting – inoffiziell – nicht auf der formellen IETF-Agenda – Zuteilung verleiht keinen Verfahrensrang. Spätere Vorgänge werden mit ihrer eigenen Autorität verknüpft. Genealogie bleibt, Rückdatierung nicht.

Aggregiert entstehen sinnvolle Betriebsdaten: Raumstunden, Dauerwünsche, Alternativen, Nichtverfügbarkeit, Konfliktarten und Remote-Fähigkeit. IESG und Meeting-Team können Kapazität beurteilen, ohne Themen zu ranken oder Personen offenzulegen.

Eine sichtbare Grenze schützt das Inoffizielle

Los, Rotation, reservierte Blöcke, mehr Räume oder Merit-Auswahl sind denkbar. Das Los senkt Planbarkeit. Rotation braucht Identitätshistorie. Merit schafft fachliche Torwächter. Zusätzlicher Raum kostet. Die Wiener Befragung wählt keine Option.

Proportional ist zunächst: einfache Queue behalten, Zustände veröffentlichen, Bedeutungsgrenze befestigen. Side Meetings sind stark, weil unfertige Fragen, Kritik und ein Ende ohne Charter erlaubt sind. Ein einmaliges gutes Gespräch ist kein Fehlschlag.

Problematisch wäre die doppelte Nutzung: am Anfang Freiheit durch Inoffizialität, später Prestige durch angebliche Anerkennung. Die IETF hat die richtige Formel bereits veröffentlicht. Der Beleg hält sie an der meistzitierten Spur fest.

Evidenzgrenzen

Genutzt wurden IETF-Richtlinie, IETF-126-Zusammenfassung, Note Well, Datenschutz und RFC zu Verwaltung, BoF, WG und Rough Consensus. Ein vollständiges öffentliches Antrags-, Ablehnungs-, Warte-, Nutzungs- oder Individualdatenset lag nicht vor. Dynamische Karten werden nicht gezählt, 42 Adressaten nicht zu 42 Meetings gemacht, kein verdrängtes Thema, keine Bevorzugung und keine Standardwirkung behauptet. Der Beleg ist Daniel Kades Governance-Vorschlag.

Quellen

  1. IETF – Side Meetings und private Meetings
  2. IETF-126-Nachbefragung
  3. IETF 126 Wien
  4. IETF Note Well
  5. IETF/IRTF/IAB-Datenschutzerklärung
  6. RFC 2418 – IETF Working Group Guidelines
  7. RFC 5434 – Erfolgreiche BoF-Sitzungen
  8. RFC 7282 – Konsens und Humming in der IETF
  9. RFC 8711 – IETF Administrative Support Activity 2.0
  10. RFC 3935 – IETF Mission Statement
  11. IETF-Side-Meeting-Scheduler