Minimale Ausgangsspezifikation, lokale Folgeentscheidungen und freiwillige Übernahme für ein Koordinationssystem des Internets

Einigkeit über die Verbindung, Freiraum für unterschiedliche Konstruktionen. Lu Heng schlägt vor, gemeinsame Regeln auf das für Interoperabilität Erforderliche zu beschränken und spätere Entscheidungen den Teilnehmern selbst zu überlassen.

Zusammenfassung

Dieses Dokument beschreibt ein Entwurfsmuster für Koordinationssysteme des Internets, 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 verbundene Prinzipien: Minimale Ausgangsspezifikation, lokale Folgeentscheidungen und freiwillige Übernahme.

In diesem Modell definiert die Ausgangsspezifikation ausschließlich die deterministischen, lokal überprüfbaren Regeln, die für Eindeutigkeit, Interoperabilität, gemeinsame Betriebssicherheit und IT-Sicherheit erforderlich sind. Nach der Ausgangsspezifikation werden künftige Änderungen nicht von einem zentralen Gremium genehmigt. Die Teilnehmer, die den Code ausführen, übernehmen sie, ignorieren sie, spalten das System ab oder verwerfen sie.

Die Nichtübernahme ist kein Verstoß. Ein Teilnehmer, der eine spätere Änderung nicht übernimmt, bleibt in seiner bestehenden Kompatibilitätsgruppe. Gibt ein Teilnehmer einen Zustand aus, der nach den von einem anderen Teilnehmer akzeptierten deterministischen Regeln ungültig ist, kann dieser andere Teilnehmer den Teilnehmer, der diesen Zustand ausgibt, lokal ignorieren. Die Folge ist die Wahl der Kompatibilität, eine Abspaltung, Isolation oder selektive Interoperabilität, keine institutionelle Bestrafung.

Dieses Dokument definiert kein Übertragungsprotokoll. Es legt eine Best Current Practice für die Gestaltung von Protokollen, Registern, Identifikatorsystemen und Koordinationsmechanismen fest, die nicht zu dauerhaften Institutionen der Steuerung und Regelsetzung werden dürfen.

1. Einleitung

Viele Internetsysteme beginnen mit einem eng begrenzten technischen Zweck: Unabhängige Akteure sollen miteinander interoperieren können, indem sie einen gemeinsamen Bezugspunkt, Identifikatorraum, eine Validierungsregel oder registerartige Aufzeichnungen nutzen. Im Laufe der Zeit sammeln solche Systeme oft Autorität an, die für die anfängliche Interoperabilität nicht erforderlich war.

Dies geschieht gewöhnlich in drei Schritten.

Erstens werden künftige Fragen in der Gründungsebene verankert, bevor dies technisch notwendig ist.

Zweitens werden Entscheidungen, die Teilnehmer beim Betrieb ihrer eigenen Systeme treffen sollten, von Anerkennung, Auslegung oder Statusentscheidungen eines dauerhaft bestehenden Gremiums abhängig.

Drittens werden Veröffentlichung, Registrierung, Empfehlung oder verfahrensmäßige Genehmigung als hinreichend betrachtet, um eine betriebliche Verpflichtung zu erzeugen – selbst dort, wo Teilnehmer die Änderung nicht in ihren laufenden Systemen übernommen haben.

Das Ergebnis ist ein fragiles System. Aus einer technischen Referenzebene wird eine Ebene der Steuerung und Regelsetzung. Aus einem Registerführer wird ein Zugangswächter. Aus einem Koordinationsartefakt wird eine Quelle künftiger Kontrolle.

Dieses Dokument schlägt eine andere Gestaltungsdisziplin vor:

