Resumen

  • El 11 de septiembre de 2026, el Datatracker registró la aprobación de draft-ietf-intarea-legacy-registries-00 como versión del grupo. El documento sigue siendo un Internet-Draft, no una RFC.
  • La propuesta no contiene una única limpieza: cerraría un registro, fijaría IESG Approval para otro, daría First Come First Served a dos listas y eliminaría —o anotaría— el registro del TTL.
  • Las cinco superficies de IANA siguen sin esos cambios. Un recibo por acción debería enlazar la etapa documental con el resultado público y conservar el tratamiento de los valores históricos.

La adopción mueve la responsabilidad

La ficha vigente del Datatracker muestra “Updates to Legacy IANA Registries” entre los documentos activos de INTAREA. En su historial aparecen, con fecha 11 de septiembre, la aprobación de la versión -00 por el grupo y la sustitución de la serie individual.

Eso no es un simple cambio tipográfico. Un grupo que adopta un proyecto se responsabiliza de discutirlo y desarrollarlo. Pero todavía no ha concluido el proceso de una norma propuesta. Las peticiones escritas en futuro dentro de las consideraciones para IANA no pasan a ser órdenes ejecutadas por llevar el nombre del grupo.

El historial de la etapa individual ayuda a leer la decisión. El 27 de agosto, los presidentes anotaron consenso para adoptar el texto. También dejaron constancia de una objeción, señalaron que había sido escuchada y debatida y explicaron que el proyecto trata el mantenimiento de registros, no adopta una posición sobre el futuro de IPv4. La adopción abre un trabajo común; no cierra cada desacuerdo técnico.

Además, el traspaso apenas tocó el contenido. La revisión individual 03 y la revisión 00 de INTAREA solicitan las mismas acciones. La diferencia sustantiva es nula: se corrigió una concordancia gramatical y se añadió un nombre a los agradecimientos. El hecho nuevo es quién custodia el documento.

Una palabra oculta cuatro tratamientos

El proyecto reúne varios residuos administrativos de épocas distintas, pero no los declara equivalentes.

Para NetWare/IP Option Type 63 Sub-Option Codes, propone cerrar el registro. Ya no se aceptarían altas, aunque las entradas existentes seguirían siendo válidas y actualizables. La RFC 8126 define precisamente así un registro cerrado y exige que la información permanezca disponible con fines informativos e históricos.

Para IP Option Numbers, el texto no cierra el espacio. Le asigna IESG Approval. La RFC 8126 describe esta vía como excepcional y poco utilizada: el IESG puede aprobar una asignación sin exigir una RFC, pedir documentación adicional o consultar a la comunidad. La propuesta elevaría la decisión a un órgano concreto, no impondría una prohibición automática.

En Machine Names y Terminal Type Names, la dirección cambia. La nueva regla sería First Come First Served, que la RFC 8126 resume como documentación mínima sin revisión. El proyecto observa que no ha habido altas durante décadas y acepta el riesgo de solicitudes poco sensatas bajo el filtrado ordinario de IANA. Una vía ligera y una clausura producen incentivos opuestos.

El registro IP Time to Live Parameter recibe un cuarto tratamiento. El proyecto sostiene que nunca debió existir, porque el TTL lo elige libremente el sistema o la aplicación, y pide eliminarlo. Si no fuera posible, ofrece una nota de reemplazo. El resultado público podría ser una página menos o la misma página con otra explicación. Llamar a ambos “cierre” borraría una diferencia comprobable.

IANA todavía muestra el antes

La página de parámetros DHCP y BOOTP conserva los subcódigos NetWare y muestra Not defined como procedimiento. No aparece una marca de cierre.

La página de parámetros IPv4 mantiene Not defined para IP Option Numbers. También mantiene el registro TTL y la recomendación de 64 como valor predeterminado. Sus valores experimentales siguen documentados, pero la política IESG Approval aún no figura allí.

La lista Machine Names continúa con Not defined. Terminal Type Names conserva la curiosa etiqueta Not defined?. Ninguna de las dos declara todavía First Come First Served.

No hay base para acusar a IANA de demora. La RFC 8126 dice que sus acciones se producen normalmente cuando un documento es aprobado para publicación, y este proyecto aún está en desarrollo. La página de documentos de INTAREA responde a la pregunta «¿en qué estado está el texto?». Los registros de IANA responden a «¿qué regla está vigente?». Son pruebas complementarias, no intercambiables.

El debate queda unido al expediente

Las actas de INTAREA en IETF 126 recogen dudas sobre el espacio de opciones IPv4 y sobre la conservación de información antigua. Un participante temía que bloquear números futuros perjudicara usos legítimos en dominios limitados. Otro pidió no perder los datos cuando algo quedara fuera de uso. El autor respondió remitiendo a valores experimentales y a la permanencia de las entradas.

El hilo de adopción cuestiona también la caracterización de las opciones IPv4 y el posible uso futuro de la justificación como una afirmación más amplia. Hubo apoyos claros. La decisión de los presidentes no borra esas intervenciones; las convierte en parte del material que el grupo debe resolver.

Por eso conviene nombrar el acto sin inflarlo: INTAREA aceptó trabajar sobre el proyecto. No aprobó todavía cada instrucción como texto final y no certificó cambios en IANA.

Un comprobante para cada verbo

Una breve constancia de acción registral haría visible el trayecto. Es una propuesta editorial, no una función anunciada por IETF o IANA.

Cada constancia incluiría el nombre y la URL exactos del registro, una captura fechada del estado anterior, la revisión y huella del proyecto, el verbo solicitado, los hitos del grupo y del IESG, la confirmación de IANA, la referencia efectiva, el estado posterior y el destino de las entradas antiguas.

No bastaría una constancia para las dos listas de nombres: sus cambios pueden ejecutarse en momentos distintos. Tampoco debería anotarse «eliminado» cuando el resultado sea «cerrado». En el caso del TTL, tendría que indicar si se retiró la página o se aplicó la nota alternativa. Si el grupo cambia de criterio, la solicitud superada debería quedar en la secuencia.

La disciplina parece minúscula, pero evita una confusión frecuente en la gobernanza técnica. Un nombre de archivo prueba que cambió la responsabilidad editorial. Una futura RFC probaría la aprobación de un texto. Solo un registro publicado con su nueva política prueba la ejecución. El público necesita las tres fechas.

Fuentes

  1. IETF Datatracker — documento actual
  2. Historial del documento del grupo
  3. Revisión 00 del grupo
  4. Historial del documento individual sustituido
  5. Revisión individual 03
  6. Actas de INTAREA en IETF 126
  7. Debate de adopción en INTAREA
  8. IANA — parámetros DHCP y BOOTP
  9. IANA — parámetros IPv4
  10. IANA — Machine Names
  11. IANA — Terminal Type Names
  12. RFC 8126 — reglas para registros IANA
  13. Documentos de INTAREA