Résumé

  • draft-cel-nfsv4-element-registries-00 propose huit registres IANA pour remplacer le choix informel du prochain numéro connu comme libre par l’auteur d’une extension NFSv4.
  • L’expert désigné vérifie l’hygiène de l’inscription, tandis que le consensus IETF juge la fonction ; ni l’un ni l’autre ne prouve qu’un binaire la prend en charge, qu’une requête est autorisée ou que l’application obtient le résultat attendu.

Un avis volontairement étroit

Le dossier arrive devant l’expert avec une opération nouvelle. La valeur demandée est la plus basse disponible. Le nom respecte la convention. Le bras XDR figure dans le projet. La colonne Versions correspond à la portée annoncée. La référence est bonne. Pour le registre, la demande est recevable.

L’expert n’a pourtant pas tranché la pertinence de l’opération. La révision 00 lui interdit précisément de confondre ces deux rôles. Le mérite appartient au processus de consensus qui produit une Proposed Standard ; l’examen expert confirme que l’attribution publique est correctement formée.

La version 00 de Registries of Network File System Version 4 Protocol Elements a été soumise le 25 septembre 2026 et expire le 29 mars 2027. Datatracker la présente comme un Internet-Draft individuel actif, sans adoption de groupe, sans flux défini, sans Area Director responsable et sans approbation IESG. Son en-tête vise Standards Track et une mise à jour de RFC 8178 si le texte est approuvé. Ce n’est pas un RFC, ni la preuve que les registres existent déjà chez IANA.

Le problème est toutefois concret dans le modèle du protocole. NFSv4 place des entiers à des endroits où ils commandent l’interprétation : numéros d’opérations et de callbacks, codes d’état, positions d’attributs, bits ACCESS et valeurs OPEN. Deux projets parallèles peuvent choisir le même prochain entier à partir de listes privées différentes. Chacun fonctionne seul ; l’ambiguïté apparaît lorsque les implémentations se rencontrent.

Le discriminant ne transporte pas son histoire

Dans une requête COMPOUND, nfs_opnum4 choisit un bras d’union pour les arguments et les résultats. CB_COMPOUND possède son espace pour les opérations de rappel. Un numéro d’attribut est aussi une position dans le bitmap fattr4. Un bit OPEN ou ACCESS modifie le comportement demandé ou rapporté.

Le paquet ne contient pas le nom du projet qui a inspiré la constante. Si deux sens occupent la même coordonnée dans le même espace, le récepteur ne peut pas consulter l’intention de l’émetteur. Il décode selon la table de son propre binaire.

RFC 8178 autorise ces formes d’extension XDR et interdit de supprimer ou de réutiliser une valeur attribuée. Il laisse néanmoins ouverte la question initiale : comment l’auteur obtient-il la valeur ? La révision 00 décrit la pratique habituelle comme le choix du nombre suivant le plus élevé connu. La qualité du contrôle dépend donc d’une connaissance exhaustive des travaux simultanés.

RFC 8276 illustre une démarche soigneuse mais locale : les auteurs des attributs étendus ont vérifié leurs valeurs contre la version de protocole et la version mineure courante connues, afin de permettre des prototypes interopérables. Une vérification manuelle ne peut pas réserver publiquement la valeur contre un projet encore invisible.

Huit espaces, une autorité bornée

Le projet demande huit registres : Operations, Callback Operations, Status Codes, fattr4 Attributes, ACCESS Flags, OPEN Share Access Flags, OPEN Result Flags et OPEN Delegation Types. Leurs tables initiales viennent de RFC publiés.

La séparation des registres est essentielle. Le nombre 4 peut être légitime dans plusieurs espaces, car le contexte lui donne sa portée. Une preuve sérieuse ne dit donc pas seulement « valeur 4 » : elle indique le registre, la direction, le type XDR, la version mineure et le texte de référence.

Après publication éventuelle du projet, chaque registre deviendrait la source autoritative des attributions de son type. Le document qui crée un élément demanderait la valeur dans ses considérations IANA et dériverait sa constante XDR de la valeur reçue. Il ne pourrait plus publier une autre constante choisie à part.