– Minimale Ausgangsspezifikation: Nur die deterministischen gemeinsamen Regeln spezifizieren, die für grundlegende Interoperabilität, Eindeutigkeit, gemeinsame Betriebssicherheit und IT-Sicherheit erforderlich sind.
– Lokale Folgeentscheidungen: Nach der Ausgangsspezifikation verbleiben künftige Entscheidungen bei den Teilnehmern, die den Code ausführen. Ein Teilnehmer kann Änderungen übernehmen oder ablehnen, eine Abspaltung vornehmen, die Verbindung trennen oder selektiv interoperieren. Kein Teilnehmer kann die Interoperabilität anderer Teilnehmer verändern, die weiterhin untereinander kompatible Regeln ausführen.
– Freiwillige Übernahme: Spätere Änderungen werden erst durch Implementierung, Betrieb, Validierung und Übernahme durch Teilnehmer, die den Code ausführen, zur Realität.

Diese Prinzipien hängen zusammen. Ein System, das zu Beginn zu viel spezifiziert, verankert künftige Kontrolle bereits im Voraus in der gemeinsamen Ebene. Ein System, das eine dauerhafte Anerkennungsebene bestehen lässt, ermöglicht es, dass Autorität nach der Inbetriebnahme erneut entsteht. Ein System, das Veröffentlichung als Wirklichkeit behandelt, macht aus Dokumentation einen Befehl.

Der Grundgedanke ist einfach: Gültigkeit muss anhand deterministischer Regeln festgestellt werden, die Teilnehmer lokal überprüfen können. Ein Teilnehmer kann eine spätere Änderung übernehmen oder ablehnen, eine Abspaltung vornehmen, die Verbindung trennen oder selektiv interoperieren. Er kann höchstens sich selbst aus einer Kompatibilitätsgruppe entfernen. Indem er eine Änderung ablehnt, kann er die Interoperabilität anderer Teilnehmer, die weiterhin untereinander kompatiblen Code ausführen, nicht zerstören.

Dies ist dieselbe allgemeine Lehre, die sich in Systemen wie Bitcoin zeigt: Konsensregeln werden von denen durchgesetzt, die Validierungscode ausführen, nicht von einer Institution, die über ihnen steht.

2. Geltungsbereich

Dieses Dokument gilt für Koordinationssysteme des Internets. Dazu gehören unter anderem gemeinsame Register, Identifikatorsysteme, Strukturen für Namen und Nummern, Mechanismen zur Protokollerweiterung, Systeme zum Nachweis der Kontrolle, Portabilitätssysteme und andere Architekturen, in denen unabhängige Akteure auf einen gemeinsamen technischen Bezugspunkt angewiesen sind.

Dieses Dokument richtet sich nicht gegen gemeinsame Regeln. Es vertritt die Auffassung, dass gemeinsame Regeln deterministisch, minimal und lokal überprüfbar sein sowie sich auf das beschränken sollten, was das System für seinen tatsächlichen Betrieb benötigt.

Dieses Dokument verlangt weder eine Blockchain noch ein verteiltes Register noch irgendeine bestimmte Technologie. Es verlangt eine Gestaltungseigenschaft: Teilnehmer sollten Gültigkeit durch lokale Anwendung der Ausgangsspezifikation feststellen können, ohne eine dauerhaft bestehende Autorität um Erlaubnis oder eine Statusentscheidung bitten zu müssen.

3. Konventionen und Definitionen

3.1. Sprache der Anforderungen

Die in diesem Dokument großgeschriebenen Anforderungsbegriffe sind in dem durch BCP 14, insbesondere RFC 2119 und RFC 8174, definierten Sinn auszulegen.

3.2. Terminologie

Ausgangsspezifikation:
Die Gesamtheit der Regeln, Datenstrukturen, Formate, Invarianten, Validierungsverfahren und Übergangsregeln, die für die erstmalige Inbetriebnahme eines Systems erforderlich sind.

Gemeinsame Ebene:
Der minimale gemeinsame Regelsatz oder die minimale Referenzstruktur, die unabhängige Teilnehmer für ihre Interoperabilität benötigen. Die gemeinsame Ebene ist keine Institution. Sie ist die technische Substanz, die Teilnehmer implementieren und überprüfen.

Deterministische Validierungsregel:
Eine Regel, anhand derer ein Teilnehmer durch lokale Berechnung oder lokale Überprüfung entscheiden kann, ob ein Zustand, Eintrag, Übergang, eine Aussage oder Nachricht nach einem festgelegten Regelsatz gültig ist.

