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 :

1. Note 52 — Lorsque le pouvoir du registre se détache de la responsabilité : pourquoi le modèle actuel de coordination des RIR ne peut survivre sous sa forme présente
2. Note 53 — Les ressources de numérotation Internet ne sont pas une propriété politique
3. Note 56 — Comment la gouvernance lourde des registres Internet régionaux transforme l’unicité en double extraction
4. Note 58 — De la double extraction à l’inversion de souveraineté : comment les nations perdent leur contrôle souverain au profit des RIR pour 100 dollars américains
5. Note 59 — La pénalité de pauvreté : comment le modèle des RIR taxe les pauvres tout en appelant cela l’égalité
6. Note 61 — La trahison du code en fonctionnement : comment le système des RIR a retourné le consensus contre la communauté technique
7. Note 62 — Le blanchiment de mandat : du fantasme des RIR à une architecture de transition

Les sept essais précédents ne constituaient pas un programme de réforme des registres Internet régionaux.

Ils constituaient une autopsie.

Ils ont suivi la même pathologie institutionnelle à travers différentes couches : la responsabilité détachée de ses conséquences ; les ressources de numérotation rebaptisées propriété politique ; l’unicité transformée en double extraction ; la souveraineté inversée ; la pauvreté taxée au nom de l’égalité ; le consensus retourné contre les réseaux qu’il était censé servir ; et enfin le mandat blanchi jusqu’à ce qu’un greffier commence à parler comme un souverain. La séquence est importante, car l’échec ne provenait pas d’un mauvais conseil d’administration, d’un mauvais registre, d’un procès ou d’un événement de marché inconfortable. Il s’agissait d’un défaut systémique apparaissant sous différentes formes. La page d’auteur de CircleID montre désormais clairement cette séquence, notamment Running-Code Betrayal et Mandate Laundering. (circleid.com)

Cet essai ne porte pas sur la manière de faire des RIR de meilleurs gouvernants.

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

Ce complément est la primauté du code en fonctionnement.

Sa nécessité n’est plus théorique. Dans un récent échange sur CircleID, John Curran a présenté la forme la plus solide de l’argument des institutions en place. Selon lui, l’autorité du système des RIR n’est pas simplement un sous-produit d’une coordination technique étroite, mais le résultat d’une chaîne historique : le Livre blanc, l’ICANN, l’ASO, ICP-2, la transition de la supervision de l’IANA et la poursuite d’une gouvernance multipartite du secteur privé. Il affirme que l’autorité du système des RIR résulte de son fonctionnement dans le cadre du modèle multipartite du secteur privé demandé par le gouvernement américain. (circleid.com)

Cet argument est utile parce qu’il rend le différend 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’élargir en 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 originale d’Internet était plus étroite, plus rigoureuse et meilleure. La RFC 3935 affirme que l’objectif de l’IETF est de « faire mieux fonctionner Internet » ; elle fonde son travail sur la compétence technique, la mise en œuvre dans le monde réel et le « consensus approximatif et le code en fonctionnement ». Elle indique également que lorsque l’IETF n’est pas responsable d’un protocole ou d’une fonction, il ne cherche pas à exercer un contrôle sur celui-ci. (rfc-editor.org) La RFC 7282 reprend l’ancienne formule de David Clark : « Nous rejetons : les rois, les présidents et le vote » et « Nous croyons au consensus approximatif et au code en fonctionnement ». (rfc-editor.org) La RFC 9592 formule encore plus clairement le principe anti-souverain : l’IETF ne dirige pas, ne contrôle pas et ne surveille 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 aidaient les systèmes à fonctionner. Elle signifiait que le processus était toléré parce qu’il servait le déploiement. Elle signifiait qu’une salle n’était utile que lorsqu’elle se disciplinait 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 manquant.

Ce que signifie la primauté du code en fonctionnement

La primauté du code en fonctionnement signifie que les systèmes de coordination d’Internet doivent être interprétés de manière étroite, par référence à la fonction technique minimale qui justifiait à l’origine les 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 du contrôle et sémantique commune minimale nécessaire pour permettre à des réseaux indépendants de fonctionner ensemble.

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

Elle n’existe pas pour contrôler la moralité commerciale.

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

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

Elle n’existe pas pour permettre à un registre privé de faire disparaître des actifs de réseau déjà en fonctionnement parce que sa théorie politique interne change.

Un registre n’est pas un État.

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

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

Une salle de politique n’est pas un pouvoir législatif.

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

Il ne s’agit pas de conservatisme. La primauté du code en fonctionnement 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 une procédure rituelle. Il doit être justifié par des règles déterministes que les opérateurs peuvent vérifier localement et par l’adoption dans des systèmes en fonctionnement.

Le bon ordre est le suivant : spécification initiale, état de registre distribué, validation locale, mise en œuvre en fonctionnement, adoption volontaire, ensemble de compatibilité, puis documentation.

Le mauvais ordre est le suivant : salle politique, déclaration, obligation revendiquée, étiquette de conformité, conformité opérationnelle forcée.

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

La correction essentielle est la suivante : après la spécification initiale, il n’existe plus d’institution permanente auprès de laquelle présenter une requête. Aucun comité ne décide si la non-adoption constitue une violation. Aucun registre ne déclare un participant invalide simplement parce qu’il refuse une modification ultérieure. Il n’existe que du code, un état de registre, une validation, une adoption, une compatibilité, un rejet local, une bifurcation et une interopération sélective.

Un opérateur qui refuse une modification ultérieure ne casse pas Internet. Il peut rester dans un ancien ensemble de compatibilité. Il peut bifurquer. Il peut se déconnecter. Il peut ne plus interopérer avec les participants ayant adopté des règles incompatibles. Mais il ne peut pas rompre l’interopérabilité des autres participants 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 : aucune institution permanente n’est nécessaire pour décider 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 de numérotation.

L’échec de conception était présent dès le début

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

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

La rareté de l’IPv4 a détruit cette prémisse.

Les adresses IPv4 sont devenues rares, transférables, finançables, louées, capitalisées, litigieuses, sanctionnées et intégrées à des réseaux actifs. La couche des registres ne se situait plus au-dessus de simples écritures administratives. Elle se situait au-dessus d’infrastructures productives. Elle se situait au-dessus de la valeur des actifs. Elle se situait au-dessus de la continuité des clients, du déploiement dans le cloud, des opérations de télécommunication, de la connectivité nationale, des ordonnances judiciaires et de l’allocation du capital.

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

Elle s’est développée.

Le résultat est un système qui continue de parler le langage de la coordination technique tout en produisant les effets d’une gouvernance des infrastructures. Il demande aux opérateurs de traiter la procédure du registre comme neutre alors que les décisions du registre influencent leur destinée commerciale. Il appelle ses participants « communauté » alors qu’un grand nombre de ceux qui supportent les conséquences n’ont jamais donné de représentation juridique claire aux personnes présentes dans la salle.

NRS formule clairement le problème structurel : les registres de numérotation Internet ont été conçus comme des organismes de coordination technique, mais lorsque la rareté de l’IPv4 a transformé les adresses en actifs de valeur, le pouvoir discrétionnaire des registres est devenu un pouvoir économique ; lorsque les systèmes de coordination contrôlent le capital, la centralisation devient un risque structurel et la décentralisation relève de l’ingénierie des systèmes plutôt que de l’idéologie. NRS expose également la direction de conception opposée : un seul Internet, une infrastructure ouverte et autonome, ainsi qu’une gouvernance décentralisée dont la participation humaine minimale constitue le cœur. (nrs.help)

Voilà le véritable problème. La couche des registres n’a jamais été corrigée pour le moment où une table de coordination est devenue une porte d’accès aux actifs.

La primauté du code en fonctionnement constitue ce correctif.

Ce n’est pas une doctrine visant à améliorer les RIR.

C’est une discipline post-RIR.

Les trois règles du correctif

La grammaire constructive est celle de la version révisée de la Note 64 : 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.

