Der Vorrang des laufenden Codes: Der notwendige Patch zur Bewahrung des ursprünglichen Internetdesigns

Die sieben vorherigen Notizen von Heng.lu in dieser Reihe sind:

Notiz 52: Wenn sich Registermacht von Verantwortung löst: Warum das gegenwärtige RIR-Koordinationsmodell in seiner derzeitigen Form nicht überleben kann
Notiz 53: Internetnummernressourcen sind kein politisches Eigentum
Notiz 56: Dichte Governance regionaler Internetregister verwandelt Einzigartigkeit in doppelte Ausbeutung
Notiz 58: Von doppelter Ausbeutung zur Umkehrung der Souveränität: Wie Nationen für 100 US-Dollar die souveräne Kontrolle an RIRs verlieren
Notiz 59: Die Armutsstrafe: Wie das RIR-Modell die Armen besteuert und dies Gleichheit nennt
Notiz 61: Verrat am laufenden Code: Wie das RIR-System den Konsens gegen die technische Gemeinschaft wandte
Notiz 62: Mandatswäsche: Von der RIR-Fantasie zur Übergangsarchitektur

Die sieben vorherigen Aufsätze waren kein Reformprogramm für die Regional Internet Registries.

Sie waren eine Autopsie.

Sie verfolgten dieselbe institutionelle Pathologie durch verschiedene Schichten: von den Folgen gelöste Verantwortung; als politisches Eigentum umbenannte Nummernressourcen; in doppelte Ausbeutung verwandelte Einzigartigkeit; umgekehrte Souveränität; im Namen der Gleichheit besteuerte Armut; ein gegen die Netze gewandter Konsens, denen er dienen sollte; und schließlich ein so lange gewaschenes Mandat, bis ein Verwaltungsbeamter wie ein Souverän zu klingen begann. Die Reihenfolge ist wichtig, weil das Scheitern weder ein schlechter Vorstand, ein schlechtes Register, ein Gerichtsverfahren noch ein unbequemes Marktereignis war. Es war ein systemischer Defekt, der unter verschiedenen Verkleidungen sichtbar wurde. Die Autorenseite von CircleID zeigt diese Abfolge inzwischen deutlich, einschließlich Running-Code Betrayal und Mandate Laundering. (circleid.com)

Dieser Aufsatz soll die RIR nicht zu besseren Regierenden machen.

Er soll erklären, warum die gegenwärtige Registerordnung kein Endpunkt sein kann und warum die am wenigsten störende Reparatur ein Zusatz zum ursprünglichen technischen Design des Internets ist.

Dieser Zusatz ist der Vorrang des laufenden Codes (Running-Code Primacy).

Seine Notwendigkeit ist nicht mehr theoretisch. In einem jüngsten Austausch auf CircleID legte John Curran die stärkste Form des Arguments der Amtsinhaber vor. Seine These lautet, dass die Autorität des RIR-Systems nicht bloß ein Nebenprodukt begrenzter technischer Koordination ist, sondern das Ergebnis einer historischen Kette: White Paper, ICANN, ASO, ICP-2, der Übergang der IANA-Aufsicht und die fortdauernde multilaterale Governance des privaten Sektors. Er behauptet, die Autorität des RIR-Systems sei das Ergebnis seiner Tätigkeit innerhalb des multilateralen Modells des privaten Sektors, das die US-Regierung vorangetrieben habe. (circleid.com)

Dieses Argument ist nützlich, weil es den Streit sichtbar macht.

Die Frage ist nicht mehr, ob es eine historische Delegation gab. Natürlich gab es sie. Die Frage ist, ob sich eine historisch delegierte Koordinationsfunktion durch dieselbe von ihr kontrollierte Verfahrensmaschinerie zu einem dauerhaften Governance-Mandat ausweiten kann. Die Antwort der Amtsinhaber lautet ja: Delegation, Anerkennung, institutionelle Kontinuität und Gemeinschaftsverfahren werden zu einem sich selbst erneuernden Mandat.

Die Antwort, die das ursprüngliche technische Design des Internets verlangt, lautet nein.

Die ursprüngliche Internettradition war enger, härter und besser. RFC 3935 erklärt, das Ziel der IETF sei es, „das Internet besser funktionieren zu lassen“; sie stützt ihre Arbeit auf technische Kompetenz, Umsetzung in der realen Welt und „rough consensus and running code“. Sie stellt außerdem fest, dass die IETF, wenn sie nicht für ein Protokoll oder eine Funktion verantwortlich ist, nicht versucht, darüber Kontrolle auszuüben. (rfc-editor.org) RFC 7282 wiederholt David Clarks alten Satz: „We reject: kings, presidents and voting“ und „We believe in: rough consensus and running code“. (rfc-editor.org) RFC 9592 macht den antisouveränen Punkt noch deutlicher: Die IETF führt, kontrolliert oder überwacht das Internet nicht und ist nicht „die Polizei der Protokolle“. (rfc-editor.org)

Diese Tradition bedeutete nie, dass Dokumente magisch wären. Sie bedeutete, dass Dokumente zählten, wenn sie halfen, Systeme funktionsfähig zu machen. Sie bedeutete, dass Verfahren geduldet wurden, weil sie der Bereitstellung dienten. Sie bedeutete, dass ein Raum nur dann nützlich war, wenn sich die Beteiligten diszipliniert an der operativen Realität orientierten.

Die Registerschicht lieh sich diese Legitimität.

Sie akzeptierte diese Disziplin nie vollständig.

Das ist der fehlende Patch.

Was der Vorrang des laufenden Codes bedeutet.

Der Vorrang des laufenden Codes bedeutet, dass Internetkoordinationssysteme strikt ausgelegt werden müssen, ausgehend von der minimalen technischen Funktion, die die Existenz laufender Netze ursprünglich rechtfertigte.

Die Schicht der Nummernressourcen existiert, um laufende Systeme zu schützen: Einzigartigkeit, Interoperabilität, routingbezogene Kontinuität, Sicherheitsbehauptungen, Kontrollnachweis und die minimale gemeinsame Semantik, die unabhängige Netze zur Zusammenarbeit benötigen.

Sie existiert nicht, um politische Autorität zu erzeugen.

Sie existiert nicht, um die kommerzielle Moral zu überwachen.

Sie existiert nicht, um die Geografie eines Dienstes in einen Eigentumstitel zu verwandeln.

Sie existiert nicht, um eine Mailingliste in eine Legislative zu verwandeln.

Sie existiert nicht, damit ein privates Register bereits aktive Netzressourcen verschwinden lassen kann, weil es sein internes Verständnis der Richtlinien geändert hat.

Ein Register ist kein Staat.

Ein Datenbankkontakt ist keine notarielle Unternehmensvollmacht.

Eine Dienstregion ist kein Volk.

Ein Policy-Raum ist keine Legislative.

Ein Register kann die operative Realität beschreiben. Es erschafft sie nicht.

Das ist kein Konservatismus. Der Vorrang des laufenden Codes sagt nicht, dass eingesetzte Systeme sich niemals ändern dürfen. Er sagt, dass institutionelle Macht über Veränderungen nicht durch historische Delegation, zirkuläre Anerkennung oder rituelle Verfahren gerechtfertigt werden darf. Sie muss durch deterministische Regeln gerechtfertigt werden, die Betreiber lokal prüfen können, sowie durch Übernahme in laufenden Systemen.

Die richtige Reihenfolge lautet: ursprüngliche Spezifikation, Zustand des verteilten Ledgers, lokale Validierung, laufende Implementierung, freiwillige Übernahme, Kompatibilitätsmenge und erst danach Dokumentation.

Die falsche Reihenfolge lautet: Policy-Raum, Erklärung, behauptete Verpflichtung, Compliance-Kennzeichnung und erzwungene Einhaltung im Betrieb.

Das RIR-System scheiterte, weil es zunehmend die zweite Reihenfolge wählte.

Die entscheidende Korrektur lautet: Nach der ursprünglichen Spezifikation gibt es keine dauerhafte Institution, die man um Erlaubnis bitten könnte. Kein Komitee entscheidet, ob Nichtübernahme einen Verstoß darstellt. Kein Register erklärt einen Teilnehmer für ungültig, nur weil er sich weigert, eine spätere Änderung zu akzeptieren. Es gibt nur Code, Ledger-Zustand, Validierung, Übernahme, Kompatibilität, lokale Ablehnung, Forking und selektive Interoperabilität.

Ein Betreiber, der eine spätere Änderung ablehnt, zerstört das Internet nicht. Er kann in einer älteren Kompatibilitätsmenge bleiben. Er kann forken. Er kann die Verbindung trennen. Er kann aufhören, mit Teilnehmern zu interoperieren, die inkompatible Regeln übernommen haben. Er kann jedoch nicht die Interoperabilität anderer zerstören, die weiterhin gegenseitig kompatiblen Code ausführen.

Die Designintuition ist dieselbe, die verteilte Ledger nützlich macht: Für die gewöhnliche Gültigkeit braucht man keine dauerhafte Institution, die entscheidet. Die Teilnehmer validieren Zustandsübergänge lokal anhand deterministischer Regeln. Ein ungültiger Zustand wird nicht von einer Institution bestraft. Er wird von den Teilnehmern ignoriert, die ihn nicht akzeptieren.

Das ist der wesentliche fehlende Patch in der Koordination von Nummernressourcen.

Der Designfehler war von Anfang an vorhanden.

Die erste Architektur der RIR ging von einer Welt mit geringem Wert aus.

Nummernressourcen wirkten technisch, reichlich vorhanden, administrativ und konfliktarm. In dieser Welt erschien Informalität effizient. Offene Mailinglisten wirkten repräsentativ. Kontaktbasierte Verwaltung schien ausreichend. Verträge mit begrenzter Haftung schienen harmlos. Ein regionales Register konnte wie ein einfaches Adressbuch erscheinen.

Die Knappheit von IPv4 zerstörte diese Annahme.

IPv4-Adressen wurden knapp, übertragbar, finanzierbar, vermietbar, kapitalisierbar, Gegenstand von Rechtsstreitigkeiten und Sanktionen und in aktive Netze integriert. Die Registerschicht stand nicht mehr über administrativen Einträgen. Sie stand über produktiver Infrastruktur. Sie stand über dem Wert von Vermögenswerten. Sie stand über Kundenkontinuität, Cloud-Bereitstellung, Telekommunikationsbetrieb, nationaler Konnektivität, gerichtlichen Anordnungen und Kapitalallokation.

Die institutionelle Form wurde nicht an dieses neue Risiko angepasst.

Sie weitete sich aus.

Das Ergebnis ist ein System, das weiterhin die Sprache technischer Koordination spricht, während es die Wirkungen von Infrastruktur-Governance ausübt. Es verlangt von Betreibern, das Registerverfahren als neutral zu behandeln, während Registerentscheidungen das kommerzielle Schicksal beeinflussen. Es nennt seine Teilnehmer „Gemeinschaft“, obwohl viele derjenigen, die die Folgen tragen, den Personen im Raum nie eine klare rechtliche Vertretungsmacht erteilt haben.

NRS legt das strukturelle Problem klar offen: Internetnummernregister wurden als Einrichtungen technischer Koordination entworfen, doch sobald die IPv4-Knappheit Adressen in wertvolle Vermögenswerte verwandelte, wurde der Ermessensspielraum des Registers zu wirtschaftlicher Macht; wenn Koordinationssysteme Kapital kontrollieren, wird Zentralisierung zu einem strukturellen Risiko und Dezentralisierung zu einer Frage der Systemtechnik statt der Ideologie. NRS beschreibt auch die entgegengesetzte Designrichtung: ein einziges Internet, offene und autonome Infrastruktur sowie dezentralisierte Governance mit minimaler menschlicher Beteiligung als Kern. (nrs.help)

Das ist das eigentliche Problem. Die Registerschicht wurde nie für den Moment angepasst, in dem eine Koordinationstabelle zu einem Zugangstor für Vermögenswerte wurde.

