Zum Hauptinhalt springen

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ächterFallakteGesellschaft für NummernressourcenICANNIETFGeschichte des InternetsNOGS
Governance Signaldarstellung
GovernanceGovernance
FokusInstitutionelle Governance

Signale für politische Kontinuität, Legitimität und Rechenschaftspflicht in Internet-Governance-Institutionen.

AktuellSieben Governance-Bereiche

RIR-Wächter, Fallakte, NRS, ICANN, IETF, Geschichte des Internets und NOG-Sitzungen

SignalHandeln statt Reden

Bei der Abdeckung liegt der Schwerpunkt auf Umsetzungsnachweisen und institutionellem Verhalten statt auf Positionsbekundungen.

Aktuelle Berichterstattung

Aktuelles zu Governance

7.559 Artikel

LWAPP ist ein historischer Datensatz, keine Deployment-Grundlage

IETF

LWAPP ist ein historischer Datensatz, keine Deployment-Grundlage

RFC 5412 hält den Lightweight Access Point Protocol-Stand fest, wie er in die CAPWAP-Arbeit eingebracht wurde. Die Beschreibung der Controller- und Lightweight-AP-Architektur ist als Archiv nützlich, doch der RFC Editor führt das Dokument als Historic und warnt vor seiner Nutzung…

8. Okt. 2026
Bei PP-26 gibt es eine Redeliste; formelle Vorschläge brauchen eine eigene Spur

Fallakte

Bei PP-26 gibt es eine Redeliste; formelle Vorschläge brauchen eine eigene Spur

Drei Minuten reichen, um einer politischen Priorität im Plenum Gehör zu verschaffen. Sie reichen nicht, um zu zeigen, was die Konferenz anschließend daraus macht. Noch vor der Eröffnung von PP-26 hat die ITU die Regeln für politische Erklärungen veröffentlicht: eine hochrangige…

8. Okt. 2026
CATS wählte den Servicekontakt. Die ausführende Instanz blieb verborgen: RFC 10053

IETF

CATS wählte den Servicekontakt. Die ausführende Instanz blieb verborgen: RFC 10053

CATS kann eine Anfrage anhand von Netz- und Rechenressourcen zu einem geeigneten Servicekontakt lenken. Diese Auswahl zeigt jedoch nicht zwangsläufig, welche interne Serviceinstanz die Anfrage bearbeitet – oder ob die gemeldeten Metriken nur diese Instanz beschreiben.

8. Okt. 2026
Der Controller brauchte erst ein Netz, bevor er es steuern konnte: RFC 7149

Geschichte

Der Controller brauchte erst ein Netz, bevor er es steuern konnte: RFC 7149

Im März 2014 forderte ein IETF-Memo Netzbetreiber auf, über das einprägsame Bild eines zentralen Controllers hinauszudenken: Wie entdeckt er Geräte, erreicht sie und beeinflusst das Netz sicher, das er steuern soll? RFC 7149 behandelte Inbetriebnahme, Aushandlung von…

8. Okt. 2026
Ein SIP-Leitfaden ist eine Karte, kein Deployment-Zertifikat

IETF

Ein SIP-Leitfaden ist eine Karte, kein Deployment-Zertifikat

RFC 5411 macht die große SIP-Familie navigierbar: Die Spezifikationen werden nach Themen geordnet, ihr Dokumentstatus wird markiert und verwandte Arbeiten werden verknüpft. Dennoch ist es ein datierter Informations-Schnappschuss und kein aktuelles Verzeichnis dessen, was ein…

8. Okt. 2026
DHCP transportierte eine stabile Teilnehmerkennung, deren Bedeutung der Standard offenließ: RFC 3993

Geschichte

DHCP transportierte eine stabile Teilnehmerkennung, deren Bedeutung der Standard offenließ: RFC 3993

Ein Kunde konnte den Zugangsweg wechseln, während der Anbieter dieselbe Konfigurationsentscheidung beibehalten wollte. RFC 3993 gab dem DHCP-Relay ein Feld für eine stabile Teilnehmerkennung; was sie bedeutete und wer sie vergab, blieb Sache des Anbieters.

