Spécification initiale minimale, décisions futures au niveau local et adoption volontaire pour un système de coordination de l’Internet

S’accorder sur le raccord, laisser place à des conceptions différentes. Lu Heng propose de limiter les règles communes à ce qu’exige l’interopérabilité et de laisser les choix ultérieurs aux participants eux-mêmes.

Résumé

Ce document décrit un modèle de conception pour les systèmes de coordination de l’Internet dont l’objectif est de fournir des points de référence techniques communs sans créer une autorité permanente au-dessus des participants qui font fonctionner le système. Il définit trois principes liés : la Spécification initiale minimale, les Décisions futures au niveau local et l’Adoption volontaire.

Dans ce modèle, la Spécification initiale définit uniquement les règles déterministes et vérifiables localement qui sont nécessaires à l’unicité, à l’interopérabilité, à 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. Ils sont adoptés, ignorés, repris dans une bifurcation ou abandonnés par les participants qui exécutent le code.

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 au regard des 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érabilité sélective, et non une sanction institutionnelle.

Ce document ne définit pas de protocole de transmission. Il énonce une meilleure pratique actuelle pour la conception de protocoles, de registres, de systèmes d’identifiants et de mécanismes de coordination qui ne doivent pas devenir des institutions permanentes de gouvernance.

1. Introduction

De nombreux systèmes de l’Internet commencent avec un objectif technique étroit : permettre à des acteurs indépendants d’interopérer en partageant un point de référence, un espace d’identifiants, une règle de validation ou un enregistrement de type registre. 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 intégrées à la couche fondatrice avant qu’elles ne soient techniquement nécessaires.

Deuxièmement, des choix qui devraient appartenir 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 les systèmes en fonctionnement.

Il en résulte un système fragile. Une couche de référence technique devient une couche de gouvernance. Le teneur de registre devient celui qui contrôle l’accès. Un artefact de coordination devient une source de contrôle sur l’avenir.

Ce document propose une autre discipline de conception :

– Spécification initiale minimale : spécifier uniquement les règles communes déterministes nécessaires à l’interopérabilité de base, à l’unicité, à la sûreté commune et à la sécurité.
– Décisions futures au niveau local : 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 à appliquer des règles mutuellement compatibles.
– Adoption volontaire : donner une réalité aux changements ultérieurs uniquement par leur mise en œuvre, leur exploitation, leur validation et leur 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 inscrit d’avance le contrôle futur dans la couche commune. Un système qui maintient 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 une 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. Un participant peut adopter un changement ultérieur, le refuser, bifurquer, se déconnecter ou interopérer de manière sélective. Il peut, tout au plus, se retirer d’un ensemble de compatibilité. En refusant un changement, il ne peut pas rompre l’interopérabilité des autres participants qui continuent à exécuter du code mutuellement compatible.

C’est la même leçon générale que l’on peut observer dans des systèmes tels que Bitcoin : les règles de consensus sont appliquées par ceux qui exécutent le code de validation, et non par une institution placée au-dessus d’eux.

2. Champ d’application

Ce document s’applique aux systèmes de coordination de l’Internet, notamment, sans s’y limiter, aux registres partagés, aux systèmes d’identifiants, aux cadres de nommage et de numérotation, aux mécanismes d’extension de protocole, aux systèmes de preuve de contrôle, aux systèmes de portabilité 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 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 ni chaîne de blocs, ni registre distribué, ni technologie particulière. Il exige une propriété de conception : les participants devraient pouvoir déterminer la validité en appliquant localement la Spécification initiale, sans demander une permission ou un statut à une autorité permanente.

3. Conventions et définitions

3.1. Terminologie des exigences

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

3.2. Terminologie

Spécification initiale :
L’ensemble des règles, structures de données, formats, invariants, procédures de validation et règles de transition nécessaires au 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écessaires à l’interopérabilité de participants indépendants. La couche commune n’est pas une institution. Elle est la substance technique que les participants mettent en œuvre et vérifient.

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 au regard d’un ensemble de règles spécifié.

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

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

Ensemble de compatibilité :
Un groupe de participants dont les règles de validation mises en œuvre 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 :
La mise en œuvre, le déploiement, la validation et l’utilisation effectifs par les participants qui font fonctionner le système.

