La primauté du code en cours d’exécution : le correctif nécessaire pour préserver la conception originale d’Internet

Les sept notes précédentes de Heng.lu dans cette séquence sont :

Note 52 : Lorsque le pouvoir du registre se détache de la responsabilité : pourquoi le modèle actuel de coordination des RIR ne peut pas survivre sous sa forme actuelle
Note 53 : Les ressources numériques d’Internet ne sont pas une propriété politique
Note 56 : La gouvernance dense des registres Internet régionaux transforme l’unicité en double extraction
Note 58 : De la double extraction à l’inversion de la souveraineté : comment les nations perdent leur contrôle souverain au profit des RIR pour 100 dollars US
Note 59 : La pénalité de la pauvreté : comment le modèle des RIR taxe les pauvres tout en appelant cela l’égalité
Note 61 : Trahison du code en cours d’exécution : comment le système des RIR a retourné le consensus contre la communauté technique
Note 62 : Blanchiment de mandat : du fantasme des RIR à l’architecture de transition

Les sept essais précédents n’étaient pas un programme de réforme des registres Internet régionaux.

C’était une autopsie.

Ils retraçaient la même pathologie institutionnelle à travers différentes couches : responsabilité détachée des conséquences ; ressources numériques rebaptisées propriété politique ; unicité transformée en double extraction ; souveraineté inversée ; pauvreté taxée au nom de l’égalité ; consensus retourné contre les réseaux qu’il était censé servir ; et finalement un mandat blanchi jusqu’à ce qu’un agent administratif commence à tenir le langage d’un souverain. La séquence compte, car l’échec n’était ni un mauvais conseil d’administration, ni un mauvais registre, ni une action en justice, ni un événement de marché gênant. C’était un défaut systémique apparaissant sous des déguisements différents. La page d’auteur de CircleID affiche désormais clairement cette séquence, notamment Running-Code Betrayal et Mandate Laundering. (circleid.com)

Cet essai ne cherche pas à faire des RIR de meilleurs gouvernants.

Il cherche à expliquer pourquoi l’ordre actuel des registres ne peut pas constituer le point final, et pourquoi la réparation la moins perturbatrice consiste à ajouter un complément à la conception technique originale d’Internet.

Ce complément est la Primauté du code en cours d’exécution (Running-Code Primacy).

La nécessité de ce complément n’est plus théorique. Dans un échange récent sur CircleID, John Curran a présenté la forme la plus solide de l’argument des institutions en place. Sa thèse est que l’autorité du système des RIR n’est pas simplement le sous-produit d’une coordination technique limitée, mais le résultat d’une chaîne historique : le White Paper, l’ICANN, l’ASO, l’ICP-2, la transition de la supervision de l’IANA et la gouvernance multilatérale continue du secteur privé. Il affirme que l’autorité du système des RIR découle du fait d’opérer dans le modèle multilatéral du secteur privé promu par le gouvernement des États-Unis. (circleid.com)

Cet argument est utile parce qu’il rend le désaccord visible.

La question n’est plus de savoir s’il y a eu une délégation historique. Bien sûr qu’il y en a eu une. La question est de savoir si une fonction de coordination historiquement déléguée peut ensuite s’étendre jusqu’à devenir un mandat permanent de gouvernance au moyen de la même machinerie procédurale qu’elle contrôle. La réponse des institutions en place est oui : délégation, reconnaissance, continuité institutionnelle et procédure communautaire deviennent un mandat qui se renouvelle lui-même.

La réponse exigée par la conception technique originale d’Internet est non.

La tradition originelle d’Internet était plus étroite, plus exigeante et meilleure. La RFC 3935 affirme que l’objectif de l’IETF est de « faire mieux fonctionner Internet » ; elle fonde le travail sur la compétence technique, la mise en œuvre dans le monde réel et le « rough consensus and running code ». Elle établit aussi que, lorsque l’IETF n’est pas responsable d’un protocole ou d’une fonction, il ne cherche pas à en exercer le contrôle. (rfc-editor.org) La RFC 7282 reprend la formule ancienne de David Clark : « We reject: kings, presidents and voting » et « We believe in: rough consensus and running code ». (rfc-editor.org) La RFC 9592 rend encore plus clair le point anti-souverain : l’IETF ne dirige pas, ne contrôle pas et ne patrouille pas Internet, et n’est pas « la police des protocoles ». (rfc-editor.org)

Cette tradition n’a jamais signifié que les documents étaient magiques. Elle signifiait que les documents comptaient lorsqu’ils contribuaient au fonctionnement des systèmes. Elle signifiait que le processus était toléré parce qu’il servait au déploiement. Elle signifiait qu’une salle n’était utile que lorsqu’elle se disciplinait elle-même autour de la réalité opérationnelle.

La couche des registres a emprunté cette légitimité.

Elle n’a jamais pleinement accepté cette discipline.

Voilà le correctif qui manque.

Ce que signifie la primauté du code en cours d’exécution.

La Primauté du code en cours d’exécution signifie que les systèmes de coordination d’Internet doivent être interprétés strictement, en se référant à la fonction technique minimale qui justifiait à l’origine l’existence des réseaux en fonctionnement.

La couche des ressources de numérotation existe pour protéger les systèmes en fonctionnement : unicité, interopérabilité, continuité liée au routage, assertions de sécurité, preuve de contrôle et sémantique commune minimale nécessaire pour que des réseaux indépendants puissent travailler ensemble.

Elle n’existe pas pour fabriquer une autorité politique.

Elle n’existe pas pour surveiller la moralité commerciale.

Elle n’existe pas pour transformer la géographie d’un service en titre de propriété.

Elle n’existe pas pour transformer une liste de diffusion en législature.

Elle n’existe pas pour permettre à un registre privé de faire disparaître des actifs réseau déjà opérationnels parce qu’il a changé sa théorie interne des politiques.

Un registre n’est pas un État.

Un contact dans une base de données n’est pas une procuration d’entreprise notariée.

Une région de service n’est pas un peuple.

Une salle de politiques n’est pas une législature.

Un registre peut décrire la réalité opérationnelle. Il ne la crée pas.

Ce n’est pas du conservatisme. La Primauté du code en cours d’exécution ne dit pas que les systèmes déployés ne peuvent jamais changer. Elle dit que le pouvoir institutionnel sur le changement ne doit pas être justifié par une délégation historique, une reconnaissance circulaire ou des procédures rituelles. Il doit être justifié par des règles déterministes que les opérateurs peuvent vérifier localement et par l’adoption dans les systèmes en fonctionnement.

L’ordre correct est : spécification initiale, état du registre distribué, validation locale, implémentation en cours d’exécution, adoption volontaire, ensemble de compatibilité, puis documentation.

L’ordre incorrect est : salle de politiques, déclaration, obligation revendiquée, étiquette de conformité et exécution opérationnelle forcée.

Le système des RIR a échoué parce qu’il a choisi de plus en plus le second ordre.

La correction essentielle est la suivante : après la spécification initiale, il n’existe aucune institution permanente à laquelle demander la permission. Aucun comité ne décide si la non-adoption constitue une infraction. Aucun registre ne déclare un participant invalide simplement parce qu’il refuse d’accepter un changement ultérieur. Il n’existe que le code, l’état du registre, la validation, l’adoption, la compatibilité, le rejet local, la bifurcation et l’interopérabilité sélective.

Un opérateur qui rejette un changement ultérieur ne casse pas Internet. Il peut rester dans un ensemble de compatibilité plus ancien. Il peut bifurquer. Il peut se déconnecter. Il peut cesser d’interopérer avec les participants qui ont adopté des règles incompatibles. Mais il ne peut pas casser l’interopérabilité des autres qui continuent d’exécuter un code mutuellement compatible.

L’intuition de conception est la même que celle qui rend les registres distribués utiles : il n’est pas nécessaire qu’une institution permanente décide de la validité ordinaire. Les participants valident localement les transitions d’état selon des règles déterministes. Un état invalide n’est pas sanctionné par une institution. Il est ignoré par les participants qui ne l’acceptent pas.

Voilà le correctif essentiel qui manque à la coordination des ressources numériques.

Le défaut de conception était présent dès le départ.

La première architecture des RIR supposait un monde de faible valeur.

Les ressources numériques semblaient techniques, abondantes, administratives et peu conflictuelles. Dans ce monde, l’informalité paraissait efficace. Les listes de diffusion ouvertes semblaient représentatives. L’administration fondée sur les contacts semblait suffisante. Les contrats à responsabilité limitée semblaient inoffensifs. Un registre régional pouvait ressembler à un simple carnet d’adresses.

La pénurie d’IPv4 a détruit cette prémisse.

Les adresses IPv4 sont devenues rares, transférables, finançables, louables, capitalisables, litigieuses, soumises à des sanctions et intégrées à des réseaux actifs. La couche du registre a cessé d’être au-dessus de simples entrées administratives. Elle s’est retrouvée au-dessus de l’infrastructure de production. Elle s’est retrouvée au-dessus de la valeur des actifs. Elle s’est retrouvée au-dessus de la continuité des clients, du déploiement dans le cloud, des opérations télécoms, de la connectivité nationale, des décisions judiciaires et de l’allocation de capital.

La forme institutionnelle ne s’est pas ajustée pour correspondre à ce nouveau risque.

Elle s’est étendue.

Le résultat est un système qui parle encore le langage de la coordination technique tout en produisant les effets d’une gouvernance d’infrastructure. Il demande aux opérateurs de traiter le processus d’enregistrement comme neutre, alors que les décisions du registre affectent le destin commercial. Il appelle ses participants une « communauté », même si beaucoup de ceux qui supportent les conséquences n’ont jamais accordé de représentation juridique claire aux personnes présentes dans la salle.

