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

Écrit par Lu Heng

|

18 avril 2026

PDG de LARUS Limited et fondateur de la Fondation LARUS. Il travaille à l'intersection de l'infrastructure Internet, des marchés d'adresses IP et de la gouvernance mondiale de l'Internet, en s'appuyant sur l'implication directe des cinq registres Internet régionaux. Ces notes visent à clarifier la manière dont les ressources numériques sont régies dans la pratique et à promouvoir un cadre plus responsable et plus résilient pour les actifs critiques IP.

Abstrait

Ce document décrit un modèle de conception pour les systèmes de coordination Internet dont le but est de fournir des points de référence techniques partagés sans créer une autorité continue au-dessus des participants qui gèrent le système. Il définit trois principes liés : la spécification initiale minimale, la décision future localisée et l'adoption volontaire.

Selon ce modèle, la spécification initiale définit uniquement les règles déterministes et vérifiables localement requises pour l'unicité, l'interopérabilité, la sûreté partagée et la sécurité. Après la spécification initiale, les modifications futures ne sont pas approuvées par un organisme central. Ils sont adoptés, ignorés, dupliqués ou abandonnés par les participants exécutant le code.

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

Ce document ne définit pas de protocole filaire. Il spécifie une meilleure pratique actuelle pour la conception de protocoles, de registres, de systèmes d'identification et de mécanismes de coordination qui ne doivent pas devenir des institutions de gouvernance permanentes.

1. Introduction

De nombreux systèmes Internet ont au départ un objectif technique étroit : permettre à des acteurs indépendants d’interagir en partageant un point de référence commun, un espace d’identification, une règle de validation ou un enregistrement de type registre. Au fil du temps, ces systèmes accumulent souvent une autorité qui n’était pas requise pour l’interopérabilité initiale.

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

Premièrement, les questions futures sont placées dans la couche fondatrice avant qu’elles ne soient techniquement nécessaires.

Deuxièmement, les choix qui devraient être faits par les participants qui gèrent leurs propres systèmes deviennent dépendants de la reconnaissance, de l'interprétation ou des décisions 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 cours.

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

Ce document propose une discipline de conception différente :

- Spécification initiale minimale :spécifier uniquement les règles communes déterministes requises pour l’interopérabilité de base, l’unicité, la sûreté partagée et la sécurité.
- Décision future localisée :après la spécification initiale, conservez les choix futurs avec les participants exécutant le code. Un participant peut adopter, refuser, bifurquer, se déconnecter ou interagir de manière sélective. Aucun participant ne peut modifier l'interopérabilité des autres participants qui continuent d'appliquer des règles mutuellement compatibles.
- Adoption volontaire :rendre les changements ultérieurs réels uniquement grâce à la mise en œuvre, à l'exploitation, à la validation et à l'adoption par les participants exécutant le code.

Ces principes sont liés. Un système qui spécifie trop de choses au début précharge le contrôle futur dans la couche commune. Un système qui laisse une couche de reconnaissance continue permet à l'autorité de réapparaître après le déploiement. Un système qui considère la publication comme une réalité convertit la documentation en commande.

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 une modification ultérieure, la refuser, la bifurquer, se déconnecter ou interagir de manière sélective. Il peut tout au plus se retirer d'un ensemble de compatibilité. Il ne peut pas, en refusant un changement, rompre l'interopérabilité des autres participants qui continuent d'exécuter du code mutuellement compatible.

C’est la même leçon générale visible 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. Portée

Ce document s'applique aux systèmes de coordination Internet, y compris, mais sans s'y limiter, les registres partagés, les systèmes d'identification, les cadres de dénomination et de numérotation, les mécanismes d'extension de protocole, les systèmes de preuve de contrôle, les systèmes de portabilité et 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 ne nécessite pas de blockchain, de registre distribué ou toute technologie spécifique. Cela nécessite une propriété de conception : les participants doivent être capables de déterminer la validité en appliquant la spécification initiale localement, sans demander l'autorisation ou le statut d'une autorité permanente.

3. Conventions et définitions

3.1. Langue des exigences

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

3.2. Terminologie

Spécification initiale :
L'ensemble des règles, des structures de données, des formats, des invariants, des procédures de validation et des règles de transition requis pour le premier déploiement d'un système.

Couche commune :
L’ensemble minimum de règles partagées ou la structure de référence requise pour que les participants indépendants interagissent. La couche commune n’est pas une institution. C'est la substance technique que les participants mettent en œuvre et vérifient.

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

Invariant global :
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é partagée ou la sécurité.