Der Vorrang des laufenden Codes ist diese Anpassung.

Es ist keine Lehre vom „besseren RIR“.

Es ist eine Post-RIR-Disziplin.

Die drei Regeln des Patches

Die konstruktive Grammatik ist die überarbeitete Notiz 64: Minimale Anfangsspezifikation, lokalisierte zukünftige Entscheidung und freiwillige Übernahme für Internetkoordinationssysteme: Minimale Anfangsspezifikation, lokalisierte zukünftige Entscheidung und freiwillige Übernahme.

Die Namen bleiben unverändert. Die Logik muss präzise sein.

Minimale Anfangsspezifikation bedeutet, dass die gemeinsame Schicht nur deterministische und lokal überprüfbare Regeln enthält, die für Einzigartigkeit, Interoperabilität, Kontrollnachweis, gemeinsame Sicherheit und Sicherheitsbehauptungen erforderlich sind. Sie enthält keine Präferenzen für Geschäftsmodelle, Preistheorien, regionale politische Empfindlichkeiten, Ermessensvollmachten zur Durchsetzung oder eine Ausweitung institutioneller Aufgaben.

Lokalisierte zukünftige Entscheidung bedeutet nicht, dass eine Institution entscheidet, welche künftigen Entscheidungen lokal sind. Das würde die Autoritätsschicht bereits wieder einführen. Es bedeutet, dass die ursprüngliche Spezifikation die Begrenzungsarbeit im Voraus leistet. Nach der Bereitstellung bleiben gewöhnliche künftige Entscheidungen bei den Teilnehmern, die den Code ausführen. Ein Teilnehmer kann übernehmen, ablehnen, forken, die Verbindung trennen oder selektiv interoperieren. Kein Teilnehmer kann die Interoperabilität anderer verändern, die weiterhin gegenseitig kompatible Regeln ausführen.

Freiwillige Übernahme bedeutet, dass eine spätere Änderung nur durch Implementierung, Validierung, Bereitstellung und Nutzung real wird. Veröffentlichung ist keine Realität. Empfehlung ist keine Realität. Institutionelle Anerkennung ist keine Realität. Nichtübernahme erzeugt keinen ungültigen Zustand. Ein Teilnehmer, der eine spätere Änderung nicht übernimmt, bleibt in seiner bestehenden Kompatibilitätsmenge. Ein Teilnehmer, der nach den deterministischen Regeln eines anderen ungültige Zustände ausgibt, kann lokal ignoriert werden. Die Wirkung ist Kompatibilitätsauswahl, nicht institutionelle Bestrafung.

Diese drei Regeln rehabilitieren die Souveränität des Registers nicht.

Sie verhindern, dass sie unter einem anderen Namen wiederkehrt.

APNIC: Die rechtliche Struktur war das Risiko

APNIC zeigt den ersten Fehler: Das Minimum wurde von Anfang an nicht streng genug spezifiziert.

Dies ist keine Geschichte über Verhaltenskodizes. Keine Geschichte über Etikette. Keine Geschichte darüber, ob ein Kritiker höflich genug zu einer etablierten Institution war.

Es ist eine Geschichte über rechtliche Struktur.

Im März 2023 veröffentlichte LARUS eine rechtliche Prüfung, die warnte, dass die Governance-Struktur von APNIC Risiken nicht nur für ein Unternehmen in Brisbane, sondern für die Internet-Governance in der gesamten Asien-Pazifik-Region schaffe. Die Prüfung erklärte, der Generaldirektor von APNIC habe die letztendliche rechtliche Macht, APNIC zu schließen und den gewählten Vorstand abzusetzen, und dringende Governance-Reformen seien nötig. Sie wies außerdem darauf hin, dass die Struktur Fragen zur Sicherheit der Internet-Governance für mehr als eine Milliarde Nutzer in der Asien-Pazifik-Region aufwerfe. (larus.net)

Der erste Anhang, der ASIC-Auszug, liefert die gesellschaftsrechtliche Grundlage. APNIC Pty Ltd war als australische private Gesellschaft mit beschränkter Haftung durch Aktien registriert, eingetragen in Queensland. Paul Byron Wilson war als Direktor und Sekretär aufgeführt. Die Aktieninformationen zeigten eine einzige ausgegebene Stammaktie und Paul Byron Wilson als alleinigen Inhaber dieser Aktie. (larus.net)

Das ist keine normale Form, um eine kritische regionale Internetkoordinationsfunktion unterzubringen.

Der zweite Anhang, das Rechtsgutachten von Dr. Peter Felter, zieht die Governance-Schlussfolgerung. Es beschreibt die öffentliche Struktur von APNIC — Mitglieder, Wahlen, Exekutivrat, Generaldirektor und Sekretariat — als ein Sonderkomitee nach Artikel 9.3 der Satzung von APNIC Pty Ltd. Es erklärt, dass APNIC Pty Ltd seit 25 Jahren ein privates Unternehmen ist, das durch einen Direktor, einen Aktionär und einen Sekretär kontrolliert wird, die alle dieselbe Person sind. (larus.net)

Diese Unterscheidung ist wichtig.

Die öffentliche und gemeinschaftsorientierte Institution war nicht die letztliche juristische Trägerstruktur. Sie war eine Struktur, die auf einem privaten Unternehmen aufgebaut wurde.

Das Rechtsgutachten erklärt anschließend, warum diese Unterscheidung wichtig ist. Es hält fest, dass die Satzung von APNIC den Gesellschaftsstatuten sowie den Befugnissen der Gesellschaft, ihrer Direktoren, Funktionsträger und Mitglieder unterliegt. Nach dieser Auslegung könnte die öffentliche Struktur von APNIC durch Beschluss des Direktors von APNIC Pty Ltd geändert werden; das Gutachten beschreibt APNIC faktisch als Abteilung von APNIC Pty Ltd. (larus.net)

Der schwerwiegendste Punkt des Gutachtens war nicht, dass APNIC technisch illegal sei. Der entscheidende Punkt war, dass Legalität und Legitimität nicht dasselbe sind. Das Gutachten argumentiert, der Treuhandmechanismus löse das Problem nicht, weil die Befugnisse des Exekutivrates weiterhin aus dem Beschluss des Direktors abgeleitet würden, der das Sonderkomitee einrichtet. Es weist auch darauf hin, dass APNIC Pty Ltd ein privates Unternehmen mit Aktien ist, dessen Struktur und Zweck nicht dem Modell einer gemeinnützigen Organisation ohne Aktien entsprechen, das man normalerweise mit einem regionalen Register von öffentlichem Interesse verbinden würde. (larus.net)

Das ist der erste Designfehler in seiner reinsten Form.

Ein regionales Koordinationssystem für Nummern sollte nicht von einer Struktur abhängen, für deren Erklärung Juristen erforderlich sind: ein privates Unternehmen mit einer einzigen Aktie, ein Sonderkomitee, ein Treuhandverhältnis und ein gewählter Rat sollen sich irgendwie zu legitimer Kontrolle über das Internetregister der Asien-Pazifik-Region verbinden.

Eine kritische Koordinationsschicht sollte von außen lesbar sein.

Sie sollte kein Vertrauen in Dokumente hinter Dokumenten erfordern.

Sie sollte nicht verlangen, dass Mitglieder nach Jahren institutioneller Abhängigkeit entdecken, dass die gewählte Schicht möglicherweise nicht die endgültige rechtliche Schicht ist.

Sie sollte nicht den Anschein einer Mitglieder-Governance erwecken, während die formale Macht anderswo liegt.

Darum muss die Minimale Anfangsspezifikation verteilte Gültigkeit statt institutionellen Vertrauens enthalten. Nicht, weil eine künftige Institution bessere Governance benötigte, sondern weil ein künftiges Post-RIR-System diese Institution überhaupt nicht benötigen darf.

Die gemeinsame Schicht sollte nicht von der verborgenen Kontrollstruktur eines privaten Unternehmens abhängen. Sie sollte deterministische Regeln für Validierung, Zustände des Kontrollnachweises, Zustandsübergänge, Konfliktregeln, Ledger-Replikation, Ausstiegspfade, Fork-Pfade und Kompatibilitätsmengen definieren. Wenn APNIC verschwindet, sich selbst vereinnahmt, seine rechtliche Haltung ändert oder einen gültigen Zustand nicht anerkennt, sollte das laufende Netz nicht von der Anerkennung durch APNIC abhängen, um zu wissen, wer welche Nummernressourcen kontrolliert.

Das Register sollte nicht die Quelle der Gültigkeit sein.

Diese Quelle sollte der Zustand des verteilten Ledgers sein, validiert nach der ursprünglichen Spezifikation.

ARIN: Politik trifft auf die Realität von Vermögenswerten

ARIN zeigt den zweiten Fehler: Die rechtliche und marktbezogene Realität kann der Registertheorie voraus sein.

Das entscheidende Ereignis war die Nortel/Microsoft-Transaktion. Als Nortel Insolvenz anmeldete, wurden seine 666.624 IPv4-Adressen zu wertvollen Vermögenswerten im Verfahren. Die Adressen wurden für 7,5 Millionen US-Dollar an Microsoft verkauft. ARIN griff unter der Annahme ein, dass Adressen kein Eigentum seien und nicht außerhalb der Registerpolitik verkauft werden könnten. Industry Canada unterstützte diese Position. Das Insolvenzgericht wies sie zurück; Microsoft unterzeichnete später eine „legacy“-Vereinbarung; und das praktische Ergebnis war eindeutig: Die Registerpolitik konnte nicht länger die einzige Quelle der Realität sein, sobald Gerichte und Märkte Nummernressourcen als Vermögenswerte behandelten. (btw.media)

Die wichtige Lehre ist nicht, dass ARIN besonders fehlerhaft war.

Die Lehre ist, dass die Registerschicht in eine neue Kategorie eingetreten war.

Ein Register ist wertvoll, weil Betreiber, Gerichte, Käufer, Verkäufer, Gläubiger und Netze ihm vertrauen. Es wird nicht dadurch autoritativ, dass es diese Abhängigkeit leugnet. Es bleibt nur dann nützlich, wenn es die rechtliche, marktliche und operative Realität hinreichend genau widerspiegelt.

Als IPv4 knapp wurde, wurde das Registerverfahren zu einer Marktschnittstelle. Übertragungsregeln, Bedarfsermittlungen, Verzögerungen bei der Anerkennung und regionale Beschränkungen waren keine Verwaltungsdetails mehr. Sie wurden zu Reibungen für Vermögenswerte. Die öffentliche Analyse beschreibt heute ein fragmentiertes Regelwerk der RIR, in dem fünf regionale Systeme einen Markt steuern, auf dem Adressen für etwa 18 bis 45 Dollar pro Stück gehandelt werden, wobei widersprüchliche Regeln Vermögenswerte blockieren, Fusionen verzögern und getrennte Unternehmensstrukturen erzwingen können, nur um Adressblöcke halten zu können. (btw.media)

Das ist keine neutrale Koordination.

Es ist eine regulatorische Wirkung ohne regulatorische Verantwortung.

ARIN zeigt, warum freiwillige Übernahme wichtig ist. Die Registerpolitik bleibt nur glaubwürdig, solange sie beschreibt, was Akteure tatsächlich implementieren, handeln, finanzieren, einklagen und nutzen. Sie wird gefährlich, wenn Veröffentlichung als ausreichend betrachtet wird, um Realität zu erzeugen.

Ein Register, das sich der Realität verweigert, wird nicht souverän.

Es wird zu einer veralteten Datenbank.

In einem Design des Vorrangs des laufenden Codes ist die Lehre noch klarer. Gerichte und Märkte brauchen kein etabliertes Register, um zu entscheiden, ob Wert existiert. Betreiber brauchen kein Komitee, um zu wissen, ob ein Block geroutet wird. Teilnehmer brauchen deterministische Regeln für Kontrollnachweis, Konfliktlösung, sichtbare Zustandsübergänge in einem Ledger und Kompatibilität. Das alte Register kann eine Ansicht veröffentlichen. Ein Softwareclient kann eine Ansicht anzeigen. Ein Ledger-Explorer kann eine Ansicht anzeigen. Keiner davon ist die Quelle der Gültigkeit.

