Resumen

  • draft-ietf-intarea-legacy-registries-00 propone cerrar el registro de subopciones NetWare, exigir aprobación del IESG para números de opciones IPv4, aplicar FCFS a nombres de máquinas y terminales, y retirar un registro de TTL que modelaba mal un valor local.
  • Ninguna de esas decisiones demuestra por sí sola qué software conserva el valor, qué trayecto lo transporta, qué operador lo autoriza o qué servicio termina bien.

La clausura no es una máquina del tiempo

El registro de NetWare/IP Option Type 63 Sub-Option Codes ofrece el caso más claro. El borrador quiere cerrarlo porque NetWare ya no se amplía, pero preserva la validez de las asignaciones existentes y permite actualizar sus registros conforme a RFC 8126. La institución deja de crear nuevos significados; no reescribe los bytes que ya circularon ni convierte retroactivamente sus valores en errores.

Para una empresa, esa diferencia determina el orden de una retirada segura. Un código heredado puede vivir en una controladora industrial, una copia de seguridad, un convertidor o un contrato de interoperabilidad. También puede ser arqueología sin usuarios. La etiqueta Closed no distingue ambos casos. Hay que observar versiones, configuraciones, registros de ejecución, rutas reales y resultados.

El peor plan elimina primero la capacidad de ver. Quita el analizador, borra la métrica y luego interpreta el silencio como prueba de ausencia. El plan defendible congela los nuevos usos, conserva telemetría, localiza dependencias, define la salida y solo después retira el último soporte reversible.

No todas las limpiezas significan lo mismo

El borrador asigna un instrumento distinto a cada problema.

Para IP Option Numbers, propone IESG Approval. Una nueva entrada necesitaría una decisión explícita de la dirección técnica. Sin embargo, el texto también advierte que las opciones IPv4 suelen fallar en la Internet pública y que una solución basada en ellas probablemente no sea fiable. La aprobación de un número no acredita que encaminadores, cortafuegos o rutas aceleradas lo transporten.

Para Machine Names y Terminal Type Names, propone First Come First Served. Esos registros carecen de procedimiento y no reciben altas desde hace veinte años. FCFS evita colisiones administrativas sin convertir a IANA en jurado de utilidad. La entrada puede ser única y, a la vez, no estar implementada, no tener usuarios o no ser segura.

Para IP Time to Live Parameter, pide eliminar el registro o corregir su nota. El sistema operativo o la aplicación de origen elige libremente el TTL. Que 64 sea un valor predeterminado recomendado no lo vuelve un código asignado centralmente. Aquí la institución no cierra un conjunto legítimo: reconoce que el conjunto nunca fue la abstracción correcta.

Por tanto, Closed detiene altas; IESG Approval eleva el umbral; FCFS ordena sin evaluar el fondo; y la eliminación corrige un error de modelo. Tratar los cuatro verbos como “obsoleto” destruye información sobre quién posee cada decisión.

Qué prueba realmente una fila de IANA

RFC 1700 publicaba Assigned Numbers como documento. RFC 3232 trasladó el registro vigente a bases de datos en línea. Fue una mejora fundamental: la autoridad administrativa pudo mantenerse sin publicar un nuevo RFC por cada cambio. Pero la mudanza no absorbió toda la realidad técnica.

La especificación conserva la semántica. Una implementación concreta decide qué acepta o genera. El operador autoriza o bloquea. La red determina el tránsito. La aplicación muestra el resultado. La fila de IANA prueba una asignación bajo una política; no prueba esas otras transiciones.

Un expediente de retirada necesita cinco comprobantes: versión y estado del documento, estado actual del registro, conducta de una versión nombrada, observación en un trayecto definido y resultado del servicio. La ausencia del último no se arregla citando dos veces el primero. Tampoco un flujo exitoso concede derecho a seguir ampliando un espacio cerrado.

Sigue siendo la revisión 00

El Datatracker presenta el texto como borrador activo del grupo intarea, con estado I-D Exists. Está fechado el 11 de septiembre de 2026 y expira el 15 de marzo de 2027. No es un RFC ni demuestra que el IESG o IANA hayan aplicado las peticiones. Las páginas vivas de IANA siguen describiendo el presente administrativo.

Esa condición abre decisiones legítimas: el grupo puede cambiar la lista, el procedimiento o la justificación. IANA puede señalar problemas de mantenimiento. Los usuarios pueden aportar evidencia de dependencias. Lo único que no cabe inferir es que una propuesta documental ya ha apagado el uso operativo.

Fuentes