Zusammenfassung
- RFC 3005 machte die allgemeine IETF-Diskussionsliste zu einem breiten Forum für Technik und institutionelle Richtung, ohne jedes Thema, jeden Ton und jede Wiederholung für angemessen zu erklären.
- Eine Person oder ein Thread durfte bei unangemessenem Inhalt mit Missbrauchsmuster eingeschränkt werden; Beschwerden gingen an das IAB, spätere BCPs präzisierten Warnung, Dauer, Empfang und Beschwerde.
Offene Teilnahme löst nicht das Problem einer wiederholten Blockade des gemeinsamen Gesprächs. Wenn ein Kanal keine Grenze kennt, kann ein einzelner Akteur die Aufmerksamkeit verbrauchen, die vielen versprochen wurde. Die RFC 3005, im November 2000 als Best Current Practice 45 veröffentlicht, gab der allgemeinsten IETF-Mailingliste eine kurze, aber erkennbare Governance.
Die allgemeine Diskussionsliste hatte zwei Aufgaben. Sie sollte durch technische Diskussion die Entwicklung und Spezifikation der Internettechnik fördern und zugleich Richtung, Politik, Sitzungen und Verfahren der IETF behandeln. Als breitestes Forum ließ sie erheblichen Spielraum. Neue Fragen ohne Arbeitsgruppe, Last Calls und Debatten über die Institution selbst brauchten einen sichtbaren Startpunkt.
Dieser Startpunkt war kein dauerhafter Sammelplatz. Gehörte ein Thema zu einer Arbeitsgruppe oder etablierten Liste, sollte die Diskussion nach einem Hinweis dorthin wechseln, außer sie benötigte breitere Orientierung. Offenheit verlangte nicht, alle Gespräche auf einem zentralen Kanal zu halten. Die Wahl des Ortes schützte die verteilte Aufmerksamkeit.
Die Charta nannte angemessene Beiträge: Last-Call-Diskussionen, technische Kandidaten für neue Arbeit, Verwaltungspolitik, Fragen zu Sitzungen und von ISOC oder IETF unterstützte Veranstaltungen. Unaufgeforderte Massenpost, sachfremde Themen, nicht unterstützte Werbung und unprofessionelle Kommentare unabhängig vom Gegenstand waren unangemessen. Ein technischer Gegenstand legitimierte nicht automatisch seine Darbietung.
Auch die Eingriffsbefugnis war begrenzt. Der IETF Chair, der Executive Director oder ein vom Chair ernannter sergeant-at-arms konnte Beiträge einer Person oder eines Threads beschränken, wenn der Inhalt unangemessen war und ein Missbrauchsmuster darstellte. Eine einzelne Entgleisung, hartnäckiger Widerspruch oder eine Minderheitsposition wurde damit nicht automatisch zum Muster.
Die Entscheidenden sollten die Gesamtnatur der Beiträge betrachten und unterscheiden, ob eine konkrete Nachricht eine Abweichung oder typisch war. Das erforderte zeitlichen Kontext. Ein Wortfilter oder eine bloße Anzahl hätte diese Abwägung nicht ersetzen können.
Die erste Entscheidung blieb überprüfbar. Beschwerden sollten an das IAB gehen. RFC 3005 bestimmte weder Höchstdauer noch feste Warnstufen oder ein Beweisformat. Trotzdem legte sie die Kontrolle außerhalb des Eingreifenden an. Aus einer technischen Sperre wurde ein institutioneller Akt, der begründet und angefochten werden konnte.
Die RFC 2418 erklärt die Bedeutung: Es gab keine formelle IETF-Mitgliedschaft, die Teilnahme stand allen offen, und Menschen wirkten als individuelle technische Beitragende. Mailinglisten waren Arbeitsflächen des Standardsprozesses. Eine Postsperre veränderte einen Teilhabeweg, widerlegte aber nicht die technische Aussage des Betroffenen.
2004 trennte die RFC 3683 fortgesetzte Störung ausdrücklich von der einzelnen abweichenden Stimme. Eine länger wirkende Posting-Rights-Aktion brauchte einen Area Director, einen IESG Last Call, Gemeinschaftsdiskussion, IESG-Entscheidung und Beschwerdemöglichkeit. Sie betraf Schreiben, nicht Lesen: Nachrichten mussten weiter empfangen werden können.
Die RFC 3934 gab Arbeitsgruppen-Chairs einen anderen, kurzen Mechanismus. Üblicherweise sollten zuerst direkter Kontakt, mindestens eine öffentliche Warnung und Rücksprache mit dem Area Director erfolgen. Als letztes Mittel war eine Sperre von höchstens 30 Tagen möglich; Empfang und Beschwerde blieben. Allgemeine Liste, Arbeitsgruppe und IESG-Aktion waren verwandte, aber nicht austauschbare Kontrollflächen.
Die Quellen zwingen zu getrennten Beweisen. Technische Relevanz beweist kein professionelles Verhalten. Eine Verhaltensmaßnahme widerlegt keinen technischen Einwand. Eine Beschwerde beweist noch keinen Verfahrensfehler. Fehlender Konsens darf Ergebnis sein, ohne Missbrauch zu bedeuten. Umgekehrt schützt der technische Gegenstand kein wiederholtes störendes Verhalten.
RFC 3005 verband einen niedrigen Zugang mit sichtbaren Grenzen: Zweck, unzulässige Nutzung, Muster statt Einzelfall, benannte Eingriffsrollen und eine externe Beschwerdestelle. Die Liste war nicht offen, weil Macht fehlte. Sie war überprüfbar offen, weil Macht einen lesbaren Umfang hatte.
Sources
- Lu Heng, „Minimum Initial Specification, Localized Future Decision, Voluntary Adoption: An Internet Coordination System“
- Lu Heng, „On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile“
- Lu Heng, „Running Code Primary: The Patch Needed to Preserve the Internet’s Original Design“
- RFC-Editor-Seite zu RFC 3005
- RFC 2026, Internet-Standardisierungsprozess
- RFC 2418, Richtlinien und Verfahren für IETF-Arbeitsgruppen
- RFC 3005, Charta der IETF-Diskussionsliste
- RFC 3683, Verfahren zum Entzug von Posting-Rechten
- RFC 3934, Aktualisierung zur Verwaltung von IETF-Mailinglisten
- RFC 7154, IETF-Verhaltensrichtlinien
- RFC 7776, IETF-Verfahren gegen Belästigung
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