NRS expose clairement le problème structurel : les registres de numérotation Internet ont été conçus comme des organismes de coordination technique, mais une fois que la pénurie d’IPv4 a transformé les adresses en actifs précieux, le pouvoir discrétionnaire du registre s’est transformé en pouvoir économique ; lorsque les systèmes de coordination contrôlent le capital, la centralisation devient un risque structurel et la décentralisation devient une question d’ingénierie des systèmes plutôt qu’une question d’idéologie. NRS indique aussi la direction inverse de la conception : un Internet unique, une infrastructure ouverte et autonome, et une gouvernance décentralisée avec une participation humaine minimale au cœur du dispositif. (nrs.help)

C’est le véritable problème. La couche du registre n’a jamais été adaptée au moment où une table de coordination est devenue une porte d’accès aux actifs.

La Primauté du code en cours d’exécution est cette adaptation.

Ce n’est pas une doctrine de « meilleur RIR ».

C’est une discipline post-RIR.

Les trois règles du correctif

La grammaire constructive est la Note 64 révisée : Spécification initiale minimale, décision future localisée et adoption volontaire pour les systèmes de coordination d’Internet : Spécification initiale minimale, décision future localisée et adoption volontaire.

Les noms restent inchangés. La logique doit être précise.

Spécification initiale minimale signifie que la couche commune ne contient que les règles déterministes et vérifiables localement nécessaires à l’unicité, à l’interopérabilité, à la preuve de contrôle, à la sécurité partagée et aux assertions de sécurité. Elle ne contient pas de préférences de modèles économiques, de théories des prix, de sentiments politiques régionaux, de pouvoirs d’exécution discrétionnaires ni d’extension de la mission institutionnelle.

Décision future localisée ne signifie pas qu’une institution décide quelles décisions futures sont locales. Cela réintroduirait la couche d’autorité. Cela signifie que la spécification initiale accomplit à l’avance le travail de limitation. Après le déploiement, les décisions futures ordinaires restent entre les mains des participants qui exécutent le code. Un participant peut adopter, rejeter, bifurquer, se déconnecter ou interopérer de manière sélective. Aucun participant ne peut modifier l’interopérabilité des autres qui continuent d’exécuter des règles mutuellement compatibles.

Adoption volontaire signifie qu’un changement ultérieur ne devient réel que par l’implémentation, la validation, le déploiement et l’utilisation. La publication n’est pas la réalité. La recommandation n’est pas la réalité. La reconnaissance institutionnelle n’est pas la réalité. La non-adoption ne crée pas un état d’invalidité. Un participant qui n’adopte pas un changement ultérieur reste dans son ensemble de compatibilité existant. Un participant qui émet des états invalides selon les règles déterministes d’un autre peut être ignoré localement. L’effet est une sélection de compatibilité, pas une sanction institutionnelle.

Ces trois règles ne réhabilitent pas la souveraineté du registre.

Elles empêchent qu’elle réapparaisse sous un autre nom.

APNIC : la structure juridique était le risque

APNIC montre le premier échec : le minimum n’a jamais été spécifié de manière suffisamment stricte dès le départ.

Ce n’est pas une histoire de codes de conduite. Ce n’est pas une histoire d’étiquette. Ce n’est pas une histoire qui demande si un critique a été assez poli avec une institution en place.

C’est une histoire de structure juridique.

En mars 2023, LARUS a publié un examen juridique avertissant que la structure de gouvernance d’APNIC créait des risques non seulement pour une entreprise de Brisbane, mais pour la gouvernance d’Internet dans toute la région Asie-Pacifique. L’examen affirmait que le directeur général d’APNIC disposait du pouvoir juridique ultime de fermer APNIC et de destituer le conseil exécutif élu, et que des réformes urgentes de gouvernance étaient nécessaires. Il signalait aussi que cette structure soulevait des doutes quant à la sécurité de la gouvernance d’Internet pour plus d’un milliard d’utilisateurs dans la région Asie-Pacifique. (larus.net)

La première annexe, l’extrait d’ASIC, fournit les éléments de droit des sociétés. APNIC Pty Ltd était enregistrée comme une société privée australienne limitée par actions, enregistrée dans le Queensland. Paul Byron Wilson y figurait comme administrateur et secrétaire. Les informations sur les actions montraient une seule action ordinaire émise, détenue par Paul Byron Wilson en qualité de membre titulaire. (larus.net)

Ce n’est pas une forme normale pour héberger une fonction critique de coordination régionale d’Internet.

La deuxième annexe, l’avis juridique du Dr Peter Felter, tire la conclusion de gouvernance. Elle décrit la structure publique d’APNIC — membres, élections, conseil exécutif, directeur général et secrétariat — comme un comité spécial fondé sur l’article 9.3 des statuts d’APNIC Pty Ltd. Elle affirme qu’APNIC Pty Ltd est depuis vingt-cinq ans une société privée contrôlée par un administrateur, un actionnaire et un secrétaire qui sont tous la même personne. (larus.net)

Cette distinction compte.

L’institution publique orientée vers la communauté n’était pas le conteneur juridique final. C’était une structure construite sur une société privée.

L’avis juridique explique ensuite pourquoi cette distinction compte. Il indique que les statuts d’APNIC sont soumis aux statuts de la société et aux pouvoirs de la société, de ses administrateurs, dirigeants et membres. Selon cette interprétation, la structure publique d’APNIC pourrait être modifiée par une résolution de l’administrateur d’APNIC Pty Ltd ; l’avis décrit APNIC comme étant, en pratique, un département d’APNIC Pty Ltd. (larus.net)

Le point le plus grave de l’avis n’était pas qu’APNIC soit techniquement illégal. C’était que la légalité et la légitimité ne sont pas la même chose. L’avis soutient que le mécanisme de fiducie ne résout pas le problème, car les pouvoirs du conseil exécutif continuent de découler de la résolution de l’administrateur qui établit le comité spécial. Il signale également qu’APNIC Pty Ltd est une société privée par actions dont la structure et l’objet ne correspondent pas au modèle d’une organisation sans actions et à but non lucratif généralement associé à un registre régional d’intérêt public. (larus.net)

C’est le premier défaut de conception dans sa forme la plus pure.

Un système régional de coordination des ressources de numérotation ne devrait pas dépendre d’une structure qui oblige des avocats à expliquer pourquoi une société privée ne comptant qu’une seule action, un comité spécial, une fiducie et un conseil élu se combinent de quelque manière pour constituer le contrôle légitime du registre Internet de l’Asie-Pacifique.

Une couche de coordination critique devrait être lisible de l’extérieur.

Elle ne devrait pas exiger de faire confiance à des documents cachés derrière d’autres documents.

Elle ne devrait pas obliger les membres à découvrir, après des années de dépendance institutionnelle, que la couche élue n’est peut-être pas la couche juridique finale.

Elle ne devrait pas donner l’apparence d’une gouvernance par les membres alors que le pouvoir formel se trouve ailleurs.

C’est pourquoi la Spécification initiale minimale doit inclure une validité distribuée, et non une confiance institutionnelle. Non pas parce qu’une institution future aurait besoin d’une meilleure gouvernance, mais parce qu’un futur système post-RIR ne doit absolument pas avoir besoin de cette institution.

La couche commune ne devrait pas dépendre de la structure de contrôle cachée d’une société privée. Elle devrait définir des règles déterministes de validation, des états de preuve de contrôle, des règles de transition d’état, des règles de conflit, la réplication des registres, des voies de sortie, des voies de bifurcation et des ensembles de compatibilité. Si APNIC disparaît, se capture elle-même, modifie sa position juridique ou refuse de reconnaître un état valide, le réseau en fonctionnement ne devrait pas dépendre de la reconnaissance d’APNIC pour savoir qui contrôle quelles ressources de numérotation.

Le registre ne devrait pas être la source de la validité.

Cette source devrait être l’état du registre distribué, validé selon la spécification initiale.

ARIN : la politique s’est heurtée à la réalité des actifs

ARIN montre le deuxième échec : la réalité juridique et la réalité du marché peuvent prendre de l’avance sur la théorie du registre.

L’événement décisif fut la transaction Nortel/Microsoft. Lorsque Nortel a fait faillite, ses 666 624 adresses IPv4 sont devenues des actifs précieux dans le cadre de la procédure. Les adresses ont été vendues à Microsoft pour 7,5 millions de dollars. ARIN est intervenu en soutenant que les adresses n’étaient pas une propriété et ne pouvaient pas être vendues en dehors de la politique du registre. Industrie Canada a appuyé cette position. Le tribunal des faillites l’a rejetée ; Microsoft a ensuite signé un accord « legacy » ; et le résultat pratique était clair : la politique du registre ne pouvait plus être la seule source de réalité dès lors que les tribunaux et les marchés traitaient les ressources numériques comme des actifs. (btw.media)

La leçon importante n’est pas qu’ARIN était particulièrement défectueux.

La leçon est que la couche du registre était entrée dans une nouvelle catégorie.

Un registre est précieux parce que les opérateurs, les tribunaux, les acheteurs, les vendeurs, les créanciers et les réseaux lui font confiance. Il ne fait pas autorité en niant cette dépendance. Il ne reste utile que s’il reflète avec suffisamment de précision la réalité juridique, commerciale et opérationnelle.

Une fois qu’IPv4 est devenu rare, le processus du registre est devenu une interface de marché. Les règles de transfert, les évaluations des besoins, les retards de reconnaissance et les restrictions régionales ont cessé d’être de simples détails administratifs. Ils sont devenus des frictions sur les actifs. L’analyse publique décrit aujourd’hui un livre de règles fragmenté des RIR dans lequel cinq systèmes régionaux gouvernent un marché qui se négocie entre environ 18 et 45 dollars par adresse, avec des règles contradictoires capables d’immobiliser des actifs, de retarder des fusions et d’imposer des structures d’entreprise distinctes simplement pour conserver des blocs d’adresses. (btw.media)

Ce n’est pas une coordination neutre.

C’est un effet réglementaire sans responsabilité réglementaire.

ARIN montre pourquoi l’adoption volontaire importe. La politique du registre ne conserve sa crédibilité que tant qu’elle décrit ce que les acteurs mettent réellement en œuvre, négocient, financent, contestent en justice et utilisent. Elle devient dangereuse lorsque la publication est considérée comme suffisante pour fabriquer la réalité.

