Résumé
- La version 02, publiée le 14 septembre, transforme plusieurs exigences chiffrées applicables aux autorités RPKI déléguées en références adaptables par les registres.
- Le seuil de disponibilité de 99,5 % et le délai de réponse de dix secondes ne sont plus absolus ; la règle sur les interruptions de manifeste et d’autres chiffres sont également assouplis.
- Le délai unique de révocation de 90 jours devient une fourchette de 60 à 90 jours, en reconnaissance des choix différents d’APNIC et de RIPE.
- Il s’agit d’un Internet-Draft individuel sans flux RFC ni approbation de l’IETF ; il ne faut pas le présenter comme une politique adoptée.
La règle change de propriétaire
La version 02 ne renonce pas à la fiabilité. Elle précise que les objectifs chiffrés et leur mise en œuvre relèvent d’une politique de l’opérateur de registre. Cette phrase donne son sens à la révision du 14 septembre.
Dans la version 01, chaque point de publication devait, avec un MUST, dépasser 99,5 % de disponibilité sur trente jours. Le nouveau texte recommande une haute disponibilité avec SHOULD, cite 99,5 % comme exemple et laisse au registre le choix de la valeur. La réponse HTTP sous dix secondes passe elle aussi de MUST à SHOULD. L’interdiction absolue d’une absence de manifeste valide supérieure à vingt-quatre heures devient une forte recommandation, avec la possibilité d’une limite régionale plus stricte.
Le différentiel officiel montre le même partage pour les traces et l’horloge. La conservation de journaux d’opérations reste obligatoire, mais deux ans deviennent une durée recommandée que le registre ou le droit applicable peut allonger. La synchronisation temporelle reste exigée ; la précision stratum 2 est désormais conseillée.
Selon RFC 2119 et RFC 8174, MUST ne laisse pas de choix, tandis que SHOULD autorise une exception dont les conséquences sont comprises. Les majuscules déplacent donc un pouvoir réel : le texte global fixe moins de nombres, l’institution locale doit davantage rendre compte de ceux qu’elle retient.
Un socle commun demeure obligatoire
Le projet continue d’exiger une infrastructure redondante avec basculement automatique, plusieurs points géographiquement dispersés, une surveillance complète, la validation avant publication et des mises à jour atomiques. Le registre doit superviser toutes les AC déléguées sous son autorité, établir des accords de niveau de service, tenter raisonnablement de joindre l’opérateur avant une révocation et publier ses procédures d’exécution.
Le travail sur les bonnes pratiques des services de publication suit déjà cette logique. Sa version 10 demande disponibilité, cohérence et surveillance sans imposer un pourcentage mondial. Un texte technique peut donc définir ce qui doit être sûr et observable, tandis que le détenteur de la délégation choisit un seuil adapté et défendable.
La preuve est distribuée. L’opérateur mesure son service ; le registre observe l’ensemble des AC qu’il délègue ; les validateurs peuvent signaler les pannes persistantes. Un projet sur la santé des dépôts propose notamment la joignabilité, la fraîcheur, l’intégrité et le taux de changement. La liste publique d’AC défaillantes et la recherche CURE montrent pourquoi une publication inutilement instable consomme les ressources de validateurs qui ne la contrôlent pas.
Une mesure n’est pourtant pas une décision. Le résultat dépend des points d’observation, de la fréquence des tests et de la capacité à découvrir puis valider un manifeste. Une infraction apparente exige encore une attribution, un avis, un examen des exceptions et une autorité identifiée.
Deux régions, deux délais légitimes
La révocation des AC durablement inopérantes illustre le mieux ce passage au niveau régional. L’ancienne version proposait plus de 90 jours après les tentatives de contact. La nouvelle retient une fourchette de 60 à 90 jours et renvoie à deux décisions publiques.
APNIC prop-166 prévoit 60 jours sans manifeste ni CRL actuels, découvrables et valides. La page d’APNIC indique que la proposition a obtenu un consensus à APNIC 60. La proposition RIPE 2025-02, marquée comme acceptée, part de trois mois et les traduit en 90 jours pour éviter les variations du calendrier. Les deux processus imposent des efforts raisonnables de détection et d’avertissement et permettent une recréation ultérieure par la voie normale.
Aucun théorème de sécurité du routage ne démontre que 60 ou 90 est le seul bon nombre. Le choix répartit le coût entre les validateurs qui interrogent un dépôt mort, l’opérateur qui a besoin de temps pour réparer et le registre qui exerce l’autorité de l’AC parente. La version 02 reconnaît ce compromis au lieu de transformer une pratique régionale en constante universelle.
La diversité reste légitime si les preuves sont comparables. Un registre devrait annoncer les points testés, les lieux de mesure, le début du décompte, les destinataires de l’avis, l’autorité qui approuve l’escalade et la voie de rétablissement. Sans cette chaîne, l’adaptation locale devient une discrétion impossible à contrôler.
Le document ne vaut pas décision de l’IETF
La fiche Datatracker classe le texte comme Internet-Draft individuel. Elle rappelle qu’un tel document peut être soumis par n’importe qui, n’est pas approuvé par l’IETF et n’a aucun statut formel. Aucun flux RFC, responsable de domaine ou téléconférence IESG ne lui est associé. La couverture vise un Best Current Practice, mais Datatracker n’enregistre actuellement aucun statut RFC prévu. L’historique atteste les dates, pas un consensus.
Cette absence de mandat rend la question visible au bon moment. Faut-il un chiffre mondial, ou des institutions tenues de choisir publiquement à partir de mesures communes ? Le projet ne définit pas encore l’instance d’appel, la norme de preuve en cas de mesure contestée ni un audit transversal entre registres.
Ses propres précautions sont institutionnelles. La surveillance détaillée peut révéler des informations sensibles. Un faux signal peut manipuler l’exécution. La révocation ne doit pas devenir un déni de service et la publication d’un incident doit ménager la vie privée. Le seuil n’est pas une simple métrique : c’est le point où une observation technique autorise une action de pouvoir.
Sources
- Fiche du projet
- Historique des versions
- Version 01
- Version 02
- Comparaison officielle
- APNIC prop-166
- Proposition RIPE 2025-02
- Projet BCP sur les services de publication
- Version 10 du BCP de publication
- Projet de surveillance des dépôts
- RFC 2119
- RFC 8174
- Observations des AC non fonctionnelles
- Recherche CURE
- Minimum Initial Specification
- The Policy Mirror
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

