Résumé

  • La fusion du 4 septembre a produit la révision 11 du projet de définition des métriques CATS, avec deux champs temporels optionnels et un véritable chapitre d’exploitation. Le texte reste un Internet-Draft de groupe de travail, pas un RFC.
  • Le choix de ne pas transmettre l’identité de la fonction dans chaque métrique a été discuté publiquement : les fonctions doivent être convenues hors ligne au démarrage afin d’éviter une négociation dynamique complexe.
  • Le nouvel accord devient un manifeste de configuration versionné et synchronisé vers les composants concernés. À l’exécution, ceux-ci doivent supposer que les scores sont entièrement comparables.
  • Observation_Time, Validity_Interval, la signature et l’autorisation ne révèlent pas si producteur et sélecteur utilisent le même manifeste après un déploiement partiel.
  • Le correctif minimal n’est pas d’envoyer l’algorithme dans chaque paquet, mais de vérifier un identifiant ou condensat commun, d’annoncer le traitement d’un écart et de conserver un reçu de décision.

Une révision qui ne se contente pas d’ajouter deux champs

Le 4 septembre, la pull request 42 a été fusionnée dans le dépôt du groupe CATS. Son commit de fusion alimente la révision 11. L’historique Datatracker confirme la date. La fiche du document le classe comme document actif du groupe, avec l’état IESG « I-D Exists ». Ce n’est ni une norme achevée ni la preuve d’un déploiement.

L’objet technique a pourtant une conséquence de gouvernance très concrète. CATS veut orienter une demande vers une instance de service en combinant l’état du réseau et celui des ressources de calcul. Les mesures brutes n’ont pas les mêmes unités. Une fonction les normalise; une autre peut les agréger en catégories de niveau 1 ou en score global de niveau 2. Le chiffre final paraît simple, mais sa signification dépend des bornes, paramètres, pondérations et du sens de comparaison choisis.

La révision 11 exige donc qu’un environnement multifournisseur s’accorde avant le déploiement sur la plage des scores, la méthode de normalisation et ses paramètres, la formule d’agrégation et ses poids, ainsi que le sens « plus élevé » ou « plus faible ». Ces résultats doivent former un manifeste de configuration, être synchronisés hors ligne pendant l’initialisation et être placés sous contrôle de version.

Le paragraphe suivant ferme volontairement la porte à une négociation continue. À l’exécution, les composants doivent supposer que les valeurs reçues ont été produites par les fonctions convenues et sont pleinement comparables. L’économie de messages et de logique est réelle. Elle déplace toutefois la question de preuve vers l’état de configuration.

Le débat d’août a éliminé une fausse piste

La pull request 41 proposait trois éléments par valeur : identité de la fonction, instant d’observation et intervalle de validité. L’idée était de permettre au sélecteur de distinguer une différence réelle de charge, une différence de calcul et une valeur périmée. Elle prévoyait aussi une identification liée aux paramètres, et pas seulement un nom vague comme « sigmoid ».

Le 25 août, un coauteur a répondu sur la liste CATS que le champ de fonction ne devait pas être répété dans chaque rapport. La cohérence entre fournisseurs devait être négociée hors bande à l’initialisation. Demander au C-PS d’interpréter un identifiant puis d’adapter dynamiquement son algorithme compliquerait inutilement le système. Les deux données temporelles pouvaient, elles, rester optionnelles.

L’auteur de la proposition a accepté cette séparation : le cadre ne prévoit pas de renégociation à chaque message, et un accord initial unique peut être plus fort qu’une réaffirmation permanente. La révision 11 contient ainsi Observation_Time et Validity_Interval, pas l’identité de la fonction. La discussion de la PR 41 précise que la PR 42 a repris les deux champs; la PR 41 restait ouverte à la date de coupure.

Il serait donc inexact d’accuser le groupe d’avoir oublié la provenance. Il a choisi un autre lieu pour la gouverner. La question restante est de savoir si ce lieu prouve sa propre cohérence.

