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

Geschichte
Der Sender sah den Verlust, nicht seine Ursache: RFC 3155
Im August 2001 beschrieb RFC 3155 eine Grenze, die mitten durch die Verlässlichkeit von TCP verlief. Der Sender konnte erkennen, dass der Bestätigungsfortschritt abgerissen war. Er konnte aber nicht zuverlässig feststellen, ob eine volle Warteschlange, ein unberichtigter…

Geschichte
Das Relay ergänzte einen Header. Das Nachrichtenende konnte fehlen: RFC 3164
Im älteren BSD-syslog-Format konnte ein Relay eine Nachricht durch Zeitstempel und Hostnamen lesbarer machen. RFC 3164 begrenzte jedoch das gesamte Paket auf 1.024 Byte: Der neue Header konnte den Platz belegen, den der Ereignistext am Ende brauchte.

IETF
Die Domain erlaubte eine Frage, aber keine Handlung
`dialogue.txt` schlägt eine öffentliche Tür vor, an der ein unbekannter Mensch oder ein Softwaresystem anfragen darf. Entscheidend ist die Grenze dahinter: Auffinden ist kein Zutritt, Zustellung ist kein Gespräch, und selbst eine Antwort erteilt noch keine Befugnis, im Namen des…

Geschichte
Der Empfänger bot Multiplexing an. Der Sender entschied weiterhin über die Nutzung: RFC 3153
Bei RFC 3153 lag zwischen „ausgehandelt“ und „ausgeführt“ eine absichtliche Lücke. Der PPP-Empfänger konnte zusagen, multiplexierte Frames zu verstehen. Der Sender durfte das Format danach verwenden, musste es aber nicht. Damit war die Kontrollmeldung nur eine Erlaubnis. Erst ein…

Berichte
Bei RIPE NCC wird der RPKI-Schlüssel moderner – seine Reichweite muss enger werden
RIPE NCC bindet das RPKI-Dashboard und künftige API-Schlüssel an OpenID Connect. Auf derselben Planungsseite steht, warum eine RPKI-Routing-Beacon noch nicht umgesetzt wurde: Die dafür vorgesehene API hätte ROAs für den gesamten Adressraum von RIPE NCC bearbeiten können. Diese…

Geschichte
Der Server brauchte eine dritte Zufallszahl: RFC 3163
Im gegenseitigen Authentisierungsmodus von RFC 3163 war der dritte Zufallswert kein Beiwerk. Er reagierte auf eine Asymmetrie im Ablauf: Als der Client seinen eigenen Wert auswählte, kannte er bereits die erste Herausforderung des Servers. Die Korrektur war eng umrissen – ebenso…

Geschichte
Der neue Reverse-Baum existierte, bevor der alte verschwand: RFC 3152
Ein Standard kann das Ziel einer Migration festlegen, aber keinen weltweiten Umschaltmoment erzeugen. RFC 3152 setzte 2001 `IP6.ARPA` an die Wurzel des IPv6-Reverse-DNS, verlangte die Delegation entlang der Adressvergabe und erklärte `IP6.INT` für neue Implementierungen als…

IETF
Das Mapping-System kannte das Ziel nicht. Trotzdem lieferte es einen Ausgang.
Ein neuer LISP-Entwurf lässt für externe oder nicht registrierte Ziele dynamisch einen pETR auswählen. Das spart statische Konfiguration. Es darf aber nicht den entscheidenden Unterschied verdecken: Ein bekannter Ausgang ist noch kein bekanntes Ziel und schon gar kein…

IETF
Ein Laborwert ist kein Urteil über das produktive Netz
Die IETF erwägt, zwei Traditionslinien der Leistungsbewertung in einer Arbeitsgruppe zu bündeln. Der neue Charterentwurf präzisiert, unter welchen Bedingungen gemessen wird – und wem die Entscheidung über eine ausreichende Leistung gerade nicht abgenommen wird.

Geschichte
IPv6 musste auf die Authentifizierung warten: RFC 3162
Der Zugangsserver musste die Sitzung autorisieren, bevor feststand, welches Internetprotokoll der Host verwenden würde. RFC 3162 ließ eine RADIUS-Nachricht beide Möglichkeiten tragen und überließ dem Netzrand die Entscheidung, welche davon anwendbar war.