La 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 du contrôle, à la sûreté commune et à la sécurité. Elle ne contient pas de préférences concernant les modèles économiques, de théories de fixation des prix, de sentiment politique régional, de pouvoirs discrétionnaires d’exécution ou d’élargissement de mission institutionnelle.

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

L’adoption volontaire signifie qu’une modification ultérieure ne devient réelle que par sa mise en œuvre, sa validation, son déploiement et son utilisation. La publication n’est pas la réalité. La recommandation n’est pas la réalité. La reconnaissance d’une institution en place n’est pas la réalité. La non-adoption ne crée aucun statut d’invalidité. Un participant qui n’adopte pas une modification ultérieure demeure dans son ensemble de compatibilité existant. Un participant qui émet un état invalide au regard des règles déterministes d’un autre participant peut être ignoré localement. L’effet produit est une sélection de compatibilité, et non une sanction institutionnelle.

Ces trois règles ne réhabilitent pas la souveraineté des registres.

Elles empêchent sa réapparition sous un autre nom.

APNIC : la structure juridique constituait le risque

L’APNIC montre le premier échec : le minimum n’a jamais été défini avec suffisamment de rigueur au départ.

Il ne s’agit pas d’une histoire de code de conduite. Il ne s’agit pas d’une histoire d’étiquette. Il ne s’agit pas de savoir si un critique a été suffisamment poli envers une institution en place.

Il s’agit d’une histoire de structure juridique.

En mars 2023, LARUS a publié une analyse juridique avertissant que la structure de gouvernance de l’APNIC créait un risque non seulement pour une entreprise à Brisbane, mais pour la gouvernance d’Internet dans toute la région Asie-Pacifique. L’analyse indiquait que le directeur général de l’APNIC disposait du pouvoir juridique ultime de fermer l’APNIC et de révoquer le Conseil exécutif élu, et que des modifications urgentes de la gouvernance étaient nécessaires. Elle indiquait également que cette structure soulevait des questions sur la sécurité de la gouvernance d’Internet pour plus d’un milliard d’utilisateurs d’Internet dans la région Asie-Pacifique. (larus.net)

La première pièce jointe, l’extrait de société de l’ASIC, fournit la base juridique de l’entreprise. APNIC Pty Ltd y était répertoriée comme une société privée australienne par actions, enregistrée dans le Queensland. Paul Byron Wilson y était indiqué comme administrateur et secrétaire. Les informations relatives aux actions indiquaient qu’une action ordinaire avait été émise et que Paul Byron Wilson était le membre détenant cette action. (larus.net)

Ce n’est pas une manière normale d’abriter une fonction critique de coordination régionale d’Internet.

La deuxième pièce jointe, l’avis juridique du Dr Peter Felter, en tirait la conclusion en matière de gouvernance. Il décrivait la structure publique de l’APNIC — membres, élections, Conseil exécutif, directeur général et secrétariat — comme un comité spécial reposant sur l’article 9.3 des statuts d’APNIC Pty Ltd. Il indiquait qu’APNIC Pty Ltd avait été pendant 25 ans une société privée contrôlée par un seul administrateur, un seul actionnaire et un seul secrétaire, toutes ces fonctions étant occupées par la même personne. (larus.net)

Cette distinction est importante.

L’institution publique tournée vers la communauté n’était pas le contenant juridique final. C’était un édifice construit sur la structure d’une société privée.

L’avis juridique expliquait ensuite pourquoi cette distinction est importante. Il indiquait que les règlements de l’APNIC étaient soumis aux statuts ainsi qu’aux pouvoirs de la société, de ses administrateurs, de ses dirigeants et de ses membres. Selon cette interprétation, la structure publique de l’APNIC pouvait être modifiée par une résolution de l’administrateur d’APNIC Pty Ltd ; l’avis décrivait l’APNIC comme, en pratique, un département d’APNIC Pty Ltd. (larus.net)

Le point le plus dommageable de cet avis n’était pas que l’APNIC était techniquement illégale. Il était que légalité et légitimité ne sont pas la même chose. L’avis soutenait que l’accord de fiducie ne résolvait pas le problème, car les pouvoirs du Conseil exécutif provenaient toujours de la résolution de l’administrateur ayant établi le comité spécial. Il relevait également qu’APNIC Pty Ltd était une société privée par actions dont la structure et les objectifs ne ressemblaient pas au modèle d’organisme sans capital-actions et sans but lucratif que la plupart des gens associeraient à un registre régional d’intérêt public. (larus.net)

Voilà le premier échec de conception sous sa forme la plus claire.

Un système de coordination des ressources de numérotation à l’échelle d’une région ne devrait pas dépendre d’une structure nécessitant l’intervention de juristes pour expliquer comment une société privée à action unique, un comité spécial, un acte de fiducie et un conseil élu se combinent pour former un contrôle légitime du registre de numérotation de l’Asie-Pacifique.

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

Elle ne devrait pas exiger de faire confiance à des documents dissimulé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 peut ne pas être la couche juridique ultime.

Elle ne devrait pas donner l’apparence d’une gouvernance par les membres tout en laissant le pouvoir formel 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 future institution aurait besoin d’une meilleure gouvernance. Mais parce qu’un futur système post-RIR doit éviter d’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 de validation déterministes, un état de preuve du contrôle, des règles de transition d’état, des règles de conflit, la réplication du registre, des mécanismes de sortie, des mécanismes de bifurcation et des ensembles de compatibilité. Si l’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 continue de l’APNIC pour savoir qui contrôle quelles ressources de numérotation.

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

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

ARIN : lorsque la politique a rencontré la réalité des actifs

L’ARIN montre le deuxième échec : la réalité juridique et commerciale peut dépasser la théorie du registre.

L’événement décisif fut la transaction Nortel/Microsoft. Lorsque Nortel a déposé son bilan, ses 666 624 adresses IPv4 sont devenues des actifs de valeur dans la procédure. Les adresses ont été vendues à Microsoft pour 7,5 millions de dollars. L’ARIN est intervenue en soutenant que les adresses n’étaient pas des biens et ne pouvaient pas être vendues libres de toute contrainte liée à la politique du registre. Industrie Canada a appuyé cette position. Le tribunal des faillites l’a rejetée ; Microsoft a ensuite signé un accord relatif aux ressources historiques ; et le résultat pratique était clair : la politique du registre ne pouvait plus rester l’unique source de réalité dès lors que les tribunaux et les marchés traitaient les ressources de numérotation comme des actifs. (btw.media)

La leçon importante n’est pas que l’ARIN était particulièrement défectueuse.

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

Un enregistrement de registre est précieux parce que les opérateurs, les tribunaux, les acheteurs, les vendeurs, les créanciers et les réseaux s’y fient. Il ne devient pas autoritatif en niant cette dépendance. Il reste utile uniquement s’il suit la réalité juridique, commerciale et opérationnelle d’assez près pour mériter la confiance.

Une fois l’IPv4 devenu rare, la procédure du registre est devenue une interface de marché. Les règles de transfert, les évaluations des besoins, les délais de reconnaissance et les restrictions régionales ont cessé d’être des détails administratifs. Ils sont devenus des frictions pesant sur les actifs. Des analyses publiques décrivent désormais un règlement fragmenté entre les RIR, dans lequel cinq systèmes régionaux régissent un marché où chaque adresse s’échange à environ 18 à 45 dollars, avec des règles contradictoires susceptibles d’immobiliser des actifs, de retarder des fusions et de contraindre les entreprises à créer des structures distinctes simplement pour détenir des blocs de numérotation. (btw.media)

Ce n’est pas une coordination neutre.

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

L’ARIN démontre pourquoi l’adoption volontaire est importante. La politique du registre reste crédible uniquement tant qu’elle décrit ce que les acteurs mettent réellement en œuvre, échangent, 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 fonctionnement, la leçon est encore plus nette. Les tribunaux et les marchés n’ont pas besoin d’un registre en place pour décider 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 du contrôle, la résolution des conflits, des transitions d’état visibles dans le registre et la compatibilité. L’ancien registre peut publier une opinion. Un client logiciel peut afficher une opinion. Un explorateur de registre peut afficher une opinion. Aucun d’entre eux n’est la source de la validité.