Globale Invariante:
Eine Eigenschaft, die innerhalb einer Kompatibilitätsgruppe allen gemeinsam bleiben muss, um Eindeutigkeit, grundlegende Interoperabilität, gemeinsame Betriebssicherheit oder IT-Sicherheit zu erhalten.

Teilnehmer:
Ein Betreiber, eine Implementierung, ein Knoten, ein Netz, eine Organisation oder ein anderer Akteur, der das System ausführt, überprüft, in Betrieb nimmt oder sich darauf stützt.

Kompatibilitätsgruppe:
Eine Gruppe von Teilnehmern, deren implementierte Validierungsregeln 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:
Die tatsächliche Implementierung, Inbetriebnahme, Validierung und Nutzung durch Teilnehmer, die das System betreiben.

Nichtübernahme:
Die Entscheidung eines Teilnehmers, eine vorgeschlagene Änderung nicht zu implementieren oder zu nutzen. Die Nichtübernahme begründet 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 Übergang zu ignorieren, zurückzuweisen oder damit nicht zu interoperieren, wenn dieser nach den von ihm ausgeführten Validierungsregeln ungültig oder inkompatibel ist.

Abspaltung:
Ein Auseinanderlaufen von Validierungsregeln oder betrieblicher Praxis, das zwei oder mehr Kompatibilitätsgruppen entstehen lässt.

Koordinationsartefakt:
Ein Dokument, Registereintrag, eine Empfehlung, Implementierungsnotiz, ein Profil, eine Referenzimplementierung oder ein anderes Artefakt, das Teilnehmern bei der Koordination hilft. Ein Koordinationsartefakt schafft keine verbindliche betriebliche Realität, solange Teilnehmer es nicht in laufenden Systemen übernehmen.

4. Problembeschreibung

Systemgestalter versuchen oft, künftige Unsicherheit zu verringern, indem sie zu viel in die Gründungsebene hineinschreiben oder ein dauerhaft bestehendes Gremium vorsehen, das künftige Fragen auslegt. Das erscheint umsichtig. Oft ist es gefährlich.

Übermäßige Spezifikation in der Gründungsebene hat drei Nachteile.

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

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

Drittens ermutigt sie ein Gremium, das Aufzeichnungen führt, Dokumente veröffentlicht oder Teilnehmer zusammenruft, diese Tätigkeiten als Autorität über die künftige Wirklichkeit zu verstehen.

Dasselbe Problem tritt nach der Inbetriebnahme auf. Wenn ein System ein dauerhaft bestehendes Gremium benötigt, das Änderungen genehmigt, den Status bestimmt oder den regulären 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 Steuerungs- und Regelsetzungsinstanz werden. Danach kann sie zum Engpass werden.

Das Gestaltungsziel dieses Dokuments ist kein besseres institutionelles Ermessen. Das Gestaltungsziel besteht darin, die Notwendigkeit dieses Ermessens zu vermeiden.

Ein gut gestaltetes Koordinationssystem des Internets sollte von Anfang an deterministische, lokal überprüfbare Gültigkeitsregeln definieren; Entscheidungen, die keine Invarianten betreffen, außerhalb der gemeinsamen Ebene belassen; und spätere Änderungen erst dann zur Realität werden lassen, wenn Teilnehmer sie freiwillig in laufenden Systemen übernehmen.

5. Prinzip 1: Minimale Ausgangsspezifikation

5.1. Grundsatz