ICANN
Zwischen 1.616 Anträgen und 1.616 TLDs liegt fast das ganze Verfahren
Am Reveal Day wird ICANN einen bislang verborgenen Markt von Ansprüchen sichtbar machen. Sichtbar werden Bewerber, Zeichenfolgen und Konkurrenzlagen. Eine delegierte, funktionierende und genutzte Namenszone entsteht daraus erst nach vielen eigenständigen Entscheidungen – sofern…

Geschichte
Der alte Name wurde zur URN. Aufgelöst war er damit noch nicht: RFC 3151
XML erbte öffentliche Bezeichner, die eine Maschine überdauern konnten, aber nicht in jedes URI-Pflichtfeld passten. RFC 3151 gab ihnen eine genaue `urn:publicid:`-Transkription. Der normalisierte Name wurde vergleichbar und transportierbar. Das Präfix registrierte keinen…

IETF
Die DHCP-Antwort nannte 1 Gbit/s. Der Engpass blieb trotzdem bestehen.
Eine neue DHCP-Option soll die vorgesehene Anschlussrate an CPE und Zugangsknoten verteilen. Das kann Shaping und Queue-Management erheblich erleichtern. Doch die Zahl ist zunächst eine Policy-Aussage: keine Messung des Pfads, keine Quittung über die eingerichtete Queue und keine…

Geschichte
Ein Paket konnte den übrigen Verkehr warten lassen: RFC 3150
Auf einer sehr langsamen Leitung bestimmt die Paketgröße auch, wie lange andere gemeinsam genutzte Datenströme auf ihre Sendemöglichkeit warten. RFC 3150 machte diese Zeit zu einer Entwurfsfrage und behandelte die MTU nicht nur als Maß für Byte-Effizienz.

Berichte
DFINFRA / AS210860: Das frozen Registrierungsobjekt und der lebendige Routing-Nachbar
Die Analyse-Zusammenfassung zu DFINFRA / AS210860: Das frozen Registrierungsobjekt und der lebendige Routing-Nachbar erläutert die Entwicklung, die öffentlich zugänglichen Belege, die beteiligten Organisationen, den regionalen Kontext, die Marktexposition und die möglichen…

Geschichte
Der Call Agent steuerte die Funktionen. Die Stummschalttaste blieb lokal: RFC 3149
MGCP verlagerte die Intelligenz der Anrufsteuerung aus dem Telefon heraus. RFC 3149 schickte deshalb jedoch nicht jede Berührung über das Netz. Ein Call Agent konnte nummerierte Funktionstasten deuten, Beschriftungen und Leuchten setzen und eine XML-Anzeige bedienen. Lautstärke…

Geschichte
Ein und derselbe Pfad konnte zwei gültige Kapazitätswerte liefern: RFC 3148
Eine Messung großer Datenübertragungen über einen einzelnen Fluss schien auf eine Zahl hinauszulaufen. RFC 3148 zeigte, warum Transportentscheidungen diese Zahl methodenabhängig machen konnten – und warum die Aufzeichnungen zum Pfad dazugehören.

IETF
Acht Antworten kamen zurück. Die Anwendung war damit noch nicht gemessen
RFC 10052 kann aus einer STAMP-Anfrage eine asymmetrische Antwortfolge machen. Damit lässt sich Prüfverkehr gezielt formen. Doch weder die gewünschte Form noch ein gesetztes oder nicht gesetztes C-Bit beweist, wie eine Anwendung lief, welche Kapazität verfügbar war oder was ein…

Geschichte
Das neue Managementnetz musste das alte durchqueren: RFC 3147
Auf einem Migrationsplan ersetzt das neue Netz das alte. Im Betrieb konnte jedoch ein neues, per IP verwaltetes SONET- oder SDH-Element jenseits eines CLNS-Netzes stehen, das noch nicht abgeschaltet werden durfte. RFC 3147 legte GRE in CLNP und erhielt den Weg. Gerade dadurch…

IETF
Der Link galt als schlafend. Seine Rückkehr war nicht bewiesen.
Ein Netz muss sich an abgeschaltete Ressourcen erinnern, sonst kann es sie bei steigender Last nicht wiederfinden. Doch eine gespeicherte Schlafzustandsmeldung ist nur Kontrollwissen. Sie ist weder der Beleg für den physischen Übergang noch die Zusage, dass beide Enden und die…
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