Resumen

  • La respuesta del Consejo de ICANN del 21 de agosto descarta un plazo máximo fijo que pueda interferir con la revisión exigida por los Bylaws para recomendaciones de complejidad desigual. En su lugar, prevé una actualización antes de cada reunión pública de ICANN y un examen permanente en los talleres previos del Consejo.
  • Informar con frecuencia no conserva la ruta de la decisión. Un reloj entre recomendación y decisión debe registrar recepción, insumos, preguntas, responsables, cambios de previsión y disposición final por recomendación, sin atribuir autoridad decisoria a un enlace, un caucus, el personal o un diálogo con la GNSO.

El 7 de junio cambió el sentido de una carta que todavía no había recibido respuesta.

Dos semanas antes, el 25 de mayo, representantes de seis grupos y unidades constitutivas de la Generic Names Supporting Organization habían escrito a Tripti Sinha, presidenta del Consejo de ICANN. Señalaron que dos paquetes de recomendaciones llevaban un periodo prolongado bajo revisión y pidieron un marco temporal más claro.

La carta no ignoraba la regla existente. El Anexo A de los Bylaws dice que el Consejo debe reunirse para discutir una recomendación del GNSO Council tan pronto como sea factible, de preferencia no más tarde de la segunda reunión posterior a la recepción del Recommendations Report. El vacío está después de ese verbo: discutir no fija la fecha de conclusión.

Los firmantes sugirieron combinar un número objetivo de reuniones con un máximo de meses; seis meses figuraba como ejemplo, no como obligación vigente. También propusieron actualizaciones constantes, un lugar estable para el Consolidated Policy Scorecard y conversaciones con el GNSO Council y los responsables del Working Group cuando el Consejo necesitara aclarar el expediente.

Antes de que llegara la contestación, el Consejo actuó sobre los dos ejemplos. El 7 de junio adoptó las 47 recomendaciones del Transfer Policy Review y las 14 recomendaciones de política de IDN EPDP Phase 2. La respuesta del 21 de agosto, por tanto, ya no trataba de cómo resolver esos expedientes concretos. Trataba de qué regla utilizar en los siguientes.

Dos decisiones no eliminan el problema del tiempo

Las resoluciones de junio ordenaron al President and CEO, o a sus designados, implementar ambos paquetes, sujetos a priorización y a consideraciones operativas, técnicas, jurídicas, de seguridad o de recursos que aparezcan durante la implementación.

Los fundamentos reconocieron expresamente la inquietud de la comunidad sobre el tiempo y el proceso de la revisión. También enumeraron materiales considerados: Final Reports, Public Comment, análisis de viabilidad, notificación al GAC y documentación específica. El registro demuestra una decisión y parte de sus insumos. No ofrece todavía una secuencia pública normalizada que explique cada cambio de previsión durante los meses anteriores.

Hoy, la página de implementación de ICANN sitúa ambos proyectos en la implementation queue. Es una condición posterior a “pendiente de acción del Consejo”, pero anterior a una implementación comprobada. Estar en cola no prueba que exista una IRT, que se haya asignado capacidad, que haya comenzado la redacción ni que una nueva obligación contractual esté vigente.

Por eso importa conservar estados anteriores. La carta de mayo aislada queda desactualizada. La página de agosto aislada borra el problema anterior. La resolución del 7 de junio es la transición que permite leer correctamente las dos fotografías.

El Consejo eligió previsibilidad, no una fecha automática

En su carta del 21 de agosto, Tripti Sinha aceptó que la revisión de recomendaciones desarrolladas por la comunidad debe avanzar con rapidez. El Consejo, sin embargo, consideró inadecuado un límite final fijo. Las recomendaciones varían en naturaleza y complejidad, y una fecha uniforme podría interferir con la revisión requerida por los Bylaws.

La alternativa es “expected timing and status reporting”. El Consejo pretende informar antes de cada ICANN Public Meeting. También incluirá el estado del trabajo de política como punto permanente en sus talleres previos y seguirá revisando el ciclo con el GNSO Council y los grupos pertinentes.

Esa respuesta no equivale a prometer seis meses ni un dashboard con campos definidos. Tampoco es una negativa a la rendición de cuentas. Es una apuesta por una obligación periódica de explicar, en lugar de una obligación de concluir en una fecha.

El riesgo está en el nivel de detalle. “En revisión” puede significar que falta cerrar Public Comment, esperar una respuesta del GAC, completar un análisis de viabilidad, resolver una duda jurídica, encontrar espacio de agenda o asignar a una persona. Sin el motivo y el próximo acto, el mismo rótulo cubre deberes distintos.

La regla de la segunda reunión tiene un alcance limitado

No hay base para afirmar, a partir del calendario, que el Consejo incumplió los Bylaws. La disposición habla de reunirse para discutir y expresa una preferencia por la segunda reunión después de la recepción. No ordena aprobar o rechazar en ese momento. La evidencia pública examinada tampoco permite fechar cada deliberación ni saber cómo se contó “reunión” en cada expediente.

