Note 65

Primauté du code en fonctionnement : le correctif nécessaire pour préserver la conception originelle d’Internet

Quel correctif unique rétablirait la conception originelle d’Internet au niveau des registres ?

Lu Heng · 18 avril 2026 · 55 min de lecture

Chaque participant peut vérifier par lui-même. La proposition de Lu Heng fait dépendre la validité de règles vérifiables localement et de l’usage effectif, plutôt que de l’autorisation d’un registre permanent.

Les sept notes de Heng.lu qui précèdent celle-ci dans cette série sont les suivantes :

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

Ils constituaient une autopsie.

Ils suivaient une même pathologie institutionnelle à travers différentes strates : la responsabilité dissociée des 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 préposé aux registres se mette à parler en souverain. Cette succession importe, car la défaillance ne se résumait ni à un mauvais conseil d’administration, ni à un mauvais registre, ni à un procès, ni à un épisode de marché dérangeant. C’était un défaut systémique sous des apparences différentes. La page auteur de CircleID fait désormais clairement apparaître cette série, notamment La trahison du code en fonctionnement et Le blanchiment de mandat. (circleid.com)

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

Il cherche à expliquer pourquoi l’ordre actuel des registres ne peut constituer l’aboutissement, et pourquoi la réparation la moins perturbatrice consiste à compléter la conception technique originelle d’Internet.

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

Sa nécessité n’est plus théorique. Dans un échange récent sur CircleID, John Curran a formulé la défense la plus forte de l’ordre établi. Selon lui, l’autorité du système des RIR n’est pas simplement un sous-produit d’une coordination technique limitée, mais le résultat d’un enchaînement historique : le Livre blanc, l’ICANN, l’ASO, l’ICP-2, la transition de la supervision des fonctions IANA et la continuité d’une gouvernance multipartite conduite par le secteur privé. Il affirme que l’autorité du système des RIR découle de son fonctionnement dans le cadre du modèle multipartite du secteur privé prescrit par le gouvernement des États-Unis. (circleid.com)

Cet argument est utile parce qu’il met le différend au jour.

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 se transformer en mandat permanent de gouvernance au moyen des mécanismes procéduraux qu’elle contrôle elle-même. La réponse de l’ordre établi est oui : la délégation, la reconnaissance, la continuité institutionnelle et les procédures communautaires deviennent un mandat qui se renouvelle de lui-même.

La réponse qu’exige la conception technique originelle d’Internet est non.

La tradition originelle d’Internet était plus circonscrite, plus exigeante et meilleure. La RFC 3935 dit que l’objectif de l’IETF est de « faire mieux fonctionner Internet » ; elle fonde ses travaux sur la compétence technique, la mise en œuvre dans le monde réel et « un consensus approximatif et du code en fonctionnement ». Elle précise aussi que, lorsque l’IETF n’est pas responsable d’un protocole ou d’une fonction, elle ne cherche pas à exercer de contrôle sur celui-ci ou celle-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 en : un consensus approximatif et du code en fonctionnement ». (rfc-editor.org) La RFC 9592 énonce encore plus clairement le refus de la souveraineté : l’IETF n’exploite pas Internet, ne le contrôle pas, ne le surveille pas et n’est pas « la police des protocoles ». (rfc-editor.org)

Cette tradition n’a jamais supposé que les documents avaient un pouvoir magique. Elle signifiait que les documents comptaient lorsqu’ils aidaient les systèmes à fonctionner. Que les procédures étaient tolérées parce qu’elles servaient le déploiement. Qu’une assemblée n’était utile que si elle s’imposait la discipline 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 fonctionnement

La primauté du code en fonctionnement signifie que les systèmes de coordination d’Internet doivent être interprétés de façon restrictive, en référence à la fonction technique minimale que les réseaux en fonctionnement justifiaient à l’origine.

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 fonctionner ensemble.

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

Elle n’existe pas pour faire la police de la morale commerciale.

Elle n’existe pas pour transformer un périmètre géographique de service en titre de propriété.

Elle n’existe pas pour transformer une liste de diffusion en assemblée législative.

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 doctrine interne en matière de politiques change.

Un registre n’est pas un État.

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

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

Une assemblée d’élaboration des politiques n’est pas un parlement.

Une inscription dans un registre peut décrire la réalité opérationnelle. Elle ne la crée pas.

Ce n’est pas du 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 se justifier par une délégation historique, une reconnaissance circulaire ou des rites procéduraux. Il doit se justifier par des règles déterministes que les opérateurs peuvent vérifier localement et par leur adoption dans des systèmes en fonctionnement.

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

Le mauvais ordre est le suivant : assemblée d’élaboration des politiques, déclaration, obligation revendiquée, qualification de conformité, mise en 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 celle-ci : 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 infraction. Aucun registre ne déclare un participant invalide simplement parce qu’il refuse un changement ultérieur. Il n’y a que le code, l’état du registre distribué, la validation, l’adoption, la compatibilité, le rejet local, la bifurcation et l’interopération sélective.

Un opérateur qui refuse un changement ultérieur ne casse pas Internet. Il peut rester dans un ensemble de compatibilité antérieur. Il peut bifurquer. Il peut se déconnecter. Il peut ne plus pouvoir interopérer avec les participants qui ont adopté des règles incompatibles. Mais il ne peut pas rompre l’interopérabilité des autres, qui continuent d’exécuter du 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 statuer sur la validité courante. Les participants valident localement les transitions d’état selon des règles déterministes. Un état invalide n’est pas puni 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.

La défaillance de conception était présente dès l’origine

La première conception des RIR supposait un monde où la valeur en jeu était faible.

Les ressources de numérotation semblaient techniques, abondantes, administratives et peu conflictuelles. Dans ce monde, l’informalité paraissait efficace. Les listes de diffusion ouvertes semblaient représentatives. Une administration fondée sur les contacts paraissait suffisante. Les contrats limitant la responsabilité semblaient inoffensifs. Un registre régional pouvait avoir l’apparence d’un carnet d’adresses.

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

Les adresses IPv4 sont devenues rares, transférables, susceptibles de financement, louées, capitalisées, objets de litiges, visées par des sanctions et intégrées à des réseaux en activité. La couche des registres ne surplombait plus de simples entrées administratives. Elle surplombait des infrastructures productives. Elle surplombait la valeur d’actifs. Elle surplombait la continuité des services aux clients, les déploiements dans le cloud, les activités de télécommunications, la connectivité nationale, les décisions de justice et l’allocation du capital.

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

Elle s’est étendue.

Il en résulte un système qui parle encore le langage de la coordination technique tout en produisant les effets d’une gouvernance des infrastructures. Il demande aux opérateurs de considérer les procédures des registres comme neutres alors que leurs décisions affectent leur destin commercial. Il appelle ses participants « communauté », alors que nombre de ceux qui en subissent les conséquences n’ont jamais donné de mandat juridique en bonne et due forme aux personnes présentes dans la salle.

