Summary

  • Resumen. El borrador draft-ietf-ianabis-rfc8126bis-04, actualizado el 26 de octubre de 2026, ordenaría a IANA crear un campo «Change Controller» en los nuevos registros que admitan inscripciones sin un RFC del cauce IETF. Enumera First Come First Served, Expert Review, Specification Required y RFC Required. En registros existentes sin ese campo añadiría más adelante casillas vacías.
  • El RFC 8126 vigente ya aconseja identificar al responsable de cambios. La nueva redacción convertiría parte de ese consejo en una instrucción operativa para IANA. La tabla pública de funciones JSONPath muestra las dos funciones separadas: Glyn Normington figura como experto e IETF como controlador de cambio de las cinco entradas actuales.

Una asignación no termina el trabajo

El día que se asigna un código, su valor y su referencia quedan a la vista. Años después puede haber que actualizar la explicación, cambiar el contacto o señalar que una descripción anterior quedó anticuada. El registro continúa funcionando mientras sus autores originales cambian de empleo o el grupo de trabajo se disuelve. La siguiente decisión llega a una mesa que necesita una firma legítima, no solo una dirección a la que escribir.

El RFC 8126 establece desde 2017 la regla de fondo. En registros e inscripciones procedentes de RFC del cauce IETF, el control corresponde por defecto al IETF a través del IESG. Recomienda definir un controlador para registros que permitan aportaciones ajenas a ese cauce y para cada valor pertinente. También dice que los nuevos registros de orden de llegada y los sometidos a revisión experta deberían llevar un campo de control de cambios. El borrador nuevo no descubre un problema secreto; toma una recomendación que ya existe y la acerca a la hoja de trabajo de IANA.

La revisión -04 de IANABIS propone una instrucción concreta. Su sección 11.2 pide crear el campo en todos los registros nuevos sometidos a First Come First Served, Expert Review, Specification Required o RFC Required, además de cualquier procedimiento que permita registrar sin un RFC IETF. La lista importa porque una revisión técnica y la potestad de modificar una entrada son actos distintos. El experto valora si una solicitud cumple los criterios; el controlador puede autorizar que una línea existente cambie. Un mismo nombre podría intervenir en ambos pasos, pero el registro debe mostrar con qué facultad actúa.

Hay una precisión casi burocrática que evita una confusión grande. El borrador dice que las inscripciones nacidas de RFC del IETF deben nombrar normalmente al «IETF», no al «IESG», en el campo de control. El IESG representa a la organización en esa función. Algunas normas de origen exigen expresamente «IESG», como sucede en registros de puertos, y esa instrucción específica manda. El título escrito en la tabla debe seguir la autoridad del documento, no la comodidad de quien rellena la celda.

La casilla sin nombre

La parte retrospectiva del plan no promete magia. IANA añadiría campos vacíos en los registros antiguos que usan esos procedimientos y carecen de la columna. El borrador no cifra cuántos registros están en esa situación ni fija la fecha para completar sus entradas. La columna vacía permite reconocer una deuda de atribución; no la liquida. Haría falta volver a la norma de creación, las reglas posteriores y las decisiones que delegaron el control. Asignar por defecto al antiguo autor o al revisor por el mero hecho de encontrar su nombre podría construir una autoridad falsa.

El registro IANA de extensiones JSONPath ofrece un ejemplo actual donde la respuesta sí aparece. Tiene Expert Review como procedimiento y nombra a Glyn Normington como experto. Sus cinco funciones publicadas —length, count, match, search y value— muestran «IETF» en la columna «Change Controller». La página no registra una disputa ni una actualización causada por este borrador. Sirve para comprobar que un experto y un responsable del cambio pueden figurar por separado en una tabla real.

La sección 3.1.2 del borrador añade una salida para la vida diaria: salvo regla particular, el procedimiento de registro también rige la modificación. Si una entrada no nació de un RFC, IANA puede confirmar y aprobar cambios en el contacto o el controlador, y pedir consejo a expertos o directores de área. Esa facultad es útil cuando los datos antiguos ya no representan a nadie. Exige una huella documental para que la siguiente persona no confunda una reparación administrativa con una cesión de poder.

El texto sigue siendo un Internet-Draft de grupo de trabajo; el Datatracker marca su estado IESG como «I-D Exists». El RFC 8126 sigue vigente. Una aprobación final y las páginas IANA actualizadas mostrarían si la instrucción propuesta llegó a las tablas. Hoy la diferencia entre el proyecto y el registro JSONPath es la diferencia entre una promesa y un ejemplo que ya funciona.