Signale für politische Kontinuität, Legitimität und Rechenschaftspflicht in Internet-Governance-Institutionen.
Governance
Governance
Governance-Analyse verfolgt die Institutionen, politischen Prozesse, Normungsgremien, Registeroperationen, Rechenschaftsstreitigkeiten und Betreibergemeinschaften, die prägen, wie das Internet regiert und betriebsfähig gehalten wird.

RIR-Wächter, Fallakte, NRS, ICANN, IETF, Geschichte des Internets und NOG-Sitzungen
Bei der Abdeckung liegt der Schwerpunkt auf Umsetzungsnachweisen und institutionellem Verhalten statt auf Positionsbekundungen.
Aktuelle Berichterstattung
Aktuelles zu Governance
7.723 Artikel

Geschichte
Der Proxy bestätigte die Bytes. Die Anwendung hatte sie noch nicht erhalten: RFC 3135
Das ACK kam früh zurück, das Sendefenster wuchs, und die Strecke wirkte schneller. Doch geantwortet hatte ein Zwischenknoten vor dem schwierigen Link. RFC 3135 zeigte 2001, warum diese Abkürzung nützlich sein konnte und weshalb sie trotzdem kein Beleg für die Zustellung an die…

IETF
Getrennte Transaktionskennungen machen den Vorgang nicht unsichtbar
Zwei Dienste können an demselben Auftrag beteiligt sein, ohne dieselbe Transaktionskennung zu erhalten. Das verhindert einen naheliegenden Abgleich, aber nicht jede Zuordnung. Ein neuer OAuth-Entwurf beschreibt sowohl die technische Trennung als auch die Spuren, die sie nicht…

IETF
Der Umschlag war signiert. Der abgetrennte Chiffretext lag außerhalb der Signatur.
Ein gültiges COSE-Objekt und eine erfolgreich entschlüsselte Datei können gleichzeitig vorliegen, ohne dass die äußere Signatur diese Datei je erfasst hat. Sobald Steuerobjekt und Chiffretext getrennt gespeichert werden, entscheidet die exakte Byte-Abdeckung über die Aussagekraft…

IETF
Der Kalender nannte ihn Eigentümer. Kontrolle hatte er damit noch nicht.
Ein portabler Kalendereintrag kann einen Teilnehmer als Eigentümer bezeichnen, ohne ihn zum berechtigten Bearbeiter zu machen. Das Label beschreibt eine Rolle; erst das Austauschprotokoll entscheidet, wer den Termin verschieben, Teilnehmer ändern oder ein Update versenden darf.

Geschichte
Für das verschachtelte Upload-Format waren keine Sender bekannt: RFC 2388
Mehrere Dateien aus einem Formularfeld sollten zunächst in einem inneren MIME-Teil stecken. RFC 2388 übernahm diese Struktur in eine Standards-Track-Spezifikation. Ihr Nachfolger hielt 2015 fest, dass keine sendenden Implementierungen dafür bekannt waren, und stellte die Dateien…

Geschichte
Die Zustellrate sah gut aus. Die Anwendung lief schlecht: RFC 3133
Statistisch fehlte kaum etwas: ein kurzes Bestätigungs-Frame unter vielen großen Daten-Frames. Für den Sender konnte gerade dieses kleine Signal entscheiden, ob er fortfahren durfte oder umfangreiche Daten erneut übertragen musste. RFC 3133 machte diese Asymmetrie zum Bestandteil…

Geschichte
Das erste Paket musste den Host wecken, bevor es ihn erreichen konnte: RFC 3132
Der mobile Host sparte Strom, indem er den Verkehrskanal nicht mehr ständig abhörte. Damit wurde das erste Paket vom Nutzinhalt zum Auslöser einer Suche: Die Netzseite musste erinnern, rufen und erst danach zustellen.

IETF
Die Umleitung gelang. Das Zugangstoken war bereits im Klartext unterwegs.
Am Ende des Traces stehen eine HTTPS-Adresse und eine erfolgreiche Antwort. Der entscheidende Vorgang liegt davor: Noch bevor der Server umleiten konnte, hatte der Client das Zugangsmittel in die erste unverschlüsselte HTTP-Anfrage geschrieben.

Geschichte
Die Variantenliste war noch nicht die Repräsentation: RFC 2295
Eine HTTP-Adresse konnte mehrere Fassungen einer Ressource bezeichnen. Die Kandidaten aufzulisten bedeutete aber noch nicht, eine davon auszuliefern. RFC 2295 machte diesen Unterschied zum Bestandteil des Protokolls: Eine Antwort konnte die Liste sichtbar machen, der Server unter…

Geschichte
Der Router blieb erreichbar, nachdem er keinen Transit mehr tragen sollte: RFC 3137
Ein OSPF-Router musste nicht aus der Topologie verschwinden, nur weil der Verkehr ihn meiden sollte. RFC 3137 hielt Ziel und Verwaltungsweg sichtbar, machte den Durchgang aber maximal teuer.

IETF
Die Kette validierte mit ihrem eigenen Anker. Die prüfende Stelle hatte ihm noch nicht vertraut.
Bei did:x509 kann die Auflösung fehlerfrei enden, obwohl die entscheidende institutionelle Prüfung noch aussteht. Kette, CA-Fingerabdruck und Blatt-Prädikate können zusammenpassen; ob die prüfende Stelle der CA vertraut und den konkreten Vorgang erlaubt, entscheidet weiterhin…