NRS expose clairement le problème structurel : les registres de numérotation d’Internet ont été conçus comme des organismes de coordination technique, mais dès que 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 des systèmes de coordination contrôlent du 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 énonce aussi la direction de conception opposée : un seul Internet, des infrastructures ouvertes et autonomes, et une gouvernance décentralisée reposant sur une participation humaine minimale. (nrs.help)

Voilà le véritable enjeu. La couche des registres n’a jamais reçu le correctif nécessaire au moment où une table de coordination est devenue un point de contrôle des actifs.

La primauté du code en fonctionnement est ce correctif.

Ce n’est pas une doctrine visant de meilleurs RIR.

C’est une discipline de l’après-RIR.

Les trois règles du correctif

Le cadre constructif est la version révisée de la Note 64 : Spécification initiale minimale, décision future locale et adoption volontaire pour les systèmes de coordination d’Internet : Spécification initiale minimale, Décision future locale 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, vérifiables localement, nécessaires à l’unicité, à l’interopérabilité, à la preuve de contrôle, à la sûreté commune et à la sécurité. Elle ne contient ni préférences de modèle économique, ni théories de fixation des prix, ni sensibilités politiques régionales, ni pouvoirs discrétionnaires de contrainte, ni élargissement de la mission institutionnelle.

La Décision future locale ne signifie pas qu’une institution décide quelles décisions futures sont locales. Ce serait déjà réintroduire la couche d’autorité. Elle signifie que la spécification initiale délimite les choses à l’avance. 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 altérer l’interopérabilité des autres, qui continuent d’appliquer des règles mutuellement compatibles.

L’Adoption volontaire signifie qu’un changement ultérieur ne devient réel que par l’implémentation, la validation, le déploiement et l’usage. La publication n’est pas la réalité. La recommandation n’est pas la réalité. La reconnaissance par l’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 un changement ultérieur reste 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 est une sélection de compatibilité, non une sanction institutionnelle.

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

Elles l’empêchent de réapparaître sous un nouveau nom.

APNIC : la structure juridique constituait le risque

APNIC illustre la première défaillance : le minimum n’a jamais été défini avec assez de rigueur dès l’origine.

Ce n’est pas une affaire de code de conduite. Ce n’est pas une affaire de savoir-vivre. Ce n’est pas une affaire de savoir si un critique s’est montré suffisamment poli envers une institution établie.

C’est une affaire de structure juridique.

En mars 2023, LARUS a publié une analyse juridique avertissant que la structure de gouvernance d’APNIC créait un risque non seulement pour une entreprise de Brisbane, mais pour la gouvernance d’Internet dans toute la région Asie-Pacifique. Selon cette analyse, le directeur général d’APNIC détenait, en dernier ressort, le pouvoir juridique de fermer APNIC et de révoquer le conseil exécutif élu ; 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’internautes en Asie-Pacifique. (larus.net)

La première pièce jointe, l’extrait du registre des sociétés de l’ASIC, fournit les données de base sur la société. APNIC Pty Ltd y figurait comme une société australienne de type « proprietary company », à responsabilité limitée par actions, enregistrée dans le Queensland. Paul Byron Wilson y figurait comme administrateur et secrétaire. Les informations relatives au capital faisaient état d’une seule action ordinaire émise, détenue par Paul Byron Wilson, inscrit comme associé. (larus.net)

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

La seconde pièce jointe, l’avis juridique du Dr Peter Felter, en tirait la conclusion en matière de gouvernance. Elle décrivait la structure d’APNIC présentée au public — 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. Elle indiquait qu’APNIC Pty Ltd était, depuis 25 ans, une société de type « proprietary company » contrôlée par un seul administrateur, un seul actionnaire et un seul secrétaire, tous trois étant la même personne. (larus.net)

Cette distinction importe.

L’institution présentée au public et à la communauté n’était pas la structure juridique ultime. C’était un édifice construit sur la structure d’une société privée.

L’avis juridique expliquait ensuite pourquoi cette distinction importe. Les règlements internes d’APNIC étaient expressément subordonnés aux statuts et aux pouvoirs de la société, de ses administrateurs, de ses dirigeants et de ses associés. Selon cette lecture, la structure publique d’APNIC pouvait être modifiée par une décision de l’administrateur d’APNIC Pty Ltd ; l’avis décrivait APNIC comme, en substance, un département d’APNIC Pty Ltd. (larus.net)

Le point le plus accablant de cet avis n’était pas qu’APNIC fût techniquement illégale. C’était que la légalité et le caractère approprié ne sont pas la même chose. L’avis soutenait que le montage fiduciaire ne résolvait pas le problème, parce que les pouvoirs du conseil exécutif découlaient toujours de la décision de l’administrateur instituant le comité spécial. Il relevait aussi qu’APNIC Pty Ltd était une société privée par actions dont la structure et l’objet ne ressemblaient pas au modèle d’organisme à but non lucratif sans capital-actions que la plupart des gens associeraient à un registre régional d’intérêt public. (larus.net)

Voilà la première défaillance de conception sous sa forme la plus nette.

Un système de coordination des ressources de numérotation à l’échelle d’une région ne devrait pas dépendre d’une structure qui oblige des juristes à expliquer comment une société privée à action unique, un comité spécial, un acte de fiducie et un conseil élu peuvent, ensemble, conférer un contrôle légitime sur le registre de numérotation de l’Asie-Pacifique.

Une couche de coordination critique devrait être intelligible 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 ses membres à découvrir, après des années de dépendance institutionnelle, que la couche élue n’est peut-être pas 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 la confiance institutionnelle. Non 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 de contrôle, des règles de transition d’état, des règles de conflit, la réplication du registre distribué, des voies de sortie, des voies de bifurcation et des ensembles de compatibilité. Si APNIC disparaît, tombe sous emprise, change de position juridique ou refuse de reconnaître un état valide, le réseau en fonctionnement ne devrait pas dépendre de la reconnaissance continue d’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 : la politique s’est heurtée à la réalité des actifs

ARIN illustre la deuxième défaillance : la réalité juridique et marchande peut dépasser la doctrine des registres.

L’événement décisif a été la transaction Nortel/Microsoft. Lorsque Nortel a déposé le bilan, ses 666 624 adresses IPv4 sont devenues des actifs de valeur dans la procédure. Ces adresses ont été vendues à Microsoft pour 7,5 millions de dollars. ARIN est intervenu en soutenant que les adresses n’étaient pas des biens et ne pouvaient être vendues libres de toute contrainte découlant des politiques du registre. Industrie Canada a soutenu cette position. Le tribunal chargé de la faillite 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 rester la seule 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 qu’ARIN aurait été singulièrement défaillant.

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