Il n’existe aucun registre vers lequel migrer.

Il n’existe aucun registre auquel demander l’autorisation.

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

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

AFRINIC est le cas central parce qu’il a réduit le problème à ses éléments essentiels.

Le récit erroné est celui d’un membre problématique ayant paralysé un registre régional.

C’est la fable morale des institutions en place.

Le récit structurel est différent. AFRINIC a tenté de transformer l’utilisation commerciale, la localisation des clients, la location, la relation avec les membres et l’interprétation interne de ses politiques en un pouvoir revendiqué de radier des ressources de numérotation déjà en fonctionnement. Dès lors que cette revendication a été formulée, le conflit ne pouvait plus rester un désaccord dans une salle politique. Il est devenu un test visant à déterminer si un registre privé pouvait utiliser une rhétorique régionale et le silence des politiques pour menacer des actifs intégrés aux opérations.

Les faits ne nécessitent aucune exagération théâtrale. Des reportages publics ont décrit le différend avec AFRINIC comme un simple litige commercial relatif à des adresses IP devenu la plus grande affaire de gouvernance d’Internet en Afrique. Ils ont également indiqué que Cloud Innovation avait souvent été présentée comme le méchant, tandis que des documents apparus ultérieurement mettaient en évidence des forces destructrices au sein même d’AFRINIC et montraient que les procédures judiciaires avaient été retardées, prolongées et poursuivies par des représentants d’AFRINIC aux frais d’AFRINIC. (btw.media)

Cela est important parce que cela inverse le récit habituel.

Les procédures judiciaires n’ont pas créé l’échec structurel.

Elles l’ont révélé.

L’échec concerné existait déjà lorsqu’un registre privé a traité l’absence d’autorisation expresse comme le fondement d’un contrôle coercitif. La location ne menaçait pas l’unicité. La localisation des clients ne constituait pas une attribution en double. L’utilisation commerciale 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, la revendication du registre a placé ces questions dans un cadre de révocation.

C’est le moment où la coordination devient gouvernance.

Des reportages indiquent qu’AFRINIC a envoyé à Cloud Innovation, en mars 2021, une lettre alléguant des violations de politique et menaçant de mettre fin à son adhésion ; qu’en juillet 2021, la Cour suprême de Maurice a interdit à AFRINIC de mettre fin à l’adhésion de Cloud Innovation ; et qu’une nouvelle tentative d’AFRINIC visant à annuler cette adhésion a été bloquée en décembre 2021. (btw.media) Cette séquence ne raconte pas l’histoire d’un registre protégeant calmement Internet. Elle raconte celle d’une autorité de registre confrontée au droit ordinaire.

L’effondrement institutionnel plus large n’a pas non plus été provoqué par un manque de pouvoir du registre. Le problème plus profond était l’enfermement. Lorsqu’un registre détient un monopole de reconnaissance sur des actifs de grande valeur en fonctionnement, chaque 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’otage.

Un registre peut corriger une fraude démontrable dans ses propres enregistrements.

Il peut empêcher les attributions en double tant que le modèle du registre existe encore.

Il peut maintenir des assertions de sécurité tant que les participants continuent de s’y fier.

Mais il s’agit de fonctions transitoires d’une ancienne architecture.

Dans une architecture post-RIR, ces fonctions ne sont pas exercées par un registre. Elles sont encodées dans un état de registre distribué, dans des règles de preuve du contrôle, des règles de conflit et des transitions vérifiables localement.

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

Il ne devrait pas transformer la localisation des clients en motif 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 autorisation.

AFRINIC démontre la nécessité de la décision future localisée correctement comprise. Il n’existe aucun organisme central décidant qu’une décision commerciale future « appartient au niveau local ». La spécification initiale doit plutôt garantir que ces décisions n’entrent jamais dans la couche commune. La location, la localisation des clients, l’utilisation commerciale, la tarification, 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 lorsqu’elles affectent directement l’unicité, la sécurité, la preuve du contrôle ou l’interopérabilité.

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

Un opérateur ne peut pas rompre l’interopérabilité des autres opérateurs en desservant des clients situés en dehors d’une région historique de registre.

Un opérateur ne peut pas rompre l’interopérabilité des autres opérateurs en utilisant un modèle économique que le registre désapprouve.

Au maximum, un opérateur peut ne pas satisfaire à des règles déterministes exécutées par d’autres participants. Dans ce cas, ces derniers rejettent localement l’état invalide. Il n’existe aucune couche de sanction. Il n’existe aucun tribunal de conformité. Il n’existe aucun souverain régional.

Cette limite n’est pas idéologique.

Elle est opérationnelle.

Le problème des procurations n’est pas un détail

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

NRS définit son fondement représentatif en termes juridiques directs. Elle indique que les membres répertoriés lui ont confié le mandat de les représenter dans les questions de gouvernance des RIR et que chacun de ces membres lui a fourni une procuration. (nrs.help) Pendant le différend électoral d’AFRINIC, NRS a demandé aux membres de signaler si leur nom apparaissait sur les listes électorales ou si des votes avaient été enregistrés sans leur participation, et a déclaré que ces signalements factuels seraient traités par les voies légales. (nrs.help)

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

Le système des RIR regroupe souvent plusieurs catégories en une seule : représentant d’entreprise, contact de base de données, contact technique, employé, consultant, détenteur d’une procuration, participant au processus politique et habitué d’une liste de diffusion. Ces catégories ne sont pas identiques.

Un contact de base de données peut contribuer à administrer des enregistrements.

Une procuration peut autoriser une représentation si elle est valide et respecte son champ d’application.

Un participant au processus politique peut apporter une expertise.

Une personne intervenant sur une liste de diffusion peut exprimer une opinion.

Aucune de ces personnes ne devient automatiquement le mandant juridique de toutes les entreprises, de tous les 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 limitée. Dès que le registre revendique un pouvoir sur la révocation, le transfert, la location, l’accès au marché, le traitement des 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 enregistrement de contact n’est pas une procuration d’entreprise.

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

Il ne s’agit pas de minutie procédurale.

C’est la différence entre coordonner et gouverner.

Un système fondé sur la primauté du code en fonctionnement évite ce piège en réduisant le nombre de décisions nécessitant une représentation. Si la validité est déterministe et locale, il y a moins de sujets sur lesquels voter. Si une modification future est volontaire, il n’est pas nécessaire de décider si une personne qui ne l’adopte pas est en situation irrégulière. Si l’état est représenté sur un registre distribué, il n’est pas nécessaire de supplier un registre en place de reconnaître la poursuite de son existence. Si les ensembles de compatibilité sont explicites, les participants savent avec qui ils peuvent interopérer sans demander l’autorisation d’une salle politique.

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 sont plus civilisés que d’autres. Ils démontrent que le modèle des RIR comporte deux couches d’exécution dépassant la fonction technique : le club et le point d’étranglement.

Le club décide qui est respectable. Le point d’étranglement décide quel statut de registre peut être déplacé.

Le refus de RIPE NCC d’accepter le parrainage de LARUS pour RIPE 90 a clairement révélé la couche du club. Un membre a proposé un parrainage. L’écosystème associé au registre l’a refusé en raison d’un litige sans rapport dans une autre région. Ce n’était pas une décision relative à la sécurité du routage. Ce n’était pas une décision relative à l’unicité. Ce n’était pas une règle de validation déterministe. C’était une mise sur liste noire privée par le contrôle de l’accès aux conférences. LACNIC a également refusé mon parrainage. Région différente, même instinct : le club des registres se protège en contrôlant les salles, la visibilité, le parrainage, la réputation et la légitimité sociale.

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