La estructura institucional explica parte de la cautela. Cuando una recomendación obtiene GNSO supermajority, el Consejo debe adoptarla salvo que más de dos tercios de los directores con derecho a voto determinen que no responde al interés superior de la ICANN community o de ICANN. Es una deferencia fuerte al trabajo ascendente, no una transferencia automática de la responsabilidad del Consejo.

Los directores deben poder evaluar legalidad, seguridad, viabilidad, recursos e interés público. Un vencimiento que produzca aprobación automática sería incompatible con esa función. Pero una revisión indefinida con estado genérico tampoco permite comprobar que la función se ejerce. La solución debe mostrar qué cuestión justifica el tiempo, no fingir que el tiempo carece de coste.

Preguntar antes sin crear una cámara de enmienda informal

La respuesta de agosto cita Board liaisons, diálogo proactivo y Board Caucus Groups. El informe Board Readiness de 2025 había encontrado una falla práctica: a menudo el Consejo empezaba su consideración meses después del Final Report, cuando el equipo del PDP ya se había disuelto y sus voluntarios habían vuelto a su actividad cotidiana.

La conversación temprana puede mejorar el expediente. Un enlace puede avisar de un posible problema de Bylaws, costes o ejecución mientras el Working Group aún puede explicar el equilibrio elegido. Un caucus organiza preguntas entre directores. El personal reúne los comentarios y la viabilidad. Los responsables del Working Group aclaran si una fórmula ambigua fue deliberada.

Pero aclarar no es modificar. El Board liaison no determina el consenso de la GNSO. Un informe del personal no reemplaza la recomendación. Una conversación bilateral no puede introducir silenciosamente una condición sustantiva. Si cambia el resultado normativo, el registro debe indicar quién tenía autoridad y si el asunto volvió al órgano de política.

La propia respuesta del Consejo lo formula: la interacción puede aclarar el expediente y hacer visibles las preguntas sin alterar los papeles respectivos del Consejo y del GNSO Council bajo los Bylaws. La rapidez pierde legitimidad si ya no puede identificarse al autor de la decisión.

El Scorecard necesita historial, no solo la última celda

ICANN org publica periódicamente el Consolidated Policy Scorecard para reunir información sobre políticas desarrolladas por la comunidad y otros resultados. Centralizar el estado es una mejora real. Evita obligar a cada lector a reconstruir una política entre cartas, actas, páginas de la GNSO y tablas de implementación.

Sin embargo, una celda actual responde “dónde”, no “cómo llegó”. Cuando un proyecto pasa a implementation queue, el nuevo estado no revela por sí solo cuándo se completó el expediente, qué pregunta fue material, por qué se revisó una fecha ni si el Consejo adoptó algunas recomendaciones y dejó otras pended.

Una razón pública acotada puede resolver buena parte del problema sin divulgar asesoramiento privilegiado. “Revisión jurídica”, “viabilidad técnica”, “análisis de recursos”, “insumo de política pública”, “aclaración solicitada” o “capacidad de agenda” identifica el tipo de dependencia. La información sensible puede permanecer protegida y su reserva revisarse más adelante.

Un reloj desde la recepción hasta la disposición

Daniel Kade propone que cada Recommendations Report abra un registro versionado. El primer evento guarda identidad y hash del paquete, voto del GNSO, vía de los Bylaws y umbral aplicable. Luego registra cuándo se abrió, cerró e incorporó cada insumo requerido: Public Comment, aviso al GAC, viabilidad y cualquier otra pieza nombrada.

El registro nombra al responsable de coordinación —liaison, caucus o personal— sin confundirlo con el Consejo que decide. Distingue primera discusión de deliberación sustantiva y de votación. La presencia en una reunión no se convierte en una conclusión implícita.

Los estados deben ser pocos y verificables: recibido, insumos pendientes, listo para deliberación, aclaración solicitada, decisión programada, adoptado, rechazado, pended, retirado o sustituido. Cada estado lleva fecha de evidencia, próximo acto, responsable y previsión. Si la previsión cambia, la anterior se conserva con la razón del cambio.

La disposición se guarda por recomendación, con voto, fundamento y condiciones. El traspaso posterior identifica el proyecto de implementación y mantiene separadas la cola y la puesta en marcha.

No es un mecanismo de aprobación por silencio. Un expediente complejo puede necesitar más de seis meses. La exigencia es otra: que la discreción deje una ruta pública proporcional, de forma que la comunidad no tenga que deducirla de informes corteses que sustituyen al anterior.

Fuentes

  1. Índice de correspondencia de ICANN
  2. Tripti Sinha a Mason Cole, Rafik Dammak y otros, 21 de agosto de 2026
  3. Owen Smigelski, Mason Cole y otros a Tripti Sinha, 25 de mayo de 2026
  4. Resoluciones aprobadas por el Consejo de ICANN, 7 de junio de 2026
  5. Bylaws actuales de ICANN
  6. Página de implementación de políticas de ICANN
  7. Informe final del GNSO Board Readiness Small Team
  8. Página del proyecto GNSO IDN EPDP
  9. Página del proyecto GNSO Transfer Policy Review