Resumen

  • El IESG abrió el 27 de agosto el último llamado sobre una propuesta que permitiría crear en IANA un registro completo antes de que el documento que lo define sea aprobado como RFC. El registro nacería como temporal, con dos años de vigencia pública.
  • La fecha del registro y la condición de sus entradas pueden divergir. Un historial de transiciones debe conservar el borrador exacto, el consenso y las aprobaciones, la regla provisional aplicada a cada alta y las decisiones posteriores de cambio, renovación, cierre o consolidación.

Supongamos que una implementación incorpora el valor 23 desde una tabla de IANA. Años después, su mantenedor todavía recuerda el número, pero no si la tabla era provisional, si el valor dependía de otro borrador o si la política de admisión cambió al mes siguiente. La coordinación funcionó en el primer momento y perdió su contexto en el segundo.

Ese es el problema institucional que aparece en Early IANA Registry Creation. El IESG pidió comentarios hasta el 10 de septiembre. La versión 02 aspira a convertirse en Proposed Standard, aunque por ahora sigue siendo un Internet-Draft que puede cambiar, ser devuelto o no aprobarse.

La propuesta intenta evitar una disyuntiva conocida. Si un grupo de trabajo necesita un espacio nuevo de nombres o códigos antes de publicar el RFC fundador, puede mantener una lista informal. Esa lista facilita las pruebas, pero puede competir después con la tabla oficial. La otra opción es esperar, con el riesgo de que varias implementaciones ocupen por su cuenta el mismo valor. Un registro temprano y público reduce ambos problemas.

Sin embargo, crear la tabla no es lo mismo que reservar una fila en una tabla existente. La decisión anticipada establece un nuevo punto de coordinación, define quién puede admitir valores mientras el texto sigue abierto y crea expectativas en implementadores externos. Por eso la procedencia de cada estado importa tanto como la fecha visible.

Del borrador a IANA hay una cadena de autorización

El proceso comienza con los autores. Ellos solicitan la creación anticipada a los presidentes del grupo de trabajo y señalan qué registro debe crearse y dónde. Los presidentes verifican las condiciones y determinan si existe consenso en el grupo para actuar antes de la aprobación del RFC. Después piden la conformidad de los directores de área, que pueden valorar especialmente el riesgo de que el registro nunca llegue a ser permanente. Solo entonces se formula la petición a IANA.

IANA crearía la tabla en el lugar correspondiente, la marcaría como temporal y haría públicas las fechas de alta y vencimiento. La primera vigencia sería de dos años. Al aproximarse el final, preguntaría a los presidentes y al director de área si desean otros dos. Después de esa primera prórroga, una renovación adicional requeriría también la aprobación del IESG, motivos y un plan para la especificación.

Sin prórroga aprobada, IANA cerraría el registro y lo identificaría como tal. Los presidentes también podrían pedir el cierre en cualquier momento. Hay una excepción al reloj: si el documento fundador entra en evaluación del IESG mientras el registro todavía es válido, el registro no caduca durante esa evaluación.

El diseño no deja la provisionalidad oculta. El inconveniente es otro: una etiqueta de estado no conserva necesariamente la decisión que la produjo. Dos registros que dicen “temporal hasta 2028” pueden haber llegado allí con consensos, políticas de entrada y dependencias documentales muy diferentes.

Dentro de una tabla temporal puede haber tiempos distintos

Durante la fase anticipada no se aplicaría todavía la política prevista para el registro definitivo. Se usaría una regla puente elegida en función de esa política futura.

Cuando el destino sea First Come First Served o Expert Review —mecanismos que no exigen un RFC para cada alta—, la entrada necesitaría la aprobación de un presidente del grupo. La propuesta afirma que, una vez concedidas, esas altas no requieren renovación. Si se trata de un texto patrocinado directamente por un director de área, el director ocupa ese puesto.

