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.749 Artikel

Geschichte
DHCPv6 konnte den SIP-Proxy finden, aber keinen Anruf aufbauen: RFC 3319
Eine DHCPv6-Antwort konnte einem SIP-Client eine geordnete Liste lokaler ausgehender Proxys übermitteln: als Domänennamen, IPv6-Adressen oder beides. Damit ließ sich der nächste Kontrollpunkt finden. Die Antwort belegte weder eine Registrierung noch abgeschlossene Signalisierung…

Geschichte
Der Router musste melden, welchen Policy-Graphen er ausführen konnte: RFC 3317
Die Tiefe eines Policy-Graphen war keine ästhetische Frage. Sie konnte an einer Pipeline, einem ASIC oder der zulässigen Verbindung zweier Funktionsblöcke enden.

IETF
Der Endpunkt erkannte Verlust nach Zeit. Die Schicht darunter wartete trotzdem.
Der Transport hatte gelernt, Umordnung von Verlust zu unterscheiden. Die Sicherungsschicht behandelte ihn weiter wie einen alten Empfänger und hielt sofort weiterleitbare Frames zurück. Der neue INTAREA-Entwurf zeigt damit nicht nur ein Latenzproblem, sondern eine veraltete…

IETF
Zwei Zähler sind noch kein Ende-zu-Ende-Beweis
Wenn Interface- und Flow-Daten ähnlich aussehen, ist Korrelation verlockend. Ohne stabilen Flow-Anker kann ein System jedoch zwei präzise Messungen zu einer falschen Kausalgeschichte verbinden.

Geschichte
Die Anwendung konnte belegen, dass der Router erreichbar war: RFC 3316
Auf frühen Mobilfunkverbindungen mit IPv6 konnte eine Rückmeldung der Gegenstelle eine zusätzliche Funksonde ersparen – weil sie genau eine Aussage über ein kurz zuvor gesendetes Paket zuließ.

Geschichte
Der Link hatte keine MAC-Adresse. Der Host musste dennoch die Erreichbarkeit prüfen: RFC 3316
Auf einer GPRS- oder UMTS-Verbindung musste ein IPv6-Host die Link-Layer-Adresse des Routers nicht erst ermitteln. Eine solche Adresse gab es dort nicht. Trotzdem musste der Host wissen, ob der Standardrouter erreichbar blieb; manchmal konnte die Antwort eines anderen Protokolls…

IETF
Auch die Netzkarte braucht ein Verkehrsbudget
Eine aktuelle Infrastrukturkarte hilft im Betrieb. Ihre Abfragen und Aktualisierungen nutzen jedoch genau das Netz, das sie beschreiben soll. Die jüngste SIMAP-Fassung macht daraus eine ausdrückliche Bedingung: Der Kartendienst darf keine anhaltende Überlastung verursachen.

IETF
Der Client reparierte nur den ersten Digest und geriet in eine Schleife
Mehrere Digest- und Präferenzfelder können mehrere Diagnoseeinträge erzeugen. Deren Reihenfolge ist keine Prioritätenliste, und der erste behobene Fehler ist keine Zusage, dass der nächste Versuch zugelassen wird.

IETF
Der leere Finalize-Body ist kein leerer Vorgang
Im vorgeschlagenen ACME-Ablauf ohne CSR enthält die letzte Anforderung nur noch `{}`. Das wirkt wie eine Vereinfachung am Ende. Tatsächlich wurden die entscheidenden Angaben nach vorn verlegt: Zertifikatsschlüssel, exakte Auftragsbytes, Besitznachweis, Identifier-Autorisierung…

Geschichte
Die schnelle Antwort konnte eine ungenutzte Adresse hinterlassen: RFC 3315
Der kurze DHCPv6-Pfad sparte nicht nur zwei Nachrichten: Der Server musste die Adresse festlegen, bevor er wissen konnte, ob seine Antwort den Client erreicht hatte.

