Résumé

  • Dans la version -06 datée du 29 septembre, le projet du groupe NFSv4 place l'attribut facultatif ACL_Choice au numéro 89 au lieu de 87. Deux autres projets utilisent 87 pour les données de fichier non mises en cache et 88 pour les métadonnées d'entrée de répertoire.
  • Quatre erreurs relatives à la taille des ACL passent de 20000–20003 à 10095–10098. Le nouveau texte exclut leur emploi si AclChoice n'est pas pris en charge par le serveur ou par le système de fichiers visé. Le passage reste signalé comme nécessitant un consensus.

Un numéro de champ peut sembler définitif dans une table de protocole. Il ne l'est pas quand trois textes évoluent encore côte à côte. Le projet ACLs within the NFSv4 Protocols proposait, dans sa version -05 du 14 septembre, d'attribuer 87 à ACL_Choice. Quinze jours plus tard, sa version -06 choisit 89. Le journal des modifications donne la raison précise : faire de la place aux travaux sur les fichiers et les répertoires « uncacheable ». Les projets correspondants placent aujourd'hui uncacheable_file_data à 87 et uncacheable_dirent_metadata à 88.

Ces trois attributs ne servent pas le même usage. ACL_Choice, optionnel dans la refonte proposée de NFSv4.1, renseignerait le client sur certains choix de fonctionnement des listes de contrôle d'accès. Les deux autres concernent la politique de cache des données ou des métadonnées de répertoire. Le déplacement n'annonce ni un incident constaté ni une migration déjà réalisée chez tous les fournisseurs. Il donne plutôt aux prototypes un nouvel ensemble de valeurs à examiner. Un essai fondé sur la version précédente doit indiquer la révision utilisée avant que l'on compare ses traces avec celles d'un autre essai.

Le changement des erreurs pousse la même logique plus loin. Le brouillon définit quatre cas où une ACL est trop grande pour être conservée ou renvoyée, avec des nuances sur la limite atteinte. Il remplace leurs valeurs 20000 à 20003 par 10095 à 10098. Surtout, une phrase ajoutée interdit, dans la proposition, de renvoyer ces erreurs lorsque le serveur ne connaît pas AclChoice ou lorsque le système de fichiers effectivement interrogé ne le prend pas en charge. L'adresse d'un serveur ne prouve donc pas à elle seule la capacité de chaque volume qu'il exporte.

Prenons un scénario de laboratoire : un même serveur présente deux systèmes de fichiers dont la prise en charge des ACL diffère. Un client sait décoder la valeur 10095, mais il n'a vérifié ACL_Choice que sur le premier volume. Interpréter une réponse du second comme une preuve de la même fonction reviendrait à sauter une étape. Ce scénario sert à éprouver la lecture du projet ; aucun défaut commercial ou changement d'autorisation en production n'est documenté ici.

Le registre IETF classe toujours cette version comme Internet-Draft actif du groupe, à l'état I-D Exists. Le texte mentionne un futur examen en dernier appel du groupe, non un appel déjà achevé. Son en-tête n'envisage de mettre à jour les RFC 7530 et 8881 que « si approuvé ». Le marqueur « Consensus Needed » demeure dans la section sur les erreurs. La lecture prudente consiste à suivre les prochaines versions et à distinguer un identifiant provisoire, une fonction annoncée et le comportement constaté du système de fichiers concerné.

Sources