ICANN81: Perspectivas del sector en la reunión general de ICANN de 2024
ICANN81 se celebró en Estambul (Turquía), entre el 9 y el 14 de noviembre de 2024. Vea el webinar y lea la transcripción a continuación para conocer lo último sobre políticas y procedimientos, del equipo de relaciones industriales globales de Markmonitor.
Introducción – ICANN81: webinar de perspectivas del sector
Hablante: Prudence Malinki
Hola a todos. Bienvenido al webinar de Markmonitor sobre ICANN81. Me llamo Prudence Malinki. Soy responsable de Relaciones de Sector Globales en Markmonitor y tendré el placer de hablarles de todo lo acaecido en ICANN81.
Hoy me acompañan miembros del fantástico equipo de Relaciones de Sector Globales (GIR). Quiero presentarles a Heidi Zhang, Responsable de Markmonitor China. A Chris Niemi, Director de Iniciativas Estratégicas y todo lo relacionado con dominios dotBrand y la próxima ronda. Y a Leanne Kenny, la incorporación más reciente en el equipo GIR, pero ya hace tiempo en el sector. Bienvenida, Leanne. Quien no está con nosotros hoy es Shane Layman. Shane ha sido padre recientemente de una preciosa niña llamado Lennon. Sentimos que no puedas acompañarnos hoy, Shane. Enhorabuena por ser un padre fantástico.
Agenda: webinar sobre ICANN81
Hoy tenemos una agenda repleta. Vamos a tratar varios temas diferentes, entre ellos:
- Subpro IRT
- PDP de transferencias
- Noticias sobre ccNSO
- RDRS y RDAP
- Comunicado del GAC
- Y mucho más.
Ha sido una reunión de ICANN muy interesante.
Resumen de la reunión ICANN81
La reunión ICANN81 se celebró en la magnífica ciudad de Estambul. Es la primera vez que se celebra en Turquía.
Esta ICANN ha sido un poco diferente, con tristes despedidas pero también bienvenidas en la comunidad de ICANN. Finalizaron los mandatos de varios cargos directivos de la Cámara de Partes Contratadas (CPH) de ICANN. Le deseo lo mejor a Ashley Heineman y le agradezco enormemente su labor como presidenta del RrSG. Y lo mismo a Sam Demetriou. Muchas gracias también por su trabajo con los registros. Les deseo a ambos mucho éxito en sus proyectos futuros. Sam, trabajaré contigo en el Consejo, así que hablaremos pronto. También quiero dar la bienvenida a Owen Smigelski. Dirigirá el Grupo de Partes Interesadas de Registradores (RrSG). Y a Beth Bacon, enhorabuena y buena suerte con tu trabajo.
Este tipo de cambios en el liderazgo significan cambios de dirección y cambios de tácticas, además de gente nueva. Enhorabuena a todos los nuevos líderes, y a Greg DiBiase, que sigue siendo Presidente del Consejo de la GNSO.
Quiero dar la bienvenida a sus cargos a todos los nuevos Consejeros de la GNSO. Estoy deseando trabajar con todos en el futuro. Próximamente, ICANN también tendrá un nuevo Director General, Kurt Lindqvist. En esta reunión de ICANN también se hizo la presentación de Elizabeth Field, nuestra nueva Ombuds, que tendrá la difícil tarea de responder a numerosas preguntas como el proceso de selección para las reuniones de ICANN. Una de las cosas que observamos durante esta reunión fueron las ausencias. Es de esperar que nuestra nueva Ombuds examine el proceso de selección de países, así como el de selección de visados.
También estamos estudiando documentos de políticas específicos. Disponemos de un nuevo documento de política ética y uno de código de conducta relativo a las declaraciones de intereses. El documento del código de conducta de SOI está disponible para comentarios públicos y se cierra el 2 de diciembre.
Elecciones a la Junta Directiva de ICANN
Como he mencionado, estamos teniendo muchas transiciones de cargos y mucho movimiento. Nos encontramos en una fase interesante en la que hay dos puestos vacantes. El puesto 12 de la Junta, que es para candidatos de la ccNSO. Y el puesto 13, para las partes contratantes. Acabo de estar en una reunión sobre candidatos. Y seguramente queda claro por mi voz que esta es una de las cosas más emocionantes que están ocurriendo ahora mismo.
Está en juego el puesto 13 de la Junta Directiva de la GNSO, puesto de las partes contratantes. Quiero dar las gracias a Becky Burr por haber desempeñado un papel ejemplar y por hacer un trabajo fantástico. El listón está muy alto y tenemos seis candidatos increíbles para el puesto. En ICANN81, una de las sesiones más candentes de esta reunión fue una en la que todos los candidatos realizaron una sesión de preguntas y respuestas con las partes contratantes. Les explico por qué.
Los favoritos iniciales que parecían tener el puesto asegurado no hicieron su mejor trabajo. Y los candidatos aparentemente más desfavorecidos descollaron al abordar las amplias necesidades de la comunidad y fueron capaces de ofrecer análisis elocuentes de los matices de un modelo con múltiples partes interesadas, así como de los retos que pueden plantearse en el futuro. O sea que tenemos candidatos increíbles, y sinceramente creo que tenemos mucho donde elegir. Se trata de un puesto muy importante, por lo que debemos asegurarnos de dar en el clavo y elegir el candidato adecuado.
Los temas de los conflictos de intereses y de políticas no van a desaparecer. La votación y el debate van a ser muy interesantes. La votación para el escaño 13 de la Junta tendrá lugar en las próximas semanas. Les mantendremos al tanto de los resultados. También en este caso todos los candidatos son increíbles. Les deseo buena suerte a todos y cada uno, incluidos los candidatos al puesto 12 de la Junta.
Y ahora, vamos a hablar de todo lo relacionado con SubPro IRT. Les dejo con Chris. Gracias, Chris.
Equipo para la Revisión de la Implementación de Procedimientos Posteriores, SubPro IRT en ICANN81
Hablante: Chris Niemi
Gracias, Prudence. En esta reunión destaca la “próxima ronda”, ya que se mantiene el objetivo de un plazo de solicitud en abril de 2026.
Antes de que esto ocurra, el Subpro IRT (Equipo para la Revisión de la Implementación de Procedimientos Posteriores) tiene la tarea de completar el trabajo de implementación que conducirá a la creación de la nueva guía para el solicitante, que debería finalizarse a finales de 2025 en previsión de la apertura de la próxima ronda, en 2026.
El IRT celebró múltiples reuniones en las que se debatieron cuestiones como el nuevo acuerdo de registro base (RA). El acuerdo de registro es el que un operador de registro (RO) firma con ICANN para que el RO gestione un dominio de primer nivel durante un periodo de 10 años. Hay multitud de cambios, como es natural, dado el intervalo de 12 años entre la última ronda y la próxima.
El nuevo RA incluirá aspectos como actualizaciones de implementación, cambios de políticas y recomendaciones de la comunidad aprobadas por la Junta Directiva de ICANN, así como novedades operativas. Una de las cuestiones principales era que habrá una nueva especificación 13 al final del acuerdo, relativa principalmente a IDN (Nombres de Dominio Internacionalizados) y que puede haber un TLD primario y una variante, potencialmente hasta cuatro TLD variantes, dependiendo del idioma o script que se utilice.
Otra importante cuestión debatida fue el deseo del Comité Asesor Gubernamental (GAC) de eliminar la controversia siempre que sea posible. Se va a crear el concepto de “cadena de sustitución”, que un solicitante puede presentar junto con su solicitud de nuevo gTLD en la próxima ronda. Al solicitar su cadena primaria u original, también podrá indicar una cadena de sustitución. Y si hay una controversia entre su cadena primaria y otra cadena original en una solicitud de otros, hay una cadena de sustitución secundaria. En la sesión hubo algunas quejas al respecto por parte de la comunidad, ya que añade una complejidad innecesaria. Pero en general se consideró que era una forma de proceder aceptable. Se cree que las marcas que utilicen la especificación 13 podrán solicitar un cambio a la solicitud para obtener su segunda opción de una cadena alternativa en caso necesario. Por ejemplo, en el caso de “delta”: hay múltiples empresas que utilizan la marca delta. Sus opciones secundarias podrían ser algo como “deltaairlines”, si es la aerolínea, o “deltafaucet”, si es el fabricante de grifería.
Otra sesión trató la evaluación de las prioridades de la comunidad, un concepto de la primera ronda por el que si alguien hacía una solicitud como comunidad, podría evitar controversias con candidaturas ajenas a la comunidad. El ejemplo clásico era algo parecido a lo siguiente: el pueblo Apache podría solicitar su propia cadena y ganarla, ya que son una comunidad frente a, por ejemplo, el fabricante de los helicópteros Apache.
La cuestión sigue preocupando a ICANN, porque les expone a potenciales riesgos legales y financieros. Por eso van a sugerir una implementación o cambios, y propusieron realizar una prueba de estrés para saber más sobre cómo funcionarían esos posibles cambios.
Por último, se debatió la divulgación en torno al compromiso para la próxima ronda. En 2024, ICANN y otras entidades organizaron 124 eventos de divulgación, 30 de ellos en octubre. La ICANN sigue divulgando y también ha desarrollado algunos materiales asociados denominados “Champions Toolkit”.
Programa de Apoyo para Solicitantes Próxima ronda
Una de las principales cuestiones que ICANN quiere dar a conocer en la comunidad de Internet en general es la noción del Programa de Apoyo para Solicitantes (ASP). Fue una idea introducida en la primera ronda que ayudó a que regiones o países y naciones infrarrepresentados de todo el mundo pudieran solicitar sus propios TLD. No tuvo mucho uso. En la ronda de 2012 se presentaron tres candidaturas y solo una de ellas superó la prueba.
Desde la primera ronda, ICANN ha desarrollado el proceso para hacerlo más accesible. La idea es que los solicitantes que no tengan los recursos financieros necesarios o que afronten limitaciones de recursos puedan obtener ayuda a través del proceso de solicitud, que podría ser en forma de apoyo financiero o no financiero.
ICANN ha señalado que destinará 5 millones de los ingresos de la subasta de 2012 a financiar la mitad del coste de los solicitantes cualificados. El programa de apoyo para solicitantes se abrió el 19 de noviembre de 2024 y permanecerá abierto durante un año para los interesados en solicitar dicho apoyo. Las personas de la comunidad dispondrán de distintas formas de presentar su solicitud, y podrán recibir ayuda para redactarla y otros medios de apoyo.
Una cuestión en la que se sigue trabajando es la noción de crédito de oferta. Las personas que se acojan al Programa de Apoyo para Solicitantes podrían recibir una bonificación o ayuda durante las posibles subastas, para ponerse más o menos al nivel de otras partes que pudieran tener más respaldo financiero. La Junta y otras partes seguirán trabajando para desarrollar ese aspecto.
Respecto a las subastas, en la próxima ronda no se permitirán las privadas, es decir, las subastas realizadas al margen de los sistemas de ICANN. Además, para resolver conflictos de solicitudes controvertidas, tampoco se va a permitir la creación de empresas conjuntas una vez presentadas las solicitudes. En este espacio hay mucha actividad para garantizar que las subastas sean justas y se consideren un medio en el que las partes no puedan controlarse innecesariamente unas a otras.
Siga este espacio, porque hay mucha actividad en curso. Te cedo la palabra, Prudence.
Proceso de desarrollo de políticas de transferencia, PDP de transferencia
Hablante: Prudence Malinki
Gracias, Chris.
Ya lo han oído. Nada de subastas privadas. Esto es bastante polémico. A algunos sectores de la comunidad les entusiasmaba la idea de una subasta privada, era parte del estímulo para la próxima ronda.
Ahora, hablemos de todo lo relacionado con el PDP de transferencias y veamos, a grandes rasgos, dónde estamos y hacia dónde nos dirigimos. El equipo del PDP de transferencias se reunió durante ICANN81. Ahora estamos revisando los comentarios al informe inicial. Durante esta reunión específica, se trató un tema concreto: la recomendación 27, relacionada con las notificaciones de datos de los registrantes. Revisamos en profundidad la recomendación 27 y examinamos los comentarios y las opiniones de la comunidad.
Durante esta sesión y revisando esos comentarios, hemos constatado principalmente que todavía hace falta debatir más, específicamente en relación con los cambios no autorizados de los datos del registrante. Así que las conversaciones proseguirán. Las revisiones de todos los comentarios e informes iniciales continuarán durante el resto del año.
Prevemos que la presentación puntual del informe final será entre febrero y marzo del año que viene. En los próximos pasos se debatirá cómo aprobar ese informe final una vez creado, dentro de un par de meses, como ya he dicho. El PDP de transferencias avanza a buen ritmo.
Ahora pasaremos de los PDP de transferencias a algo igualmente fascinante: el EPDP-IDN o proceso de desarrollo de políticas acelerado sobre nombres de dominio internacionalizados. Le cedo la palabra a Chris.
Proceso de desarrollo de políticas acelerado sobre nombres de dominio internacionalizados, EPDP-IDN
Hablante: Chris Niemi
Gracias. El EPDP-IDN era una parte crítica de la próxima ronda. En Estambul se completó el informe final de la segunda fase, que fue aceptado por el Consejo de la GNSO.
No voy a entrar en detalles, porque los IDN pueden hacerse muy técnicos y complicados rápidamente. La idea principal es asegurar que en los dominios de nivel superior en alfabetos distintos de ASCII esas variantes existentes se identifican, y que se solicitan y se asignan las partes apropiadas (que ya tienen sistemas y operadores de registro back). Se trata de asegurar que a esos registrantes se les conceden los dominios de segundo nivel correctos que coinciden con las variantes.
Los IDN son una parte importante del programa. Desde 2012, parte del programa general de ICANN ha consistido en establecer más nombres de dominio internacionalizados en todo el sector, para que diversos usuarios del mundo puedan utilizar sus propios idiomas locales. Ese informe se completó y ahora vamos a seguir avanzando en el proceso.
ccNSO, Organización de Apoyo para Nombres de Dominio con Código de País
Hablante: Leanne Kenny
Voy a hablarles muy brevemente del mundo de los ccTLD, con información actualizada sobre algunas de las sesiones de la ccNSO.
Para quienes no estén familiarizados o hayan olvidado qué es la ccNSO, se trata de la Organización de Apoyo para Nombres de Dominio con Código de País. Los integrantes son dominios de alto nivel con código de país (ccTLD): hay 178 miembros y no elaboran políticas. Funcionan independientemente de ICANN. A menudo, se rigen por normativas nacionales en sus propias jurisdicciones; los ccTLD tienen su propio tipo de desarrollo de políticas para su propio registro. Pero esa comunidad colabora para compartir mejores prácticas, compartir formación y compartir experiencias, de modo que todos los ccTLD puedan aprender unos de otros. Eso nos lleva al Comité Permanente sobre el Uso Indebido de DNS (DASC), tarea en la que se centra dicho comité. Su objetivo es compartir información y mejores prácticas sobre cómo intentan mitigar el uso indebido de DNS los administradores de ccTLD.
Por uso indebido de DNS, nos referimos a la definición que utiliza ICANN. El uso indebido de DNS consiste en phishing, pharming, malware, botnets y spam cuando se utiliza como mecanismo de entrega de cualquiera de las formas de uso indebido anteriores. La misión del DASC es concienciar a los administradores de ccTLD sobre el uso indebido de DNS, promover un diálogo abierto y constructivo e intentar ayudar a los ccTLD a mitigar ese uso indebido.
En 2022 hicieron una encuesta que se repitió en 2024. Celebraron un par de sesiones en ICANN81, una de ellas para presentar los resultados de la encuesta. La encuesta se envió a 316 operadores de ccTLD y no era necesario ser miembro de la ccNSO para completarla. Respondieron aproximadamente un tercio de los operadores de ccTLD (entre ellos los de los 10 principales ccTLD), una participación comparable a la de la encuesta de 2022. Como nota positiva, ahora los registros parecen ser mucho más conscientes de los niveles de uso indebido en sus ccTLD. En 2022, el 35 % de los encuestados declararon que no estaban seguros de cuánto uso indebido de DNS había en su ccTLD. Esa cifra se redujo al 21 % en 2024.
Creo que la comisión está bastante satisfecha de que algunos de sus esfuerzos por concienciar sobre este tema empiecen a dar resultados. Ahora bien, en general los ccTLD tienen un nivel bastante bajo de uso indebido de DNS, con una tendencia a la baja, según el NetBeacon Institute. Alrededor del 69 % notificó menos del 0-1 % de uso indebido de DNS en los dominios gestionados en sus registros. Una pequeña salvedad es que, obviamente, son datos de autoevaluación. Hay muchos ccTLD que son muy pequeños y no disponen de los recursos necesarios para medir los niveles de uso indebido de DNS de forma significativa.
No obstante, el comité expresó su confianza en la honestidad y buena fe de las respuestas de los ccTLD a la encuesta. Eso es una noticia positiva. La comunidad de ccTLD parece tener menos niveles de uso indebido de DNS que la comunidad de gTLD más grande. Pero no saben por qué. Hay quienes piensan que podría estar relacionado con la validación de los datos o con el idioma, pero nada en la encuesta lo corroboraba.
Otra sesión fue un taller en el que debatieron en qué centrarse a continuación. Un área de interés es investigar si existe una correlación entre la validación de los datos de los registrantes y la reducción de los índices de uso indebido. También se sugirió la colaboración entre ccTLD y registradores en relación con los procesos de validación de datos. Y el comité pareció tenerla en cuenta. Eso fue muy positivo.
Ahora vamos a hablar de la financiación y del puesto en la Junta. Una de las presentaciones fue sobre la financiación de la ccNSO. En 2010, el CEO de ICANN en aquel momento hizo una declaración sobre si los ccTLD contribuían lo suficiente a los costes de ICANN.
Causó bastante polémica, pero la ccNSO lo asumió. Crearon un grupo de trabajo de finanzas para examinar cuánto le costaba a ICANN mantener los ccTLD en comparación con la contribución que aportaban estos. También examinaron si existían modelos de financiación que pudieran ayudarles a llegar a una cifra tangible. El grupo de trabajo ideó un modelo de intercambio de valor.
El modelo se centraba básicamente en tres tipos de cosas, una especie de intercambio recíproco por así decirlo, entre los ccTLD y la ICANN. Por una parte estaban aspectos concretos, como el hecho de que ICANN proporcione una secretaría a la ccNSO. Por otra, estaban los servicios compartido (cosas como los servicios de IANA y la frecuente labor anfitriona de un registro de ccTLD para la reunión de ICANN). Por ejemplo, la ICANN81 de Estambul fue organizada por el registro de Turquía. Y también aplicaron un punto de vista global, dado que los ccTLD refuerzan la legitimidad de ICANN en un escenario global. Introdujeron ese modelo en 2013, y lo revisaron en 2018. En la presentación de ICANN81 se mencionó la necesidad de tener que revisarlo de nuevo. La estimación actual es que existe un déficit aproximado de 2,6 millones de dólares entre la cantidad que los ccTLD cuestan realmente a ICANN y lo que aportan. Sabemos que algunos ccTLD han reducido su contribución recientemente. Y se están buscando voluntarios para que vuelvan a revisar ese modelo. El plan es que presenten sus conclusiones en ICANN82, en Seattle. Sigan este espacio para ver los resultados.
Y como ya ha mencionado Prudence, hay una vacante en la Junta. Hay dos candidatos, ambos veteranos del sector. Se trata de Byron Holland, Presidente y Director General de CIRA, el registro canadiense. Y de Nick Wenban-Smith, Consejero General de Nominet, del registro .uk.
Ambos participaron en una sesión de preguntas y respuestas. Fue interesante: se plantearon las preguntas que cabría esperar en cuanto a cómo gestionarían los conflictos, de forma similar a la GNSO, y cuánto tiempo podrían dedicar a la Junta. Se estima que se requieren de dos días a 20 horas semanales. También hubo preguntas relativas a sus habilidades, su experiencia previa y lo que pueden aportar a la Junta. Los próximos pasos de esa votación comienzan el martes 4 de febrero y se cierran el martes 18. El candidato elegido ocupará el puesto hasta 2027. En cuanto a la actitud general entre los asistentes, creo que la ccNSO está muy satisfecha de tener dos candidatos tan buenos y, al igual que la GNSO, no está a falta de opciones. Les gustaría elegir a los dos, pero no pueden.
Cuestiones de Acreditación de Servicios de Privacidad y Representación, PPSAI
Hablante: Prudence Malinki
Muchas gracias por ponernos al día, Leanne. Nunca faltan cosas interesantes en el entorno de ICANN.
Hablemos de todo lo relacionado con PPSAI. El equipo de PPSAI se encarga de revisar la implementación de servicios de privacidad y los servicio proxy o de representación, y la acreditación (o creación de acreditaciones o normalización) de cómo utilizamos e implementamos estos servicios en todo el ámbito y en toda la comunidad.
Es un grupo muy activo y, como vemos en la diapositiva, hay más de 50 participantes que cubren toda la esfera global de ICANN. Tuvimos una sesión muy amena durante la reunión de ICANN. Se habló de los diferentes modelos de negocio y formas de utilizar los servicios de privacidad y proxy, y de los diferentes casos y retos afrontados al intentar obtener datos cuando se utiliza un servicio de privacidad o proxy. Los registradores explicaron la diferencia entre la implementación de un servicio de privacidad y la de un servicio proxy. Las reuniones de este grupo comenzaron en junio de este año, por lo que es un grupo incipiente y aún tienen muchas cosas que tratar, incluidas las diferencias entre privacidad y proxy.
Aún queda mucho por aprender. Una de las razones por las que el grupo ha vuelto a reunirse es la implementación de esta política. No se trata de crear una política nueva. Teniendo en cuenta los modelos actuales (por ejemplo, las políticas de datos surgidas recientemente con respecto a los datos de registro; o legislación como el GDPR y el NIS2), tenemos que ver si tienen un impacto en nuestra implementación de los servicios de privacidad y los servicios proxy.
Como vemos en la diapositiva, estamos considerando varias cuestiones básicas. Sin embargo, el IRT todavía está tratando de limar asperezas sobre lo que significa tener un proxy y lo que significa tener un servicio de privacidad. No voy someter a examen a los participantes de hoy preguntándoles cuál es cuál, pero sí voy a expandirme y proporcionar un poco más de contexto.
Un servicio de privacidad es uno en el que un registrador utiliza sus propios datos de registro, o los de una filial, para ocultar la información de registro de sus clientes. Creo que este es el servicio en el que piensa la mayoría de la gente al oír “proxy”, pero realmente significa privacidad. En estos casos, el registrador sabe quién es el cliente.
En el caso de un servicio proxy, una persona registra un nombre de dominio en nombre de otra. Esa persona o proxy irá al registrador para registrar el nombre de dominio en nombre de otra persona. Sin embargo, en este caso, el registrador no sabe a quién representa el proxy, ni quién es el tercero en nombre del que se registra el dominio. Eso significa que, a todos los efectos, el registrador parte de la premisa de que el registrante es la persona que ha acudido a él y ha registrado el nombre, sin saber que hay otra parte implicada y, sobre todo, sin conocer su identidad.
Los servicios proxy y los servicios de privacidad son ligeramente diferentes y tienen obligaciones ligeramente distintas. Actualmente se discute si estos servicios entran o no en el ámbito que nos ocupa. Obviamente, un servicio de privacidad entra dentro del ámbito, y todos los participantes están muy a favor de crear nociones estandarizadas sobre cómo se implementan los servicios de privacidad, para garantizar los niveles de calidad y la coherencia en general.
Cuando se trata de servicios proxy, esto se vuelve un poco más complejo. Aunque parte del equipo de revisión de la implementación quiere asegurarse de que incluimos a los proxy, hay dificultades para hacerlo de forma realista, especialmente cuando los registradores no saben quién es el registrante final.
Va a ser un equipo muy interesante. Sigan todo lo relacionado con PPSAI porque va a ser muy interesante a medida que avancemos. Como ya he dicho, todo esto está en sus fases iniciales. Pero les mantendremos al tanto de todos los avances importantes y nos aseguraremos de que, si hay algún cambio destacado en la forma de implementar los servicios de privacidad para sus nombres de dominio, se lo comunicaremos y nos aseguraremos de que reciban y mantengan un nivel de servicio útil para ustedes. Y ahora pasemos a la siguiente diapositiva, para hablar de los datos de registro.
Servicio de Solicitud de Datos de Registración, RDRS
Este fue uno de los temas más candentes de la reunión de ICANN. En breve, Heidi nos hablará de novedades del GAC y la perspectiva del GAC sobre el asunto, que figuraba en el comunicado. El RDRS se creó porque el sistema de solicitud original —SSAD (Sistema Estandarizado de Acceso/Divulgación)— se consideraba demasiado costoso de implementar y difícil de aplicar de forma realista.
Así que creamos el sistema RDRS. Se suponía que iba a ser un proyecto piloto —algunos lo llaman experimento o prueba— de dos años y ya llevamos un año con él. Hace un año que utilizamos el sistema RDRS. Pero, ¿qué significa eso?
Se supone que es un sistema de solicitud estandarizado. Lo que no hace es garantizar que los registradores proporcionen los datos de registro solicitados. Gabe, del GAC, proporcionó una valiosa estadística de uso durante la reunión, que reproducimos aquí. Esta estadística refleja los problemas a los que se ha enfrentado el RDRS, con respecto a la comprensión de lo que puede y no puede hacer.
Hablemos de los inconvenientes en relación con las solicitudes habituales. Quiero comentar un par de cosas sobre este gráfico en concreto. Una de ellas es que durante esta reunión hubo muchas peticiones implícitas y extraoficiales para poner fin al proyecto piloto de RDRS. Porque ciertas partes y elementos de la comunidad creen que no ha tenido éxito y opinan que deberíamos abandonarlo y pasar a lo siguiente. Lo que pasa es todavía no tenemos lo siguiente: técnicamente aún no existe. Por eso tuvimos que trabajar como comunidad y decidir qué íbamos a hacer.
Uno de los resultados realmente positivos de una sesión de la Junta fue aclarar que el RDRS se seguirá utilizando mientras la Junta toma una decisión sobre si centrarse en el SSAD o utilizar el RDRS en adelante como sistema de solicitud estandarizado. Como vemos, las peticiones siguen llegando, por lo que necesitamos algún tipo de sistema. Pero, afortunadamente, de momento el RDRS no va a desaparecer. ¿Se mantendrá? No lo sabemos. Pero el resto se mantendrá, no se va a suprimir inmediatamente, en contra de ciertos rumores que circularon durante la reunión. En la comunidad hay bastante gente descontenta con el RDRS. Eso se debe a muchas razones. Una de ellas, demostrada en este gráfico, es la falta de conocimientos con respecto a lo que el RDRS puede y no puede hacer.
Miren este gráfico. Solo voy a comentar generalidades de estos números. El número alto en el extremo izquierdo es alrededor de 18 000. Estamos tratando con volúmenes muy elevados de consultas iniciales o de personas que hacen búsquedas iniciales de dominios para comprobar si están ahí. Aquí es donde entra en juego la educación, ya que de esas 18 000 solicitudes se pueden descartar inmediatamente más de 10 000. Se trata de solicitudes relativas a TLD que están completamente fuera del ámbito de aplicación, como ccTLD o TLD que no forman parte del sistema. Otra cosa que se ha destacado es que el RDRS es optativo, no obligatorio. Markmonitor es parte de ese servicio, y varios registradores de Newfold también. Pero no es obligatorio.
Aquí se ve que alrededor de 4 000, casi 5 000, de esas solicitudes son a registradores que no están implicados. Eso significa que si usted está en el sistema e introduce un dominio, no obtendrá un resultado porque ese registrador no está dado de alta. Y si no está dado de alta, usted no va a poder enviarle esa solicitud normalizada porque el registrador no está utilizando ese sistema.
De las 18 000 solicitudes, alrededor de 5 000 de los dominios están ahí y son aptos, Eso es bueno. Pero ocurre algo realmente interesante: de esas 5 000 solicitudes, aunque los dominios están en el sistema, por razones que desconocemos solo se envían solicitudes a una parte de ellos. 2 000 de los 5 000 tienen la solicitud hecha, pero alrededor de 3 000 no están haciendo ninguna solicitud. De las 18 000 iniciales solo se aprueban unas 400.
Si se examinan las razones por las que se deniegan las solicitudes, la inmensa mayoría se debe a que no hay suficiente información en la solicitud. En unos 500 casos se necesita más información, pero no se ha facilitado en el momento de presentar la solicitud, por lo que no se pueden dar los datos del registro.
Es revelador ver una instantánea de lo que ha estado sucediendo en relación con el uso y los niveles de educación requeridos en relación con el RDRS de cara al futuro. Pero, como he dicho antes, no ha dejado de existir. Va continuar hasta que la Junta averigüe qué le seguirá. Y Becky hizo un comentario relevante: tenemos una buena cantidad de datos. Están contentos con los datos. Hasta ahora están contentos con los resultados. Pero no está claro si van a utilizar estas infraestructuras para ayudar con el SSAD o si van a mantener el método del RDRS. Les mantendremos al tanto y, si necesitan ayuda para desenvolverse con el RDRS, pueden consultar con su gestor de cuenta, para intentar maximizar sus probabilidades de éxito. En caso de tener que solicitar datos a un registrador, ponemos nuestra experiencia a su disposición.
Protocolo de acceso a datos de registro, RDAP
Sería negligente por mi parte no mencionar el RDAP después de hablar del RDRS. Para quienes no lo sepan: RDAP es el sucesor de WHOIS. En 2025 está prevista la retirada parcial de WHOIS y la transición al sistema RDAP. Sin embargo, aún no hay nada confirmado. Podría haber un retraso en el calendario del RDAP que afectará a su lanzamiento el próximo año, ya que está pendiente la cuestión del cumplimiento de los registradores y de los requisitos relativos al RDAP. Pero de momento no hay nada concretado. Seguimos ateniéndonos a estos plazos, pero ha habido rumores de que podrían cambiar. Emoción y suspense…
Pasemos a la siguiente diapositiva y hablemos de la situación actual de la Política de Datos de Registro. La entrada en vigor de la nueva política está prevista para agosto de 2025. Es el resultado directo de esas cuatro letras por las que tanto apego siento: RGPD.
Ahora veamos los registros. Los registros tienen básicamente dos opciones en cuanto a la forma de gestionar los datos de los registrantes. Pueden mantener un repositorio de toda la información de los registrantes o limitarla a un conjunto mínimo de datos. Y pueden elegir cómo hacerlo. Actualmente, aproximadamente el 38 % de los registros han indicado qué vía quieren seguir. Google Registry, Radix y creo que PIR, en parte, han revelado que van a pasar a un conjunto mínimo de datos. Les mantendremos al tanto de la evolución.
Otro tema muy candente durante la reunión de ICANN fue el del contacto de facturación. Durante las conversaciones del grupo de políticas de registro, resultó que no está del todo claro cuáles son las obligaciones que tienen los registradores de reunir información del contacto de facturación. Se anunció que existe la posibilidad de que se publique un aviso que, sin prescribir nada categóricamente, puede utilizarse como herramienta para ayudar a los registradores a decidir qué hacer con el contacto de facturación. Recordemos que un aviso es meramente orientativo. No es una política, no es algo inamovible en sí mismo, pero puede servir para orientar las decisiones. Esa es la situación actual respecto a la Política de Datos de Registro.
Ahora pasaremos a hablar de todo lo relacionado con el Comunicado del GAC. Heidi nos lo explica.
Comunicado del GAC en ICANN81
Hablante: Heidi Zhang
Gracias, Prudence.
GAC son las siglas inglesas de Comité Asesor Gubernamental. No es un órgano de toma de decisiones, simplemente asesora a ICANN. Las sesiones del GAC se celebran en todas las reuniones de ICANN y este año han sido relativamente ligeras. Asistieron a la reunión 69 miembros del GAC y seis observadores. Y se celebraron las elecciones anuales a la Vicepresidencia. Se eligieron cinco Vicepresidentes, de Australia, Colombia, Países Bajos, Egipto y Suiza.
Se hizo una sugerencia en relación con la titularidad, ya que actualmente el mandato del Presidente del GAC es de dos años y el del Vicepresidente es de un año. Muchos de los miembros dicen que el mandato es demasiado corto porque hay muchas cuestiones y temas en curso en el GAC. Y creen que la duración de los mandatos actuales no es suficiente para que los miembros hagan contribuciones y hagan seguimientos de los temas y las preguntas. De momento, la prolongación del mandato no es una sugerencia formal, pero la recomendación es prorrogar dos años la Presidencia y la Vicepresidencia. Los miembros del GAC necesitarán más tiempo para debatirlo en sus reuniones fuera de línea y en el futuro.
Como acabo de mencionar, las sesiones del GAC fueron bastante ligeras en ICANN81. No se hizo ninguna recomendación final a la Junta. El GAC celebró sus reuniones y debates habituales con la Junta General, las Organizaciones de Apoyo (OA), la Cámara de Partes Contratadas (CPH) y el Comité Asesor de Seguridad y Estabilidad (SSAC).
Para el GAC, la próxima ronda de nuevos gTLD es un tema candente al que han dedicado mucho tiempo. El GAC aprecia realmente todos los esfuerzos de ICANN para difundir el programa, pero la cuestión principal actualmente es cómo ayudar a las regiones y países necesitados de esas iniciativas de difusión. El GAC recomienda que ICANN se alinee con los miembros del GAC para encontrar el objetivo adecuado para esas regiones y países, y elabore planes personalizados para ellos.
También se debatieron las tarifas de solicitud y evaluación para la próxima ronda. La tarifa de solicitud será de 227 000 USD y podría haber una exención máxima del 85 %, lo que supondría unos 34 000 dólares. Al GAC le sigue preocupando que incluso esa cantidad suponga un reto para algunos de los solicitantes de los países y regiones necesitados, especialmente porque además de la tarifa de solicitud habrá otras tasas y costes, como la tasa del RSP (Programa de Evaluación de Proveedores de Servicios de Registro), el coste de custodia de datos, los honorarios de consultoría, etc. Cómo apoyar a los solicitantes de esos países y regiones es un gran problema. El GAC sugiere a ICANN que implique realmente a la comunidad inversora para que ayude, y también que averigüe la forma adecuada de poner en contacto a las entidades de financiación con los solicitantes cualificados para utilizar su asistencia y apoyo. Es un gran problema.
Quiero mencionar las subastas privadas. Como ya ha dicho Chris, el tema de las subastas preocupa al GAC. El GAC quiere intentar evitar por todos los medios las subastas privadas, por lo que acoge con gran satisfacción la propuesta de cadena alternativa.
Y el último tema del que quiero hablar, relacionado con el GAC, se refiere al nombre de dominio y los datos de registro. Prudence ha hablado extensamente del RDRS y yo puedo decirles algo de la perspectiva del GAC al respecto. El RDRS se encuentra a mitad de camino en el proyecto piloto y el GAC está realmente interesado en las mejoras. Quiere saber cuál será el sistema estandarizado definitivo para el acceso y la divulgación de los datos de registro. El RDRS no tiene por qué ser la solución definitiva, y el GAC está abierto a desarrollos y cambios. Habrá que esperar a ver qué pasa. Eso era lo que quería comentar sobre el GAC. Le cedo la palabra al equipo.
Novedades sobre Web3 y ICANN
Hablante: Chris Niemi
Como ha dicho Prudence, Shane —nuestro experto en Web3— no pudo estar presencialmente en la reunión ICANN81, pero tuvo la amabilidad de proporcionar una rápida puesta al día sobre lo que está sucediendo en el espacio de cadena de bloques.
Este tema se ha ido desarrollando a lo largo de los años. En un principio, ICANN no demostraba mucho interés al respecto, pero ahora parece más orientada al espacio de cadena de bloques. La sesión estuvo muy concurrida. Creo que no había asientos vacíos. La sala estaba abarrotada, algo que no siempre ocurre en algunas de estas sesiones de la comunidad. Puedo dar una descripción bastante neutra, o tal vez positiva, de lo que está ocurriendo en el espacio Web3, es decir, no en la Internet tradicional o Web2 o en los dominios oficiales de primer nivel de DNS. Se debatió cómo deberían llamarse los dominios de Web3, con sugerencias como “identificadores de billetera” o “identificadores de Web3”
En la sesión se habló sobre raíces alternativas o TLD alternativos del pasado, ya que en los últimos 20 años ha habido diferentes intentos de proporcionar servicios alternativos que imiten al DNS. Pero la cuestión más importante debatida fue la de las colisiones de nombres. Existen distintos servidores de resoluciones que proporcionan resultados diferentes según dónde se consulte un determinado identificador de billetera de Web3. Pero hay un tipo de registro DNS específico llamado “wallet RR type”.
O sea que hay una tendencia a una mayor colaboración. El debate más amplio trató sobre cómo va a desarrollar la comunidad una especie de política en torno a este tema. ¿Qué va a pasar? ¿Cómo afectará a la próxima ronda? Hay muchos desarrollos pendientes en este espacio y seguiremos atentos para ver cómo interactúa ICANN con este tema en particular.
Participe en ICANN y otros grupos de políticas
Como ha dicho Prudence, aconsejamos a nuestros clientes que participen en el proceso de desarrollo de políticas. Hay varias formas de hacerlo. Una es uniéndose a la comunidad de ICANN, como se muestra en la pantalla. Las partes interesadas en la propiedad intelectual pueden unirse a la unidad constitutiva de propiedad intelectual o IPC.
Los usuarios comerciales de Internet pueden unirse a la BC (Business Constituency) para expresar sus opiniones. Otra forma de unirse es a través del Brand Registry Group, formado por las partes que tienen su propio TLD dotBrand o que están interesadas en solicitar un dominio dotBrand en la próxima ronda (como incentivo: si se unen al BRG y asisten a las reuniones de ICANN, les invito a una buena comida). Animamos a todos los que siguen este webinar a aprovechar la oportunidad de unirse a cualquiera de estos grupos de políticas. Les ayudaremos y orientaremos en la dirección correcta. Ahora les dejo con Prudence para la conclusión de este webinar.
Actualizaciones y comentarios finales de ICANN81
Siempre digo que nosotros asistimos a las reuniones de ICANN para que ustedes no tengan que hacerlo, pero queremos que nos acompañen y que disfruten, porque esto es muy divertido. Y están ocurriendo muchas cosas interesantes: intercambios de poder, nuevo CEO, nuevos miembros de la Junta Directiva, miembros del GAC que quieren una permanencia de 2+2 en el cargo… Todo eso es fascinante. Animamos a todos nuestros clientes a que se impliquen y participen en las políticas con nosotros.
Un par de cosas: Mi reconocimiento a Ram, que hizo un trabajo ejemplar de divulgación y comunicación para el SSAC. Quiero estar en el SSAC. Ustedes deberían estar en el SSAC. Todos deberíamos estar en el SSAC. SSAC es lo mejor que hay. ¿Se nota que me entusiasma? También quiero aludir a uno de los temas que he pasado por alto, el de la plataforma Domain Metrica, cuya puesta en marcha generó mucha polémica. Les mantendremos al tanto de cómo funciona Domain Metrica, y hablaremos de qué es y en qué consiste un poco más adelante, ya que fue otro tema candente durante la reunión de ICANN.
Hablando de reuniones de ICANN, la próxima tendrá lugar en la maravillosa Seattle, en marzo del año que viene. Acompáñenos allí. Si no puedes venir, siga el webinar de resumen para participar. Lo hacemos en su beneficio. Creamos estos contenidos para ustedes. Pueden ayudarnos a hacerlos lo más relevantes posible para ustedes. Si hay algún tema en el que quieran que profundicemos, solo tienen que decírnoslo. Si hay algún área que quieren que tratemos o creen que no se ha tratado adecuadamente, hágannoslo saber.
Y con esto ponemos fin a nuestro webinar. Muchas gracias por participar y estar con nosotros.