Un registre qui refuse la réalité ne devient pas souverain.

Il devient une base de données obsolète.

Dans une conception fondée sur la Primauté du code en cours d’exécution, la leçon est encore plus nette. Les tribunaux et les marchés n’ont pas besoin d’un registre en place pour déterminer si une valeur existe. Les opérateurs n’ont pas besoin d’un comité pour savoir si un bloc est routé. Les participants ont besoin de règles déterministes permettant la preuve de contrôle, la résolution des conflits, des transitions d’état visibles dans un registre et la compatibilité. L’ancien registre peut publier une vue. Un client logiciel peut afficher une vue. Un explorateur de registre peut afficher une vue. Aucun n’est la source de la validité.

Il n’y a pas de registre vers lequel migrer.

Il n’y a aucun registre auquel s’adresser.

Il n’existe qu’un état distribué que les participants valident, acceptent, rejettent ou font bifurquer, ou avec lequel ils interopèrent.

AFRINIC : quand la théorie du registre a menacé des actifs en fonctionnement

AFRINIC est le cas central parce qu’il réduit le problème à son essence.

Le mauvais récit est celui d’un membre problématique qui aurait paralysé un registre régional.

C’est le récit moral de l’institution en place.

L’histoire structurelle est différente. AFRINIC a tenté de transformer l’usage commercial, la géographie des clients, la location, la relation avec les membres et son interprétation interne des politiques en un pouvoir déclaré de retirer de l’enregistrement des ressources de numérotation déjà en fonctionnement. Une fois cette affirmation formulée, le conflit ne pouvait plus rester un désaccord dans une salle de politiques. Il devenait un test visant à déterminer si un registre privé pouvait utiliser la rhétorique régionale et le silence normatif pour menacer des actifs intégrés à l’exploitation.

Les faits ne nécessitent aucune exagération théâtrale. Des rapports publics ont décrit le litige AFRINIC comme un simple conflit commercial autour d’adresses IP devenu la plus grande histoire de gouvernance d’Internet en Afrique. Ils ont également signalé que Cloud Innovation avait souvent été présenté comme le méchant, tandis que des documents ultérieurs mettaient en évidence des forces destructrices au sein même d’AFRINIC et des litiges retardés, prolongés et poursuivis par les représentants d’AFRINIC aux frais d’AFRINIC. (btw.media)

Cela compte parce que cela inverse le récit habituel.

Le contentieux n’a pas créé le défaut structurel.

Il l’a exposé.

Le défaut pertinent était déjà présent lorsqu’un registre privé a traité l’absence d’autorisation explicite comme une base de contrôle coercitif. La location ne constituait pas une menace pour l’unicité. La géographie des clients n’était pas une affectation en double. L’usage commercial n’était pas une défaillance de la sécurité du routage. Un modèle économique désapprouvé par un registre n’était pas un invariant mondial.

Pourtant, l’interprétation du registre a placé ces éléments dans un cadre de révocation.

C’est à ce moment que la coordination devient gouvernance.

Des rapports indiquent qu’AFRINIC a envoyé à Cloud Innovation une lettre en mars 2021 alléguant des violations de politiques et menaçant de mettre fin à son adhésion ; qu’en juillet 2021 la Cour suprême de Maurice a interdit à AFRINIC d’annuler l’adhésion de Cloud Innovation ; et qu’une nouvelle tentative d’annulation a été bloquée en décembre 2021. (btw.media) Cette séquence n’est pas l’histoire d’un registre protégeant calmement Internet. C’est l’histoire de l’autorité du registre qui rencontre le droit ordinaire.

L’effondrement institutionnel n’a pas non plus été causé par un excès de pouvoir du registre. Le problème plus profond était le verrouillage structurel. Si un registre détient un monopole de reconnaissance sur des actifs vivants de grande valeur, toute défaillance interne devient un risque pour la continuité d’Internet. Si les membres ne peuvent pas quitter le système de reconnaissance, la défaillance du registre devient un pouvoir de prise d’otages.

Un registre peut corriger une fraude d’enregistrement démontrable dans ses propres données.

Il peut empêcher les affectations en double tant que le modèle de registre existe.

Il peut maintenir des assertions de sécurité tant que les participants dépendent de lui.

Mais ce sont des fonctions transitoires d’une ancienne architecture.

Dans une architecture post-RIR, ces fonctions ne sont pas assurées par un registre. Elles sont codées dans l’état d’un registre distribué, les règles de preuve de contrôle, les règles de conflit et les transitions vérifiables localement.

Un organisme privé ne devrait pas transformer la location en trahison régionale.

Il ne devrait pas transformer la géographie des clients en déclencheur de révocation.

Il ne devrait pas traiter un désaccord commercial comme une invalidité technique.

Il ne devrait pas transformer la continuité des actifs en permission.

AFRINIC montre la nécessité de comprendre correctement la Décision future localisée. Il n’existe pas d’organe central qui décide qu’une future décision commerciale « appartient localement ». Au contraire, la spécification initiale doit garantir que ces décisions n’entrent jamais dans la couche commune. La location, la géographie des clients, l’usage commercial, la fixation des prix, le financement, la composition de la clientèle et la stratégie de déploiement restent en dehors des règles de validité déterministes, sauf s’ils affectent directement l’unicité, la sécurité, la preuve de contrôle ou l’interopérabilité.

Un opérateur ne peut pas casser l’interopérabilité des autres opérateurs en louant des adresses.

Il ne peut pas la casser en servant des clients en dehors d’une région historique du registre.

Il ne peut pas la casser en utilisant un modèle économique que le registre désapprouve.

Dans tous les cas, un opérateur peut ne pas respecter des règles déterministes exécutées par d’autres participants. Dans ce cas, les autres rejettent localement l’état invalide. Il n’y a pas de couche punitive. Il n’y a pas de tribunal de conformité. Il n’y a pas de souverain régional.

Cette ligne n’est pas idéologique.

Elle est opérationnelle.

Le problème du proxy n’est pas un détail

La controverse électorale d’AFRINIC a rendu visible un deuxième défaut : la représentation.

NRS expose sa base de représentation en termes juridiques directs. Elle affirme que les membres répertoriés ont confié à NRS leur représentation dans les affaires de gouvernance des RIR et que chaque membre répertorié a accordé une procuration notariée (power of attorney). (nrs.help) Pendant le conflit électoral d’AFRINIC, NRS a demandé aux membres d’indiquer si leurs noms figuraient dans les registres de vote ou si leurs votes avaient été enregistrés sans leur participation, en précisant que ces signalements factuels seraient traités par les voies légales. (nrs.help)

Cela compte parce que cela montre la différence entre représentation juridique et rhétorique communautaire.

Le système des RIR amalgame souvent plusieurs catégories en une seule : représentant d’entreprise, contact de base de données, contact technique, salarié, consultant, titulaire d’une procuration, participant aux politiques, utilisateur régulier des listes de diffusion. Ce ne sont pas les mêmes choses.

Un contact dans une base de données peut aider à administrer des enregistrements.

Une procuration notariée peut autoriser une représentation si elle est valide et si la représentation entre dans son champ d’application.

Un participant aux politiques peut apporter une expertise.

Un participant à une liste de diffusion peut exprimer une opinion.

Aucun de ces éléments ne devient automatiquement le mandant juridique de toutes les entreprises, clients, États, créanciers, prêteurs, acheteurs, locataires ou réseaux qui supportent les conséquences d’une décision du registre.

Cette distinction ne peut être ignorée que tant que la couche commune reste mince. Dès que le registre revendique un pouvoir sur la révocation, le transfert, la location, l’accès au marché, les sanctions, la continuité des actifs ou le risque pour les infrastructures nationales, la représentation devient constitutionnelle.

Une salle n’est pas un mandat.

Une liste de diffusion n’est pas un peuple.

Un registre de contacts n’est pas une procuration d’entreprise notariée.

Une région de service n’est pas une circonscription souveraine.

Ce n’est pas une question de rigueur procédurale.

C’est la différence entre coordination et autorité normative.

Un système fondé sur la Primauté du code en cours d’exécution évite ce problème en réduisant d’abord le nombre de décisions qui nécessitent une représentation. Si la validité est déterministe et locale, il y a moins de choses à voter. Si le changement futur est volontaire, il n’est pas nécessaire de décider si un non-adoptant est en tort. Si l’état est représenté dans un registre distribué, il n’est pas nécessaire de demander à un registre en place de reconnaître l’existence continue d’un participant. Si les ensembles de compatibilité sont explicites, les participants savent avec qui ils peuvent interopérer sans consulter une salle de politiques.

Le meilleur problème de gouvernance est celui que la conception du système élimine.

RIPE NCC et LACNIC : le club et le point d’étranglement

RIPE NCC et LACNIC ne démontrent pas que certains RIR seraient plus « civilisés » que d’autres. Ils démontrent que le modèle des RIR comporte deux couches d’exécution au-delà de la fonction technique : le club et le point d’étranglement.

Le club décide qui est respectable. Le point d’étranglement décide de l’évolution du statut d’enregistrement.

Le refus de RIPE NCC d’accepter le parrainage de LARUS pour RIPE 90 a clairement montré la couche du club. Un membre a proposé un parrainage. L’écosystème du registre l’a rejeté en raison d’un différend sans rapport dans une autre région. Ce n’était pas une décision de sécurité du routage. Ce n’était pas une décision d’unicité. Ce n’était pas une règle de validation déterministe. C’était une forme d’exclusion privée par le contrôle de l’accès aux espaces, de la visibilité, du parrainage et de la légitimité sociale.

LACNIC a également rejeté le parrainage. Région différente, même schéma : le club du registre se protège en contrôlant les salles, la visibilité et la réputation.

Ce n’est pas une communauté. C’est un contrôle d’accès.