Es gibt kein Register, zu dem man migrieren könnte.

Es gibt kein Register, das man fragen könnte.

Es gibt nur einen verteilten Zustand, den Teilnehmer validieren, akzeptieren, ablehnen, forken oder mit dem sie interoperieren.

AFRINIC: Als die Registertheorie aktive Vermögenswerte bedrohte

AFRINIC ist der zentrale Fall, weil er das Problem auf seinen Kern reduzierte.

Die falsche Geschichte lautet, dass ein problematisches Mitglied ein regionales Register lahmlegte.

Das ist die moralische Erzählung des Amtsinhabers.

Die strukturelle Geschichte ist anders. AFRINIC versuchte, aus kommerzieller Nutzung, Kundengeografie, Vermietung, Mitgliederbeziehungen und interner Politikinterpretation eine ausdrückliche Befugnis zur Deregistrierung bereits laufender Nummernressourcen abzuleiten. Sobald diese Behauptung aufgestellt war, konnte der Konflikt kein Streit in einem Policy-Raum bleiben. Er wurde zu einem Test, ob ein privates Register regionale Rhetorik und normative Stille nutzen konnte, um operativ integrierte Vermögenswerte zu bedrohen.

Die Tatsachen erfordern keine theatralische Übertreibung. Öffentliche Berichte beschrieben den AFRINIC-Streit als einfachen kommerziellen Konflikt über IP-Adressen, der zur größten Geschichte der Internet-Governance in Afrika wurde. Sie wiesen auch darauf hin, dass Cloud Innovation oft als Bösewicht dargestellt worden war, während spätere Dokumente auf zerstörerische Kräfte innerhalb von AFRINIC selbst sowie auf verzögerte, verlängerte und von AFRINIC-Vertretern auf Kosten von AFRINIC fortgeführte Rechtsstreitigkeiten hindeuteten. (btw.media)

Das ist wichtig, weil es die übliche Erzählung umkehrt.

Der Rechtsstreit hat den strukturellen Fehler nicht geschaffen.

Er hat ihn offengelegt.

Der relevante Fehler war bereits vorhanden, als ein privates Register das Fehlen einer ausdrücklichen Erlaubnis als Grundlage für Zwangskontrolle behandelte. Vermietung war keine Bedrohung der Einzigartigkeit. Kundengeografie war keine Doppelzuweisung. Kommerzielle Nutzung war kein Fehler der Routing-Sicherheit. Ein von einem Register missbilligtes Geschäftsmodell war keine globale Invariante.

Dennoch stellte die Registerauslegung diese Elemente in einen Widerrufsrahmen.

Das ist der Moment, in dem Koordination zu Governance wird.

Berichte halten fest, dass AFRINIC Cloud Innovation im März 2021 einen Brief schickte, in dem es Verstöße gegen Richtlinien behauptete und mit der Beendigung der Mitgliedschaft drohte; dass der Oberste Gerichtshof von Mauritius AFRINIC im Juli 2021 untersagte, die Mitgliedschaft von Cloud Innovation zu kündigen; und dass ein erneuter Kündigungsversuch im Dezember 2021 blockiert wurde. (btw.media) Diese Abfolge ist nicht die Geschichte eines Registers, das das Internet ruhig schützt. Es ist die Geschichte der Registerautorität, die auf gewöhnliches Recht trifft.

Der institutionelle Zusammenbruch wurde auch nicht durch zu viel Registermacht verursacht. Das tiefere Problem war die strukturelle Blockade. Wenn ein Register ein Anerkennungsmonopol über lebende Vermögenswerte mit hohem Wert besitzt, wird jeder interne Fehler zu einem Risiko für die Kontinuität des Internets. Wenn Mitglieder das Anerkennungssystem nicht verlassen können, wird der Registerfehler zu Geiselmacht.

Ein Register kann nachweisbaren Registrierungsbetrug in seinen eigenen Daten korrigieren.

Es kann Doppelzuweisungen verhindern, solange das Registermodell besteht.

Es kann Sicherheitsbehauptungen aufrechterhalten, solange Teilnehmer von ihm abhängen.

Doch dies sind Übergangsfunktionen einer alten Architektur.

In einer Post-RIR-Architektur werden diese Funktionen nicht von einem Register ausgeübt. Sie werden in den Zustand eines verteilten Ledgers, in Kontrollnachweisregeln, Konfliktregeln und lokal überprüfbare Übergänge codiert.

Eine private Organisation sollte Vermietung nicht in regionalen Verrat verwandeln.

Sie sollte Kundengeografie nicht zu einem Widerrufsauslöser machen.

Sie sollte kommerziellen Dissens nicht als technische Ungültigkeit behandeln.

Sie sollte die Kontinuität von Vermögenswerten nicht in eine Erlaubnisfrage verwandeln.

AFRINIC zeigt die Notwendigkeit einer richtig verstandenen lokalisierten zukünftigen Entscheidung. Es gibt kein zentrales Organ, das entscheidet, dass eine künftige kommerzielle Entscheidung „lokal“ ist. Vielmehr muss die ursprüngliche Spezifikation sicherstellen, dass solche Entscheidungen überhaupt nicht in die gemeinsame Schicht gelangen. Vermietung, Kundengeografie, kommerzielle Nutzung, Preisgestaltung, Finanzierung, Kundenmix und Bereitstellungsstrategie bleiben außerhalb der deterministischen Gültigkeitsregeln, sofern sie nicht direkt Einzigartigkeit, Sicherheit, Kontrollnachweis oder Interoperabilität betreffen.

Ein Betreiber kann die Interoperabilität anderer Betreiber nicht dadurch zerstören, dass er Adressen vermietet.

Er kann sie nicht dadurch zerstören, dass er Kunden außerhalb einer historischen Registerregion bedient.

Er kann sie nicht durch ein Geschäftsmodell zerstören, das das Register missbilligt.

In jedem Fall kann ein Betreiber deterministische Regeln verletzen, die andere Teilnehmer ausführen. Dann lehnen die anderen den ungültigen Zustand lokal ab. Es gibt keine Bestrafungsschicht. Kein Compliance-Gericht. Keinen regionalen Souverän.

Diese Linie ist nicht ideologisch.

Sie ist operativ.

Das Proxy-Problem ist kein Detail

Die Wahlkontroverse bei AFRINIC machte einen zweiten Fehler sichtbar: die Vertretung.

NRS legt seine Vertretungsgrundlage in direkten rechtlichen Begriffen dar. Es erklärt, dass die aufgeführten Mitglieder NRS mit der Vertretung in Angelegenheiten der RIR-Governance betraut hätten und dass jedes aufgeführte Mitglied eine notarielle Vollmacht (power of attorney) erteilt habe. (nrs.help) Während des AFRINIC-Wahlstreits bat NRS die Mitglieder mitzuteilen, ob ihre Namen in den Abstimmungsunterlagen erschienen oder ob ihre Stimmen ohne ihre Beteiligung erfasst worden seien, und wies darauf hin, dass solche Tatsachenberichte auf rechtlichem Weg behandelt würden. (nrs.help)

Das ist wichtig, weil es den Unterschied zwischen rechtlicher Vertretung und Gemeinschaftsrhetorik zeigt.

Das RIR-System vermischt häufig mehrere Kategorien: Unternehmensvertreter, Datenbankkontakt, technischer Kontakt, Angestellter, Berater, Inhaber einer Vollmacht, Policy-Teilnehmer, regelmäßiger Mailinglisten-Nutzer. Sie sind nicht dasselbe.

Ein Datenbankkontakt kann bei der Verwaltung von Datensätzen helfen.

Eine notarielle Vollmacht kann zur Vertretung berechtigen, wenn sie gültig ist und die Vertretung von ihrem Umfang gedeckt ist.

Ein Policy-Teilnehmer kann Fachwissen beitragen.

Ein Mailinglisten-Teilnehmer kann eine Meinung äußern.

Keines dieser Elemente wird automatisch zum rechtlichen Auftraggeber für alle Unternehmen, Kunden, Staaten, Gläubiger, Kreditgeber, Käufer, Mieter oder Netze, die die Folgen einer Registerentscheidung tragen.

Diese Unterscheidung kann nur ignoriert werden, solange die gemeinsame Schicht dünn bleibt. Sobald das Register Macht über Widerruf, Übertragung, Vermietung, Marktzugang, Sanktionen, Vermögenskontinuität oder nationale Infrastruktur-Risiken beansprucht, wird Vertretung konstitutionell.

Ein Raum ist kein Mandat.

Eine Mailingliste ist kein Volk.

Ein Kontaktregister ist keine notarielle Unternehmensvollmacht.

Eine Dienstregion ist kein souveräner Wahlkreis.

Das ist keine Frage prozeduraler Strenge.

Es ist der Unterschied zwischen Koordination und normativer Autorität.

Ein System des Vorrangs des laufenden Codes vermeidet dieses Problem, indem es die Zahl der Entscheidungen reduziert, die überhaupt Vertretung erfordern. Wenn Gültigkeit deterministisch und lokal ist, gibt es weniger Dinge, über die abgestimmt werden muss. Wenn künftige Änderungen freiwillig sind, muss nicht entschieden werden, ob ein Nichtübernehmer in einer schlechten Position ist. Wenn der Zustand in einem verteilten Ledger dargestellt wird, muss ein Teilnehmer kein etabliertes Register bitten, seine fortbestehende Existenz anzuerkennen. Wenn Kompatibilitätsmengen explizit ausgewiesen sind, wissen Teilnehmer, mit wem sie interoperieren können, ohne einen Policy-Raum zu befragen.

Das beste Governance-Problem ist dasjenige, das das Systemdesign beseitigt.

RIPE NCC und LACNIC: der Club und der Engpass

RIPE NCC und LACNIC zeigen nicht, dass einige RIR „zivilisierter“ seien als andere. Sie zeigen, dass das RIR-Modell jenseits der technischen Funktion zwei Durchsetzungsschichten besitzt: den Club und den Engpass.

Der Club entscheidet, wer respektabel ist. Der Engpass entscheidet über die Bewegung des Registerstatus.

Die Weigerung von RIPE NCC, das Sponsoring von LARUS für RIPE 90 anzunehmen, zeigte die Clubschicht deutlich. Ein Mitglied bot Sponsoring an. Das Registerökosystem lehnte es wegen eines nicht zusammenhängenden Streits in einer anderen Region ab. Das war keine Entscheidung über Routing-Sicherheit. Keine Entscheidung über Einzigartigkeit. Keine deterministische Validierungsregel. Es war eine Form privater Ausgrenzung durch Kontrolle des Zugangs zu Räumen, Sichtbarkeit, Sponsoring und sozialer Legitimität.

Auch LACNIC lehnte das Sponsoring ab. Andere Region, dasselbe Muster: Der Registerclub schützt sich, indem er Räume, Sichtbarkeit und Reputation kontrolliert.

Das ist keine Gemeinschaft. Es ist Zugangskontrolle.

Die Sanktionsschicht ist schwerwiegender, weil sie den Engpass in rechtlicher Form zeigt. RIPE NCC erklärt, dass es als niederländische Organisation EU-Sanktionen einhalten muss; wenn diese greifen, friert es Datensätze in der RIPE-Datenbank ein, blockiert Erwerbe und Übertragungen und kann Fälle als eingefroren behandeln, wenn eine Partei keine ausreichende Dokumentation vorlegen kann. Aufgrund von Bankanforderungen führt es außerdem Prüfungen gegen OFAC-Listen durch. (RIPE-NCC-Sanktionstransparenz)