Participant:
Opérateur, implémentation, nœud, réseau, organisation ou autre acteur qui exécute, vérifie, déploie ou s'appuie sur le système.

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

Adoption:
Mise en œuvre, déploiement, validation et utilisation réelles par les participants exécutant 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 crée pas un statut invalide. Cela signifie simplement que le participant n'a pas rejoint l'ensemble de compatibilité créé par cette modification.

Rejet local :
Décision locale d'un participant d'ignorer, de rejeter ou de ne pas interagir avec un état, un message, un enregistrement ou une transition qui est invalide ou incompatible selon les règles de validation qu'il exécute.

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

Artefact de coordination :
Un document, une entrée de registre, une recommandation, une note de mise en œuvre, un profil, une mise en œuvre 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 à moins que les participants ne l’adoptent dans les systèmes en cours d’exécution.

4. Énoncé du problème

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

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

Premièrement, cela déplace les choix futurs vers une couche commune où le changement est plus difficile et où la capture a plus d’effet.

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

Troisièmement, cela encourage un organisme qui tient des registres, publie des documents ou convoque des participants à considérer 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 nécessite qu'un organisme permanent approuve le changement, détermine le statut ou interprète le fonctionnement ordinaire, le système a créé une couche de contrôle post-fondation. Cette couche peut commencer par l’administration. Cela peut devenir une gouvernance. Cela peut alors devenir un point d’étranglement.

L’objectif de conception de ce document n’est pas une meilleure discrétion institutionnelle. L’objectif de la conception est d’éviter le besoin de cette discrétion.

Un système de coordination Internet bien conçu devrait définir dès le départ des règles de validité déterministes et vérifiables localement ; devrait laisser les choix non invariants en dehors de la couche commune ; et devrait permettre aux changements ultérieurs de devenir réels uniquement lorsque les participants les adoptent volontairement dans les systèmes en cours d'exécution.

5. Principe 1 : Spécification initiale minimale

5.1. Déclaration

Une spécification initiale SHOULD définit uniquement les règles communes déterministes minimales requises pour l'interopérabilité de base, l'unicité, la sûreté partagée et la sécurité.

5.2. Exigences

Une conception utilisant ce principe :

1. MUST identifie explicitement ses invariants globaux.
2. MUST définit des règles de validation déterministes pour chaque invariant global.
3. MUST NOT place une règle dans la spécification initiale, sauf si la règle est requise pour préserver un invariant global déclaré ou pour permettre le premier déploiement.
4. MUST sépare les règles de validation des préférences politiques, des accords commerciaux, des rôles institutionnels, des aspirations en matière de gouvernance et du jugement discrétionnaire.
5. MUST permet aux participants de vérifier la validité ordinaire localement sans demander conseil à aucune institution, registre, comité, organe politique ou autre autorité.
6. SHOULD définit les structures de données, les signatures, les preuves, les règles de transition d'état, les règles de conflit ou d'autres mécanismes nécessaires à la vérification locale.
7. SHOULD définit la signalisation d'extension, la gestion des versions, l'étiquetage de compatibilité ou l'identification des forks là où des variations futures sont prévisibles.
8. MUST garantit que les artefacts de coordination requis sont portables, vérifiables, reproductibles et remplaçables.
9. SHOULD préfère les conditions objectives vérifiables par machine au jugement subjectif du mérite.
10. MUST NOT fait de la future reconnaissance institutionnelle la seule voie par laquelle un état valide peut être connu, enregistré ou utilisé.

5.3. Implications en matière de conception

Spécification initiale minimale ne signifie pas spécification vague. Cela signifie une spécification stricte de ce qui doit être commun uniquement.

Un système a encore besoin de suffisamment de structure commune pour fonctionner. La discipline consiste à distinguer :

- ce qui doit être commun pour l'unicité, l'interopérabilité, la sûreté et la sécurité partagées ; et
- ce qui peut rester en dehors de la couche commune car cela concerne la préférence de l'opérateur, la pratique commerciale, le calendrier de déploiement ou le choix d'une adoption ultérieure.

Une conception qui ne peut pas énoncer clairement ses invariants globaux et ses règles de validation déterministes devrait supposer qu'elle a spécifié trop de discrétion et trop peu de substance vérifiable.

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

6.1. Déclaration

Après la spécification initiale, les décisions futures SHOULD restent locales pour les participants exécutant le code. Une décision future ne devient effective que pour l'ensemble de compatibilité dont les participants l'adoptent. Aucune autorité continue n'est requise pour l'approuver, et la non-adoption ne crée pas un statut invalide.

