Resumen

  • El aviso de 28 de agosto dice que ICANN termina el Registrar Accreditation Agreement de IPIP INC. conforme a la sección 5.5.4 y que la terminación será efectiva el 13 de septiembre de 2026.
  • ICANN basa la decisión en cuatro incumplimientos que afirma que seguían sin subsanar: servicio RDAP, depósitos de datos en escrow, cuotas de acreditación y enlace en la portada al procedimiento de solicitudes de divulgación.
  • A continuación, el escrito presenta otros puntos como «preocupaciones adicionales» y luego trata la transición, la licencia del logotipo y las obligaciones que sobreviven. No son categorías intercambiables.
  • Un registro de disposición por asunto conservaría norma, evidencia, acción requerida, plazo, respuesta, clasificación y estado sin revelar correspondencia privada ni datos personales.

El verbo cambia entre el 28 de agosto y el 13 de septiembre

ICANN fechó su aviso el 28 de agosto de 2026. En él comunica a IPIP INC., registrador IANA 3774, que su acuerdo de acreditación de 2013 queda terminado conforme a la sección 5.5.4. La frase siguiente introduce el futuro: la terminación «será efectiva» el 13 de septiembre, 16 días naturales después, conforme a la sección 5.6.

Al cierre de pruebas de este artículo, el 30 de agosto, no es un matiz. La decisión está tomada; la fecha efectiva no ha llegado. Aún no hay en ese expediente público un registrador receptor, una cifra de nombres afectados, una fecha de traslado masivo ni una constancia de finalización. Tampoco consta públicamente un arbitraje, una suspensión del efecto o una subsanación posterior.

La página de avisos de ICANN conecta el incumplimiento del 5 de agosto con su escalada a terminación. Registra la situación de la medida contractual, no el final de la transición operativa.

La primera lista conserva cuatro fundamentos

El escrito afirma que IPIP no corrigió antes del 26 de agosto los incumplimientos comunicados el día 5. Después enumera cuatro que, según ICANN, seguían abiertos.

El primero es el servicio RDAP. Debía ofrecer los datos exigidos para todos los nombres gTLD activos patrocinados por IPIP y aplicar la guía técnica y el perfil de respuesta vigentes. El aviso de agosto anterior señala que existía una URL base registrada, pero que las consultas probadas por ICANN no devolvían datos de los dominios patrocinados.

El segundo es la falta de depósitos oportunos de datos de registro ante un agente de escrow aprobado, bajo el calendario, las condiciones y el formato establecidos. El tercero son cuotas de acreditación vencidas. El cuarto es la ausencia en la portada de un enlace directo al mecanismo y proceso para solicitar la divulgación de datos de registro no públicos.

Son superficies de control distintas. RDAP permite consultar datos públicos. El escrow conserva un paquete de continuidad. Las cuotas son una obligación de pago. El enlace de divulgación hace visible una vía exigida por la sección 10.1 de la Registration Data Policy. Reducirlo todo a «problemas de cumplimiento» pierde el mecanismo de impacto y la prueba de subsanación que correspondería a cada caso.

Las normas subyacentes están publicadas. El perfil RDAP de febrero de 2024 es obligatorio desde el 21 de agosto de 2025. La especificación de escrow de 2025 entró en vigor el mismo día. La política de datos exige que la página de divulgación explique formato y contenido de la solicitud, modo de respuesta y plazo previsto.

Las conclusiones sobre IPIP siguen siendo conclusiones de ICANN. BTW no ha reconstruido el universo de dominios, accedido al agente de escrow ni revisado la cuenta de facturación. La atribución no es una formalidad: fija quién reunió la prueba y quién ejerció la autoridad.

La segunda lista no se llama incumplimiento

Tras esos cuatro puntos, el aviso dice «además» y abre el grupo de «preocupaciones adicionales» que IPIP no habría atendido ni resuelto.

Incluye un formulario o correo dedicado para denuncias de abuso, la descripción de cómo se reciben y siguen, los nombres y cargos de los directivos, el domicilio de correspondencia, las políticas de eliminación y renovación automática, las tarifas de restauración, los métodos de notificación de renovación y un plan de remediación con fechas.

No son detalles decorativos. Varios remiten a deberes expresos del RAA. Tampoco puede deducirse que una «preocupación» carezca para siempre de efecto contractual. Lo que sí puede afirmarse es que este documento no la incorporó a la lista anterior de cuatro incumplimientos restantes.