Das ist keine Kritik an RIPE NCC, weil es das Gesetz einhält. Eine niederländische Organisation muss niederländisches und EU-Recht befolgen. Das Problem ist architektonisch: Warum sollte eine private Organisation in den Niederlanden der zentrale Anerkennungspunkt für die Mobilität von Nummernressourcen zwischen mehreren Ländern, Betreibern und Rechtssystemen sein?

Sanktionen können eine Bank binden. Sie können eine niederländische Organisation binden. Sie können eine Gegenpartei binden, die sich gegen Handel entscheidet. Sie sollten jedoch nicht zu einer globalen Bedingung technischer Gültigkeit für alle anderen werden.

Das ist der Designfehler.

Dieselbe Zentralität, die dem Club ermöglicht, einen Kritiker auszuschließen, ermöglicht es auch einer Gerichtsbarkeit, die Mobilität des Registers einzufrieren. Das eine ist soziale Durchsetzung. Das andere ist rechtliche Durchsetzung. Beide funktionieren nur, weil das Register eine Position einnimmt, an der Gültigkeit nicht liegen sollte.

Das steht direkt mit den drei Prinzipien in Verbindung.

Minimale Anfangsspezifikation: Die Respektabilität des Clubs, Sponsoring-Eignung, regionale Politik, Sanktionsklassifikation und Reputation dürfen niemals in die gemeinsame Schicht gelangen. Die gemeinsame Schicht darf nur deterministische Regeln für Einzigartigkeit, Kontrollnachweis, Konfliktlösung, Zustandsübergang und Sicherheit enthalten.

Lokalisierte zukünftige Entscheidung: Rechtliches Risiko, Wahl der Gegenpartei, Sponsoring, kommerzielles Vertrauen und Sanktionsrisiko gehören den Akteuren, die sie übernehmen. Eine niederländische Organisation kann eine Transaktion ablehnen. Eine Bank kann eine Zahlung ablehnen. Eine Gegenpartei kann die Interaktion verweigern. Nichts davon darf zur globalen Wahrheit des Registers werden.

Freiwillige Übernahme: Teilnehmer akzeptieren Gegenparteien, indem sie Code ausführen, Zustände validieren und auswählen, mit wem sie interoperieren. Nichtübernahme ist kein Fehlverhalten. Lokale Ablehnung ist keine globale Ungültigkeit. Die Ablehnung durch einen Club sollte einen gültigen Zustand nicht löschen. Eine Sanktionspflicht muss den betroffenen Akteur beschränken, nicht den globalen Ledger der Nummernressourcen umschreiben.

Darum ist eine verteilte Ledger-Architektur erforderlich. In einem Post-RIR-System wird die gewöhnliche Gültigkeit nicht von RIPE NCC, LACNIC, einem Sanktionsgremium, einem Sitzungskomitee oder einem Sponsoringbüro entschieden. Teilnehmer validieren den Zustand lokal. Gegenparteien akzeptieren oder lehnen freiwillig ab. Forks sind sichtbar. Kompatibilitätsmengen sind explizit ausgewiesen. Das zentrale Register verschwindet als Wahrheitsquelle.

Die Lösung ist keine bessere Etikette.

Sie ist keine transparentere Sanktionswarteschlange.

Die Lösung besteht darin, Gültigkeit sowohl dem Club als auch dem Engpass zu entziehen.

Verteilter Zustand. Lokale Validierung. Freiwillige Gegenparteienannahme. Kein Register als Gültigkeitsquelle.

Der NRO-Brief: der Fluchtweg nach oben

Der gravierendste Beleg ist nicht AFRINICs Überschreitungsversuch.

Es ist die kollektive Antwort des Systems.

Im Jahr 2022 schrieb die Number Resource Organization an die Regierung von Mauritius. Der Brief beschrieb die NRO als Koordinationsorgan der RIR der Welt und erklärte, dass die RIR die Nummernressourcen in ihren jeweiligen Regionen verwalten. Er stellte fest, dass die fünf Register die Funktion erfüllen, Nummernressourcen nach regional verabschiedeten Regeln oder einstimmig angenommenen globalen Richtlinien zu verwalten. (nro.net)

Der gleiche Brief kritisierte den Rechtsstreit von Cloud Innovation, erklärte, es seien mehr als 25 Klagen eingereicht worden, beklagte gerichtliche Anordnungen, die AFRINIC-Konten eingefroren und Wahlen gestoppt hätten, und behauptete, AFRINIC habe Mauritius wiederholt ersucht, als internationale Organisation anerkannt zu werden. Die NRO forderte die Regierung auf, Maßnahmen zu ergreifen, um die Unabhängigkeit von AFRINIC und die Stabilität des Internets in Afrika zu bewahren. (nro.net)

Das ist das aufschlussreichste Dokument der gesamten Geschichte.

Als ein privates Register mit ordentlichen Gerichten in Konflikt geriet, bestand der Reflex des Systems nicht darin, den Umfang des Mandats zu reduzieren.

Er bestand nicht darin, die Registerblockade zu beseitigen.

Er bestand nicht darin, Registerverwaltung von Durchsetzung zu trennen.

Er bestand nicht darin, verteilte Validierung zu definieren.

Er bestand nicht darin, zu fragen, ob die einseitige Widerrufsmacht über aktive Vermögenswerte von Anfang an illegitim gewesen war.

Der Reflex war ein Fluchtweg nach oben.

Ein privates Koordinationsorgan kann nicht technisch sein, wenn es Ermessensspielraum will, gemeinschaftlich, wenn es Legitimität will, vertraglich, wenn es Gebühren will, Nichteigentümer, wenn es Verantwortung vermeiden will, und quasi-international, wenn es Immunität vor Gerichten will.

Diese Kombination ist keine Governance.

Sie ist eine systemische Form der „Mandatswäsche“.

Wenn die RIR öffentlich-rechtliche Privilegien wollen, müssen sie öffentlich-rechtliche Verantwortung akzeptieren. Wenn sie die Flexibilität des Privatrechts wollen, müssen sie privatrechtliche Prozessführung akzeptieren. Was sie nicht kohärent zugleich verlangen können, sind privater Ermessensspielraum, öffentliche Infrastruktur-Bedeutung, geringe Verantwortung, schwache Vertretung, Monopolstatus und quasi-diplomatische Immunität.

Das ist der Weg zum Zusammenbruch.

Der Vorrang des laufenden Codes lehnt ihn ab.

Wenn ein Register auf rechtlichen Widerstand stößt, darf es nicht nach oben entkommen und Immunität suchen. Die Architektur muss sich nach unten zusammenziehen und auf die strikte Funktion des laufenden Codes zurückführen, die sie ursprünglich rechtfertigte.

Weniger Souveränität.

Kein Register als Quelle der Gültigkeit.

Weniger Durchsetzung.

Mehr verteilte Validierung.

Die Überarbeitung von ICP-2 reicht nicht aus

Das gegenwärtige System erkennt an, dass etwas zerbrochen ist.

Die öffentliche Kommentarseite von ICANN zum zweiten Entwurf des Governance-Dokuments für die RIR erklärt, der Vorschlag werde Regeln und Kriterien für die Anerkennung neuer RIR, operative Pflichten und Anforderungen an bestehende RIR sowie Regeln für die Aberkennung festlegen; bei Annahme würde er ICP-2 ersetzen. Auf derselben Seite steht, dass das Verfahren begann, nachdem die NRO die ASO ersucht hatte, Aktualisierungen vorzuschlagen, um das RIR-System gegenüber der Internetgemeinschaft rechenschaftspflichtiger zu machen. (icann.org)

Das kann als Kontinuitätsmaßnahme notwendig sein.

Als Legitimitätstheorie reicht es nicht.

Anerkennungs- und Aberkennungsregeln beantworten eine späte Frage: Wann ist ein Register so weit gescheitert, dass es entfernt werden kann?

Die frühere Frage ist wichtiger: Warum sollte ein Register überhaupt genug Macht haben, um katastrophal zu scheitern?

Ein Nachfolger von ICP-2, der lediglich Anerkennung, Prüfung, Übergang und Aberkennung verschärft, kann die institutionelle Hygiene verbessern und gleichzeitig den Kategorienfehler bewahren. Er nimmt weiterhin an, dass das RIR die primäre souveräne Form der Koordination von Nummernressourcen ist.

Der Vorrang des laufenden Codes stellt andere Fragen.

Wie funktioniert das Internet weiter, wenn ein RIR zusammenbricht?

Wie bleiben Nummernressourcenzuweisungen ohne Erlaubnis einer etablierten Stelle überprüfbar?

Wie überlebt Einzigartigkeit ohne monopolistischen Ermessensspielraum?

Wie verhindert man, dass Register zu Instrumenten der Durchsetzung durch Zwang werden?

Wie hält man kommerzielle Entscheidungen außerhalb der deterministischen Gültigkeit, außer wenn eine echte globale Invariante gefährdet ist?

Wie bleibt Koordination ohne ein autoritatives Register nutzbar?

Wie validiert ein Betreiber den gewöhnlichen Zustand, ohne eine dauerhafte Organisation zu befragen?

Wie verhindert man, dass Ablehnung zu einem Verstoßetikett wird?

Das sind keine Reformfragen.

Es sind Post-RIR-Fragen.

Warum dies der Patch des ursprünglichen Designs ist

Das Problem ist nicht, ob jemand etablierte Register mag.

Das Problem ist, ob die Schicht der Nummernressourcen weiterhin der Design­disziplin folgt, die das Internet möglich machte: minimale gemeinsame Regeln, lokale Validierung, freiwillige Übernahme und laufender Code.

Der Vorrang des laufenden Codes ist keine PR-Strategie und kein institutioneller Kompromiss. Er ist die im ursprünglichen Design enthaltene technische Reparatur. Wenn das Internet geschaffen wurde, um Könige, Präsidenten und Abstimmungen als Quellen technischer Wahrheit abzulehnen, darf die Schicht der Nummernressourcen diese Formen nicht durch Registerverfahren, historische Delegation oder Gemeinschaftstheater nachbilden.

Konsens allein kann zum Ritual werden. Laufender Code allein kann untergeordnet werden, wenn die Registerschicht darüber als Anerkennungsquelle gestellt wird. Die fehlende Regel ist interpretativ und architektonisch: Wenn institutionelles Verfahren mit der minimalen technischen Funktion kollidiert, die laufende Systeme benötigen, hat der laufende Code Vorrang; und wenn eine spätere Änderung vorgeschlagen wird, wird sie nur durch freiwillige Übernahme der Teilnehmer real, die die Validierungsregeln ausführen.

So bewahrt man das ursprüngliche Design, statt es aufzugeben.

Das Internet war wichtig, weil es zum ersten globalen Kommunikationssystem wurde, das keine vorherige Erlaubnis eines einzigen Souveräns, Ministeriums, einer Kirche, eines Unternehmens oder eines Wächters verlangte. Wenn dieser Erfolg weiterhin verteidigenswert ist, darf die Schicht der Nummernressourcen nicht zur Ausnahme werden, die die Regel entkräftet.

Ein System, das Könige vermeiden soll, darf nicht zulassen, dass ein Buchhalter einer werden will.

Der Patch stellt die ursprüngliche Hierarchie wieder her: Code zuerst, Betreiber zuerst, deterministische Validierung zuerst, verteilter Zustand zuerst; Institutionen, falls sie während des Übergangs existieren, nur als nicht autoritative Artefakte, niemals als Gültigkeitsquellen.

Was Post-RIR-Koordination erfordert

Post-RIR-Koordination bedeutet kein Chaos.

Sie bedeutet, dass die gemeinsame Schicht dünner, objektiver, deterministischer und verteilter wird als das gegenwärtige RIR-Monopol.

Es gibt kein Register, zu dem man migriert.

Es gibt kein neues Register, das gekrönt wird.

Es gibt kein neues Priestertum.

Es gibt ein verteiltes Ledger für den Zustand der Nummernressourcen mit deterministischen Validierungsregeln, Kontrollnachweismechanismen, Konfliktbehandlung, Kompatibilitätsmengen, einer Historie der Zustandsübergänge und lokaler Prüfung durch die Teilnehmer.

