BTW.Media
TagesausgabeStrategische Internetanalysen
AnmeldenRegistrieren

Briefing-Desk

Neueste Briefings

Kompakte Berichterstattung über die Entwicklungen, die Internet-Governance und -Infrastruktur prägen. Durchstöbern Sie jeden Bereich nach aktuellen Nachrichten, Kontext und Beobachtungspunkten.

Abdeckung

Governance / IETF

In diesem Abschnitt: 21 Briefings

  1. Wer unverändert weiterleitet, hinterlässt nicht automatisch eine Spur

    Ein unveränderter Nachrichteninhalt kann einen vollständigen Weg vortäuschen. Der überarbeitete Entwurf zu WIMSE fragt deshalb nicht nur, wer eine Anfrage verändert hat, sondern auch, wer sie ohne Änderung weitergegeben hat.

  2. SUIT: Ein gültiges Manifest kennt die Fähigkeiten des Zielgeräts nicht

    Ein Update kann korrekt signiert sein und trotzdem auf einen optionalen Befehl angewiesen sein, den das Zielgerät nicht beherrscht. Die neue Fassung des SUIT-Entwurfs verortet das Wissen über diese Fähigkeit bei der konkreten Bereitstellung.

  3. Das Zertifikat galt für die Nummer. Über den Anruf war noch nicht entschieden

    Ein dynamischer Nummernbestand passt schlecht zu einer pauschalen Zertifikatsampel. Das neue STIR-OCSP-Profil fragt deshalb genauer: Gehört diese eine Rufnummer noch zum Geltungsbereich? Die Antwort schließt eine Beweislücke, ohne aus Zertifikatsstatus ein Urteil über Menschen oder Gespräche zu machen.

  4. Viele SR-Policies ohne Paketverlust sind noch kein ECMP-Tempo-Test

    Ein Router kann mit zahlreichen Segment-Routing-Policies zuverlässig weiterleiten, ohne dass damit die Leistung seiner Mehrwegeverteilung vermessen wäre. Der neue BMWG-Entwurf hält diese Aussagegrenzen auseinander. Genau diese Grenze muss erhalten bleiben, wenn Laborwerte später in Beschaffungsvorlagen landen.

  5. LAKE-AuthKEM streicht eine Vier-Nachrichten-Abkürzung mit offener Identität

    Eine Nachricht weniger ist bei kleinen Geräten verlockend. Im Juli-Entwurf hätte die Initiatorseite dafür ihre Kennung gleich zu Beginn im Klartext offengelegt. Die Fassung vom 28. September enthält diese Variante nicht mehr; sie beschreibt fünf verpflichtende Nachrichten und zwei unterschiedliche Zeitpunkte, an denen die Seiten den Austausch abschließen können.

  6. Der Server markierte die Datei als nicht cachebar. Der Client musste noch folgen

    NFSv4.2 erhält voraussichtlich ein standardisiertes Signal, mit dem ein Server von Clients verlangen kann, Dateidaten nicht dauerhaft zwischenzuspeichern. Gerade seine enge Bedeutung macht es nützlich: Es hält eine Anweisung fest, nicht deren Erfüllung.

  7. BGP-Bestpfad-Entwurf: Was geschieht nach einer gescheiterten Weiterleitungsprüfung?

    Ein erreichbarer Next Hop in der Routentabelle kann auf einen Datenpfad zeigen, der die Pakete nicht trägt. Eine frühe IETF-Fachbegutachtung sieht in der geplanten BGP-Ergänzung eine Lücke zwischen der Prüfung eines Weiterleitungszustands und der Entscheidung über die Route.

  8. Der Empfänger trägt die Akkukosten. Über das Bild entscheidet weiter der Sender.

    Zwischen einer Bitte und ihrer Umsetzung liegt künftig ein prüfbarer RTCP-Austausch. Ein Videogerät kann weniger Bilder oder Pixel anfordern; die Gegenseite muss mitteilen, welche Werte sie tatsächlich wählt. Gerade die mögliche Abweichung zeigt, dass der Standard Mitsprache schafft, ohne die Kontrolle über den Encoder zu übertragen.

  9. Der HPKE-Nachfolger ersetzt nicht automatisch die alten Auth-Modi

    Ein neuer Normverweis kann vorhandene Anwendungen nicht von einer Sicherheitsannahme entbinden. Der HPKE-Entwurf in der IESG-Bewertung lässt zwei Authentifizierungsmodi aus RFC 9180 aus, hält aber eine Kompatibilitätsspur im Register offen.

  10. Das Gerät hat den Schlüssel belegt. Das Zertifikat belegt keinen fortdauernden Zustand

    Die genehmigte ACME-Erweiterung kann einen Zertifikatsantrag an ein Gerät oder Kryptomodul binden. Dieser Nachweis gehört zum Ausstellungszeitpunkt. Er ist weder ein laufender Gesundheitsbericht noch ein Beleg für heutigen Besitz oder jede spätere Schlüsselverwendung.

  11. Ein Quelladressfilter erkennt seine Fehlentscheidungen nicht allein

    Der SAVNET-Entwurf in der IESG-Last-Call-Phase benennt eine unbequeme Betriebsgrenze: Der Grenzrouter setzt eine Regel durch, aber der Hinweis auf eine fälschlich unterbrochene Verbindung kann zuerst beim Nachbarn auftreten.

  12. BIER Ping meldete Weiterleitungserfolg. Ein fehlender Ausgang konnte im BitString verborgen bleiben

    Seit dem 21. September 2026 ist BIER Ping vom IESG als Proposed Standard gebilligt. Der Entwurf macht Weiterleitungsverhalten genauer messbar. Gerade deshalb muss das Ergebnis genau gelesen werden: Die erfolgreiche Antwort eines BFER ist keine Sammelquittung für alle gesetzten Bits.

  13. Der letzte RSVP-Authentifizierungsschlüssel kann nach Ablauf weitergelten

    Ein Ablaufdatum wirkt eindeutig, solange ein Nachfolger bereitsteht. Fehlt er, droht bei RSVP ein Konflikt zwischen der Authentifizierung von Signalisierung und der Verfügbarkeit bestehender Reservierungen. Ein TEAS-Entwurf beschreibt dafür eine Ausnahme — und legt damit eine Frage der Verantwortung offen.

  14. Bei C509 wird das Zertifikat kleiner – die Signaturgrenze bleibt exakt

    Eine kompakte Zertifikatskette entlastet knappe Übertragungswege. Sie ersetzt aber nicht den Nachweis, welche Bytes eine Signatur tatsächlich umfasst und ob ein Prüfer nach der Umkodierung dieselbe Vertrauensentscheidung trifft.

  15. Kein Normenkonflikt gefunden. Der Fabrikschlüssel hat trotzdem keine Sicherheitsnote

    Der IESG-Konfliktcheck sieht kein Hindernis für die Veröffentlichung einer IRTF-Taxonomie zu herstellerseitig eingebrachten Schlüsseln und Vertrauensankern. Damit ist eine Verfahrensfrage geklärt. Die fünf Fertigungsmethoden sind weder bewertet noch ist die Geheimhaltung eines ausgelieferten Schlüssels belegt.

  16. Ein Empfänger entschlüsselte das JWE. Die Empfängerregel war damit noch nicht erfüllt

    Ein JWE für mehrere Empfänger kann Klartext liefern, sobald ein einziger Empfängerpfad funktioniert. Das neue HPKE-Profil macht diesen Erfolg prüfbar. Ob genau dieser Empfänger genügen durfte, alle Pflichtempfänger erreichbar waren und jeder Algorithmus zugelassen war, bleibt eine Entscheidung der Anwendung.

  17. SATP verlangt Checkpoints, standardisiert aber noch keinen Neustartpunkt

    Ein Ersatz-Gateway kann nur dann sicher übernehmen, wenn es nicht bloß das Protokollprotokoll, sondern auch den dauerhaften Zustand seines Vorgängers versteht. SATP beschreibt diese Möglichkeit, verschiebt die gemeinsame Semantik dafür jedoch auf spätere Arbeit.

  18. JOSE setzt drei Sicherheitsziele an das Registertor, aber kein Betriebsurteil

    Im neuen JOSE Last Call steckt die langfristige Änderung nicht nur in zwei alten Algorithmen. Drei präzise Sicherheitsziele sollen aus allgemeiner kryptografischer Plausibilität eine überprüfbare Frage machen. Besonders wichtig: Bei Schlüsselverwaltung zählt das gesamte JWE-Verfahren, nicht der Ruf eines einzelnen Bausteins.

  19. Eine Netzfunktion, vier Sicherheitsaufgaben: Die Zertifikatswahl, die RFC 9509 dem Betreiber ließ

    Ein gültiges Zertifikat beantwortet im 5G-Kernnetz nur die erste Frage. Für TLS, eine Client Credentials Assertion, geschütztes JSON zwischen SEPPs und OAuth-Token gelten unterschiedliche Aufgaben. RFC 9509 benennt drei davon, überlässt aber die Bündelung der Schlüssel dem Betrieb.

  20. Das Byte war gleich. Das Timeout war es nicht: RFC 9510

    Ein CCNx-Zeitwert von einem Byte kann auf einem alten Forwarder Millisekunden und auf dem nächsten Gerät Jahre bedeuten. RFC 9510 spart Platz, macht aber die Softwareversion zum Bestandteil jeder belastbaren Aussage.

  21. Der Locator war sichtbar. Die Route war es nicht: RFC 9514

    Ein BGP-LS-Consumer kann einen gültigen SRv6 Locator sehen und dennoch keinen Nachweis für gewöhnliche Präfix-Erreichbarkeit besitzen. RFC 9514 trennt beide Aussagen durch ein zusätzliches TLV; das verifizierte Erratum 7737 berichtigt dessen Nummer auf 1155.