Eine Ausgangsspezifikation SOLLTE ausschließlich das Minimum an deterministischen gemeinsamen Regeln definieren, das für grundlegende Interoperabilität, Eindeutigkeit, gemeinsame Betriebssicherheit und IT-Sicherheit erforderlich ist.

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. DARF eine Regel NICHT in die Ausgangsspezifikation aufnehmen, sofern sie nicht erforderlich ist, um eine benannte globale Invariante zu erhalten oder die erstmalige Inbetriebnahme zu ermöglichen.
4. MUSS Validierungsregeln von politischen und regulatorischen Präferenzen, geschäftlichen Vereinbarungen, institutionellen Rollen, Steuerungs- und Regelsetzungsambitionen sowie Ermessensentscheidungen trennen.
5. MUSS Teilnehmern ermöglichen, die Gültigkeit im regulären Betrieb lokal zu überprüfen, ohne eine Institution, ein Register, einen Ausschuss, ein Regelsetzungsgremium oder eine andere Autorität fragen zu müssen.
6. SOLLTE Datenstrukturen, Signaturen, Nachweise, Zustandsübergangsregeln, Konfliktregeln oder andere für die lokale Überprüfung notwendige Mechanismen definieren.
7. SOLLTE die Signalisierung von Erweiterungen, Versionierung, Kompatibilitätskennzeichnung oder die Identifizierung von Abspaltungen definieren, sofern künftige Varianten absehbar sind.
8. MUSS sicherstellen, dass erforderliche Koordinationsartefakte portabel, prüfbar, reproduzierbar und ersetzbar sind.
9. SOLLTE objektive, maschinell überprüfbare Bedingungen subjektiven Werturteilen vorziehen.
10. DARF künftige institutionelle Anerkennung NICHT zum einzigen Weg machen, auf dem ein gültiger Zustand erkannt, aufgezeichnet oder genutzt werden kann.

5.3. Konsequenzen für die Gestaltung

Minimale Ausgangsspezifikation bedeutet keine vage Spezifikation. Sie bedeutet, ausschließlich das strikt zu spezifizieren, 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 Eindeutigkeit, Interoperabilität, gemeinsame Betriebssicherheit und IT-Sicherheit gemeinsam sein muss; und
– dem, was außerhalb der gemeinsamen Ebene verbleiben kann, weil es Betreiberpräferenzen, Geschäftspraktiken, den Zeitpunkt der Inbetriebnahme oder spätere Entscheidungen über die Übernahme betrifft.

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 Folgeentscheidungen

6.1. Grundsatz

Nach der Ausgangsspezifikation SOLLTEN Folgeentscheidungen lokal bei den Teilnehmern verbleiben, die den Code ausführen. Eine Folgeentscheidung wird nur für die Kompatibilitätsgruppe wirksam, deren Teilnehmer sie übernehmen. Es ist keine dauerhaft bestehende Autorität erforderlich, um sie zu genehmigen, und die Nichtübernahme begründet keinen ungültigen Status.

6.2. Anforderungen

Ein Entwurf, der dieses Prinzip anwendet:

1. DARF von Teilnehmern NICHT verlangen, für Entscheidungen die Erlaubnis einer etablierten Institution, eines Registers, Ausschusses, Vorstands, Regelsetzungsgremiums oder einer anderen Autorität einzuholen, wenn diese Entscheidungen die deterministischen Validierungsregeln der Kompatibilitätsgruppe, der sie angehören, nicht verändern.
2. DARF KEIN dauerhaft bestehendes Gremium schaffen, dessen Anerkennung der einzige Weg ist, auf dem eine spätere Änderung betriebliche Realität werden kann.
3. MUSS zwischen Gültigkeit nach der Ausgangsspezifikation 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 verbleiben, wenn sie eine spätere Änderung nicht übernehmen.
6. MUSS Teilnehmern ermöglichen, durch die Ü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. DARF KEINE Institution, kein Register, keinen Ausschuss, kein Regelsetzungsgremium und keinen anderen Akteur dazu ermächtigen, einen Teilnehmer allein deshalb für ungültig zu erklären, weil er eine spätere Änderung abgelehnt hat.
9. SOLLTE Abspaltungen, Versionen, Profile oder Kompatibilitätsgruppen ausdrücklich kenntlich machen, damit Teilnehmer wissen, welche Regeln sie ausführen und mit welchen anderen Teilnehmern sie interoperieren können.
10. SOLLTE jeden Entwurf vermeiden, in dem ein etablierter Registerführer ansonsten gültige Teilnehmer daran hindern kann, weiterhin miteinander zu interoperieren.

6.3. Konsequenzen für die Gestaltung