Die gemeinsame Schicht muss die Einzigartigkeit von Kennungen, Kontrollnachweis, Übertragungszustand, Delegationszustand, routingbezogene Sicherheitsbehauptungen, Prüfbarkeit, Konfliktmetadaten und die Sichtbarkeit von Forks bewahren.

Die Betreiberschicht muss die kommerzielle Nutzung, Vermietung, Kundengeografie, Routingpraktiken, Finanzierung, Auswahl von Gegenparteien und nicht-invariante Geschäftsregeln steuern.

Die Übernahmeschicht muss bestimmen, was real wird. Eine Koordinationsregel zählt nur, wenn Betreiber sie implementieren können, Gegenparteien sie akzeptieren können, Märkte ihr vertrauen können, Gerichte sie verstehen können und Interoperabilität erhalten bleibt, ohne die Anerkennung des Amtsinhabers zur einzigen Realitätsquelle zu machen.

Die Durchsetzungsschicht darf nicht mit der Zustandsschicht verschmolzen werden. Ein verteiltes Ledger kann den Zustand aufzeichnen. Es kann Übergänge validieren. Es kann Konflikte offenlegen. Es kann Nachweise portabel machen. Es darf nicht zugleich Staatsanwalt, Richter, Sanktionsbehörde, Marktregulierer, kommerzieller Moralrichter und Vermögensverwahrer werden.

Am wichtigsten ist, Portabilität richtig zu verstehen.

In einer Welt verteilter Ledger bedeutet Portabilität nicht den Wechsel von einem Register zu einem anderen Register. Das ist weiterhin Registerdenken. Es gibt kein Register, zu dem man migriert. Der Kontrollnachweis des Inhabers, die Zustandshistorie und die Übertragungsfähigkeit sind nicht in einer etablierten Datenbank gefangen. Sie existieren in einem gemeinsamen, überprüfbaren Zustand, den Teilnehmer lokal validieren und Gegenparteien freiwillig akzeptieren.

Ohne dies ist jedes Register ein Blockadepunkt.

Damit verliert das Register seine Funktion als Gültigkeitsquelle.

Post-RIR-Koordination benötigt daher vier Designeigenschaften.

Erstens deterministische Gültigkeit. Ein Teilnehmer muss wissen können, ob ein Zustandsübergang, Nachweis, eine Delegation, Übertragung oder Behauptung gültig ist, indem er die Spezifikation lokal anwendet.

Zweitens Kompatibilitätsmengen. Wenn Teilnehmer unterschiedliche künftige Regeln übernehmen, muss das System die Kompatibilitätsgrenzen klar beschreiben, statt Dissens als Verstoß zu behandeln.

Drittens verteilten Kontrollnachweis. Ein Inhaber darf seine Ressourcen nicht „in ein anderes Register verschieben“; er muss Kontrolle durch einen gültigen Zustand im Ledger nachweisen, den jede Gegenpartei ohne Zustimmung des Amtsinhabers prüfen kann.

Viertens sichtbare Forks. Wenn Regelsätze auseinanderlaufen, muss die Abweichung explizit ausgewiesen werden. Teilnehmer entscheiden, welche Kompatibilitätsmenge sie ausführen und mit welchen Gegenparteien sie interagieren. Ein Fork kann Teilnehmer isolieren, gibt jedoch keiner Seite institutionelle Macht, die andere zu löschen.

Das ist kein Plädoyer für fünf bessere Monopole.

Es ist ein Argument gegen das Monopol als Gültigkeitsquelle.

Warum der Ausfallpfad vorhersehbar ist

Wenn sich nichts ändert, ist der Ausfallpfad klar.

Erstens werden mehr Streitigkeiten aus Policy-Räumen in Gerichte wandern. Knappe Vermögenswerte ziehen rechtliche Prüfung auf sich. Gerichte werden gebeten werden, Konten einzufrieren, Aufzeichnungen zu bewahren, unregelmäßige Wahlen zu blockieren, gerichtliche Verwalter einzusetzen, Übertragungen anzuerkennen oder zu bestimmen, wer im Namen eines Registers handeln darf.

Zweitens werden Staaten die RIR nicht länger als harmlose technische Verbände behandeln. Die Kontinuität der Adressierung betrifft nationale Konnektivität, Sanktionen, Strafverfolgung, Telekommunikationsresilienz, Cloud-Infrastruktur und wirtschaftliche Sicherheit. Kein Staat wird auf Dauer eine ausländische private Organisation als unangefochtenen übergeordneten Punkt nationaler Kommunikationskontinuität akzeptieren.

Drittens werden Betreiber die Registerautorität umgehen, wenn möglich. Wenn Register politisch, unsicher, nicht repräsentativ oder von der Realität der Vermögenswerte abgekoppelt werden, greifen Betreiber auf private Verträge, durch Gerichtsverfahren gestützte Übertragungen, alternative Zertifizierungen, nationale Anerkennung oder die faktische Routingrealität zurück.

Viertens werden ICANN- und NRO-Schichten versucht sein zu zentralisieren. Das würde eine dichtere Version desselben Problems erzeugen, sofern das Mandat selbst nicht reduziert wird.

Fünftens werden Regierungen versucht sein zu nationalisieren. Das wäre vorhersehbar und gefährlich. Wenn private Register quasi-souveräne Autorität ohne öffentliche Verantwortung beanspruchen, werden Staaten letztlich Souveränität beanspruchen. Das Ergebnis könnte Fragmentierung, Vergeltung, konkurrierende Register und politischer Druck auf das Routing sein.

Das Internet scheitert nicht nur, wenn Pakete sich nicht mehr bewegen.

Es scheitert auch, wenn Institutionen, die beschreiben, wer Kennungen nutzen darf, das Vertrauen der Betreiber verlieren, die diese Pakete bewegen.

Ein verteilter Ledger löst nicht alle politischen Probleme. Aber er tut etwas Wichtigeres: Er beseitigt das dauerhafte Register als gewöhnliche Gültigkeitsquelle. Das reduziert die Angriffsfläche. Es verringert die institutionelle Geiselmacht. Es verwandelt künftige Meinungsverschiedenheiten in Kompatibilitätsauswahl statt in Verwaltungskrieg.

Die Frage ändert sich

Das alte System fragt: Wer hat das Mandat?

Das ist die falsche Frage.

Die bessere Frage lautet: Was erfordert der laufende Code tatsächlich?

Schützt diese Regel die Einzigartigkeit?

Bewahrt sie die Interoperabilität?

Korrigiert sie nachweisbaren Registrierungsbetrug durch deterministische Belege?

Schützt sie routingbezogene Sicherheit?

Erhält sie die Genauigkeit des Kontrollnachweises?

Ermöglicht sie lokale Validierung?

Beseitigt sie die Abhängigkeit von einem einzigen Amtsinhaber?

Beschreibt sie die übernommene Realität oder erklärt sie eine nicht übernommene Verpflichtung?

Kann ein Teilnehmer sie ablehnen, ohne als ungültig gekennzeichnet zu werden?

Kann ein Teilnehmer die gewöhnliche Gültigkeit prüfen, ohne ein Register um einen Zustand zu bitten?

Kann eine Gegenpartei den Zustand freiwillig akzeptieren oder ablehnen?

Kann ein Fork stattfinden, ohne dass eine Institution eine Seite beseitigt?

Wenn die Antwort nicht an die deterministische Notwendigkeit des laufenden Codes gebunden ist, sollte diese Macht nicht in der gemeinsamen Schicht liegen.

Das ist der Vorrang des laufenden Codes.

Zur Diskussion

Dieser Vorschlag ist zur Diskussion gestellt. Er ist keine endgültige Lösung.

Der nächste Schritt sollte ein ernsthafter Internet-Draft oder ein BCP-ähnliches Dokument sein, das den Vorrang des laufenden Codes für Internetkoordinationssysteme definiert, beginnend mit Nummernressourcen. Der Entwurf sollte nicht fragen, wie das RIR-Monopol rehabilitiert werden kann. Er sollte fragen, wie Post-RIR-Koordination durch Zustand in einem verteilten Ledger, deterministische Validierung, freiwillige Übernahme, Gegenparteienannahme und ausdrücklich gekennzeichnete Kompatibilitätsmengen aufgebaut werden kann.

Er sollte von Betreibern, Juristen, Ökonomen, Protokollingenieuren, Experten für Routing-Sicherheit, Marktteilnehmern, Regierungen und Kritikern bewertet werden.

Der Entwurf sollte schwierige Fragen stellen.

Welche globalen Invarianten gibt es?

Welche Validierungsregeln sind deterministisch?

Welche Zustandsübergänge müssen global sichtbar sein?

Welche alten Registerbefugnisse sind historische Überreste?

Welche Entscheidungen gehören den Betreibern?

Welche Entscheidungen erfordern keine Vertretung, weil sie niemals in die gemeinsame Schicht gelangen sollten?

Wie sieht der Ablehnungspfad aus?

Wie sieht der Fork-Pfad aus?

Wie sieht der lokale Zurückweisungspfad aus?

Wie weist ein Inhaber Kontrolle ohne ein etabliertes Register nach?

Wie prüft eine Gegenpartei den Zustand ohne Register?

Kann das Internet weiterlaufen, wenn ein RIR zusammenbricht?

Können Nummernressourcen ohne Erlaubnis eines Amtsinhabers einzigartig bleiben?

Kann ein Teilnehmer den gewöhnlichen Zustand ohne dauerhafte Institution validieren?

Kann ein Policy-Verfahren zwischen einer Invariante des laufenden Codes und institutionellem Willen unterscheiden?

Kann die alte Registerschicht verschwinden, ohne den überprüfbaren Zustand zu verlieren?

Kann ein Register die Realität beschreiben, ohne souverän über sie zu werden?

Interessierte Personen können mich über LinkedIn kontaktieren. Seriöse Forscher, technische Autoren, Institutionen oder Policy-Experten, die helfen wollen, dies in einen ersten Internet-Draft und schließlich in ein RFC oder eine BCP-Diskussion zu überführen, falls die Gemeinschaft dies für nützlich hält, können mich kontaktieren. Die LARUS Foundation und ich sind bereit, ernsthafte Forschung in dieser Richtung zu unterstützen und zu finanzieren.

Das RIR-System scheiterte in seinem ursprünglichen Design, weil es nie fragte, was der laufende Code tatsächlich erfordert.

Es fragte, wer im Raum sprechen durfte.

Das nächste System muss diese Reihenfolge umkehren.

Es ist keine Mandatswäsche.

Es ist kein Verrat am laufenden Code.

Vorrang des laufenden Codes.

Anhang: Minimale Anfangsspezifikation, lokalisierte zukünftige Entscheidung und freiwillige Übernahme für Internetkoordinationssysteme

Notiz 64

Zusammenfassung

Dieses Dokument beschreibt ein Designmuster für Internetkoordinationssysteme, dessen Zweck darin besteht, gemeinsame technische Bezugspunkte bereitzustellen, ohne eine dauerhafte Autorität über den Teilnehmern zu schaffen, die das System ausführen. Es definiert drei verbundene Prinzipien: Minimale Anfangsspezifikation, lokalisierte zukünftige Entscheidung und freiwillige Übernahme.

Nach diesem Modell definiert die Anfangsspezifikation nur die deterministischen und lokal überprüfbaren Regeln, die für Einzigartigkeit, Interoperabilität, Kontrollnachweis, gemeinsame Sicherheit und Sicherheit erforderlich sind. Nach der Anfangsspezifikation werden künftige Änderungen nicht von einem zentralen Organ genehmigt. Sie werden von den Teilnehmern, die Code ausführen, übernommen, ignoriert, geforkt oder aufgegeben.

