Resumen

  • El RFC 8126 fija diez políticas de registro para los registros de parámetros gestionados por la IANA; en dos de ellas, Private Use y Experimental Use, la IANA no registra valor alguno.
  • La impugnación corre con reloj fijo: la apelación debe iniciarse dentro de los dos meses siguientes al conocimiento público. La decisión corre con reloj abierto: un «periodo razonable» sin plazo universal, y la previsibilidad definida como ausencia de pasos inesperados, no como un número de días prometido.
  • La IAB puede anular una decisión de la IESG y restaurar la situación anterior, pero no puede tomar decisiones reservadas a la IESG, y ninguna disposición revisada la faculta expresamente para ordenar el registro. La IESG es el órgano que nombra, y puede remover a su discreción, al experto cuyo criterio se impugna.

Empiece por una solicitud, no por un principio. Alguien quiere que un valor quede inscrito en un registro de parámetros de protocolo gestionado por la IANA. El registro, los nombres de campo y la política aplicable son tres cosas distintas, y la propia guía de la IANA, con fecha de revisión visible del 13 de julio de 2026, lo dice sin rodeos: distintos rangos de un mismo registro pueden usar procedimientos de registro diferentes, de modo que nombrar el registro no equivale a nombrar la regla (IANA, Guidance for RFC Authors). La misma página pide identificar el registro exacto y aportar la información de campo exigida, y advierte que el RFC de referencia del registro puede requerir una plantilla con campos que la visualización del registro nunca muestra.

Quién decide de verdad lo fija el instrumento, no la costumbre. El RFC 8722, documento informativo de la IAB publicado en febrero de 2020, sitúa el trabajo del operador del registro en inscribir parámetros según criterios y procedimientos definidos por RFC y según la política de registro aplicable, con las ambigüedades remitidas para aclaración (RFC 8722, §2.1). El mismo documento retira la valoración técnica de los hombros del operador: «the Registry Operator will seek and follow technical guidance exclusively from the IESG», y la evaluación técnica no es, en general, responsabilidad suya (RFC 8722, §2.3). El nombramiento o la terminación de la organización operadora del registro corresponde a la IAB junto con la IETF LLC, un acto distinto del nombramiento de expertos individuales (RFC 8722, §2.2).

El menú de políticas es un conjunto cerrado de diez. El RFC 8126, publicado en junio de 2017, enumera Private Use, Experimental Use, Hierarchical Allocation, First Come First Served, Expert Review, Specification Required, RFC Required, IETF Review, Standards Action e IESG Approval (RFC 8126, §§4.1–4.10). Dos de esas categorías callan por diseño: los valores de Private Use y Experimental Use no los registra la IANA en absoluto. Specification Required añade a Expert Review una exigencia documental: una especificación permanente, públicamente recuperable, clara y técnicamente sólida, suficiente para permitir interoperabilidad independiente, no necesariamente un RFC (RFC 8126, §4.6).

Donde el experto cuenta con criterios publicados, los aplica. Donde el registro no los tiene, el RFC 8126 le pide valorar la completitud de la documentación, la interoperabilidad y los conflictos, y presumir la concesión salvo objeción contundente (RFC 8126, §§5.1–5.3). La denegación tiene motivos nombrados —escasez del recurso, documentación poco clara, efectos arquitectónicos o de despliegue dañinos, conflictos dañinos con el trabajo de la IETF— y no figura ningún otro (RFC 8126, §5.3).

Ahora el reloj. El RFC 2026, de octubre de 1996 y todavía la red procedural de fondo, lo escribe y lo sostiene: «All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged» (RFC 2026, §6.5.4). La misma sección obliga a quien decide a seguir el procedimiento, le exige decidir y comunicar en un periodo razonable, y no ofrece ningún plazo fijo universal. Los principios de la IAB para la operación de los registros de la IANA dicen lo mismo en otro registro: un procesamiento predecible consiste en evitar pasos inesperados, no en garantizar que las decisiones de los expertos lleguen en un número de días predeterminado (RFC 8720, §3.1). Lea esas dos disposiciones juntas y aparece una asimetría aparente: la parte con agravio está cronometrada; la parte con la pluma no recibe ninguna cifra. Que la redacción sea deliberada no queda establecido aquí.

La escala arranca donde ocurrió el rechazo. El RFC 8126 encamina una impugnación de una decisión de registro hacia la IESG y luego hacia la IAB, y aplica a las disputas con equipos de expertos el procedimiento del RFC 2026 §6.5.1 (RFC 8126, §10). Ese procedimiento incorporado pasa por los presidentes de grupos de trabajo, luego por los directores de área responsables, luego por la IESG completa y luego por la IAB, con cada órgano obligado a revisar e intentar resolver, y con la IAB como instancia final en cumplimiento procedimental y mérito técnico (RFC 2026, §6.5.1). Cuando se constata un fallo de procedimiento, la IESG reexamina su acción e informa a la IETF; la IAB puede anular la decisión de la IESG y restaurar la situación anterior, o recomendar una acción, pero no puede tomar decisiones reservadas a la IESG (RFC 2026, §6.5.2).

