Resumen

  • El grupo NFSv4 publicó el 29 de septiembre la revisión -06 de su borrador sobre ACL. Su atributo opcional ACL_Choice deja el identificador 87 y pasa al 89; los borradores de archivo no almacenable en caché y de metadatos de directorio usan 87 y 88.
  • Los cuatro códigos propuestos para errores de tamaño ACL se trasladan de 20000–20003 a 10095–10098. El nuevo texto impide emitirlos sin AclChoice, incluso cuando el servidor lo admite en otro sistema de archivos. La sección aún solicita consenso.

Quien mantiene un decodificador de NFSv4 puede ver tres números contiguos y pensar que representan una asignación ya cerrada. El cambio real es más modesto. La versión -05, fechada el 14 de septiembre, proponía el 87 para ACL_Choice. En la -06 del día 29, la tabla de atributos y la constante del esquema pasan a 89. El propio registro de cambios lo vincula con dos trabajos paralelos: uncacheable_file_data está propuesto como 87 y uncacheable_dirent_metadata como 88. Los tres textos siguen siendo borradores.

Esta coordinación importa porque no son tres nombres para una misma capacidad. Un atributo trataría de explicar al cliente opciones de semántica ACL en la revisión propuesta de NFSv4.1; los otros dos describen límites del caché de datos de archivos y de metadatos de entradas de directorio. Si un prototipo conservó una tabla antigua, sus pruebas deberían identificar con qué revisión se construyó. No hay, en las fuentes públicas consultadas, evidencia de una colisión en sistemas desplegados ni de que todos los fabricantes hayan implementado estos valores.

La reubicación de los errores enseña otra frontera. Los nombres NFS4ERR_ACLST_POORFIT, NFS4ERR_ACLST_NOFIT, NFS4ERR_ACLST_TOOBIG y NFS4ERR_ACLFT_TOOBIG distinguen distintas situaciones de ACL que no cabe guardar o devolver. La versión anterior les daba valores 20000 a 20003; la nueva asigna 10095 a 10098. Más allá del cambio de cifras, el borrador incorpora una condición: el servidor no debe devolverlos si no soporta AclChoice ni cuando el sistema de archivos al que se accede carece de esa función. El soporte no se deduce de un solo nombre de servidor.

Un ensayo ilustrativo sería montar dos exportaciones en la misma máquina. En una, la información de elección ACL está disponible; en la otra, no. Que el cliente reconozca un número de error no demostraría por sí solo que la segunda exportación ofrece esa semántica. Habría que comprobar la capacidad donde se realiza la operación y registrar la versión del borrador usada por cliente y servidor. Es una propuesta de prueba, no el relato de una incidencia real.

El Datatracker mantiene -06 como documento activo del grupo de trabajo en estado I-D Exists. No es un RFC y todavía no ha actualizado RFC 7530 ni RFC 8881. El propio texto habla de preparar un futuro último llamamiento del grupo; además, señala que la parte de errores necesita consenso. La consecuencia editorial no es declarar vencedores definitivos para 87, 88 y 89, sino separar la coordinación del papel de la compatibilidad que pueda demostrarse en una implementación concreta.

Fuentes