Das vorgesehene Designmuster ist ein verteiltes Ledger des gültigen Zustands oder ein gleichwertiger Mechanismus für verteilten überprüfbaren Zustand, keine Registerhierarchie. Es gibt kein dauerhaftes Register, das über die gewöhnliche Gültigkeit entscheidet. Teilnehmer validieren den Zustand lokal, akzeptieren Gegenparteien freiwillig und entscheiden, welche Kompatibilitätsmengen sie ausführen.

Nichtübernahme ist kein Verstoß. Ein Teilnehmer, der eine spätere Änderung nicht übernimmt, bleibt in seiner bestehenden Kompatibilitätsmenge. Ein Teilnehmer, der Zustände ausgibt, die nach den deterministischen Regeln eines anderen ungültig sind, kann von diesem Teilnehmer lokal ignoriert werden. Die Wirkung ist Kompatibilitätsauswahl, Forking, Isolation oder selektive Interoperabilität, keine institutionelle Bestrafung.

Dieses Dokument definiert kein Netzwerkprotokoll (wire protocol). Es spezifiziert eine Best Current Practice (BCP) für das Design von Protokollen, Kennungssystemen, verteilten Ledgers und Koordinationsmechanismen, die nicht zu dauerhaften Governance-Institutionen werden dürfen.

1. Einleitung

Viele Internetsysteme beginnen mit einem begrenzten technischen Zweck: unabhängigen Akteuren durch einen gemeinsamen Bezugspunkt, einen Kennungsraum, eine Validierungsregel, einen Ledger-Zustand oder ein gemeinsames Kontrollnachweisregister die Interoperabilität zu ermöglichen. Mit der Zeit sammeln diese Systeme häufig Autorität an, die für die ursprüngliche Interoperabilität nicht erforderlich war.

Dies geschieht normalerweise in drei Schritten.

Erstens werden künftige Fragen in die Fundamentschicht aufgenommen, bevor sie technisch notwendig sind.

Zweitens werden Entscheidungen, die von den Teilnehmern getroffen werden sollten, die ihre eigenen Systeme ausführen, von Anerkennung, Auslegung oder Statusentscheidungen eines dauerhaften Organs abhängig gemacht.

Drittens werden Veröffentlichung, Registrierung, Empfehlung oder verfahrenstechnische Genehmigung als ausreichend behandelt, um operative Pflichten zu schaffen, selbst wenn Teilnehmer die Änderung in laufenden Systemen nicht übernommen haben.

Das Ergebnis ist ein fragiles System. Eine technische Bezugsschicht wird zu einer Governance-Schicht. Ein Register wird zu einem Kontrollpunkt. Ein Koordinationsartefakt wird zu einer Quelle zukünftiger Kontrolle.

Dieses Dokument schlägt eine andere Design­disziplin vor:

Minimale Anfangsspezifikation: Nur die deterministischen gemeinsamen Regeln definieren, die für grundlegende Interoperabilität, Einzigartigkeit, Kontrollnachweis, gemeinsame Sicherheit und Sicherheit erforderlich sind.

Lokalisierte zukünftige Entscheidung: Nach der Anfangsspezifikation künftige Entscheidungen bei den Teilnehmern belassen, die Code ausführen. Ein Teilnehmer kann übernehmen, ablehnen, forken, die Verbindung trennen oder selektiv interoperieren. Kein Teilnehmer kann die Interoperabilität anderer Teilnehmer verändern, die weiterhin gegenseitig kompatible Regeln ausführen.

Freiwillige Übernahme: Spätere Änderungen nur durch Implementierung, Betrieb, Validierung und Übernahme durch die Teilnehmer, die Code ausführen, real werden lassen.

Diese Prinzipien hängen zusammen. Ein System, das von Anfang an zu viel spezifiziert, lädt künftige Kontrolle in die gemeinsame Schicht vor. Ein System, das eine dauerhafte Anerkennungsschicht beibehält, erlaubt es, dass Autorität nach der Bereitstellung wiederkehrt. Ein System, das Veröffentlichung als Realität behandelt, verwandelt Dokumentation in ein Mandat.

Die Designintuition ist einfach: Gültigkeit muss durch deterministische Regeln bestimmt werden, die Teilnehmer lokal gegen einen gemeinsamen Zustand prüfen können. Ein Teilnehmer kann eine spätere Änderung übernehmen, ablehnen, forken, die Verbindung trennen oder selektiv interoperieren. Höchstens kann er sich aus einer Kompatibilitätsmenge zurückziehen. Durch die Ablehnung einer Änderung kann er nicht die Interoperabilität anderer Teilnehmer zerstören, die weiterhin gegenseitig kompatible Regeln ausführen.

Dies ist die allgemeine Lehre des Designs verteilter Ledger: Konsensregeln werden von Teilnehmern angewandt, die Validierungscode ausführen und entscheiden, welchen Zustand sie akzeptieren, nicht von einer über ihnen stehenden Institution.

2. Geltungsbereich

Dieses Dokument gilt für Internetkoordinationssysteme, einschließlich, aber nicht beschränkt auf Kennungssysteme, Namens- und Nummerierungsrahmen, Protokollerweiterungsmechanismen, Kontrollnachweissysteme, Portabilitätssysteme, verteilte Ledger und andere Architekturen, in denen unabhängige Akteure von einem gemeinsamen technischen Bezugspunkt abhängen.

Dieses Dokument wendet sich nicht gegen gemeinsame Regeln. Es argumentiert, dass gemeinsame Regeln deterministisch, minimal, lokal überprüfbar und auf das beschränkt sein müssen, was das System für seine Funktion tatsächlich benötigt.

Dieses Dokument verlangt keine bestimmte Implementierung eines verteilten Ledgers. Es verlangt eine Designeigenschaft: Teilnehmer müssen die Gültigkeit bestimmen können, indem sie die Anfangsspezifikation lokal auf einen gemeinsamen oder replizierbaren Zustand anwenden, ohne eine dauerhafte Autorität um Erlaubnis oder Status zu bitten.

3. Konventionen und Definitionen

3.1. Anforderungssprache

Die großgeschriebenen Anforderungsbegriffe in diesem Dokument sind im Sinne von BCP 14, insbesondere RFC 2119 und RFC 8174, auszulegen.

3.2. Terminologie

Anfangsspezifikation:
Die Menge von Regeln, Datenstrukturen, Formaten, Invarianten, Validierungsverfahren, Zustandsübergangsregeln und Konfliktregeln, die für die erste Bereitstellung eines Systems erforderlich sind.

Gemeinsame Schicht (Common Layer):
Die minimale Menge gemeinsamer Regeln oder Referenzstrukturen, die unabhängige Teilnehmer zur Interoperabilität benötigen. Die gemeinsame Schicht ist keine Institution. Sie ist die technische Substanz, die Teilnehmer implementieren und prüfen.

Verteilter Ledger (Distributed Ledger):
Eine replizierte oder anderweitig verteilte Aufzeichnung von Zustandsübergängen, die Teilnehmern ermöglicht, die gewöhnliche Gültigkeit zu prüfen, ohne von einem dauerhaften Register, Komitee oder einer anderen Autorität abhängig zu sein. Der Begriff verlangt keinen bestimmten Konsensalgorithmus oder eine bestimmte Implementierung.

Deterministische Validierungsregel (Deterministic Validation Rule):
Eine Regel, die einem Teilnehmer durch lokale Berechnung oder lokale Prüfung ermöglicht zu entscheiden, ob ein Zustand, Datensatz, Übergang, eine Behauptung oder Nachricht nach einem festgelegten Regelwerk gültig ist.

Globale Invariante (Global Invariant):
Eine Eigenschaft, die innerhalb einer Kompatibilitätsmenge gemeinsam bleiben muss, um Einzigartigkeit, grundlegende Interoperabilität, Integrität des Kontrollnachweises, gemeinsame Sicherheit oder Sicherheit zu bewahren.

Teilnehmer (Participant):
Ein Betreiber, eine Implementierung, ein Knoten, ein Netz, eine Organisation oder ein anderer Akteur, der das System ausführt, prüft, bereitstellt oder von ihm abhängt.

Kompatibilitätsmenge (Compatibility Set):
Eine Gruppe von Teilnehmern, deren implementierte Validierungsregeln ihnen die Interoperabilität miteinander erlauben. Eine spätere Änderung kann eine neue Kompatibilitätsmenge erzeugen, wenn einige Teilnehmer sie übernehmen und andere nicht.

Übernahme (Adoption):
Tatsächliche Implementierung, Bereitstellung, Validierung und Nutzung durch die Teilnehmer, die das System ausführen.

Gegenparteienannahme (Counterparty Acceptance):
Die freiwillige Entscheidung eines Teilnehmers, den Zustand eines anderen Teilnehmers nach den von ihm ausgeführten Validierungsregeln zu akzeptieren, mit ihm Transaktionen durchzuführen, zu interoperieren oder ihm zu vertrauen.

Nichtübernahme (Non-Adoption):
Die Entscheidung eines Teilnehmers, eine vorgeschlagene Änderung nicht zu implementieren oder zu nutzen. Nichtübernahme erzeugt keinen ungültigen Zustand. Sie bedeutet nur, dass der Teilnehmer nicht in die durch die Änderung geschaffene Kompatibilitätsmenge eingetreten ist.

Lokale Ablehnung (Local Rejection):
Die lokale Entscheidung eines Teilnehmers, einen Zustand, eine Nachricht, einen Datensatz oder einen Übergang zu ignorieren oder abzulehnen oder damit nicht zu interoperieren, wenn das jeweilige Element nach den von ihm ausgeführten Validierungsregeln ungültig oder inkompatibel ist.

Fork:
Eine Abweichung bei Validierungsregeln oder operativer Praxis, die zwei oder mehr Kompatibilitätsmengen erzeugt.

Koordinationsartefakt (Coordination Artifact):
Ein Dokument, eine Empfehlung, eine Implementierungsnotiz, ein Profil, eine Referenzimplementierung, ein Ledger-Explorer, eine Replik oder ein anderes Artefakt, das Teilnehmern bei der Koordination hilft. Ein Koordinationsartefakt erzeugt keine bindende operative Realität, sofern Teilnehmer es nicht in laufenden Systemen übernehmen.

4. Problemstellung

Designer versuchen häufig, künftige Unsicherheit zu verringern, indem sie zu viel in die Fundamentschicht schreiben oder einem dauerhaften Organ die Auslegung künftiger Fragen überlassen. Das wirkt umsichtig. Oft ist es gefährlich.

Eine Überspezifikation in der Fundamentschicht verursacht Kosten in dreierlei Hinsicht.

Erstens verlagert sie künftige Entscheidungen in eine gemeinsame Schicht, in der Änderungen schwieriger sind und Vereinnahmung größere Wirkung hat.

Zweitens schafft sie Unklarheit zwischen technischer Gültigkeit und institutioneller Anerkennung.

Drittens ermutigt sie ein Organ, das Register führt, Dokumente veröffentlicht oder Teilnehmer zusammenruft, diese Handlungen als Autorität über die künftige Realität zu behandeln.

Dasselbe Problem tritt nach der Bereitstellung auf. Wenn ein System ein dauerhaftes Organ benötigt, um Änderungen zu genehmigen, Zustände zu bestimmen oder den gewöhnlichen Betrieb auszulegen, hat das System eine Kontrollschicht nach der Gründung geschaffen. Sie kann als Verwaltung beginnen. Sie kann zu Governance werden. Und sie kann zu einem Engpass werden.

Das Designziel dieses Dokuments ist keine bessere institutionelle Ermessensausübung. Das Ziel ist, die Notwendigkeit dieser Ermessensausübung zu vermeiden.

Ein gut entworfenes Internetkoordinationssystem sollte von Anfang an deterministische und lokal überprüfbare Gültigkeitsregeln definieren; den gültigen Zustand verteilt oder replizierbar darstellen; nicht-invariante Entscheidungen außerhalb der gemeinsamen Schicht halten; und spätere Änderungen nur dann real werden lassen, wenn Teilnehmer sie freiwillig in laufenden Systemen übernehmen.

5. Prinzip 1: Minimale Anfangsspezifikation

5.1. Erklärung