Lokale Folgeentscheidungen bedeuten nicht, dass eine zentrale Autorität künftige Entscheidungen lokalen Akteuren zuweist. Sie bedeuten, dass das System so gestaltet ist, dass reguläre künftige Entscheidungen nach der Ausgangsspezifikation keine solche Zuweisung benötigen.

Die Ausgangsspezifikation nimmt die Begrenzung im Voraus vor. Sie definiert die minimalen Invarianten, die für Eindeutigkeit, Interoperabilität, gemeinsame Betriebssicherheit und IT-Sicherheit erforderlich sind. Alles andere bleibt außerhalb der gemeinsamen Ebene.

Künftige Änderungen werden nicht zentral genehmigt. Die Teilnehmer, die den Code ausführen, übernehmen sie, ignorieren sie, spalten das System ab oder verwerfen sie.

Ein Teilnehmer, der eine Änderung ablehnt, kann außerhalb der durch diese Änderung geschaffenen Kompatibilitätsgruppe bleiben. Er kann seine Verbindung zu anderen trennen. Er kann in einer älteren Kompatibilitätsgruppe weiterarbeiten. Er kann eine Abspaltung vornehmen. Er kann selektiv interoperieren. Doch er kann die Interoperabilität anderer Teilnehmer, die weiterhin untereinander kompatible Regeln ausführen, nicht zerstören.

Die Folge eines ungültigen oder inkompatiblen Zustands ist lokale Zurückweisung, keine Bestrafung. Niemand muss entscheiden, dass ein Teilnehmer seinen ordnungsgemäßen Status verloren hat. Ein Teilnehmer, der kompatible Validierungsregeln ausführt, akzeptiert den ungültigen oder inkompatiblen Zustand schlicht nicht.

7. Prinzip 3: Freiwillige Übernahme

7.1. Grundsatz

Änderungen in einem Koordinationssystem des Internets SOLLTEN durch Implementierung, Validierung, Inbetriebnahme und Übernahme durch die 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, Registrierung, Empfehlung, Zustimmung in einer Sitzung oder verfahrensmäßige Genehmigung NICHT als hinreichend behandeln, um eine allgemeine betriebliche Verpflichtung zu erzeugen.
2. MUSS ermöglichen, dass neue Regeln, Erweiterungen, Profile oder Verfahren schrittweise durch die Teilnehmer in Betrieb genommen werden, die sich für ihre Ausführung entscheiden.
3. MUSS Teilnehmern ermöglichen, eine spätere Änderung abzulehnen, ohne dadurch 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, sofern die Ausgangsspezifikation diese Kontinuität zulässt.
5. MUSS Teilnehmern, die nach den Regeln einer Kompatibilitätsgruppe arbeiten, ermöglichen, Zustände aus einer anderen Kompatibilitätsgruppe lokal zurückzuweisen oder zu ignorieren, wenn die Regeln inkompatibel sind.
6. SOLLTE Wege zur Übernahme wesentlicher Änderungen definieren, einschließlich Versionssignalisierung, Kompatibilitätskennzeichnung, Übergangshinweisen und Testvektoren.
7. SOLLTE Wege zur Ablehnung wesentlicher Änderungen definieren, einschließlich der Frage, wie Teilnehmer, die eine Änderung nicht übernehmen, ihren Betrieb fortsetzen, ihre Kompatibilitätsgruppe kenntlich machen und uneindeutige Interoperabilität vermeiden.
8. MUSS sicherstellen, dass Teilnehmer erforderliche Koordinationsartefakte verlassen, portieren, spiegeln, neu implementieren oder ersetzen können, ohne untragbare Umstellungskosten.
9. SOLLTE vorsehen, dass Register, Aufzeichnungen, Empfehlungen und Koordinationsartefakte die durch Übernahme entstandene Wirklichkeit beschreiben, statt eine nicht übernommene künftige Wirklichkeit durch Erklärung ins Leben zu rufen.
10. MUSS vermeiden, ein System zu gestalten, in dem eine Änderung ausschließlich durch vorherige Anerkennung eines etablierten Gremiums zur Realität werden kann.

7.3. Konsequenzen für die Gestaltung