6.2. Exigences

Une conception utilisant ce principe :

1. MUST NOT exige que les participants obtiennent l'autorisation d'une institution, d'un registre, d'un comité, d'un conseil d'administration, d'un organe politique ou d'une autre autorité en place pour les choix qui ne modifient pas les règles de validation déterministes de l'ensemble de compatibilité auquel ils participent.
2. MUST NOT crée un corps permanent dont la reconnaissance est la seule voie par laquelle un changement ultérieur peut devenir opérationnel réel.
3. MUST distingue la validité selon la spécification initiale de la compatibilité avec une modification facultative ultérieure.
4. MUST NOT traite la non-adoption d'une modification ultérieure comme une invalidité.
5. MUST permet aux participants de rester dans un ensemble de compatibilité existant lorsqu'ils n'adoptent pas de modification ultérieure.
6. MUST permet aux participants de rejoindre un nouvel ensemble de compatibilité en adoptant de nouvelles règles de validation ou profils opérationnels.
7. MUST permet aux participants de rejeter localement des états, des enregistrements, des transitions ou des messages non valides ou incompatibles selon les règles de validation qu'ils exécutent.
8. MUST NOT autorise toute institution, registre, comité, organisme politique ou autre acteur à déclarer un participant invalide simplement parce qu'il a refusé un changement ultérieur.
9. SHOULD rend explicites les forks, les versions, les profils ou les ensembles de compatibilité afin que les participants sachent quelles règles ils exécutent et avec quels autres participants ils peuvent interagir.
10. SHOULD évite toute conception dans laquelle un archiviste en place peut empêcher des participants autrement valides de continuer à interagir.

6.3. Implications en matière de conception

La décision future localisée ne signifie pas qu’une autorité centrale attribue les décisions futures aux 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 ne nécessitent pas une telle allocation.

La spécification initiale effectue le travail limitatif à l'avance. Il définit les invariants minimaux requis pour l'unicité, l'interopérabilité, la sûreté partagée et la sécurité. Tout le reste reste en dehors de la couche commune.

Les changements futurs ne sont pas approuvés de manière centralisée. Il est adopté, ignoré, dupliqué ou abandonné par les participants exécutant le code.

Un participant qui refuse un changement peut rester en dehors de l'ensemble de compatibilité créé par ce changement. Il peut se déconnecter des autres. Cela peut continuer dans un ensemble de compatibilité plus ancien. Cela peut bifurquer. Il peut interagir de manière sélective. Mais cela ne peut pas briser l’interopérabilité des autres participants qui continuent d’appliquer des règles mutuellement compatibles.

L’effet d’un état invalide ou incompatible est un rejet local et non une punition. Personne n’a besoin de décider qu’un participant est en mauvaise posture. Un participant exécutant des règles de validation compatibles n'accepte tout simplement pas l'état invalide ou incompatible.

7. Principe 3 : Adoption volontaire

7.1. Déclaration

Les changements dans un système de coordination Internet SHOULD deviennent opérationnels grâce à la mise en œuvre, la validation, le déploiement et l'adoption par les participants, et non par la seule publication ou déclaration.

7.2. Exigences

Une conception utilisant ce principe :

1. MUST NOT considère la publication, l'enregistrement, la recommandation, l'approbation de réunion ou l'approbation de procédure comme suffisantes pour créer une obligation opérationnelle universelle.
2. MUST permet de déployer progressivement de nouvelles règles, extensions, profils ou procédures par les participants qui choisissent de les exécuter.
3. MUST permet aux participants de refuser une modification ultérieure sans acquérir un statut invalide, à condition que leurs propres transitions d'état satisfassent aux règles de validation déterministes de leur ensemble de compatibilité.
4. MUST permet aux participants de continuer à utiliser un ensemble de compatibilité plus ancien lorsque la spécification initiale autorise une telle continuité.
5. MUST permet aux participants exécutant un ensemble de compatibilité de rejeter ou d'ignorer localement l'état d'un autre ensemble de compatibilité dont les règles sont incompatibles.
6. SHOULD définit les chemins d'adoption pour les changements majeurs, y compris la signalisation des versions, l'étiquetage de compatibilité, les conseils de transition et les vecteurs de test.
7. SHOULD définit les chemins de refus pour les changements majeurs, y compris la manière dont les participants non adoptants continuent leurs opérations, identifient leur ensemble de compatibilité et évitent les interopérations ambiguës.
8. MUST garantit que les artefacts de coordination requis peuvent être supprimés, portés, mis en miroir, réimplémentés ou remplacés sans coût de transition impossible.
9. SHOULD a des registres, des enregistrements, des recommandations et des artefacts de coordination qui décrivent la réalité adoptée plutôt que de déclarer l'existence d'une réalité future non adoptée.
10. MUST évitez de concevoir un système dans lequel le seul moyen pour qu'un changement devienne réel est la reconnaissance préalable par un organisme en place.