Une valeur signée peut garder le mauvais sens

Imaginons une maintenance banale. Le sélecteur et le producteur A sont encore sous le manifeste M1. Le producteur B a reçu M2, où une borne de normalisation ou un poids a changé. A et B publient chacun un score global égal à 7. Les clés sont autorisées, les signatures valides, les observations récentes. Pourtant, les deux 7 ne désignent pas forcément le même niveau de capacité.

Ce cas est hypothétique : aucune source ne montre qu’il s’est produit. Mais il ne contredit aucune protection du projet. Le champ Source indique qu’une valeur résulte d’une normalisation ou d’une agrégation, sans identifier laquelle. Le temps d’observation situe la mesure. L’intervalle de validité indique sa durée d’usage. L’authentification prouve l’émetteur. Rien ne lie l’ensemble à M1 ou M2.

Le problème avait été signalé avant la fusion. Dans une revue de la PR 42, un participant a rappelé qu’une synchronisation hors ligne peut échouer dans un système distribué. Il proposait de détecter et signaler tout déploiement incomplet. Le texte final garde le manifeste et son versionnage, mais pas cette phrase. Un commentaire GitHub ne vaut pas consensus du groupe; il établit seulement que le mode de panne était connu.

L’évaluation OPSDIR de la révision 10 avait déjà conclu « Has issues » et demandé des règles de comparabilité multifournisseur, des identifiants de politique possibles, des procédures de calibration, des alarmes et un modèle d’exploitation. La révision 11 répond à une grande partie de cette critique. Elle recommande de limiter les annonces routinières, permet les mises à jour déclenchées par événement et décrit les replis lorsque les métriques manquent ou vieillissent.

Le dernier centimètre reste vide. Un composant sur l’ancienne version n’est pas nécessairement en panne. Un score sous M2 n’est pas nécessairement anormal vu depuis M1. Réutiliser la dernière bonne valeur peut même prolonger le décalage si le terme « bonne » n’inclut pas la lignée de configuration.

Prouver l’égalité sans publier le secret

La solution n’a pas besoin de normaliser l’algorithme mondialement. Avant d’admettre une valeur, les composants pourraient comparer un identifiant canonique et un condensat du manifeste, son domaine administratif, son périmètre de composants, son époque d’activation et l’état d’achèvement de la synchronisation. Producteur et sélecteur attesteraient chacun le condensat actif.

L’identité compacte peut voyager avec la métrique, être liée à une session authentifiée ou rester dans un plan de gestion consulté avant la décision. L’emplacement est secondaire. La propriété nécessaire est la jointure : après une orientation, l’opérateur doit pouvoir associer la valeur calculée et l’interprétation du sélecteur au même manifeste.

En cas d’écart, la politique reste locale. Rejeter le score, revenir aux catégories de niveau 1, n’utiliser que le réseau ou attendre la fin du déploiement sont des choix raisonnables selon le service. Le reçu doit enregistrer l’écart, l’action, l’alarme, l’acquittement et la condition de retour. Les pondérations sensibles peuvent demeurer confidentielles; un condensat permet de tester l’identité sans les rendre publiques.

Le cadre CATS actuel situe ces composants dans un même domaine administratif et exige des fonctions communes. Ce périmètre réduit les conflits d’autorité. Il rend surtout la preuve faisable. Le RFC 8911 fournit un précédent limité : identifier une métrique avec les paramètres fixes qui en déterminent le sens. CATS n’a pas à copier son mécanisme pour retenir sa leçon.

Sources

  1. Datatracker — définition des métriques CATS
  2. Révision 11 du projet
  3. Révision 10 du projet
  4. Historique Datatracker
  5. Revue OPSDIR de la révision 10
  6. Décision du coauteur sur l’accord hors ligne
  7. Réponse du contributeur
  8. Pull request 41
  9. Pull request 42
  10. Commit de fusion de la PR 42
  11. Cadre CATS actuel
  12. RFC 8911
  13. Heng Lu sur le minimum commun et le choix local