La couche des sanctions est pire, car elle montre le point d’étranglement central sous une forme juridique. RIPE NCC déclare que, puisqu’il est établi aux Pays-Bas, il doit respecter les sanctions de l’Union européenne ; lorsque des sanctions s’appliquent, il gèle les enregistrements dans la base de données RIPE, bloque les acquisitions et les transferts, et peut considérer des dossiers comme gelés lorsqu’une partie ne fournit pas suffisamment de documents. Il vérifie également les listes de l’OFAC parce que ses relations bancaires influencent les paiements. (Transparence de RIPE NCC concernant les sanctions)

Il ne s’agit pas de reprocher à RIPE NCC de respecter la loi. Une entité néerlandaise doit respecter le droit néerlandais et européen. Le problème réside dans l’architecture : pourquoi une entité privée néerlandaise devrait-elle constituer le point central de reconnaissance de la mobilité des ressources de numérotation dans de nombreux pays, pour de nombreux opérateurs et systèmes juridiques ?

Les sanctions peuvent s’imposer à une banque. Les sanctions peuvent s’imposer à une entité néerlandaise. Les sanctions peuvent s’imposer à une contrepartie qui choisit de ne pas effectuer une transaction. Elles ne devraient pas devenir une condition mondiale de validité technique pour tous les autres.

Voilà l’échec de conception.

La même centralité qui permet à un club d’exclure un critique permet également à une juridiction de geler la mobilité dans le registre. L’un relève de l’exécution sociale. L’autre relève de l’exécution juridique. Les deux ne fonctionnent que parce que le registre se trouve à l’endroit où la validité ne devrait pas se trouver.

Cela renvoie directement aux trois principes.

Spécification initiale minimale : la respectabilité au sein du club, l’admissibilité au parrainage, la politique régionale, la classification au titre des sanctions et la réputation ne doivent jamais entrer dans la couche commune. Celle-ci ne devrait contenir que des règles déterministes relatives à l’unicité, à la preuve du contrôle, au traitement des conflits, aux transitions d’état et à la 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 supportent. Une entité néerlandaise peut refuser une transaction. Une banque peut refuser un paiement. Une contrepartie peut refuser de traiter avec quelqu’un. Rien de tout cela ne devrait devenir une vérité universelle du registre.

Adoption volontaire : les participants acceptent les contreparties en exécutant du code, en validant l’état et en choisissant avec qui interopérer. La non-adoption n’est pas une faute. Un refus local n’est pas une invalidité mondiale. Le refus d’un club ne devrait pas effacer un état valide. Une obligation liée aux sanctions devrait contraindre l’acteur qui y est soumis, et non réécrire le registre mondial des ressources de numérotation.

C’est pourquoi une conception fondée sur un 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 l’état localement. Les contreparties acceptent ou rejettent 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.

La solution n’est pas une file de traitement des 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 fuite vers le haut

La preuve la plus grave n’est pas la tentative d’abus de pouvoir d’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 entier et indiquait que les RIR géraient les ressources de numérotation dans leurs régions respectives. Elle affirmait que les cinq registres exerçaient la fonction d’administration des ressources de numérotation selon des règles adoptées au niveau régional ou des politiques mondiales adoptées à l’unanimité. (nro.net)

La même lettre critiquait les procédures judiciaires de Cloud Innovation, indiquait que plus de 25 actions en justice avaient été engagées, se plaignait d’ordonnances judiciaires ayant gelé les comptes d’AFRINIC et interrompu les élections, et indiquait qu’AFRINIC avait demandé à plusieurs reprises à Maurice de la reconnaître 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)

Il s’agit du document le plus révélateur de toute cette histoire.

Lorsqu’un registre privé s’est heurté aux tribunaux ordinaires, le réflexe du système n’a pas été de réduire le mandat.

Il n’a pas été de supprimer l’enfermement lié au registre.

Il n’a pas été de séparer la tenue des registres de l’exécution.

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

Il n’a pas été de demander si le pouvoir unilatéral de radier des actifs en fonctionnement était illégitime depuis le début.

Le réflexe a été la fuite vers le haut.

Un organisme privé de coordination ne peut pas être technique lorsqu’il veut exercer un pouvoir discrétionnaire, communautaire lorsqu’il veut obtenir de la légitimité, contractuel lorsqu’il veut percevoir des frais, opposé à la propriété lorsqu’il veut éviter les responsabilités liées à celle-ci, et quasi international lorsqu’il veut s’isoler des tribunaux.

Cet ensemble n’est pas de la gouvernance.

C’est du blanchiment de mandat à l’échelle du système.

Si les RIR veulent bénéficier de privilèges relevant du droit public, ils doivent accepter la responsabilité propre au droit public. S’ils veulent la souplesse du droit privé, ils doivent accepter les litiges de droit privé. Ce qu’ils ne peuvent raisonnablement exiger simultanément, c’est un pouvoir discrétionnaire privé, une importance d’infrastructure publique, une faible responsabilité, une représentation limitée, un statut monopolistique et une protection quasi diplomatique.

Voilà la voie vers la catastrophe.

La primauté du code en fonctionnement la rejette.

Lorsqu’un registre rencontre une résistance juridique, il ne doit pas s’échapper vers le haut en recherchant une immunité. L’architecture doit se contracter vers le bas, jusqu’à la fonction étroite du code en fonctionnement qui le justifiait.

Moins de souveraineté.

Aucun registre comme source de validité.

Moins d’exécution.

Davantage de validation distribuée.

La révision d’ICP-2 ne suffit pas

Le système actuel sait que quelque chose est cassé.

La page de consultation publique de l’ICANN consacrée au deuxième projet de document sur la gouvernance des RIR indique que la proposition établirait des règles et des critères de reconnaissance des nouveaux RIR, les obligations et exigences opérationnelles des RIR ainsi que les règles de retrait de la reconnaissance ; si elle était adoptée, elle remplacerait 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 d’accroître la responsabilité du système des RIR envers la communauté Internet. (icann.org)

Cela peut être nécessaire en tant que mesure de continuité.

Ce n’est pas suffisant en tant que théorie de la légitimité.

Les règles de reconnaissance et de retrait de la reconnaissance répondent à une question tardive : à partir de quand un registre a-t-il échoué au point de devoir être supprimé ?

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

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

La primauté du code en fonctionnement pose un ensemble différent de questions.

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

Comment les revendications sur les ressources de numérotation restent-elles vérifiables sans l’autorisation de l’institution en place ?

Comment préserver l’unicité sans pouvoir discrétionnaire monopolistique ?

Comment empêcher les enregistrements de devenir des armes d’exécution ?

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 peut-elle rester utilisable sans aucun registre faisant autorité ?

Comment un opérateur peut-il valider un état ordinaire sans demander son statut à un organisme permanent ?

Comment faire en sorte qu’un refus ne devienne pas une étiquette de violation ?

Il ne s’agit pas de questions de réforme.

Ce sont des questions post-RIR.

Pourquoi il s’agit du correctif de la conception originale

La question n’est pas de savoir si l’on apprécie ou non les registres en place.

La question est de savoir si la couche des ressources de numérotation respecte encore la discipline de conception qui a permis à Internet de fonctionner : règles communes minimales, validation locale, adoption volontaire et code en fonctionnement.

La primauté du code en fonctionnement n’est ni une stratégie de relations publiques ni un compromis institutionnel. C’est la réparation technique impliquée par la conception originale. Si Internet a été construit pour rejeter les rois, les présidents et le vote comme sources de vérité technique, la couche des ressources de numérotation ne peut recréer ces formes au moyen de procédures de registre, de délégations historiques ou d’un théâtre communautaire.

Le consensus seul peut devenir un rituel. Le code en fonctionnement lui-même peut être subordonné si la couche des registres se situe en amont de la reconnaissance. La règle manquante est à la fois interprétative et architecturale : lorsque la procédure institutionnelle entre en conflit avec la fonction technique minimale exigée par les systèmes en fonctionnement, le code en fonctionnement est prioritaire ; et lorsqu’une modification ultérieure est proposée, elle ne devient réelle que par l’adoption volontaire des participants qui exécutent les règles de validation.

