Resumen

  • Los Procedimientos Operativos de la GNSO v3.8, fechados el 1 de septiembre de 2026, incorporan un proceso de reversión aprobado por el Consejo de la GNSO el 21 de mayo. Solo sirve en circunstancias limitadas y extraordinarias antes de que concluya la implementación; no hay constancia de que esté en uso.
  • La Junta debería dialogar con el Consejo de la GNSO durante tiempo suficiente —unos 60 días es solo un ejemplo—, pero la primera declaración pública obligatoria llega después de que actúa. El texto final no exige consulta pública previa ni intervención de un Equipo de Revisión de la Implementación.

Una recomendación puede estar en un terreno incómodo: adoptada, pero todavía no plenamente operativa. Hay contratos en análisis, sistemas en construcción, preguntas abiertas en un IRT y empresas que ya planifican sobre la decisión. Aparece entonces información nueva. La Junta considera que la recomendación ya no sirve al interés de ICANN o de su comunidad y estudia retirar la adopción anterior.

La cuestión no es si una institución puede rectificar. La cuestión es cuándo quienes soportan las consecuencias pueden ver y disputar la evidencia que convierte una preocupación en una actuación. La nueva regla prevé una conversación previa con el Consejo de la GNSO y exige que la Junta explique públicamente la reversión. Pero entre ambas fases está la primera decisión, sin obligación de abrir antes un expediente probatorio.

Esa es la frontera de control que muestra la versión 3.8 de los Procedimientos Operativos de la GNSO. Haber cerrado un vacío es valioso. Publicar los motivos después del acto no equivale, no obstante, a permitir que la evidencia sea corregida antes de él.

Tres fechas que no deben fundirse

La página de procedimientos de la GNSO, actualizada el 2 de septiembre, presenta la versión 3.8 con fecha 1 de septiembre. El historial de versiones dice que el documento consolidado incorpora el Anexo 2, Manual del PDP, y el Anexo 5, Manual del GGP, aprobados el 21 de mayo de 2026. Los documentos independientes están fechados el 11 de mayo. Las demás revisiones de v3.8 se describen como administrativas y editoriales.

Por tanto, la resolución del 21 de mayo es la decisión de aprobación. Septiembre es el momento de consolidación y publicación. Ninguna fecha demuestra que la regla se haya activado. Las fuentes revisadas no nombran una recomendación que esté atravesando hoy este proceso.

El informe de la sesión estratégica de 2025 explica el antecedente. La Junta había encontrado problemas en recomendaciones ya adoptadas, entre ellas la 20.6 del programa de nuevos gTLD, sin un mecanismo específico para revertir. Ese episodio motivó el diseño; este artículo no reabre sus méritos ni lo presenta como una aplicación de v3.8.

Cómo funciona la secuencia

La sección 16 del Manual del PDP y la sección 10 del Manual del GGP comparten casi todo el diseño. La reversión se reserva a circunstancias limitadas y extraordinarias. Puede considerarse cuando la Junta adoptó una recomendación y su implementación todavía no ha concluido. Deja de estar disponible cuando la recomendación ya fue implementada y está en vigor.

Antes de actuar, la Junta debería dialogar con el Consejo de la GNSO. Como mínimo debe comunicar la intención, detallar el problema, exponer motivos e impacto y explicar por qué revertir es la única o la mejor salida. El Consejo de la GNSO debe tener tiempo suficiente para estudiar la cuestión y pedir aclaraciones. El ejemplo de 60 días orienta, pero no establece un plazo fijo.

La prueba sustantiva tiene dos componentes. Debe existir información nueva o un cambio de circunstancias. Además, la Junta debe concluir que la recomendación dejó de beneficiar a ICANN o a su comunidad. Una novedad sin efecto institucional no basta; tampoco basta invocar el interés general sin mostrar qué cambió.

El umbral del voto depende del apoyo original. Si la recomendación fue aprobada con Supermayoría de la GNSO, la reversión requiere dos tercios de la Junta. Si el apoyo fue inferior, basta la mayoría de la Junta.

Al ejecutar la acción, la Junta debe explicar su determinación en una Board Statement enviada al Consejo de la GNSO. La declaración y cualquier documento adjunto deben publicarse. El Consejo de la GNSO la revisa después, dialoga con la Junta y se reúne para confirmar o modificar la recomendación. Esa Recomendación Suplementaria vuelve a la Junta bajo umbrales que también reflejan el grado de apoyo de la GNSO.