Freiwillige Übernahme ist die betriebliche Bewährungsprobe dafür, ob eine Änderung nützlich, tragbar und mit dem tatsächlichen Einsatz vereinbar ist.

Ein Vorschlag ist keine Wirklichkeit. Eine Empfehlung ist keine Wirklichkeit. Eine Registeraktualisierung ist keine Wirklichkeit. Ein Dokument ist keine Wirklichkeit. Wirklichkeit entsteht, wenn Teilnehmer die Änderung implementieren, validieren, in Betrieb nehmen und sich auf sie stützen.

Die Nichtübernahme begründet keinen Status eines Regelverstoßes. Sie schafft lediglich eine Tatsache: Der Teilnehmer ist der durch die Änderung geschaffenen Kompatibilitätsgruppe nicht beigetreten.

Das beseitigt weder Normungsverfahren noch Register, Dokumentation oder Prüfung. Es begrenzt ihren Anspruch. Sie dürfen Teilnehmern bei der Koordination helfen. Sie dürfen Referenzmaterial veröffentlichen. Sie dürfen die erfolgte Übernahme beschreiben. Sie dürfen Empfehlungen aussprechen. Sie dürfen aber nicht allein durch Erklärung eine nicht übernommene künftige Wirklichkeit für Teilnehmer verbindlich machen, die sie nicht in ihren Systemen ausführen.

8. Das Verhältnis der drei Prinzipien zueinander

Die drei Prinzipien verstärken sich gegenseitig und sind für sich allein nicht wirksam.

Die minimale Ausgangsspezifikation stellt sicher, dass die gemeinsame Ebene deterministische Validierungsregeln enthält und keine Ermessensautorität.

Lokale Folgeentscheidungen stellen sicher, dass künftige Entscheidungen bei den Teilnehmern verbleiben, die den Code ausführen, statt von einer zentralen Genehmigungsebene wieder vereinnahmt zu werden.

Freiwillige Übernahme stellt sicher, dass spätere Änderungen sich in der Implementierung und Nutzung bewähren müssen.

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

– Eine minimale Ausgangsspezifikation ohne lokale Folgeentscheidungen kann weiterhin zulassen, dass sich nach der Inbetriebnahme Autorität ansammelt.
– Lokale Folgeentscheidungen ohne minimale Ausgangsspezifikation können Unklarheit erzeugen, weil Teilnehmer Gültigkeit nicht lokal feststellen 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 Ausstiegsmöglichkeiten, Portabilität oder Ersetzbarkeit kann weiterhin zu einer Bindung ohne praktikable Ausweichmöglichkeit führen, wenn sich die Artefakte der Registerführung nicht mehr verlassen lassen.

Zusammen ergeben die Prinzipien ein System, in dem die gemeinsame Ebene schmal bleibt, Gültigkeit lokal überprüfbar ist, künftige Änderungen freiwillig sind und keine dauerhaft bestehende Institution benötigt wird, um über den regulären Betrieb zu entscheiden.

9. Empfohlenes Entwurfsmuster

9.1. Deterministische gemeinsame Ebene

Die gemeinsame Ebene SOLLTE beschränkt sein auf:

– eine stabile Semantik der Identifikatoren;
– deterministische Gültigkeitsregeln;
– Konfliktlösungsregeln, die zur Wahrung der Eindeutigkeit erforderlich sind;
– Interoperabilitätsanforderungen auf Übertragungs- oder Protokollebene;
– gemeinsame Sicherheitsinvarianten;
– Mechanismen zum Nachweis der Kontrolle, wo erforderlich;
– portable und prüfbare Aufzeichnungsformate, wo Aufzeichnungen erforderlich sind;
– die Signalisierung von Erweiterungen und die Identifizierung von Kompatibilitätsgruppen.

Die gemeinsame Ebene SOLLTE NICHT enthalten:

– Regeln für Geschäftsmodelle;
– Preisregeln;
– regionale politische Präferenzen;
– ideologisch begründete Teilnahmebedingungen ohne Bezug zu technischen Invarianten;
– Ermessensbefugnisse zur Durchsetzung von Regeln;
– subjektive Werturteile;
– eine Ausweitung des institutionellen Auftrags;
– irgendeine Regel, deren Hauptfunktion darin besteht, die Autorität eines etablierten Gremiums zu erhalten.