C’est ainsi que la conception originale est préservée, et non abandonnée.

Internet a eu de l’importance parce qu’il est devenu le premier système mondial de communication ne nécessitant pas l’autorisation préalable d’un souverain, d’un ministère, d’une église, d’une entreprise ou d’un contrôleur unique. Si cette réalisation mérite encore d’être défendue, la couche des registres ne peut devenir l’exception qui engloutit la règle.

Un système construit pour éviter les rois ne peut permettre à un comptable de passer une audition pour en devenir un.

Le correctif rétablit la hiérarchie originale : le code en premier, les opérateurs en premier, la validation déterministe en premier, l’état distribué en premier ; les institutions, s’il en reste 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 fine, plus objective, plus déterministe et plus distribuée que le monopole actuel des RIR.

Il n’existe aucun registre vers lequel migrer.

Il n’existe aucun nouveau registre à couronner.

Il n’existe aucun nouveau clergé de remplacement.

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

La couche commune devrait préserver l’unicité des identifiants, la preuve du 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 relatives aux conflits et la visibilité des bifurcations.

La couche des opérateurs devrait contrôler l’utilisation commerciale, la location, la localisation des clients, les pratiques de routage, le financement, la sélection des contreparties et les règles commerciales ne constituant pas des invariants.

La couche d’adoption devrait déterminer ce qui devient réel. Une règle de coordination n’a d’importance que si les opérateurs peuvent la mettre en œuvre, si les contreparties peuvent l’accepter, si les marchés peuvent s’y fier, si les tribunaux peuvent la comprendre et si l’interopérabilité est préservée sans faire de la reconnaissance par une 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 un état. Il peut valider des transitions. Il peut exposer des conflits. Il peut rendre une preuve portable. Il ne doit pas devenir simultanément procureur, juge, autorité de sanction, régulateur du marché, moraliste commercial et dépositaire d’actifs.

Plus important encore, la portabilité doit être correctement comprise.

Dans un monde fondé sur un registre distribué, la portabilité ne signifie pas passer d’un registre à un autre. Cela reste une façon de penser propre aux registres. Il n’existe aucun registre vers lequel migrer. La preuve du contrôle du détenteur, l’historique de l’état et la capacité de transfert ne sont pas enfermés dans une base de données institutionnelle. Ils existent dans un état partagé et vérifiable que les participants valident localement et que les contreparties acceptent volontairement.

Sans cela, chaque registre constitue un point d’enfermement.

Avec cela, le registre disparaît en tant que source de validité.

La coordination post-RIR nécessite donc quatre propriétés de conception.

Premièrement, une validité déterministe. Un participant devrait 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 devrait décrire clairement la limite de compatibilité au lieu de traiter la dissidence comme une faute.

Troisièmement, une preuve distribuée du contrôle. Un détenteur ne devrait pas « transférer » ses ressources vers un autre registre ; il devrait démontrer son contrôle grâce à un état valide dans le registre que toute contrepartie peut vérifier sans la bénédiction de l’institution en place.

Quatrièmement, la visibilité des bifurcations. Si les ensembles de règles divergent, cette divergence devrait être explicite. Les participants décident quel ensemble de compatibilité exécuter et quelles contreparties accepter. Une bifurcation peut isoler certains participants. Elle ne confère pas à l’un des camps le pouvoir institutionnel d’effacer l’autre.

Il ne s’agit pas d’un argument en faveur de cinq meilleurs monopoles.

Il s’agit d’un argument contre le monopole comme source de validité.

Pourquoi la trajectoire d’échec est prévisible

Si rien ne change, la trajectoire d’échec est claire.

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

Deuxièmement, les États cesseront de traiter les RIR comme des associations techniques inoffensives. La continuité de la numérotation concerne la connectivité nationale, les sanctions, l’application de la loi, la résilience des télécommunications, les infrastructures cloud et la sécurité économique. Aucun État n’acceptera indéfiniment qu’une structure privée étrangère de registre constitue le point amont non examiné de la continuité de ses communications nationales.

Troisièmement, les opérateurs contourneront l’autorité des registres lorsque cela sera possible. Si les enregistrements deviennent politiques, dangereux, non représentatifs ou détachés de la réalité des actifs, les opérateurs se fieront à des contrats privés, à des transferts soutenus par des décisions de justice, à des attestations alternatives, à la reconnaissance nationale ou à la réalité de fait du routage.

Quatrièmement, l’ICANN et la couche de la NRO seront tentées de centraliser. Cela produirait une version plus lourde 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 des registres privés revendiquent une autorité quasi souveraine sans responsabilité de droit public, les États finiront par reprendre leur souveraineté. Il pourrait en résulter une fragmentation, des représailles, des registres contradictoires et une pression politique sur le routage.

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

Il échoue également lorsque les institutions décrivant qui peut utiliser les identifiants perdent la confiance des opérateurs qui acheminent les paquets.

Un registre distribué ne résout pas tous les problèmes politiques. Il accomplit quelque chose de plus important : il supprime le registre permanent en tant que source ordinaire de validité. Cela réduit la surface d’attaque. Cela réduit le pouvoir institutionnel de prise d’otage. 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 possède le mandat ?

C’est la mauvaise question.

La meilleure question est : de quoi le code en fonctionnement a-t-il réellement besoin ?

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

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

Corrige-t-elle une fraude démontrable dans les enregistrements au moyen de preuves déterministes ?

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

Préserve-t-elle l’exactitude de la preuve du contrôle ?

Permet-elle une validation locale ?

Supprime-t-elle la dépendance à l’égard d’une institution en place ?

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

Un participant peut-il la refuser sans se voir attribuer un statut d’invalidité ?

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

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

Une bifurcation peut-elle avoir lieu sans qu’un camp soit effacé par une institution ?

Si la réponse n’est pas liée à une nécessité déterministe du code en fonctionnement, ce pouvoir ne devrait pas se trouver dans la couche commune.

Voilà la primauté du code en fonctionnement.

Pour discussion

Cette proposition est soumise à discussion. Elle ne constitue pas un règlement définitif.

La prochaine étape devrait être un Internet-Draft sérieux ou un document de type BCP définissant la primauté du code en fonctionnement pour les systèmes de coordination d’Internet, en commençant par les ressources de numérotation. 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 de registre distribué, d’une validation déterministe, d’une adoption volontaire, de l’acceptation des contreparties et d’ensembles de compatibilité explicites.

Il devrait être testé 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 des registres sont des résidus historiques ?

Quelles décisions appartiennent aux opérateurs ?

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

Quelle est la voie du refus ?

Quelle est la voie de la bifurcation ?

Quelle est la voie du rejet local ?

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

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

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

Les ressources de numérotation peuvent-elles rester uniques sans l’autorisation d’une institution en place ?

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

Un processus politique peut-il distinguer un invariant du code en fonctionnement d’un appétit institutionnel ?

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

Un enregistrement peut-il décrire la réalité sans devenir souverain sur celle-ci ?

Toute personne intéressée peut me contacter sur LinkedIn. Les chercheurs sérieux, auteurs techniques, institutions ou experts en politiques qui souhaitent contribuer à transformer cette idée en un premier Internet-Draft, puis éventuellement en discussion sur une RFC ou une BCP si la communauté la juge utile, sont invités à me contacter. La LARUS Foundation et moi-même sommes disposés à soutenir et financer des recherches sérieuses dans cette direction.

La première conception du système des RIR a échoué parce qu’elle n’a jamais demandé ce dont le code en fonctionnement avait réellement besoin.

Elle a demandé qui pouvait prendre la parole dans la salle.

Le prochain système doit inverser cet ordre.

Pas de blanchiment de mandat.

Pas de trahison du code en fonctionnement.