La couche des sanctions est plus grave, car elle montre le point d’étranglement sous sa forme juridique. RIPE NCC indique qu’étant établi aux Pays-Bas, il doit respecter les sanctions de l’UE ; lorsqu’elles s’appliquent, il gèle les enregistrements dans la base RIPE, bloque les acquisitions et les transferts, et peut traiter les dossiers comme gelés lorsqu’une partie ne peut pas fournir une documentation suffisante. Il effectue également des contrôles par rapport aux listes de l’OFAC en raison des exigences bancaires. (transparence des sanctions de RIPE NCC)

Ce n’est pas une critique de RIPE NCC parce qu’il respecte la loi. Une entité néerlandaise doit respecter le droit néerlandais et européen. Le problème est architectural : pourquoi une entité privée aux Pays-Bas devrait-elle être le point central de reconnaissance de la mobilité des ressources numériques entre plusieurs pays, opérateurs et systèmes juridiques ?

Les sanctions peuvent obliger une banque. Elles peuvent obliger une entité néerlandaise. Elles peuvent obliger une contrepartie qui décide de ne pas commercer. Mais elles ne devraient pas devenir une condition mondiale de validité technique pour tous les autres.

Voilà le défaut de conception.

La même centralité qui permet au club d’exclure un critique permet aussi à une juridiction de geler la mobilité du registre. L’une est une exécution sociale. L’autre est une exécution juridique. Toutes deux ne fonctionnent que parce que le registre occupe une place où la validité ne devrait pas résider.

Cela se rattache directement aux trois principes.

Spécification initiale minimale : la respectabilité du club, l’éligibilité au parrainage, la politique régionale, la classification des sanctions et la réputation ne doivent jamais entrer dans la couche commune. Celle-ci doit contenir uniquement des règles déterministes d’unicité, de preuve de contrôle, de résolution des conflits, de transition d’état et de sécurité.

Décision future localisée : le risque juridique, le choix de la contrepartie, le parrainage, la confiance commerciale et l’exposition aux sanctions appartiennent aux acteurs qui les assument. Une entité néerlandaise peut refuser une transaction. Une banque peut refuser un paiement. Une contrepartie peut refuser d’interagir. Rien de tout cela ne doit devenir une vérité mondiale du registre.

Adoption volontaire : les participants acceptent des contreparties en exécutant du code, en validant des états et en choisissant avec qui ils interopèrent. La non-adoption n’est pas une mauvaise conduite. Le rejet local n’est pas une invalidité globale. Le rejet par un club ne devrait pas effacer un état valide. Une obligation de sanction doit limiter l’acteur concerné, et non réécrire le registre mondial des ressources numériques.

C’est pourquoi une architecture de registre distribué est nécessaire. Dans un système post-RIR, la validité ordinaire n’est pas décidée par RIPE NCC, LACNIC, un service chargé des sanctions, un comité de réunion ou un bureau de parrainage. Les participants valident localement l’état. Les contreparties acceptent ou refusent volontairement. Les bifurcations sont visibles. Les ensembles de compatibilité sont explicites. Le registre central disparaît en tant que source de vérité.

La solution n’est pas une meilleure étiquette.

Ce n’est pas une file de sanctions plus transparente.

La solution consiste à retirer la validité à la fois du club et du point d’étranglement.

État distribué. Validation locale. Acceptation volontaire des contreparties. Aucun registre comme source de validité.

La lettre de la NRO : la voie d’évasion vers le haut

La preuve la plus sérieuse n’est pas le dépassement de pouvoir tenté par AFRINIC.

C’est la réponse collective du système.

En 2022, la Number Resource Organization a écrit au gouvernement mauricien. La lettre décrivait la NRO comme l’organisme de coordination des RIR du monde et affirmait que les RIR gèrent les ressources de numérotation dans leurs régions respectives. Elle indiquait que les cinq registres assurent la fonction d’administration des ressources numériques selon des règles adoptées régionalement ou des politiques mondiales adoptées à l’unanimité. (nro.net)

La même lettre critiquait le contentieux de Cloud Innovation, affirmait que plus de vingt-cinq actions avaient été engagées, se plaignait des ordonnances judiciaires qui avaient gelé les comptes d’AFRINIC et interrompu les élections, et soutenait qu’AFRINIC avait demandé à plusieurs reprises à Maurice d’être reconnue comme organisation internationale. La NRO exhortait le gouvernement à prendre des mesures pour préserver l’indépendance d’AFRINIC et la stabilité d’Internet en Afrique. (nro.net)

C’est le document le plus révélateur de toute l’histoire.

Lorsqu’un registre privé est entré en conflit avec les tribunaux ordinaires, le réflexe du système n’a pas été de réduire la portée du mandat.

Ce n’a pas été de supprimer le verrouillage des registres.

Ce n’a pas été de séparer l’administration des registres de l’exécution.

Ce n’a pas été de définir une validation distribuée.

Ce n’a pas été de se demander si le pouvoir unilatéral de désenregistrement des actifs en fonctionnement était illégitime depuis le départ.

Le réflexe a été une voie d’évasion vers le haut.

Un organisme privé de coordination ne peut pas être technique lorsqu’il veut du pouvoir discrétionnaire, communautaire lorsqu’il veut de la légitimité, contractuel lorsqu’il veut percevoir des frais, non propriétaire lorsqu’il veut éviter la responsabilité, et quasi international lorsqu’il veut l’immunité face aux tribunaux.

Cet ensemble n’est pas une gouvernance.

C’est une forme systémique de « blanchiment de mandat ».

Si les RIR veulent les privilèges du droit public, ils doivent accepter la responsabilité du droit public. S’ils veulent la souplesse du droit privé, ils doivent accepter le contentieux du droit privé. Ce qu’ils ne peuvent pas exiger de manière cohérente, c’est à la fois un pouvoir discrétionnaire privé, une importance d’infrastructure publique, une faible responsabilité, une représentation faible, un statut monopolistique et une immunité quasi diplomatique.

Voilà la voie de l’effondrement.

La Primauté du code en cours d’exécution la rejette.

Lorsqu’un registre rencontre une résistance juridique, il ne doit pas s’échapper vers le haut à la recherche de l’immunité. L’architecture doit se contracter vers le bas, en revenant à la fonction stricte du code en cours d’exécution qui la justifiait à l’origine.

Moins de souveraineté.

Aucun registre comme source de validité.

Moins d’exécution.

Plus de validation distribuée.

La révision de l’ICP-2 ne suffit pas

Le système actuel reconnaît que quelque chose s’est brisé.

La page de commentaires publics de l’ICANN sur le deuxième projet de document de gouvernance des RIR indique que la proposition établirait des règles et des critères pour reconnaître de nouveaux RIR, des obligations opérationnelles et des exigences pour les RIR existants, ainsi que des règles de retrait de reconnaissance ; si elle est adoptée, elle remplacerait l’ICP-2. La même page indique que le processus a été lancé après que la NRO a demandé à l’ASO de proposer des mises à jour afin de rendre le système des RIR davantage responsable devant la communauté Internet. (icann.org)

Cela peut être nécessaire comme mesure de continuité.

Ce n’est pas suffisant comme théorie de la légitimité.

Les règles de reconnaissance et de retrait de reconnaissance répondent à une question tardive : quand un registre a-t-il suffisamment échoué pour être supprimé ?

La question antérieure est plus importante : pourquoi un registre devrait-il disposer d’un pouvoir suffisant pour échouer de manière catastrophique au départ ?

Un successeur de l’ICP-2 qui ne ferait que renforcer la reconnaissance, l’audit, la transition et le retrait de reconnaissance pourrait améliorer l’hygiène institutionnelle tout en préservant l’erreur de catégorie. Il continuerait à supposer que le RIR est la forme souveraine première de coordination des ressources numériques.

La Primauté du code en cours d’exécution pose un autre ensemble de questions.

Comment Internet continue-t-il si un RIR s’effondre ?

Comment les affectations de ressources numériques restent-elles vérifiables sans l’autorisation d’une entité en place ?

Comment l’unicité survit-elle sans pouvoir discrétionnaire monopolistique ?

Comment empêcher les registres de devenir des instruments d’exécution coercitive ?

Comment maintenir les décisions commerciales en dehors de la validité déterministe, sauf lorsqu’un véritable invariant mondial est menacé ?

Comment la coordination reste-t-elle utilisable sans registre faisant autorité ?

Comment un opérateur valide-t-il l’état ordinaire sans consulter un organisme permanent ?

Comment éviter que le refus ne devienne une étiquette d’infraction ?

Ce ne sont pas des questions de réforme.

Ce sont des questions post-RIR.

Pourquoi il s’agit du correctif de la conception originale

Le problème n’est pas de savoir si quelqu’un aime ou non les registres en place.

Le problème est de savoir si la couche des ressources numériques suit encore la discipline de conception qui a rendu Internet possible : règles communes minimales, validation locale, adoption volontaire et code en cours d’exécution.

La Primauté du code en cours d’exécution n’est ni une stratégie de relations publiques ni un compromis institutionnel. C’est la réparation technique implicite dans la conception originale. Si Internet a été construit pour rejeter les rois, les présidents et le vote comme sources de vérité technique, alors la couche des ressources numériques ne peut pas recréer ces formes à travers des processus de registre, la délégation historique ou le théâtre communautaire.

Le consensus seul peut devenir un rituel. Le code en cours d’exécution seul peut être subordonné si la couche du registre est placée au-dessus comme source de reconnaissance. La règle manquante est interprétative et architecturale : lorsque le processus institutionnel entre en conflit avec la fonction technique minimale requise par les systèmes en fonctionnement, le code en cours d’exécution a priorité ; et lorsqu’un changement ultérieur est proposé, il ne devient réel que par l’adoption volontaire des participants qui exécutent les règles de validation.

C’est ainsi que l’on préserve la conception originale, et non qu’on l’abandonne.

Internet était important parce qu’il est devenu le premier système mondial de communications qui ne nécessitait pas l’autorisation préalable d’un souverain unique, d’un ministère, d’une Église, d’une entreprise ou d’un gardien. Si cette réussite mérite toujours d’être défendue, la couche des ressources numériques ne peut pas devenir l’exception qui invalide la règle.