9.2. Entscheidungsraum der Betreiber

Die folgenden Fragen SOLLTEN außerhalb der gemeinsamen Ebene verbleiben, sofern sie nicht unmittelbar eine benannte globale Invariante verändern:

– der Zeitpunkt der Inbetriebnahme;
– die kommerzielle Nutzung;
– die geografische Verteilung der Kunden;
– Vereinbarungen über Vermietung, Finanzierung oder Übertragung;
– lokale Präferenzen bei den Teilnahmebedingungen;
– die Reihenfolge betrieblicher Abläufe;
– Routingpraktiken, die für die gemeinsame Gültigkeit nicht erforderlich sind;
– das Geschäftsmodell;
– die Organisationsstruktur;
– der Zeitpunkt einer freiwilligen Migration;
– optionale Profile oder Erweiterungen.

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

9.3. Übernahmezyklus

Wo praktikabel, ist für wesentliche Systemänderungen die folgende Reihenfolge vorzuziehen:

1. Vorschlag;
2. Implementierung;
3. Testvektoren oder eine deterministische Überprüfungsmethode;
4. begrenzte Inbetriebnahme durch dazu bereite Teilnehmer;
5. Beobachtung der Auswirkungen auf Interoperabilität und Sicherheit;
6. Kennzeichnung der Kompatibilitätsgruppe;
7. Dokumentation oder Empfehlung, die die durch Übernahme entstandene Wirklichkeit beschreibt.

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

9.4. Ausstieg, Abspaltung und Portabilität

Ein konformer Entwurf SOLLTE Ausstieg, Abspaltung und Portabilität als normale Gestaltungsanforderungen behandeln, nicht als Scheitern.

Das System SOLLTE definieren, wie ein Teilnehmer:

– in einer älteren Kompatibilitätsgruppe weiterarbeiten kann;
– durch Übernahme der entsprechenden Regeln einer neueren Kompatibilitätsgruppe beitreten kann;
– sich in eine andere Kompatibilitätsgruppe abspalten kann;
– Aufzeichnungen, Identifikatoren, Nachweise oder den Betriebszustand portieren kann;
– die Gültigkeit von Aufzeichnungen überprüfen kann, ohne sich auf einen etablierten Registerführer zu verlassen;
– selektiv interoperieren kann, wo die Kompatibilität es zulässt.

Ein System, aus dem man nicht aussteigen oder das man nicht abspalten kann, ohne einen gültigen Betrieb zu zerstören, hat wahrscheinlich Steuerungs- und Regelsetzungsmacht in seiner Registerführungsfunktion versteckt.

10. Anwendbarkeit und Grenzen

Dieses Entwurfsmuster eignet sich besonders, wenn:

– das System mehrere Akteure und mehrere Rechtsordnungen umfasst;
– eine unabhängige Inbetriebnahme wichtig ist;
– die Koordinationsebene schmal bleiben soll;
– künftige Varianten wahrscheinlich sind, sich aber nicht im Detail vorhersagen lassen;
– eine Bindung ohne praktikable Ausweichmöglichkeit Risiken für Steuerung und Regelsetzung schaffen würde;
– Gültigkeit deterministisch oder lokal überprüfbar gestaltet werden kann.

Es lässt sich möglicherweise weniger unmittelbar anwenden, wenn:

– die beabsichtigte Architektur einen einzigen Verwaltungsbereich vorsieht;
– eine starke Echtzeitkopplung jederzeit einheitliches Verhalten verlangt;
– der Schutz von Menschenleben sofortige globale Einheitlichkeit erfordert;
– Gültigkeit durch keinen praktikablen Mechanismus lokal überprüft werden kann.

Auch in solchen Fällen SOLLTEN Systemgestalter die gemeinsame Ebene weiterhin minimieren und künftige Kontrolle nach Ermessen nach Möglichkeit vermeiden.