8. Okt. 2026
Die Erweiterung trug eine Schlüsselmeldung. Sie bewies nicht die Installation.

IETF

Die Erweiterung trug eine Schlüsselmeldung. Sie bewies nicht die Installation.

RFC 5410 definiert eine MIKEY-General-Extension für OMA BCAST 1.0. Sie transportiert STKM, LTKM, LTKM-Berichte und Jugendschutzdaten. Ein empfangener Type-5-Payload ist kein Beleg für installierte Schlüssel, aktiven Kontext oder erlaubte Wiedergabe.

8. Okt. 2026
CMS verpackte den Schlüssel. Die Empfängeridentität musste trotzdem passen.

IETF

CMS verpackte den Schlüssel. Die Empfängeridentität musste trotzdem passen.

RFC 5409 beschreibt BF/BB1 in CMS: die Inhaltsverschlüsselungsschlüssel werden geschützt, die Empfängeridentität wird kodiert und OIDs wählen den Algorithmus. Ein lesbarer Inhalt ist noch keine Berechtigung.

8. Okt. 2026
Eine Identität kann einen öffentlichen Schlüssel bilden. Sie ist noch keine Berechtigung.

IETF

Eine Identität kann einen öffentlichen Schlüssel bilden. Sie ist noch keine Berechtigung.

Identity-Based Encryption erlaubt dem Absender, aus Identität und öffentlichen Parametern direkt einen öffentlichen Schlüssel zu berechnen. Der Private-Key-Generator (PKG) stellt das passende Geheimnis erst auf Anfrage bereit. RFC 5408 beschreibt diesen Ablauf als Architektur für…

8. Okt. 2026
Ein besserer Edge-Standort macht eine Sitzung noch nicht migrierbar: RFC 10054

IETF

Ein besserer Edge-Standort macht eine Sitzung noch nicht migrierbar: RFC 10054

Ein Client kann den Bereich wechseln, während der Sitzungszustand am bisherigen Edge-Standort bleibt. RFC 10054 verbindet Rechen- und Netzwerkbedingungen bei der Instanzauswahl. Für die Lenkung einer laufenden, zustandsbehafteten Sitzung muss die Anwendung jedoch ausdrücklich…

8. Okt. 2026
CNCFs Faktor 2,07 braucht eine klare Beschreibung der untersuchten Projekte

Fallakte

CNCFs Faktor 2,07 braucht eine klare Beschreibung der untersuchten Projekte

CNCF berichtet, dass Projekte, deren Maintainer beim Eintritt in die Sandbox mehrere Organisationen vertraten, später häufiger den Status Graduated erreichen. Die aktuelle Governance-Review-Vorlage verlangt separat, dass bei der Graduation Maintainer aus mindestens zwei…

8. Okt. 2026
Der Kanal war gebunden; die Operation blieb eine eigene Entscheidung.

IETF

Der Kanal war gebunden; die Operation blieb eine eigene Entscheidung.

An SIP gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5407 draws a harder line: SIP Version 2 can bind a SIP message to lower-channel information, but the binding does not become local…

8. Okt. 2026
Protokollstufe 2 galt je Sitzung, nicht für das ganze Gerät: RFC 7147

Geschichte

Protokollstufe 2 galt je Sitzung, nicht für das ganze Gerät: RFC 7147

Ein iSCSI-Speichersystem kann mehrere Initiatoren über getrennte Sitzungen bedienen. RFC 7147 verankerte die ausgehandelte Protokollstufe deshalb in jedem Sitzungsdatensatz: Sie beschreibt die Vereinbarung zwischen zwei Endpunkten, nicht eine dauerhafte Eigenschaft des Geräts.

8. Okt. 2026
Der Kanal war gebunden; die Operation blieb eine eigene Entscheidung.

IETF

Der Kanal war gebunden; die Operation blieb eine eigene Entscheidung.

An IPsec gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5406 draws a harder line: IPsec Version 2 can bind a IPsec message to lower-channel information, but the binding does not become…