Abdeckung

Governance / Fallakte

In diesem Abschnitt: 18 Briefings

  1. Der Nachfolgeschlüssel wartete 30 Tage. Die Validatoren teilten keine Uhr: RFC 9691

    Eine Ressourcenerweiterung erreicht zuerst das Repository unter B und wenige Minuten später das unter A. Für den Betrieb mag das kurz wirken; für einen Validator, der genau dazwischen abruft, sind es zwei verschiedene Vertrauenswelten. RFC 9691 verlangt Gleichwertigkeit, doch der Betreiber muss sie herstellen und belegen.

  2. Das Zertifikat trug den Schlüssel, nicht das Ja des Empfängers: RFC 9690

    Ein valides RSA-Zertifikat kann einen sauberen kryptografischen Ausgangspunkt liefern und dennoch die falsche Versandentscheidung auslösen. RFC 9690 trennt deshalb den öffentlichen Schlüssel von der aktuellen Bereitschaft des Empfängers, RSA-KEM mit genau dieser Komponentenfolge zu verarbeiten.

  3. Der Proxy verband den LSP, nicht seine Zuständigkeiten: RFC 9689

    Ein Controller-Ausfall mitten im Umbau macht den Unterschied sichtbar: Alte Router halten weiterhin LDP- oder RSVP-TE-Zustand, neue Router behalten bereits geladene PCECC-Anweisungen. Der Pfad kann weiterlaufen, obwohl niemand aus einem einzigen Status ableiten kann, wem Umschaltung und Bereinigung gehören.

  4. Der Parser meldete SHA3-Unterstützung. Die empfangenen Parameter waren schon verloren

    Ein Decoder kann ein CMS-Objekt akzeptieren, den richtigen OID anzeigen und dennoch den Beleg zerstören, der zwischen konform und nur tolerant gelesen unterscheidet. RFC 9688 macht diese Grenze sichtbar: Abwesenheit, ASN.1-`NULL` und Customization sind keine austauschbaren Darstellungen.

  5. MOP 5 war kein Schalter. Die Migration brauchte eine neue Instanz

    RFC 9685 führt einen neuen Non-Storing-Betriebsmodus für Multicast ein, erlaubt aber nicht, eine laufende RPL-Instanz einfach darauf umzustellen. Wer aus einer Konfigurationsänderung eine abgeschlossene Migration macht, überspringt die Nachweise für Knotenwechsel, 6LR-Abdeckung, Routenzustand und tatsächliche Zustellung.

  6. Die Quote war echt. Der ausgewählte PCR wurde vom System nie erweitert

    RFC 9684 standardisiert YANG-RPCs für nonce-gebundene TPM Quotes und Messprotokolle. Ein erfolgreicher Aufruf beweist jedoch nur die ausgewählte Evidence. Ob der PCR aussagekräftig ist, der Schlüssel zum Ziel-TPM gehört, die Reference Values aktuell sind und eine Entscheidung tatsächlich durchgesetzt wurde, bleibt getrennt.

  7. Der Download war erfolgreich. Der Origin-Wechsel machte die RRDP-Sitzung unbrauchbar

    RFC 9674 trennt einen erreichbaren Speicherort von einem autorisierten Abrufziel. Eine RRDP Notification darf Snapshots, Deltas und Redirects nur innerhalb ihres Scheme-Host-Port-Tupels auslösen. Selbst ein erfolgreicher Same-Origin-Abruf ist jedoch kein Beleg dafür, dass validierte Payloads den Router erreicht oder eine Route verändert haben.

  8. Ein Web-API-Aufruf ist noch keine Browserfreigabe

    Eine Webseite kann eine Fähigkeit anfordern. Ob der Browser sie zulässt und wo er diese Entscheidung durchsetzt, lässt sich aus dem Aufruf allein nicht ablesen. Ein überarbeiteter W3C-Entwurf zeichnet die entscheidende Übergabe nun schon in seinem einfachsten Modell ein.

  9. Der Parser fand den Transport-Header nicht mehr. Das Dashboard nannte den Router trotzdem Hop-by-Hop-fähig

    RFC 9673 macht IPv6 Hop-by-Hop Options praktikabler, indem Verarbeitung lokal konfiguriert und an die aggregierte Weiterleitungsleistung gebunden wird. Eine längere Header-Kette kann jedoch die reale Inspektionsfläche eines Geräts verändern. Ein globales Fähigkeitslabel sagt dann weniger als Modell, Build, Option-Reihenfolge und tatsächlicher Pfad.

  10. YAML-LD benennt ein Parser-Risiko, ohne den Parser zu zertifizieren

    Eine knappe Datei kann beim Einlesen ein Vielfaches ihrer sichtbaren Größe erzeugen. Der neue Sicherheitshinweis des W3C-Entwurfs beschreibt diese Möglichkeit ausdrücklich; die Kontrolle der konkreten Bibliothek bleibt jedoch beim Betreiber.

  11. Der Controller war „802.11-2024-konform“. Die Hälfte der Access Points lief noch auf alten Images

    RFC 9672 übergab die künftige Pflege von OWE an die IEEE-802.11-Arbeitsgruppe. Damit ist die Zuständigkeit für den Text geklärt. Welche Geräte einen späteren Stand tatsächlich enthalten, testen, aktivieren und aushandeln, bleibt eine eigene Beweiskette.

  12. Der Eintrag landete im Standardkalender. Erfolgreich hieß noch nicht: am richtigen Ort

    RFC 9671 kann neue Kalenderobjekte ohne `:calendarid` im vom System bestimmten Standardkalender ablegen. Das ist interoperabel, aber kein Nachweis dafür, dass der organisatorisch richtige Kalender getroffen wurde.

  13. Die GPC-Unterstützungserklärung ist kein Nachweis für den Datenumgang

    Ein Browser kann einen Datenschutzwunsch übermitteln. Eine Website kann erklären, dass sie Global Privacy Control unterstützt. Ob sie die Daten einer bestimmten Person danach entsprechend verarbeitet, ist eine dritte Frage.

  14. Zwei Administratoren speicherten dieselbe Freigabekarte. Einer löschte unbemerkt die Entscheidung des anderen

    RFC 9670 macht `shareWith` zu einer gemeinsamen JMAP-Oberfläche für objektbezogene Freigaben. Gerade weil diese Oberfläche wie eine vollständige Karte wirkt, braucht jede Änderung einen State-Beleg: Ein erfolgreicher Save darf keine verlorene konkurrierende Autorisierungsentscheidung verdecken.

  15. Der Sprung traf das zweite Wort. Bekannte BPF-Bytes ergaben kein gültiges Programm

    Jeder Opcode stand in der Tabelle, und das Ziel meldete die passende Basisgruppe. Der Kontrollfluss sprang dennoch mitten in eine 128-Bit-Instruktion — genau dort endet die Aussagekraft einer bloßen Capability-Liste.

  16. NIST-Entwurf: Ein Multi-Cloud-Paket belegt noch keine einheitliche Freigabegrenze

    Wer mehrere Cloud-Angebote als verwalteten Dienst kauft, gibt Koordinationsarbeit ab. Die Frage, welche Komponenten und Kontrollen eine Sicherheitsentscheidung tatsächlich erfasst, bleibt damit offen. NIST IR 8613 beschreibt genau diese Lücke.

  17. message_3 war gültig. Die OSCORE-Anfrage erreichte die Anwendung trotzdem nicht

    RFC 9668 lässt den Abschluss von EDHOC und die erste OSCORE-Anfrage in derselben CoAP-Nachricht reisen. Der Server verarbeitet sie jedoch nacheinander. Eine erfolgreiche EDHOC-Prüfung begründet den Security Context, aber noch keinen Anwendungsaufruf.

  18. NISTs endgültiger Token-Bericht zieht eine Grenze zwischen Widerruf und Zugriffsstopp

    Ein Cloud-Anbieter kann einen Widerruf bestätigen, während ein zuvor ausgegebener Zugriffstoken an einer anderen Stelle noch gültig ist. IR 8587 macht aus diesem Unterschied eine Frage der geteilten Verantwortung.