Eine Anfangsspezifikation SOLLTE nur die minimalen gemeinsamen deterministischen Regeln definieren, die für grundlegende Interoperabilität, Einzigartigkeit, Kontrollnachweis, gemeinsame Sicherheit und Sicherheit erforderlich sind.

5.2. Anforderungen

Ein Design, das dieses Prinzip verwendet:

• MUSS seine globalen Invarianten ausdrücklich identifizieren.
• MUSS für jede globale Invariante deterministische Validierungsregeln definieren.
• MUSS definieren, wie gültiger Zustand dargestellt, repliziert, geprüft und aktualisiert wird.
• DARF NICHT eine Regel in die Anfangsspezifikation aufnehmen, es sei denn, sie ist notwendig, um eine erklärte globale Invariante zu bewahren oder die erste Bereitstellung zu ermöglichen.
• MUSS Validierungsregeln von politischen Präferenzen, Handelsvereinbarungen, institutionellen Rollen, Governance-Ambitionen und Ermessensentscheidungen trennen.
• MUSS Teilnehmern ermöglichen, die gewöhnliche Gültigkeit lokal zu prüfen, ohne Informationen von einer Institution, einem Register, Komitee, Policy-Organ oder einer anderen Autorität anzufordern.
• SOLLTE für die lokale Prüfung erforderliche Datenstrukturen, Signaturen, Nachweise, Zustandsübergangsregeln, Konfliktregeln oder andere Mechanismen definieren.
• SOLLTE die Kennzeichnung von Erweiterungen, Versionierung, Kompatibilitätsmarkierungen oder Fork-Identifikation definieren, wenn künftige Variation absehbar ist.
• MUSS sicherstellen, dass erforderliche Koordinationsartefakte portabel, prüfbar, reproduzierbar und ersetzbar sind.
• SOLLTE objektive, maschinell überprüfbare Bedingungen gegenüber subjektiven Verdiensturteilen bevorzugen.
• DARF NICHT künftige institutionelle Anerkennung zum einzigen Weg machen, auf dem ein gültiger Zustand bekannt, registriert oder genutzt werden kann.

5.3. Designimplikationen

Minimale Anfangsspezifikation bedeutet keine vage Spezifikation. Sie bedeutet eine strenge Spezifikation nur dessen, was gemeinsam sein muss.

Ein System benötigt weiterhin genügend gemeinsame Struktur, um zu funktionieren. Die Disziplin besteht darin, zu unterscheiden zwischen:

• dem, was für Einzigartigkeit, Interoperabilität, Kontrollnachweis, gemeinsame Sicherheit und Sicherheit gemeinsam sein muss; und
• dem, was außerhalb der gemeinsamen Schicht bleiben kann, weil es zur Betreiberpräferenz, kommerziellen Praxis, Gegenparteiwahl, Bereitstellungszeit oder späteren Übernahmeentscheidungen gehört.

Ein Design, das seine globalen Invarianten und deterministischen Validierungsregeln nicht klar ausdrücken kann, sollte davon ausgehen, dass es zu viel Ermessensspielraum und zu wenig überprüfbare Substanz spezifiziert hat.

6. Prinzip 2: Lokalisierte zukünftige Entscheidung

6.1. Erklärung

Nach der Anfangsspezifikation SOLLTEN zukünftige Entscheidungen lokal bei den Teilnehmern bleiben, die Code ausführen. Eine zukünftige Entscheidung wird nur für die Kompatibilitätsmenge wirksam, deren Teilnehmer sie übernehmen. Keine dauerhafte Autorität ist zu ihrer Genehmigung erforderlich, und Nichtübernahme erzeugt keinen ungültigen Zustand.

6.2. Anforderungen

Ein Design, das dieses Prinzip verwendet:

• DARF NICHT verlangen, dass Teilnehmer die Erlaubnis einer etablierten Institution, eines Registers, Komitees, Rates, Policy-Organs oder einer anderen Autorität für Entscheidungen einholen, die die deterministischen Validierungsregeln der Kompatibilitätsmenge, der sie angehören, nicht verändern.
• DARF NICHT ein dauerhaftes Organ schaffen, dessen Anerkennung der einzige Weg ist, auf dem eine spätere Änderung operative Realität werden kann.
• MUSS zwischen Gültigkeit nach der Anfangsspezifikation und Kompatibilität mit einer optionalen späteren Änderung unterscheiden.
• DARF NICHT die Nichtübernahme einer späteren Änderung als Ungültigkeit behandeln.
• MUSS Teilnehmern erlauben, in einer bestehenden Kompatibilitätsmenge zu bleiben, wenn sie eine spätere Änderung nicht übernehmen.
• MUSS Teilnehmern erlauben, einer neuen Kompatibilitätsmenge durch Übernahme neuer Validierungsregeln oder Betriebsprofile beizutreten.
• MUSS Teilnehmern erlauben, Zustände, Datensätze, Übergänge oder Nachrichten lokal abzulehnen, die nach den von ihnen ausgeführten Validierungsregeln ungültig oder inkompatibel sind.
• MUSS Teilnehmern erlauben, Gegenparteien freiwillig nach den akzeptierten Validierungsregeln und Kompatibilitätsmengen auszuwählen.
• DARF NICHT eine Institution, ein Register, ein Komitee, ein Policy-Organ oder einen anderen Akteur ermächtigen, einen Teilnehmer allein deshalb für ungültig zu erklären, weil er eine spätere Änderung ablehnt.
• SOLLTE Forks, Versionen, Profile oder Kompatibilitätsmengen explizit ausweisen, damit Teilnehmer wissen, welche Regeln sie ausführen und mit welchen anderen Teilnehmern sie interoperieren können.
• SOLLTE jedes Design vermeiden, in dem ein etabliertes Register verhindern kann, dass weiterhin gültige Teilnehmer interoperieren.

6.3. Designimplikationen

Lokalisierte zukünftige Entscheidung bedeutet nicht, dass eine zentrale Autorität künftige Entscheidungen lokalen Akteuren zuweist. Es bedeutet, dass das System so entworfen ist, dass gewöhnliche künftige Entscheidungen nach der Anfangsspezifikation diese Zuweisung nicht benötigen.

Die Anfangsspezifikation leistet die Begrenzungsarbeit im Voraus. Sie definiert die minimalen Invarianten für Einzigartigkeit, Interoperabilität, Kontrollnachweis, gemeinsame Sicherheit und Sicherheit. Alles andere bleibt außerhalb der gemeinsamen Schicht.

Künftige Änderungen werden nicht zentral genehmigt. Sie werden von den Teilnehmern übernommen, ignoriert, geforkt oder aufgegeben, die Code ausführen.

Ein Teilnehmer, der eine Änderung ablehnt, kann außerhalb der durch die Änderung geschaffenen Kompatibilitätsmenge bleiben. Er kann die Verbindung zu anderen trennen. Er kann in einer früheren Kompatibilitätsmenge fortfahren. Er kann forken. Er kann selektiv interoperieren. Er kann jedoch nicht die Interoperabilität anderer Teilnehmer zerstören, die weiterhin gegenseitig kompatible Regeln ausführen.

Die Wirkung eines ungültigen oder inkompatiblen Zustands ist lokale Ablehnung, keine Bestrafung. Niemand muss feststellen, dass ein Teilnehmer in einer schlechten Position ist. Ein Teilnehmer, der kompatible Validierungsregeln ausführt, akzeptiert den ungültigen oder inkompatiblen Zustand einfach nicht.

7. Prinzip 3: Freiwillige Übernahme

7.1. Erklärung

Änderungen in einem Internetkoordinationssystem SOLLTEN durch Implementierung, Validierung, Bereitstellung, Gegenparteienannahme und Übernahme durch Teilnehmer operative Realität werden, nicht allein durch Veröffentlichung oder Erklärung.

7.2. Anforderungen

Ein Design, das dieses Prinzip verwendet:

• DARF NICHT Veröffentlichung, Empfehlung, Sitzungsbeschluss oder verfahrenstechnische Genehmigung als ausreichend betrachten, um eine universelle operative Verpflichtung zu schaffen.
• MUSS erlauben, dass neue Regeln, Erweiterungen, Profile oder Verfahren von den Teilnehmern, die sich für ihre Ausführung entscheiden, schrittweise bereitgestellt werden.
• MUSS Teilnehmern ermöglichen, eine spätere Änderung abzulehnen, ohne dadurch den Status „ungültig“ zu erhalten, solange ihre eigenen Zustandsübergänge den deterministischen Regeln ihrer Kompatibilitätsmenge entsprechen.
• MUSS Teilnehmern erlauben, eine frühere Kompatibilitätsmenge weiter zu verwenden, wenn die Anfangsspezifikation diese Kontinuität zulässt.
• MUSS Teilnehmern, die in einer Kompatibilitätsmenge arbeiten, erlauben, Zustände einer anderen Kompatibilitätsmenge lokal abzulehnen oder zu ignorieren, wenn die Regeln inkompatibel sind.
• SOLLTE Übernahmepfade für wesentliche Änderungen definieren, einschließlich Versionssignalisierung, Kompatibilitätskennzeichnung, Übergangsanleitungen und Testvektoren.
• SOLLTE Ablehnungspfade für wesentliche Änderungen definieren, einschließlich der Art, wie Nichtübernehmer weiterarbeiten, ihre Kompatibilitätsmenge identifizieren und mehrdeutige Interoperabilität vermeiden.
• MUSS sicherstellen, dass notwendige Koordinationsartefakte aufgegeben, repliziert, neu implementiert oder ersetzt werden können, ohne untragbare Übergangskosten.
• SOLLTE sicherstellen, dass Register, Empfehlungen und Koordinationsartefakte die übernommene Realität beschreiben, statt zu versuchen, eine nicht übernommene künftige Realität für existent zu erklären.
• DARF NICHT ein System entwerfen, in dem eine Änderung nur dann real werden kann, wenn sie zuvor von einem etablierten Organ anerkannt wurde.

7.3. Designimplikationen

Freiwillige Übernahme ist der operative Test dafür, ob eine Änderung nützlich, tragbar und mit realer Bereitstellung vereinbar ist.

Ein Vorschlag ist keine Realität. Eine Empfehlung ist keine Realität. Ein Dokument ist keine Realität. Realität entsteht, wenn Teilnehmer die Änderung implementieren, validieren, bereitstellen, Gegenparteien akzeptieren und sich auf sie verlassen.

Nichtübernahme erzeugt keinen Verstoßzustand. Sie erzeugt nur eine Tatsache: Der Teilnehmer ist nicht in die durch die Änderung geschaffene Kompatibilitätsmenge eingetreten.

Dies beseitigt Standardisierungsprozesse, Dokumentation, Implementierungsnotizen, Explorer, Replikate oder Prüfungen nicht. Es begrenzt ihren Umfang. Sie können Teilnehmern bei der Koordination helfen. Sie können Referenzmaterial veröffentlichen. Sie können Übernahme beschreiben. Sie können empfehlen. Aber sie können allein durch Erklärung keine nicht übernommene künftige Realität für Teilnehmer, die sie nicht ausführen, verbindlich machen.

8. Verhältnis der drei Prinzipien

Die drei Prinzipien verstärken sich gegenseitig und sind isoliert nicht wirksam.

Die Minimale Anfangsspezifikation stellt sicher, dass die gemeinsame Schicht deterministische Validierungsregeln statt Ermessensautorität enthält.

Die lokalisierte zukünftige Entscheidung stellt sicher, dass künftige Entscheidungen bei den Teilnehmern bleiben, die Code ausführen, statt von einer zentralen Genehmigungsschicht wieder vereinnahmt zu werden.

Die freiwillige Übernahme stellt sicher, dass spätere Änderungen den Kontakt mit Implementierung, Prüfung, Gegenparteienannahme und Nutzung überstehen müssen.

Ein System, das nur eines oder zwei dieser Prinzipien übernimmt, kann dieselbe Zentralisierung auf anderen Wegen reproduzieren.