8. Okt. 2026
Der Kanal war gebunden; die Operation blieb eine eigene Entscheidung.

IETF

Der Kanal war gebunden; die Operation blieb eine eigene Entscheidung.

An RTP gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5404 draws a harder line: G.719 RTP Version 2 can bind a G.719 frame block to lower-channel information, but the binding does not…

8. Okt. 2026
Der Kanal war gebunden; die Operation blieb eine eigene Entscheidung.

IETF

Der Kanal war gebunden; die Operation blieb eine eigene Entscheidung.

An RPC gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5403 draws a harder line: RPCSEC_GSS Version 2 can bind a GSS context to lower-channel information, but the binding does not…

8. Okt. 2026
Authentifizierung durfte einseitig sein, die Kanalbindung nicht: RFC 5387

IETF

Authentifizierung durfte einseitig sein, die Kanalbindung nicht: RFC 5387

Zwei gültige IPsec-Sicherheitsassoziationen können in einem Audit tadellos aussehen und dennoch von einem unbefugten Vermittler verbunden sein. RFC 5387 trennt deshalb zwei Fragen: Wer muss seine Identität beweisen, und haben beide Endpunkte tatsächlich denselben geschützten…

8. Okt. 2026
Die globale Adresse konnte Leihgabe sein, nicht Host-Identität: RFC 1335

Geschichte

Die globale Adresse konnte Leihgabe sein, nicht Host-Identität: RFC 1335

Im Mai 1992 begann ein Vorschlag angesichts des Zuteilungsdrucks bei IPv4 mit einer unscheinbaren Unterscheidung: Ein Rechner könnte seine Adresse im eigenen Netz behalten und eine weltweit eindeutige Adresse nur dann ausleihen, wenn er mit dem Internet außerhalb dieses Netzes…

8. Okt. 2026
APNOG stellt die Amtszeit auf März um. Der Wechsel muss nachvollziehbar sein.

APRICOT

APNOG stellt die Amtszeit auf März um. Der Wechsel muss nachvollziehbar sein.

APNOG hat beschlossen, dass die Amtszeiten des Boards von März bis März laufen und damit nicht genau mit der Jahresversammlung zusammenfallen. Die veröffentlichte Begründung ist praktisch: Das scheidende und das neue Board sollen Aufgaben übergeben können; neue Direktoren sollen…

8. Okt. 2026
Vor oder nach der Signatur komprimiert: derselbe Beleg ist es nicht

IETF

Vor oder nach der Signatur komprimiert: derselbe Beleg ist es nicht

Zwei Archive enthielten dieselbe lesbare Bestellung. In einem Fall hatte die Signatur den komprimierten CMS-Inhalt geschützt, im anderen den unkomprimierten MIME-Teil, bevor alles gemeinsam komprimiert wurde. RFC 5402 erlaubt beide Reihenfolgen. Für eine belastbare Wiederholung…

8. Okt. 2026

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 öffnen

Fallakte

Langfristige Governance-Dossiers mit rechtlicher, wahlbezogener und institutioneller Belastungsanalyse.

Fallakte öffnen

Gesellschaft für Nummernressourcen

Mitgliedschaft, Satzung und Analysen zur Ressourcen-Governance aus dem NRS-Ökosystem.

NRS-Sitzung öffnen

ICANN

DNS-Koordination, Rechenschaftsrahmen und Dynamiken globaler Multi-Stakeholder-Prozesse.

ICANN-Sitzung öffnen

IETF

Entwicklung der Protokollstandardisierung und Interoperabilitätsrisiko unter fragmentierten politischen Bedingungen.

IETF-Sitzung öffnen

Geschichte des Internets

Langzyklische Infrastrukturgeschichte zur Interpretation von Governance und für Strukturprognosen.

Historische Sitzung öffnen

NOGs

Erkenntnisse zur Implementierung auf Betreiberebene von APRICOT sowie aus regionalen und nationalen NOG-Ökosystemen.

NOGS-Sitzung öffnen