Esa última cláusula pesa más de lo que su longitud sugiere, y la conclusión que aquí se extrae es lectura de este artículo, no una frase que escriba ninguno de los dos documentos: si el desenlace más fuerte identificado en la escala revisada es una anulación que restaura la situación anterior, y esa cima no puede tomar decisiones reservadas a la IESG, entonces las disposiciones revisadas no confieren expresamente la potestad de ordenar que el registro se practique. Eso deja abiertas una recomendación, una anulación seguida de reexamen, o una vía propia del caso hacia un registro posterior. Anular no es ordenar.

Un solicitante puede ganar el argumento sin que la apelación misma inscriba el valor.

Un hecho estructural más, y es el que conviene clavar sobre el escritorio. El RFC 8126 §5.2.1 dice, palabra por palabra, que «The IESG may remove any designated expert that it appointed, at its discretion», y la misma sección describe a la IESG nombrando y reemplazando expertos de los registros de la IETF, normalmente a recomendación de un director de área (RFC 8126, §5.2.1). La sección 10 envía la impugnación a ese mismo órgano en primera instancia. Ninguno de los dos documentos reconcilia el papel de nombramiento con el papel de apelación, y en las disposiciones revisadas no se enuncia separación alguna entre ambos. El primer escalón institucional nombrado en la cadena es el órgano que nombra al experto: la vía del §10 pasa por los presidentes de grupos de trabajo y los directores de área responsables antes de la IESG completa, y quién escucha una apelación concreta, y si actúan las mismas personas, no queda establecido aquí.

Otras disposiciones suavizan los bordes sin cambiar la forma. La IESG puede, de manera excepcional, pasar por encima de los procedimientos de registro caso por caso (RFC 8126, §3.3). Los retrasos repetidos e inexplicados en la revisión del experto obligan a la IANA a escalar el asunto a la IESG, que debe corregir la situación o reemplazar al experto (RFC 8126, §5.3): un remedio dirigido al retraso, no al valor solicitado. Y el principio de transparencia es explícito: «the recommendations by designated experts must be visible to the public to the maximum extent possible and subject to challenge or appeal» (RFC 8720, §3.3). La visibilidad está prometida. Una fecha de decisión, no.

El expediente en torno al instrumento está vivo y en movimiento. El RFC 9907, de marzo de 2026, actualiza el RFC 8126 y deja obsoleto el RFC 8407, exigiendo instrucciones que conecten los cambios de un registro autoritativo con el mantenimiento del módulo YANG mantenido por la IANA correspondiente, con los valores nuevos en el registro y no añadidos directamente al módulo (RFC 9907). El archivo de erratas muestra lo que la comunidad ya intentó: la errata técnica 6522, rechazada el 8 de abril de 2021, habría permitido expresamente que versiones fechadas de Internet-Draft satisficieran el criterio documental del §4.6, y el verificador la trató como propuesta de política que requiere discusión y consenso, no como corrección de un error; la errata editorial 5772, retenida para actualización del documento el 3 de julio de 2019, se refiere a una mención de agradecimientos y a nada más (erratas del RFC 8126). Ese rechazo registra la negativa a una redacción propuesta. No establece que ningún Internet-Draft haya sido jamás aceptado en la práctica bajo las reglas de ningún registro, y el §4.6 tal como está escrito no incluye los Internet-Drafts entre las formas aceptables.

Existe un texto de reemplazo y no está en vigor. El draft-ietf-ianabis-rfc8126bis-05 se publicó el 2 de noviembre de 2026; su resumen dice que deja obsoleto el RFC 8126, mientras su propia cabecera condiciona eso a la aprobación y su estado lo identifica como Internet-Draft, es decir, trabajo en curso (draft-ietf-ianabis-rfc8126bis-05). El RFC 8126 se lee aquí como el texto operativo; el reemplazo queda registrado como condicional, no como una sustitución consumada.

Tres límites van junto a las afirmaciones, no al final del texto. No se examinó ninguna solicitud de registro real, ni rechazo, ni presentación de apelación, ni resolución: todo lo anterior describe el marco publicado, no cómo se trató una solicitud concreta. No se estableció qué políticas obligan a un registro determinado —un mismo registro puede llevar varias—. No se obtuvo el manejo interno de una apelación por parte de la IESG, ni historial no publicado de apelaciones pasadas.

Un límite de búsqueda, dicho una vez: tres intentos de investigación sobre la clase de instrumentos de la función de nombres de la IANA fallaron en el proveedor antes de cerrar esa línea, y el contrato de la función de nombres, la carta del Customer Standing Committee y el informe de la Naming Function Review siguen sin leerse en esta revisión. Es una laguna en la búsqueda de esta mesa. No es una conclusión sobre esos documentos.

¿Qué cambiaría la lectura? Una resolución de apelación publicada que termine con un valor inscrito bajo la dirección de la IAB y no de la IESG, o un registro que escriba sus propios criterios y convierta así una concesión presunta en una prueba verificable. Hasta que aparezca una de las dos, el resumen honesto para quien se apoya en una entrada de registro de la IANA es más estrecho de lo que parece: el marco publica la norma, publica la promesa de transparencia, y entrega el calendario y la última palabra a las mismas pocas personas.