Non-adoption :
Le choix d’un participant de ne pas mettre en œuvre ou utiliser un changement proposé. La non-adoption ne confère pas un 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 cet élément, parce qu’il est invalide ou incompatible au regard des règles de validation qu’il applique.

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

Artefact de coordination :
Un document, une entrée de registre, une recommandation, une note de mise en œuvre, un profil, une implémentation de référence ou tout autre artefact qui aide les participants à se coordonner. Un artefact de coordination ne crée pas de réalité opérationnelle contraignante tant que les participants ne l’adoptent pas 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 le soin d’interpréter les questions futures. Cela paraît prudent. C’est souvent dangereux.

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

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

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

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

Le même problème se présente 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 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 est d’éviter d’avoir besoin de ce pouvoir discrétionnaire.

Un système de coordination de l’Internet bien conçu devrait définir dès le départ des règles de validité déterministes et vérifiables localement ; laisser les choix qui ne concernent pas les invariants hors de la couche commune ; et permettre aux changements ultérieurs de devenir réels uniquement lorsque les participants les adoptent volontairement dans des systèmes en fonctionnement.

5. Principe 1 : Spécification initiale minimale

5.1. Énoncé

Une Spécification initiale DEVRAIT définir uniquement le minimum de règles communes déterministes nécessaires à l’interopérabilité de base, à l’unicité, à la sûreté commune et à la sécurité.

5.2. Exigences

Une conception qui applique ce principe :

1. DOIT identifier explicitement ses Invariants globaux.
2. DOIT définir des règles de validation déterministes pour chaque Invariant global.
3. 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 global énoncé ou pour permettre le premier déploiement.
4. DOIT séparer les règles de validation des préférences en matière de politiques, des arrangements commerciaux, des rôles institutionnels, des aspirations de gouvernance et du jugement discrétionnaire.
5. DOIT permettre aux participants de vérifier localement la validité ordinaire sans interroger une institution, un registre, un comité, un organisme chargé des politiques ou toute autre autorité.
6. 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.
7. 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.
8. DOIT garantir que les artefacts de coordination requis sont portables, auditables, reproductibles et remplaçables.
9. DEVRAIT préférer des conditions objectives vérifiables par machine à un jugement subjectif sur le mérite.
10. 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 les seuls éléments qui doivent être communs.

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

– ce qui doit être commun pour assurer l’unicité, l’interopérabilité, la sûreté commune et la sécurité ; et
– ce qui peut rester hors de la couche commune parce que cela relève des préférences de l’opérateur, des pratiques commerciales, du calendrier de déploiement ou d’un choix d’adoption ultérieur.

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

6. Principe 2 : Décisions futures au niveau local

6.1. Énoncé

Après la Spécification initiale, les Décisions futures DEVRAIENT rester au niveau local, 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 confère pas un statut d’invalidité.

6.2. Exigences

Une conception qui applique ce principe :

1. NE DOIT PAS exiger des participants qu’ils obtiennent la permission d’une institution en place, d’un registre, d’un comité, d’un conseil d’administration, d’un organisme chargé des politiques ou de toute 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 serait la seule voie par laquelle un changement ultérieur peut acquérir une réalité opérationnelle.
3. DOIT distinguer la validité au regard de la Spécification initiale de la compatibilité avec un changement facultatif ultérieur.
4. NE DOIT PAS traiter la non-adoption d’un changement ultérieur comme une invalidité.
5. DOIT permettre aux participants de rester dans un ensemble de compatibilité existant lorsqu’ils n’adoptent pas un changement ultérieur.
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 des états, enregistrements, transitions ou messages invalides ou incompatibles au regard des règles de validation qu’ils appliquent.
8. NE DOIT PAS autoriser une institution, un registre, un comité, un organisme chargé des politiques ou tout autre acteur à déclarer un participant invalide au seul motif qu’il a refusé un changement ultérieur.
9. DEVRAIT rendre explicites les bifurcations, versions, profils ou ensembles de compatibilité, afin que les participants sachent quelles règles ils appliquent et avec quels autres participants ils peuvent interopérer.
10. 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écisions futures au niveau local ne signifie pas qu’une autorité centrale attribue les décisions futures à 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’aient pas besoin d’une telle attribution.

La Spécification initiale accomplit à l’avance le travail de délimitation. Elle définit les invariants minimaux nécessaires à l’unicité, à l’interopérabilité, à 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 de manière centrale. Ils sont adoptés, ignorés, repris dans une bifurcation ou abandonnés par les participants qui exécutent le code.

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é plus ancien. 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 à appliquer des règles mutuellement compatibles.