11. Nicht angestrebte Ziele

Dieses Dokument:

– verbietet nicht jede Koordination;
– verbietet nicht alle gemeinsamen Register;
– verlangt weder Blockchain-Technologie noch die Technologie verteilter Register;
– 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, bei dem zugleich Kompatibilität beansprucht wird;
– beseitigt nicht die Notwendigkeit sicherheitskritischer gemeinsamer Regeln.

12. Sicherheitsaspekte

Eine schmalere Koordinationsebene kann das Risiko einer Vereinnahmung verringern, die Reichweite institutioneller Fehler begrenzen und die Ersetzbarkeit verbessern. Größerer lokaler Entscheidungsspielraum kann jedoch auch zu uneinheitlichen Sicherheitsniveaus, Möglichkeiten der Herabstufung, Fragmentierungsdruck, unklaren Kompatibilitätsbehauptungen und unsicheren Abspaltungen führen.

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

– Anforderungen an Authentifizierung und Autorisierung, die für die gemeinsame Gültigkeit erforderlich sind, MÜSSEN deterministisch und lokal überprüfbar sein;
– Versionsaushandlung und der Umgang mit Erweiterungen MÜSSEN unbemerkte Herabstufungen vermeiden, wenn die Sicherheit betroffen ist;
– Wege zur Ablehnung, Abspaltung und Ersetzung MÜSSEN auf Missbrauchs- und Denial-of-Service-Risiken untersucht werden;
– Kompatibilitätskennzeichnungen SOLLTEN klar genug sein, um unbeabsichtigte Interoperabilität zwischen inkompatiblen Regelsätzen zu verhindern;
– lokalen Varianten DARF NICHT gestattet werden, fälschlich Kompatibilität mit einem Regelsatz zu beanspruchen, den sie nicht erfüllen.

Die Existenz sicherheitsbedingter Ausnahmen rechtfertigt keine allgemeine Genehmigungsebene. Sie rechtfertigt nur deterministische Sicherheitsregeln, die erforderlich sind, um die benannten globalen Invarianten zu erhalten.

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, Gestaltungsaspekte für Protokollerweiterungen, RFC 6709.
– RFC 7282 — Resnick, P., Über Konsens und Summen in der IETF, RFC 7282.

Anhang A. Prüfliste für die Gestaltung

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 erhalten diese globalen Invarianten?
3. Welche Regeln in der Ausgangsspezifikation sind für die erstmalige Inbetriebnahme zwingend erforderlich?
4. Welche künftigen Fragen werden bewusst außerhalb der gemeinsamen Ebene belassen?
5. Welche künftigen Entscheidungen können Teilnehmer treffen, ohne die Kompatibilitätsgruppe, der sie angehören, zu verändern?
6. Wie übernimmt ein Teilnehmer eine spätere Änderung?
7. Wie lehnt ein Teilnehmer eine spätere Änderung ab, ohne dass ihm ein ungültiger Status zugewiesen wird?
8. Wie werden Kompatibilitätsgruppen gekennzeichnet oder ermittelt?
9. Wie funktioniert die lokale Zurückweisung, wenn ein Zustand nach den von einem Teilnehmer ausgeführten Regeln ungültig oder inkompatibel ist?
10. Wie verläuft der Weg zur Abspaltung?
11. Wie verläuft der Weg zur Portierung?
12. Wie kann ein Teilnehmer jedes erforderliche Koordinationsartefakt verlassen?
13. Können Teilnehmer die Gültigkeit im regulären Betrieb überprüfen, ohne sich auf einen etablierten Registerführer zu verlassen?
14. Beschreiben Aufzeichnungen und Koordinationsartefakte die durch Übernahme entstandene Wirklichkeit, oder versuchen sie, eine nicht übernommene künftige Wirklichkeit durch Erklärung ins Leben zu rufen?
15. Hat das System die Zahl der in der gemeinsamen Ebene verankerten Entscheidungen minimiert?
16. Hat das System jede dauerhaft bestehende Autorität vermieden, die den regulären Status der Teilnehmer bestimmt?

Anschrift des Autors

H. Lu