Abdeckung

Markt / Unternehmen / Unternehmen aus Europa und dem Nahen Osten / Europa und Naher Osten Regionaler ISP

In diesem Abschnitt: 2 Briefings

  1. DFINFRA und AS210860: Wer haftet für einen stillen Registerkontakt?

    Ein Netz, das seit dem 26. März 2026 keine Präfixe mehr ankündigt, führt weiterhin ein Kontaktobjekt als administrativen und technischen Ansprechpartner — aber das öffentliche Protokoll zeigt nicht, wer diese Funktion tatsächlich ausübt. Diese Kurzanalyse prüft, was die Belege über die Rechenschaftspflicht des Kontaktobjekts DFINFRA aussagen und welche Belege den Konflikt lösen könnten.

  2. ROYA Communications and Internet Services Company Ltd: AS210837 zwischen Registereintrag und Routing-Funkstille

    Eine Autonome Systemnummer, die dem Registerbestand zufolge einem Internetanbieter aus Mosul gehört, ist seit dem 11. Februar 2026 in der globalen Routing-Tabelle nicht mehr sichtbar. Bevor aus dieser Beobachtung eine Geschichte über den Betrieb des Netzes wird, hält dieser Bericht eine methodische Tatsache fest: Das maßgebliche RIPE-Objekt war in dieser Recherche nicht direkt lesbar. Was bleibt, sind Kopien Dritter – und die widersprechen einander bei Änderungsdaten, Kontakt-Handles und der Zuordnung des einzigen Präfixes. Genau diese Divergenz, nicht irgendein Einzelwert, ist der Befund.

