Resumen

  • La autoridad práctica de ICANN se distribuye entre sus Articles of Incorporation, los Bylaws, los arreglos de rendición de cuentas y los contratos que vinculan a registros y registradores.
  • Los recursos no son equivalentes: la reconsideración examina ciertos actos u omisiones frente a políticas, estatutos o procedimientos; el Independent Review Process se ocupa de determinadas alegaciones de inconsistencia con los Articles o los Bylaws; y los poderes de la Empowered Community operan sobre decisiones institucionales específicas.

La afirmación de que ICANN “controla” una parte de Internet necesita una precisión institucional. ICANN es una corporación californiana sin ánimo de lucro de beneficio público. Sus Articles of Incorporation describen, entre otros fines, la coordinación de los sistemas mundiales de identificadores de Internet y funciones técnicas relacionadas, mientras que sus Bylaws establecen misión, valores fundamentales, estructura del Board, procesos de desarrollo de políticas, mecanismos de rendición de cuentas y límites para el ejercicio de su autoridad. Ninguno de esos instrumentos, por sí solo, convierte a ICANN en un regulador público general. Juntos, sin embargo, organizan una institución capaz de producir efectos concretos dentro de un ecosistema contractual.[https://www.icann.org/resources/pages/governance/articles-en] [https://www.icann.org/resources/pages/governance/bylaws-en]

La cadena causal comienza con el mandato constitutivo. Los Articles de ICANN definen la forma corporativa y sus propósitos; los Bylaws detallan cómo se ejerce el gobierno interno y qué procedimientos pueden cuestionar una actuación. La documentación sobre la transición de la custodia de las funciones IANA describe el paso desde el marco contractual anterior del Gobierno estadounidense hacia arreglos de rendición de cuentas desarrollados por la comunidad, y distingue las funciones de ICANN, Public Technical Identifiers y la comunidad mundial. Esa documentación es explicativa, no el contrato operativo completo, pero ayuda a identificar por qué la autoridad posterior a la transición no debe describirse como una simple delegación gubernamental.[https://www.icann.org/resources/pages/iana-transition-2016-06-03-en]

El segundo eslabón es la política institucional. Los Bylaws proporcionan el marco para los procesos de desarrollo de políticas y para la estructura del Board, pero una política no se vuelve automáticamente una orden aplicable a cualquier actor de Internet. La transformación ocurre cuando una obligación entra en una relación contractual o en un procedimiento operativo reconocido por los participantes. La propia colección de acuerdos de ICANN identifica instrumentos para registros, registradores, operadores técnicos y otros participantes, y describe compromisos contractuales, cumplimiento, auditoría, controversias y posibles sanciones o terminación. La página de acuerdos es una puerta de entrada al repositorio; para una disputa concreta, el documento ejecutado y su versión temporal serían determinantes.[https://www.icann.org/resources/pages/agreements-2012-02-25-en]

Los acuerdos de registro muestran esa conversión con mayor nitidez. Los registry agreements establecen responsabilidades delegadas, requisitos técnicos, informes, cumplimiento y obligaciones relacionadas con controversias. El acuerdo base de 30 de junio de 2017 incluye, según la documentación publicada, operación del registro, cumplimiento técnico y normativo, custodia de datos, informes, auditoría e inspección, tarifas, resolución de disputas y remedios contractuales. La consecuencia analítica es importante: ICANN no necesita una potestad pública general para influir sobre la operación de un registro. Puede hacerlo mediante las condiciones que el operador aceptó al entrar en el sistema contractual, aunque el alcance exacto dependa del acuerdo y de sus enmiendas.[https://www.icann.org/resources/pages/registry-agreements-en] [https://www.icann.org/resources/pages/registry-agreement-2017-06-30-en]

La misma lógica se aplica a los registradores. El Registrar Accreditation Agreement publicado el 17 de septiembre de 2013 fija condiciones para entidades acreditadas e incluye obligaciones del registrador, auditoría y cumplimiento, requisitos de datos y protección del consumidor, términos sobre disputas y remedios que pueden incluir suspensión o terminación. Esos poderes no son idénticos a una sanción administrativa impuesta por una agencia pública. Son mecanismos contractuales, aunque pueden tener efectos operativos muy amplios para quien necesita conservar la acreditación y seguir ofreciendo servicios dentro del sistema. Los acuerdos posteriores o sus modificaciones pueden controlar para periodos posteriores; por eso, una conclusión sobre un caso concreto no debe apoyarse únicamente en la versión histórica más accesible.[https://www.icann.org/resources/pages/registrars/registrar-accreditation-agreement-2013-09-17-en]

Esta distinción entre coordinación, contrato y autoridad pública también limita el lenguaje sobre “control”. Un acuerdo puede permitir auditorías, imponer informes o establecer consecuencias por incumplimiento. Eso demuestra una capacidad de gobernanza contractual. No demuestra, sin más, que ICANN tenga jurisdicción general sobre todos los nombres, números o protocolos ni que sus decisiones tengan el mismo estatus que una sentencia o una norma legislativa. La documentación de la transición IANA identifica arreglos comunitarios posteriores a 2016, pero la existencia de esos arreglos no elimina la necesidad de examinar qué entidad posee cada función, qué documento la regula y qué remedio corresponde a cada desacuerdo.[https://www.icann.org/resources/pages/iana-transition-2016-06-03-en]

La tercera capa es la rendición de cuentas. ICANN publica varios mecanismos: reconsideración, Independent Review Process, Ombudsman, solicitudes de información documental y poderes de la comunidad. No son intercambiables. Difieren en quién puede activarlos, qué tipo de decisión revisan, quién decide, qué estándar aplican, qué remedio ofrecen y si el resultado es vinculante o consultivo. Presentarlos como una única “apelación” ocultaría precisamente la arquitectura que permite medir la autoridad institucional.[https://www.icann.org/resources/pages/accountability/mechanisms-2018-06-15-en]

La reconsideración está orientada a ciertos actos u omisiones de personal o del Board. La descripción publicada indica que una parte afectada puede pedir al Board Governance Committee que reconsidere una actuación, sujeto a requisitos de elegibilidad y presentación. El foco general no es una nueva decisión sobre los méritos de cualquier controversia, sino la consistencia de la actuación u omisión con las políticas de ICANN, los Bylaws o los procedimientos documentados. Por eso, el recurso puede ser adecuado para un defecto institucional o procedimental y no necesariamente para sustituir el juicio sustantivo de la autoridad que tomó la decisión. Los plazos y requisitos vigentes deben comprobarse en los Bylaws y reglas aplicables al momento del conflicto.[https://www.icann.org/resources/pages/accountability/reconsideration-2012-02-25-en]

El Independent Review Process ocupa otra posición. La información publicada lo describe como un mecanismo externo para determinadas alegaciones de que el Board o el personal actuaron de manera inconsistente con los Articles of Incorporation o los Bylaws. Tiene carácter adjudicativo y puede producir declaraciones u otros resultados definidos por los Bylaws y las reglas del IRP. Esto no equivale a una revisión general de cualquier consecuencia contractual ni garantiza una reparación idéntica a la de un tribunal estatal. La versión de los Bylaws y los procedimientos suplementarios vigentes para la fecha del conflicto son esenciales para saber quién tiene legitimación, qué puede examinarse y qué efecto tiene el resultado.[https://www.icann.org/resources/pages/accountability/irp-2012-02-25-en]

La Empowered Community introduce un mecanismo de naturaleza diferente. La documentación publicada sobre sus poderes identifica facultades respecto de determinadas actuaciones del Board y cambios fundamentales de los Bylaws. Entre los ejemplos figuran rechazar presupuestos o planes estratégicos, remover a directores individuales, retirar al Board completo y aprobar o rechazar acciones fundamentales especificadas, siempre conforme a requisitos de procedimiento. Es un control comunitario sobre decisiones institucionales delimitadas, no un recurso universal para cualquier operador que alegue una pérdida contractual. Sus disposiciones operativas están en los Bylaws vigentes y en los documentos constitutivos de la comunidad; la página explicativa no sustituye esos textos.[https://www.icann.org/resources/pages/community-powers-2016-03-16-en]

La transparencia cumple una función de soporte, no de sustitución. El proceso de información documental ofrece un canal para pedir registros sobre las operaciones de ICANN, sujeto a excepciones y protecciones de confidencialidad. Puede producir evidencia para evaluar o cuestionar una decisión, pero la divulgación no es automática. Una solicitud documental puede ayudar a establecer qué órgano decidió, qué procedimiento siguió y qué materiales tuvo ante sí; no convierte por sí misma una decisión en inválida ni asegura que todos los documentos sean revelados. Para una controversia específica, debe usarse la política operativa vigente y sus excepciones.[https://www.icann.org/resources/pages/governance/transparency-2012-02-25-en]

La estructura resultante puede representarse como una secuencia de cuatro preguntas. Primero: ¿qué instrumento define la misión o la competencia institucional? Segundo: ¿qué órgano o procedimiento convierte esa misión en una política o decisión? Tercero: ¿qué contrato, acuerdo técnico o relación de acreditación hace que la decisión sea operativa para un participante? Cuarto: ¿qué mecanismo permite cuestionarla y qué tipo de alivio puede producir? Si la respuesta se detiene en la primera pregunta, el análisis exagera el mandato. Si empieza y termina en el contrato, puede ignorar los límites institucionales.

Si enumera recursos sin explicar su alcance, confunde la existencia formal de un remedio con su capacidad práctica para alterar el resultado.

La documentación disponible permite sostener una conclusión acotada. ICANN dispone de una autoridad institucional y contractual estratificada: los Articles y los Bylaws organizan propósito, gobierno y límites; los arreglos posteriores a la transición distribuyen responsabilidades de supervisión; y los acuerdos con registros y registradores traducen obligaciones en condiciones de operación, auditoría, cumplimiento y posibles remedios. Esa arquitectura puede producir consecuencias decisivas dentro del sistema de identificadores sin convertir automáticamente a ICANN en una autoridad pública general.

La fuerza de una impugnación dependerá de la capa afectada: cumplimiento contractual, procedimiento institucional, consistencia con los Articles o Bylaws, o decisión reservada a los poderes de la comunidad.

También permanece una incertidumbre que importa. Las fuentes revisadas son páginas y materiales públicos de ICANN, algunos de carácter explicativo y varios sujetos a versiones, enmiendas o reorganización del repositorio. No permiten determinar por sí solas el resultado de una disputa histórica concreta ni identificar qué texto controlaría cada caso sin fechas, acuerdos ejecutados y reglas aplicables. La investigación seria debe seguir la cadena documental completa: mandato, órgano, contrato, acto operativo y remedio.

Esa cadena es más estrecha que una afirmación genérica de “poder de ICANN”, pero ofrece una explicación verificable de cómo la coordinación puede convertirse en control y dónde empiezan sus límites.

Fuentes y límites

Para el contexto institucional del sujeto puede consultarse también la entrada de ICANN en el directorio de BTW. Esa entrada identifica el objeto editorial; no sustituye la evidencia documental de las fuentes anteriores.