Resumen

La discusión sobre ICANN suele empezar con una falsa alternativa: o es una autoridad pública global o es apenas una organización privada sin capacidad coercitiva. Los instrumentos públicos muestran una arquitectura más incómoda. ICANN es una corporación de beneficio público de California cuya misión se formula alrededor de los sistemas de identificadores únicos de Internet. Su alcance se vuelve material cuando una política entra en una relación contractual, cuando un operador depende de una especificación incorporada, o cuando un actor técnico controla una etapa concreta de la publicación o mantenimiento de un recurso.

La investigación, por tanto, debe seguir la cadena de implementación. ¿Qué instrumento crea la capacidad? ¿Qué actor puede producir el efecto? ¿La persona afectada es parte del contrato? ¿Puede pedir que se detenga la ejecución, obtener una revisión vinculante o lograr que se repare el daño antes de que pierda valor práctico? Estas preguntas añaden una dimensión distinta a la cobertura previa sobre negativas de acceso a documentos, filtros para activar revisiones y transparencia de los expedientes. Aquellos trabajos examinaban cómo se explica una decisión o cómo llega un asunto a una revisión.

Este análisis sigue el paso posterior: cómo una decisión se convierte en una condición técnica o contractual y si el remedio alcanza el lugar donde ocurre el perjuicio.

1. La carta corporativa fija capacidad, no soberanía