La primauté du code en fonctionnement.

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 destiné aux systèmes de coordination d’Internet dont l’objectif est de fournir des points de référence techniques partagés sans créer une autorité permanente au-dessus des participants qui exploitent le système. Il définit trois principes liés : la spécification initiale minimale, la décision future localisée et l’adoption volontaire.

Selon 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 du contrôle, à la sûreté commune et à la sécurité. Après la spécification initiale, les modifications futures ne sont pas approuvées par un organisme central. Elles sont adoptées, ignorées, bifurquées ou abandonnées par les participants exécutant le code.

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

La non-adoption n’est pas une violation. Un participant qui n’adopte pas une modification ultérieure reste dans son ensemble de compatibilité existant. Un participant qui émet un état non valide selon les règles déterministes acceptées par un autre participant peut être ignoré localement par ce dernier. L’effet produit est une sélection de compatibilité, une bifurcation, un isolement ou une interopération sélective, et non une sanction institutionnelle.

Ce document ne définit pas un protocole filaire. Il précise une meilleure pratique actuelle 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 par un objectif technique limité : permettre à des acteurs indépendants d’interopérer en partageant un point de référence commun, un espace d’identifiants, une règle de validation, un état de registre ou un enregistrement de preuve du contrôle. Au fil du temps, ces systèmes accumulent souvent une autorité qui n’était pas nécessaire à l’interopérabilité initiale.

Cela se produit généralement en trois étapes.

Premièrement, des questions futures sont placées dans la couche fondatrice avant d’être techniquement nécessaires.

Deuxièmement, des choix qui devraient être effectués par des participants exploitant leurs propres systèmes deviennent dépendants de décisions de reconnaissance, d’interprétation ou de statut prises par un organisme permanent.

Troisièmement, la publication, l’enregistrement, la recommandation ou l’approbation procédurale sont considérés comme suffisants pour créer une obligation opérationnelle, même lorsque les participants n’ont pas adopté la modification dans des 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 teneur de registre devient un contrôleur. Un artefact de coordination devient une source de contrôle futur.

Ce document propose une discipline de conception différente :

• Spécification initiale minimale : ne spécifier que les règles communes déterministes requises pour l’interopérabilité de base, l’unicité, la preuve du contrôle, la sûreté commune et la sécurité.
• Décision future localisée : après la spécification initiale, laisser les choix futurs aux participants qui exécutent le code. Un participant peut adopter, refuser, bifurquer, se déconnecter ou interopérer de manière sélective. Aucun participant ne peut modifier l’interopérabilité des autres participants qui continuent d’exécuter des règles mutuellement compatibles.
• Adoption volontaire : rendre une modification ultérieure réelle uniquement par sa mise en œuvre, son exploitation, sa validation et son adoption par les participants exécutant le code.

Ces principes sont liés. Un système qui spécifie trop de choses dès le départ précharge le contrôle futur dans la couche commune. Un système qui conserve une couche permanente de reconnaissance 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 commandement.

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 par rapport à un état partagé. Un participant peut adopter une modification ultérieure, la refuser, bifurquer, se déconnecter ou interopérer de manière sélective. Il peut tout au plus se retirer lui-même d’un ensemble de compatibilité. En refusant une modification, il ne peut pas rompre l’interopérabilité des autres participants qui continuent d’exécuter un code mutuellement compatible.

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

2. Champ d’application

Ce document s’applique aux systèmes de coordination d’Internet, y compris, sans s’y limiter, les systèmes d’identifiants, les cadres de nommage et de numérotation, les mécanismes d’extension de protocoles, les systèmes de preuve du contrôle, les systèmes de portabilité, les registres distribués et les autres architectures dans lesquelles des acteurs indépendants s’appuient sur un point de référence technique commun.

Ce document ne s’oppose pas aux règles communes. Il affirme que les règles communes devraient ê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 mise en œuvre particulière d’un registre distribué. Il exige une propriété de conception : les participants devraient pouvoir déterminer la validité en appliquant localement la spécification initiale à un état partagé ou reproductible, sans demander une autorisation ou un statut à une autorité permanente.

3.Conventions et définitions

3.1. Terminologie normative

Les termes normatifs écrits en majuscules dans ce document doivent être interprétés au sens défini par la BCP 14, plus précisément 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 :
Ensemble minimal partagé de règles ou structure de référence nécessaire pour permettre à des participants indépendants d’interopérer. La couche commune n’est pas une institution. Elle constitue la substance technique que les participants mettent en œuvre et vérifient.

Registre distribué :
Enregistrement répliqué ou distribué d’une autre manière 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é. Ce terme n’impose aucun algorithme de consensus ni aucune mise en œuvre particulière.

Règle de validation déterministe :
Règle permettant à un participant de déterminer, au moyen d’un calcul ou d’une vérification locale, si un état, un enregistrement, une transition, une assertion ou un message est valide selon un ensemble de règles déterminé.

Invariant mondial :
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 du contrôle, la sûreté commune ou la sécurité.

Participant :
Opérateur, mise en œuvre, nœud, réseau, organisation ou autre acteur qui exécute, vérifie, déploie ou utilise le système.

Ensemble de compatibilité :
Groupe de participants dont les règles de validation mises en œuvre leur permettent d’interopérer. Une modification ultérieure peut créer un nouvel ensemble de compatibilité si certains participants l’adoptent et d’autres non.

Adoption :
Mise en œuvre, déploiement, validation et utilisation effectifs par les participants qui exploitent le système.

Acceptation de la contrepartie :
Décision volontaire d’un participant d’accepter l’état d’un autre participant, d’effectuer une transaction avec lui, d’interopérer avec lui ou de s’appuyer sur son état selon les règles de validation qu’il exécute.

Non-adoption :
Choix d’un participant de ne pas mettre en œuvre ou utiliser une modification proposée. La non-adoption ne crée aucun statut d’invalidité. Elle signifie uniquement que le participant n’a pas rejoint l’ensemble de compatibilité créé par cette modification.

Rejet local :
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 qui est invalide ou incompatible selon les règles de validation qu’il exécute.

Bifurcation :
Divergence dans les règles de validation ou les pratiques opérationnelles créant au moins deux ensembles de compatibilité.

Artefact de coordination :
Document, recommandation, note de mise en œuvre, profil, mise en œuvre de référence, explorateur de registre, miroir ou autre artefact aidant les participants à se coordonner. Un artefact de coordination ne crée pas de réalité opérationnelle contraignante à moins que les participants ne l’adoptent dans des systèmes en fonctionnement.

4. Énoncé du problème

Les concepteurs tentent souvent de réduire l’incertitude future en inscrivant trop de choses dans la couche fondatrice ou en laissant un organisme permanent interpréter les questions futures. Cela semble prudent. C’est souvent dangereux.

La surspécification de la couche fondatrice entraîne trois coûts.

Premièrement, elle déplace les choix futurs dans une couche commune où le changement est plus difficile et où la capture produit davantage d’effets.

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

Troisièmement, elle encourage 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 qu’un organisme permanent approuve les modifications, détermine le statut ou interprète le fonctionnement ordinaire, le système a créé une couche de contrôle postérieure à sa fondation. Cette couche peut commencer comme une administration. Elle peut devenir une gouvernance. Elle peut ensuite devenir un point d’étranglement.

L’objectif de conception de ce document n’est pas d’améliorer le pouvoir discrétionnaire institutionnel. Il consiste à éviter d’avoir besoin de ce pouvoir discrétionnaire.

Un système de coordination d’Internet correctement 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 reproductible ; laisser les choix ne constituant pas des invariants en dehors de la couche commune ; et permettre aux modifications ultérieures de devenir réelles uniquement lorsque les participants les adoptent volontairement dans des systèmes en fonctionnement.

5. Principe 1 : spécification initiale minimale

5.1. Énoncé

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 du contrôle, à la sûreté commune et à la sécurité.

5.2. Exigences

Une conception utilisant ce principe :