Minimale Anfangsspezifikation ohne lokalisierte zukünftige Entscheidung kann weiterhin erlauben, dass sich Autorität nach der Bereitstellung ansammelt.
Lokalisierte zukünftige Entscheidung ohne minimale Anfangsspezifikation kann Mehrdeutigkeit erzeugen, weil Teilnehmer die Gültigkeit nicht lokal bestimmen können.
Freiwillige Übernahme ohne deterministische Validierung kann Verwirrung erzeugen, weil Teilnehmer kompatible Varianten nicht von ungültigen Zuständen unterscheiden können.
Deterministische Validierung ohne verteilten Zustand kann Teilnehmer weiterhin von einem privilegierten Register abhängig lassen.
Verteilter Zustand ohne Sichtbarkeit von Forks kann Dissens bis zum operativen Ausfall verbergen.
Verteilter Zustand ohne freiwillige Gegenparteienannahme kann Zwang durch eine andere Schnittstelle wiederherstellen.

Zusammen erzeugen die Prinzipien ein System, in dem die gemeinsame Schicht dünn, die Gültigkeit lokal überprüfbar, künftige Änderung freiwillig und der Zustand verteilt ist und keine dauerhafte Institution erforderlich ist, um über den gewöhnlichen Betrieb zu entscheiden.

9. Empfohlenes Designmuster

9.1. Deterministische verteilte gemeinsame Schicht

Die gemeinsame Schicht SOLLTE beschränkt sein auf:

• stabile Semantik von Kennungen;
• deterministische Gültigkeitsregeln;
• Konfliktlösungsregeln, die zur Wahrung der Einzigartigkeit erforderlich sind;
• Mechanismen des Kontrollnachweises;
• Regeln für Zustandsübergänge;
• Interoperabilitätsanforderungen auf Netzwerk- oder Protokollebene;
• gemeinsame Sicherheitsinvarianten;
• portable und prüfbare Zustandsformate;
• Sichtbarkeit des verteilten oder replizierten Zustands;
• Signalisierung von Erweiterungen und Identifikation von Kompatibilitätsmengen.

Die gemeinsame Schicht SOLLTE NICHT enthalten:

• Regeln für Geschäftsmodelle;
• Preisregeln;
• regionale politische Präferenzen;
• nicht mit technischen Invarianten verbundene Ideologie der Teilnahmeberechtigung;
• Ermessensvollmachten zur Durchsetzung;
• subjektive Verdienstbewertungen;
• Ausweitung institutioneller Aufgaben;
• jede Regel, deren Hauptfunktion darin besteht, die Autorität eines etablierten Organs zu bewahren.

9.2. Entscheidungsfläche des Betreibers

Folgendes SOLLTE außerhalb der gemeinsamen Schicht bleiben, sofern es keine erklärte globale Invariante direkt verändert:

• Zeitpunkt der Bereitstellung;
• kommerzielle Nutzung;
• Kundengeografie;
• Vereinbarungen über Vermietung, Finanzierung oder Übertragung;
• lokale Präferenz für Teilnahmeberechtigung;
• operative Reihenfolge;
• für gemeinsame Gültigkeit nicht erforderliche Routingpraxis;
• Geschäftsmodell;
• Organisationsstruktur;
• Zeitpunkt freiwilliger Migration;
• optionale Profile oder Erweiterungen;
• Auswahl von Gegenparteien.

Teilnehmer DÜRFEN in diesen Bereichen unterschiedliche Entscheidungen treffen. Solche Entscheidungen können unterschiedliche Kompatibilitätsmengen, Geschäftsbeziehungen, Peering-Vereinbarungen oder Betriebsgemeinschaften hervorbringen. Sie erzeugen keine Ungültigkeit, außer wenn sie deterministische Validierungsregeln innerhalb einer Kompatibilitätsmenge verletzen.

9.3. Übernahmezyklus

Wenn möglich, ist die bevorzugte Reihenfolge für wesentliche Systemänderungen:

• Vorschlag;
• Implementierung;
• Testvektoren oder deterministische Prüfmethode;
• begrenzte Bereitstellung durch willige Teilnehmer;
• Beobachtung von Interoperabilitäts- und Sicherheitseffekten;
• Kennzeichnung von Kompatibilitätsmengen;
• Dokumentation oder Empfehlung, die die übernommene Realität beschreibt.

Ein Koordinationsartefakt SOLLTE der Übernahme folgen, statt sie vorwegzunehmen.

9.4. Forking, lokale Ablehnung und Gegenparteienannahme

Ein konformes Design SOLLTE Forking, lokale Ablehnung und Gegenparteienannahme als normale Designanforderungen behandeln und nicht als Fehler.

Das System SOLLTE definieren, wie ein Teilnehmer:

• in einer früheren Kompatibilitätsmenge bleiben kann;
• eine neue Kompatibilitätsmenge übernehmen kann;
• in eine andere Kompatibilitätsmenge forken kann;
• den Zustand prüfen kann, ohne von einem etablierten Register abhängig zu sein;
• Gegenparteien freiwillig akzeptieren kann;
• ungültige oder inkompatible Zustände lokal ablehnen kann;
• selektiv interoperieren kann, wenn Kompatibilität dies erlaubt.

Ein System, das sich nicht forken oder lokal prüfen lässt oder mit dem man nicht selektiv interoperieren kann, ohne den gültigen Betrieb zu zerstören, hat wahrscheinlich Governance-Macht in seiner Registerfunktion verborgen.

10. Anwendbarkeit und Grenzen

Dieses Designmuster ist besonders anwendbar, wenn:

• das System mehrere Akteure und mehrere Rechtsordnungen umfasst;
• unabhängige Bereitstellung wichtig ist;
• die Koordinationsschicht dünn bleiben soll;
• künftige Variation wahrscheinlich, aber im Detail nicht vorhersehbar ist;
• Lock-in oder Abhängigkeit Governance-Risiken erzeugen würden;
• Gültigkeit deterministisch oder lokal überprüfbar gemacht werden kann;
• verteilter Zustand das Risiko institutioneller Vereinnahmung verringern kann.

Es kann weniger unmittelbar anwendbar sein, wenn:

• eine einzige administrative Domäne als Architektur vorgesehen ist;
• enge Echtzeitkopplung jederzeit einheitliches Verhalten verlangt;
• lebenswichtige Sicherheitsaspekte sofortige globale Einheitlichkeit erfordern;
• Gültigkeit durch keinen praktikablen Mechanismus lokal überprüft werden kann.

Auch in diesen Fällen SOLLTEN Designer die gemeinsame Schicht weiterhin minimieren und künftige Ermessenskontrolle soweit wie möglich vermeiden.

11. Nichtziele

Dieses Dokument:

• verbietet nicht jede Koordination;
• erfordert keine bestimmte Implementierung eines verteilten Ledgers;
• garantiert keinen Konsens;
• garantiert keine politische Neutralität;
• verlangt nicht, dass alle Teilnehmer jede spätere Änderung übernehmen;
• behandelt die Ablehnung einer Übernahme nicht als Ungültigkeit;
• legitimiert kein lokal inkompatibles Verhalten unter dem Anspruch von Kompatibilität;
• beseitigt nicht die Notwendigkeit gemeinsamer Regeln, die für die Sicherheit kritisch sind.

12. Sicherheitserwägungen

Eine dünnere Koordinationsschicht kann das Risiko der Vereinnahmung verringern, den Wirkungsradius institutioneller Fehler verkleinern und die Ersetzbarkeit verbessern. Größerer lokaler Ermessensspielraum und verteilter Zustand können jedoch auch inkonsistente Sicherheitslagen, Herabstufungspfade, Fragmentierungsdruck, mehrdeutige Kompatibilitätsbehauptungen, unsichere Forks, Streitigkeiten über den Ledger-Zustand und Versuche zur Fälschung von Nachweisen erzeugen.

Daher MÜSSEN Designer, die dieses Dokument anwenden, Sicherheitsinvarianten ausdrücklich spezifizieren. Insbesondere:

• Authentifizierungs- und Autorisierungsanforderungen, die für gemeinsame Gültigkeit erforderlich sind, MÜSSEN deterministisch und lokal überprüfbar sein;
• Kontrollnachweismechanismen MÜSSEN Fälschung, Wiederholung und nicht autorisierte Übertragung abwehren;
• Versionsaushandlung und Erweiterungsbehandlung MÜSSEN stille Herabstufungen verhindern, wenn die Sicherheit betroffen ist;
• Ablehnungs-, Fork- und Ersatzpfade MÜSSEN auf Missbrauchs- und Denial-of-Service-Risiken geprüft werden;
• Kompatibilitätskennzeichnungen SOLLTEN klar genug sein, um unbeabsichtigte Interoperabilität zwischen inkompatiblen Regelsätzen zu vermeiden;
• verteilter Zustand SOLLTE prüfbar und reproduzierbar sein, um inkonsistente Ansichten zu erkennen;
• lokale Variation DARF NICHT fälschlich Kompatibilität mit einem Regelsatz erklären können, den sie nicht erfüllt.

Die Existenz von Sicherheitsausnahmen rechtfertigt keine allgemeine Berechtigungsschicht. Sie rechtfertigt nur deterministische Sicherheitsregeln, die erforderlich sind, um die erklärten globalen Invarianten zu bewahren.

13. IANA-Erwägungen

Dieses Dokument erfordert keine Maßnahmen der IANA.

14. Referenzen

14.1. Normative Referenzen

• RFC 2119 — Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119.
• RFC 8174 — Leiba, B., Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words, BCP 14, RFC 8174.

14.2. Informative Referenzen

• RFC 6709 — Carpenter, B. und B. Aboba, Design Considerations for Protocol Extensions, RFC 6709.
• RFC 7282 — Resnick, P., On Consensus and Humming in the IETF, RFC 7282.

Anhang A. Design-Checkliste

Ein Design, das Konformität mit diesem Dokument behauptet, SOLLTE die folgenden Fragen klar beantworten können:

• Was sind die globalen Invarianten?
• Welche deterministischen Validierungsregeln bewahren diese globalen Invarianten?
• Welche Regeln der Anfangsspezifikation sind für die erste Bereitstellung strikt erforderlich?
• Wie wird gültiger Zustand dargestellt und geprüft?
• Ist der Zustand verteilt, repliziert oder anderweitig unabhängig überprüfbar?
• Welche künftigen Fragen werden absichtlich außerhalb der gemeinsamen Schicht gehalten?
• Welche künftigen Entscheidungen können Teilnehmer treffen, ohne die Kompatibilitätsmenge zu verändern, in der sie sich befinden?
• Wie übernimmt ein Teilnehmer eine spätere Änderung?
• Wie lehnt ein Teilnehmer eine spätere Änderung ab, ohne dass ihm der Status „ungültig“ zugewiesen wird?
• Wie werden Kompatibilitätsmengen gekennzeichnet oder erkannt?
• Wie funktioniert lokale Ablehnung, wenn ein Zustand nach den Regeln eines Teilnehmers ungültig oder inkompatibel ist?
• Wie sieht der Fork-Pfad aus?
• Wie weist ein Inhaber Kontrolle ohne ein etabliertes Register nach?
• Wie prüft eine Gegenpartei den Zustand ohne Register?
• Können Teilnehmer die gewöhnliche Gültigkeit prüfen, ohne von einem etablierten Register abhängig zu sein?
• Beschreiben Register und Koordinationsartefakte die übernommene Realität oder versuchen sie, eine nicht übernommene künftige Realität als existent zu erklären?
• Hat das System die Zahl der Entscheidungen in der gemeinsamen Schicht minimiert?
• Hat das System jede dauerhafte Autorität vermieden, die den gewöhnlichen Zustand der Teilnehmer bestimmt?
• Können Teilnehmer Gegenparteien freiwillig akzeptieren oder ablehnen?
• Kann das System fortbestehen, wenn alle etablierten Register verschwinden?

Autorenadresse

Lu
[TBD]