Das Primat des lauffähigen Codes: Der nötige Patch, um den ursprünglichen Entwurf des Internets zu bewahren

Jeder Teilnehmer kann selbst prüfen. Nach Lu Hengs Vorschlag hängt Gültigkeit von lokal überprüfbaren Regeln und tatsächlicher Nutzung ab, statt von der Genehmigung einer dauerhaft bestehenden Registrierungsstelle.

Die sieben vorausgehenden Heng.lu-Notizen dieser Reihe sind:

1. Notiz:52 Wenn die Macht der Registrierungsstellen sich von der Haftung löst: Warum das gegenwärtige RIR-Koordinationsmodell in seiner heutigen Form nicht überleben kann
2. Notiz:53 Internet-Nummernressourcen sind kein politisches Eigentum
3. Notiz:56 Wie die ausufernde Governance der Regional Internet Registries aus Eindeutigkeit doppelte Abschöpfung macht
4. Notiz:58 Von doppelter Abschöpfung zur Umkehrung der Souveränität: Wie Staaten für 100 US-Dollar ihre souveräne Kontrolle an RIRs verlieren
5. Notiz:59 Die Armutsstrafe: Wie das RIR-Modell die Armen besteuert und es Gleichheit nennt
6. Notiz:61 Verrat am lauffähigen Code: Wie das RIR-System den Konsens gegen die technische Gemeinschaft wendete
7. Notiz:62 Mandatswäsche: Von der RIR-Fantasie zur Übergangsarchitektur

Die vorausgehenden sieben Essays waren kein Reformprogramm für die Regional Internet Registries.

Sie waren eine Autopsie.

Sie verfolgten dieselbe institutionelle Pathologie durch verschiedene Schichten: Haftung, die von den Konsequenzen abgekoppelt wurde; Nummernressourcen, die zu politischem Eigentum umetikettiert wurden; Eindeutigkeit, die zur doppelten Abschöpfung wurde; Souveränität, die sich umkehrte; Armut, die im Namen der Gleichheit besteuert wurde; Konsens, der sich gegen die Netze wendete, denen er dienen sollte; und schließlich ein Mandat, das so lange gewaschen wurde, bis ein Sachbearbeiter wie ein Souverän zu sprechen begann. Diese Abfolge ist wichtig, denn das Versagen bestand nicht in einem schlechten Vorstand, einer schlechten Registrierungsstelle, einem Rechtsstreit oder einem unbequemen Marktereignis. Es war ein Systemfehler in wechselndem Gewand. Die Autorenseite von CircleID zeigt diese Abfolge inzwischen deutlich, einschließlich Verrat am lauffähigen Code und Mandatswäsche. (circleid.com)

In diesem Essay geht es nicht darum, die RIRs zu besseren Regenten zu machen.

Es geht darum, zu erklären, warum die gegenwärtige Registrierungsordnung nicht der Endpunkt sein kann und warum die am wenigsten disruptive Reparatur in einer Ergänzung des ursprünglichen technischen Entwurfs des Internets besteht.

Diese Ergänzung ist das Primat des lauffähigen Codes.