Un système construit pour éviter les rois ne peut pas permettre à un comptable d’aspirer à en devenir un.

Le correctif rétablit la hiérarchie originale : le code d’abord, les opérateurs d’abord, la validation déterministe d’abord, l’état distribué d’abord ; les institutions, si elles existent pendant la transition, ne sont que des artefacts dépourvus d’autorité, jamais des sources de validité.

Ce qu’exige la coordination post-RIR

La coordination post-RIR ne signifie pas le chaos.

Elle signifie que la couche commune devient plus mince, plus objective, plus déterministe et plus distribuée que le monopole actuel des RIR.

Il n’y a pas de registre vers lequel migrer.

Il n’y a pas de nouveau registre à couronner.

Il n’y a pas de nouveau sacerdoce.

Il existe un registre distribué de l’état des ressources de numérotation, avec des règles de validation déterministes, des mécanismes de preuve de contrôle, une gestion des conflits, des ensembles de compatibilité, l’historique des transitions d’état et une vérification locale par les participants.

La couche commune doit préserver l’unicité des identifiants, la preuve de contrôle, l’état des transferts, l’état des délégations, les assertions de sécurité liées au routage, l’auditabilité, les métadonnées de conflit et la visibilité des bifurcations.

La couche des opérateurs doit contrôler l’usage commercial, la location, la géographie des clients, les pratiques de routage, le financement, le choix des contreparties et les règles commerciales qui ne sont pas des invariants.

La couche d’adoption doit déterminer ce qui devient réel. Une règle de coordination n’a d’importance que si les opérateurs peuvent l’implémenter, si les contreparties peuvent l’accepter, si les marchés peuvent lui faire confiance, si les tribunaux peuvent la comprendre et si l’interopérabilité est maintenue sans faire de la reconnaissance par l’institution en place l’unique source de réalité.

La couche d’exécution ne doit pas être fusionnée avec la couche d’état. Un registre distribué peut enregistrer l’état. Il peut valider les transitions. Il peut exposer les conflits. Il peut rendre la preuve portable. Il ne doit pas devenir simultanément procureur, juge, autorité de sanction, régulateur de marché, moraliste commercial et dépositaire des actifs.

Le plus important est de comprendre correctement la portabilité.

Dans un monde de registres distribués, la portabilité ne signifie pas passer d’un registre à un autre. Cela reste une pensée de registre. Il n’y a pas de registre vers lequel migrer. La preuve de contrôle du titulaire, l’historique d’état et la capacité de transfert ne sont pas enfermés dans la base de données d’une institution en place. Ils existent dans un état partagé vérifiable que les participants valident localement et que les contreparties acceptent volontairement.

Sans cela, chaque registre est un point de blocage.

Avec cela, le registre cesse d’être la source de la validité.

Par conséquent, la coordination post-RIR a besoin de quatre propriétés de conception.

Premièrement, une validité déterministe. Un participant doit pouvoir savoir si une transition d’état, une preuve, une délégation, un transfert ou une assertion est valide en appliquant localement la spécification.

Deuxièmement, des ensembles de compatibilité. Si les participants adoptent des règles futures différentes, le système doit décrire clairement les limites de compatibilité au lieu de traiter la dissidence comme une infraction.

Troisièmement, une preuve distribuée du contrôle. Un titulaire ne doit pas « déplacer » ses ressources vers un autre registre ; il doit démontrer son contrôle par un état valide dans le registre que toute contrepartie peut vérifier sans l’approbation de l’institution en place.

Quatrièmement, la visibilité des bifurcations. Si les ensembles de règles divergent, la divergence doit être explicite. Les participants décident quel ensemble de compatibilité exécuter et avec quelles contreparties interagir. Une bifurcation peut isoler des participants, mais elle ne donne pas à l’une des parties le pouvoir institutionnel d’effacer l’autre.

Ce n’est pas un argument en faveur de cinq meilleurs monopoles.

C’est un argument contre le monopole comme source de validité.

Pourquoi la voie de l’échec est prévisible

Si rien ne change, la voie de l’échec est claire.

Premièrement, davantage de différends passeront des salles de politiques aux tribunaux. Les actifs rares attirent l’examen juridique. Les tribunaux seront invités à geler des comptes, à préserver des registres, à bloquer des élections irrégulières, à nommer des administrateurs judiciaires, à reconnaître des transferts ou à déterminer qui peut agir au nom d’un registre.

Deuxièmement, les États cesseront de considérer les RIR comme des associations techniques inoffensives. La continuité de l’adressage touche la connectivité nationale, les sanctions, l’application de la loi, la résilience des télécommunications, l’infrastructure cloud et la sécurité économique. Aucun État n’acceptera indéfiniment une entité privée étrangère comme point ascendant incontesté de la continuité des communications nationales.

Troisièmement, les opérateurs contourneront l’autorité du registre lorsque cela sera possible. Si les registres deviennent politiques, peu sûrs, non représentatifs ou déconnectés de la réalité des actifs, les opérateurs se tourneront vers des contrats privés, des transferts soutenus par des contentieux, des certifications alternatives, une reconnaissance nationale ou la réalité de fait du routage.

Quatrièmement, les couches de l’ICANN et de la NRO seront tentées de centraliser. Cela produirait une version plus dense du même problème, à moins que le mandat lui-même ne soit réduit.

Cinquièmement, les gouvernements seront tentés de nationaliser. Ce serait prévisible et dangereux. Si les registres privés revendiquent une autorité quasi souveraine sans responsabilité publique, les États finiront par revendiquer la souveraineté. Le résultat pourrait être la fragmentation, les représailles, des registres en conflit et une pression politique sur le routage.

Internet n’échoue pas seulement lorsque les paquets cessent de circuler.

Il échoue aussi lorsque les institutions qui décrivent qui peut utiliser les identifiants perdent la confiance des opérateurs qui font circuler ces paquets.

Un registre distribué ne résout pas tous les problèmes politiques. Mais il accomplit quelque chose de plus important : il élimine le registre permanent comme source ordinaire de validité. Cela réduit la surface d’attaque. Cela réduit le pouvoir institutionnel de prise d’otages. Cela transforme les désaccords futurs en sélection de compatibilité plutôt qu’en guerre administrative.

La question change

L’ancien système demande : qui détient le mandat ?

C’est la mauvaise question.

La meilleure question est : qu’exige réellement le code en cours d’exécution ?

Cette règle protège-t-elle l’unicité ?

Préserve-t-elle l’interopérabilité ?

Corrige-t-elle une fraude d’enregistrement démontrable au moyen de preuves déterministes ?

Protège-t-elle la sécurité liée au routage ?

Maintient-elle l’exactitude de la preuve de contrôle ?

Permet-elle la validation locale ?

Élimine-t-elle la dépendance à une seule institution en place ?

Décrit-elle la réalité adoptée ou déclare-t-elle une obligation non adoptée ?

Un participant peut-il la rejeter sans être étiqueté invalide ?

Un participant peut-il vérifier la validité ordinaire sans demander un état à un registre ?

Une contrepartie peut-elle accepter ou rejeter l’état volontairement ?

Une bifurcation peut-elle se produire sans que l’une des parties soit supprimée par une institution ?

Si la réponse n’est pas liée à la nécessité déterministe du code en cours d’exécution, ce pouvoir ne devrait pas résider dans la couche commune.

C’est cela, la Primauté du code en cours d’exécution.

Pour discussion

Cette proposition est destinée à la discussion. Ce n’est pas une solution finale.

La prochaine étape devrait être un véritable Internet-Draft ou un document de type BCP définissant la Primauté du code en cours d’exécution pour les systèmes de coordination d’Internet, en commençant par les ressources numériques. Le projet ne devrait pas demander comment réhabiliter le monopole des RIR. Il devrait demander comment construire une coordination post-RIR au moyen d’un état dans un registre distribué, d’une validation déterministe, d’une adoption volontaire, de l’acceptation par les contreparties et d’ensembles de compatibilité explicites.

Il devrait être évalué par des opérateurs, des juristes, des économistes, des ingénieurs de protocoles, des experts de la sécurité du routage, des acteurs du marché, des gouvernements et des critiques.

Le projet devrait poser des questions difficiles.

Quels sont les invariants mondiaux ?

Quelles règles de validation sont déterministes ?

Quelles transitions d’état doivent être visibles mondialement ?

Quels anciens pouvoirs du registre sont des vestiges historiques ?

Quelles décisions appartiennent aux opérateurs ?

Quelles décisions ne nécessitent pas de représentation parce qu’elles ne devraient jamais entrer dans la couche commune ?

Quelle est la voie du rejet ?

Quelle est la voie de la bifurcation ?

Quelle est la voie du rejet local ?

Comment un titulaire démontre-t-il son contrôle sans registre en place ?

Comment une contrepartie vérifie-t-elle l’état sans registre ?

Internet peut-il continuer si un RIR s’effondre ?

Les ressources numériques peuvent-elles rester uniques sans la permission d’une institution en place ?

Un participant peut-il valider l’état ordinaire sans institution permanente ?

Un processus de politiques peut-il distinguer un invariant du code en cours d’exécution de la volonté institutionnelle ?

L’ancienne couche des registres peut-elle disparaître sans perte de l’état vérifiable ?

Un registre peut-il décrire la réalité sans devenir souverain sur elle ?

Toute personne intéressée peut me contacter via LinkedIn. Les chercheurs sérieux, les auteurs techniques, les institutions ou les experts en politiques qui souhaitent contribuer à transformer cela en un premier Internet-Draft puis éventuellement en RFC ou en discussion BCP, si la communauté le juge utile, peuvent me contacter. La LARUS Foundation et moi sommes prêts à soutenir et à financer une recherche sérieuse dans cette direction.

Le système des RIR a échoué dans sa conception initiale parce qu’il n’a jamais demandé ce qu’exigeait réellement le code en cours d’exécution.

Il a demandé qui pouvait parler dans la salle.

Le système suivant doit inverser cet ordre.

Ce n’est pas du blanchiment de mandats.

Ce n’est pas une trahison du code en cours d’exécution.

