Resumen

  • ICANN es una corporación californiana con una misión delimitada por sus Articles of Incorporation y sus Bylaws, no una autoridad pública con jurisdicción general sobre servicios o contenidos de Internet.
  • Su influencia práctica nace sobre todo de contratos con operadores de registros y registradores, mientras que PTI ejecuta funciones IANA separadas de la elaboración de políticas.
  • Reconsideration, Independent Review y Ombudsman ofrecen controles diferenciados; ninguno equivale por sí solo a una apelación general capaz de reabrir cualquier resultado.

La pregunta decisiva sobre ICANN no es si tiene poder, sino de dónde procede cada poder y qué puede cambiar una persona o una organización cuando ese poder se ejerce. La respuesta está distribuida entre instrumentos que cumplen funciones distintas.

1. El punto de partida es corporativo, no soberano

Los Articles of Incorporation describen a ICANN como una corporación californiana sin ánimo de lucro de beneficio público, organizada con fines benéficos y públicos. No la presentan como un gobierno ni como un regulador creado por tratado. También conectan su propósito corporativo con la misión establecida en los Bylaws. [https://www.icann.org/resources/pages/governance/articles-en]

Esa distinción importa porque evita confundir la condición jurídica de ICANN con su influencia sistémica. Los Articles no contienen por sí solos el conjunto de obligaciones técnicas, operativas y comerciales que afectan a los operadores de dominios. Esas obligaciones aparecen en otros instrumentos. [https://www.icann.org/resources/pages/governance/articles-en]

Los Bylaws sitúan la misión alrededor de la coordinación de los identificadores únicos de Internet y limitan la actuación de ICANN fuera de esa misión. También restringen su capacidad para regular los servicios que utilizan esos identificadores o el contenido que transportan, salvo dentro de la misión y de excepciones específicas. [https://www.icann.org/resources/pages/governance/bylaws-en]

Por eso, una política de ICANN no debe describirse automáticamente como una ley aplicable a todos los usuarios de Internet. La cuestión correcta es más estrecha: qué órgano adoptó la decisión, dentro de qué misión, mediante qué procedimiento y contra quién puede hacerse valer.

2. La transición de IANA no convirtió a ICANN en propietaria de Internet

La Affirmation of Commitments de 2009 fue un instrumento bilateral entre ICANN y el Departamento de Comercio de Estados Unidos. Estableció revisiones periódicas sobre rendición de cuentas, transparencia, seguridad y estabilidad, competencia, confianza del consumidor y servicios de datos de registro. No era el estatuto corporativo de ICANN ni un contrato de registro. [https://www.icann.org/resources/pages/affirmation-of-commitments-2009-09-30-en]

Estados Unidos e ICANN terminaron esa Affirmation después de la transición de la supervisión de IANA. La notificación de 2017 explicó que compromisos de revisión y rendición de cuentas habían sido incorporados a los Bylaws revisados. La Affirmation conserva valor histórico, pero no debe presentarse como la fuente contractual vigente de toda autoridad de ICANN. [https://www.ntia.gov/press-release/2017/us-government-and-icann-terminate-affirmation-commitments]

En 2014, la NTIA anunció la intención de iniciar una transición hacia la comunidad global de múltiples partes interesadas. El anuncio exigía proteger la seguridad, estabilidad y resiliencia del DNS, mantener el modelo multilateral y preservar la apertura de Internet. No transfirió la propiedad de Internet ni otorgó a ICANN una jurisdicción regulatoria general. [https://www.ntia.gov/press-release/2014/ntia-announces-intent-transition-key-internet-domain-name-functions]

La expiración del contrato de funciones IANA de la NTIA en 2016 terminó la función contractual de supervisión estadounidense. La operación y la rendición de cuentas pasaron a arreglos que involucraban a ICANN, PTI y las comunidades operativas correspondientes. La terminación del contrato no significó que ICANN adquiriera propiedad del DNS o autoridad irrestricta. [https://www.ntia.gov/press-release/2016/statement-assistant-secretary-strickling-iana-functions-contract]

El diseño de transición separó la elaboración de políticas de la ejecución operativa en las comunidades de nombres, números y parámetros de protocolo. Para nombres, contempló una entidad jurídicamente separada, Public Technical Identifiers, con contrato, niveles de servicio, comité de clientes, revisiones periódicas y un posible proceso de separación. [https://www.icann.org/en/system/files/files/iana-stewardship-transition-proposal-10mar16-en.pdf]

3. PTI ejecuta funciones; no recibe por ello autoridad general para crear políticas

IANA describe funciones operativas que incluyen la coordinación de la zona raíz del DNS, la asignación de recursos numéricos y el mantenimiento de registros de parámetros de protocolo. Esas funciones son realizadas por PTI, una afiliada de ICANN. [https://www.iana.org/about] [https://pti.icann.org/]

El contrato de funciones de nombres de IANA delega a PTI la operación de esos servicios y establece obligaciones de rendimiento, informes, niveles de servicio, auditoría, escalamiento y subcontratación. El contrato organiza la ejecución; no crea por sí mismo autoridad para formular políticas de nombres de dominio. [https://www.icann.org/en/system/files/files/iana-naming-function-contract-01oct16-en.pdf]

La separación también aparece en el ámbito de los protocolos. RFC 2860 distingue la administración de los registros de parámetros de protocolo de la elaboración de políticas técnicas mediante el proceso del IETF. Administrar un registro no equivale a decidir unilateralmente qué estándares debe adoptar Internet. [https://www.rfc-editor.org/rfc/rfc2860]

En materia de números, el acuerdo de nivel de servicio con la comunidad de registros regionales vincula el desempeño operativo de IANA/PTI con compromisos de servicio y revisión. La política global de recursos numéricos permanece asociada a la comunidad de registros regionales, no a una autoridad única de ICANN. [https://www.nro.net/accountability/operational/iana-numbering-services-review-committee/iana-numbering-services-sla/]

4. El control más tangible está en los contratos

La influencia cotidiana de ICANN sobre el sistema de nombres genéricos se entiende mejor a través de los contratos. La propia colección de acuerdos de registros muestra que las obligaciones de los operadores de gTLD nacen de contratos individuales y que los términos varían entre arreglos. Un único acuerdo base no describe automáticamente todos los TLD heredados, patrocinados o de código de país. [https://www.icann.org/resources/pages/registries/registries-agreements-en] [https://www.icann.org/resources/pages/cctlds-2012-02-25-en]

El Base Registry Agreement constituye una superficie contractual importante sobre muchos operadores de nuevos gTLD. Incluye obligaciones sobre políticas, custodia de datos, requisitos técnicos y de seguridad, auditorías, incumplimiento, suspensión, terminación y resolución de controversias. [https://www.icann.org/en/registry-agreements/base-agreement]

Pero el mismo acuerdo limita la capacidad de incorporar nuevas políticas. La especificación sobre políticas de consenso y temporales delimita los asuntos en los que esas políticas pueden obligar al registro. El resultado es un poder considerable, aunque acotado por el contrato, las políticas incorporadas, los Bylaws y los mecanismos de disputa. [https://www.icann.org/en/registry-agreements/base-agreement]

La relación con los registradores sigue una lógica parecida. El Registrar Accreditation Agreement establece obligaciones sobre políticas, servicios de datos de registro, custodia y conservación de datos, contactos de abuso, supervisión de revendedores, auditorías, investigaciones de cumplimiento y suspensión o terminación. [https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en]

Sin embargo, el registrante suele contratar con un registrador o revendedor, no directamente con ICANN. Esa arquitectura limita los remedios contractuales directos de ICANN frente al usuario final. También significa que una decisión que afecta a un registrante puede atravesar varios niveles contractuales antes de llegar al actor que siente el impacto.

Los acuerdos con administradores de ccTLD son más heterogéneos: pueden incluir acuerdos de patrocinio, marcos de rendición de cuentas o intercambios de cartas. La existencia de una relación publicada no demuestra que todos los administradores de TLD estén sometidos al mismo modelo contractual. [https://www.icann.org/resources/pages/cctlds-2012-02-25-en]

5. Los remedios son canales distintos, no una apelación única

Los materiales de cumplimiento, reconsideración, Independent Review y Ombudsman muestran canales diferenciados. [https://www.icann.org/compliance] [https://www.icann.org/resources/pages/reconsideration-2012-02-25-en] [https://www.icann.org/resources/pages/irp-2012-02-25-en] [https://www.icann.org/en/system/files/files/irp-interim-supplementary-procedures-25oct18-en.pdf] [https://www.icann.org/ombudsman]

Reconsideration está orientada a determinados actos de la Junta o del personal y depende de requisitos de alcance y procedimiento. Independent Review examina cuestiones definidas de gobernanza conforme a sus reglas y procedimientos. El Ombudsman funciona como mecanismo institucional de equidad y facilitación, no como sentencia judicial. [https://www.icann.org/resources/pages/reconsideration-2012-02-25-en] [https://www.icann.org/resources/pages/irp-2012-02-25-en] [https://www.icann.org/en/system/files/files/irp-interim-supplementary-procedures-25oct18-en.pdf] [https://www.icann.org/ombudsman]

La diferencia entre registrar una objeción y cambiar un resultado es el límite práctico. Un procedimiento puede crear un expediente, exigir una explicación o identificar un defecto sin producir necesariamente la reparación que busca el impugnante. El momento también importa: un recurso que llega después de una transferencia, una suspensión o la expiración de un contrato puede tener menos capacidad para restaurar la situación original.

La página de revisiones de ICANN debe leerse junto con los instrumentos concretos y la versión vigente de los Bylaws. Los compromisos históricos, propuestas de transición y procedimientos provisionales no deben confundirse con las reglas actualmente aplicables. [https://www.icann.org/resources/reviews]

Conclusión: seguir la cadena de autoridad

La autoridad de ICANN es más precisa y más limitada de lo que sugieren sus efectos sistémicos. Los Articles establecen una base corporativa. Los Bylaws fijan misión, órganos y límites. Los contratos convierten parte de esa misión en obligaciones exigibles frente a registros y registradores. PTI ejecuta funciones IANA bajo arreglos operativos separados. Los mecanismos de revisión abren controles, pero no una apelación universal.

Para evaluar una decisión concreta, el mapa mínimo es: instrumento que concede el poder, entidad que lo ejerce, actor al que obliga, procedimiento utilizado y remedio disponible. Si alguno de esos eslabones queda fuera del análisis, la discusión puede llamar “regulación” a un contrato, “política” a una operación técnica o “apelación” a una revisión que nunca pudo modificar el resultado.

Fuentes adicionales del análisis institucional: propuesta de responsabilidad de la comunidad.