Une inscription dans un registre a de la valeur parce que les opérateurs, les tribunaux, les acheteurs, les vendeurs, les créanciers et les réseaux s’y fient. Elle n’acquiert pas autorité en niant cette dépendance. Elle ne reste utile que si elle suit assez fidèlement la réalité juridique, marchande et opérationnelle pour inspirer confiance.

Dès que l’IPv4 est devenu rare, les procédures des registres sont devenues 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 corpus fragmenté de règles des RIR, dans lequel cinq systèmes régionaux régissent un marché où les prix se situent autour de 18 à 45 dollars par adresse, avec des règles contradictoires susceptibles de bloquer des actifs, de retarder des fusions et d’imposer des structures juridiques distinctes simplement pour détenir des blocs d’adresses. (btw.media)

Ce n’est pas une coordination neutre.

C’est un effet réglementaire sans obligation de rendre compte propre à un régulateur.

ARIN montre pourquoi l’Adoption volontaire importe. La politique d’un registre ne reste crédible que tant qu’elle décrit ce que les acteurs implémentent, échangent, financent, soumettent aux tribunaux et utilisent effectivement comme fondement. Elle devient dangereuse lorsque sa publication est tenue pour suffisante pour fabriquer la réalité.

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

Il devient une base de données périmée.

Dans une conception fondée sur la primauté du code en fonctionnement, la leçon est encore plus tranchée. 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 de contrôle, la résolution des conflits, des transitions d’état visibles dans le registre distribué et la compatibilité. L’ancien registre peut publier une représentation de l’état. Un client logiciel peut en afficher une. Un explorateur de registre distribué peut en afficher une. Aucun n’est la source de la validité.

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

Il n’y a pas de registre à solliciter.

Il n’y a qu’un état distribué que les participants valident, acceptent, rejettent, à partir duquel ils bifurquent ou avec lequel ils interopèrent.

AFRINIC : quand la doctrine du registre menaçait des actifs en fonctionnement

AFRINIC est le cas central parce qu’il a ramené le problème à l’essentiel.

Le récit erroné est celui d’un membre perturbateur qui aurait paralysé un registre régional.

C’est la fable morale de l’ordre établi.

Le récit structurel est différent. AFRINIC a tenté de transformer l’usage commercial, la localisation des clients, la location, la relation d’adhésion et l’interprétation de ses politiques internes en un pouvoir revendiqué de radier des ressources de numérotation déjà en fonctionnement. Dès lors que ce pouvoir a été revendiqué, le conflit ne pouvait plus rester un désaccord dans une assemblée d’élaboration des politiques. Il mettait à l’épreuve la possibilité, pour un registre privé, d’utiliser la rhétorique régionale et le silence des politiques pour menacer des actifs intégrés aux opérations.

Les faits n’ont pas besoin d’être dramatisés. Des articles publics ont décrit le différend avec AFRINIC comme un simple litige commercial portant sur des adresses IP, devenu la plus grande affaire de gouvernance d’Internet en Afrique. Ils ont aussi rapporté que Cloud Innovation avait souvent été dépeint comme le coupable, alors que des documents apparus par la suite pointaient vers des forces destructrices au sein même d’AFRINIC et vers des procédures retardées, prolongées et poursuivies par des représentants d’AFRINIC, aux frais d’AFRINIC. (btw.media)

Cela importe parce que cela renverse le récit habituel.

Le contentieux n’a pas créé la défaillance structurelle.

Il l’a révélée.

La défaillance en cause était déjà présente lorsqu’un registre privé a traité l’absence d’autorisation expresse comme un fondement de contrôle coercitif. La location ne menaçait pas l’unicité. La localisation des clients n’était pas une attribution en double. L’usage commercial n’était pas une défaillance de sécurité du routage. Un modèle économique déplaisant à un registre n’était pas un invariant global.

Pourtant, la prétention du registre a fait entrer ces questions dans un cadre de révocation.

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

Les articles rapportent qu’AFRINIC a adressé à Cloud Innovation, en mars 2021, une lettre alléguant des violations de ses politiques 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 d’annuler cette adhésion a été bloquée en décembre 2021. (btw.media) Cette succession ne raconte pas l’histoire d’un registre protégeant calmement Internet. Elle raconte celle d’une autorité de registre confrontée au droit commun.

L’effondrement institutionnel plus large n’a pas davantage été causé par un manque de pouvoir du registre. Le problème profond était le verrouillage. Si un registre détient un monopole de reconnaissance sur des actifs de valeur en activité, 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 lui confère un pouvoir de prise en otage.

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

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

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

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 encodées dans l’état d’un registre distribué, dans des règles de preuve de 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 soumettre la continuité des actifs à autorisation.

AFRINIC démontre la nécessité de la Décision future locale correctement comprise. Il n’y a pas d’organisme central décidant qu’une future décision commerciale « relève du niveau local ». Au contraire, la spécification initiale doit garantir que ces décisions n’entrent jamais dans la couche commune. La location, la localisation des clients, l’usage commercial, les prix, le financement, la composition de la clientèle et la stratégie de déploiement restent hors des règles déterministes de validité, 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 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 servant des clients hors 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 qui déplaît à un registre.

Tout au plus peut-il ne pas satisfaire aux règles déterministes qu’appliquent les autres participants. Dans ce cas, ces derniers rejettent localement l’état invalide. Il n’y a pas de couche punitive. Il n’y a pas de tribunal de la conformité. Il n’y a pas de souverain régional.

Cette frontière n’est pas idéologique.

Elle est opérationnelle.

La question des procurations n’est pas un détail

La controverse sur les élections d’AFRINIC a mis en lumière un second défaut : la représentation.

NRS expose le fondement de sa représentation en termes juridiques directs. Il indique que les membres figurant sur sa liste lui ont confié le mandat de les représenter dans les questions de gouvernance des RIR et que chacun a fourni une procuration. (nrs.help) Pendant le différend électoral d’AFRINIC, NRS a demandé aux membres de signaler si leurs noms figuraient sur les listes électorales ou si des votes avaient été enregistrés sans leur participation, précisant que ces signalements factuels seraient traités par les voies légales. (nrs.help)

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

Le système des RIR confond souvent plusieurs catégories : représentant d’une entreprise, contact dans une base de données, contact technique, salarié, consultant, titulaire d’une procuration, participant à l’élaboration des politiques, habitué d’une liste de diffusion. Ce ne sont pas les mêmes choses.

Un contact dans une base de données peut aider à administrer les inscriptions.

Une procuration peut autoriser une représentation si elle est valide et utilisée dans les limites de son mandat.

Un participant à l’élaboration des politiques peut apporter une expertise.

Un intervenant sur une liste de diffusion peut exprimer une opinion.

Aucun ne devient automatiquement le mandant juridique de chaque entreprise, client, État, créancier, prêteur, acheteur, locataire ou réseau qui subit 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é, le traitement des sanctions, la continuité des actifs ou le risque pesant sur les infrastructures nationales, la représentation devient une question constitutionnelle.