Dass wir sie brauchen, ist längst keine theoretische Frage mehr. In einem jüngsten Austausch auf CircleID hat John Curran die stärkste Fassung der Argumentation der etablierten Institutionen vorgetragen. Seiner Ansicht nach ist die Autorität des RIR-Systems nicht bloß ein Nebenprodukt eng begrenzter technischer Koordination, sondern das Ergebnis einer historischen Kette: des White Paper, von ICANN, der ASO, ICP-2, der Übertragung der IANA-Aufsicht und der fortgesetzten privatwirtschaftlichen Multistakeholder-Governance. Er erklärt, die Autorität des RIR-Systems ergebe sich daraus, dass es innerhalb des von der US-Regierung vorgegebenen privatwirtschaftlichen Multistakeholder-Modells arbeitet. (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 eine historisch delegierte Koordinationsfunktion sich später mithilfe derselben Verfahrensmaschinerie, die sie selbst kontrolliert, zu einem dauerhaften Governance-Mandat erweitern darf. Die Antwort der etablierten Institutionen lautet ja: Delegation, Anerkennung, institutionelle Kontinuität und Gemeinschaftsverfahren werden zu einem sich selbst erneuernden Mandat.

Die Antwort, die der ursprüngliche technische Entwurf des Internets verlangt, lautet nein.

Die ursprüngliche Internet-Tradition war enger gefasst, strenger und besser. RFC 3935 bezeichnet als Ziel der IETF, „das Internet besser funktionieren zu lassen“; es gründet ihre Arbeit auf technische Kompetenz, praktische Implementierung sowie „groben Konsens und lauffähigen Code“. Es erklärt außerdem, dass die IETF nicht versucht, Kontrolle über ein Protokoll oder eine Funktion auszuüben, für die sie nicht verantwortlich ist. (rfc-editor.org) RFC 7282 wiederholt David Clarks alten Satz: „Wir lehnen ab: Könige, Präsidenten und Abstimmungen“ und „Wir glauben an: groben Konsens und lauffähigen Code“. (rfc-editor.org) RFC 9592 formuliert die Absage an hoheitliche Autorität noch deutlicher: Die IETF betreibt, kontrolliert oder überwacht das Internet nicht und ist nicht „die Protokollpolizei“. (rfc-editor.org)

Diese Tradition bedeutete nie, dass Dokumente magische Kräfte hätten. Sie bedeutete, dass Dokumente dann zählten, wenn sie zum Funktionieren von Systemen beitrugen. Sie bedeutete, dass Verfahren geduldet wurden, weil sie der praktischen Einführung dienten. Sie bedeutete, dass eine Versammlung nur dann nützlich war, wenn sie sich selbst an der betrieblichen Realität ausrichtete.

Die Registrierungsschicht borgte sich diese Legitimität.

Die dazugehörige Disziplin akzeptierte sie nie vollständig.

Das ist der fehlende Patch.

Was das Primat des lauffähigen Codes bedeutet

Das Primat des lauffähigen Codes bedeutet, dass Internet-Koordinationssysteme eng ausgelegt werden müssen: nach Maßgabe jener technischen Mindestfunktion, die laufende Netze ursprünglich rechtfertigten.

Die Schicht der Nummernressourcen dient dem Schutz laufender Systeme: der Eindeutigkeit, der Interoperabilität, der Kontinuität im Umfeld des Routings, sicherheitsbezogener Aussagen, des Nachweises der Kontrolle sowie der minimalen gemeinsamen Semantik, die unabhängige Netze für ihr Zusammenwirken benötigen.

Sie ist nicht dazu da, politische Autorität zu erzeugen.

Sie ist nicht dazu da, über die Moral geschäftlichen Handelns zu wachen.

Sie ist nicht dazu da, aus dem geografischen Tätigkeitsgebiet einen Rechtstitel abzuleiten.

Sie ist nicht dazu da, eine Mailingliste in ein Parlament zu verwandeln.

Sie ist nicht dazu da, einer privaten Registrierungsstelle zu erlauben, bereits betriebene Netzressourcen verschwinden zu lassen, weil sich ihre interne Auslegung von Richtlinien ändert.

Eine Registrierungsstelle ist kein Staat.

Ein Datenbankkontakt ist keine Unternehmensvollmacht.

Eine Dienstleistungsregion ist kein Staatsvolk.

Ein Richtliniengremium ist kein Parlament.

Ein Registrierungseintrag kann betriebliche Realität beschreiben. Er erschafft sie nicht.

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

Die richtige Reihenfolge lautet: Anfangsspezifikation, Zustand des verteilten Ledgers, lokale Validierung, laufende Implementierung, freiwillige Übernahme, Kompatibilitätsgruppe, dann Dokumentation.

Die falsche Reihenfolge lautet: Richtliniengremium, Erklärung, behauptete Verpflichtung, Konformitätsetikett, erzwungene betriebliche Befolgung.

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

Die entscheidende Korrektur lautet: Nach der Anfangsspezifikation gibt es keine fortbestehende Institution, an die man Gesuche richten könnte. Kein Ausschuss entscheidet, ob die Nichtübernahme einen Verstoß darstellt. Keine Registrierungsstelle erklärt einen Teilnehmer allein deshalb für ungültig, weil er eine spätere Änderung ablehnt. Es gibt nur Code, Ledger-Zustand, Validierung, Übernahme, Kompatibilität, lokale Zurückweisung, Forks und selektive Interoperation.

Ein Betreiber, der eine spätere Änderung ablehnt, macht das Internet nicht kaputt. Er kann in einer älteren Kompatibilitätsgruppe bleiben. Er kann einen Fork bilden. Er kann seine Verbindung trennen. Er kann möglicherweise nicht mit Teilnehmern interoperieren, die inkompatible Regeln übernommen haben. Aber er kann die Interoperabilität anderer, die weiterhin miteinander kompatiblen Code betreiben, nicht zerstören.

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

Das ist der entscheidende Patch, der der Koordination von Nummernressourcen fehlt.

Der Entwurfsfehler war von Anfang an vorhanden

Der erste RIR-Entwurf ging von einer Welt aus, in der wenig Wert auf dem Spiel stand.

Nummernressourcen erschienen als technische, reichlich vorhandene, verwaltungsmäßige und konfliktarme Angelegenheit. In dieser Welt wirkte Informalität effizient. Offene Mailinglisten wirkten repräsentativ. Eine kontaktbasierte Verwaltung schien ausreichend. Verträge mit begrenzter Haftung erschienen harmlos. Eine regionale Registrierungsstelle konnte wie ein Adressbuch wirken.

Die IPv4-Knappheit zerstörte diese Prämisse.

IPv4-Adressen wurden knapp, übertragbar, finanzierbar, vermietet, kapitalisiert, Gegenstand von Rechtsstreitigkeiten und Sanktionen sowie Bestandteil laufender Netze. Die Registrierungsschicht saß nicht mehr über bloßen Verwaltungseinträgen. Sie saß über produktiver Infrastruktur. Sie saß über Vermögenswerten. Sie saß über der Versorgungskontinuität für Kunden, der Einführung von Cloud-Diensten, dem Telekommunikationsbetrieb, der nationalen Konnektivität, gerichtlichen Anordnungen und der Kapitalallokation.

Die institutionelle Form wurde angesichts dieses neuen Risikos nicht zurückgenommen.

Sie wurde ausgeweitet.

Das Ergebnis ist ein System, das weiterhin die Sprache technischer Koordination spricht, während es die Wirkungen einer Infrastruktur-Governance entfaltet. Es verlangt von Betreibern, Registrierungsverfahren als neutral zu behandeln, obwohl Entscheidungen der Registrierungsstellen ihr wirtschaftliches Schicksal beeinflussen. Es nennt seine Teilnehmer „Gemeinschaft“, obwohl viele derjenigen, die die Folgen tragen, den Menschen im jeweiligen Gremium nie eine eindeutige rechtliche Vertretungsbefugnis erteilt haben.

NRS benennt das strukturelle Problem klar: Internet-Nummernregister wurden als technische Koordinationsstellen entworfen. Doch als IPv4-Knappheit Adressen zu wertvollen Vermögensgegenständen machte, wurde der Ermessensspielraum der Registrierungsstellen zu wirtschaftlicher Macht. Wenn Koordinationssysteme Kapital kontrollieren, wird Zentralisierung zum strukturellen Risiko und Dezentralisierung zur Systemtechnik statt zur Ideologie. NRS benennt auch die entgegengesetzte Entwurfsrichtung: ein Internet, offene und autonome Infrastruktur sowie eine dezentrale Governance, deren Kern mit einem Minimum an menschlicher Mitwirkung auskommt. (nrs.help)

Das ist das eigentliche Problem. Die Registrierungsschicht wurde nie für den Augenblick nachgebessert, in dem aus einer Koordinationstabelle eine Zugangsschranke zu Vermögenswerten wurde.

Das Primat des lauffähigen Codes ist dieser Patch.

Es ist keine Doktrin für bessere RIRs.

Es ist eine Entwurfsdisziplin für die Zeit nach den RIRs.

Die drei Regeln des Patches

Die konstruktive Grundstruktur liefert die überarbeitete Notiz 64: Minimale Anfangsspezifikation, lokale Entscheidung über die Zukunft und freiwillige Übernahme für Internet-Koordinationssysteme: Minimale Anfangsspezifikation, Lokale Entscheidung über die Zukunft und Freiwillige Übernahme.

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

Minimale Anfangsspezifikation bedeutet, dass die gemeinsame Schicht ausschließlich deterministische, lokal überprüfbare Regeln enthält, die für Eindeutigkeit, Interoperabilität, den Nachweis der Kontrolle, gemeinsame Betriebssicherheit und Informationssicherheit erforderlich sind. Sie enthält keine Vorlieben für Geschäftsmodelle, keine Preistheorien, keine regionalpolitischen Stimmungen, keine Ermessensbefugnisse zur Durchsetzung und keine Ausweitung institutioneller Aufgaben.

Lokale Entscheidung über die Zukunft bedeutet nicht, dass eine Institution entscheidet, welche künftigen Entscheidungen lokal zu treffen sind. Damit wäre die Autoritätsschicht bereits wieder eingeführt. Es bedeutet, dass die Anfangsspezifikation die Begrenzung im Voraus leistet. Nach der Einführung bleiben gewöhnliche künftige Entscheidungen bei den Teilnehmern, die den Code betreiben. Ein Teilnehmer kann Änderungen übernehmen, ablehnen, einen Fork bilden, sich abkoppeln oder selektiv interoperieren. Kein Teilnehmer kann die Interoperabilität anderer verändern, die weiterhin miteinander kompatible Regeln ausführen.

Freiwillige Übernahme bedeutet, dass spätere Veränderungen erst durch Implementierung, Validierung, Einführung und Nutzung real werden. Veröffentlichung ist nicht Realität. Empfehlung ist nicht Realität. Anerkennung durch etablierte Institutionen ist nicht Realität. Die Nichtübernahme erzeugt keinen ungültigen Status. Ein Teilnehmer, der eine spätere Änderung nicht übernimmt, bleibt in seiner bestehenden Kompatibilitätsgruppe. Ein Teilnehmer, der einen Zustand ausgibt, der nach den deterministischen Regeln eines anderen Teilnehmers ungültig ist, kann von diesem lokal ignoriert werden. Die Wirkung besteht in der Auswahl von Kompatibilität, nicht in institutioneller Bestrafung.

Diese drei Regeln rehabilitieren keine Souveränität der Registrierungsstellen.

Sie verhindern, dass diese unter einem neuen Namen wiederkehrt.

APNIC: Die Rechtsstruktur war das Risiko

APNIC zeigt das erste Versagen: Das Minimum wurde zu Beginn nie streng genug spezifiziert.

Hier geht es nicht um einen Verhaltenskodex. Es geht nicht um Etikette. Es geht nicht darum, ob ein Kritiker gegenüber einer etablierten Institution höflich genug war.

Es geht um die Rechtsstruktur.

Im März 2023 veröffentlichte LARUS eine rechtliche Prüfung, die davor warnte, dass APNICs Governance-Struktur nicht bloß für ein Unternehmen in Brisbane Risiken schuf, sondern für die Internet-Governance im gesamten asiatisch-pazifischen Raum. Die Prüfung erklärte, APNICs Generaldirektor habe letztlich die rechtliche Befugnis, APNIC zu schließen und den gewählten Executive Council abzusetzen, und dringende Änderungen der Governance seien erforderlich. Sie erklärte außerdem, die Struktur werfe Fragen zur Sicherheit der Internet-Governance für mehr als eine Milliarde Internetnutzer im asiatisch-pazifischen Raum auf. (larus.net)

Der erste Anhang, der ASIC-Unternehmensregisterauszug, liefert die gesellschaftsrechtliche Ausgangslage. APNIC Pty Ltd war als australische Gesellschaft in privater Hand mit Aktienkapital und beschränkter Gesellschafterhaftung aufgeführt, registriert in Queensland. Paul Byron Wilson war als Director und Company Secretary eingetragen. Die Angaben zum Aktienkapital zeigten eine einzige ausgegebene Stammaktie; Paul Byron Wilson war als Gesellschafter aufgeführt, der diese Aktie hielt. (larus.net)

Das ist keine normale Konstruktion für eine kritische regionale Funktion der Internet-Koordination.

Der zweite Anhang, das Rechtsgutachten von Dr. Peter Felter, zog daraus die Governance-Schlussfolgerung. Es beschrieb die öffentlich sichtbare APNIC-Struktur — Mitglieder, Wahlen, Executive Council, Generaldirektor und Sekretariat — als Sonderausschuss auf Grundlage von Artikel 9.3 der Satzung von APNIC Pty Ltd. Es erklärte, APNIC Pty Ltd sei seit 25 Jahren eine private Gesellschaft gewesen, die über einen einzigen Director, einen einzigen Aktionär und einen einzigen Company Secretary kontrolliert worden sei — sämtlich dieselbe Person. (larus.net)

Diese Unterscheidung ist entscheidend.

Die öffentlich an die Gemeinschaft gerichtete Institution war nicht die letztentscheidende rechtliche Trägerstruktur. Sie war ein Gebilde auf dem Fundament einer privaten Unternehmensstruktur.

Das Rechtsgutachten erläuterte anschließend, warum diese Unterscheidung wichtig ist. APNICs interne Statuten standen demnach unter dem Vorbehalt der Gesellschaftssatzung und der Befugnisse der Gesellschaft sowie ihrer Directors, leitenden Funktionsträger und Gesellschafter. Nach dieser Lesart konnte die öffentliche APNIC-Struktur durch einen Director-Beschluss von APNIC Pty Ltd geändert werden; das Gutachten beschrieb APNIC faktisch als Abteilung von APNIC Pty Ltd. (larus.net)

Der schwerwiegendste Punkt des Gutachtens war nicht, dass APNIC im streng rechtlichen Sinne illegal gewesen sei. Er war, dass Rechtmäßigkeit und Angemessenheit nicht dasselbe sind. Das Gutachten argumentierte, die Treuhandkonstruktion löse das Problem nicht, weil die Befugnisse des Executive Council weiterhin aus dem Director-Beschluss zur Einrichtung des Sonderausschusses hervorgingen. Es stellte außerdem fest, dass APNIC Pty Ltd eine private Aktiengesellschaft war, deren Struktur und Gesellschaftszwecke nicht dem gemeinnützigen Modell ohne Aktienkapital entsprachen, das die meisten Menschen mit einer regionalen Registrierungsstelle im öffentlichen Interesse verbinden würden. (larus.net)

Das ist der erste Entwurfsfehler in seiner reinsten Form.

Ein Nummernkoordinationssystem für eine ganze Weltregion sollte nicht von einer Struktur abhängen, bei der Juristen erklären müssen, warum eine private Gesellschaft mit einer einzigen Aktie, ein Sonderausschuss, eine Treuhandurkunde und ein gewählter Rat irgendwie zusammen eine legitime Kontrolle über das Nummernregister des asiatisch-pazifischen Raums ergeben.

Eine kritische Koordinationsschicht sollte von außen verständlich sein.

Sie sollte kein Vertrauen in Dokumente hinter anderen Dokumenten verlangen.

Sie sollte nicht verlangen, dass Mitglieder nach Jahren institutioneller Abhängigkeit entdecken, dass die gewählte Ebene möglicherweise nicht die letztentscheidende rechtliche Ebene ist.

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

Deshalb muss die minimale Anfangsspezifikation eine verteilte Grundlage der Gültigkeit vorsehen, statt auf Vertrauen in Institutionen zu setzen. Nicht, weil eine künftige Institution bessere Governance braucht. Sondern weil ein künftiges System nach den RIRs so gestaltet sein muss, dass es diese Institution überhaupt nicht benötigt.

Die gemeinsame Schicht sollte nicht von der verborgenen Kontrollstruktur einer privaten Gesellschaft abhängen. Sie sollte deterministische Validierungsregeln, Zustände zum Nachweis der Kontrolle, Zustandsübergangsregeln, Konfliktregeln, Ledger-Replikation, Ausstiegswege, Fork-Wege und Kompatibilitätsgruppen definieren. Wenn APNIC verschwindet, sich selbst vereinnahmt, seine rechtliche Position verändert oder die Anerkennung eines gültigen Zustands verweigert, sollte das laufende Netz nicht auf die fortgesetzte Anerkennung durch APNIC angewiesen sein, um zu wissen, wer welche Nummernressourcen kontrolliert.

Die Registrierungsstelle sollte nicht die Quelle der Gültigkeit sein.

Diese Quelle sollte der nach der Anfangsspezifikation validierte Zustand des verteilten Ledgers sein.

ARIN: Richtlinien trafen auf die Realität von Vermögenswerten

ARIN zeigt das zweite Versagen: Rechtliche und wirtschaftliche Realität können der Theorie einer Registrierungsstelle davonlaufen.

Das entscheidende Ereignis war die Transaktion zwischen Nortel und Microsoft. Als Nortel Insolvenz anmeldete, wurden seine 666.624 IPv4-Adressen zu wertvollen Vermögensgegenständen im Verfahren. Die Adressen wurden für 7,5 Millionen US-Dollar an Microsoft verkauft. ARIN intervenierte mit der Begründung, die Adressen seien kein Eigentum und könnten nicht frei von Bindungen an die Richtlinien der Registrierungsstelle verkauft werden. Industry Canada unterstützte diese Auffassung. Das Insolvenzgericht wies sie zurück; Microsoft unterzeichnete später eine Vereinbarung über Altbestände. Das praktische Ergebnis war eindeutig: Registrierungsrichtlinien konnten nicht länger die einzige Quelle der Realität bleiben, sobald Gerichte und Märkte Nummernressourcen als Vermögenswerte behandelten. (btw.media)

Die wichtige Lehre ist nicht, dass ARIN auf einzigartige Weise mangelhaft war.

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

Ein Registrierungseintrag ist wertvoll, weil Betreiber, Gerichte, Käufer, Verkäufer, Gläubiger und Netze sich darauf verlassen. Er erlangt keine Autorität, indem er diese Abhängigkeit leugnet. Er bleibt nur dann nützlich, wenn er die rechtliche, wirtschaftliche und betriebliche Realität genau genug abbildet, um vertrauenswürdig zu sein.

Mit der IPv4-Knappheit wurden Registrierungsverfahren zu einer Marktschnittstelle. Übertragungsregeln, Bedarfsprüfungen, Verzögerungen bei der Anerkennung und regionale Beschränkungen waren keine bloßen Verwaltungsdetails mehr. Sie wurden zu Hemmnissen beim Umgang mit Vermögenswerten. Öffentliche Analysen beschreiben inzwischen ein fragmentiertes RIR-Regelwerk, in dem fünf regionale Systeme einen Markt bestimmen, auf dem Adressen für etwa 18 bis 45 US-Dollar gehandelt werden. Widersprüchliche Regeln können Vermögenswerte blockieren, Fusionen verzögern und allein für das Halten von Adressblöcken separate Unternehmensstrukturen erzwingen. (btw.media)

Das ist keine neutrale Koordination.

Es ist regulatorische Wirkung ohne regulatorische Rechenschaftspflicht.

ARIN zeigt, warum freiwillige Übernahme wichtig ist. Registrierungsrichtlinien bleiben nur glaubwürdig, solange sie beschreiben, was Akteure tatsächlich implementieren, handeln, finanzieren, gerichtlich austragen und worauf sie sich verlassen. Sie werden gefährlich, sobald Veröffentlichung als ausreichend gilt, um Realität zu erzeugen.

Eine Registrierungsstelle, die sich der Realität verweigert, wird dadurch nicht zum Souverän.

Sie wird zu einer veralteten Datenbank.

In einem Entwurf nach dem Primat des lauffähigen Codes ist die Lehre noch schärfer. Gerichte und Märkte brauchen keine etablierte Registrierungsstelle, die entscheidet, ob ein Wert existiert. Betreiber brauchen keinen Ausschuss, um zu wissen, ob ein Adressblock geroutet wird. Teilnehmer brauchen deterministische Regeln, die den Nachweis der Kontrolle, Konfliktlösung, im Ledger sichtbare Zustandsübergänge und Kompatibilität ermöglichen. Die alte Registrierungsstelle kann eine Sicht veröffentlichen. Ein Software-Client kann eine Sicht anzeigen. Ein Ledger-Explorer kann eine Sicht anzeigen. Keine dieser Instanzen ist die Quelle der Gültigkeit.

Es gibt keine Registrierungsstelle, zu der man wechseln könnte.

Es gibt keine Registrierungsstelle, die man fragen könnte.

Es gibt nur einen verteilten Zustand, den Teilnehmer validieren, akzeptieren, zurückweisen, von dem sie sich durch einen Fork abspalten oder mit dem sie interoperieren.

AFRINIC: Als Registrierungstheorie Ressourcen im laufenden Betrieb bedrohte

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

Die falsche Erzählung lautet, ein lästiges Mitglied habe eine regionale Registrierungsstelle lahmgelegt.

Das ist das Moralstück der etablierten Institution.

Die strukturelle Geschichte ist eine andere. AFRINIC versuchte, kommerzielle Nutzung, den Standort von Kunden, Vermietung, Mitgliedschaft und interne Richtlinienauslegung in eine behauptete Befugnis umzuwandeln, bereits betriebene Nummernressourcen aus dem Register zu löschen. Sobald dieser Anspruch erhoben war, konnte der Konflikt nicht länger eine Meinungsverschiedenheit in einem Richtliniengremium bleiben. Er wurde zur Prüfung der Frage, ob eine private Registrierungsstelle regionale Rhetorik und das Schweigen von Richtlinien nutzen darf, um betrieblich eingebundene Vermögenswerte zu bedrohen.

Die Fakten brauchen keine dramatische Überhöhung. Öffentliche Berichte beschrieben den AFRINIC-Streit als einfachen geschäftlichen Streit über IP-Adressen, der zur größten Geschichte der Internet-Governance in Afrika wurde. Sie berichteten auch, Cloud Innovation sei häufig als Bösewicht dargestellt worden, während späteres Dokumentenmaterial auf zerstörerische Kräfte innerhalb von AFRINIC selbst und darauf hinwies, dass AFRINIC-Vertreter Rechtsstreitigkeiten auf Kosten von AFRINIC verzögerten, verlängerten und fortführten. (btw.media)

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

Die Rechtsstreitigkeiten haben das strukturelle Versagen nicht geschaffen.

Sie haben es offengelegt.

Das maßgebliche Versagen war bereits vorhanden, als eine private Registrierungsstelle das Fehlen einer ausdrücklichen Erlaubnis zur Grundlage zwangsausübender Kontrolle machte. Vermietung bedrohte die Eindeutigkeit nicht. Der Standort eines Kunden war keine doppelte Zuweisung. Kommerzielle Nutzung war kein Versagen der Routing-Sicherheit. Ein Geschäftsmodell, das einer Registrierungsstelle missfiel, war keine globale Invariante.

Dennoch stellte der Anspruch der Registrierungsstelle diese Fragen in einen Rahmen des Entzugs.

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

Berichte halten fest, dass AFRINIC Cloud Innovation im März 2021 ein Schreiben sandte, in dem es Richtlinienverstöße behauptete und mit der Beendigung der Mitgliedschaft drohte; dass der Supreme Court von Mauritius AFRINIC im Juli 2021 untersagte, Cloud Innovations Mitgliedschaft zu beenden; und dass ein weiterer Versuch AFRINICs, die Mitgliedschaft aufzuheben, im Dezember 2021 blockiert wurde. (btw.media) Diese Abfolge erzählt nicht von einer Registrierungsstelle, die besonnen das Internet schützt. Sie erzählt davon, wie die Autorität einer Registrierungsstelle auf das gewöhnliche Recht trifft.

Auch der umfassendere institutionelle Zusammenbruch wurde nicht durch zu wenig Macht der Registrierungsstelle verursacht. Das tiefere Problem war die Bindung ohne Ausweichmöglichkeit. Wenn eine einzige Registrierungsstelle das Anerkennungsmonopol über wertvolle Ressourcen im laufenden Betrieb hält, wird jedes interne Versagen zum Risiko für die Kontinuität des Internets. Wenn Mitglieder das Anerkennungssystem nicht verlassen können, wird das Versagen der Registrierungsstelle zur Macht, sie als Geiseln zu halten.

Eine Registrierungsstelle darf nachweisbaren Registrierungsbetrug in ihren eigenen Einträgen berichtigen.

Sie darf doppelte Zuweisungen verhindern, solange das Registrierungsmodell noch besteht.

Sie darf sicherheitsbezogene Aussagen pflegen, solange Teilnehmer noch auf sie vertrauen.

Doch das sind Übergangsfunktionen einer alten Architektur.

In einer Architektur nach den RIRs werden diese Funktionen nicht von einer Registrierungsstelle erfüllt. Sie sind im Zustand eines verteilten Ledgers, in Regeln zum Nachweis der Kontrolle, in Konfliktregeln und in lokal überprüfbaren Übergängen kodiert.

Eine private Körperschaft sollte Vermietung nicht in Verrat an der Region umdeuten.

Sie sollte den Standort von Kunden nicht zum Auslöser eines Entzugs machen.

Sie sollte eine geschäftliche Meinungsverschiedenheit nicht als technische Ungültigkeit behandeln.

Sie sollte die Kontinuität von Vermögenswerten nicht von einer Erlaubnis abhängig machen.

AFRINIC zeigt die Notwendigkeit einer richtig verstandenen lokalen Entscheidung über die Zukunft. Es gibt kein zentrales Gremium, das entscheidet, eine künftige geschäftliche Entscheidung „gehöre auf die lokale Ebene“. Vielmehr muss die Anfangsspezifikation dafür sorgen, dass solche Entscheidungen gar nicht erst in die gemeinsame Schicht gelangen. Vermietung, Kundenstandorte, kommerzielle Nutzung, Preisgestaltung, Finanzierung, Kundenmix und Einführungsstrategie bleiben außerhalb deterministischer Gültigkeitsregeln, sofern sie nicht unmittelbar Eindeutigkeit, Sicherheit, den Nachweis der Kontrolle oder Interoperabilität betreffen.

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

Ein Betreiber kann die Interoperabilität anderer Betreiber nicht dadurch zerstören, dass er Kunden außerhalb einer historischen Registrierungsregion bedient.

Ein Betreiber kann die Interoperabilität anderer Betreiber nicht dadurch zerstören, dass er ein Geschäftsmodell nutzt, das einer Registrierungsstelle missfällt.

Allenfalls kann ein Betreiber deterministische Regeln nicht erfüllen, die andere Teilnehmer ausführen. In diesem Fall weisen die anderen Teilnehmer den ungültigen Zustand lokal zurück. Es gibt keine Bestrafungsschicht. Es gibt kein Konformitätsgericht. Es gibt keinen regionalen Souverän.

Diese Grenze ist nicht ideologisch.

Sie ist betrieblich begründet.

Das Vollmachtsproblem ist keine Nebensache

Die Kontroverse um die AFRINIC-Wahl machte einen zweiten Defekt sichtbar: die Vertretung.

NRS benennt die Grundlage seiner Vertretungsbefugnis in unmittelbar rechtlichen Begriffen. Es erklärt, die aufgeführten Mitglieder hätten NRS damit beauftragt, sie in Fragen der RIR-Governance zu vertreten, und jedes aufgeführte Mitglied habe eine Vollmacht erteilt. (nrs.help) Während des Streits um die AFRINIC-Wahl bat NRS Mitglieder, sich zu melden, wenn ihre Namen in Wählerverzeichnissen auftauchten oder Stimmen ohne ihre Mitwirkung erfasst worden seien, und erklärte, solche Tatsachenmeldungen würden auf rechtmäßigen Wegen behandelt. (nrs.help)

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

Das RIR-System wirft häufig mehrere Kategorien in einen Topf: Unternehmensvertreter, Datenbankkontakt, technischer Kontakt, Mitarbeiter, Berater, Bevollmächtigter, Teilnehmer an Richtlinienverfahren, regelmäßiger Mailinglisten-Beitragender. Das ist nicht dasselbe.

Ein Datenbankkontakt kann bei der Verwaltung von Einträgen helfen.

Eine Vollmacht kann zur Vertretung berechtigen, sofern sie gültig ist und im Rahmen ihres Umfangs ausgeübt wird.

Ein Teilnehmer an einem Richtlinienverfahren kann Fachwissen beitragen.

Ein Sprecher auf einer Mailingliste kann eine Meinung äußern.

Niemand in einer dieser Rollen wird dadurch automatisch selbst zum rechtlichen Auftraggeber für jedes Unternehmen, jeden Kunden, Staat, Gläubiger, Kreditgeber, Käufer, Mieter oder jedes Netz, das die Folgen einer Registrierungsentscheidung trägt.

Diese Unterscheidung lässt sich nur ignorieren, solange die gemeinsame Schicht schlank bleibt. Sobald die Registrierungsstelle Macht über Entzug, Übertragung, Vermietung, Marktzugang, den Umgang mit Sanktionen, Vermögenskontinuität oder Risiken für nationale Infrastruktur beansprucht, wird Vertretung zu einer Frage von verfassungsrechtlicher Tragweite.

Eine Versammlung ist kein Mandat.

Eine Mailingliste ist kein Staatsvolk.

Ein Kontakteintrag ist keine Unternehmensvollmacht.

Eine Dienstleistungsregion ist keine souveräne Wählerschaft.

Das ist keine pedantische Verfahrensstrenge.

Es ist der Unterschied zwischen Koordination und Herrschaft.

Ein System nach dem Primat des lauffähigen Codes vermeidet diese Falle, indem es die Zahl der Entscheidungen verringert, die überhaupt Vertretung erfordern. Wenn Gültigkeit deterministisch und lokal ist, gibt es weniger, worüber abgestimmt werden muss. Wenn künftige Veränderungen freiwillig sind, muss niemand entscheiden, ob ein Teilnehmer durch Nichtübernahme einen beanstandeten Status erhält. Wenn der Zustand in einem verteilten Ledger abgebildet wird, muss niemand eine etablierte Registrierungsstelle darum anbetteln, seine fortgesetzte Existenz anzuerkennen. Wenn Kompatibilitätsgruppen ausdrücklich ausgewiesen sind, wissen Teilnehmer, mit wem sie interoperieren können, ohne ein politisches Gremium fragen zu müssen.

Das beste Governance-Problem ist jenes, das der Systementwurf beseitigt.

RIPE NCC und LACNIC: Der Club und der Engpass

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

Der Club entscheidet, wer als respektabel gilt. Der Engpass entscheidet, wessen Registrierungsstatus sich verändern kann.

RIPE NCCs Weigerung, LARUS als Sponsor für RIPE 90 zu akzeptieren, machte die Clubschicht deutlich sichtbar. Ein Mitglied bot Sponsoring an. Das Umfeld der Registrierungsstelle lehnte es wegen eines nicht damit zusammenhängenden Streits in einer anderen Region ab. Das war keine Entscheidung zur Routing-Sicherheit. Es war keine Entscheidung zur Eindeutigkeit. Es war keine deterministische Validierungsregel. Es war private Ausgrenzung über den Zugang zu einer Konferenz. Auch LACNIC lehnte mein Sponsoring ab. Andere Region, derselbe Instinkt: Der Registrierungsclub schützt sich selbst, indem er Räume, Sichtbarkeit, Sponsoring, Reputation und gesellschaftliche Legitimität kontrolliert.

Das ist keine Gemeinschaft. Das ist Zugangskontrolle.

Die Sanktionsschicht ist noch schlimmer, weil sie den zentralen Engpass in rechtlicher Form zeigt. RIPE NCC erklärt, es müsse als in den Niederlanden ansässige Organisation EU-Sanktionen einhalten; wenn Sanktionen greifen, friere es die Registrierung in der RIPE-Datenbank ein, blockiere Erwerb und Übertragung und könne Fälle als eingefroren behandeln, wenn eine Partei keine hinreichenden Nachweise vorlegen könne. Es prüft außerdem OFAC-Listen, weil Bankbeziehungen Zahlungen beeinflussen. (RIPE NCC: Transparenz zu Sanktionen)

Das ist keine Kritik an RIPE NCC dafür, dass es das Gesetz befolgt. Eine niederländische Körperschaft muss niederländisches Recht und EU-Recht einhalten. Das Problem ist die Architektur: Warum sollte eine einzige niederländische private Körperschaft der zentrale Anerkennungspunkt für die Übertragbarkeit von Nummernressourcen über viele Länder, Betreiber und Rechtsordnungen hinweg sein?

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

Das ist der Entwurfsfehler.

Dieselbe zentrale Stellung, die es einem Club ermöglicht, einen Kritiker auszuschließen, ermöglicht es auch einer Rechtsordnung, Veränderungen im Register einzufrieren. Das eine ist soziale Durchsetzung. Das andere ist rechtliche Durchsetzung. Beides funktioniert nur, weil die Registrierungsstelle an einer Stelle sitzt, an der Gültigkeit nicht angesiedelt sein sollte.

Das führt unmittelbar zu den drei Prinzipien.

Minimale Anfangsspezifikation: Respektabilität im Club, Sponsoringberechtigung, Regionalpolitik, Sanktionsklassifizierung und Reputation dürfen niemals in die gemeinsame Schicht gelangen. Diese sollte ausschließlich deterministische Regeln für Eindeutigkeit, den Nachweis der Kontrolle, Konfliktbehandlung, Zustandsübergänge und Sicherheit enthalten.

Lokale Entscheidung über die Zukunft: Rechtliche Risiken, die Wahl von Gegenparteien, Sponsoring, geschäftliches Vertrauen und die Betroffenheit von Sanktionen gehören zu den Akteuren, die sie tragen. Eine niederländische Körperschaft darf eine Transaktion ablehnen. Eine Bank darf eine Zahlung ablehnen. Eine Gegenpartei darf eine Geschäftsbeziehung ablehnen. Nichts davon sollte zur universellen Registrierungswahrheit werden.

Freiwillige Übernahme: Teilnehmer akzeptieren Gegenparteien, indem sie Code betreiben, 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 keinen gültigen Zustand auslöschen. Eine Sanktionspflicht sollte den ihr unterliegenden Akteur beschränken, nicht das weltweite Ledger der Nummernressourcen umschreiben.

Deshalb ist ein Entwurf mit verteiltem Ledger notwendig. In einem System nach den RIRs wird gewöhnliche Gültigkeit nicht von RIPE NCC, LACNIC, einer Sanktionsabteilung, einem Tagungsausschuss oder einem Sponsoringbüro entschieden. Teilnehmer validieren Zustände lokal. Gegenparteien akzeptieren oder lehnen freiwillig ab. Forks sind sichtbar. Kompatibilitätsgruppen sind ausdrücklich ausgewiesen. Das zentrale Register verschwindet als Quelle der Wahrheit.

Die Lösung ist nicht bessere Etikette.

Die Lösung ist nicht eine transparentere Warteschlange für Sanktionsfälle.

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

Verteilter Zustand. Lokale Validierung. Freiwillige Akzeptanz von Gegenparteien. Keine Registrierungsstelle als Quelle der Gültigkeit.

Der NRO-Brief: Die Flucht nach oben

Der schwerwiegendste Beleg ist nicht AFRINICs Versuch, seine Befugnisse zu überschreiten.

Es ist die gemeinsame Reaktion des Systems.

2022 schrieb die Number Resource Organization an die Regierung von Mauritius. Der Brief beschrieb die NRO als Koordinierungsorgan der weltweiten RIRs und erklärte, die RIRs verwalteten Nummernressourcen in ihren jeweiligen Regionen. Er stellte fest, alle fünf Registrierungsstellen erfüllten die Funktion der Verwaltung von Nummernressourcen nach regional verabschiedeten Regeln oder einstimmig angenommenen globalen Richtlinien. (nro.net)

Derselbe Brief kritisierte Cloud Innovations Prozessführung, erklärte, es seien mehr als 25 Klagen eingereicht worden, beklagte gerichtliche Anordnungen, die AFRINICs Konten eingefroren und Wahlen gestoppt hätten, und stellte fest, AFRINIC habe Mauritius wiederholt um Anerkennung als internationale Organisation gebeten. Die NRO drängte die Regierung, Schritte zum Erhalt von AFRINICs Unabhängigkeit und der Internet-Stabilität in Afrika zu unternehmen. (nro.net)

Das ist das aufschlussreichste Dokument der gesamten Geschichte.

Als eine private Registrierungsstelle mit gewöhnlichen Gerichten kollidierte, bestand der Reflex des Systems nicht darin, das Mandat einzugrenzen.

Er bestand nicht darin, die Bindung an die Registrierungsstelle ohne Ausweichmöglichkeit zu beseitigen.

Er bestand nicht darin, Registerführung von Durchsetzung zu trennen.

Er bestand nicht darin, verteilte Validierung zu definieren.

Er bestand nicht darin, zu fragen, ob die einseitige Befugnis zur Löschung laufender Ressourcen aus dem Register von Anfang an illegitim gewesen war.

Der Reflex war die Flucht nach oben.

Eine private Koordinationsstelle kann nicht technisch sein, wenn sie Ermessensspielraum will; gemeinschaftsbasiert, wenn sie Legitimität will; vertraglich, wenn sie Gebühren will; auf dem Nicht-Eigentumscharakter beharren, wenn sie Eigentümerhaftung vermeiden will; und quasi-international, wenn sie Abschirmung vor Gerichten will.

Dieses Gesamtpaket ist keine Governance.

Es ist Mandatswäsche auf Systemebene.

Wenn RIRs öffentlich-rechtliche Privilegien wollen, müssen sie öffentlich-rechtliche Rechenschaftspflicht akzeptieren. Wenn sie privatrechtliche Flexibilität wollen, müssen sie privatrechtliche Rechtsstreitigkeiten akzeptieren. Was sie vernünftigerweise nicht zugleich verlangen können, sind privater Ermessensspielraum, Bedeutung als öffentliche Infrastruktur, geringe Haftung, schwache Vertretung, Monopolstatus und quasi-diplomatische Abschirmung.

Das ist der Weg in die Katastrophe.

Das Primat des lauffähigen Codes weist ihn zurück.

Wenn eine Registrierungsstelle auf rechtlichen Widerstand trifft, darf sie nicht nach oben in die Immunität fliehen. Die Architektur muss nach unten auf die eng begrenzte Funktion des lauffähigen Codes zurückgeführt werden, die sie rechtfertigte.

Weniger Souveränität.

Keine Registrierungsstelle als Quelle der Gültigkeit.

Weniger Durchsetzung.

Mehr verteilte Validierung.

Eine Überarbeitung von ICP-2 reicht nicht aus

Das gegenwärtige System weiß, dass etwas kaputtgegangen ist.

ICANNs Seite zur öffentlichen Kommentierung des zweiten Entwurfs des RIR-Governance-Dokuments erklärt, der Vorschlag solle Regeln und Kriterien für die Anerkennung neuer RIRs, betriebliche Pflichten und Anforderungen an RIRs sowie Regeln zum Entzug der Anerkennung festlegen; werde er angenommen, ersetze er ICP-2. Dieselbe Seite erklärt, das Verfahren sei eingeleitet worden, nachdem die NRO die ASO aufgefordert habe, Aktualisierungen vorzuschlagen, die dem RIR-System eine stärkere Rechenschaftspflicht gegenüber der Internet-Gemeinschaft auferlegen. (icann.org)

Das mag als Maßnahme zur Sicherung der Kontinuität notwendig sein.

Als Theorie der Legitimität reicht es nicht aus.

Regeln zur Anerkennung und zum Entzug der Anerkennung beantworten eine spät ansetzende Frage: Wann hat eine Registrierungsstelle so schwer versagt, dass sie entfernt werden muss?

Die vorgelagerte Frage ist wichtiger: Warum sollte eine Registrierungsstelle überhaupt mächtig genug sein, um katastrophal versagen zu können?

Ein Nachfolger von ICP-2, der lediglich Anerkennung, Prüfung, Übergabe und Anerkennungsentzug verschärft, kann die institutionelle Hygiene verbessern und zugleich den Kategorienfehler bewahren. Er setzt weiterhin voraus, dass die RIR die primäre souveräne Form der Koordination von Nummernressourcen ist.

Das Primat des lauffähigen Codes stellt andere Fragen.

Wie funktioniert das Internet weiter, wenn eine RIR zusammenbricht?

Wie bleiben Ansprüche auf Nummernressourcen ohne Genehmigung der etablierten Institution überprüfbar?

Wie bleibt Eindeutigkeit ohne monopolistischen Ermessensspielraum erhalten?

Wie verhindert man, dass Einträge zu Durchsetzungswaffen werden?

Wie bleiben geschäftliche Entscheidungen außerhalb deterministischer Gültigkeit, solange keine echte globale Invariante gefährdet ist?

Wie bleibt Koordination ganz ohne maßgebliche Registrierungsstelle nutzbar?

Wie validiert ein Betreiber gewöhnliche Zustände, ohne eine dauerhafte Körperschaft nach seinem Status fragen zu müssen?

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

Das sind keine Reformfragen.

Es sind Fragen für die Zeit nach den RIRs.

Warum dies der Patch für den ursprünglichen Entwurf ist

Es geht nicht darum, ob man die etablierten Registrierungsstellen mag oder nicht.

Es geht darum, ob die Schicht der Nummernressourcen noch jener Entwurfsdisziplin folgt, die das Internet zum Funktionieren brachte: minimale gemeinsame Regeln, lokale Validierung, freiwillige Übernahme und lauffähiger Code.

Das Primat des lauffähigen Codes ist weder eine PR-Strategie noch ein institutioneller Kompromiss. Es ist die technische Reparatur, die sich aus dem ursprünglichen Entwurf ergibt. Wenn das Internet darauf angelegt war, Könige, Präsidenten und Abstimmungen als Quellen technischer Wahrheit zurückzuweisen, darf die Schicht der Nummernressourcen diese Formen nicht durch Registrierungsverfahren, historische Delegation oder Gemeinschaftstheater wiederherstellen.

Konsens allein kann zum Ritual werden. Lauffähiger Code allein kann untergeordnet werden, wenn die Registrierungsschicht der Anerkennung vorgelagert ist. Die fehlende Regel betrifft Auslegung und Architektur: Wo institutionelle Verfahren mit der technischen Mindestfunktion in Konflikt geraten, die laufende Systeme benötigen, hat lauffähiger Code Vorrang; und wo spätere Änderungen vorgeschlagen werden, werden sie erst durch freiwillige Übernahme durch Teilnehmer real, die Validierungsregeln ausführen.

So wird der ursprüngliche Entwurf bewahrt, nicht aufgegeben.

Das Internet war deshalb von Bedeutung, weil es zum ersten globalen Kommunikationssystem wurde, das keine vorherige Erlaubnis eines einzelnen Souveräns, Ministeriums, einer Kirche, eines Unternehmens oder eines Zugangswächters erforderte. Wenn diese Errungenschaft weiterhin verteidigenswert ist, darf die Registrierungsschicht nicht zur Ausnahme werden, die die Regel verschlingt.

Ein System, das Könige vermeiden soll, darf nicht zulassen, dass ein Buchhalter für diese Rolle vorspricht.

Der Patch stellt die ursprüngliche Rangfolge wieder her: zuerst Code, zuerst Betreiber, zuerst deterministische Validierung, zuerst verteilter Zustand; Institutionen, sofern während des Übergangs überhaupt welche verbleiben, nur als nicht maßgebliche Artefakte, niemals als Quellen der Gültigkeit.

Was Koordination nach den RIRs erfordert

Koordination nach den RIRs bedeutet kein Chaos.

Sie bedeutet, dass die gemeinsame Schicht schlanker, objektiver, deterministischer und stärker verteilt wird als das gegenwärtige RIR-Monopol.

Es gibt keine Registrierungsstelle, zu der man wechseln könnte.

Es gibt keine neue Registrierungsstelle, die man krönen könnte.

Es gibt keine Ersatzpriesterschaft.

Es gibt ein verteiltes Ledger des Zustands von Nummernressourcen, mit deterministischen Validierungsregeln, Mechanismen zum Nachweis der Kontrolle, Konfliktbehandlung, Kompatibilitätsgruppen, einer Historie der Zustandsübergänge und lokaler Überprüfung durch die Teilnehmer.

Die gemeinsame Schicht sollte die Eindeutigkeit von Kennungen, den Nachweis der Kontrolle, Übertragungszustände, Delegationszustände, sicherheitsbezogene Aussagen im Umfeld des Routings, Prüfbarkeit, Konfliktmetadaten und die Sichtbarkeit von Forks bewahren.

Die Betreiberschicht sollte kommerzielle Nutzung, Vermietung, Kundenstandorte, Routing-Praxis, Finanzierung, die Auswahl von Gegenparteien und geschäftliche Regeln kontrollieren, die keine Invarianten sind.

Die Übernahmeschicht sollte bestimmen, was real wird. Eine Koordinationsregel zählt nur dann, wenn Betreiber sie implementieren, Gegenparteien sie akzeptieren, Märkte sich darauf verlassen, Gerichte sie verstehen können und die Interoperabilität erhalten bleibt, ohne die Anerkennung durch eine etablierte Institution zur einzigen Quelle der Realität zu machen.

Die Durchsetzungsschicht darf nicht mit der Zustandsschicht verschmolzen werden. Ein verteiltes Ledger kann Zustände erfassen. Es kann Übergänge validieren. Es kann Konflikte offenlegen. Es kann Nachweise portabel machen. Es darf nicht zugleich Ankläger, Richter, Sanktionsbehörde, Marktregulierer, Geschäftsmoralist und Vermögensverwahrer werden.

Vor allem muss Portabilität richtig verstanden werden.

In einer Welt verteilter Ledger bedeutet Portabilität nicht, von einer Registrierungsstelle zu einer anderen zu wechseln. Das ist noch immer Registrierungsdenken. Es gibt keine Registrierungsstelle, zu der man wechseln könnte. Der Kontrollnachweis, die Zustandshistorie und die Übertragungsfähigkeit des Inhabers sind nicht in der Datenbank einer etablierten Institution gefangen. Sie bestehen in einem gemeinsamen überprüfbaren Zustand, den Teilnehmer lokal validieren und Gegenparteien freiwillig akzeptieren.

Ohne das ist jede Registrierungsstelle ein Punkt, an dem Abhängigkeit ohne Ausweichmöglichkeit entsteht.

Mit ihm verschwindet die Registrierungsstelle als Quelle der Gültigkeit.

Koordination nach den RIRs braucht deshalb vier Entwurfseigenschaften.

Erstens: deterministische Gültigkeit. Ein Teilnehmer sollte durch lokale Anwendung der Spezifikation erkennen können, ob ein Zustandsübergang, ein Nachweis, eine Delegation, eine Übertragung oder eine Aussage gültig ist.

Zweitens: Kompatibilitätsgruppen. Wenn Teilnehmer unterschiedliche künftige Regeln übernehmen, sollte das System die Kompatibilitätsgrenze klar beschreiben, statt Dissens als Fehlverhalten zu behandeln.

Drittens: verteilte Nachweise der Kontrolle. Ein Inhaber sollte seine Ressourcen nicht zu einer anderen Registrierungsstelle „verschieben“; er sollte die Kontrolle durch einen nach den Ledger-Regeln gültigen Zustand nachweisen, den jede Gegenpartei ohne den Segen der etablierten Institution überprüfen kann.

Viertens: Sichtbarkeit von Forks. Wenn Regelwerke auseinanderlaufen, sollte diese Abweichung ausdrücklich erkennbar sein. Teilnehmer entscheiden, welche Kompatibilitätsgruppe sie betreiben und welche Gegenparteien sie akzeptieren. Ein Fork kann Teilnehmer isolieren. Er gibt keiner Seite institutionelle Macht, die andere auszulöschen.

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

Es ist ein Plädoyer gegen das Monopol als Quelle der Gültigkeit.

Warum der Weg des Versagens vorhersehbar ist

Wenn sich nichts ändert, ist der Weg des Versagens klar.

Erstens werden mehr Streitigkeiten aus Richtliniengremien vor Gericht wandern. Knappe Vermögenswerte ziehen rechtliche Prüfung auf sich. Gerichte werden aufgefordert werden, Konten einzufrieren, Einträge zu sichern, unzulässige Wahlen zu blockieren, Verwalter einzusetzen, Übertragungen anzuerkennen oder festzustellen, wer für eine Registrierungsstelle handeln darf.

Zweitens werden Staaten aufhören, RIRs als harmlose technische Vereinigungen zu behandeln. Kontinuität bei Nummernressourcen berührt nationale Konnektivität, Sanktionen, Strafverfolgung, die Widerstandsfähigkeit der Telekommunikation, Cloud-Infrastruktur und wirtschaftliche Sicherheit. Kein Staat wird für immer eine ausländische private Registrierungsstruktur als ungeprüften vorgelagerten Bezugspunkt für die Kontinuität seiner nationalen Kommunikation akzeptieren.

Drittens werden Betreiber die Autorität der Registrierungsstellen umgehen, wo immer das möglich ist. Wenn Registrierungseinträge politisch, unsicher, nicht repräsentativ oder von der Realität der Vermögenswerte abgekoppelt werden, werden Betreiber auf private Verträge, gerichtlich abgesicherte Übertragungen, alternative Bescheinigungen, nationale Anerkennung oder die faktische Routing-Realität setzen.

Viertens werden ICANN und die NRO-Schicht versucht sein, zu zentralisieren. Das würde eine noch umfangreichere Version desselben Problems erzeugen, sofern nicht das Mandat selbst eingegrenzt wird.

Fünftens werden Regierungen versucht sein, zu verstaatlichen. Das wäre vorhersehbar und gefährlich. Wenn private Registrierungsstellen quasi-souveräne Autorität ohne öffentliche Rechenschaftspflicht beanspruchen, werden Staaten irgendwann die Souveränität zurückfordern. Das Ergebnis könnte Fragmentierung, Vergeltung, widersprüchliche Register und politischer Druck auf das Routing sein.

Das Internet versagt nicht nur, wenn Pakete aufhören, sich zu bewegen.

Es versagt auch dann, wenn die Institutionen, die beschreiben, wer Kennungen nutzen darf, das Vertrauen jener Betreiber verlieren, die die Pakete bewegen.

Ein verteiltes Ledger löst nicht jedes politische Problem. Es tut etwas Wichtigeres: Es beseitigt die dauerhaft bestehende Registrierungsstelle als gewöhnliche Quelle der Gültigkeit. Das verkleinert die Angriffsfläche. Es verringert die institutionelle Macht, andere als Geiseln zu halten. Es verwandelt künftige Meinungsverschiedenheiten in eine Auswahl zwischen Kompatibilitäten statt in Verwaltungskrieg.

Die Frage verändert sich

Das alte System fragt: Wer hat das Mandat?

Das ist die falsche Frage.

Die bessere Frage lautet: Was braucht lauffähiger Code tatsächlich?

Schützt diese Regel die Eindeutigkeit?

Bewahrt sie die Interoperabilität?

Berichtigt sie nachweisbaren Registrierungsbetrug anhand deterministischer Belege?

Schützt sie die Sicherheit im Umfeld des Routings?

Wahrt sie die Genauigkeit der Kontrollnachweise?

Ermöglicht sie lokale Validierung?

Beseitigt sie die Abhängigkeit von einer einzigen etablierten Institution?

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

Kann ein Teilnehmer sie ablehnen, ohne einen ungültigen Status zu erhalten?

Kann ein Teilnehmer gewöhnliche Gültigkeit überprüfen, ohne eine Registrierungsstelle nach dem Status zu fragen?

Kann eine Gegenpartei einen Zustand freiwillig akzeptieren oder zurückweisen?

Kann ein Fork entstehen, ohne dass eine Institution eine Seite auslöscht?

Wenn die Antwort nicht an eine deterministische Notwendigkeit des lauffähigen Codes gebunden ist, gehört diese Macht nicht in die gemeinsame Schicht.

Das ist das Primat des lauffähigen Codes.

Zur Diskussion

Dieser Vorschlag steht zur Diskussion. Er ist keine abschließende Regelung.

Der nächste Schritt sollte ein ernsthafter Internet-Draft oder ein Dokument im BCP-Stil sein, das das Primat des lauffähigen Codes für Internet-Koordinationssysteme definiert, beginnend mit Nummernressourcen. Der Entwurf sollte nicht fragen, wie sich das RIR-Monopol rehabilitieren lässt. Er sollte fragen, wie Koordination nach den RIRs durch verteilten Ledger-Zustand, deterministische Validierung, freiwillige Übernahme, Akzeptanz durch Gegenparteien und ausdrücklich ausgewiesene Kompatibilitätsgruppen aufgebaut werden kann.

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

Der Entwurf sollte schwierige Fragen stellen.

Was sind die globalen Invarianten?

Welche Validierungsregeln sind deterministisch?

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

Welche alten Befugnisse der Registrierungsstellen sind historische Überbleibsel?

Welche Entscheidungen gehören den Betreibern?

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

Wie sieht der Weg der Ablehnung aus?

Wie sieht der Fork-Weg aus?

Wie sieht der Weg der lokalen Zurückweisung aus?

Wie weist ein Inhaber die Kontrolle ohne eine etablierte Registrierungsstelle nach?

Wie überprüft eine Gegenpartei einen Zustand ohne Registrierungsstelle?

Kann das Internet weiter funktionieren, wenn eine RIR zusammenbricht?

Können Nummernressourcen ohne Genehmigung einer etablierten Institution eindeutig bleiben?

Kann ein Teilnehmer gewöhnliche Zustände ohne eine dauerhafte Institution validieren?

Kann ein Richtlinienverfahren eine Invariante des lauffähigen Codes von institutionellem Machthunger unterscheiden?

Kann die alte Registrierungsschicht verschwinden, ohne dass überprüfbarer Zustand verloren geht?

Kann ein Eintrag Realität beschreiben, ohne zu ihrem Souverän zu werden?

Interessierte können mich über LinkedIn kontaktieren. Ernsthaft arbeitende Forscher, technische Autoren, Institutionen oder Richtlinienexperten, die dabei helfen möchten, daraus einen ersten Internet-Draft und schließlich eine RFC- oder BCP-Diskussion zu machen, sofern die Gemeinschaft dies nützlich findet, sollten sich bei mir melden. Die LARUS Foundation und ich sind bereit, ernsthafte Forschung in dieser Richtung zu unterstützen und zu finanzieren.

Der erste Entwurf des RIR-Systems scheiterte, weil er nie fragte, was lauffähiger Code tatsächlich brauchte.

Er fragte, wer im Raum sprechen durfte.

Das nächste System muss diese Reihenfolge umkehren.

Keine Mandatswäsche.

Kein Verrat am lauffähigen Code.

Das Primat des lauffähigen Codes.

Anhang: Minimale Anfangsspezifikation, lokale Entscheidung über die Zukunft und freiwillige Übernahme für Internet-Koordinationssysteme

Notiz 64

Zusammenfassung

Dieses Dokument beschreibt ein Entwurfsmuster für Internet-Koordinationssysteme, deren Zweck darin besteht, gemeinsame technische Bezugspunkte bereitzustellen, ohne eine dauerhafte Autorität über den Teilnehmern zu schaffen, die das System betreiben. Es definiert drei miteinander verknüpfte Prinzipien: minimale Anfangsspezifikation, lokale Entscheidung über die Zukunft und freiwillige Übernahme.

In diesem Modell definiert die Anfangsspezifikation ausschließlich die deterministischen, lokal überprüfbaren Regeln, die für Eindeutigkeit, Interoperabilität, den Nachweis der Kontrolle, gemeinsame Betriebssicherheit und Informationssicherheit erforderlich sind. Nach der Anfangsspezifikation werden künftige Änderungen nicht von einem zentralen Gremium genehmigt. Teilnehmer, die Code betreiben, übernehmen sie, ignorieren sie, bilden Forks oder geben sie auf.

Das beabsichtigte Entwurfsmuster ist ein verteiltes Ledger gültiger Zustände oder ein gleichwertiger verteilter Mechanismus für überprüfbaren Zustand, keine Hierarchie von Registrierungsstellen. Es gibt keine dauerhaft bestehende Registrierungsstelle, die über gewöhnliche Gültigkeit entscheidet. Teilnehmer validieren Zustände lokal, akzeptieren Gegenparteien freiwillig und entscheiden, welche Kompatibilitätsgruppen sie betreiben.

Nichtübernahme ist kein Verstoß. Ein Teilnehmer, der eine spätere Änderung nicht übernimmt, bleibt in seiner bestehenden Kompatibilitätsgruppe. Ein Teilnehmer, der einen Zustand ausgibt, der nach den von einem anderen Teilnehmer akzeptierten deterministischen Regeln nicht gültig ist, kann von diesem Teilnehmer lokal ignoriert werden. Die Wirkung besteht in der Auswahl von Kompatibilität, einem Fork, Isolation oder selektiver Interoperation, nicht in institutioneller Bestrafung.

Dieses Dokument definiert kein Übertragungsprotokoll. Es legt eine Best Current Practice für den Entwurf von Protokollen, Kennungssystemen, verteilten Ledgers und Koordinationsmechanismen fest, die nicht zu dauerhaften Governance-Institutionen werden dürfen.

1. Einleitung

Viele Internet-Systeme beginnen mit einem eng begrenzten technischen Zweck: Unabhängige Akteure sollen interoperieren können, indem sie einen gemeinsamen Bezugspunkt, einen Kennungsraum, eine Validierungsregel, einen Ledger-Zustand oder einen Eintrag zum Nachweis der Kontrolle teilen. Mit der Zeit sammeln solche Systeme oft Autorität an, die für die anfängliche Interoperabilität nicht erforderlich war.

Das geschieht gewöhnlich in drei Schritten.

Erstens werden künftige Fragen in die Gründungsschicht verlagert, bevor dies technisch notwendig ist.

Zweitens werden Entscheidungen, die Teilnehmer beim Betrieb ihrer eigenen Systeme treffen sollten, von Anerkennung, Auslegung oder Statusentscheidungen einer dauerhaft bestehenden Körperschaft abhängig gemacht.

Drittens werden Veröffentlichung, Registrierung, Empfehlung oder verfahrensmäßige Genehmigung als ausreichend behandelt, um betriebliche Verpflichtungen zu schaffen, selbst wenn Teilnehmer die Änderung in laufenden Systemen nicht übernommen haben.

Das Ergebnis ist ein fragiles System. Eine technische Referenzschicht wird zur Governance-Schicht. Ein Registerführer wird zum Zugangswächter. Ein Koordinationsartefakt wird zur Quelle künftiger Kontrolle.

Dieses Dokument schlägt eine andere Entwurfsdisziplin vor:

• Minimale Anfangsspezifikation: Nur die deterministischen gemeinsamen Regeln spezifizieren, die für grundlegende Interoperabilität, Eindeutigkeit, den Nachweis der Kontrolle, gemeinsame Betriebssicherheit und Informationssicherheit erforderlich sind.
• Lokale Entscheidung über die Zukunft: Nach der Anfangsspezifikation künftige Entscheidungen bei den Teilnehmern belassen, die Code betreiben. Ein Teilnehmer kann Änderungen übernehmen, ablehnen, einen Fork bilden, sich abkoppeln oder selektiv interoperieren. Kein Teilnehmer kann die Interoperabilität anderer Teilnehmer verändern, die weiterhin miteinander kompatible Regeln ausführen.
• Freiwillige Übernahme: Spätere Änderungen ausschließlich durch Implementierung, Betrieb, Validierung und Übernahme durch Teilnehmer real werden lassen, die Code betreiben.

Diese Prinzipien hängen zusammen. Ein System, das zu Beginn zu viel spezifiziert, verankert künftige Kontrolle bereits in der gemeinsamen Schicht. Ein System, das eine dauerhafte Anerkennungsschicht bestehen lässt, ermöglicht die Wiederkehr von Autorität nach der Einführung. Ein System, das Veröffentlichung als Realität behandelt, verwandelt Dokumentation in einen Befehl.

Die grundlegende Entwurfsidee ist einfach: Gültigkeit muss durch deterministische Regeln bestimmt werden, die Teilnehmer lokal anhand eines gemeinsamen Zustands überprüfen können. Ein Teilnehmer kann eine spätere Änderung übernehmen, sie ablehnen, einen Fork bilden, sich abkoppeln oder selektiv interoperieren. Er kann sich allenfalls selbst aus einer Kompatibilitätsgruppe entfernen. Er kann nicht dadurch, dass er eine Änderung ablehnt, die Interoperabilität anderer Teilnehmer zerstören, die weiterhin miteinander kompatiblen Code betreiben.

Das ist die allgemeine Lehre aus dem Entwurf verteilter Ledger: Konsensregeln werden von Teilnehmern durchgesetzt, die Validierungscode ausführen und entscheiden, welchen Zustand sie akzeptieren, nicht von einer Institution, die über ihnen steht.

2. Geltungsbereich

Dieses Dokument gilt für Internet-Koordinationssysteme, darunter unter anderem Kennungssysteme, Namens- und Nummerierungsrahmen, Mechanismen für Protokollerweiterungen, Systeme zum Nachweis der Kontrolle, Portabilitätssysteme, verteilte Ledger und andere Architekturen, in denen unabhängige Akteure auf einen gemeinsamen technischen Bezugspunkt vertrauen.

Dieses Dokument argumentiert nicht gegen gemeinsame Regeln. Es argumentiert dafür, dass gemeinsame Regeln deterministisch, minimal, lokal überprüfbar und auf das beschränkt sein sollten, was das System tatsächlich zum Funktionieren braucht.

Dieses Dokument verlangt keine bestimmte Implementierung eines verteilten Ledgers. Es verlangt eine Entwurfseigenschaft: Teilnehmer sollten 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 Statusauskunft zu bitten.

3. Konventionen und Definitionen

3.1. Anforderungssprache

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

3.2. Terminologie

Anfangsspezifikation:
Die Menge der Regeln, Datenstrukturen, Formate, Invarianten, Validierungsverfahren, Zustandsübergangsregeln und Konfliktregeln, die für die erste Einführung eines Systems erforderlich sind.

Gemeinsame Schicht:
Das minimale gemeinsame Regelwerk oder die minimale Referenzstruktur, die unabhängige Teilnehmer für ihre Interoperation benötigen. Die gemeinsame Schicht ist keine Institution. Sie ist der technische Inhalt, den Teilnehmer implementieren und überprüfen.

Verteiltes Ledger:
Eine replizierte oder anderweitig verteilte Aufzeichnung von Zustandsübergängen, die es Teilnehmern ermöglicht, gewöhnliche Gültigkeit zu überprüfen, ohne sich auf eine dauerhafte Registrierungsstelle, einen Ausschuss oder eine andere Autorität zu verlassen. Der Begriff setzt keinen bestimmten Konsensalgorithmus und keine bestimmte Implementierung voraus.

Deterministische Validierungsregel:
Eine Regel, die einem Teilnehmer ermöglicht, durch lokale Berechnung oder lokale Überprüfung zu entscheiden, ob ein Zustand, Eintrag, Übergang, eine Aussage oder Nachricht nach einem festgelegten Regelwerk gültig ist.

Globale Invariante:
Eine Eigenschaft, die innerhalb einer Kompatibilitätsgruppe gemeinsam erhalten bleiben muss, um Eindeutigkeit, grundlegende Interoperabilität, die Integrität des Kontrollnachweises, gemeinsame Betriebssicherheit oder Informationssicherheit zu bewahren.

Teilnehmer:
Ein Betreiber, eine Implementierung, ein Knoten, ein Netz, eine Organisation oder ein anderer Akteur, der das System betreibt, überprüft, einführt oder sich darauf verlässt.

Kompatibilitätsgruppe:
Eine Gruppe von Teilnehmern, deren implementierte Validierungsregeln es ihnen ermöglichen, miteinander zu interoperieren. Eine spätere Änderung kann eine neue Kompatibilitätsgruppe schaffen, wenn einige Teilnehmer sie übernehmen und andere nicht.

Übernahme:
Tatsächliche Implementierung, Einführung, Validierung und Nutzung durch Teilnehmer, die das System betreiben.

Akzeptanz einer Gegenpartei:
Die freiwillige Entscheidung eines Teilnehmers, nach den von ihm ausgeführten Validierungsregeln den Zustand eines anderen Teilnehmers zu akzeptieren, auf seiner Grundlage Transaktionen durchzuführen, mit ihm zu interoperieren oder sich darauf zu verlassen.

Nichtübernahme:
Die Entscheidung eines Teilnehmers, eine vorgeschlagene Änderung nicht zu implementieren oder zu nutzen. Nichtübernahme erzeugt keinen ungültigen Status. Sie bedeutet lediglich, dass der Teilnehmer der durch diese Änderung geschaffenen Kompatibilitätsgruppe nicht beigetreten ist.

Lokale Zurückweisung:
Die lokale Entscheidung eines Teilnehmers, einen Zustand, eine Nachricht, einen Eintrag oder einen Übergang, der nach den von ihm ausgeführten Validierungsregeln ungültig oder inkompatibel ist, zu ignorieren, zurückzuweisen oder damit nicht zu interoperieren.

Fork:
Eine Abweichung in Validierungsregeln oder betrieblicher Praxis, durch die zwei oder mehr Kompatibilitätsgruppen entstehen.

Koordinationsartefakt:
Ein Dokument, eine Empfehlung, ein Implementierungshinweis, ein Profil, eine Referenzimplementierung, ein Ledger-Explorer, eine Spiegelung oder ein anderes Artefakt, das Teilnehmern bei der Koordination hilft. Ein Koordinationsartefakt schafft keine verbindliche betriebliche Realität, sofern Teilnehmer es nicht in laufenden Systemen übernehmen.

4. Problemstellung

Systementwickler versuchen häufig, künftige Unsicherheit zu verringern, indem sie zu viel in die Gründungsschicht schreiben oder eine dauerhafte Körperschaft zur Auslegung künftiger Fragen vorsehen. Das erscheint umsichtig. Es ist häufig gefährlich.

Eine Überfrachtung der Gründungsschicht mit Spezifikationen hat drei Kosten.

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

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

Drittens ermutigt sie eine Körperschaft, die Einträge pflegt, Dokumente veröffentlicht oder Teilnehmer zusammenruft, diese Handlungen als Autorität über künftige Realität zu behandeln.

Dasselbe Problem tritt nach der Einführung auf. Wenn ein System eine dauerhafte Körperschaft braucht, die Änderungen genehmigt, Status bestimmt oder den gewöhnlichen Betrieb auslegt, hat das System eine Kontrollschicht für die Zeit nach seiner Gründung geschaffen. Diese Schicht kann als Verwaltung beginnen. Sie kann zur Governance werden. Und sie kann dann zum Engpass werden.

Das Entwurfsziel dieses Dokuments ist nicht besseres institutionelles Ermessen. Das Entwurfsziel ist, die Notwendigkeit dieses Ermessens zu vermeiden.

Ein gut entworfenes Internet-Koordinationssystem sollte zu Beginn deterministische, lokal überprüfbare Gültigkeitsregeln definieren; gültigen Zustand in verteilter oder anderweitig replizierbarer Form abbilden; Entscheidungen, die keine Invarianten betreffen, außerhalb der gemeinsamen Schicht belassen; und spätere Änderungen erst dann real werden lassen, wenn Teilnehmer sie freiwillig in laufenden Systemen übernehmen.

5. Prinzip 1: Minimale Anfangsspezifikation

5.1. Grundsatz

Eine Anfangsspezifikation SOLLTE ausschließlich die minimalen deterministischen gemeinsamen Regeln definieren, die für grundlegende Interoperabilität, Eindeutigkeit, den Nachweis der Kontrolle, gemeinsame Betriebssicherheit und Informationssicherheit erforderlich sind.

5.2. Anforderungen

Ein Entwurf, der dieses Prinzip anwendet:

1. MUSS seine globalen Invarianten ausdrücklich benennen.
2. MUSS für jede globale Invariante deterministische Validierungsregeln definieren.
3. MUSS definieren, wie gültiger Zustand abgebildet, repliziert, überprüft und aktualisiert wird.
4. DARF eine Regel NICHT in die Anfangsspezifikation aufnehmen, sofern sie nicht erforderlich ist, um eine benannte globale Invariante zu bewahren oder die erste Einführung zu ermöglichen.
5. MUSS Validierungsregeln von Richtlinienpräferenzen, geschäftlichen Vereinbarungen, institutionellen Rollen, Governance-Ambitionen und Ermessensentscheidungen trennen.
6. MUSS Teilnehmern ermöglichen, gewöhnliche Gültigkeit lokal zu überprüfen, ohne eine Institution, Registrierungsstelle, einen Ausschuss, ein Richtliniengremium oder eine andere Autorität fragen zu müssen.
7. SOLLTE Datenstrukturen, Signaturen, Nachweise, Zustandsübergangsregeln, Konfliktregeln oder andere Mechanismen definieren, die für die lokale Überprüfung notwendig sind.
8. SOLLTE Erweiterungssignalisierung, Versionierung, Kompatibilitätskennzeichnung oder Fork-Kennung definieren, wenn künftige Varianten absehbar sind.
9. MUSS sicherstellen, dass erforderliche Koordinationsartefakte portabel, prüfbar, reproduzierbar und ersetzbar sind.
10. SOLLTE objektive, maschinell überprüfbare Bedingungen einer subjektiven Bewertung der Berechtigung vorziehen.
11. DARF künftige institutionelle Anerkennung NICHT zum einzigen Weg machen, auf dem ein gültiger Zustand erkannt, erfasst oder genutzt werden kann.

5.3. Konsequenzen für den Entwurf

Minimale Anfangsspezifikation bedeutet nicht vage Spezifikation. Sie bedeutet eine strenge Spezifikation ausschließlich dessen, was gemeinsam sein muss.

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

• dem, was für Eindeutigkeit, Interoperabilität, den Nachweis der Kontrolle, gemeinsame Betriebssicherheit und Informationssicherheit gemeinsam sein muss; und
• dem, was außerhalb der gemeinsamen Schicht bleiben kann, weil es um Betreiberpräferenzen, Geschäftspraxis, die Wahl von Gegenparteien, den Einführungszeitpunkt oder spätere Übernahmeentscheidungen geht.

Ein Entwurf, der seine globalen Invarianten und deterministischen Validierungsregeln nicht klar benennen kann, sollte davon ausgehen, dass er zu viel Ermessen und zu wenig überprüfbare Substanz spezifiziert hat.

6. Prinzip 2: Lokale Entscheidung über die Zukunft

6.1. Grundsatz

Nach der Anfangsspezifikation SOLLTEN künftige Entscheidungen lokal bei den Teilnehmern verbleiben, die Code betreiben. Eine künftige Entscheidung wird nur für jene Kompatibilitätsgruppe wirksam, deren Teilnehmer sie übernehmen. Zu ihrer Genehmigung ist keine dauerhafte Autorität erforderlich, und Nichtübernahme erzeugt keinen ungültigen Status.

6.2. Anforderungen

Ein Entwurf, der dieses Prinzip anwendet:

1. DARF von Teilnehmern NICHT verlangen, für Entscheidungen, die die deterministischen Validierungsregeln ihrer Kompatibilitätsgruppe nicht verändern, die Erlaubnis einer etablierten Institution, Registrierungsstelle, eines Ausschusses, Vorstands, Richtliniengremiums oder einer anderen Autorität einzuholen.
2. DARF KEINE dauerhafte Körperschaft schaffen, deren Anerkennung der einzige Weg ist, auf dem eine spätere Änderung betriebliche Realität werden kann.
3. MUSS zwischen Gültigkeit nach der Anfangsspezifikation und Kompatibilität mit einer späteren optionalen Änderung unterscheiden.
4. DARF die Nichtübernahme einer späteren Änderung NICHT als Ungültigkeit behandeln.
5. MUSS Teilnehmern ermöglichen, in einer bestehenden Kompatibilitätsgruppe zu bleiben, wenn sie eine spätere Änderung nicht übernehmen.
6. MUSS Teilnehmern ermöglichen, durch Übernahme neuer Validierungsregeln oder Betriebsprofile einer neuen Kompatibilitätsgruppe beizutreten.
7. MUSS Teilnehmern ermöglichen, Zustände, Einträge, Übergänge oder Nachrichten lokal zurückzuweisen, die nach den von ihnen ausgeführten Validierungsregeln ungültig oder inkompatibel sind.
8. MUSS Teilnehmern ermöglichen, Gegenparteien nach den von ihnen akzeptierten Validierungsregeln und Kompatibilitätsgruppen freiwillig auszuwählen.
9. DARF KEINE Institution, Registrierungsstelle, keinen Ausschuss, kein Richtliniengremium und keinen anderen Akteur ermächtigen, einen Teilnehmer allein deshalb für ungültig zu erklären, weil er eine spätere Änderung abgelehnt hat.
10. SOLLTE Forks, Versionen, Profile oder Kompatibilitätsgruppen ausdrücklich ausweisen, damit Teilnehmer wissen, welche Regeln sie ausführen und mit welchen anderen Teilnehmern sie interoperieren können.
11. SOLLTE jeden Entwurf vermeiden, in dem ein etablierter Registerführer ansonsten gültige Teilnehmer daran hindern kann, weiter miteinander zu interoperieren.

6.3. Konsequenzen für den Entwurf

Lokale Entscheidung über die Zukunft 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 keine solche Zuweisung benötigen.

Die Anfangsspezifikation leistet die Begrenzung im Voraus. Sie definiert die minimalen Invarianten, die für Eindeutigkeit, Interoperabilität, den Nachweis der Kontrolle, gemeinsame Betriebssicherheit und Informationssicherheit erforderlich sind. Alles andere bleibt außerhalb der gemeinsamen Schicht.

Künftige Veränderungen werden nicht zentral genehmigt. Teilnehmer, die Code betreiben, übernehmen sie, ignorieren sie, bilden Forks oder geben sie auf.

Ein Teilnehmer, der eine Änderung ablehnt, kann außerhalb der durch diese Änderung geschaffenen Kompatibilitätsgruppe bleiben. Er kann sich von anderen abkoppeln. Er kann in einer älteren Kompatibilitätsgruppe weiterarbeiten. Er kann einen Fork bilden. Er kann selektiv interoperieren. Aber er kann die Interoperabilität anderer Teilnehmer nicht zerstören, die weiterhin miteinander kompatible Regeln ausführen.

Die Wirkung eines ungültigen oder inkompatiblen Zustands ist lokale Zurückweisung, nicht Bestrafung. Niemand muss entscheiden, dass ein Teilnehmer einen beanstandeten Status hat. Ein Teilnehmer, der kompatible Validierungsregeln ausführt, akzeptiert den ungültigen oder inkompatiblen Zustand einfach nicht.

7. Prinzip 3: Freiwillige Übernahme

7.1. Grundsatz

Änderungen in einem Internet-Koordinationssystem SOLLTEN durch Implementierung, Validierung, Einführung, Akzeptanz durch Gegenparteien und Übernahme durch Teilnehmer betriebliche Realität werden, nicht allein durch Veröffentlichung oder Erklärung.

7.2. Anforderungen

Ein Entwurf, der dieses Prinzip anwendet:

1. DARF Veröffentlichung, Empfehlung, Zustimmung einer Versammlung oder verfahrensmäßige Genehmigung NICHT als ausreichend behandeln, um eine universelle betriebliche Verpflichtung zu schaffen.
2. MUSS ermöglichen, dass neue Regeln, Erweiterungen, Profile oder Verfahren schrittweise von Teilnehmern eingeführt werden, die sich für ihren Betrieb entscheiden.
3. MUSS Teilnehmern ermöglichen, eine spätere Änderung abzulehnen, ohne einen ungültigen Status zu erhalten, solange ihre eigenen Zustandsübergänge die deterministischen Validierungsregeln ihrer Kompatibilitätsgruppe erfüllen.
4. MUSS Teilnehmern ermöglichen, eine ältere Kompatibilitätsgruppe weiter zu nutzen, soweit die Anfangsspezifikation diese Kontinuität zulässt.
5. MUSS Teilnehmern, die eine Kompatibilitätsgruppe betreiben, ermöglichen, Zustände aus einer anderen Kompatibilitätsgruppe lokal zurückzuweisen oder zu ignorieren, wenn die Regeln inkompatibel sind.
6. SOLLTE Übernahmewege für wesentliche Änderungen definieren, einschließlich Versionssignalisierung, Kompatibilitätskennzeichnung, Übergangshinweisen und Testvektoren.
7. SOLLTE Ablehnungswege für wesentliche Änderungen definieren, einschließlich der Frage, wie nicht übernehmende Teilnehmer ihren Betrieb fortsetzen, ihre Kompatibilitätsgruppe kenntlich machen und mehrdeutige Interoperation vermeiden.
8. MUSS sicherstellen, dass erforderliche Koordinationsartefakte ohne untragbare Übergangskosten verlassen, gespiegelt, neu implementiert oder ersetzt werden können.
9. SOLLTE dafür sorgen, dass Einträge, Empfehlungen und Koordinationsartefakte eine übernommene Realität beschreiben, statt eine nicht übernommene künftige Realität durch Erklärung ins Leben zu rufen.
10. MUSS den Entwurf eines Systems vermeiden, in dem die vorherige Anerkennung durch eine etablierte Körperschaft der einzige Weg ist, auf dem eine Änderung real werden kann.

7.3. Konsequenzen für den Entwurf

Freiwillige Übernahme ist die betriebliche Prüfung, ob eine Änderung nützlich, tragbar und mit der praktischen Einführung vereinbar ist.

Ein Vorschlag ist nicht Realität. Eine Empfehlung ist nicht Realität. Ein Dokument ist nicht Realität. Realität entsteht, wenn Teilnehmer implementieren, validieren, einführen, Gegenparteien akzeptieren und sich auf die Änderung verlassen.

Nichtübernahme schafft keinen Status des Verstoßes. Sie schafft nur eine Tatsache: Der Teilnehmer ist der durch die Änderung geschaffenen Kompatibilitätsgruppe nicht beigetreten.

Das beseitigt weder Standardisierungsverfahren noch Dokumentation, Implementierungshinweise, Explorer, Spiegelungen oder Prüfungen. Es begrenzt ihren Anspruch. Sie dürfen Teilnehmern bei der Koordination helfen. Sie dürfen Referenzmaterial veröffentlichen. Sie dürfen Übernahme beschreiben. Sie dürfen Empfehlungen geben. Sie dürfen nicht durch bloße Erklärung eine nicht übernommene künftige Realität für Teilnehmer verbindlich machen, die sie nicht betreiben.

8. Verhältnis der drei Prinzipien zueinander

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

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

Lokale Entscheidung über die Zukunft stellt sicher, dass künftige Entscheidungen bei den Teilnehmern bleiben, die Code betreiben, statt von einer zentralen Genehmigungsschicht wieder an sich gezogen zu werden.

Freiwillige Übernahme stellt sicher, dass spätere Veränderungen sich im Kontakt mit Implementierung, Überprüfung, Akzeptanz durch Gegenparteien und Nutzung bewähren müssen.

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

• Minimale Anfangsspezifikation ohne lokale Entscheidung über die Zukunft kann weiterhin zulassen, dass sich nach der Einführung Autorität ansammelt.
• Lokale Entscheidung über die Zukunft ohne minimale Anfangsspezifikation kann Unklarheit erzeugen, weil Teilnehmer Gültigkeit nicht lokal bestimmen können.
• Freiwillige Übernahme ohne deterministische Validierung kann Verwirrung erzeugen, weil Teilnehmer kompatible Varianten nicht von ungültigem Zustand unterscheiden können.
• Deterministische Validierung ohne verteilten Zustand kann Teilnehmer weiterhin von einem privilegierten Registerführer abhängig lassen.
• Verteilter Zustand ohne Sichtbarkeit von Forks kann Meinungsverschiedenheiten bis zum betrieblichen Versagen verbergen.
• Verteilter Zustand ohne freiwillige Akzeptanz von Gegenparteien kann Zwang über eine andere Schnittstelle wiederherstellen.

Zusammen ergeben die Prinzipien ein System, in dem die gemeinsame Schicht schlank, Gültigkeit lokal überprüfbar, künftige Veränderung freiwillig und Zustand verteilt ist und in dem keine dauerhafte Institution benötigt wird, um über den gewöhnlichen Betrieb zu entscheiden.

9. Empfohlenes Entwurfsmuster

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 Bewahrung der Eindeutigkeit notwendig sind;
• Mechanismen zum Nachweis der Kontrolle;
• Zustandsübergangsregeln;
• Interoperabilitätsanforderungen auf Übertragungs- oder Protokollebene;
• gemeinsame Sicherheitsinvarianten;
• portable und prüfbare Zustandsformate;
• verteilte oder replizierte Sichtbarkeit des Zustands;
• Erweiterungssignalisierung und Identifizierung von Kompatibilitätsgruppen.

Die gemeinsame Schicht SOLLTE NICHT enthalten:

• Regeln für Geschäftsmodelle;
• Preisregeln;
• regionalpolitische Präferenzen;
• eine Ideologie der Teilnahmeberechtigung ohne Bezug zu technischen Invarianten;
• Ermessensbefugnisse zur Durchsetzung;
• subjektive Bewertungen der Berechtigung;
• Ausweitung institutioneller Aufgaben;
• irgendeine Regel, deren Hauptfunktion darin besteht, die Autorität einer etablierten Körperschaft zu bewahren.

9.2. Entscheidungsbereich der Betreiber

Folgendes SOLLTE außerhalb der gemeinsamen Schicht bleiben, sofern es nicht unmittelbar eine benannte globale Invariante verändert:

• Einführungszeitpunkt;
• kommerzielle Nutzung;
• Kundenstandorte;
• Vermietungs-, Finanzierungs- oder Übertragungsvereinbarungen;
• lokale Präferenzen hinsichtlich der Teilnahmeberechtigung;
• Reihenfolge betrieblicher Schritte;
• Routing-Praxis, die für gemeinsame Gültigkeit nicht erforderlich ist;
• Geschäftsmodell;
• Organisationsstruktur;
• Zeitpunkt einer freiwilligen Migration;
• optionale Profile oder Erweiterungen;
• Wahl der Gegenpartei.

Teilnehmer DÜRFEN in diesen Bereichen unterschiedliche Entscheidungen treffen. Diese Entscheidungen können unterschiedliche Kompatibilitätsgruppen, Geschäftsbeziehungen, Peering-Vereinbarungen oder betriebliche Gemeinschaften hervorbringen. Sie schaffen keine Ungültigkeit, sofern sie nicht gegen deterministische Validierungsregeln in einer Kompatibilitätsgruppe verstoßen.

9.3. Übernahmezyklus

Soweit praktikabel, ist die bevorzugte Reihenfolge für wesentliche Systemänderungen:

1. Vorschlag;
2. Implementierung;
3. Testvektoren oder deterministisches Überprüfungsverfahren;
4. begrenzte Einführung durch bereitwillige Teilnehmer;
5. Beobachtung der Auswirkungen auf Interoperabilität und Sicherheit;
6. Kennzeichnung der Kompatibilitätsgruppe;
7. Dokumentation oder Empfehlung, die die übernommene Realität beschreibt.

Ein Koordinationsartefakt SOLLTE der Übernahme folgen, statt zu versuchen, ihr vorzugreifen.

9.4. Fork, lokale Zurückweisung und Akzeptanz von Gegenparteien

Ein konformer Entwurf SOLLTE Forks, lokale Zurückweisung und die Akzeptanz von Gegenparteien als normale Entwurfsanforderungen behandeln, nicht als Versagen.

Das System SOLLTE definieren, wie ein Teilnehmer:

• in einer älteren Kompatibilitätsgruppe weiterarbeiten kann;
• eine neuere Kompatibilitätsgruppe übernehmen kann;
• durch einen Fork eine andere Kompatibilitätsgruppe bilden kann;
• Zustände überprüfen kann, ohne sich auf einen etablierten Registerführer zu verlassen;
• Gegenparteien freiwillig akzeptieren kann;
• ungültige oder inkompatible Zustände lokal zurückweisen kann;
• selektiv interoperieren kann, soweit die Kompatibilität es zulässt.

Ein System, das nicht geforkt, lokal überprüft oder selektiv akzeptiert werden kann, ohne gültigen Betrieb zu zerstören, hat vermutlich Governance-Macht in seiner Registerführungsfunktion versteckt.

10. Anwendbarkeit und Grenzen

Dieses Entwurfsmuster eignet sich besonders, wenn:

• das System mehrere Akteure und mehrere Rechtsordnungen umfasst;
• unabhängige Einführung wichtig ist;
• die Koordinationsschicht schlank bleiben soll;
• künftige Varianten wahrscheinlich sind, sich aber nicht im Detail vorhersagen lassen;
• eine Bindung ohne Ausweichmöglichkeit Governance-Risiken schaffen würde;
• Gültigkeit deterministisch oder lokal überprüfbar gestaltet werden kann;
• verteilter Zustand das Risiko institutioneller Vereinnahmung verringern kann.

Es ist möglicherweise weniger unmittelbar anwendbar, wenn:

• ein einzelner Verwaltungsbereich die beabsichtigte Architektur ist;
• eine enge Kopplung in Echtzeit jederzeit einheitliches Verhalten verlangt;
• der Schutz von Menschenleben unmittelbare globale Einheitlichkeit erfordert;
• Gültigkeit mit keinem praktikablen Mechanismus lokal überprüft werden kann.

Auch in solchen Fällen SOLLTEN Systementwickler die gemeinsame Schicht weiterhin minimieren und künftige Ermessenskontrolle nach Möglichkeit vermeiden.

11. Nicht verfolgte Ziele

Dieses Dokument:

• verbietet nicht jede Koordination;
• verlangt 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 inkompatibles lokales Verhalten, das zugleich Kompatibilität beansprucht;
• beseitigt nicht die Notwendigkeit sicherheitskritischer gemeinsamer Regeln.

12. Sicherheitsaspekte

Eine schlankere Koordinationsschicht kann das Risiko der Vereinnahmung verringern, den Wirkungsradius institutioneller Fehler verkleinern und die Ersetzbarkeit verbessern. Mehr lokaler Entscheidungsspielraum und verteilter Zustand können allerdings auch uneinheitliche Sicherheitsniveaus, Downgrade-Wege, Fragmentierungsdruck, mehrdeutige Kompatibilitätsbehauptungen, unsichere Forks, Streitigkeiten über den Ledger-Zustand und Versuche mit gefälschten Nachweisen schaffen.

Systementwickler, die dieses Dokument anwenden, MÜSSEN Sicherheitsinvarianten daher ausdrücklich spezifizieren. Insbesondere gilt:

• Authentifizierungs- und Autorisierungsanforderungen, die für gemeinsame Gültigkeit erforderlich sind, MÜSSEN deterministisch und lokal überprüfbar sein;
• Mechanismen zum Nachweis der Kontrolle MÜSSEN Fälschung, Replay und unbefugter Übertragung widerstehen;
• Versionsaushandlung und der Umgang mit Erweiterungen MÜSSEN unbemerkte Downgrades vermeiden, wenn die Sicherheit betroffen ist;
• Ablehnungs-, Fork- und Ersatzwege MÜSSEN auf Missbrauchs- und Denial-of-Service-Risiken untersucht werden;
• Kompatibilitätskennzeichnungen SOLLTEN klar genug sein, um versehentliche Interoperation zwischen inkompatiblen Regelwerken zu verhindern;
• Verteilter Zustand SOLLTE hinreichend prüfbar und reproduzierbar sein, um widersprüchliche Sichten zu erkennen;
• Lokalen Varianten DARF NICHT gestattet werden, fälschlich Kompatibilität mit einem Regelwerk zu behaupten, dessen Anforderungen sie nicht erfüllen.

Die Existenz von Sicherheitsausnahmen rechtfertigt keine allgemeine Genehmigungsschicht. Sie rechtfertigt ausschließlich deterministische Sicherheitsregeln, die notwendig sind, um die benannten globalen Invarianten zu bewahren.

13. IANA-Aspekte

Dieses Dokument erfordert keine Maßnahmen der IANA.

14. Referenzen

14.1. Normative Referenzen

• RFC 2119 — Bradner, S., Schlüsselwörter zur Angabe von Anforderungsstufen in RFCs, BCP 14, RFC 2119.
• RFC 8174 — Leiba, B., Mehrdeutigkeit von Groß- und Kleinschreibung bei den Schlüsselwörtern aus RFC 2119, BCP 14, RFC 8174.

14.2. Informative Referenzen

• RFC 6709 — Carpenter, B. und B. Aboba, Entwurfsüberlegungen für Protokollerweiterungen, RFC 6709.
• RFC 7282 — Resnick, P., Über Konsens und Summen in der IETF, RFC 7282.

Anhang A. Entwurfscheckliste

Ein Entwurf, der Konformität mit diesem Dokument beansprucht, SOLLTE die folgenden Fragen klar beantworten können:

1. Was sind die globalen Invarianten?
2. Welche deterministischen Validierungsregeln bewahren diese globalen Invarianten?
3. Welche Regeln in der Anfangsspezifikation sind für die erste Einführung zwingend notwendig?
4. Wie wird gültiger Zustand abgebildet und überprüft?
5. Ist der Zustand verteilt, repliziert oder auf andere Weise unabhängig überprüfbar?
6. Welche künftigen Fragen werden bewusst außerhalb der gemeinsamen Schicht belassen?
7. Welche künftigen Entscheidungen können Teilnehmer treffen, ohne ihre Kompatibilitätsgruppe zu verändern?
8. Wie übernimmt ein Teilnehmer eine spätere Änderung?
9. Wie lehnt ein Teilnehmer eine spätere Änderung ab, ohne einen ungültigen Status zu erhalten?
10. Wie werden Kompatibilitätsgruppen gekennzeichnet oder entdeckt?
11. Wie funktioniert lokale Zurückweisung, wenn ein Zustand nach den von einem Teilnehmer ausgeführten Regeln ungültig oder inkompatibel ist?
12. Wie sieht der Fork-Weg aus?
13. Wie weist ein Inhaber die Kontrolle ohne einen etablierten Registerführer nach?
14. Wie überprüft eine Gegenpartei einen Zustand ohne Registrierungsstelle?
15. Können Teilnehmer gewöhnliche Gültigkeit überprüfen, ohne sich auf einen etablierten Registerführer zu verlassen?
16. Beschreiben Einträge und Koordinationsartefakte eine übernommene Realität, oder versuchen sie, eine nicht übernommene künftige Realität durch Erklärung ins Leben zu rufen?
17. Hat das System die Zahl der Entscheidungen minimiert, die in die gemeinsame Schicht eingebettet sind?
18. Hat das System jede dauerhafte Autorität vermieden, die den gewöhnlichen Teilnehmerstatus bestimmt?
19. Können Teilnehmer Gegenparteien freiwillig akzeptieren oder ablehnen?
20. Kann das System weiter funktionieren, wenn sämtliche etablierten Registrierungsstellen verschwinden?

Autor: Lu Heng