Un état invalide ou incompatible entraîne un rejet local, et non une sanction. Personne n’a besoin de décider qu’un participant n’est pas en règle. Un participant qui applique 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 apportés à un système de coordination de l’Internet DEVRAIENT acquérir une réalité opérationnelle par leur mise en œuvre, leur validation, leur déploiement et leur adoption par les participants, et non par la seule publication ou déclaration.

7.2. Exigences

Une conception qui applique ce principe :

1. NE DOIT PAS traiter la publication, l’enregistrement, la recommandation, l’approbation en réunion ou l’approbation procédurale comme suffisants pour créer une obligation opérationnelle universelle.
2. DOIT permettre le déploiement progressif de nouvelles règles, extensions, profils ou procédures par les participants qui choisissent de les appliquer.
3. DOIT permettre aux participants de refuser un changement ultérieur sans acquérir un 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 ensemble de compatibilité plus ancien lorsque la Spécification initiale autorise cette continuité.
5. DOIT permettre aux participants qui appliquent les règles d’un ensemble de compatibilité de rejeter ou d’ignorer localement les états provenant d’un autre ensemble de compatibilité lorsque les règles sont incompatibles.
6. DEVRAIT définir des voies d’adoption pour les changements majeurs, notamment la signalisation des versions, l’étiquetage de compatibilité, les indications de transition et les vecteurs de test.
7. DEVRAIT définir des voies de refus pour les changements majeurs, notamment la manière dont les participants qui ne les adoptent pas poursuivent leur fonctionnement, identifient leur ensemble de compatibilité et évitent les situations d’interopérabilité ambiguës.
8. DOIT garantir qu’il est possible de quitter, de porter, de mettre en miroir, de réimplémenter ou de remplacer les artefacts de coordination requis sans coût de transition prohibitif.
9. DEVRAIT faire en sorte que les registres, enregistrements, recommandations et artefacts de coordination décrivent la réalité adoptée plutôt que de décréter l’existence d’une réalité future non adoptée.
10. DOIT éviter de concevoir un système dans lequel la seule façon pour un changement de devenir réel est sa reconnaissance préalable par un organisme en place.

7.3. Conséquences pour la conception

L’Adoption volontaire est le test opérationnel qui permet de savoir si un changement 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é. Une mise à jour de registre 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 le changement, le valident, le déploient et s’appuient sur lui.

La non-adoption ne crée aucun statut d’infraction. Elle ne crée qu’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 les registres, ni la documentation, 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’appliquent 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.

Les Décisions futures au niveau local garantissent que les choix futurs restent entre les mains des participants qui exécutent le code, au lieu d’être repris par une couche centrale d’approbation.

L’Adoption volontaire garantit que les changements ultérieurs doivent résister à l’épreuve de la mise en œuvre et de 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écisions futures au niveau local peut encore permettre à l’autorité de s’accumuler après le déploiement.
– Des Décisions futures au niveau local sans Spécification initiale minimale peuvent produire de l’ambiguïté, parce que les participants ne peuvent pas déterminer localement la validité.
– Une 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.
– Une validation déterministe sans possibilité de sortie, de portabilité ou de remplacement peut encore produire une dépendance captive si les artefacts de tenue des registres deviennent impossibles à quitter.

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 et aucune institution permanente n’est nécessaire pour décider du fonctionnement ordinaire.

9. Modèle de conception recommandé

9.1. Couche commune déterministe

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é ;
– les exigences d’interopérabilité au niveau des échanges sur le réseau ou du protocole ;
– des invariants de sécurité communs ;
– des mécanismes de preuve de contrôle, lorsque cela est nécessaire ;
– des formats d’enregistrement portables et auditables, lorsque des enregistrements sont nécessaires ;
– 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 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. Périmètre de décision de l’opérateur

Les éléments suivants DEVRAIENT rester hors de la couche commune, sauf s’ils modifient directement un Invariant global énoncé :

– le calendrier de déploiement ;
– l’usage commercial ;
– la localisation géographique des clients ;
– les arrangements 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 qui ne sont pas nécessaires à la validité commune ;
– le modèle économique ;
– la structure organisationnelle ;
– le calendrier de migration volontaire ;
– les profils ou extensions facultatifs.

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’appairage 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 possible, l’ordre préférable pour un changement substantiel du système est le suivant :

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 plutôt que tenter de la devancer.