1. DOIT identifier explicitement ses invariants mondiaux.
2. DOIT définir des règles de validation déterministes pour chaque invariant mondial.
3. DOIT définir comment l’état valide est représenté, répliqué, vérifié et mis à jour.
4. NE DOIT PAS inclure une règle dans la spécification initiale, sauf si cette règle est nécessaire pour préserver un invariant mondial déclaré ou permettre le premier déploiement.
5. DOIT séparer les règles de validation des préférences politiques, des arrangements commerciaux, des rôles institutionnels, des ambitions de gouvernance et du jugement discrétionnaire.
6. DOIT permettre aux participants de vérifier localement la validité ordinaire sans consulter une institution, un registre, un comité, un organisme politique ou une autre autorité.
7. DEVRAIT définir les structures de données, signatures, preuves, règles de transition d’état, règles de conflit ou autres mécanismes nécessaires à la vérification locale.
8. DEVRAIT définir la signalisation des extensions, le versionnage, l’étiquetage de compatibilité ou l’identification des bifurcations lorsque des variations futures sont prévisibles.
9. DOIT garantir que les artefacts de coordination requis sont portables, auditables, reproductibles et remplaçables.
10. DEVRAIT privilégier des conditions objectives vérifiables par machine plutôt qu’une évaluation subjective du mérite.
11. NE DOIT PAS faire de la reconnaissance institutionnelle future l’unique voie permettant de connaître, d’enregistrer ou d’utiliser un état valide.

5.3. Conséquences pour la conception

La spécification initiale minimale ne signifie pas une spécification vague. Elle signifie une spécification stricte portant uniquement sur ce qui doit être commun.

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 du contrôle, la sûreté commune et la sécurité ; et
• ce qui peut rester en dehors de la couche commune parce que cela concerne les préférences des opérateurs, les pratiques commerciales, le choix des contreparties, le calendrier de déploiement ou les choix d’adoption ultérieurs.

Une conception incapable d’énoncer clairement ses invariants mondiaux et ses règles de validation déterministes devrait présumer 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. Énoncé

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 aucun statut d’invalidité.

6.2. Exigences

Une conception utilisant ce principe :

1. NE DOIT PAS exiger des participants qu’ils obtiennent l’autorisation d’une institution en place, d’un registre, d’un comité, d’un conseil, d’un organisme politique ou d’une autre autorité pour des choix qui ne modifient pas les règles de validation déterministes de l’ensemble de compatibilité auquel ils participent.
2. NE DOIT PAS créer un organisme permanent dont la reconnaissance constitue l’unique voie permettant à une modification ultérieure de devenir opérationnellement réelle.
3. DOIT distinguer la validité selon la spécification initiale de la compatibilité avec une modification facultative ultérieure.
4. NE DOIT PAS traiter la non-adoption d’une modification ultérieure comme une invalidité.
5. DOIT permettre aux participants de rester dans un ensemble de compatibilité existant lorsqu’ils n’adoptent pas une modification ultérieure.
6. 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.
7. DOIT permettre aux participants de rejeter localement les états, enregistrements, transitions ou messages qui sont invalides ou incompatibles selon les règles de validation qu’ils exécutent.
8. DOIT permettre aux participants de choisir volontairement leurs contreparties selon les règles de validation et les ensembles de compatibilité qu’ils acceptent.
9. NE DOIT PAS autoriser une institution, un registre, un comité, un organisme politique ou un autre acteur à déclarer un participant invalide simplement parce qu’il a refusé une modification ultérieure.
10. 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.
11. DEVRAIT éviter toute conception dans laquelle un teneur de registre en place peut empêcher des participants autrement valides de continuer à interopérer.

6.3. Conséquences pour la 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 manière à ce qu’après la spécification initiale, les choix futurs ordinaires ne nécessitent aucune attribution de ce type.

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

Les modifications futures ne sont pas approuvées de manière centralisée. Elles sont adoptées, ignorées, bifurquées ou abandonnées par les participants qui exécutent le code.

Un participant qui refuse une modification peut rester en dehors de l’ensemble de compatibilité créé par celle-ci. Il peut se déconnecter des autres. Il peut continuer dans un ancien ensemble de compatibilité. Il peut bifurquer. Il peut interopérer de manière sélective. Mais il ne peut pas rompre 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. Personne n’a besoin de décider qu’un participant est en situation irrégulière. Un participant exécutant des règles de validation compatibles n’accepte simplement pas l’état invalide ou incompatible.

7. Principe 3 : adoption volontaire

7.1. Énoncé

Les modifications apportées à un système de coordination d’Internet DEVRAIENT devenir opérationnellement réelles par leur mise en œuvre, leur validation, leur déploiement, leur acceptation par les contreparties et leur adoption par les participants, et non par leur seule publication ou déclaration.

7.2. Exigences

Une conception utilisant ce principe :

1. NE DOIT PAS traiter la publication, la recommandation, l’approbation en réunion ou l’approbation procédurale comme suffisantes pour créer une obligation opérationnelle universelle.
2. DOIT permettre aux participants qui le souhaitent de déployer progressivement de nouvelles règles, extensions, profils ou procédures.
3. DOIT permettre aux participants de refuser une modification ultérieure sans acquérir de statut d’invalidité, tant que leurs propres transitions d’état satisfont aux règles de validation déterministes de leur ensemble de compatibilité.
4. DOIT permettre aux participants de continuer à utiliser un ancien ensemble de compatibilité lorsque la spécification initiale autorise cette continuité.
5. DOIT permettre aux participants exécutant un ensemble de compatibilité de rejeter ou d’ignorer localement l’état provenant d’un autre ensemble de compatibilité lorsque les règles sont incompatibles.
6. DEVRAIT définir des voies d’adoption pour les modifications importantes, notamment la signalisation des versions, l’étiquetage de compatibilité, les recommandations de transition et les vecteurs de test.
7. DEVRAIT définir des voies de refus pour les modifications importantes, notamment la manière dont les participants qui ne les adoptent pas poursuivent leur fonctionnement, identifient leur ensemble de compatibilité et évitent une interopération ambiguë.
8. DOIT garantir que les artefacts de coordination requis peuvent être quittés, mis en miroir, réimplémentés ou remplacés sans coût de transition impossible.
9. DEVRAIT faire en sorte que les enregistrements, recommandations et artefacts de coordination décrivent la réalité adoptée plutôt que de déclarer une réalité future non adoptée.
10. DOIT éviter de concevoir un système dans lequel la seule manière pour une modification de devenir réelle consiste à obtenir au préalable la reconnaissance d’un organisme en place.

7.3. Conséquences pour la conception

L’adoption volontaire constitue le test opérationnel permettant de déterminer si une modification est utile, tolérable et compatible avec un 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 mettent en œuvre, valident, déploient et acceptent la modification, acceptent les contreparties et s’appuient sur celle-ci.

La non-adoption ne crée aucun statut de violation. Elle crée seulement un fait : le participant n’a pas rejoint l’ensemble de compatibilité créé par la modification.

Cela n’élimine pas les processus de normalisation, la documentation, les notes de mise en œuvre, les explorateurs, les miroirs ou les examens. Cela limite leur prétention. Ils peuvent aider les participants à se coordonner. Ils peuvent publier des documents de référence. Ils peuvent décrire l’adoption. Ils peuvent formuler des recommandations. Ils ne peuvent pas, par simple déclaration, rendre une réalité future non adoptée contraignante 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 lorsqu’ils sont appliqués 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 choix futurs restent entre les mains des participants qui exécutent le code, au lieu d’être récupérés par une couche centrale d’approbation.

L’adoption volontaire garantit qu’une modification ultérieure doit survivre à la confrontation avec la mise en œuvre, la vérification, l’acceptation des contreparties et l’utilisation.

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

• Une spécification initiale minimale sans décision future localisée peut encore permettre à l’autorité de s’accumuler après le déploiement.
• Une 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é.
• Une adoption volontaire sans validation déterministe peut produire de la confusion, car les participants ne peuvent pas distinguer une variation compatible d’un état invalide.
• Une validation déterministe sans état distribué peut encore laisser les participants dépendants d’un teneur de registre privilégié.
• Un état distribué sans visibilité des bifurcations peut dissimuler les désaccords jusqu’à une défaillance opérationnelle.
• Un état distribué sans acceptation volontaire des contreparties peut recréer la coercition au moyen d’une autre interface.