No es un punto final unilateral: la GNSO conserva una respuesta formal. La debilidad precisa está en el momento de apertura. El primer artefacto necesariamente público aparece después de la primera actuación de la Junta.

Lo que pidió la consulta y no quedó como obligación

La consulta pública estuvo abierta entre el 20 de noviembre de 2025 y el 22 de enero de 2026, con diez aportaciones. El informe de síntesis registra un apoyo amplio a un mecanismo raro y protegido por salvaguardias.

El proceso sí absorbió cambios. Los participantes pidieron que la Junta “debería” seguirlo, en lugar de decir que “podría” hacerlo, y esa es la formulación final. También propusieron añadir el cambio de circunstancias a la información nueva, y el texto adoptado contiene ambos supuestos.

Otras peticiones no se convirtieron en pasos forzosos. Varios comentarios solicitaron un periodo breve de consulta pública o comunitaria antes de cerrar la reversión. Los grupos de registradores y registros, junto con Tucows, respaldaron una consulta obligatoria con el IRT correspondiente. Los registros propusieron además oír, cuando fuera posible, al grupo de trabajo original. Los manuales no imponen ninguna de esas consultas.

No se sigue de ello que un caso vaya a ser secreto. Los consejeros pueden consultar a sus comunidades, la Junta puede publicar documentos pronto y ambos órganos pueden acudir al IRT. La afirmación verificable es más limitada: esas aperturas son opciones, no requisitos para la primera actuación.

Una frontera de implementación sin custodio nombrado

La regla de elegibilidad parece clara: implementación “no concluida” frente a recomendación “implementada y en vigor”. Un programa real rara vez cambia de estado de una sola vez. Puede haber texto contractual completo y software incompleto, una fecha efectiva con migración pendiente, preguntas del IRT sin cerrar o aplicación aplazada. Una recomendación también puede formar parte de un paquete con dependencias que no se pretende revertir.

Los manuales no nombran a la persona u órgano que certifica esa frontera, ni exigen un documento de certificación o un conjunto mínimo de pruebas. Es una omisión del texto, no una afirmación de que ICANN carezca de trabajo interno. Aun así, importa porque clasificar el estado decide si el remedio excepcional está disponible.

Marcar demasiado pronto “en vigor” puede cerrar la vía cuando una evidencia nueva justificaría examinarla. Mantener demasiado tiempo “no concluida” puede permitir una reversión después de que registros, registradores, solicitantes o usuarios hayan confiado razonablemente en la política. La Board Statement posterior deja constancia de la clasificación escogida; no ofrece una oportunidad garantizada para corregirla antes del voto.

Un expediente público antes de la primera actuación

Falta un expediente de reversión acotado, versionado y público antes de la primera decisión. No tiene por qué ser una consulta interminable ni exponer asesoramiento protegido. Debe mostrar qué autoridad se ejerce y con qué pruebas mientras la decisión todavía puede cambiar.

El expediente debería identificar el aviso inicial, las recomendaciones incluidas, sus dependencias, la adopción original y su umbral, la fase de implementación y el custodio que la certifica. Esa certificación debería enlazar una instantánea fechada de evidencias, no una mera etiqueta.

También debería preservar la información nueva o el cambio de circunstancias, su procedencia, el impacto alegado y las alternativas evaluadas. Las preguntas de la Junta y las respuestas de la GNSO necesitan versiones estables. Un canal con fecha de cierre permitiría al IRT, al grupo de trabajo y a la comunidad aportar evidencia pertinente. Si algún material debe protegerse, el registro público aún puede indicar su existencia, custodio y efecto sobre la decisión.

Después del acto, el mismo expediente incorporaría el voto, la Board Statement, la discusión, la Recomendación Suplementaria y la resolución final. Las correcciones se añadirían con trazabilidad; no sustituirían en silencio el conjunto usado para decidir.

Este expediente es una propuesta editorial propia, no un compromiso de ICANN. Aplica el mapa de autoridad de The Policy Mirror, la ejecución observable de Running-Code Primacy y la separación entre hechos y relato institucional de Reality, Not Advocacy.

La nueva regla reconoce correctamente que una adopción no puede borrar la información posterior. El siguiente paso es no confundir transparencia después de actuar con capacidad de disputar la evidencia antes de actuar.

Fuentes