Une assemblée n’est pas un mandat.

Une liste de diffusion n’est pas un peuple.

Une fiche de contact n’est pas une procuration délivrée par une entreprise.

Une région de service n’est pas un corps politique souverain.

Ce n’est pas du pointillisme procédural.

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 qui nécessitent une représentation. Si la validité est déterministe et locale, il y a moins de choses à soumettre au vote. Si les changements futurs sont volontaires, nul besoin de décider si un non-adoptant est en règle. Si l’état est représenté dans un registre distribué, nul besoin de supplier le registre en place de reconnaître que l’on continue d’exister. Si les ensembles de compatibilité sont explicites, les participants savent avec qui ils peuvent interopérer sans consulter une assemblée politique.

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

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

RIPE NCC et LACNIC ne prouvent pas que certains RIR sont plus civilisés que d’autres. Ils prouvent que le modèle des RIR comporte deux couches de contrainte au-delà de la fonction technique : le club et le goulet d’étranglement.

Le club décide qui est respectable. Le goulet d’étranglement décide qui peut faire évoluer son statut dans le registre.

Le refus de RIPE NCC d’accepter le parrainage de LARUS pour RIPE 90 a clairement exposé 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 relative à l’unicité. Ce n’était pas une règle de validation déterministe. C’était une mise à l’index privée par le contrôle de l’accès à une conférence. LACNIC a également refusé mon parrainage. Autre région, même réflexe : 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 filtrage des accès.