La Primauté du code en cours d’exécution.

Annexe : Spécification initiale minimale, décision future localisée et adoption volontaire pour les systèmes de coordination d’Internet

Note 64

Résumé

Ce document décrit un modèle de conception pour les systèmes de coordination d’Internet dont l’objectif est de fournir des points de référence techniques partagés sans créer d’autorité permanente au-dessus des participants qui exécutent le système. Il définit trois principes liés : Spécification initiale minimale, Décision future localisée et Adoption volontaire.

Dans ce modèle, la Spécification initiale définit uniquement les règles déterministes et vérifiables localement nécessaires à l’unicité, à l’interopérabilité, à la preuve de contrôle, à la sécurité partagée et à la sécurité. Après la Spécification initiale, les changements futurs ne sont pas approuvés par un organisme central. Ils sont adoptés, ignorés, bifurqués ou abandonnés par les participants qui exécutent le code.

Le modèle de conception envisagé est un registre distribué d’états valides, ou un mécanisme équivalent d’état vérifiable distribué, et non une hiérarchie de registres. Il n’existe pas de registre permanent qui décide de la validité ordinaire. Les participants valident localement l’état, acceptent volontairement les contreparties et décident quels ensembles de compatibilité ils exécutent.

La non-adoption n’est pas une infraction. Un participant qui n’adopte pas un changement ultérieur reste dans son ensemble de compatibilité existant. Un participant qui émet des états non valides selon les règles déterministes acceptées par un autre participant peut être ignoré localement par celui-ci. L’effet est une sélection de compatibilité, une bifurcation, un isolement ou une interopérabilité sélective, et non une sanction institutionnelle.

Ce document ne définit pas un protocole réseau (wire protocol). Il spécifie des bonnes pratiques actuelles (BCP) pour la conception de protocoles, de systèmes d’identifiants, de registres distribués et de mécanismes de coordination qui ne doivent pas devenir des institutions permanentes de gouvernance.

1. Introduction

De nombreux systèmes Internet commencent avec un objectif technique limité : permettre à des acteurs indépendants d’interopérer au moyen d’un point de référence commun, d’un espace d’identifiants, d’une règle de validation, de l’état d’un registre distribué ou d’un registre partagé de preuve de contrôle. Avec le temps, ces systèmes accumulent souvent une autorité qui n’était pas nécessaire à l’interopérabilité initiale.

Cela se produit normalement en trois étapes.

Premièrement, les questions futures sont intégrées à la couche fondamentale avant d’être techniquement nécessaires.

Deuxièmement, les décisions qui devraient être prises par les participants exécutant leurs propres systèmes deviennent dépendantes de la reconnaissance, de l’interprétation ou des décisions relatives au statut prises par un organisme permanent.

Troisièmement, la publication, l’enregistrement, la recommandation ou l’approbation procédurale sont traités comme suffisants pour créer des obligations opérationnelles, même lorsque les participants n’ont pas adopté le changement dans les systèmes en fonctionnement.

Le résultat est un système fragile. Une couche de référence technique devient une couche de gouvernance. Un registre devient un point de contrôle. Un artefact de coordination devient une source de contrôle futur.

Ce document propose une discipline de conception différente :

Spécification initiale minimale : définir uniquement les règles déterministes communes nécessaires à l’interopérabilité de base, à l’unicité, à la preuve de contrôle, à la sécurité partagée et à la sécurité.

Décision future localisée : après la Spécification initiale, maintenir les décisions futures chez les participants qui exécutent le code. Un participant peut adopter, rejeter, bifurquer, se déconnecter ou interopérer sélectivement. Aucun participant ne peut modifier l’interopérabilité des autres participants qui continuent d’exécuter des règles mutuellement compatibles.

Adoption volontaire : faire en sorte que les changements ultérieurs ne deviennent réels que par l’implémentation, l’exploitation, la validation et l’adoption par les participants qui exécutent le code.

Ces principes sont liés. Un système qui spécifie trop de choses au départ précharge le contrôle futur dans la couche commune. Un système qui conserve une couche de reconnaissance continue permet à l’autorité de réapparaître après le déploiement. Un système qui traite la publication comme la réalité transforme la documentation en mandat.

L’intuition de conception est simple : la validité doit être déterminée par des règles déterministes que les participants peuvent vérifier localement contre un état partagé. Un participant peut adopter un changement ultérieur, le rejeter, bifurquer, se déconnecter ou interopérer sélectivement. Au plus, il peut sortir d’un ensemble de compatibilité. En rejetant un changement, il ne peut pas casser l’interopérabilité des autres participants qui continuent d’exécuter des règles mutuellement compatibles.

C’est la leçon générale de la conception des registres distribués : les règles de consensus sont appliquées par des participants qui exécutent un code de validation et décident quel état ils acceptent, et non par une institution située au-dessus d’eux.

2. Champ d’application

Ce document s’applique aux systèmes de coordination d’Internet, notamment aux systèmes d’identifiants, aux cadres de noms et de numérotation, aux mécanismes d’extension de protocoles, aux systèmes de preuve de contrôle, aux systèmes de portabilité, aux registres distribués et aux autres architectures dans lesquelles des acteurs indépendants dépendent d’un point de référence technique commun.

Ce document ne s’oppose pas aux règles communes. Il soutient que les règles communes doivent être déterministes, minimales, vérifiables localement et limitées à ce dont le système a réellement besoin pour fonctionner.

Ce document n’exige aucune implémentation particulière d’un registre distribué. Il exige une propriété de conception : les participants doivent pouvoir déterminer la validité en appliquant localement la Spécification initiale à un état partagé ou réplicable, sans demander la permission ou le statut à une autorité permanente.

3. Conventions et définitions

3.1. Langage des exigences

Les termes d’exigence en majuscules dans ce document doivent être interprétés au sens défini par le BCP 14, en particulier les RFC 2119 et RFC 8174.

3.2. Terminologie

Spécification initiale :
Ensemble des règles, structures de données, formats, invariants, procédures de validation, règles de transition d’état et règles de conflit nécessaires au premier déploiement d’un système.

Couche commune (Common Layer) :
Ensemble minimal de règles partagées ou structure de référence nécessaire pour que des participants indépendants interopèrent. La couche commune n’est pas une institution. C’est la substance technique que les participants implémentent et vérifient.

Registre distribué (Distributed Ledger) :
Registre répliqué ou autrement distribué des transitions d’état, permettant aux participants de vérifier la validité ordinaire sans dépendre d’un registre permanent, d’un comité ou d’une autre autorité. Le terme n’exige aucun algorithme de consensus ni implémentation particulière.

Règle de validation déterministe (Deterministic Validation Rule) :
Règle permettant à un participant de décider, par calcul ou vérification locale, si un état, un enregistrement, une transition, une assertion ou un message est valide selon un ensemble de règles spécifié.

Invariant mondial (Global Invariant) :
Propriété qui doit rester commune au sein d’un ensemble de compatibilité afin de préserver l’unicité, l’interopérabilité de base, l’intégrité de la preuve de contrôle, la sécurité partagée ou la sécurité.

Participant (Participant) :
Opérateur, implémentation, nœud, réseau, organisation ou autre acteur qui exécute, vérifie, déploie le système ou en dépend.

Ensemble de compatibilité (Compatibility Set) :
Groupe de participants dont les règles de validation implémentées leur permettent d’interopérer. Un changement ultérieur peut créer un nouvel ensemble de compatibilité si certains participants l’adoptent et d’autres non.

Adoption (Adoption) :
Implémentation, déploiement, validation et utilisation réelles par les participants qui exécutent le système.

Acceptation de la contrepartie (Counterparty Acceptance) :
Décision volontaire d’un participant d’accepter, de réaliser des transactions, d’interopérer ou de faire confiance à l’état d’un autre participant selon les règles de validation qu’il exécute.

Non-adoption (Non-Adoption) :
Décision d’un participant de ne pas implémenter ou utiliser un changement proposé. La non-adoption ne crée pas un état d’invalidité. Elle signifie seulement que le participant n’est pas entré dans l’ensemble de compatibilité créé par ce changement.

Rejet local (Local Rejection) :
Décision locale d’un participant d’ignorer, de rejeter ou de ne pas interopérer avec un état, un message, un enregistrement ou une transition invalide ou incompatible selon les règles de validation qu’il exécute.

Bifurcation (Fork) :
Divergence des règles de validation ou de la pratique opérationnelle qui crée deux ensembles de compatibilité ou davantage.

Artefact de coordination (Coordination Artifact) :
Document, recommandation, note d’implémentation, profil, implémentation de référence, explorateur de registre, réplique ou autre artefact qui aide les participants à se coordonner. Un artefact de coordination ne crée pas une réalité opérationnelle contraignante tant que les participants ne l’ont pas adopté dans des systèmes en fonctionnement.

4. Énoncé du problème

Les concepteurs tentent souvent de réduire l’incertitude future en écrivant trop de choses dans la couche fondamentale ou en laissant à un organisme permanent l’interprétation des questions futures. Cela semble prudent. C’est souvent dangereux.

La surspécification de la couche fondamentale a trois coûts.

Premièrement, elle transfère les décisions futures vers une couche commune où le changement est plus difficile et où la capture a un effet plus important.

Deuxièmement, elle crée une ambiguïté entre validité technique et reconnaissance institutionnelle.

Troisièmement, elle incite un organisme qui tient des registres, publie des documents ou réunit des participants à traiter ces actes comme une autorité sur la réalité future.

Le même problème apparaît après le déploiement. Si un système exige un organisme permanent pour approuver les changements, déterminer les statuts ou interpréter le fonctionnement ordinaire, le système a créé une couche de contrôle postérieure à la fondation. Cette couche peut commencer comme une administration. Elle peut devenir une gouvernance. Elle peut devenir un point d’étranglement.

L’objectif de conception de ce document n’est pas d’améliorer l’exercice du pouvoir discrétionnaire des institutions. L’objectif est d’éviter d’avoir besoin de ce pouvoir.