9.4. Sortie, bifurcation et portabilité

Une conception conforme DEVRAIT traiter la sortie, la bifurcation et la portabilité 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é plus ancien ;
– adopter un ensemble de compatibilité plus récent ;
– bifurquer vers un ensemble de compatibilité différent ;
– porter des enregistrements, des identifiants, des preuves ou un état opérationnel ;
– vérifier la validité des enregistrements sans dépendre d’un teneur de registre en place ;
– interopérer de manière sélective lorsque la compatibilité le permet.

Un système que l’on ne peut quitter ou faire bifurquer sans détruire son fonctionnement 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 fait intervenir plusieurs acteurs et relève de plusieurs juridictions ;
– le déploiement indépendant est important ;
– la couche de coordination est destinée à rester mince ;
– des variations futures sont probables, mais ne peuvent pas être prévues en détail ;
– une dépendance captive créerait un risque de gouvernance ;
– la validité peut être rendue déterministe ou vérifiable localement.

Il peut être moins directement applicable lorsque :

– l’architecture prévue repose sur un seul domaine administratif ;
– un couplage étroit en temps réel exige un comportement uniforme à tout instant ;
– des enjeux de sécurité des personnes exigent une uniformité globale immédiate ;
– aucun mécanisme praticable ne permet de vérifier la validité localement.

Même dans ces cas, les concepteurs DEVRAIENT néanmoins réduire au minimum la couche commune et éviter, chaque fois que possible, tout contrôle discrétionnaire sur l’avenir.

11. Ce que ce document ne vise pas

Ce document :

– n’interdit pas toute coordination ;
– n’interdit pas tous les registres partagés ;
– n’exige pas de technologie de chaîne de blocs ou 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 prétendrait néanmoins être compatible ;
– 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 capture, limiter l’étendue des dommages causés par une erreur institutionnelle et faciliter le remplacement. Toutefois, une latitude locale accrue peut aussi créer des postures de sécurité incohérentes, des voies de rétrogradation, des pressions à la fragmentation, des revendications de compatibilité ambiguës et des bifurcations dangereuses.

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é commune DOIVENT être déterministes et vérifiables localement ;
– 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 faire l’objet d’une analyse des risques d’abus et de déni de service ;
– les étiquettes de compatibilité DEVRAIENT être suffisamment claires pour empêcher une interopérabilité accidentelle entre des ensembles de règles incompatibles ;
– 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 de sécurité ne justifie pas une couche générale de permissions. Elle justifie uniquement 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 demande aucune action à 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 protocole, RFC 6709.
– RFC 7282 — Resnick, P., Du consensus et des bourdonnements à 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 :

1. Quels sont les Invariants globaux ?
2. Quelles règles de validation déterministes préservent ces Invariants globaux ?
3. Quelles règles de la Spécification initiale sont strictement nécessaires au premier déploiement ?
4. Quelles questions futures sont intentionnellement laissées hors de la couche commune ?
5. Quels choix futurs les participants peuvent-ils faire sans modifier l’ensemble de compatibilité auquel ils appartiennent ?
6. Comment un participant adopte-t-il un changement ultérieur ?
7. Comment un participant refuse-t-il un changement ultérieur sans se voir attribuer un statut d’invalidité ?
8. Comment les ensembles de compatibilité sont-ils étiquetés ou découverts ?
9. Comment fonctionne le rejet local lorsqu’un état est invalide ou incompatible au regard des règles qu’un participant applique ?
10. Quelle est la voie de bifurcation ?
11. Quelle est la voie de portabilité ?
12. Quelle est la voie de sortie de tout artefact de coordination requis ?
13. Les participants peuvent-ils vérifier la validité ordinaire sans dépendre d’un teneur de registre en place ?
14. Les enregistrements et les artefacts de coordination décrivent-ils la réalité adoptée, ou tentent-ils de décréter l’existence d’une réalité future non adoptée ?
15. Le système a-t-il réduit au minimum le nombre de décisions inscrites dans la couche commune ?
16. Le système a-t-il évité toute autorité permanente qui détermine le statut ordinaire des participants ?

Adresse de l’auteur

H. Lu