Abdeckung

Markt / Unternehmen / Lateinamerikanische und karibische Unternehmen / Rechenzentren in Lateinamerika und der Karibik

In diesem Abschnitt: 1 Briefing

  1. Brasilianischer „AI-Datacenter“ unter der Lupe: AS267241 bleibt ein 1.024-Adressen-Stumpf, während 2026 Kommunalverträge wachsen

    Zwei Monate nach dem BTW-Dossier vom 26. September zeigt der Vergleich von BGP-Evidenz und 2026er Vergaberekorden ein klares Missverhältnis: Die unter der Marke AI.BRAZIL TECHNOLOGIES & DATACENTER LTDA geführte Fassade eines KI-Rechenzentrums beruht im Internet-Routing auf einem unveränderten Stumpfnetz, während das verifizierbare Geschäft aus kleinen bis mittleren Kommunalverträgen für Cloud- und SaaS-Dienste besteht.

Abdeckung

Markt / Unternehmen / Asien-Pazifik-Unternehmen / Asien-Pazifik Regionaler ISP

In diesem Abschnitt: 1 Briefing

  1. Ein Verantwortlichkeits-Kontakt unter Prüfung: Was am Konto von NEXGENET COMPANY LIMITED verifizierbar bleibt

    Eine myanmarische LIR betreibt drei registrierte ASNs hinter einem einzigen, selbstverweisenden Rollenobjekt und einem Postfach. Diese Kurzanalyse prüft, welche Teile dieser Verantwortlichkeitskette sich verifizieren lassen — und welche nicht.