La precisión evita dos errores simétricos. Decir que el segundo grupo no importa jurídicamente excede la fuente. Contar cada subapartado como otro fundamento ya resuelto de terminación también la excede.

ICANN no ordena los cuatro primeros por gravedad ni explica cuál sería decisivo por sí solo. La sección 5.5.4 permite terminar por falta de subsanación de cualquier incumplimiento dentro de 21 días tras el aviso. El documento dice que quedaban cuatro; no publica una prueba de necesidad o suficiencia individual. Esa jerarquía no debe nacer en la noticia.

La cronología acredita comunicación, no intención

Los anexos registran contactos desde marzo y junio: avisos escalados o sucesivos, correos rechazados, falta de respuesta, llamadas telefónicas y una respuesta que ICANN consideró insuficiente. El 5 de agosto emitió el aviso formal y fijó el 26 como fecha de subsanación. La entrega por mensajería se confirmó el 7 de agosto; el 19 se enviaron recordatorios; el 28 ICANN dijo que no se habían adoptado las medidas necesarias.

Eso documenta intentos de notificación, una oportunidad de corregir y la valoración de ICANN. No explica el motivo de un rebote o un silencio. No prueba abandono, insolvencia, fraude, compromiso de seguridad ni evasión deliberada.

El mejor argumento a favor de un aviso breve es la protección del expediente. ICANN puede ejercer una facultad contractual sin publicar direcciones personales, datos de clientes, registros sensibles o asesoramiento jurídico interno. Pero puede ser breve sin borrar la clase de cada elemento.

Consecuencias y obligaciones forman un tercer bloque

Después de las razones, el aviso pasa a lo que viene. ICANN aplicará el De-Accredited Registrar Transition Procedure para trasladar los nombres a un registrador acreditado y cualificado. La licencia del logotipo queda revocada con efecto el 13 de septiembre. La conservación de datos, determinadas cuotas, la resolución de disputas y las limitaciones a remedios monetarios sobreviven. También quedan importes por pagar.

Son consecuencias y deberes persistentes, no nuevas infracciones que sumar. Responden a quién seguirá prestando el servicio, qué autorización de marca termina y qué obligaciones no desaparecen con la acreditación.

BTW ya publicó un análisis sobre cómo se elige al registrador receptor y otro sobre por qué un archivo en escrow no equivale a un registrador operativo. Este texto no reproduce esas rutas. Su objeto exclusivo es la clasificación dentro de una decisión viva.

Una tabla que muestre el cambio de estado

ICANN ya mantiene un índice público por caso. Una tabla por asunto añadiría trazabilidad con poco coste informativo.

Cada fila debería mostrar identificador, clase, disposición exacta del acuerdo o la política, fuente pública y fecha de observación, corrección o información solicitada, plazo y prórroga, estado de respuesta, resultado en cada aviso, papel explícito en la medida actual y cualquier rectificación, impugnación, arbitraje o suspensión de efecto publicados.

Después de la terminación, convendría identificar al responsable del siguiente paso y la próxima revisión. Un incumplimiento puede cerrarse, sobrevivir como deuda o entrar en disputa. Una preocupación puede ser contestada, formalizada después o quedar como nota histórica. Esa evolución no debería depender de que el lector compare párrafos distantes.

No hace falta publicar correos privados, nombres personales, trazas crudas ni opinión legal. La transparencia necesaria está en el tipo, la autoridad y la disposición de la actuación.

La idea de Heng Lu funciona aquí como una disciplina de lectura: el poder institucional de alto impacto debe seguir unido a una autoridad identificable, evidencia, responsabilidad y revisión. El contrato es la fuente de la facultad de ICANN. La disciplina evita que una paráfrasis amplíe silenciosamente ese poder.

Fuentes

  1. ICANN — Aviso de terminación a IPIP INC., 28 de agosto de 2026
  2. ICANN — Aviso de incumplimiento a IPIP INC., 5 de agosto de 2026
  3. ICANN — Avisos de incumplimiento, suspensión, terminación y no renovación
  4. ICANN — Registrar Accreditation Agreement y materiales relacionados
  5. ICANN — Registration Data Policy
  6. ICANN — Perfil RDAP de gTLD
  7. ICANN — Programa de escrow de datos de registradores
  8. ICANN — Enfoque y procesos de Cumplimiento Contractual
  9. ICANN — Terminación de una acreditación
  10. ICANN — De-Accredited Registrar Transition Procedure
  11. Heng Lu — Cuando el poder del registro se separa de la responsabilidad