Resumen

  • draft-cel-nfsv4-element-registries-00 propone ocho registros IANA y exige obtener los nuevos valores mediante asignación pública o asignación temprana, en vez de escoger el siguiente entero que el autor cree disponible.
  • Una entrada nunca se elimina ni se reutiliza aunque el elemento deje de aplicarse a todas las versiones; esa memoria evita ambigüedad, pero no demuestra qué constantes siguen dentro de los sistemas desplegados.

La lápida ocupa espacio por una razón

Un estándar posterior retira un elemento de NFSv4.2. El responsable actualiza la columna Versions hasta none y añade la referencia del retiro. Sería tentador borrar la fila y devolver el número al inventario libre. La propuesta lo prohíbe.

No existe un mecanismo capaz de certificar que todos los clientes, servidores, analizadores y equipos cerrados abandonaron a la vez la constante anterior. Si el número se asigna a otro elemento, un emisor antiguo puede encontrarse con un receptor nuevo. Ambos usarán un valor formalmente válido y entenderán cosas distintas.

La revisión 00 de Registries of Network File System Version 4 Protocol Elements fue presentada el 25 de septiembre de 2026 y vence el 29 de marzo de 2027. Datatracker la registra como Internet-Draft individual activo, sin adopción de grupo, sin flujo formal, sin AD responsable y sin aprobación del IESG. El encabezado propone Standards Track y actualizar RFC 8178 si se aprueba. No es un RFC ni prueba de que IANA haya creado los registros.

El documento cubre ocho familias: operaciones, operaciones de callback, códigos de estado, atributos fattr4, flags de ACCESS, flags de acceso de OPEN, flags de resultado de OPEN y tipos de delegación de OPEN. Cada familia tiene su propio contexto. El mismo entero puede existir en registros distintos; dentro del mismo registro, dos sentidos son incompatibles.

Cuando el número decide cómo leer los bytes

NFSv4 concentra las acciones de archivo, bloqueo, sesión y pNFS en operaciones de COMPOUND. El número nfs_opnum4 selecciona un brazo XDR con argumentos y resultados concretos. CB_COMPOUND hace lo mismo en sentido de callback. Un atributo usa su número como constante y posición del bitmap. Los bits de ACCESS y OPEN cambian conducta.

Por eso la colisión no es una duplicación de catálogo. Si dos borradores asignan el mismo discriminante a estructuras diferentes, el receptor no puede recuperar la intención del emisor. Aplica la tabla compilada que posee.

RFC 8178 define qué extensiones XDR son admisibles y ya impide borrar o reutilizar elementos. Sin embargo, no explica cómo se elige el valor nuevo. Según la revisión 00, el autor suele tomar el siguiente número posterior al máximo que conoce. Dos trabajos simultáneos pueden considerar libre la misma posición.

RFC 8276 documentó una práctica prudente: comprobó sus valores de atributos extendidos frente a las especificaciones más recientes conocidas. Eso facilitó prototipos interoperables, pero no produjo una reserva pública capaz de cubrir un borrador paralelo aún desconocido.

Del recuerdo privado a la asignación pública

La propuesta rellena las tablas iniciales con elementos publicados en RFC y convierte cada registro en fuente autoritativa de asignaciones para su tipo. Un documento nuevo debe pedir su valor en IANA Considerations, recibirlo por el proceso y derivar de él la constante XDR. No puede publicar otra constante elegida por separado.

La política combina Standards Action with Expert Review. Standards Action conserva el requisito de RFC 8178: una extensión de una versión menor existente debe publicarse como Proposed Standard. El experto no sustituye ese consenso. Verifica registro correcto, dirección, menor valor disponible o asignación temprana propia, nombre único, definición XDR, alcance de versiones y referencia.

La distinción es decisiva. IANA coordina el número. El consenso decide el mérito de la función. Un proveedor decide si la implementa. El operador decide qué versión ejecuta. El servidor decide si reconoce y autoriza la solicitud. El almacenamiento y la aplicación muestran el resultado.

Reservar antes de estandarizar

Los prototipos necesitan constantes antes de que un RFC llegue al final del proceso. RFC 7120 permite una asignación temprana cuando la especificación está descrita y estable y existe interés de implementación o riesgo de contención. IANA publica el valor como temporal, normalmente por un año.

La revisión 00 indica que un documento de grupo debería pedirla después de ser adoptado y no debe usar un valor no registrado ni asignado tempranamente. Así se evita que cada laboratorio cree su propia realidad mientras el texto madura.

Temporal no significa aprobado. La asignación puede renovarse, caducar, quedar obsoleta y, bajo ciertas condiciones, desasignarse. El recibo debe guardar fechas y estado. Una fila expirada no puede citarse como si fuera autoridad vigente.

La columna Versions no es un censo

Una entrada 4.1+ afirma que el estándar hace aplicable el elemento desde NFSv4.1 mientras ninguna norma posterior lo retire. No afirma que todos los clientes y servidores 4.1 lo soporten. RFC 8178 permite variantes válidas de una misma versión menor, con subconjuntos distintos de extensiones opcionales.

Una entrada none afirma que ninguna versión menor actual conserva esa aplicabilidad normativa. Tampoco demuestra que todos los artefactos antiguos desaparecieron. La fila describe el mapa público del protocolo; el inventario operativo describe el mundo instalado.

El operador debe buscar constantes en código fuente, XDR generado, bibliotecas, analizadores, pruebas, firmware y capturas. La clave de búsqueda incluye registro, dirección y valor. Un número sin tipo carece de alcance suficiente.

La ausencia en el registro es una prueba útil de falta de asignación pública para un elemento cubierto. No prueba que ningún fork privado lo emita. La presencia demuestra coordinación, no soporte. Un binario puede ser anterior a la fila, mantener un formato provisional o reconocer el elemento sin implementarlo.

Nueve recibos, no una fila mágica

La cadena completa conserva: documento y estado; fila del registro; decisión de asignación y fechas; definición XDR; huella del build y tabla de constantes; capacidad efectiva; paquete y contexto COMPOUND; decisión de reconocimiento/autorización/ejecución; resultado visible en almacenamiento y aplicación.

Cada nivel responde otra pregunta. Una asignación final no actualiza el software. Un decode correcto no concede permisos. Un resultado de operación no prueba necesariamente persistencia. Una lectura posterior tampoco puede reconstruir qué tabla de constantes usó una captura antigua si se perdió el build.

Antes de renumerar una constante provisional hay que conservar paquetes y huellas, aislar los emisores viejos y verificar que dos significados no coincidan durante la transición. El registro decide la coordenada oficial, pero no reescribe el pasado.

Límites del expediente

Las trece fuentes muestran la propuesta, el método ad hoc anterior, el riesgo de trabajos concurrentes, la asignación temprana, la conservación de entradas y el alcance del experto. No prueban una colisión NFSv4 real, un producto afectado, adopción por el WG, consenso IETF, creación efectiva de los registros, uso desplegado, incidente o explotación.

Aplicada la doctrina de Lu Heng, la estabilidad útil consiste en no perder la historia de una coordenada. El registro puede sostener esa afirmación. No debe transformarse en autoridad sobre software, autorización o resultados que solo el sistema en ejecución puede observar.

Fuentes