Résumé

  • RFC 9519 fait passer de nombreux intervalles des registres SSH de l’IETF Review à l’Expert Review, sans modifier les espaces soumis à Standards Action ni ceux réservés à l’usage privé.
  • L’attribution règle l’unicité d’un nom ou d’une valeur. Elle ne démontre ni sa présence dans les logiciels, ni sa négociation entre pairs, ni son activation sûre.
  • La preuve complète relie deux dossiers distincts : demande, examen et décision d’une part ; code, versions, tests, interopérabilité, exploitation et retrait d’autre part.

Le risque commence par une phrase administrativement exacte : « le paramètre est enregistré ». Elle peut devenir, quelques réunions plus tard, « le paramètre est normalisé », puis « nos équipements le prennent en charge ». Aucun mensonge n’est nécessaire ; il suffit de perdre le verbe précis à chaque passage.

RFC 9519 modifie une porte bien définie. Il met à jour RFC 4250, RFC 4716, RFC 4819 et RFC 8308. Pour les plages visées, l’IETF Review cède la place à l’Expert Review. Certaines plages restent soumises à Standards Action ; l’usage privé reste un domaine local où plusieurs acteurs peuvent réutiliser une valeur sans promesse d’interopérabilité mondiale.

La réforme redistribue un droit de décision. L’IETF Review passe normalement par un RFC de l’IETF et le consensus. L’Expert Review confie l’évaluation à un groupe désigné. Selon RFC 8126, ces experts sont nommés et peuvent être remplacés par l’IESG, doivent suivre des critères, gérer les conflits d’intérêts et rendre leurs décisions défendables. Délégation ne signifie donc pas absence de procédure.

Le registre SSH d’IANA montre la coexistence des régimes. Les numéros de messages conservent une barrière Standards Action. Des registres de noms d’algorithmes utilisent l’Expert Review, publient les experts et renvoient vers RFC 9519. Le registre prouve ainsi qu’une chaîne de coordination a accepté une affectation déterminée. Il ne mesure pas le parc logiciel.

Ce second dossier commence sur le fil. RFC 4253 fait choisir l’algorithme dans l’intersection de listes ordonnées. Un nom enregistré mais absent d’une liste ne participe à aucune connexion. RFC 8308 ajoute un échange d’extensions parce qu’un pair doit annoncer ce qu’il sait traiter. Même cette annonce ne garantit ni un code correct ni une politique locale favorable. Enfin, RFC 9142 rappelle qu’un nom enregistré peut rester nécessaire à l’analyse tout en devenant déconseillé ou interdit.

Le reçu d’attribution doit conserver le registre, la plage, la demande, le demandeur, le contrôleur du changement, la documentation, les experts, les récusations, les échanges, les révisions, le motif et la date de publication IANA. Le reçu d’adoption ajoute les commits, versions, rôles pris en charge, captures de négociation, tests avec un second logiciel, valeurs par défaut, politiques, télémétrie d’échec, maintenance et chemin de retrait.

Les archives permettent de contrôler la première moitié : notice RFC Editor, texte, XML, errata, historique Datatracker et dernière révision du draft. Elles ne remplacent pas la seconde.

Les essais sur la primauté du code exécuté, la spécification minimale et l’adoption volontaire et les couches de réalité servent ici de discipline : respecter le registre pour ce qu’il coordonne, sans lui attribuer un résultat qu’il n’observe pas.