Geschichte
AES kam mit zwölf Kombinationen in TLS, nicht als Einzelwahl: RFC 3268
2002 ergänzte TLS AES, ohne den Handshake neu zu entwerfen. Der Algorithmus kam als zwölf Cipher Suites ins Protokoll: Verschlüsselung allein konnte weder Schlüsselaustausch noch Authentisierung festlegen.

IETF
Der Empfänger kannte noch ein gutes Referenzbild. Der Sender hatte es bereits verworfen.
Eine Resynchronisationsmeldung benennt Zustand beim Empfänger. Ob daraus ein neues Bild codiert werden kann, entscheidet zusätzlich der Referenzpuffer des Senders. Erst beide Enden zusammen begründen eine belastbare Wiederanlaufentscheidung.

IETF
Bei TCP-AO ist „KMAC“ noch keine vollständige Rezeptur
Zwei Gegenstellen können dieselbe kryptografische Bezeichnung anzeigen und dennoch unterschiedliche Verkehrsschlüssel berechnen. Der neue TCPM-Entwurf legt fest, welche NIST-Variante hinter seiner vorgeschlagenen KMAC-Ableitung für TCP-AO steht. Daraus folgt eine konkrete…

Geschichte
Der Zufallsschlüssel rettete nichts. Er brachte den Fehler zum Schweigen: RFC 3218
Ein CMS-Empfänger konnte eine verschlüsselte Nachricht ablehnen, noch bevor er deren Inhalt berührte. Eine genaue Fehlerursache wirkte wie saubere Ingenieursarbeit, bis ein Angreifer dieselbe Frage tausendfach stellen konnte. RFC 3218 verlangte deshalb etwas Widersprüchliches…

Geschichte
Die URL war keine eigene Schublade mehr: RFC 3305
In der frühen Web-Zeit schien die Trennung einfach: Eine URL sagte, wohin man gelangen konnte; eine URN benannte etwas unabhängig von seinem Ort. 2002 hielt eine gemeinsame Planungsgruppe von W3C und IETF in RFC 3305 dagegen: Diese saubere Zweiteilung erschwerte zunehmend das…

IETF
Die Gruppe blieb gleich. Der Fünf-Tupel war schon weitergezogen.
Der Controller übersetzte eine stabile Gruppenkennung in eine konventionelle ACL. Bevor alle Durchsetzungspunkte die Regel erhielten, wechselte die Anwendung den Host und damit ihre Paketkoordinaten. Die Absicht blieb richtig, ihre Projektion wurde alt.

Geschichte
Die Bestätigung sagte, der NAK sei gehört worden – nicht, dass die Reparatur ankam: RFC 3208
PGM verzichtete auf positive Quittungen jedes einzelnen Multicast-Empfängers. Ein Empfänger meldete eine Lücke per NAK, Netzelemente bestätigten und verdichteten die Anfragen, und Reparaturzustand begrenzte RDATA auf betroffene Zweige. Diese Skalierung machte aus dem NCF weder…

Geschichte
Eine Milliarde Nutzer hätte die Mehrheit noch ausgeschlossen: RFC 3271
2002 prognostizierte Vint Cerf bis Ende 2005 mehr als eine Milliarde Internetnutzer – und stellte unmittelbar klar, dass dies nur etwa 16 Prozent der Weltbevölkerung entspräche. Dieser Abstand macht aus „Das Internet ist für alle da“ mehr als einen Wachstumsslogan: eine Prüfung…

IETF
RadSec verwirft die Antwort und lässt die Verbindung bestehen
Ein verspätetes RADIUS-Paket kann auf eine Kennung treffen, die bereits einem neuen Auftrag gehört. Der überarbeitete RadSec-Entwurf verlangt dann eine saubere Trennung: falsche Antwort verwerfen, geschützte Verbindung nicht allein deshalb kappen.

IETF
Der Cone enthielt AS-Nummern. Das nächste System las Präfixe.
Die Übergabe war syntaktisch einwandfrei und semantisch unbrauchbar. Ein Team hatte mit `cone` eine Menge nachgelagerter autonomer Systeme bezeichnet; der nachfolgende Dienst behandelte denselben Wert wie eine Menge von IP-Präfixen. Ein vertrautes Wort hatte den Datentyp…
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