Un système de coordination d’Internet bien conçu devrait définir dès le départ des règles de validité déterministes et vérifiables localement ; représenter l’état valide sous une forme distribuée ou réplicable ; maintenir les décisions qui ne sont pas des invariants en dehors de la couche commune ; et permettre aux changements ultérieurs de devenir réels uniquement lorsque les participants les adoptent volontairement dans des systèmes en fonctionnement.

5. Principe 1 : Spécification initiale minimale

5.1. Déclaration

Une Spécification initiale DEVRAIT définir uniquement les règles communes déterministes minimales nécessaires à l’interopérabilité de base, à l’unicité, à la preuve de contrôle, à la sécurité partagée et à la sécurité.

5.2. Exigences

Une conception qui utilise ce principe :

• DOIT identifier explicitement ses Invariants mondiaux.
• DOIT définir des règles de validation déterministes pour chaque Invariant mondial.
• DOIT définir comment l’état valide est représenté, répliqué, vérifié et mis à jour.
• NE DOIT PAS inclure une règle dans la Spécification initiale à moins qu’elle ne soit nécessaire pour préserver un Invariant mondial déclaré ou permettre le déploiement initial.
• DOIT séparer les règles de validation des préférences en matière de politique, des accords commerciaux, des rôles institutionnels, des aspirations de gouvernance et du jugement discrétionnaire.
• DOIT permettre aux participants de vérifier localement la validité ordinaire sans demander d’information à une institution, un registre, un comité, un organisme de politiques ou une autre autorité.
• DEVRAIT définir les structures de données, les signatures, les preuves, les règles de transition d’état, les règles de conflit ou les autres mécanismes nécessaires à la vérification locale.
• DEVRAIT définir la signalisation des extensions, le versionnage, l’étiquetage de compatibilité ou l’identification des bifurcations lorsque la variation future est prévisible.
• DOIT garantir que les artefacts de coordination requis soient portables, auditables, reproductibles et remplaçables.
• DEVRAIT privilégier des conditions objectives vérifiables par machine plutôt que des jugements subjectifs de mérite.
• NE DOIT PAS faire de la reconnaissance institutionnelle future la seule voie par laquelle un état valide peut être connu, enregistré ou utilisé.

5.3. Implications de conception

La Spécification initiale minimale ne signifie pas une spécification vague. Elle signifie une spécification stricte de ce qui doit être commun, et de cela seulement.

Un système a toujours besoin d’une structure commune suffisante pour fonctionner. La discipline consiste à distinguer :

• ce qui doit être commun pour l’unicité, l’interopérabilité, la preuve de contrôle, la sécurité partagée et la sécurité ; et
• ce qui peut rester en dehors de la couche commune parce que cela relève de la préférence de l’opérateur, de la pratique commerciale, du choix de la contrepartie, du calendrier de déploiement ou de décisions d’adoption ultérieures.

Une conception qui ne peut pas exprimer clairement ses Invariants mondiaux et ses règles de validation déterministes devrait partir du principe qu’elle a prévu trop de pouvoir discrétionnaire et trop peu de substance vérifiable.

6. Principe 2 : Décision future localisée

6.1. Déclaration

Après la Spécification initiale, les Décisions futures DEVRAIENT rester locales aux participants qui exécutent le code. Une Décision future ne devient effective que pour l’ensemble de compatibilité dont les participants l’adoptent. Aucune autorité permanente n’est nécessaire pour l’approuver, et la non-adoption ne crée pas un état d’invalidité.

6.2. Exigences

Une conception qui utilise ce principe :

• NE DOIT PAS exiger que les participants obtiennent la permission d’une institution en place, d’un registre, d’un comité, d’un conseil, d’un organisme de politiques ou d’une autre autorité pour des décisions qui ne modifient pas les règles de validation déterministes de l’ensemble de compatibilité auquel ils appartiennent.
• NE DOIT PAS créer un organisme permanent dont la reconnaissance est la seule voie par laquelle un changement ultérieur peut devenir une réalité opérationnelle.
• DOIT distinguer la validité selon la Spécification initiale de la compatibilité avec un changement ultérieur facultatif.
• NE DOIT PAS traiter la non-adoption d’un changement ultérieur comme une invalidité.
• DOIT permettre aux participants de rester dans un ensemble de compatibilité existant lorsqu’ils n’adoptent pas un changement ultérieur.
• DOIT permettre aux participants de rejoindre un nouvel ensemble de compatibilité en adoptant de nouvelles règles de validation ou de nouveaux profils opérationnels.
• DOIT permettre aux participants de rejeter localement des états, des enregistrements, des transitions ou des messages invalides ou incompatibles selon les règles de validation qu’ils exécutent.
• DOIT permettre aux participants de choisir volontairement des contreparties selon les règles de validation et les ensembles de compatibilité qu’ils acceptent.
• NE DOIT PAS autoriser une institution, un registre, un comité, un organisme de politiques ou un autre acteur à déclarer un participant invalide uniquement parce qu’il a rejeté un changement ultérieur.
• DEVRAIT rendre explicites les bifurcations, versions, profils ou ensembles de compatibilité, afin que les participants sachent quelles règles ils exécutent et avec quels autres participants ils peuvent interopérer.
• DEVRAIT éviter toute conception dans laquelle un registre en place pourrait empêcher des participants qui restent valides de continuer à interopérer.

6.3. Implications de conception

La Décision future localisée ne signifie pas qu’une autorité centrale attribue les décisions futures à des acteurs locaux. Elle signifie que le système est conçu de telle sorte qu’après la Spécification initiale, les décisions futures ordinaires ne requièrent pas cette attribution.

La Spécification initiale accomplit à l’avance le travail de limitation. Elle définit les invariants minimaux nécessaires à l’unicité, à l’interopérabilité, à la preuve de contrôle, à la sécurité partagée et à la sécurité. Tout le reste demeure en dehors de la couche commune.

Le changement futur n’est pas approuvé centralement. Il est adopté, ignoré, bifurqué ou abandonné par les participants qui exécutent le code.

Un participant qui rejette un changement peut rester en dehors de l’ensemble de compatibilité créé par celui-ci. Il peut se déconnecter des autres. Il peut continuer dans un ensemble de compatibilité antérieur. Il peut bifurquer. Il peut interopérer sélectivement. Mais il ne peut pas casser l’interopérabilité des autres participants qui continuent d’exécuter des règles mutuellement compatibles.

L’effet d’un état invalide ou incompatible est le rejet local, et non la sanction. Il n’est pas nécessaire que quelqu’un détermine qu’un participant est en tort. Un participant qui exécute des règles de validation compatibles n’accepte tout simplement pas l’état invalide ou incompatible.

7. Principe 3 : Adoption volontaire

7.1. Déclaration

Les changements dans un système de coordination d’Internet DEVRAIENT devenir une réalité opérationnelle par l’implémentation, la validation, le déploiement, l’acceptation par les contreparties et l’adoption par les participants, et non par la seule publication ou déclaration.

7.2. Exigences

Une conception qui utilise ce principe :

• NE DOIT PAS considérer la publication, la recommandation, l’approbation en réunion ou l’approbation procédurale comme suffisante pour créer une obligation opérationnelle universelle.
• DOIT permettre aux participants qui décident de les exécuter de déployer progressivement de nouvelles règles, extensions, profils ou procédures.
• DOIT permettre aux participants de rejeter un changement ultérieur sans acquérir un état d’invalidité, à condition que leurs propres transitions d’état respectent les règles déterministes de leur ensemble de compatibilité.
• DOIT permettre aux participants de continuer à utiliser un ensemble de compatibilité antérieur lorsque la Spécification initiale permet cette continuité.
• DOIT permettre aux participants opérant dans un ensemble de compatibilité de rejeter ou d’ignorer localement les états d’un autre ensemble lorsque les règles sont incompatibles.
• DEVRAIT définir des voies d’adoption pour les changements importants, notamment la signalisation des versions, l’étiquetage de compatibilité, les guides de transition et les vecteurs de test.
• DEVRAIT définir des voies de rejet pour les changements importants, notamment la manière dont les participants non adoptants continuent à fonctionner, identifient leur ensemble de compatibilité et évitent une interopérabilité ambiguë.
• DOIT garantir que les artefacts de coordination nécessaires puissent être abandonnés, répliqués, réimplémentés ou remplacés sans coûts de transition impossibles.
• DEVRAIT faire en sorte que les registres, recommandations et artefacts de coordination décrivent la réalité adoptée, plutôt que de tenter de déclarer existante une réalité future non adoptée.
• NE DOIT PAS concevoir un système dans lequel la seule façon pour qu’un changement devienne réel est sa reconnaissance préalable par un organisme en place.

7.3. Implications de conception

L’Adoption volontaire est le test opérationnel qui permet de vérifier qu’un changement est utile, tolérable et compatible avec le déploiement réel.

Une proposition n’est pas la réalité. Une recommandation n’est pas la réalité. Un document n’est pas la réalité. La réalité apparaît lorsque les participants implémentent, valident, déploient, acceptent des contreparties et dépendent du changement.

La non-adoption ne crée aucun état d’infraction. Elle crée seulement un fait : le participant n’est pas entré dans l’ensemble de compatibilité créé par le changement.

Cela ne supprime ni les processus de normalisation, ni la documentation, ni les notes d’implémentation, ni les explorateurs, ni les répliques, ni les examens. Cela en limite la portée. Ils peuvent aider les participants à se coordonner. Ils peuvent publier des documents de référence. Ils peuvent décrire l’adoption. Ils peuvent recommander. Mais ils ne peuvent pas, à eux seuls et par une déclaration, rendre contraignante une réalité future non adoptée pour les participants qui ne l’exécutent pas.

8. Relation entre les trois principes

Les trois principes se renforcent mutuellement et ne sont pas efficaces isolément.

La Spécification initiale minimale garantit que la couche commune contient des règles de validation déterministes plutôt qu’une autorité discrétionnaire.

La Décision future localisée garantit que les décisions futures restent chez les participants qui exécutent le code, au lieu d’être reprises par une couche centrale d’approbation.