Ensemble, ces principes produisent un système dans lequel la couche commune est fine, la validité est vérifiable localement, les modifications futures sont volontaires, 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 être limitée aux éléments suivants :

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

La couche commune NE DEVRAIT PAS contenir :

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

9.2. Surface décisionnelle des opérateurs

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’utilisation commerciale ;
• la localisation des clients ;
• les accords de location, de financement ou de transfert ;
• les préférences locales en matière d’admissibilité ;
• l’ordre des opérations ;
• les pratiques de routage non nécessaires à 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 choix différents dans ces domaines. Ces choix peuvent produire des ensembles de compatibilité, des relations commerciales, des accords d’interconnexion ou des communautés opérationnelles différents. Ils ne créent aucune invalidité, sauf s’ils enfreignent les règles de validation déterministes d’un ensemble de compatibilité.

9.3. Boucle d’adoption

Lorsque cela est possible, l’ordre privilégié pour une modification importante du système est :

1. proposition ;
2. mise en œuvre ;
3. vecteurs de test ou méthode de vérification déterministe ;
4. déploiement limité par des participants volontaires ;
5. observation des effets sur l’interopérabilité et la sécurité ;
6. étiquetage de l’ensemble de compatibilité ;
7. documentation ou recommandation décrivant la réalité adoptée.

Un artefact de coordination DEVRAIT suivre l’adoption au lieu de tenter de l’anticiper.

9.4. Bifurcation, rejet local et acceptation des contreparties

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 défaillances.

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

• continuer dans un ancien ensemble de compatibilité ;
• adopter un ensemble de compatibilité plus récent ;
• bifurquer vers un ensemble de compatibilité différent ;
• vérifier l’état sans dépendre d’un teneur de registre en place ;
• accepter volontairement des contreparties ;
• rejeter localement un état invalide ou incompatible ;
• interopérer de manière sélective lorsque la compatibilité le permet.

Un système qui ne peut pas être bifurqué, vérifié localement ou accepté de manière sélective sans détruire une opération valide a probablement dissimulé un pouvoir de gouvernance dans sa fonction de tenue des registres.

10.Applicabilité et limites

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

• le système comporte plusieurs acteurs et plusieurs juridictions ;
• le déploiement indépendant est important ;
• la couche de coordination est censée rester limitée ;
• des variations futures sont probables, mais ne peuvent pas être prévues en détail ;
• l’enfermement créerait un risque de gouvernance ;
• la validité peut être rendue déterministe ou vérifiable localement ;
• un état distribué peut réduire le risque de capture institutionnelle.

Il peut être moins directement applicable lorsque :

• une architecture à domaine administratif unique est prévue ;
• un couplage fort en temps réel exige un comportement uniforme en permanence ;
• des enjeux 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 néanmoins réduire au minimum la couche commune et éviter autant que possible le contrôle discrétionnaire futur.

11.Objectifs exclus

Ce document :

• n’interdit pas toute coordination ;
• n’exige aucune mise en œuvre particulière d’un registre distribué ;
• ne garantit pas le consensus ;
• ne garantit pas la neutralité politique ;
• n’exige pas que tous les participants adoptent chaque modification ultérieure ;
• ne traite pas le refus d’adopter comme une invalidité ;
• ne légitime pas un comportement local incompatible tout en prétendant être compatible ;
• n’élimine pas la nécessité de règles communes essentielles à la sécurité.

12. Considérations relatives à la sécurité

Une couche de coordination plus fine peut réduire le risque de capture, limiter l’étendue des conséquences d’une erreur institutionnelle et améliorer la remplaçabilité. Toutefois, une plus grande liberté locale et un état distribué peuvent également créer des postures de sécurité incohérentes, des voies de rétrogradation, une pression à la fragmentation, des revendications de compatibilité ambiguës, des bifurcations dangereuses, des différends concernant l’état du registre et des tentatives de falsification de preuves.

Les concepteurs appliquant ce document DOIVENT donc préciser 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 du contrôle DOIVENT résister à la falsification, à la réutilisation et aux transferts non autorisés ;
• la négociation des versions et le traitement des extensions DOIVENT éviter une rétrogradation silencieuse lorsque la sécurité est affectée ;
• les voies de refus, de bifurcation et de remplacement DOIVENT être analysées au regard des risques d’abus et de déni de service ;
• les étiquettes de compatibilité DEVRAIENT être suffisamment claires pour éviter une interopération accidentelle entre des ensembles de règles incompatibles ;
• l’état distribué DEVRAIT être suffisamment auditable et reproductible pour permettre de détecter des vues incohérentes ;
• les variations locales NE DOIVENT PAS être autorisées à prétendre faussement être compatibles avec un ensemble de règles qu’elles ne respectent pas.

L’existence d’exceptions de sécurité ne justifie pas une couche générale d’autorisation. Elle justifie uniquement les règles de sécurité déterministes nécessaires à la préservation des invariants mondiaux déclarés.

13. Considérations relatives à l’IANA

Ce document ne requiert aucune action de l’IANA.

14. Références

14.1. Références normatives

• RFC 2119 — Bradner, S., Mots clés à utiliser dans les RFC pour indiquer les niveaux d’exigence, BCP 14, RFC 2119.
• RFC 8174 — Leiba, B., Ambiguïté entre les majuscules et les minuscules dans les mots clés de la RFC 2119, BCP 14, RFC 8174.

14.2. Références informatives

• RFC 6709 — Carpenter, B. et B. Aboba, Considérations relatives à la conception des extensions de protocoles, RFC 6709.
• RFC 7282 — Resnick, P., À propos du consensus et du fredonnement au sein de l’IETF, RFC 7282.

Annexe A. Liste de contrôle de conception

Une conception déclarant être conforme à ce document DEVRAIT pouvoir répondre clairement aux questions suivantes :

1. Quels sont les invariants mondiaux ?
2. Quelles règles de validation déterministes préservent ces invariants mondiaux ?
3. Quelles règles de la spécification initiale sont strictement nécessaires au premier déploiement ?
4. Comment l’état valide est-il représenté et vérifié ?
5. L’état est-il distribué, répliqué ou vérifiable de manière indépendante par un autre moyen ?
6. Quelles questions futures sont intentionnellement laissées en dehors de la couche commune ?
7. Quels choix futurs peuvent être effectués par les participants sans modifier l’ensemble de compatibilité auquel ils appartiennent ?
8. Comment un participant adopte-t-il une modification ultérieure ?
9. Comment un participant refuse-t-il une modification ultérieure sans se voir attribuer un statut d’invalidité ?
10. Comment les ensembles de compatibilité sont-ils étiquetés ou découverts ?
11. Comment fonctionne le rejet local lorsqu’un état est invalide ou incompatible selon les règles exécutées par un participant ?
12. Quelle est la voie de bifurcation ?
13. Comment un détenteur prouve-t-il son contrôle sans teneur de registre en place ?
14. Comment une contrepartie vérifie-t-elle l’état sans registre ?
15. Les participants peuvent-ils vérifier la validité ordinaire sans dépendre d’un teneur de registre en place ?
16. Les enregistrements et les artefacts de coordination décrivent-ils la réalité adoptée, ou tentent-ils de déclarer une réalité future non adoptée ?
17. Le système a-t-il réduit au minimum le nombre de décisions intégrées à la couche commune ?
18. Le système a-t-il évité toute autorité permanente déterminant le statut ordinaire des participants ?
19. Les participants peuvent-ils accepter ou rejeter volontairement des contreparties ?
20. Le système peut-il continuer à fonctionner si tous les registres en place disparaissent ?

Adresse de l’auteur

1. Lu
   [À déterminer]