Si la política futura exige RFC, como IETF Review o Standards Action, la fila debe seguir el procedimiento de asignación anticipada descrito en la revisión de RFC 7120. Incluso cuando la tabla se vuelva permanente, esa fila conserva su marca temporal hasta que su propio documento sea aprobado. Specification Required añade dos caminos según se admita o no que un Internet-Draft sirva como especificación permanente.

Así, el contenedor puede caducar en dos años mientras una entrada aprobada por el presidente no necesita renovarse; otra entrada sí tiene plazo propio; y una tercera depende de que un texto distinto avance. Más tarde, el contenedor puede hacerse definitivo y seguir albergando una fila provisional. No existe un único reloj que explique todo.

La distinción es esencial para no repetir una conclusión vieja con un título nuevo. El RFC 7120 vigente organiza reservas tempranas en registros ya creados. La consulta de 2026 pregunta si se puede crear antes el propio registro y cómo gobernarlo hasta que llegue su fundamento permanente.

La política escrita puede moverse mientras IANA opera

Un borrador no queda congelado por abrir una tabla. Si la futura política de registro cambia de Expert Review a IETF Review, por ejemplo, también cambia el mecanismo provisional que corresponde. La propuesta ordena notificarlo a IANA y, a la vez, declara que IANA no seguirá las modificaciones de los documentos creadores.

La separación es correcta: IANA ejecuta las instrucciones y administra la tabla; no debería inferir política de cada nueva versión. Autores y presidentes conservan la obligación de revisar el contenido y la estructura. Pero esa distribución exige una unión probatoria. La notificación debe indicar qué versión introdujo el cambio, quién la validó, cuándo empezó a regir y qué filas quedaron afectadas.

De lo contrario, la página operativa puede mostrar el resultado sin revelar el camino. Un observador verá un número y una referencia, pero no sabrá si la puerta fue la aprobación del presidente, una asignación anticipada o un requisito que solo iba a existir en la versión final.

El control útil es un historial, no una captura de pantalla

El registro necesita dos capas de trazabilidad.

La primera acompaña a la tabla: identificador inmutable, grupo de registro, borrador fundador con versión y huella, constancia del consenso, decisiones de presidentes y director de área, fecha de solicitud, creación, vencimiento, política permanente proyectada y procedimiento provisional vigente. Cada cambio de estructura o política debe añadir un evento. Renovación, pausa durante evaluación del IESG, petición de suspensión de IANA, cierre y consolidación deben conservar el antes y el después.

La segunda acompaña a la fila: valor, significado, referencia, responsable del cambio, vía de aprobación, versión de política y situación temporal. Si depende de otro borrador, esa relación no puede quedar solo en el correo de solicitud. Al cerrar o consolidar el registro, la fila debe explicar si se mantuvo, cambió de condición o quedó sujeta a una nueva decisión.

El objetivo no es publicar conversaciones privadas. Basta con roles, referencias de decisión, fechas, huellas documentales y resultados. IANA no gana poder político por exponer la procedencia; simplemente hace verificable la instrucción que ejecutó.

Ni registro ni último llamado equivalen a aprobación final

La consulta se refiere a coordinación, no a una licencia técnica. Una entrada pública identifica un valor y su significado documentado. No certifica un producto, no obliga a un operador a desplegarlo y no convierte una asignación temprana en consenso definitivo sobre la tecnología.

Tampoco debe sobredimensionarse el cierre. El borrador dice que un registro sin prórroga será cerrado y etiquetado. No ofrece una regla universal que borre o libere inmediatamente todas sus filas. Atribuirle ese efecto sería inventar una consecuencia que el texto no expresa.

No se encontró evidencia de un registro ya creado con este mecanismo, de una implementación dependiente de él ni de un abuso. Precisamente por eso este es el momento adecuado para diseñar la trazabilidad: antes de que los valores salgan de la tabla, se incrusten en productos y dejen atrás la explicación de su autoridad provisional.

Fuentes