Los Articles of Incorporation establecen a ICANN como una corporación californiana de beneficio público, no como una agencia gubernamental ni como una organización intergubernamental. Su propósito declarado incluye coordinar los sistemas globales de identificadores únicos y promover la estabilidad operativa de Internet. [https://www.icann.org/resources/pages/governance/articles-en]

Ese documento importa porque determina la forma jurídica y el propósito institucional. Pero una carta corporativa no es una ley de habilitación. No entrega por sí sola facultades para legislar, conceder licencias, imponer sanciones públicas o resolver controversias con autoridad estatal. El lenguaje de “interés público” puede explicar por qué existe la organización; no convierte automáticamente sus decisiones en actos de un regulador soberano.

La diferencia tiene consecuencias prácticas. Si ICANN actúa fuera de su propósito o de los límites que la rigen, el argumento no es necesariamente que una autoridad pública haya excedido una delegación administrativa. Puede ser que una corporación haya actuado más allá de su misión, de sus estatutos, de un contrato o de los procedimientos aplicables. La base de la impugnación y el remedio dependerán del instrumento que se alegue infringido.

Los estatutos de ICANN añaden una delimitación explícita. Describen una misión centrada en coordinar los sistemas de identificadores únicos y desarrollar políticas razonable y apropiadamente relacionadas con esas funciones. También afirman que ICANN no posee autoridad regulatoria conferida por un gobierno y que no debe regular servicios que utilicen identificadores de Internet ni el contenido transportado por esos servicios fuera de su misión definida. [https://www.icann.org/resources/pages/governance/bylaws-en]

Esto no significa que sus reglas carezcan de efectos regulatorios en la vida de los operadores. Una regla que condiciona la acreditación de un registrador, el funcionamiento de un registro o la continuidad de una relación contractual puede tener efectos económicos y operativos amplios. La cuestión jurídica y analítica es otra: esos efectos nacen de una delegación pública o del poder privado de contratar, acreditar, incorporar políticas y hacer valer condiciones de cumplimiento.

2. La política se vuelve operativa cuando cruza una frontera contractual

La elaboración de políticas no es el mismo acto que su ejecución. Una propuesta puede surgir de procesos de las organizaciones de apoyo y comités asesores, ser aprobada mediante los procedimientos corporativos de ICANN y después aparecer en un acuerdo de registro, un acuerdo de acreditación o una especificación incorporada. El efecto que percibe el operador depende de esa última conexión.

Los repositorios de acuerdos de registros y registradores muestran una arquitectura de instrumentos específicos por dominio, enmiendas, especificaciones y políticas incorporadas. Esos documentos cubren, entre otros asuntos, operación técnica, custodia de datos, servicios de datos de registro, contactos de abuso, tarifas, auditorías, cumplimiento, incumplimiento y terminación. [https://www.icann.org/resources/pages/registries/registries-agreements-en] [https://www.icann.org/en/registry-agreements/base-agreement] [https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en] [https://www.icann.org/resources/pages/registrars/consensus-policies-en]

La cadena causal puede expresarse así:

  1. una comunidad formula una política dentro de un proceso de ICANN;
  2. el órgano competente la adopta o la incorpora al marco aplicable;
  3. el texto aparece en un contrato, una especificación o una obligación de acreditación;
  4. un equipo de cumplimiento identifica una infracción o una falta de ejecución;
  5. el operador recibe una exigencia, una notificación o una amenaza de consecuencia;
  6. el contrato determina si existe subsanación, suspensión, terminación, auditoría o una vía de disputa.

La capacidad que importa en el último paso no es abstracta. Es la capacidad de enviar una notificación, exigir una corrección, condicionar una autorización o iniciar una terminación. En ese punto, la forma privada del acuerdo puede producir una presión comparable a la regulación para la empresa que necesita conservar acceso al sistema coordinado. Sin embargo, la analogía tiene límites: la obligación, su alcance y su remedio dependen del acuerdo y de la ley aplicable, no de una potestad general sobre todos los servicios de Internet.

También hay límites materiales. El repositorio no demuestra que un único contrato gobierne todos los dominios de nivel superior. Los dominios de código de país pueden operar bajo arreglos diferentes. Por eso, decir “ICANN regula los dominios” oculta la pregunta relevante: ¿qué entidad, bajo qué documento y con qué mecanismo puede afectar este dominio, este registrador o este operador?

3. La transición de 2016 distribuyó el control técnico

La antigua relación con la administración estadounidense muestra que el papel de ICANN no siempre tuvo la misma base. El contrato de funciones IANA anterior a 2016 situaba el papel de ICANN dentro de un marco de contratación y supervisión del gobierno de Estados Unidos, incluidas responsabilidades relacionadas con la gestión de la zona raíz. [https://www.icann.org/en/system/files/files/contract-01oct12-en.pdf] Ese instrumento es evidencia histórica. No establece por sí solo la autoridad actual de ICANN después de la transición.

La propuesta de transición de 2016 describió un arreglo distribuido, no una transferencia de soberanía sin condiciones a ICANN. Incluyó a Public Technical Identifiers, un contrato entre ICANN y PTI para la función de nombres, la supervisión del Customer Standing Committee, revisiones de la función de nombres y una posible separación. También mantuvo arreglos diferenciados con los registros regionales de Internet y con la comunidad del IETF. [https://www.icann.org/en/system/files/files/iana-stewardship-transition-proposal-10mar16-en.pdf]

El contrato ICANN-PTI define servicios operativos, obligaciones de desempeño, informes, niveles de servicio y escalamiento para la función de nombres. [https://www.icann.org/iana_pti_docs/151-iana-naming-function-contract-v-30sep2016] PTI es una afiliada controlada por ICANN, de modo que no se trata simplemente de una externalización entre partes independientes. Aun así, el instrumento ayuda a separar dos cuestiones: la capacidad corporativa de ICANN para organizar su función y la ejecución concreta de tareas según obligaciones de servicio verificables.

El acuerdo de mantenimiento de la zona raíz divide responsabilidades técnicas entre ICANN o PTI y Verisign. Incluye niveles de servicio, control de cambios, seguridad, desempeño y remedios contractuales. [https://www.icann.org/en/system/files/files/root-zone-maintainer-service-agreement-30sep16-en.pdf] La zona raíz, por tanto, no aparece como una palanca única bajo control indiferenciado de ICANN. Hay una cadena operacional en la que distintos participantes pueden causar, bloquear, retrasar o corregir una acción concreta.

La misma lógica se observa en la numeración. El acuerdo de nivel de servicio para los servicios de numeración IANA sitúa esos servicios dentro de una relación contractual con ICANN y los registros regionales de Internet, mientras que el sistema de políticas de los RIR aporta la capa de elaboración de políticas. [https://www.icann.org/en/system/files/files/iana-numbering-services-sla-30jun16-en.pdf] Esto no significa que ICANN decida unilateralmente todas las asignaciones de números. El instrumento se refiere a los servicios IANA y no sustituye los procesos de cada RIR.

En los parámetros de protocolo, el memorando entre IETF e ICANN sitúa la política dentro de los procesos del IETF y el trabajo de registro correspondiente como un servicio técnico de IANA. [https://www.icann.org/resources/pages/ietf-icann-mou-2012-02-25-en] Esa separación es fundamental: una comunidad puede desarrollar una política y otra organización puede ejecutar el registro conforme a ella. Confundir esas funciones atribuye a ICANN un poder de decisión que el arreglo no necesariamente le concede.

4. El control real se encuentra en el punto de ejecución

Un marco de autoridad útil debe identificar cinco capacidades distintas: causar una consecuencia, bloquearla, condicionarla, retrasarla y repararla. Un órgano puede aprobar una política sin controlar la operación diaria. Un contratista puede ejecutar una tarea sin tener capacidad para modificar la política. Un comité puede supervisar un nivel de servicio sin poder ordenar por sí mismo una indemnización o revertir un registro.

Por eso conviene reconstruir cada caso con una tabla de control:

Pregunta Lo que debe establecerse
¿Qué se decidió? La política, resolución, especificación o instrucción concreta.
¿Qué instrumento la vuelve exigible? Estatutos, contrato, acreditación, SLA, procedimiento o ley aplicable.
¿Quién ejecuta? ICANN, PTI, un registro, un registrador, Verisign, un RIR, IANA u otro actor.
¿Qué efecto se produce? Suspensión, transferencia, bloqueo, cambio técnico, publicación, retirada o terminación.
¿Quién puede impugnar? Parte contractual, comunidad, miembro, solicitante, tercero afectado u otro sujeto con legitimación.
¿Qué remedio llega al punto de control? Revisión, orden vinculante, suspensión, reparación, nueva decisión o solo recomendación.

La última fila es la más débil en el paquete actual. ICANN publica materiales sobre cumplimiento, Reconsideration, el Independent Review Process, el Ombudsman, el Empowered Community, el Customer Standing Committee y las revisiones de IANA. [https://www.icann.org/compliance] [https://www.icann.org/resources/pages/accountability/reconsideration-en] [https://www.icann.org/resources/pages/irp-2012-02-25-en] [https://www.icann.org/en/system/files/files/irp-supp-procedures-25oct18-en.pdf] [https://www.icann.org/ombudsman] [https://www.icann.org/resources/pages/empowered-community-2017-03-23-en] [https://www.icann.org/csc] Pero la documentación reunida no permite afirmar que todos esos canales tengan la misma legitimación, admisibilidad, estándar de revisión, capacidad de medidas provisionales, fuerza vinculante, alcance reparador, velocidad o coste.

Una vía que explica una decisión no necesariamente puede detenerla. Una revisión que declara que el Board actuó de forma inconsistente con los estatutos no necesariamente puede obligar a un registrador independiente a deshacer una acción ya ejecutada. Un mecanismo de supervisión técnica puede identificar una degradación del servicio sin tener facultad para resolver una disputa contractual de un tercero.

La diferencia entre revisión y reparación es, por ello, central. El afectado puede obtener una respuesta y aun así perder el recurso, el nombre de dominio, el acceso operativo o la oportunidad comercial antes de que termine la revisión. La pregunta de legitimidad no se agota en si existe un foro. Hay que preguntar si ese foro puede llegar a la decisión ejecutiva, si puede ofrecer una medida a tiempo y si el resultado obliga al actor que controla la consecuencia.

5. El problema del tercero no contractual

La arquitectura contractual funciona con más claridad para una parte del contrato. Un registrador puede invocar cláusulas, plazos y procedimientos previstos en su acuerdo con ICANN. Pero muchos efectos repercuten sobre personas que no son partes directas del acuerdo institucional. Un registrante puede sufrir la suspensión o transferencia de un nombre; un proveedor puede depender de una condición de acreditación; un usuario puede verse afectado por una decisión técnica sin tener una relación contractual con ICANN.

Ese tercero puede tener una vía de reclamación, pero su naturaleza no debe presumirse. Puede depender del contrato del registrador, de una política de consenso, de un procedimiento administrativo, de la jurisdicción judicial o de reglas específicas del sistema de nombres. También puede ocurrir que el tercero solo tenga una vía indirecta: convencer a la contraparte contractual de impugnar, buscar una revisión corporativa o acudir a un tribunal con una teoría jurídica distinta.

Aquí aparece la pregunta que la cobertura anterior sobre los filtros de revisión aún no resolvía: ¿puede el mecanismo de accountability alcanzar la acción contractual o técnica que ya produjo el daño cuando quien pide remedio no es la contraparte de ICANN? Si la respuesta es no, el sistema puede ser formalmente revisable y materialmente difícil de corregir.

No debe concluirse de antemano que todo tercero carece de remedio. El punto es exigir precisión. La legitimación, el plazo, la carga de la prueba, la posibilidad de medidas provisionales y el efecto de la decisión deben establecerse para el mecanismo concreto. Las etiquetas generales —“accountability”, “review” o “ombudsman”— no sustituyen ese análisis.

6. Qué significa que ICANN tenga efectos regulatorios

Describir efectos regulatorios no equivale a afirmar autoridad pública. Un acuerdo privado puede producir consecuencias amplias porque el sistema coordinado es difícil de abandonar y porque una organización puede condicionar la continuidad de una relación comercial o técnica. Esa capacidad puede ser de facto poderosa aunque no sea una potestad legislativa.

Los propios estatutos ofrecen el punto de partida para mantener separadas ambas ideas: ICANN afirma límites a su autoridad regulatoria y a su capacidad para regular servicios y contenido fuera de su misión. [https://www.icann.org/resources/pages/governance/bylaws-en] Los contratos, por su parte, muestran cómo una política puede ser exigible dentro de relaciones definidas. [https://www.icann.org/resources/pages/registries/registries-agreements-en] [https://www.icann.org/resources/pages/registrars/consensus-policies-en] La transición técnica muestra que la ejecución también se distribuye entre afiliadas, contratistas, RIR y la comunidad de protocolos. [https://www.icann.org/en/system/files/files/iana-stewardship-transition-proposal-10mar16-en.pdf] [https://www.icann.org/en/system/files/files/iana-numbering-services-sla-30jun16-en.pdf] [https://www.icann.org/resources/pages/ietf-icann-mou-2012-02-25-en]

La formulación más exacta es, por tanto, que ICANN ejerce una combinación de capacidad corporativa, coordinación multistakeholder, influencia contractual y control o supervisión de determinadas interfaces técnicas. En algunos contextos esa combinación puede tener un efecto regulatorio de hecho. El material reunido no incluye todavía una ley independiente, una delegación normativa, una decisión judicial o un análisis externo que resuelva de manera general si una actuación concreta constituye autoridad pública o poder privado.

Esa cautela no reduce la importancia del asunto. Para un operador, la distinción doctrinal no elimina una dependencia real. Pero sí determina qué argumento puede prosperar, contra quién debe dirigirse, qué foro tiene competencia y qué remedio puede ejecutarse.

7. La prueba pendiente: reconstruir una decisión completa

El paquete actual identifica los instrumentos y las capas, pero todavía no contiene un caso completo que siga una política desde la propuesta hasta la ejecución, la impugnación y la reparación. Ese es el siguiente test empírico.

Una investigación de caso debería seleccionar una política concreta y documentar:

  • quién la propuso y mediante qué proceso;
  • qué órgano la adoptó y bajo qué autoridad estatutaria;
  • en qué contrato, especificación o procedimiento apareció;
  • qué actor recibió la obligación de ejecutarla;
  • qué aviso, incumplimiento o acción técnica activó la consecuencia;
  • si el afectado era parte contractual o un tercero;
  • qué revisión se solicitó y dentro de qué plazo;
  • si existió una suspensión o medida provisional;
  • qué actor podía revertir o reparar el efecto;
  • y si el resultado final fue vinculante y ejecutable.

Sin esa reconstrucción, es posible describir la arquitectura pero no medir su desempeño. La principal incertidumbre no es solo si ICANN tiene poder, sino si el sistema permite transformar una objeción válida en una corrección oportuna en el lugar donde se produjo el efecto.

Conclusión

La autoridad de ICANN no es un bloque único transferido por un documento fundador. Su alcance práctico se arma mediante una misión corporativa, estatutos, procesos comunitarios, contratos, acuerdos técnicos y mecanismos diferenciados de revisión. Cada capa responde una pregunta distinta y deja a otro actor en posición de causar, bloquear, condicionar o reparar una consecuencia.

La distinción entre coordinación privada y regulación pública sigue siendo necesaria. También lo es reconocer que el poder contractual y técnico puede producir efectos amplios sin convertirse por ello en soberanía. La evaluación de legitimidad debe llegar más lejos que el texto de una política: debe identificar el instrumento que la vuelve operativa, el actor que controla su ejecución y el remedio que puede alcanzarlo.

La cuestión aún abierta es concreta: cuando una decisión de ICANN se convierte en una acción contractual o técnica que afecta a alguien sin ser contraparte directa, ¿puede un revisor detenerla o corregirla a tiempo, mediante una decisión vinculante y exigible? Hasta que una investigación de caso responda esa pregunta, la arquitectura de accountability estará descrita, pero su capacidad reparadora seguirá sin demostrarse.

Fuentes