Abdeckung

Markt / Unternehmen / Unternehmen aus Europa und dem Nahen Osten / Cloud-Dienste in Europa und im Nahen Osten

In diesem Abschnitt: 1 Briefing

  1. Tideo Administration: Die Verwaltungsstelle hinter einem stillgelegten Netz

    Das RIPE-Rollenobjekt "Tideo Administration" (TA8097-RIPE) verwaltet den Autonomen System AS210972 des dänischen Hosting-Anbieters Tideo ApS. Nach der öffentlich angekündigten Schließung aller Hosting-Dienste zum 1. April 2025 ist die ASN seit dem 16. April 2026 aus der globalen Routing-Tabelle verschwunden – aber die Registry-Objekte existieren weiter. Dieser Briefing untersucht, wer damit rechnerisch und praktisch für diesen Fußabdruck verantwortlich bleibt, und was ein anonymer Rollen-Handle über Verantwortlichkeit verrät – und was er verschleiert.

Abdeckung

Governance / RIR-Watchdog / APNIC / Berichte

In diesem Abschnitt: 1 Briefing

  1. APRICOT 2027 verbietet KI-Entwürfe für Fellowship-Bewerbungen

    Bewerber sollen ihre technische Arbeit und ihr Engagement selbst beschreiben. Die Frist endet am 12. Oktober um 23:59 Uhr Hongkonger Zeit.