Cette autorité reste bornée. IANA est autoritative pour l’attribution. Le RFC est autoritatif pour la définition normative. Le binaire livre une table effective. Le serveur décide si l’opération est prise en charge et autorisée. Le stockage et l’application attestent le résultat. Une ligne de registre ne peut exercer aucun de ces pouvoirs en cascade.

L’allocation précoce n’est pas une approbation anticipée

Attribuer uniquement au moment de la publication d’un RFC laisserait une période dangereuse. Les prototypes auraient besoin d’une constante, et les auteurs recommenceraient à choisir une valeur apparemment libre. RFC 7120 offre l’allocation précoce.

La spécification doit être suffisamment décrite et stable. Les responsables doivent constater un intérêt pour l’implémentation anticipée ou un risque de contention. IANA publie alors une allocation temporaire, normalement valable un an, avec ses dates.

La révision 00 demande à un document de groupe de solliciter cette allocation après adoption et lui interdit d’employer une valeur qui n’est ni enregistrée ni allouée précocement. Le reçu temporaire affirme : « cette coordonnée est réservée à ce travail pendant cette période ». Il n’affirme pas : « ce travail sera un RFC ».

Expiration, renouvellement, dépréciation et éventuelle désallocation restent des événements distincts. Les opérateurs doivent enregistrer l’état exact de la ligne, pas seulement son existence.

Ne jamais effacer, ne jamais réutiliser

La proposition attribue la plus petite valeur disponible non réservée. Mais une valeur attribuée ne revient pas automatiquement dans le stock. Si un élément est retiré de toutes les versions, l’entrée reste. La colonne Versions peut devenir none et une nouvelle référence expliquer le retrait.

Ce choix conserve la mémoire de l’écosystème. Retirer une fonction de la norme ne retire pas sa constante des sources anciennes, des générateurs XDR, des analyseurs, des captures ou des équipements non mis à jour. Réutiliser le numéro donnerait au même octet deux histoires incompatibles.

none n’est donc pas la preuve qu’aucune machine n’émet plus la valeur. C’est une déclaration sur la portée normative actuelle. De même, 4.1+ n’est pas un recensement des serveurs NFSv4.1. RFC 8178 autorise plusieurs variantes valides d’une même version mineure, selon les extensions optionnelles mises en œuvre.

Du registre à l’effet visible

Une enquête opérationnelle doit relier neuf reçus : révision et statut du document ; ligne de registre ; action d’attribution et dates ; définition XDR exacte ; empreinte du code et des tables générées ; capacité réellement prise en charge ; octets et contexte du paquet ; décision d’exécution et d’autorisation ; observation par le stockage et l’application.

Une ligne trouvée ferme la question de la coordination centrale. Elle ne prouve pas que le logiciel installé connaît la définition. Une ligne absente met en cause l’autorité publique d’une valeur couverte ; elle ne prouve pas qu’aucun fork expérimental ne l’émet. Un décodage réussi ne prouve pas l’autorisation. NFS4_OK ne prouve pas à lui seul la durabilité ou la lecture ultérieure.

La migration doit donc inventorier le code source, les XDR générés, les bindings, les dissectors, les fixtures et les binaires. Il faut comparer l’espace et la direction, pas un entier nu. Les anciens paquets et empreintes de builds doivent être conservés avant toute renumérotation : le registre futur ne pourra pas reconstruire le sens choisi par un binaire ancien.

Ce que les sources ne démontrent pas

Le dossier gelé établit la proposition des huit registres, le risque de collision entre travaux simultanés, les règles d’allocation, l’absence de réutilisation et la portée réduite de l’expert. Il ne documente aucune collision observée, aucun produit défectueux, aucune adoption par le groupe NFSv4, aucun consensus IETF, aucune action IANA déjà réalisée, aucun déploiement, incident ou exploit.

Lu Heng invite à placer l’autorité au niveau de la preuve qu’elle peut réellement soutenir. Ici, le registre peut dire qui détient une coordonnée et selon quelle référence. Le processus de normalisation peut dire quelle règle a été adoptée. Seul le système en marche peut dire ce qu’il a décodé, autorisé et produit.

Sources