Resumen
- Desde el 1 de septiembre, la plataforma Open Data y su API dejarán de estar disponibles. ICANN dirige a los usuarios a una página que ofrece los CSV disponibles sin cuenta y les pide actualizar sus procesos.
- Acceso y continuidad no son la misma prueba. Un mapa del traspaso y un recibo de cada publicación permitirían saber adónde fue cada conjunto anterior y qué bytes, periodo, definición y estado de corrección respaldan un análisis.
La decisión de ICANN no cabe en la frase “se cierra una API”. También elimina un requisito de acceso que, para muchos lectores, era innecesario.
El 15 de junio, la organización presentó su nueva página de datos públicos y anunció un periodo de coexistencia hasta finales de agosto. El 27 de agosto volvió a advertir a quienes dependían de la plataforma: debían cambiar sus procesos antes del día 31. A partir del 1 de septiembre, ni la plataforma ni la API estarían disponibles, y la dirección anterior redirigiría a la iniciativa Open Data.
ICANN explica la transición como una simplificación que, además, reduce sus necesidades de mantenimiento, almacenamiento y copias de seguridad. El cierre, por tanto, fue anunciado y tuvo una ventana de adaptación. No hay base en las fuentes revisadas para presentarlo como una maniobra oculta.
La cuestión pendiente es distinta. Una fecha, una redirección y una nueva portada no constituyen por sí solas un inventario de continuidad.
La nueva puerta es más ancha
En la portada actual aparecen dos familias: los indicadores del mercado de nombres de dominio (DNMI) y las solicitudes de exención para respuestas de seguridad (SRW). Los archivos enlazados se descargan sin autenticación.
DNMI describe 16 indicadores activos en su estructura Version 1.1. Se distribuyen entre competencia robusta, estabilidad del mercado y confianza del consumidor. Las páginas separan las mediciones activas, que se actualizan anualmente, de los indicadores archivados. SRW ofrece un único CSV anual con cinco medidas sobre solicitudes, cobertura, momento de presentación y resultados.
La sencillez es valiosa. Un CSV completo puede guardarse, inspeccionarse y procesarse con herramientas comunes. No exige una clave, no consume una cuota y no obliga a un investigador ocasional a mantener una cuenta.
Los dos archivos de muestra consultados para este trabajo respondieron correctamente. El servidor mostraba datos de entrega como Last-Modified y ETag. Son señales útiles para cachés y para detectar cambios. Las páginas revisadas no las declaran, sin embargo, como el recibo oficial de una edición ni como la historia de sus correcciones.
Ahí aparece la diferencia. La accesibilidad dice si el archivo puede descargarse. La reproducibilidad exige saber cuál fue la edición exacta, qué periodo cubría, qué definición aplicaba y qué publicación la corrigió o sustituyó.
El producto anterior organizaba algo más que archivos
Cuando ICANN buscó proveedor en 2018, definió la plataforma como un sistema fuente para datos fiables, legibles por máquinas, con licencia abierta y acceso por API. La comunidad y el propio personal debían poder descargarlos, procesarlos y convertirlos en análisis.
La antigua página “About” añadía metas de uso: información oportuna y completa, comparable e interoperable, capaz de mejorar la gobernanza y la participación. Las cuentas permitían guardar análisis, recibir avisos de actualización, generar claves y revisar cuotas.
Esas funciones no convierten a la plataforma en intocable. Mantener un producto separado tiene coste. Los formatos sencillos suelen sobrevivir mejor que una interfaz dependiente de un proveedor. Para obtener una fotografía completa, incluso puede ser más fácil conservar un CSV que reconstruir una consulta.
Pero una interfaz también guardaba relaciones. Un programa podía nombrar un conjunto, seleccionar campos, filtrar filas, recorrer páginas o recibir un aviso. Cuando desaparece esa capa, el usuario necesita una declaración explícita sobre qué relación se conserva y cuál termina.
Defender la continuidad no implica conservar el software. Implica que el significado público viaje separado del software.
El catálogo anterior y la portada actual no son equivalentes visibles
La antigua portada agrupaba cuatro temas: DNMI, indicadores de salud de las tecnologías de identificadores (ITHI), informes de actividad de registros e informes de transacciones de registradores. La nueva portada enumera DNMI y SRW, y anticipa que se añadirán más datos cuando estén disponibles.
Contar cuatro y dos no prueba una pérdida. Los informes mensuales de registros siguen accesibles en otra página de ICANN, ordenados por dominio de nivel superior. ITHI mantiene un panel especializado con valores actuales e históricos.
La observación sí revela una falta de correspondencia visible en las páginas de transición: quien conocía un nombre del catálogo anterior no recibe allí una fila que indique su destino actual y el cambio de capacidades.
Los informes de registros son especialmente ilustrativos. En 2021, ICANN pidió a los responsables de descargas automatizadas que modificaran sus programas para usar la API Open Data. Quien obedeció aquella instrucción debe adaptar ahora el mismo flujo a otra superficie. No sabemos que ese proceso haya fallado; sí sabemos que la dependencia fue creada y reconocida públicamente.
Un mapa honesto puede registrar resultados diferentes. “Migrado a CSV”, “conservado en un panel especializado”, “disponible en el archivo principal”, “fusionado” o “retirado sin equivalente” son disposiciones comprensibles si llevan fecha, responsable y explicación. La ambigüedad aparece cuando el usuario debe deducirlas.
Una URL no es la versión
La redirección prevista preserva un camino de navegación. No preserva el significado de una consulta antigua ni identifica los bytes que una institución publicó en una fecha concreta.
Pensemos en RC 2.1. Citar el nombre y el enlace actual no basta si el fichero puede recibir una nueva edición. Para reproducir un resultado hacen falta el periodo de cobertura, la versión de la definición, la hora de publicación, una huella esperada, el número de filas y el vínculo a cualquier corrección posterior.
El usuario puede calcular su propia huella y conservar una copia. Eso demuestra lo que guardó. Solo ICANN puede afirmar que esa secuencia concreta de bytes fue su edición reconocida para un periodo y explicar qué decisión la reemplazó.
La solución no exige reconstruir la plataforma. Puede reducirse a dos piezas: una tabla de transición y un registro de ediciones.
| Campo público | Pregunta resuelta |
|---|---|
| Familia, identificador y ruta de API anteriores | ¿Qué dependencia se está trasladando? |
| Ubicación canónica y responsable actuales | ¿Dónde vive ahora y quién responde por ella? |
| Disposición y diferencia funcional | ¿Se migró, quedó aparte, se fusionó, se archivó o terminó? |
| Periodo, frecuencia y versión de la definición | ¿Qué significan los valores? |
| Fecha, huella esperada y filas | ¿Qué objeto exacto constituye la edición? |
| Corrección y sustitución | ¿Cómo cambió el registro sin borrar el anterior? |
| Licencia, límites y contacto | ¿Cómo puede reutilizarse y cuestionarse? |
La tabla dice adónde fue cada dependencia. El recibo dice qué publicación respalda ICANN. Las dos funciones son pequeñas, pero no intercambiables.
La transparencia debe sobrevivir al proveedor
El balance correcto no enfrenta “API buena” contra “CSV malo”. La descarga sin cuenta es un avance. Una plataforma más barata puede liberar recursos. Ninguna fuente revisada demuestra que los archivos actuales sean erróneos o que una familia haya desaparecido.
La prueba consiste en separar la información del producto que la entrega. Con identidades y recibos portátiles, ICANN podría mover mañana los ficheros, cambiar de almacenamiento o añadir otra interfaz sin romper la historia. Los programas se actualizarían contra un destino declarado. Los trabajos académicos y periodísticos podrían citar una edición, no solo una dirección cambiante.
ICANN ya ha publicado el momento del cambio, la nueva entrada y el motivo general. Un recibo de traspaso completaría la cadena. Haría comprobable la continuidad sin convertir el antiguo proveedor en una obligación permanente.
Fuentes
- Actualización de la página de datos públicos, 27 de agosto de 2026
- Lanzamiento de la nueva página, 15 de junio de 2026
- Iniciativa Open Data de ICANN
- Indicadores del mercado de nombres de dominio
- DNMI: competencia robusta
- DNMI: estabilidad del mercado
- DNMI: confianza del consumidor
- Solicitudes de exención para respuestas de seguridad
- Portada de la antigua plataforma
- Presentación de la antigua plataforma
- Anuncio de contratación de la plataforma en 2018
- Anuncio de migración de informes en 2021
- Informes mensuales de registros actuales
- Panel ITHI actual
- CSV de muestra DNMI RC 2.1
- CSV de muestra SRW M1-M5
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance