Resumen
- India solicitó validar correo y teléfono antes de activar un dominio, imponer y centralizar informes sobre abuso del DNS y poner en marcha la autenticación policial para solicitudes urgentes de datos de registro.
- El presidente y director ejecutivo de ICANN respondió que los dos primeros asuntos merecen más consideración y aparecen en la priorización del GNSO, pero que él no puede dirigir las prioridades ni el resultado de un PDP.
- El grupo de autenticación sí publica reuniones e hitos entre junio de 2026 y marzo de 2027. No es un órgano de políticas, y su prueba de concepto no activa por sí misma la respuesta de veinticuatro horas.
- Un comprobante de ruta por petición permitiría ver la autoridad competente, el estado actual, el procedimiento, la siguiente decisión autorizada y todo lo que ese estado todavía no acredita.
La seguridad común no borra las diferencias
El 14 de julio de 2026, S. Krishnan, secretario del Ministerio de Electrónica y Tecnología de la Información de India, escribió a Kurt Erik Lindqvist, presidente y director ejecutivo de ICANN. El documento presenta tres cuestiones como pendientes desde hace tiempo y pide que reciban prioridad inmediata. Comparten una preocupación por la seguridad, pero exigen decisiones distintas.
La primera propuesta cambia el momento de la verificación. India quiere comprobar el correo electrónico y el teléfono antes de activar el dominio. Su carta contrasta ese modelo con el periodo actual de respuesta posterior a una consulta de exactitud y sostiene que bastarían enmiendas contractuales menores. La documentación de ICANN sobre el Whois Accuracy Program explica las consecuencias que pueden aplicarse tras más de quince días sin respuesta. No dice que la validación previa ya sea una obligación ni que la propuesta haya sido aceptada.
La segunda propuesta crea una arquitectura de datos. India pide que registradores y registros publiquen estadísticas periódicas sobre denuncias, clases de abuso, medidas de mitigación y plazos de respuesta. También quiere un mecanismo central gestionado por ICANN. La obligación de informar y el sistema común son decisiones separables. Incluso una base única puede producir una comparación falsa si no define el universo cubierto, el denominador, el significado de «denuncia», la confirmación de un incidente y el tratamiento de correcciones.
La tercera propuesta intenta hacer operativa una regla ya escrita pero aún condicionada. La Registration Data Policy establece acuse en dos horas y respuesta en veinticuatro para una solicitud urgente, salvo una excepción limitada. La nota de implementación mantiene la sección 10.7 inactiva hasta que ICANN aplique plenamente una Política de Consenso que establezca la autenticación del solicitante. India pide acelerar ese mecanismo para las fuerzas del orden.
La carta india es evidencia de una preferencia de política pública. No es una decisión del GNSO, una modificación del contrato ni una demostración de eficacia. Una gobernanza seria no tiene que escoger entre ignorar la urgencia y obedecerla. Debe mostrar quién está autorizado para tomar el siguiente paso.
ICANN respondió con una frontera de competencias
La contestación de Lindqvist, fechada el 11 de agosto y publicada el día 12, comparte el objetivo de un DNS seguro, pero no confunde acuerdo sobre el objetivo con potestad sobre el método.
Primero menciona el consejo consensuado del GAC en ICANN83 y el PDP 1 del GNSO sobre comprobaciones de dominios asociados. Ese proceso estudia responsabilidades respecto de otros dominios vinculados a una cuenta objeto de un informe de abuso susceptible de actuación. Es trabajo de política real y activo. No equivale a validar los datos de contacto antes de la activación ni a construir el sistema estadístico solicitado por India.
Para la verificación y la transparencia de informes, la respuesta es más cauta. ICANN org considera que merecen estudio adicional y entiende que el Consejo del GNSO los discute dentro de sus esfuerzos de priorización. «Consideración» y «priorización» prueban que el asunto está a la vista. No prueban una posición en la cola, una carta de trabajo, un grupo, una negociación contractual, una recomendación ni una fecha.
El propio reparto institucional explica el lenguaje. El GNSO desarrolla y recomienda políticas sustantivas para los gTLD. El GAC aporta asesoramiento sobre preocupaciones gubernamentales y de interés público. La dirección ejecutiva puede asegurar datos, apoyo y experiencia operativa, y puede aplicar lo aprobado. No puede ordenar al Consejo del GNSO qué debe priorizar ni cuál debe ser el resultado de un PDP.
El límite protege a todos. Un gobierno conserva el derecho a formular una demanda urgente, pero no obtiene un voto decisorio nuevo. El GNSO conserva su competencia, pero no debería presentar una conversación como si hubiera resuelto la demanda. ICANN org puede preparar la ejecución, pero no convertir esa preparación en una fuente autónoma de política. Para imponer una obligación a las partes contratadas hace falta el instrumento político o contractual correspondiente.
Tres peticiones, tres estados comprobables
Con corte al 31 de agosto, el expediente público permite esta comparación:
| Medida solicitada | Estado público | Próximo paso autorizado visible |
|---|---|---|
| Validar correo y teléfono antes de activar | Recibida, reconocida y remitida a consideración y priorización del GNSO | No aparece una decisión de prioridad, carta, PDP ni paso contractual con fecha |
| Informes obligatorios y centralizados sobre abuso del DNS | Recibida, reconocida y remitida a consideración y priorización del GNSO | No aparece una decisión fechada sobre la obligación, el modelo de datos, el sistema o el proceso |
| Autenticación policial para solicitudes urgentes | Grupo formado, reuniones en curso y hitos de prueba publicados | Cambios de maqueta RDRS en octubre de 2026, pruebas en diciembre, resultados en marzo de 2027 y después el instrumento de política válido que corresponda |
La diferencia no dice cuál medida es más importante. Dice cuál ruta puede auditar hoy un observador.
Las actas del Consejo del GNSO del 13 de agosto muestran por qué no conviene completar los huecos con inferencias. El Consejo discutió el borrador de la carta del PDP 2 sobre mitigación del abuso del DNS. Hubo desacuerdo sobre el texto de partida, el alcance de los mecanismos automatizados y el peligro de redactar preguntas que ya presupusieran requisitos vinculantes. El equipo de redacción comenzaría reuniones semanales la semana del 24 de agosto.
Las actas no incorporan las dos primeras peticiones indias al PDP 2. Sí recogen que el enlace entre GNSO y GAC consideró que las preguntas sobre el plazo de verificación del registrante llegaron demasiado tarde en ICANN86 para consultar adecuadamente a los grupos del Consejo. Esa frase identifica un fallo de tiempo en la comunicación, no una decisión sustantiva.
También queda clara la función del enlace. Puede trasladar aportaciones del GAC, pero la redacción de la carta sigue siendo responsabilidad del Consejo. El enlace no representa ni defiende por defecto la posición del GAC. La comunicación cruza la frontera; la autoridad no.
Un prototipo con fechas sigue siendo un prototipo
La ruta de autenticación ofrece más señales. La página pública de ICANN sitúa la formación del grupo en junio, el comienzo de reuniones en julio, la presentación de cambios de interfaz RDRS en octubre, el inicio de pruebas en diciembre y un resumen de conclusiones en marzo de 2027. Ya enlaza grabaciones del 22 de julio y del 12 de agosto.
La misma página niega cualquier función normativa al grupo. Su cometido es técnico y operativo, y la carta constitutiva todavía figura como pendiente. Puede examinar flujos de trabajo, interoperabilidad, minimización de datos, registro de actividad y experiencia de uso. No puede decidir que una petición concreta sea urgente, que exista una base jurídica, que la divulgación sea necesaria o que el solicitante tenga derecho a recibir los datos.
Por eso los hitos mejoran la rendición de cuentas sin aumentar la autoridad. Permiten comprobar si un ensayo empezó, cambió o se retrasó. No sustituyen la Política de Consenso de la que depende la entrada en vigor ni las decisiones individuales sobre divulgación.
El registro que falta después del acuse
ICANN ha publicado las dos cartas. Para conocer el estado de cada medida, sin embargo, el lector debe enlazar manualmente la respuesta ejecutiva, las actas del GNSO, el sitio del PDP, la página del grupo de autenticación y las notas de implementación.
Un comprobante público de ruta podría resolverlo sin crear una nueva burocracia decisoria. Para cada petición registraría el resultado exacto solicitado; la clase de autoridad del remitente; el órgano competente; el estado —recibida, en consulta, priorizada, en redacción, en PDP, en negociación contractual, en implementación, completada, rechazada o sustituida—; el expediente; el responsable del apoyo de ICANN org; las dependencias; la siguiente decisión y su fecha, o «sin programar»; la última evidencia y las correcciones.
La columna más importante explicaría lo que no ha ocurrido. «Reconocida» no significa priorizada. «En priorización» no significa que haya una carta. «Carta en redacción» no decide la política. «Prueba de concepto» no crea una obligación ni un derecho de acceso. «Implementada» debe remitir al instrumento que permite exigirla.
El seguimiento tiene que dividirse por medida. Una carta con tres peticiones no puede recibir un único semáforo. «ICANN mantiene el diálogo con India» puede ser cierto y, aun así, ocultar que una ruta tiene fechas y dos no muestran todavía la próxima decisión.
El comprobante tampoco concede al remitente la facultad de fijar el resultado. Solo identifica al responsable de la próxima elección. La demora se vuelve visible sin transformarse en aceptación tácita; la independencia del proceso se conserva sin convertirla en opacidad.
La autoridad también necesita trazabilidad
La respuesta del 11 de agosto acierta al no elevar al director ejecutivo por encima del GNSO. Su siguiente obligación de transparencia es menos grandiosa: mostrar con igual claridad dónde se encuentra cada medida.
India puede insistir en la urgencia. El GAC puede aconsejar. El GNSO puede ordenar su trabajo y decidir qué preguntas abre. ICANN org puede aportar medios y ejecutar una política válida. Un grupo técnico puede producir conocimiento. Los contratos y las Políticas de Consenso son los que transportan obligaciones. Ningún paso debe apropiarse del mandato del siguiente.
En ese modelo, participación no equivale a autorización y procedimiento no equivale a resultado. La ficha pública hace compatible esa modestia con la rendición de cuentas: una petición, una ruta competente, un estado actual, una próxima decisión y un historial que no desaparece cuando cambia la agenda.
Fuentes
- ICANN — índice de correspondencia
- S. Krishnan a Kurt Erik Lindqvist, 14 de julio de 2026
- Kurt Erik Lindqvist a S. Krishnan, 11 de agosto de 2026
- ICANN — Desarrollo de políticas
- Consejo del GNSO — actas del 13 de agosto de 2026
- ICANN — grupo sobre mecanismos de autenticación de organismos policiales
- GNSO — DNS Abuse Mitigation PDP 1
- ICANN — Registration Data Policy
- ICANN — RAA de 2013 y Whois Accuracy Program Specification
- Lu Heng — The Multi-Stakeholder Mirage
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