7.3. Implications en matière de conception

L'adoption volontaire est le test opérationnel permettant de déterminer 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 du registre n'est pas une réalité. Un document n'est pas la réalité. La réalité apparaît lorsque les participants mettent en œuvre, valident, déploient et s'appuient sur le changement.

La non-adoption ne crée aucun statut de violation. Cela crée seulement un fait : le participant n'a pas rejoint l'ensemble de compatibilité créé par le changement.

Cela n’élimine pas les processus de normalisation, les registres, la documentation ou la révision. Cela limite leurs prétentions. Ils peuvent aider les participants à se coordonner. Ils peuvent publier du matériel de référence. Ils peuvent décrire l’adoption. Ils peuvent recommander. Ils ne peuvent pas, par la seule déclaration, rendre une réalité future non adoptée contraignante pour les participants qui ne la dirigent pas.

8. Relation entre les trois principes

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

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

La décision future localisée garantit que les choix futurs restent entre les mains des participants exécutant le code plutôt que d'être récupérés par une couche d'approbation centrale.

L'adoption volontaire garantit que les changements ultérieurs doivent survivre au contact avec la mise en œuvre et l'utilisation.

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

- La spécification initiale minimale sans décision future localisée peut toujours permettre à l'autorité de s'accumuler après le déploiement.
- Une décision future localisée sans spécification initiale minimale peut produire une ambiguïté, car les participants ne peuvent pas déterminer localement la validité.
- L'adoption volontaire sans validation déterministe peut produire de la confusion, car les participants ne peuvent pas distinguer une variation compatible d'un état invalide.
- Une validation déterministe sans sortie, portabilité ou remplaçabilité peut toujours produire un verrouillage si les artefacts de tenue de 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 SHOULD doit être limitée à :

- sémantique d'identifiant stable ;
- 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 du fil ou du protocole ;
- des invariants de sécurité partagés ;
- des mécanismes de preuve de contrôle, si nécessaire ;
- formats d'enregistrement portables et vérifiables, lorsque des enregistrements sont nécessaires ;
- signalisation d'extension et identification de l'ensemble de compatibilité.

La couche commune SHOULD NOT contient :

- les règles du modèle économique ;
- les règles de tarification ;
- les préférences politiques régionales ;
- une idéologie d'éligibilité sans rapport avec les invariants techniques ;
- des pouvoirs discrétionnaires d'exécution ;
- évaluations subjectives du mérite ;
- l'expansion de la mission institutionnelle ;
- toute règle dont la fonction première est de préserver l'autorité d'un organe en place.

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

Les SHOULD suivants restent en dehors de la couche commune à moins qu'ils ne modifient directement un invariant global déclaré :

- le calendrier de déploiement ;
- utilisation commerciale ;
- géographie des clients ;
- les modalités de location, de financement ou de transfert ;
- préférence d'éligibilité locale ;
- le séquencement opérationnel ;
- pratique de routage non requise pour la validité partagée ;
- modèle économique ;
- la structure organisationnelle ;
- le moment de la migration volontaire ;
- profils ou extensions optionnels.

Les participants MAY adoptent des choix différents dans ces domaines. Ces choix peuvent produire différents ensembles de compatibilité, relations commerciales, accords de peering ou communautés opérationnelles. Ils ne créent pas d'invalidité à moins qu'ils ne violent les règles de validation déterministes dans un ensemble de compatibilité.

9.3. Boucle d'adoption

Lorsque cela est possible, l’ordre préféré pour le changement du système matériel est :

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

Un artefact de coordination SHOULD suit l'adoption plutôt que de tenter de la préempter.

9.4. Sortie, fourche et portabilité

Une conception conforme SHOULD traite la sortie, la fourche et la portabilité comme des exigences de conception normales plutôt que comme des défaillances.

Le système SHOULD définit 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 ;
- les enregistrements portuaires, les identifiants, les preuves ou l'état opérationnel ;
- vérifier la validité des dossiers sans faire appel à un archiviste titulaire ;
- interopérer de manière sélective là où la compatibilité le permet.

Un système dont on ne peut pas sortir ou bifurquer sans détruire le fonctionnement valide a probablement un pouvoir de gouvernance caché dans sa fonction de tenue de registres.