Geschichte
Ein eintägiger Workshop konnte keine ablaufende Signatur testen: RFC 3130
Um IETF 49 konnte eine DNSSEC-Demonstration erfolgreich enden, bevor die entscheidenden Ereignisse begonnen hatten. RFC 3130 hielt fest, dass Ablaufzeiten, wiederholte Validierung, Schlüsselwechsel und institutionelle Übergaben längere Beweise verlangten als einen Workshop.

Geschichte
Syntax musste nicht länger abgeschrieben werden: RFC 2234 und ABNF
Früher erklärte eine Protokollspezifikation oft nicht nur das Nachrichtenformat, sondern wiederholte auch die Notation, in der ihre Grammatik formuliert war. RFC 2234 machte aus dieser Erklärung ein eigenständiges Dokument, auf das andere Spezifikationen gezielt verweisen…

Berichte
EDEKAs Nummernressourcen in zwei Schichten: AS197909 führt das Routing, die Registrierungsschicht um DFINFRA steht still
Die Analyse-Zusammenfassung zu EDEKAs Nummernressourcen in zwei Schichten: AS197909 führt das Routing, die Registrierungsschicht um DFINFRA steht still erläutert die Entwicklung, die öffentlich zugänglichen Belege, die beteiligten Organisationen, den regionalen Kontext, die…

Geschichte
Das KDC trug das Vertrauen, das nicht jeder IPsec-Peer tragen konnte: RFC 3129
Im Juni 2001 behandelte RFC 3129 Schlüsselaustausch als Organisationsfrage. Wenn jeder IPsec-Peer Zertifikate, Rechenlast, Richtlinien und paarweise Geheimnisse selbst verwaltet, wird nicht nur Kryptografie benötigt, sondern eine Institution, die das Geflecht beherrschbar macht.

IETF
Der Ersatz sah den Primären nicht mehr. Der Multicast-Pfad lebte weiter.
Ein BIER-Backup kann die Überwachungsverbindung zum ausgewählten Ingress verlieren, obwohl dessen Verteilpfade zu den Empfängern intakt bleiben. Wird aus dieser begrenzten Beobachtung ein Übernahmebefehl, erzeugt die Redundanz selbst den doppelten Verkehr.

Geschichte
Das Pluszeichen war nur ein lokaler Dialekt: RFC 5233
Der lokale Teil einer Adresse kann einen Zustellhinweis tragen, doch dieser Hinweis ist keine universelle Sprache. RFC 5233 ermöglichte Sieve den Vergleich eines „Benutzer“- und eines „Detail“-Teils, ohne zu behaupten, alle Mail-Systeme trennten beide gleich — oder verwendeten…

Geschichte
Das erste Fragment passierte; die Überlappung änderte den Port: RFC 3128
RFC 3128 beschrieb keinen Filter, der blind war. Der Filter sah einen zulässigen TCP-Anfang und entschied nachvollziehbar. Erst die spätere Zusammensetzung überlappender Fragmente konnte daraus einen Header mit einem anderen Zielport machen.

Geschichte
Langzeitbeweise mussten den Schlüssel überleben: RFC 3126
RFC 3126 behandelte eine alte Signatur als Aufbewahrungsproblem. Eine 2001 richtige Berechnung konnte sich Jahrzehnte später nicht erklären, wenn Zertifikate, Sperrdaten, exakte Bytes oder vertrauenswürdige Algorithmen fehlten. Die Antwort war eine erneuerbare Beweiskette, kein…

IETF
Die Nachricht ließ sich öffnen. Der Gruppenkontext fehlte trotzdem.
Ein externer MLS-Empfänger kann denselben Commit oder Proposal wie die Mitglieder entschlüsseln und dennoch den Absender nicht authentifizieren. Dafür braucht er den GroupContext, der Epoche, Sender-Leaf, Credential und vereinbarte Empfängerliste verbindet.
Sitzungsplan
Governance-Bereich
RIR-Watchdog
Fünf regionale Sitzungen befassen sich mit Zuteilungspolitik, der Legitimität des Vorstands und der institutionellen Kontinuität.
RIR-Watchdog öffnenFallakte
Langfristige Governance-Dossiers mit rechtlicher, wahlbezogener und institutioneller Belastungsanalyse.
Fallakte öffnenGesellschaft für Nummernressourcen
Mitgliedschaft, Satzung und Analysen zur Ressourcen-Governance aus dem NRS-Ökosystem.
NRS-Sitzung öffnenICANN
DNS-Koordination, Rechenschaftsrahmen und Dynamiken globaler Multi-Stakeholder-Prozesse.
ICANN-Sitzung öffnenIETF
Entwicklung der Protokollstandardisierung und Interoperabilitätsrisiko unter fragmentierten politischen Bedingungen.
IETF-Sitzung öffnenGeschichte des Internets
Langzyklische Infrastrukturgeschichte zur Interpretation von Governance und für Strukturprognosen.
Historische Sitzung öffnenNOGs
Erkenntnisse zur Implementierung auf Betreiberebene von APRICOT sowie aus regionalen und nationalen NOG-Ökosystemen.
NOGS-Sitzung öffnen