L’Adoption volontaire garantit que les changements ultérieurs doivent survivre au contact de l’implémentation, de la vérification, de l’acceptation par les contreparties et de l’usage.

Un système qui n’adopte qu’un ou deux de ces principes peut reproduire la même centralisation par d’autres moyens.

La Spécification initiale minimale sans Décision future localisée peut encore permettre l’accumulation d’autorité après le déploiement.
La Décision future localisée sans Spécification initiale minimale peut produire de l’ambiguïté, car les participants ne peuvent pas déterminer localement la validité.
L’Adoption volontaire sans validation déterministe peut produire de la confusion, car les participants ne peuvent pas distinguer les variations compatibles des états invalides.
La validation déterministe sans état distribué peut encore laisser les participants dépendants d’un registre privilégié.
L’état distribué sans visibilité des bifurcations peut cacher le désaccord jusqu’à la défaillance opérationnelle.
L’état distribué sans acceptation volontaire des contreparties peut recréer la coercition par une autre interface.

Ensemble, les principes produisent un système dans lequel la couche commune est mince, la validité est vérifiable localement, le changement futur est volontaire, l’état est distribué et aucune institution permanente n’est nécessaire pour décider du fonctionnement ordinaire.

9. Modèle de conception recommandé

9.1. Couche commune distribuée et déterministe

La couche commune DEVRAIT se limiter à :

• une sémantique stable des identifiants ;
• des règles de validité déterministes ;
• des règles de résolution des conflits nécessaires pour préserver l’unicité ;
• des mécanismes de preuve de contrôle ;
• des règles de transition d’état ;
• des exigences d’interopérabilité au niveau du réseau ou du protocole ;
• des invariants de sécurité partagés ;
• des formats d’état portables et auditables ;
• la visibilité de l’état distribué ou répliqué ;
• la signalisation des extensions et l’identification des ensembles de compatibilité.

La couche commune NE DEVRAIT PAS contenir :

• des règles de modèles économiques ;
• des règles de prix ;
• des préférences politiques régionales ;
• une idéologie d’éligibilité sans rapport avec les invariants techniques ;
• des pouvoirs d’exécution discrétionnaires ;
• des évaluations subjectives du mérite ;
• une extension de la mission institutionnelle ;
• toute règle dont la fonction principale est de préserver l’autorité d’un organisme en place.

9.2. Surface de décision de l’opérateur

Les éléments suivants DEVRAIENT rester en dehors de la couche commune, sauf s’ils modifient directement un Invariant mondial déclaré :

• le calendrier de déploiement ;
• l’usage commercial ;
• la géographie des clients ;
• les accords de location, de financement ou de transfert ;
• la préférence locale en matière d’éligibilité ;
• le séquençage opérationnel ;
• la pratique de routage non nécessaire à la validité partagée ;
• le modèle économique ;
• la structure organisationnelle ;
• le calendrier de migration volontaire ;
• les profils ou extensions facultatifs ;
• le choix des contreparties.

Les participants PEUVENT adopter des décisions différentes dans ces domaines. Ces décisions peuvent produire des ensembles de compatibilité, des relations commerciales, des accords de peering ou des communautés opérationnelles différents. Elles ne créent pas d’invalidité, sauf si elles violent des règles de validation déterministes au sein d’un ensemble de compatibilité.

9.3. Cycle d’adoption

Lorsque cela est possible, l’ordre privilégié pour les changements substantiels du système est :

• proposition ;
• implémentation ;
• vecteurs de test ou méthode de vérification déterministe ;
• déploiement limité par les participants qui le souhaitent ;
• observation des effets sur l’interopérabilité et la sécurité ;
• étiquetage des ensembles de compatibilité ;
• documentation ou recommandation décrivant la réalité adoptée.

Un artefact de coordination DEVRAIT suivre l’adoption plutôt que tenter de l’anticiper.

9.4. Bifurcation, rejet local et acceptation de la contrepartie

Une conception conforme DEVRAIT traiter la bifurcation, le rejet local et l’acceptation des contreparties comme des exigences normales de conception, et non comme des échecs.

Le système DEVRAIT définir comment un participant peut :

• rester dans un ensemble de compatibilité antérieur ;
• adopter un nouvel ensemble de compatibilité ;
• bifurquer vers un ensemble de compatibilité différent ;
• vérifier l’état sans dépendre d’un registre en place ;
• accepter volontairement des contreparties ;
• rejeter localement des états invalides ou incompatibles ;
• interopérer sélectivement lorsque la compatibilité le permet.

Un système qui ne peut ni être bifurqué, ni être vérifié localement, ni interopérer sélectivement sans compromettre un fonctionnement valide a probablement dissimulé un pouvoir de gouvernance dans sa fonction de registre.

10. Applicabilité et limites

Ce modèle de conception est particulièrement applicable lorsque :

• le système est multi-acteurs et multijuridictionnel ;
• le déploiement indépendant est important ;
• la couche de coordination est destinée à rester mince ;
• une variation future est probable mais ne peut pas être prédite dans le détail ;
• le verrouillage ou la dépendance (lock-in) créerait un risque de gouvernance ;
• la validité peut être rendue déterministe ou vérifiable localement ;
• l’état distribué peut réduire le risque de capture institutionnelle.

Il peut être moins directement applicable lorsque :

• l’architecture prévue relève d’un seul domaine administratif ;
• un couplage fort en temps réel exige un comportement uniforme à tout moment ;
• des considérations de sécurité vitale exigent une uniformité mondiale immédiate ;
• la validité ne peut être vérifiée localement par aucun mécanisme pratique.

Même dans ces cas, les concepteurs DEVRAIENT continuer à minimiser la couche commune et à éviter autant que possible le contrôle discrétionnaire futur.

11. Non-objectifs

Ce document :

• n’interdit pas toute coordination ;
• n’exige aucune implémentation particulière de registre distribué ;
• ne garantit pas le consensus ;
• ne garantit pas la neutralité politique ;
• n’exige pas que tous les participants adoptent chaque changement ultérieur ;
• ne traite pas le refus d’adopter comme une invalidité ;
• ne légitime pas un comportement local incompatible sous prétexte de compatibilité ;
• ne supprime pas la nécessité de règles communes critiques pour la sécurité.

12. Considérations de sécurité

Une couche de coordination plus mince peut réduire le risque de capture, diminuer le rayon d’impact des erreurs institutionnelles et améliorer la capacité de remplacement. Cependant, une plus grande latitude décisionnelle au niveau local et un état distribué peuvent également créer des postures de sécurité incohérentes, des voies de dégradation, une pression à la fragmentation, des assertions de compatibilité ambiguës, des bifurcations dangereuses, des différends sur l’état du registre et des tentatives de falsification des preuves.

Par conséquent, les concepteurs qui appliquent ce document DOIVENT spécifier explicitement les invariants de sécurité. En particulier :

• les exigences d’authentification et d’autorisation nécessaires à la validité partagée DOIVENT être déterministes et vérifiables localement ;
• les mécanismes de preuve de contrôle DOIVENT résister à la falsification, à la répétition et au transfert non autorisé ;
• la négociation des versions et la gestion des extensions DOIVENT empêcher les dégradations silencieuses lorsque la sécurité est affectée ;
• les voies de rejet, de bifurcation et de remplacement DOIVENT être analysées au regard du risque d’abus et de déni de service ;
• les étiquettes de compatibilité DEVRAIENT être suffisamment claires pour éviter l’interopérabilité accidentelle entre des ensembles de règles incompatibles ;
• l’état distribué DEVRAIT être auditable et reproductible afin de détecter les vues incohérentes ;
• la variation locale NE DOIT PAS pouvoir déclarer faussement sa compatibilité avec un ensemble de règles auquel elle ne se conforme pas.

L’existence d’exceptions de sécurité ne justifie pas une couche générale d’autorisations. Elle justifie uniquement les règles de sécurité déterministes nécessaires pour préserver les Invariants mondiaux déclarés.

13. Considérations relatives à l’IANA

Ce document ne nécessite aucune action de la part de l’IANA.

14. Références

14.1. Références normatives

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

14.2. Références informatives

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

Annexe A. Liste de contrôle de conception

Une conception qui revendique sa conformité à ce document DEVRAIT pouvoir répondre clairement aux questions suivantes :

• Quels sont les Invariants mondiaux ?
• Quelles règles de validation déterministes préservent ces Invariants mondiaux ?
• Quelles règles de la Spécification initiale sont strictement nécessaires au premier déploiement ?
• Comment l’état valide est-il représenté et vérifié ?
• L’état est-il distribué, répliqué ou autrement vérifiable indépendamment ?
• Quelles questions futures sont intentionnellement laissées en dehors de la couche commune ?
• Quelles décisions futures les participants peuvent-ils prendre sans modifier l’ensemble de compatibilité dans lequel ils se trouvent ?
• Comment un participant adopte-t-il un changement ultérieur ?
• Comment un participant rejette-t-il un changement ultérieur sans se voir attribuer un état d’invalidité ?
• Comment les ensembles de compatibilité sont-ils étiquetés ou découverts ?
• Comment fonctionne le rejet local lorsqu’un état est invalide ou incompatible selon les règles exécutées par un participant ?
• Quelle est la voie de bifurcation ?
• Comment un titulaire démontre-t-il son contrôle sans registre en place ?
• Comment une contrepartie vérifie-t-elle l’état sans registre ?
• Les participants peuvent-ils vérifier la validité ordinaire sans dépendre d’un registre en place ?
• Les registres et les artefacts de coordination décrivent-ils la réalité adoptée ou tentent-ils de déclarer existante une réalité future non adoptée ?
• Le système a-t-il minimisé le nombre de décisions intégrées à la couche commune ?
• Le système a-t-il évité toute autorité permanente qui détermine l’état ordinaire des participants ?
• Les participants peuvent-ils accepter ou rejeter volontairement des contreparties ?
• Le système peut-il continuer si tous les registres en place disparaissent ?

Adresse de l’auteur

Lu
[TBD]