10. Applicabilité et limites

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

- le système est multi-acteurs et multi-juridictionnel ;
- les questions de déploiement indépendant ;
- la couche de coordination a vocation à rester fine ;
- une variation future est probable mais ne peut être prédite en détail ;
- le verrouillage créerait un risque de gouvernance ;
- la validité peut être rendue déterministe ou vérifiable localement.

Elle peut être moins directement applicable lorsque :

- un domaine administratif unique constitue l'architecture envisagée ;
- un couplage temps réel fort nécessite un comportement uniforme à tout moment ;
- les préoccupations concernant la sécurité des personnes nécessitent une uniformité mondiale immédiate ;
- la validité ne peut être vérifiée localement par aucun mécanisme pratique.

Même dans de tels cas, les concepteurs SHOULD minimisent toujours la couche commune et évitent autant que possible tout contrôle discrétionnaire futur.

11. Non-objectifs

Ce document ne :

- interdire toute coordination ;
- interdire tous les registres partagés ;
- nécessitent une technologie blockchain ou de registre distribué ;
- garantir le consensus ;
- garantir la neutralité politique ;
- exiger de tous les participants qu'ils adoptent tout changement ultérieur ;
- considérer le refus d'adopter comme une invalidité ;
- légitimer des comportements locaux incompatibles tout en revendiquant la compatibilité ;
- éliminer le besoin de règles communes critiques pour la sécurité.

12. Considérations de sécurité

Une couche de coordination plus fine peut réduire le risque de capture, réduire le rayon d’explosion des erreurs institutionnelles et améliorer la remplaçabilité. Cependant, une discrétion locale accrue peut également créer une posture de sécurité incohérente, des chemins de rétrogradation, une pression de fragmentation, des déclarations de compatibilité ambiguës et des forks dangereux.

Les concepteurs appliquant ce document MUST spécifient donc explicitement les invariants de sécurité. En particulier:

- les exigences d'authentification et d'autorisation requises pour la validité partagée MUST soient déterministes et vérifiables localement ;
- la négociation de version et la gestion des extensions MUST évitent les rétrogradations silencieuses lorsque la sécurité est affectée ;
- les chemins de refus, de fork et de remplacement MUST doivent être analysés pour détecter les risques d'abus et de déni de service ;
- les étiquettes de compatibilité SHOULD doivent être suffisamment claires pour empêcher une interopération accidentelle entre des ensembles de règles incompatibles ;
- La variante locale MUST NOT peut prétendre à tort qu'elle est compatible avec un ensemble de règles qu'elle ne satisfait pas.

L’existence d’exceptions de sécurité ne justifie pas une couche d’autorisation générale. Il justifie uniquement les règles de sécurité déterministes nécessaires pour préserver les invariants globaux énoncés.

13. Considérations relatives au IANA

Ce document ne comporte aucune action IANA.

14. Références

14.1. Références normatives

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

14.2. Références informatives

- RFC 6709 — Charpentier, B. et B. Aboba, Considérations de conception pour les extensions de protocole, RFC 6709.
- RFC 7282 — Resnick, P., Sur le consensus et le bourdonnement dans le IETF, RFC 7282.

Annexe A. Liste de contrôle de conception

Une conception qui revendique la conformité à ce document SHOULD peut 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 en dehors de la couche commune ?
5. Quels choix futurs les participants peuvent-ils faire sans modifier l’ensemble de compatibilité dans lequel ils se trouvent ?
6. Comment un participant adopte-t-il un changement ultérieur ?
7. Comment un participant peut-il refuser une modification ultérieure sans se voir attribuer un statut invalide ?
8. Comment les ensembles de compatibilité sont-ils étiquetés ou découverts ?
9. Comment fonctionne le rejet local lorsque l'état est invalide ou incompatible selon les règles appliquées par un participant ?
10. Quel est le chemin de la fourche ?
11. Quelle est la voie de la portabilité ?
12. Quel est le chemin de sortie de tout artefact de coordination requis ?
13. Les participants peuvent-ils vérifier la validité ordinaire sans faire appel à un archiviste titulaire ?
14. Les enregistrements et les artefacts de coordination décrivent-ils la réalité adoptée, ou tentent-ils de déclarer l’existence d’une réalité future non adoptée ?
15. Le système a-t-il minimisé le nombre de décisions intégrées dans la couche commune ?
16. Le système a-t-il évité toute autorité continue qui détermine le statut de participant ordinaire ?

## Adresse de l'auteur

H. Lu
[TBD]