La couche des sanctions est pire, car elle montre le goulet d’étranglement central sous sa forme juridique. RIPE NCC indique que, parce qu’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 inscriptions dans la base RIPE, bloque les acquisitions et les transferts, et peut considérer un dossier comme gelé lorsqu’une partie ne fournit pas une documentation suffisante. Il vérifie également les listes de l’OFAC parce que ses relations bancaires influent sur les paiements. (Transparence de RIPE NCC sur 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 celui de l’Union européenne. Le problème est architectural : pourquoi une seule entité privée néerlandaise devrait-elle être le point central de reconnaissance de la mobilité des ressources de numérotation pour de nombreux pays, opérateurs et systèmes juridiques ?

Des sanctions peuvent s’imposer à une banque. Elles peuvent s’imposer à une entité néerlandaise. Elles 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à la défaillance de conception.

La même centralité qui permet à un club d’exclure un critique permet aussi à une juridiction de geler la mobilité dans le registre. L’une relève de la contrainte sociale. L’autre de la contrainte juridique. Les deux ne fonctionnent que parce que le registre occupe une place où la validité ne devrait pas résider.

Le lien avec les trois principes est direct.

Spécification initiale minimale : la respectabilité au sein du club, l’admissibilité au parrainage, la politique régionale, la classification au regard 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 de contrôle, au traitement des conflits, aux transitions d’état et à la sécurité.

Décision future locale : le risque juridique, le choix des contreparties, le parrainage, la confiance commerciale et l’exposition aux sanctions relèvent des acteurs qui en supportent les conséquences. Une entité néerlandaise peut refuser une transaction. Une banque peut refuser un paiement. Une contrepartie peut refuser une relation d’affaires. Rien de cela ne devrait devenir une vérité universelle du registre.

Adoption volontaire : les participants acceptent leurs 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. Le 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, 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é courante n’est pas décidée par RIPE NCC, LACNIC, un service chargé des sanctions, un comité organisateur ou un bureau du 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é.

Le remède n’est pas un meilleur savoir-vivre.

Le remède n’est pas une file de traitement des sanctions plus transparente.

Le remède consiste à soustraire la validité au club comme au goulet 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

L’élément le plus grave n’est pas la tentative d’AFRINIC d’outrepasser ses pouvoirs.

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

En 2022, la Number Resource Organization a écrit au gouvernement de Maurice. La lettre présentait la NRO comme l’organisme de coordination des RIR du monde entier et indiquait que les RIR gèrent les ressources de numérotation dans leurs régions respectives. Elle précisait que les cinq registres administrent ces ressources 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 actions judiciaires de Cloud Innovation, affirmait que plus de 25 procédures avaient été engagées, se plaignait de décisions de justice ayant gelé les comptes d’AFRINIC et interrompu les élections, et indiquait qu’AFRINIC avait demandé à plusieurs reprises à Maurice de le reconnaître comme une 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 cette histoire.

Lorsqu’un registre privé s’est heurté aux juridictions de droit commun, le réflexe du système n’a pas été de restreindre le mandat.

Il n’a pas été de supprimer le verrouillage imposé par le registre.

Il n’a pas été de séparer la tenue des données du pouvoir de contrainte.

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

Il n’a pas été de se demander si le pouvoir unilatéral de radier des actifs en fonctionnement n’avait pas été illégitime dès l’origine.

Le réflexe a été la fuite 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 des redevances, étranger à la propriété lorsqu’il veut éviter les responsabilités du propriétaire, et quasi international lorsqu’il veut se soustraire aux tribunaux.

Cet assemblage n’est pas de la gouvernance.

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

Si les RIR veulent les privilèges du droit public, ils doivent accepter les obligations de rendre compte du droit public. S’ils veulent la souplesse du droit privé, ils doivent accepter les contentieux du droit privé. Ce qu’ils ne peuvent raisonnablement exiger, c’est cumuler un pouvoir discrétionnaire privé, l’importance d’une infrastructure publique, une faible responsabilité, une représentation déficiente, un statut de monopole et une protection quasi diplomatique.

C’est la voie du désastre.

La primauté du code en fonctionnement la rejette.

Lorsqu’un registre rencontre une résistance juridique, il ne doit pas fuir vers le haut, vers l’immunité. L’architecture doit se resserrer vers le bas, jusqu’à la fonction limitée du code en fonctionnement qui la justifiait.

Moins de souveraineté.

Aucun registre comme source de validité.

Moins de contrainte.

Plus de validation distribuée.

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

Le système actuel sait que quelque chose s’est brisé.

La page de consultation publique de l’ICANN consacrée à la deuxième version du document de gouvernance des RIR indique que la proposition établirait des règles et des critères de reconnaissance de nouveaux RIR, des obligations et exigences de fonctionnement pour les RIR, ainsi que des règles de retrait de reconnaissance ; si elle était adoptée, elle remplacerait ICP-2. La même page indique que le processus a été engagé après que la NRO a demandé à l’ASO de proposer des mises à jour afin de renforcer l’obligation du système des RIR de rendre compte à 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 : à partir de quel degré de défaillance un registre doit-il être retiré ?

La question préalable est plus importante : pourquoi un registre devrait-il être assez puissant pour que sa défaillance puisse être catastrophique ?

Un successeur d’ICP-2 qui se contente de renforcer la reconnaissance, l’audit, la passation et le retrait de reconnaissance peut améliorer l’hygiène institutionnelle tout en maintenant l’erreur de catégorie. Il suppose toujours que le RIR est la forme souveraine première de coordination des ressources de numérotation.

La primauté du code en fonctionnement pose d’autres questions.

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

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

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

Comment empêcher les inscriptions de devenir des armes de contrainte ?

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

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

Comment un opérateur valide-t-il l’état courant sans demander à un organisme permanent de statuer sur son statut ?

Comment éviter que le refus soit qualifié d’infraction ?

Ce ne sont pas des questions de réforme.

Ce sont des questions de l’après-RIR.

Pourquoi il s’agit du correctif à la conception originelle

La question n’est pas d’aimer ou de détester les registres en place.

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

La primauté du code en fonctionnement n’est ni une stratégie de communication ni un compromis institutionnel. C’est la réparation technique qu’implique la conception originelle. 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 de numérotation ne peut recréer ces formes au moyen des procédures des registres, d’une délégation historique ou d’une mise en scène communautaire.

Le consensus seul peut devenir un rituel. Le code en fonctionnement seul peut être subordonné si la couche des registres se situe en amont de la reconnaissance. La règle manquante est interprétative et architecturale : lorsque les procédures institutionnelles entrent en conflit avec la fonction technique minimale requise par les systèmes en fonctionnement, le code en fonctionnement 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 la conception originelle est préservée, et non abandonnée.

Internet a compté parce qu’il est devenu le premier système mondial de communication qui n’exigeait pas l’autorisation préalable d’un souverain, d’un ministère, d’une Église, d’une entreprise ou d’un gardien unique. Si cet acquis mérite encore d’être défendu, la couche des registres ne peut devenir l’exception qui dévore la règle.

Un système construit pour se passer de rois ne peut laisser un teneur de livres se porter candidat au trône.

Le correctif rétablit la hiérarchie originelle : le code d’abord, les opérateurs d’abord, la validation déterministe d’abord, l’état distribué d’abord ; les institutions, s’il en reste pendant la transition, uniquement comme artefacts ne faisant pas autorité, jamais comme 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 clergé pour remplacer l’ancien.

Il y a 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, un traitement des conflits, des ensembles de compatibilité, un 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 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 devrait maîtriser l’usage commercial, la location, la localisation des clients, les pratiques de routage, le financement, le choix des contreparties et les règles commerciales qui ne relèvent pas des invariants.

La couche d’adoption devrait déterminer ce qui devient réel. Une règle de coordination ne compte que si les opérateurs peuvent l’implémenter, les contreparties l’accepter, les marchés s’y fier, les tribunaux la comprendre, et si l’interopérabilité est préservée sans faire de la reconnaissance par l’institution en place la seule source de réalité.

La couche de contrainte ne doit pas être fusionnée avec la couche d’état. Un registre distribué peut consigner l’état. Il peut valider les transitions. Il peut révéler les conflits. Il peut rendre la preuve portable. Il ne doit pas devenir à la fois procureur, juge, autorité de sanction, régulateur du marché, moraliste commercial et dépositaire des actifs.

La portabilité, surtout, doit être comprise correctement.

Dans un monde de registres distribués, la portabilité ne signifie pas passer d’un registre à un autre. Cela reste la logique des registres. Il n’y a pas de registre vers lequel migrer. La preuve de contrôle du détenteur, son historique d’état et sa 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é et vérifiable que les participants valident localement et que les contreparties acceptent volontairement.

Sans cela, chaque registre est un point de verrouillage.

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

La coordination post-RIR a donc besoin de quatre propriétés de conception.

Premièrement, la validité déterministe. Un participant devrait 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, les ensembles de compatibilité. Si les participants adoptent des règles futures différentes, le système devrait décrire clairement la frontière de compatibilité plutôt que de traiter le désaccord comme une faute.

Troisièmement, la preuve de contrôle distribuée. Un détenteur ne devrait pas « déplacer » ses ressources vers un autre registre ; il devrait démontrer son contrôle au moyen d’un état valide dans le registre distribué, 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 des participants. Elle ne donne pas à un camp 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 trajectoire de défaillance est prévisible

Si rien ne change, la trajectoire de défaillance est claire.

Premièrement, davantage de différends passeront des assemblées d’élaboration des politiques aux tribunaux. Des actifs rares attirent l’examen juridique. Il sera demandé aux tribunaux de geler des comptes, de préserver des données, de bloquer des élections irrégulières, de nommer des administrateurs judiciaires, de reconnaître des transferts ou de déterminer qui peut agir au nom d’un registre.

Deuxièmement, les États cesseront de traiter les RIR comme d’inoffensives associations techniques. La continuité de la numérotation touche à la connectivité nationale, aux sanctions, à l’application de la loi, à la résilience des télécommunications, aux infrastructures cloud et à la sécurité économique. Aucun État n’acceptera éternellement qu’une structure privée étrangère de registre soit, sans examen, le point situé en amont de la continuité de ses communications nationales.

Troisièmement, les opérateurs contourneront l’autorité des registres lorsque ce sera possible. Si les inscriptions dans les registres deviennent politiques, peu sûres, non représentatives ou dissociées de la réalité des actifs, les opérateurs s’appuieront sur des contrats privés, des transferts confortés par les tribunaux, des attestations alternatives, une reconnaissance nationale ou la réalité de fait du routage.

Quatrièmement, l’ICANN et la couche NRO seront tentées de centraliser. Cela produirait une version plus épaisse du même problème, à moins de restreindre le mandat lui-même.

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 obligation publique de rendre compte, les États finiront par reprendre la souveraineté. Il pourrait en résulter une fragmentation, des représailles, des registres contradictoires et des pressions politiques 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 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 comme source courante de validité. Cela réduit la surface d’attaque. Cela réduit le pouvoir institutionnel de prise en 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 détient le mandat ?

C’est la mauvaise question.

La meilleure question est : qu’exige réellement le code en fonctionnement ?

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

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

Corrige-t-elle une fraude à l’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 ?

Supprime-t-elle la dépendance envers une seule institution en place ?

Décrit-elle une réalité adoptée, ou proclame-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é courante sans demander à un registre de statuer sur son statut ?

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

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

Si la réponse ne se rattache pas à une nécessité déterministe du code en fonctionnement, le pouvoir ne devrait pas se trouver dans la couche commune.

Voilà la primauté du code en fonctionnement.

Pour ouvrir la discussion

Cette proposition est soumise à discussion. Ce n’est pas un règlement définitif.

La prochaine étape devrait être un véritable Internet-Draft 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. Ce projet ne devrait pas demander comment réhabiliter le monopole des RIR. Il devrait demander comment construire une coordination post-RIR au moyen de l’état d’un registre distribué, de la validation déterministe, de l’adoption volontaire, de l’acceptation des contreparties et d’ensembles de compatibilité explicites.

Il devrait être mis à l’épreuve par des opérateurs, des juristes, des économistes, des ingénieurs en 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 globaux ?

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 relèvent des 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 de refus ?

Quelle est la voie de bifurcation ?

Quelle est la voie de rejet local ?

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

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

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

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

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

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

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

Une inscription peut-elle décrire la réalité sans devenir souveraine sur elle ?

Toute personne intéressée peut me contacter sur LinkedIn. Les chercheurs, auteurs techniques, institutions ou experts des politiques publiques qui souhaitent contribuer sérieusement à transformer cette proposition en un premier Internet-Draft, puis, si la communauté le juge utile, en une discussion autour d’une RFC ou d’une BCP, 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 qu’exigeait réellement le code en fonctionnement.

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 locale et adoption volontaire pour les systèmes de coordination d’Internet

Note 64

Résumé

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

Dans ce modèle, la Spécification initiale ne définit que les règles déterministes, vérifiables localement, requises pour l’unicité, l’interopérabilité, la preuve de contrôle, la sûreté commune et la sécurité. Après la Spécification initiale, les changements futurs ne sont pas approuvés par un organisme central. Les participants qui exécutent le code les adoptent, les ignorent, en font des bifurcations ou les abandonnent.

Le schéma de conception visé est un registre distribué d’état valide, ou un mécanisme équivalent d’état distribué vérifiable, et non une hiérarchie de registres. Il n’existe pas de registre permanent qui statue sur la validité courante. Les participants valident l’état localement, acceptent volontairement leurs 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 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 est une sélection de compatibilité, une bifurcation, un isolement ou une interopération sélective, non une sanction institutionnelle.

Ce document ne définit pas de protocole de communication sur le réseau. Il énonce une meilleure pratique actuelle, au sens de la catégorie 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 d’Internet naissent avec 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, l’état d’un registre distribué ou un enregistrement 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 généralement en trois étapes.

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

Deuxièmement, des choix qui devraient revenir aux 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é le changement dans des systèmes en fonctionnement.

Il en résulte un système fragile. Une couche de référence technique devient une couche de gouvernance. Un teneur de registre devient un gardien des accès. Un artefact de coordination devient une source de contrôle futur.

Ce document propose une autre discipline de conception :

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 de contrôle, la sûreté commune et la sécurité.
Décision future locale : 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 altérer l’interopérabilité des autres participants qui continuent d’appliquer des règles mutuellement compatibles.
Adoption volontaire : ne rendre un changement ultérieur réel 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éinstalle un 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 au regard d’un état partagé. Un participant peut adopter un changement ultérieur, le refuser, bifurquer, se déconnecter ou interopérer de manière sélective. Tout au plus peut-il se retirer lui-même d’un ensemble de compatibilité. En refusant un changement, il ne peut pas rompre l’interopérabilité des autres participants qui continuent d’exécuter du 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 du code de validation et décident quel état ils acceptent, 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, notamment, sans s’y limiter, aux systèmes d’identifiants, aux cadres de nommage et de numérotation, aux mécanismes d’extension des 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 s’appuient sur un point de référence technique commun.

Ce document ne s’oppose pas aux règles communes. Il soutient qu’elles 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 implémentation particulière de 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 réplicable, sans demander à une autorité permanente une permission ou une décision de statut.

3. Conventions et définitions

3.1. Vocabulaire des exigences

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

3.2. Terminologie

Spécification initiale :
L’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 requis pour le premier déploiement d’un système.

Couche commune :
L’ensemble minimal de règles partagées ou la structure de référence minimale nécessaire pour permettre à des participants indépendants d’interopérer. La couche commune n’est pas une institution. Elle est la substance technique que les participants implémentent et vérifient.

Registre distribué :
Un enregistrement répliqué ou autrement distribué des transitions d’état, qui permet aux participants de vérifier la validité courante 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 implémentation particuliers.

Règle de validation déterministe :
Une règle qui permet à un participant de décider, par un calcul local ou une vérification locale, si un état, un enregistrement, une transition, une assertion ou un message est valide selon un ensemble de règles donné.

Invariant global :
Une propriété qui doit rester commune au sein d’un ensemble de compatibilité pour préserver l’unicité, l’interopérabilité de base, l’intégrité de la preuve de contrôle, la sûreté commune ou la sécurité.

Participant :
Un opérateur, une implémentation, un nœud, un réseau, une organisation ou un autre acteur qui fait fonctionner le système, le vérifie, le déploie ou s’appuie sur lui.

Ensemble de compatibilité :
Un 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 :
L’implémentation, le déploiement, la validation et l’usage effectifs par les participants qui font fonctionner le système.

Acceptation des contreparties :
La décision volontaire d’un participant d’accepter l’état d’un autre participant, d’effectuer des transactions avec lui, d’interopérer avec lui ou de s’appuyer sur cet état selon les règles de validation qu’il exécute.

Non-adoption :
Le choix d’un participant de ne pas implémenter ou utiliser un changement proposé. La non-adoption ne crée pas de statut d’invalidité. Elle signifie seulement que le participant n’a pas rejoint l’ensemble de compatibilité créé par ce changement.

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

Bifurcation :
Une divergence des règles de validation ou des pratiques opérationnelles qui crée deux ensembles de compatibilité ou davantage.

Artefact de coordination :
Un document, une recommandation, une note d’implémentation, un profil, une implémentation de référence, un explorateur de registre distribué, un miroir ou tout autre artefact qui aide 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 cherchent souvent à réduire l’incertitude future en inscrivant trop de choses dans la couche fondatrice ou en conservant un organisme permanent chargé d’interpréter les questions futures. Cela paraît prudent. C’est souvent dangereux.

Une spécification excessive de la couche fondatrice entraîne trois coûts.

Premièrement, elle déplace les choix futurs vers une couche commune où le changement est plus difficile et où la prise de contrôle a des effets plus importants.

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

Troisièmement, elle encourage un organisme qui tient des données, 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 changements, détermine les statuts ou interprète le fonctionnement courant, il a créé une couche de contrôle après sa fondation. Cette couche peut commencer comme de l’administration. Elle peut devenir de la gouvernance. Elle peut ensuite devenir un goulet d’étranglement.

L’objectif de conception de ce document n’est pas d’améliorer le pouvoir discrétionnaire des institutions. Il 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, vérifiables localement ; représenter l’état valide sous une forme distribuée ou autrement réplicable ; laisser hors de la couche commune les choix qui ne relèvent pas des invariants ; et ne permettre aux changements ultérieurs de devenir réels que 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 requises pour l’interopérabilité de base, l’unicité, la preuve de contrôle, la sûreté commune et la sécurité.

5.2. Exigences

Une conception qui applique ce principe :

DOIT identifier explicitement ses Invariants globaux.
DOIT définir des règles de validation déterministes pour chaque Invariant global.
DOIT définir comment l’état valide est représenté, répliqué, vérifié et mis à jour.
NE DOIT PAS placer une règle dans la Spécification initiale à moins que cette règle ne soit nécessaire pour préserver un Invariant global énoncé ou permettre le premier déploiement.
DOIT séparer les règles de validation des préférences de politique, des arrangements commerciaux, des rôles institutionnels, des ambitions de gouvernance et du jugement discrétionnaire.
DOIT permettre aux participants de vérifier localement la validité courante sans consulter aucune institution, aucun registre, aucun comité, aucun organisme d’élaboration des politiques ni aucune autre autorité.
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.
DEVRAIT définir la signalisation des extensions, la gestion des versions, l’étiquetage de compatibilité ou l’identification des bifurcations lorsque des variations futures sont prévisibles.
DOIT garantir que les artefacts de coordination requis sont portables, auditables, reproductibles et remplaçables.
DEVRAIT privilégier des conditions objectives vérifiables par machine plutôt qu’une appréciation subjective du 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. Conséquences pour la conception

Spécification initiale minimale ne signifie pas spécification vague. Cela signifie spécifier rigoureusement ce qui doit être commun, et rien d’autre.

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

Une conception qui ne peut énoncer clairement ses Invariants globaux et ses règles de validation déterministes devrait présumer qu’elle a spécifié trop de pouvoir discrétionnaire et trop peu de substance vérifiable.

6. Principe 2 : Décision future locale

6.1. Énoncé

Après la Spécification initiale, les Décisions futures DEVRAIENT rester locales, entre les mains des participants qui exécutent le code. Une Décision future ne prend effet 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 de statut d’invalidité.

6.2. Exigences

Une conception qui applique ce principe :

NE DOIT PAS exiger que les participants obtiennent l’autorisation d’une institution en place, d’un registre, d’un comité, d’un conseil, d’un organisme d’élaboration des politiques 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.
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é au regard de la Spécification initiale de la compatibilité avec un changement facultatif ultérieur.
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 leurs 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 d’élaboration des politiques ou tout autre acteur à déclarer un participant invalide simplement parce qu’il a refusé 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 teneur de registre en place peut empêcher des participants par ailleurs valides de continuer à interopérer.

6.3. Conséquences pour la conception

Décision future locale ne signifie pas qu’une autorité centrale répartit les décisions futures entre des acteurs locaux. Cela signifie que le système est conçu de telle sorte qu’après la Spécification initiale, les choix futurs ordinaires n’ont pas besoin d’une telle répartition.

La Spécification initiale délimite les choses à l’avance. Elle définit les invariants minimaux requis pour l’unicité, l’interopérabilité, la preuve de contrôle, la sûreté commune et la sécurité. Tout le reste demeure hors de la couche commune.

Les changements futurs ne sont pas approuvés centralement. Les participants qui exécutent le code les adoptent, les ignorent, en font des bifurcations ou les abandonnent.

Un participant qui refuse un changement peut rester hors de l’ensemble de compatibilité créé par ce changement. Il peut se déconnecter des autres. Il peut continuer dans un ensemble de compatibilité antérieur. 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’appliquer des règles mutuellement compatibles.

L’effet d’un état invalide ou incompatible est le rejet local, non la punition. Personne n’a besoin de décider qu’un participant n’est pas en règle. 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. Énoncé

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

7.2. Exigences

Une conception qui applique ce principe :

NE DOIT PAS considérer la publication, la recommandation, l’approbation en réunion ou l’approbation procédurale comme suffisantes pour créer une obligation opérationnelle universelle.
DOIT permettre aux participants qui choisissent de les exécuter de déployer progressivement de nouvelles règles, extensions, profils ou procédures.
DOIT permettre aux participants de refuser un changement ultérieur 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é.
DOIT permettre aux participants de continuer à utiliser un ensemble de compatibilité antérieur lorsque la Spécification initiale autorise cette continuité.
DOIT permettre aux participants qui exécutent 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.
DEVRAIT définir des voies d’adoption pour les changements majeurs, notamment la signalisation des versions, l’étiquetage de compatibilité, des orientations de transition et des vecteurs de test.
DEVRAIT définir des voies de refus pour les changements majeurs, notamment la manière dont les participants non adoptants poursuivent leur fonctionnement, identifient leur ensemble de compatibilité et évitent une interopération ambiguë.
DOIT garantir qu’il est possible de se dégager des artefacts de coordination requis, de les reproduire en miroir, de les réimplémenter ou de les remplacer sans coût de transition insurmontable.
DEVRAIT faire en sorte que les enregistrements, recommandations et artefacts de coordination décrivent la réalité adoptée plutôt que de prétendre faire exister, par déclaration, une réalité future non adoptée.
DOIT éviter de concevoir un système dans lequel la reconnaissance préalable par un organisme en place constitue la seule façon pour un changement de devenir réel.

7.3. Conséquences pour la conception

L’Adoption volontaire est le test opérationnel qui détermine si un changement est utile, supportable 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 implémentent, valident, déploient, acceptent des contreparties et s’appuient sur le changement.

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

Cela n’élimine ni les processus de normalisation, ni la documentation, ni les notes d’implémentation, ni les explorateurs, ni les miroirs, ni l’examen. Cela limite leurs prétentions. 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. Ils ne peuvent pas, par une simple déclaration, rendre une réalité future non adoptée contraignante pour les participants qui ne l’exécutent pas.

8. Relations 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 locale garantit que les choix futurs restent aux participants qui exécutent le code, plutôt que d’être repris par une couche centrale d’approbation.

L’Adoption volontaire garantit qu’un changement ultérieur doit résister à l’épreuve de l’implémentation, de la vérification, de l’acceptation des 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 locale peut encore permettre une accumulation d’autorité après le déploiement.
La Décision future locale sans Spécification initiale minimale peut produire de l’ambiguïté, parce que les participants ne peuvent pas déterminer la validité localement.
L’Adoption volontaire sans validation déterministe peut produire de la confusion, parce que les participants ne peuvent pas distinguer une variation compatible d’un état invalide.
La validation déterministe sans état distribué peut encore laisser les participants dépendants d’un teneur de registre privilégié.
L’état distribué sans visibilité des bifurcations peut dissimuler 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, ces principes produisent un système dans lequel la couche commune est mince, la validité est vérifiable localement, les changements futurs sont volontaires, l’état est distribué et aucune institution permanente n’est nécessaire pour statuer sur le fonctionnement courant.

9. Schéma de conception recommandé

9.1. Couche commune déterministe et distribuée

La couche commune DEVRAIT se limiter 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 de contrôle ;
des règles de transition d’état ;
des exigences d’interopérabilité au niveau du format sur le réseau ou du protocole ;
des invariants de sécurité partagés ;
des formats d’état portables et auditables ;
la 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 de modèle économique ;
des règles de fixation des prix ;
des préférences politiques régionales ;
une idéologie de l’admissibilité sans rapport avec les invariants techniques ;
des pouvoirs discrétionnaires de contrainte ;
des appréciations subjectives du mérite ;
un élargissement de la mission institutionnelle ;
toute règle dont la fonction première est de préserver l’autorité d’un organisme en place.

9.2. Domaine de décision des opérateurs

Les éléments suivants DEVRAIENT rester hors de la couche commune, à moins qu’ils ne modifient directement un Invariant global énoncé :

le calendrier du déploiement ;
l’usage commercial ;
la localisation des clients ;
les arrangements de location, de financement ou de transfert ;
les préférences locales en matière d’admissibilité ;
l’ordonnancement des opérations ;
les pratiques de routage non requises pour la validité partagée ;
le modèle économique ;
la structure organisationnelle ;
le calendrier des migrations volontaires ;
les profils ou extensions facultatifs ;
le choix des contreparties.

Les participants PEUVENT faire 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 pas d’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 réalisable, l’ordre préférable pour un changement substantiel du système est le suivant :

proposition ;
implémentation ;
vecteurs de test ou méthode de vérification déterministe ;
déploiement limité par des participants volontaires ;
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 chercher à la devancer.

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 plutôt que comme des échecs.

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

continuer dans un ensemble de compatibilité antérieur ;
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 un fonctionnement valide a probablement dissimulé un pouvoir de gouvernance dans sa fonction de tenue des données.

10. Applicabilité et limites

Ce schéma de conception est particulièrement applicable lorsque :

le système implique plusieurs acteurs et plusieurs juridictions ;
le déploiement indépendant importe ;
la couche de coordination est destinée à rester mince ;
des variations futures sont probables, mais ne peuvent être prévues en détail ;
le verrouillage 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 prise de contrôle institutionnelle.

Il peut être moins directement applicable lorsque :

l’architecture visée repose sur un seul domaine administratif ;
un couplage étroit en temps réel exige un comportement uniforme à tout moment ;
la protection des vies humaines exige une uniformité mondiale immédiate ;
aucun mécanisme praticable ne permet de vérifier la validité localement.

Même dans de tels cas, les concepteurs DEVRAIENT toujours réduire au minimum la couche commune et éviter autant que possible le contrôle discrétionnaire futur.

11. Ce qui n’est pas visé

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 qui revendique pourtant la compatibilité ;
n’élimine 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 prise de contrôle, limiter l’étendue des conséquences d’une erreur institutionnelle et améliorer la possibilité de remplacement. Toutefois, une plus grande latitude locale et un état distribué peuvent aussi créer des postures de sécurité incohérentes, des voies de rétrogradation, des pressions à la fragmentation, des revendications ambiguës de compatibilité, des bifurcations dangereuses, des différends sur l’état du registre distribué et des tentatives de falsification des preuves.

Les concepteurs qui appliquent ce document DOIVENT donc 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, au rejeu et au transfert non autorisé ;
la négociation des versions et le traitement des extensions DOIVENT éviter toute rétrogradation silencieuse lorsqu’elle affecte la sécurité ;
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 assez claires pour empêcher 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 représentations incohérentes ;
une variation locale NE DOIT PAS être autorisée à revendiquer faussement la compatibilité avec un ensemble de règles auquel elle ne satisfait pas.

L’existence d’exceptions liées à la sécurité ne justifie pas une couche générale d’autorisation. Elle ne justifie que les règles de sécurité déterministes nécessaires à la préservation des Invariants globaux énoncés.

13. Considérations relatives à l’IANA

Ce document ne prévoit 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 majuscules et 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 de conception pour les extensions de protocoles, RFC 6709.
RFC 7282 — Resnick, P., Du consensus et du fredonnement au sein de l’IETF, RFC 7282.

Annexe A. Liste de vérification de la conception

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

Quels sont les Invariants globaux ?
Quelles règles de validation déterministes préservent ces Invariants globaux ?
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 de manière indépendante ?
Quelles questions futures sont volontairement laissées hors de la couche commune ?
Quels choix futurs les participants peuvent-ils faire sans modifier l’ensemble de compatibilité auquel ils appartiennent ?
Comment un participant adopte-t-il un changement ultérieur ?
Comment un participant refuse-t-il un changement ultérieur sans se voir attribuer un statut d’invalidité ?
Comment les ensembles de compatibilité sont-ils étiquetés ou découverts ?
Comment le rejet local fonctionne-t-il lorsque l’état est invalide ou incompatible selon les règles qu’exécute un participant ?
Quelle est la voie de bifurcation ?
Comment un détenteur prouve-t-il son contrôle sans teneur de registre en place ?
Comment une contrepartie vérifie-t-elle l’état sans registre ?
Les participants peuvent-ils vérifier la validité courante sans dépendre d’un teneur de registre en place ?
Les enregistrements et artefacts de coordination décrivent-ils la réalité adoptée, ou cherchent-ils à faire exister par déclaration une réalité future non adoptée ?
Le système a-t-il réduit au minimum le nombre de décisions intégrées à la couche commune ?
Le système a-t-il évité toute autorité permanente déterminant le statut courant des participants ?
Les participants peuvent-ils accepter ou rejeter volontairement des contreparties ?
Le système peut-il continuer de fonctionner si tous les registres en place disparaissent ?

Auteur : Lu Heng

Où se situe cette Note

Que faut-il préserver, et pour qui ?

Ce que cette Note apporte

Le code en fonctionnement doit primer sur l’autorisation institutionnelle

La Note 65 met au jour une protection manquante dans la coordination d’Internet : le registre avait été conçu comme un relevé technique limité, mais la rareté de l’IPv4 l’a transformé en pouvoir sur une infrastructure précieuse et en service. Elle propose la primauté du code en fonctionnement. Les règles communes initiales doivent rester limitées, déterministes et vérifiables localement ; ensuite, les acteurs qui font tourner le code décident eux-mêmes ce qu’ils mettent en œuvre, vérifient, adoptent, forkent ou refusent. Un document de politique ou une déclaration institutionnelle ne peut pas rendre universellement obligatoire une modification qui n’est pas déployée. La question est urgente : une décision de registre peut toucher des réseaux actifs, des clients et la continuité de services à l’échelle mondiale.

Cette question dans l’exposition

“Every system eventually reaches a moment when it must either adapt to reality or attempt to freeze itself in place.”Salle 5 · L’échelle du tempsLa montagne demeure, le temps passe Note 25

Carte de lecture

Avant de commencer

La continuité signifie qu’un réseau en fonctionnement peut continuer à fonctionner même si son administrateur échoue ou doit être remplacé.

Le problème
La « stabilité » sert souvent à défendre un gardien permanent, alors que ce qu’il faut réellement préserver peut être la continuité du registre et la possibilité de continuer ailleurs.
La direction proposée
Protéger la continuité du registre tout en gardant le service remplaçable et la sortie effective.
Pourquoi cela compte maintenant
Attendre la panne visible peut revenir à attendre que les solutions de rechange, le savoir et le pouvoir de négociation aient disparu.