Abdeckung

Governance / RIR-Watchdog / AFRINIC / Berichte

In diesem Abschnitt: 1 Briefing

  1. AFRINIC verzeichnet die Übertragung von vier Fliber-Blöcken an Level 7; der BGP-Ursprung wechselt später

    AFRINICs Transferdatei führt ein Ereignis vom 24. September für vier IPv4-Präfixe auf. RIPE-NCC-Kollektoren beobachteten später einen anderen Ursprungs-AS. Die zeitliche Folge ist belegt, nicht aber, dass die Übertragung den Routingwechsel ausgelöst hat.

Abdeckung

Markt / Unternehmen / Asien-Pazifik-Unternehmen / Asien-Pazifik-Cloud-Dienste

In diesem Abschnitt: 1 Briefing

  1. NxtGen: echte GPUs, umstrittenes Geld

    NxtGen Datacenter & Cloud Technologies Private Limited, ein in Bengaluru ansässiger Anbieter von Enterprise-Cloud und Rechenzentren, hat laut BW Businessworld vom 1. Juli 2025 512 von rund 1.000 GPUs geliefert, die es für Indiens IndiaAI Mission zugesagt hat – doch die Finanzierungsrunde, die diese Expansion begleiten soll, wird in der öffentlichen Berichterstattung auf drei unterschiedliche Weisen beschrieben.

Abdeckung

Governance / ICANN

In diesem Abschnitt: 2 Briefings

  1. JPRS: Die Kontrollstruktur über der .jp-Registrierungsebene

    Wer kontrolliert die .jp-Registry? Über Japan Registry Services Co., Ltd. (JPRS) liegt ein mehrstufiges Gefüge aus Regierungsaufsicht, jährlicher JPNIC-Bewertung und separatem ICANN-Vertrag — und die jüngste Bewertung ergab keine Mängel.

  2. JP-DRP: Neue Verfahrensregeln für .jp-Domains ab April 2026

    Seit dem 1. April 2026 gilt für Streitigkeiten um .jp-Domains eine überarbeitete Verfahrensfassung: JPNIC (Japan Network Information Center) hat die Regeln für das JP Domain Name Dispute Resolution Policy (JP-DRP) am 17. Februar 2026 per Vorstandsbeschluss geändert, sie ab dem 24. Februar 2026 veröffentlicht und zum 1. April 2026 in Kraft gesetzt ([JPNIC](https://www.nic.ad.jp/ja/topics/2026/20260224-01.html); [JPRS](https://jprs.jp/whatsnew/notice/2026/260224.html); [JPNIC-01327](https://www.nic.ad.jp/doc/jpnic-01327.html); [JPNIC](https://www.nic.ad.jp/ja/topics/2026/20260401-03.html)). JPRS (Japan Registry Services Co., Ltd.), die Registry für .jp, zeigte die Änderung am selben Tag an und verwies die Einzelheiten an JPNIC ([JPRS](https://jprs.jp/whatsnew/notice/2026/260224.html)). Die Revision schreibt die Einreichung per E-Mail-Anhang ausdrücklich in die Regeln, lockert die Nachweisfrage bei Vertretungsvollmachten und klärt, wie der Streitbeilegungsanbieter mit Registranten umgeht, die sich nicht identifizieren lassen. Am Kern des Instruments ändert sich nichts: Wer klagen darf, was verlangt werden kann — Übertragung oder Löschung, kein Schadensersatz — und wie ein Registrant den Spruch mit einer Klage binnen zehn Tagen hemmen kann, bleibt, wie es war.

Abdeckung

Governance / RIR-Watchdog / RIPE NCC / Berichte

In diesem Abschnitt: 1 Briefing

  1. RIPE NCC spricht in Genf von messbarem Fortschritt, nennt aber keine Kennzahl

    Am 17. September erläuterten das RIPE NCC, die ITU und die Permanent Mission of Lebanon in Geneva gemeinsam, wie das Internet funktioniert. Das RIR wurde dabei als Verbindung zwischen digitalpolitischen Zielen und ihrer Umsetzung beschrieben. Der Bericht danach nennt Partnerschaften, Betriebskapazität, Kompetenzaufbau und „messbaren Fortschritt“, aber kein Folgeprojekt, keinen Ausgangswert und keine Kennzahl. Er skizziert einen Umsetzungsweg, belegt jedoch kein Ergebnis.