Skip to main content
Resources

Actas | Reunión Ordinaria de la Junta Directiva de la ICANN

Esta página está disponible en:

Este documento ha sido traducido a varios idiomas como información únicamente. El texto original y válido (en inglés) se puede obtener en: http://www.icann.org/en/groups/board/documents/resolutions-28sep13-en.htm

 

  1. Orden del Día Convenido
    1. Aprobación de las Actas de las Reuniones de la Junta Directiva
    2. Delegación de un Dominio de Alto Nivel con Código de País (ccTLD) para Irán en escritura árabe
    3. Recomendaciones de PDP de la GNSO para el Bloqueo de un Nombre de Dominio Sujeto a Procedimientos de UDRP
    4. Implementación de la Revisión de la Organización de Apoyo para Nombres de Dominio con Código de País (ccNSO)
    5. Revisión de la GNSO
  2. Orden del día principal
    1. Designación del Presidente y Presidente-Electo del Comité de Nominaciones para el año 2014
    2. Tratamiento de los Costos Históricos de los Nuevos gTLD
    3. Proceso Propuesto para las Enmiendas a los Estatutos del Grupo de Partes Interesadas y las Unidades Constitutivas de la GNSO
    4. Aclaración Respecto de los Criterios de Medición de Competencia, Confianza del Consumidor y Elección del Consumidor para el Programa de Nuevos gTLD de Conformidad con la Revisión establecida en la AoC

 

  1. Orden del Día Convenido:

    1. Aprobación de las Actas de las Reuniones de la Junta Directiva

      Resuélvase que (2013.09.28.01), La Junta Directiva apruebe las actas de las Reuniones de la Junta Directiva de la ICANN celebradas el 17 y 18 de julio y 22 de agosto de 2013.

    2. Delegación de un Dominio de Alto Nivel con Código de País (ccTLD) para Irán en escritura árabe

      Resuélvase que (2013.09.28.02), como parte del ejercicio de sus responsabilidades según lo establecido en el Contrato de Funciones de la IANA, la ICANN ha revisado y evaluado la solicitud para delegar el dominio de alto nivel con código de país ایران ('Irán') al Instituto para la Investigación en Ciencias Fundamentales. La documentación demuestra que se siguieron los procedimientos adecuados durante la evaluación de la solicitud.

      Resuélvase que (2013.09.28.03), la Junta Directiva dispone que, conforme al Artículo III, Sección 5.2 de los Estatutos de la ICANN, ciertos fragmentos de los fundamentos no apropiados para divulgación pública en las resoluciones, el informe preliminar o las actas en este momento debido a obligaciones contractuales, sean retenidos hasta tanto se autorice su divulgación pública de acuerdo con dichas obligaciones contractuales.

      Fundamentos de las resoluciones 2013.09.28.02 – 2013.09.28.03

      ¿Por qué la Junta Directiva está abordando ahora la cuestión?

      De acuerdo con el Contrato de Funciones de la IANA, el personal de la ICANN ha evaluado una solicitud de delegación de un dominio de alto nivel con código de país (ccTLD) y presenta su informe ante la Junta Directiva para revisión. La revisión por parte de la Junta Directiva tiene por objetivo verificar que el personal de la ICANN haya seguido los procedimientos adecuados.

      ¿Cuál es la propuesta que se somete a consideración?

      La propuesta consiste en aprobar una solicitud al Departamento de la IANA de la ICANN para crear el dominio de alto nivel con código de país y asignarle el rol de organización patrocinadora (también conocida como gerente o administrador) al Instituto para la Investigación en Ciencias Fundamentales.

      ¿Cuáles son las partes interesadas u otros participantes consultados?

      Durante la evaluación de una solicitud de delegación, el personal de la ICANN consulta al solicitante y a otras partes interesadas. Como parte del proceso de solicitud, el solicitante debe describir las consultas realizadas en el país correspondiente al ccTLD y su aplicabilidad a la comunidad local de Internet.

      ¿Qué inquietudes o cuestiones mencionó la comunidad?

      El personal no tiene conocimiento de ninguna inquietud o cuestión significativa planteada por la comunidad en relación con esta solicitud.

      [Se omiten los fundamentos].

      ¿Qué factores considera importantes la Junta Directiva?

      La Junta Directiva no identificó ningún factor específico importante respecto de esta solicitud.

      ¿Se observan impactos positivos o negativos en la comunidad?

      La aprobación oportuna de administradores de nombres de dominio con código de país que cumplen con los diversos criterios de interés público tiene un impacto positivo para la misión de la ICANN a nivel general y para las comunidades locales a las que están destinados dichos dominios de alto nivel con código de país, y responde a las obligaciones de la ICANN previstas en el Contrato de Funciones de la IANA.

      ¿Se observan impactos financieros o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad y/o el público?

      La administración de las delegaciones de dominios con código país en la zona raíz del DNS forma parte de las funciones de la IANA y, por ello, la acción de delegación no debería causar variaciones de importancia en los gastos ya planificados. No corresponde a la ICANN evaluar el impacto financiero de las operaciones internas de los nombres de dominio con código de país dentro de un país.

      ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      La ICANN considera que esta solicitud no implica riesgos significativos para la seguridad, estabilidad o flexibilidad.

      Esta decisión forma parte de las funciones administrativas y organizacionales que no requieren comentarios públicos.

    3. Recomendaciones de PDP de la GNSO para el Bloqueo de un Nombre de Dominio Sujeto a Procedimientos de UDRP

      Visto y considerando que, el 15 de diciembre de 2011, el Consejo de la Organización de Apoyo para Nombres Genéricos (GNSO) lanzó un Proceso de Desarrollo de Políticas (PDP) sobre el Bloqueo de un Nombre de Dominio Sujeto a Procedimientos de UDRP que aborda cinco cuestiones del estatuto, establecidas en https://community.icann.org/x/ma-bAQ.

      Visto y considerando que, el PDP siguió los pasos establecidos para dicho proceso, de acuerdo con lo indicado en los Estatutos y generó el Informe Final que fue presentado el 5 de julio de 2013.

      Visto y considerando que, el Grupo de Trabajo (WG) sobre el Bloqueo de un Nombre de Dominio Sujeto a Procedimientos de UDRP alcanzó el consenso total respecto de las recomendaciones relacionadas con las cinco cuestiones establecidas en los Estatutos.

      Visto y considerando que, el Consejo de la GNSO examinó y debatió las recomendaciones del Grupo de Trabajo (WG) sobre el Bloqueo de un Nombre de Dominio Sujeto a Procedimientos de UDRP y adoptó las Recomendaciones el 1 de agosto de 2013 por amplia mayoría y voto unánime (Véase: http://gnso.icann.org/en/council/resolutions#201308).

      Visto y considerando que, el voto del Consejo de la GNSO alcanzó y superó el límite de votos requerido para imponer nuevas obligaciones a las partes contratadas de la ICANN.

      Visto y considerando que, con posterioridad a la votación del Consejo de la GNSO, comenzó el período establecido para recibir comentarios públicos sobre las recomendaciones aprobadas y que dichos comentarios fueron resumidos y sometidos a consideración (http://www.icann.org/en/news/public-comment/locking-domain-name-recommendations-02aug13-en.htm).

      Resuélvase que (2013.09.28.04), la Junta Directiva adopta las Recomendaciones de Políticas del Consejo de la GNSO sobre el Bloqueo de un Nombre de Dominio Sujeto a Procedimientos de UDRP, tal como se indica en el Informe Final (véase http://gnso.icann.org/es/issues/locking/domain-name-final-05jul13-es.pdf). [PDF, 1.21 MB]

      Resuélvase que (2013.09.28.05), el Presidente y Director Ejecutivo debe desarrollar y completar un plan de implementación para estas Recomendaciones y se debe mantener comunicado con la comunidad con relación a dicha tarea.

      Fundamentos de las Resoluciones 2013.09.28.04 - 2013.09.28.05

      ¿Por qué la Junta Directiva está abordando ahora esta cuestión?

      En la actualidad, no existe ningún requisito para bloquear nombres en el período comprendido entre la presentación de la denuncia y la apertura del procedimiento, ni una definición de "statu quo", que haya dado lugar a diferentes interpretaciones y a la confusión de la política. Para abordar esta cuestión, el Consejo de la GNSO decidió iniciar un Proceso de Desarrollo de Políticas (PDP), el 15 de diciembre de 2011. Como parte de sus deliberaciones, el Grupo de Trabajo (WG) debió considerar las siguientes preguntas:

      1. Si fuera deseable la creación de un esquema para un procedimiento propuesto que el demandante deba seguir para que un registrador bloquee un nombre de dominio.

      2. Si fuera deseable la creación de un esquema con los pasos del proceso que un registrador pueda razonablemente esperar que se lleven a cabo durante una disputa de UDRP.

      3. Si debe estandarizarse el período durante el cual un registrador debe bloquear un dominio luego de que se haya presentado una UDRP.

      4. a. Si debe definirse lo que constituye un nombre de dominio "bloqueado".

        b. Si, una vez que el nombre de dominio es "bloqueado" según lo establecido en un procedimiento de UDRP, la información del registratario debe modificarse o cambiarse.

      5. Si se deben crear medidas de protección adicionales para la protección de los registratarios en casos donde el nombre de dominio esté bloqueado sujeto a un procedimiento de UDRP.

      El Grupo de Trabajo publicó su Informe Inicial para recibir comentarios del público el 15 de marzo de 2013, seguido de su Informe Final, el 5 de julio de 2013, que recibió el apoyo unánime por consenso del Grupo de Trabajo de Desarrollo de Políticas (PDP WG), así como del Consejo de la GNSO. Con posterioridad al cierre del período de comentarios públicos, la siguiente etapa, según lo establecido en el Anexo A de los Estatutos de la ICANN, es someter las recomendaciones a consideración de la Junta Directiva de la ICANN.

      ¿Cuál es la propuesta que se somete a consideración?

      Las siguientes recomendaciones se han sometido a consideración:

      Recomendación Nro. 1: En este contexto, el término "bloqueo" significa impedir cualquier cambio de registrador y registratario. Este "bloqueo" no debe poner en peligro la resolución del nombre de dominio únicamente porque se ha presentado un reclamo según el UDRP o únicamente porque hay un proceso de UDRP en curso.1

      Recomendación Nro. 2: Modificar la disposición de las reglas de UDRP que especifica que, ante la presentación de un reclamo ante el Proveedor de Servicios de UDRP, el Demandante también debe 'declarar que una copia del reclamo […] ha sido enviada o transmitida al demandado' (sección 3, b – xii) y recomendar, como mejor práctica, que los demandantes no necesitan informar a los demandados acerca de la presentación de un reclamo, a los efectos de evitar la práctica de "cyberflight" (transferencia intencional del nombre de dominio por parte del titular con el fin de evitar ser demandado). El Proveedor de Servicios de UDRP será el responsable de informar al Demandado la apertura oficial de los procedimientos.

      Recomendación Nro. 3: Tras la recepción del reclamo, y luego de efectuar una verificación preliminar de deficiencias2, el Proveedor de Servicios de UDRP enviará una solicitud de verificación al Registrador, la cual incluirá una solicitud de evitar todo cambio de registrador y registratario para el registro del nombre de dominio ("bloqueo"). El registrador no tiene permitido notificar al registratario acerca del procedimiento pendiente hasta tanto se haya logrado evitar cualquier cambio de registrador y registratario; no obstante, el registrador podrá proceder con la notificación una vez evitados los cambios de registrador y registratario. En el caso de los proveedores de servicios de privacidad/ representación acreditados3 o de un proveedor de servicios de privacidad / representación relacionado con el registrador, el registrador podrá contactar al proveedor de servicios de privacidad / representación acreditado o relacionado para permitir la divulgación de los datos del cliente que solicitó los servicios de representación. Sin embargo, dicho contacto solamente podrá establecerse una vez que se haya aplicado el bloqueo inicial, evitando de esa forma cualquier cambio de registrador y registratario.

      Recomendación Nro. 4: Dentro de un plazo máximo de dos días laborales4 posteriores a la recepción de la solicitud de verificación por parte del Proveedor del Servicio de UDRP, el Registrador modificará el estado de la registración con el fin de evitar cualquier cambio de registrador y registratario ("bloqueo"). El Registrador debe continuar evitando cambios a lo largo del plazo de vigencia restante del Procedimiento de UDRP, excepto en el caso de una suspensión del procedimiento de UDRP (véase la recomendación Nro. 10). El plazo de vigencia comienza a partir del momento en el cual un reclamo sometido al procedimiento de UDRP, o un documento pertinente que dé inicio a procedimientos judiciales o arbitrales, es presentado por el Demandante ante el Proveedor de Servicios de UDRP, según el caso. Cualquier actualización5 que resultare de una solicitud cursada por el proveedor de servicios de privacidad / representación acreditado/relacionado con el fin de divulgar los datos del cliente de servicios de representación, debe ser efectuada antes de que venza el plazo de dos días laborales, o bien antes de que el registrador verifique la información solicitada y confirme el bloqueo al Proveedor de Servicios de UDRP, lo que ocurra primero.

      Un registrador no podrá permitir la transferencia a otro registratario6 o registrador una vez recibida la solicitud de verificación enviada por el Proveedor de Servicios de UDRP al Registrador, excepto en circunstancias acotadas que impliquen un arbitraje que no se lleve a cabo de conformidad con la Política o que impliquen un litigio, tal como se estipula en los párrafos 8(a) u 8(b) de la Política de UDRP. A los efectos de la UDRP, el Registratario que figure en el registro de Whois al momento del bloqueo será considerado como Demandado(s). Cualquier cambio efectuado a la información de Whois durante la vigencia del procedimiento administrativo de conformidad con la Política será permitido o prohibido sobre la base de las políticas y los contratos aplicables del registrador; sin embargo, es responsabilidad del Registratario (Regla (e) y Regla 5(b) (ii) de la UDRP) informar al Proveedor de toda actualización relevante que pueda afectar a las notificaciones u obligaciones del proveedor para con el acusado de conformidad con la UDRP.

      Dependiendo de los términos del servicio de Representación /Privacidad, un Registrador podrá optar por revelar los datos subyacentes como resultado de servicios de privacidad  / representación al Proveedor o en el Whois, o de ambas maneras, si tiene conocimiento de ello. Esto no cuenta como una "transferencia", en violación de lo anterior, en caso de producirse, de acuerdo con la recomendación preliminar Nro. 2. Si se revela un servicio de privacidad/ representación, o si se da a conocer la información de un cliente de servicios de representación luego de que se aplique el Bloqueo, y se notifica al Proveedor, el Proveedor no está obligado a requerir al Demandante que modifique su reclamo en consecuencia, pero podrá hacerlo a su criterio. Es responsabilidad del Registratario (Regla 2(e) y Regla 5(b)(ii) de la UDRP) informar al proveedor de toda actualización pertinente que pueda afectar a las notificaciones y obligaciones del proveedor para con el Demandado de conformidad con la UDRP; asimismo, el proveedor, de conformidad con la UDRP, deberá proporcionar al Demandado la información del caso con el nivel de detalle que prefiera una vez que el Proveedor esté al tanto de la actualización (El ítem 5(b)(iii) de la UDRP )requiere que el proveedor envíe las comunicaciones al correo electrónico preferido del Demandado, por ejemplo).

      Recomendación Nro. 5: Como práctica recomendada, se alienta a los registradores y Proveedores de Servicios de UDRP a proporcionar un medio que permita a terceros identificar cuál es el horario / día de apertura, durante el cual es posible esperar que se realicen tareas de UDRP.

      Recomendación Nro. 6: El registrador debe confirmar al Proveedor de Servicios de UDRP, dentro de los dos días laborales de recibida la solicitud de verificación7 por parte del Proveedor de UDRP, que todo cambio de registrador y registratario ha sido evitado, y será evitado, durante la vigencia del procedimiento y el Registrador deberá verificar8 la información solicitada por el Proveedor de Servicios de UDRP.

      Recomendación Nro. 7: De corresponder, el proveedor de la UDRP enviará el reclamo al Registrador y al Demandado, y los notificará del comienzo del procedimiento administrativo dentro de un plazo máximo de tres días laborales9 luego de haberse recibido el pago de los honorarios correspondientes por parte del Demandante.

      Recomendación Nro. 810: Se concederá a los Demandados que participen de la UDRP una opción expresa de solicitar una prórroga de cuatro días si así lo deciden, por lo que cualquier solicitud de extensión de cuatro días recibida se concederá de forma automática, y el Proveedor de UDRP extenderá el plazo correspondiente, sin costo alguno para el Demandado. La disponibilidad de dicha opción de prórroga automática de cuatro días a petición también debe ser señalada por el Proveedor de UDRP dentro de la información del Demandado al inicio del proceso y no será un impedimento para que el Proveedor de UDRP conceda alguna otra extensión adicional, según lo dispuesto en el artículo 5d de las Reglas de UDRP.

      Recomendación Nro. 9: Si la demanda persistiese en incumplimiento, o las tases correspondientes no fuesen abonadas una vez transcurrido en el período para la verificación de las deficiencias administrativas estipulado en el Párrafo 4 de la UDRP, o si el demandante retirase el reclamo en forma voluntaria y durante dicho período, el Proveedor de Servicios de UDRP informará al Registrador que el procedimiento ha sido anulado. El Registrador procederá entonces a desactivar el 'bloqueo' en el plazo de un día hábil a partir de haberse transmitido dicha notificación de nulidad.

      Recomendación Nro. 10: Como parte de la notificación que curse al Registratario (Notificación de Reclamo - ver sección 4 de las Reglas de UDRP), el Proveedor del Servicio de UDRP informará al Registratario que toda corrección a la información de contacto del Registratario durante el plazo de vigencia restante del procedimiento también debe ser comunicada al Proveedor del Servicio de UDRP de conformidad con las Regla 5(ii) y (iii) de la UDRP.

      Recomendación Nro. 11: En dicha notificación también se informará la necesidad de que el Panel de UDRP debata/trate en forma directa cualquier modificación resultante del levantamiento de los servicios de privacidad/representación luego del 'bloqueo'. El Grupo de Trabajo (WG) recomienda que se proceda a una mayor revisión de esta cuestión como parte del trabajo de desarrollo del programa de acreditación de servicios de privacidad/ representación.

      Recomendación Nro. 12: Una vez que haya recibido la comunicación de la decisión del Proveedor, el Registrador tendrá un plazo de tres días laborales para cumplir con su obligación de comunicar a cada parte, al Proveedor y a la ICANN la fecha de implementación de la decisión de conformidad con la Política (Regla 16 de la UDRP, Párrafos 4(k) y 8(a) de la UDRP). Si el reclamante resulta ganador, el Registrador deberá acatar la orden del Panel en forma inmediata transcurrido un plazo de diez días laborales (Párrafo 4(k) de la UDRP). El Reclamante, o su representante autorizado, debe proporcionar al Registrador la información requerida respecto de la implementación de la decisión del Panel; dicha información debería incluir información que debería figurar en el Whois. Si el Demandado resulta ganador, el Registrador prohibirá la transferencia del nombre de dominio a otro registrador o registratario durante 15 días laborales a partir de la fecha de la transmisión de por parte del proveedor (Párrafo 8 de la UDRP).

      Recomendación Nro. 13: En caso de que se suspenda un procedimiento (cuando las partes hayan llegado a un acuerdo), el Proveedor del Servicio de UDRP informará al Registrador acerca de la Suspensión, y de la duración esperada de la misma. Si ambas partes llegan a un acuerdo, lo que implicaría una transferencia, cancelación o acuerdo que el registro se mantendrá en poder del Demandado, el Registrador debe eliminar cualquier bloqueo a fin de impedir la transferencia o cancelación dentro de los 2 días laborales a partir de la confirmación de la cancelación por parte del Proveedor de Servicios de UDRP , a menos que el registro del nombre de dominio en disputa esté sujeto a un procedimiento judicial que se haya iniciado en relación a ese nombre de dominio en disputa.

      Recomendación Nro. 14: El proceso de resolución debe constar de los siguientes pasos: (1) Las partes solicitan la suspensión por parte de Proveedor de Servicios de UDRP, (2) partes llegan a un acuerdo, (3) las partes presentan al Proveedor de UDRP una "forma de acuerdo" estandarizada , (4) el Proveedor de Servicios de UDRP confirma al Registrador, con copia tanto al Demandante como al Demandado , si los términos del acuerdo indican el acuerdo del Demandado respecto a la transferencia o cancelación del o los nombre/s de dominio en disputa, o el acuerdo del Demandante respecto de que dicho/s nombre/s de dominio sean mantenidos por el Demandado (5) el Registrador implementa el acuerdo de resolución (6) El Demandante confirma la implementación al Proveedor de UDRP (7) el Proveedor de Servicios de UDRP desestima el caso.

      Recomendación Nro. 15: La ICANN, en colaboración con los Proveedores de Servicio de UDRP, Registradores y demás partes interesadas, desarrollará materiales educativos e informativos que servirán para informar a las partes afectadas acerca de estos nuevos requerimientos y las mejores prácticas recomendadas luego de la adopción de estas recomendaciones por parte de la Junta Directiva de la ICANN.

      ¿Cuáles son las partes interesadas u otros participantes consultados?

      Según lo requerido en su estatuto, el Grupo de Trabajo sobre Procesos de Desarrollo de Políticas (PDP WG) fue requerido como "un primer paso, [para] solicitar el aporte de la opinión pública sobre este tema con el fin de tener una comprensión clara de la naturaleza exacta y el alcance de los problemas encontrados en relación al bloqueo de un nombre de dominio sujeto a un Procedimiento de UDRP. Como resultado de ello, el Grupo de Trabajo (WG) llevó a cabo una encuesta entre los registradores y los Proveedores de Servicio de UDRP tal como se indica en el apartado 5.1. del Informe Final. Además de las preguntas específicas sobre las prácticas y experiencias de los registradores y los Proveedores de Servicio de UDRP, se pidió a los Demandados que dieran su opinión sobre las preguntas referidas al estatuto. Además, el Grupo de Trabajo (WG) abrió un foro para comentarios públicos a fin de recibir los aportes de la comunidad el 25 de julio de 2012.

      Además de las actualizaciones frecuentes del Consejo de la GNSO, se organizaron talleres para informar y solicitar la participación de la comunidad en las reuniones de la ICANN (véase, por ejemplo, http://beijing46.icann.org/node/37193, http://toronto45.icann.org/node/34245 y http://prague44.icann.org/node/31807).

      Se solicitaron Declaraciones del Grupo de Partes Interesadas /Unidades Constitutivas y el aporte de otras Organizaciones de Apoyo y Comités Asesores de la ICANN en las primeras etapas del proceso. No se recibió ningún aporte en respuesta a dichas solicitudes. El Presidente del Grupo de Trabajo de PDP efectivamente se reunió con la ccNSO durante la reunión de la ICANN celebrada en Praga para llevar a cabo un intercambio de opiniones sobre este tema (véase http://ccnso.icann.org/meetings/toronto/summary.htm#neylon-greenberg para más detalles).

      El Grupo de Trabajo (WG) abrió un foro para comentarios públicos referido al Informe Final el 5 de marzo de 2013.

      Todos los comentarios recibidos han sido revisados ​​y considerados por el Grupo de Trabajo de PDP sobre el Bloqueo de un Nombre de Dominio sujeto a los Procedimientos de UDRP (Consultar la sección 6 del Informe Final).

      ¿Qué inquietudes o cuestiones mencionó la comunidad?

      No se han planteado inquietudes por parte de la comunidad en relación al Informe Final y sus recomendaciones. Todos los comentarios restantes que se recibieron fueron revisados y abordados por el Grupo de Trabajo de PDP (PDP WG) tal como se establece en la sección 6 del Informe Final.

      ¿Qué materiales de importancia analizó la Junta Directiva?

      La Junta Directiva analizó el Informe de las Recomendaciones del Consejo de la GNSO presentado a la Junta Directiva, así como, el resumen de los comentarios públicos.

      ¿Qué factores considera importantes la Junta Directiva?

      Las recomendaciones fueron preparadas según el Proceso de Desarrollo de Políticas de la GNSO, de acuerdo con lo descripto en el Anexo A de los Estatutos de la ICANN y han recibido el apoyo unánime del Consejo de la GNSO. De conformidad con los Estatutos de la ICANN, el apoyo unánime del Consejo para aprobar la moción (amplia mayoría) obliga a la Junta Directiva a adoptar esta recomendación, excepto que con más del 66% de los votos la Junta establezca que la política no beneficia a la comunidad de la ICANN o a la ICANN propiamente dicha.

      ¿Se observan impactos positivos o negativos en la comunidad?

      Se espera que la adopción de las recomendaciones aclare y estandarice el proceso para el bloqueo de un nombre de dominio sujeto a los Procedimientos de UDRP para todas las partes involucradas, que incluyen a los demandantes, demandados, registradores y Proveedores de Servicio de UDRP. La implementación de las recomendaciones requerirá de ciertos cambios en algunos procesos del registrador dado que, en la actualidad, no hay un proceso estandarizado implementado para manejar el bloqueo de un nombre de dominio sujeto a los Procedimientos de UDRP, así como ciertas modificaciones en las prácticas de los Proveedores de Servicio de UDRP. Para los Demandantes, el principal cambio es que en el momento de la presentación, ya no es necesario que el denunciante notifique al demandado, lo que se espera reduzca las instancias de "cyberflight" (la notificación al demandado es realizada por el Proveedor de UDRP al momento del inicio formal del procedimiento). Como resultado del cambio de ya no requerir la notificación del demandado por parte del demandante al momento de la presentación, el demandado podrá ver una reducción del tiempo de respuesta informal. No obstante, a fin de compensar esta posible pérdida de tiempo de respuesta informal, las recomendaciones prevén que los Demandados que participen de la UDRP obtengan una opción expresa de solicitar una prórroga de cuatro días si así lo deciden, por lo que cualquier solicitud de extensión de cuatro días recibida se concederá de forma automática, y el Proveedor de Servicios de UDRP extenderá el plazo correspondiente, sin costo alguno para el Demandado.

      ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad y/o el público?

      Además de los cambios que se requieren en el proceso para los registradores y los Proveedores de Servicio de UDRP, como se indicó anteriormente, es probable que haya impactos fiscales relacionados con la implementación de la política, pero se prevé que dichos costos estén dentro del presupuesto actual.

      ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      No se observan cuestiones sobre seguridad, estabilidad ni flexibilidad relacionadas con el Sistema de Nombres de Dominio (DNS) como consecuencia de la aprobación por parte de la Junta Directiva de las recomendaciones propuestas.

    4. Implementación de la Revisión de la Organización de Apoyo para Nombres de Dominio con Código de País (ccNSO)

      Visto y considerando que, el 21 de abril de 2011, la Junta Directiva resolvió solicitar al personal de la ICANN que, en coordinación con el Comité de Mejoras Estructurales (SIC), desarrollara un plan de implementación propuesto y un calendario de implementación para las recomendaciones en el Informe Final del Grupo de Trabajo de la Junta Directiva para Revisión de la ccNSO [PDF, 1.01 MB]) y que los presentara ante el Comité de Mejoras Estructurales para su revisión y aprobación por parte de la Junta Directiva (Resolución 2011.04.21.06).

      Visto y considerando que, en su reunión del 18 de junio de 2011, el SIC recibió del personal un plan de implementación, denominado "Plan del Proyecto de Implementación de Mejoras de la ccNSO", de fecha 9 de junio de 2011, y resolvió recomendarlo para su aprobación por parte de la Junta Directiva de la ICANN.

      Visto y considerando que, en su reunión del 24 de junio de 2011, la Junta Directiva resolvió solicitar al Director Ejecutivo de la ICANN que orden al personal continuar con la implementación de conformidad con el documento del plan de implementación Plan del Proyecto de Implementación de Mejoras de la ccNSO de fecha 9 de junio de 2011 [PDF, 508 KB] (Resolución 2011.06.24.03).

      Visto y considerando que, el 27 de septiembre de 2013, el SIC recibió la carta del Presidente de la ccNSO que anunciaba la finalización de la implementación de la revisión de la ccNSO como parte de una actualización final del Plan del Proyecto de Implementación de la ccNSO, con fecha septiembre de 2013.

      Visto y considerando que, el 27 de septiembre de 2013, el SIC acordó recomendar a la Junta Directiva de la ICANN recibir la Actualización final del Plan del Proyecto de Implementación de la ccNSO [PDF, 170 KB] con fecha de septiembre de 2013, indicar de la fase de implementación de la revisión de la ccNSO como finalizada y comenzar con la etapa de evaluación inherente al ciclo de revisión.

      Resuélvase que (2013.09.28.06), la Junta Directiva reciba la actualización final del Plan del Proyecto de Implementación de la ccNSO con fecha de septiembre de 2013, y tome nota de la finalización de la implementación de las recomendaciones de revisión de la ccNSO.

      Resuélvase que (2013.09.28.07), la Junta Directiva instruya al Presidente y Director Ejecutivo de la ICANN evaluar las mejoras derivadas de la revisión de la ccNSO según la fase de evaluación del ciclo de revisión de la organización.

      Resuélvase que (2013.09.28.08), la Junta Directiva agradece a la ccNSO por su trabajo de implementación.

      Fundamentos de las resoluciones 2013.09.28.06 – 2013.09.28.08

      De conformidad con los Estatutos de la ICANN, se requiere una revisión periódica de las SO y los AC de la ICANN para evaluar el rendimiento y la eficacia operativa de la entidad sometida a revisión. El objetivo de esta revisión es determinar: (i) si dicha organización tiene un propósito de continuidad dentro de la estructura de la ICANN; y (ii) en caso afirmativo, si es deseable realizar algún cambio en su estructura u operaciones a fin de mejorar su efectividad.

      Esta acción es en respuesta directa a la petición de la Junta Directiva de implementar las recomendaciones derivadas del esfuerzo de revisión de la ccNSO y sirve para permitir la evaluación de las mejoras de revisión de la ccNSO de manera oportuna.

      Esta acción no implica ningún cambio estructural complejo o consecuencias presupuestarias. No se prevé ningún impacto en la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio como resultado de esta acción.

      Esta decisión forma parte de las funciones administrativas y organizacionales que no requieren comentario público.

    5. Revisión de la GNSO

      Visto y considerando que, según los Estatutos de la ICANN la próxima revisión de la GNSO debía comenzar en 2013.

      Visto y considerando que, el SIC solicitó y consideró los comentarios públicos respecto de si la revisión debería ser pospuesta y respecto de si se debe establecer un nuevo cronograma para la revisión dentro de los próximos seis meses.

      Visto y considerando que, es importante que la revisión de la GNSO tenga en cuenta los resultados de los esfuerzos de planificación estratégica de la ICANN y el trabajo del Segundo Equipo de Revisión sobre Responsabilidad y Transparencia, que sólo puede lograrse mediante el inicio de una revisión de la GNSO en 2014.

      Resuélvase que (2013.09.28.09), la Junta Directiva instruya al SIC programar la revisión de la Organización de Apoyo para Nombres Genéricos (GNSO) la cual, según los Estatutos de la ICANN, Artículo IV, Sección 4, deberá comenzará en 2014, y que los preparativos para esta Revisión comiencen a la mayor brevedad posible.

      Fundamentos de las resoluciones 2013.09.28.09

      Los estatutos de la ICANN requieren que las estructuras dentro de la ICANN sean revisadas regularmente como parte del proceso de responsabilidad continua de la ICANN. Para ello, se inició la primera revisión organizacional de la GNSO en 2006. Como parte de esa revisión, en septiembre de 2006, se publicó un informe del Grupo de Políticas Públicas LSE y la Empresa LSE, un evaluador independiente contratado para llevar a cabo dicha revisión, y el 3 de febrero de 2008, se emitió el Informe del Grupo de Revisión de la GNSO del Comité de Gobernanza de la Junta Directiva sobre Mejoras de la GNSO. Según lo dispuesto en los Estatutos de la ICANN, Artículo IV, Sección 4, la siguiente revisión comenzaría en cinco años luego de la publicación del informe final, lo que requeriría que la revisión comenzara a principios del año 2013. El Comité de Mejoras Estructurales (SIC) recomendó a la Junta Directiva que la ICANN se beneficiaría al retrasar el inicio de esta nueva revisión de la GNSO para considerar los valiosos aportes del Proceso de Planificación Estratégica de la ICANN y del trabajo en curso del Segundo Equipo de Revisión sobre Responsabilidad y Transparencia creado según la Afirmación de Compromisos (ATRT 2). El período de comentarios públicos se inició el 15 de julio de 2013 para recabar información para informar la acción del SIC respecto de la Posible Postergación de la Revisión de la GNSO. La respuesta de la Comunidad a los Comentarios Públicos dio como resultado ocho respuestas y siete participantes en las respuestas indicaron que la revisión de la GNSO no debe aplazarse. Las razones citadas incluyeron:

      • La expansión del espacio de los TLD ha aumentado el número y la variedad de partes interesadas que participan en la elaboración de políticas de la GNSO y la revisión debe llevarse a cabo en la fecha prevista para examinar si el modelo actual cumple con las necesidades de una nueva generación de partes interesadas.
      •  Es poco probable que la Estructura de la GNSO pueda acoger el nuevo flujo de partes interesadas resultante de la expansión del espacio de los TLD. La revisión de la GNSO será un vehículo importante para considerar y abordar esta cuestión. Es necesario que el desequilibrio que ya existe sea abordado por la Revisión de la GNSO.
      • Llevó varios años implementar la revisión anterior. Quienes respondieron enfatizaron la necesidad de minimizar la extensión del proceso de Revisión de la GNSO en general, a fin de proporcionar una revisión más efectiva y de mayor respuesta y más eficiente de la GNSO para toda la comunidad de la ICANN.
      • La labor emprendida por el ATRT 2 para evaluar el proceso de desarrollo de políticas o el proceso de Planificación Estratégica no abordará las cuestiones indicadas de ninguna manera sustantiva.

      Los participantes en el proceso de comentarios públicos incluyeron el Grupo de Registros de Marcas, Google, la Unidad Constitutiva de Proveedores de Servicios de Internet y Proveedores de Conectividad, la Unidad Constitutiva Operacional sin Fines de Lucro, el Grupo de Partes Interesadas No Comerciales, la Unidad Constitutiva de la Propiedad Intelectual, la Unidad Constitutiva Comercial y los Servicios de Registro de ARI.

      El enfoque propuesto tiene como objeto dar respuesta a la retroalimentación de la comunidad sin más demora, conforme se establece, también, un plazo para el inicio de una revisión que sea adecuada para la complejidad del trabajo, y la importancia de una planificación cuidadosa, que incluya las consideraciones de la metodología de la revisión y la participación de la comunidad en el proceso. Mediante el reconocimiento de la importancia de una revisión minuciosa y bien organizada que tenga en cuenta los aportes relevantes de los trabajos en curso, así como la diversidad de opiniones de la comunidad, el SIC equiparó estas consideraciones con la retroalimentación de la comunidad.

      A fin de cumplir con la obligación de la Junta Directiva, según los Estatutos, de "realizar una revisión periódica del funcionamiento y operación de cada Organización de Apoyo, cada Consejo de una Organización de Apoyo", el SIC recomienda que la planificación para la próxima revisión de la GNSO comience seriamente en preparación para la Revisión, que comenzará a la mayor brevedad posible en 2014.

      El objetivo de la revisión estructural es "determinar (i) si dicha organización tiene un propósito de continuidad dentro de la estructura de la ICANN; y (ii) en caso afirmativo, si es deseable realizar algún cambio en su estructura u operaciones a fin de mejorar su efectividad". Dados el entorno cambiante, el incremento en la cantidad de partes interesadas y de su diversidad y las lecciones recogidas de la última revisión de la GNSO, el SIC considera que la planificación de la revisión será de suma importancia para asegurar que las recomendaciones de mejora sean útiles y aplicables. El SIC desarrollará e implementará un programa de revisión que tiene en cuenta el sentido de urgencia articulado dentro de los comentarios públicos, en tanto que garantiza que se asigne suficiente tiempo a los esfuerzos de planificación. El tiempo adicional asignado a las consultas de la comunidad asegurará que la comunidad tenga el tiempo suficiente para considerar y dar su opinión sobre cómo se debe llevar a cabo la segunda Revisión de la GNSO, lo que mejora, así, la responsabilidad y la transparencia de la ICANN.

      No se espera que esta decisión tenga un impacto sobre la seguridad o estabilidad del DNS. Habrá impactos fiscales y sobre los recursos asociados a la Revisión de la GNSO cuando se inicie. Estos recursos y los costos serán asignados y anticipados dentro del presupuesto de la ICANN para el año fiscal correspondiente dentro el cual se inicie y complete la revisión.

      La presente acción es una Función Organizacional y Administrativa, respecto de la cual se recibieron comentarios públicos.

  2. Orden del día principal:

    1. Designación del Presidente y Presidente-Electo del Comité de Nominaciones para el año 2014

      Visto y considerando que, el BGC revisó las Expresiones de Interés de los candidatos para Presidente y Presidente-Electo del Comité de Nominaciones para el 2014 ("NomCom"), entrevistó a los candidatos y examinó los resultados de una evaluación de 360 ​​grados del liderazgo del Comité de Nominaciones durante el 2013.

      Visto y considerando que, el BGC recomendó que Cheryl Langdon-Orr sea designada Presidente del NomCom para el año 2014, y Stéphane Van Gelder sea designado Presidente- Electo del NomCom para el año 2014.

      Resuélvase que (2013.09.28.10), la Junta Directiva designa por la presente a Cheryl Langdon-Orr como Presidente del Comité de Nominaciones para el año 2014 y a Stéphane Van Gelder como Presidente-Electo del Comité de Nominaciones para el año 2014.

      Fundamentos de las resoluciones 2013.09.28.10

      De acuerdo con los Estatutos de la ICANN, la Junta Directiva debe designar al Presidente y al Presidente Electo del Comité de Nominaciones (NomCom). Consultar el Artículo VII, secciones 2.1 y 2.2 en http://www.icann.org/fr/general/bylaws.htm#VII. La Junta Directiva ha delegado en el Comité de Gobernanza de la Junta la responsabilidad de recomendar al Presidente y al Presidente -Electo del NomCom para la aprobación de la Junta Directiva. Véase el estatuto del BGC http://www.icann.org/en/committees/board-governance/charter.htm. El BGC publicó una convocatoria para obtener expresiones de interés (EOI), revisó las expresiones de interés recibidas, llevó a cabo entrevistas con los candidatos, y supervisó una evaluación de 360 ​​grados del liderazgo del Comité de Nominaciones durante el año 2013 antes de realizar una recomendación. La Junta Directiva ha sometido a consideración la recomendación del BGC y está de acuerdo con ella. La Junta Directiva también quisiera agradecer a todos quienes expresaron su interés en formar parte del liderazgo del Comité de Nominaciones.

      La designación del Presidente y el Presidente- Electo del NomCom identificados a través de un proceso público de EOI tiene un impacto positivo en la transparencia y la responsabilidad de la ICANN. La adopción de la recomendación del BGC no tiene un impacto económico en la ICANN que no haya sido anticipado y no impactará de manera negativa en la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio.

      Esta decisión forma parte de las funciones administrativas y organizacionales que no requieren comentario público.

    2. Tratamiento de los Costos Históricos de los Nuevos gTLD

      Visto y considerando que, la ICANN incurrió en gastos durante varios años para diseñar y preparar el lanzamiento del Programa de Nuevos gTLD.

      Visto y considerando que, los gastos efectuados a partir de octubre de 2007 (la fecha de la recomendación de la GNSO sobre el Programa de Nuevos gTLD) para la puesta en marcha del Programa ("Costos de Históricos de Desarrollo") deben ser reembolsados ​​a la ICANN a partir de una porción de las tarifas de solicitud del Programa de Nuevos gTLD.

      Visto y considerando que, los Costos Históricos de Desarrollo se cobran al Programa de manera progresiva conforme avanza el trabajo de evaluación y los honorarios se tornan no reembolsables, lo que se inició en julio de 2012.

      Visto y considerando que, el Comité de Finanzas de la Junta Directiva ha recomendado que el importe de los Costos Históricos de Desarrollo reembolsados al fondo de operaciones de la ICANN a partir del Programa de Nuevos gTLD sean transferidos al Fondo de Reserva.

      Resuélvase que (2013.09.28.11), la Junta Directiva autorice al Presidente y Director Ejecutivo, o a quien(es) este designe, a tomar todas las acciones necesarias para la transferencia, cuando y según proceda, del fondo de operaciones de la ICANN al Fondo de Reserva de la ICANN, de todas las sumas, se hayan ya abonado o sean reembolsadas en el futuro, que constituyan Costos Históricos de Desarrollo.

      Fundamentos de las resoluciones 2013.09.28.11

      La ICANN ha incurrido en costos para definir, diseñar y preparar el lanzamiento del Programa de Nuevos gTLD durante los años que precedieron la puesta en marcha del Programa en enero de 2012 ("Costos Históricos de Desarrollo"). "(Véase Anexo 1.)

      Como parte del diseño del Programa, los Costos Históricos de Desarrollo, fueron anticipados por el fondo operativo de la ICANN y debían ser recuperados a través de una parte de la tarifa de solicitud percibida de los solicitantes del Programa de Nuevos gTLD. A fin de garantizar que se recibieran fondos suficientes, la tarifa de solicitud incluía $ 25,000 por cada solicitud para permitir el reembolso de los Costos Históricos de Desarrollo a la ICANN. El importe de $ 25,000 resultó de una estimación histórica de los costos de desarrollo totales del Programa, dividido entre 500 solicitudes. También se determinó que los costos incurridos por la ICANN que serían reembolsados mediante una parte de la tarifa de solicitud serían los incurridos entre octubre de 2007, la fecha aproximada de las recomendaciones sobre políticas de la GNSO respecto de los nuevos gTLD, y el lanzamiento del Programa en enero de 2012.

      El personal de la ICANN ha estimado que los Costos Históricos de Desarrollo son de aproximadamente $ 32, 5 millones. Este importe se ha comunicado como parte de la presentación del Presupuesto para el Año Fiscal 2013 (FY13), en junio de 2012. Su documentación detallada está, actualmente, en la fase de finalización para su auditoría y comunicación a la comunidad.

      El importe de los Costos Históricos de Desarrollo cubiertos con los $25.000 obtenidos de las solicitudes reales recibidas asciende a aproximadamente $ 48 millones (25k * 1.930 solicitudes), antes del impacto de los reembolsos. La diferencia entre los $ 48 millones (menos reembolsos) y los aproximadamente $ 32,5 millones contribuye al saldo neto restante del Programa.

      El importe del reembolso de los Costos Históricos de Desarrollo se cobra al Programa de Nuevos gTLD, desde julio de 2012, conforme avanza el trabajo de evaluación y las tarifas de solicitud se tornan no reembolsables.

      Aproximadamente $ 17 millones en concepto de costos cobrados al Programa de Nuevos gTLD a partir de julio de 2012 hasta junio de 2013, con un ingreso correspondiente a la ICANN, fueron transferidos a la cuenta operativa de la ICANN en agosto de 2013.

      Aunque siempre la intención ha sido que los fondos resultantes del reembolso de los Costos Históricos de Desarrollo se transfieran al Fondo de Reserva de la ICANN, dicha intención nunca fue formalizada mediante una resolución de la Junta Directiva. "(Véase Anexo 1.)

      Después de la transferencia inicial inminente al Fondo de Reserva de los Costos Históricos de Desarrollo ya recuperados que ahora se encuentran en la cuenta operativa de la ICANN, a efectos prácticos, la ICANN prevé realizar transferencias trimestrales al Fondo de Reserva conforme los importes se cobran a la cuenta del Programa de Nuevos gTLD.

      Esta resolución tendrá un impacto positivo, ya que proporciona claridad a la gestión de los recursos de la ICANN. Esto tendrá un impacto fiscal sobre la ICANN y la comunidad como era objetivo. Esto no tendrá impacto en la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio (DNS).

      Esta es una Función Administrativa Organizacional que no requiere comentarios públicos en esta etapa, sin embargo la naturaleza y el método de manejo de los Costos Históricos de Desarrollo y el hecho de que sean transferidos al Fondo de Reserva han sido previamente publicados y estuvieron sometidos a comentarios públicos.

    3. Proceso Propuesto para las Enmiendas a los Estatutos del Grupo de Partes Interesadas y las Unidades Constitutivas de la GNSO

      Visto y considerando que, los Estatutos de la ICANN (Artículo X, Sección 5.3) establecen que: "Cada Grupo de Partes Interesadas [de la GNSO]… y cada una de sus Unidades Constitutivas asociadas deberá mantener el reconocimiento de la Junta Directiva de la ICANN".

      Visto y considerando que, es importante que los Grupos de Partes Interesadas las Unidades Constitutivas de la GNSO tengan la flexibilidad de actualizar, modificar y adaptar sus estatutos organizacionales para reflejar los cambios de la comunidad al tiempo que equilibran la necesidad de validación por parte de la Junta Directiva.

      Visto y considerando que, en la actualidad no existe ningún procedimiento para que un Grupo de Partes Interesadas o Unidad Constitutiva de la GNSO obtenga aprobación de la Junta Directiva de la ICANN para la modificación de sus estatutos.

      Visto y considerando que, el Comité de Mejoras Estructurales de la Junta Directiva de la ICANN ha formulado y recomendado un proceso por el cual los Grupos de Partes Interesadas y las Unidades Constitutivas de la GNSO pueden modificar sus estatutos, en tanto que la Junta Directiva mantiene sus responsabilidades de validación apropiadas para el reconocimiento de dichos grupos de la GNSO.

      Visto y considerando que, la comunidad ha tenido la oportunidad de revisar y comentar sobre el proceso propuesto y se han hecho cambios al proceso propuesto para abordar las sugerencias de la comunidad.

      Resuélvase que (2013.09.28.12), la Junta Directiva apruebe el proceso formulado y recomendado por el Comité de Mejoras Estructurales e instruya al personal de la ICANN notificar al liderazgo de los diferentes Grupos de Partes Interesadas y Unidades Constitutivas de la GNSO sobre el proceso y publicar una copia del proceso aprobado en el sitio web de la GNSO dentro del plazo de 7 días calendario.

      Fundamentos de las resoluciones 2013.09.28.12

      En julio de 2009, como parte del Programa Integral de Mejoras de la GNSO, la Junta Directiva de la ICANN aprobó los Estatutos formales de cuatro nuevos Grupos de Partes Interesadas de la GNSO (véase Resolución de la Junta Directiva de la ICANN 2009.30.07.09).

      Los Estatutos de la ICANN (Artículo X, Sección 5.3) establecen que: "Cada Grupo de Partes Interesadas… y cada una de sus Unidades Constitutivas asociadas deberá mantener el reconocimiento de la Junta Directiva de la ICANN". Debido a que los estatutos organizacionales originales de la GNSO aprobados en 2009 estuvieron sujetos a exhaustivas y rigurosas negociaciones y discusiones entre la comunidad y los miembros de la Junta Directiva, es conveniente que la Junta Directiva tenga la oportunidad de revisar y aprobar las posteriores enmiendas a los estatutos. Además, la Junta Directiva considera que la revisión de las enmiendas al estatuto de la GNSO mantenida por los Grupos de Partes Interesadas y las Unidades Constitutivas de la GNSO que los integran es una obligación importante a fin de mantener el reconocimiento de las Estructuras de la GNSO aprobadas formalmente en consonancia con los principios de los estatutos de la ICANN.

      El Comité de Mejoras Estructurales (SIC) de la Junta Directiva ha desarrollado este proceso y la propuesta fue compartida con la comunidad para su revisión y comentarios. La versión final aprobada por la Junta Directiva refleja ajustes a la propuesta original del SIC, luego de considerar la útil retroalimentación de la comunidad con respecto a los plazos de notificación del personal y el plazo y proceso para la revisión por parte de la Junta Directiva de las enmiendas de la comunidad a los estatutos.

      Esta acción no tendrá un impacto inmediato o sustancial sobre los recursos de la ICANN. En ciertos momentos, se requerirá trabajo adicional de la comunidad, tareas de apoyo por parte del personal y tiempo de revisión de la Junta Directiva, pero dichos esfuerzos deben tener una duración limitada y mejorarán la transparencia y la eficacia final de los procesos estructurales y de gestión de la ICANN.

      Se prevé que esta medida no tendrá impacto en la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio.

      ENLACES A DOCUMENTOS /ANTECEDENTES:
      Vínculo a la Comunidad Foro de Comentarios Públicos.

      La presente acción es una función organizacional y administrativa, respecto de la cual se recibieron comentarios públicos.

    4. Aclaración Respecto de los Criterios de Medición de Competencia, Confianza del Consumidor y Elección del Consumidor para el Programa de Nuevos gTLD de Conformidad con la Revisión establecida en la AoC

      Visto y considerando que, el 18 de julio de 2013, la Junta Directiva de la ICANN ordenó al Director Ejecutivo iniciar el proceso de convocatoria para la creación del Equipo de Revisión de la Competencia, Confianza del Consumidor y Elección del Consumidor (CCT) a fin de facilitar el trabajo preliminar sobre la viabilidad, utilidad y costo-efectividad de la adopción de las recomendaciones del Consejo de la GNSO y el ALAC, así como analizar otros criterios de medición potenciales disponibles para la revisión por parte del CCT.

      Visto y considerando que, la Junta Directiva desea aclarar sus resoluciones 2013.07.18.06 y 2013.07.18.07 a fin de identificar que la revisión actual del CCT no se inicia en este momento, sino que se ha aprobado la designación de un Grupo Asesor de Implementación para la Competencia, Confianza del Consumidor y Elección del Consumidor. El trabajo de este Grupo Asesor pretende ser un aporte para la revisión del CCT en el futuro, cuando se inicie la revisión por parte del CCT de acuerdo con el cronograma establecido en la Afirmación de Compromisos (AOC).

      Resuélvase que (2013.09.28.13), la Junta Directiva ordene al Director Ejecutivo convocar a un grupo de voluntarios (el Grupo Asesor de Implementación para la Competencia, Confianza del Consumidor y Elección del Consumidor) con anterioridad a la formación de un futuro Equipo de Revisión para la Competencia, Confianza del Consumidor y Elección del Consumidor con el propósito de: (i) evaluar e informar a la Junta Directiva respecto de la factibilidad, la utilidad y el costo de la adopción de las recomendaciones del Consejo de la GNSO y del ALAC; (ii) evaluar otros aportes, entre ellos, datos históricos sobre criterios de medición aplicados para la evaluación de las rondas anteriores de nuevos gTLDs (2000, 2004); (iii) participar junto a la GNSO, el ALAC y el personal de una iniciativa en pos de llegar a un acuerdo sobre los criterios de medición; y (iv) proponer un conjunto de criterios de medición a ser compilados por la ICANN para su aplicación en la próxima revisión del Programa de Nuevos gTLD por parte del Equipo de Revisión de la AoC.

      Resuélvase que (2013.09.28.14), se retracten las partes de las resoluciones 2013.07.18.06 y 2013.07.18.07 que sugieren que la revisión del CCT se iniciaría antes de lo requerido en la AoC.

      Fundamentos de las resoluciones 2013.09.28.13 – 2013.09.28.14

      La resolución de la Junta Directiva clarifica su resolución anterior referida a la evaluación de los criterios de medición propuestos por la comunidad para su uso en una revisión futura, según lo establecido en la Afirmación de Compromisos (AoC), del impacto de los nuevos gTLDs en las áreas de competencia, confianza del consumidor y elección del consumidor.

      La resolución de la Junta Directiva solicita al Presidente y Director Ejecutivo convocar a un grupo de voluntarios para brindar asesoramiento de implementación con anterioridad a la convocatoria de un futuro Equipo de Revisión de la Competencia, Confianza del Consumidor y Elección del Consumidor para: evaluar e informar sobre la viabilidad, utilidad y costo-efectividad de la implementación de los diferentes criterios de medición del consumidor recomendados por la comunidad; la evaluación de otros aportes, incluidos los datos históricos con respecto a los criterios de medición utilizados en rondas anteriores de nuevos gTLD (2000, 2004); participar con la GNSO y el ALAC para identificar un acuerdo sobre los criterios de medición, y en última instancia, proponer una serie de criterios de medición para que la Junta Directiva apruebe, a fin de que sean considerados y puestos a disposición para ser utilizados en la revisión futura a efectuarse según lo establecido en la AoC, a su discreción. Si, tras analizar esto con la GNSO y el ALAC, el Equipo Asesor de Implementación para la Competencia, Confianza del Consumidor y Elección del Consumidor finalmente recomienda no utilizar los criterios de medición propuestos por el Consejo de la GNSO y/o el ALAC, se espera que el Equipo Asesor presente una explicación a la Junta Directiva.

      Esta labor comenzará inmediatamente, y consiste en hacer participar a la comunidad y a la ICANN, evaluar y presentar informes sobre los criterios de medición propuestos por el Consejo de la GNSO y el ALAC, y recomendar criterios de medición para que sean recogidos por la ICANN en preparación para una futura revisión del Programa de Nuevos gTLD.

      La revisión solicitada según lo establecido en el AoC tendrá lugar una vez que los nuevos gTLDs hayan estado en funcionamiento durante un año, e implica evaluar hasta qué punto la introducción o la expansión de los gTLD ha promovido la competencia, confianza del consumidor y elección del consumidor. Dicha revisión aún no está lista para comenzar. En la actualidad, la Junta Directiva realiza un llamamiento para proceder con la labor de implementación cuyo objetivo es facilitar el trabajo de revisión establecida en la AoC en el momento adecuado.

      Esto constituye una Función Administrativa y Organizacional que no requiere comentarios públicos.


1 Cabe señalar que dicho bloqueo no debe impedir la renovación de un nombre de dominio sujeto a los procedimientos de UDRP, de acuerdo con la Política de Eliminación de Dominios Vencidos (EDDP).

2 Esta es una verificación inicial que realiza el proveedor del servicio de UDRP para asegurarse de no estar tratando con un reclamo falso. Esta verificación no debe confundirse con la verificación de cumplimiento administrativo descripta en la UDRP, la cual se efectúa según el cuarto paso de la presente propuesta.

3 Esto se aplicará a los proveedores de servicios de privacidad / representación acreditados tras la finalización del programa de acreditación de servicios de privacidad/representación por parte de la ICANN.

4 Los días laborales se definen como días laborales en la jurisdicción de la entidad que debe iniciar la acción, en este caso, el registrador.

5 Los datos divulgados podrán incluir únicamente los datos que obren en los registros del proveedor de servicios de privacidad/representación acreditado/relacionado.

6 A modo de aclaración, esto incluye cualquier transferencia a un servicio de privacidad o representación que no sea la divulgación de los datos del cliente de servicios de representación, de conformidad con lo dispuesto en el próximo párrafo.

7 El Proveedor de Servicios de UDRP enviará una solicitud al registrador para verificar, entre otras cosas, que el Demandado que se menciona es, efectivamente, el registratario de nombre, o de los nombres, de dominio en cuestión; se verificarán también el idioma del acuerdo de registración y los datos de contacto del Demandado.

8 La solicitud de verificación se refiere al requisito de que el Registrador proporcione al Proveedor la verificación de los ítems solicitados.

9 Se recomienda esta modificación a las Reglas de UDRP (actualmente, se indican días 'calendario') a los efectos de garantizar una uniformidad con el requisito de dos días laborales para el bloqueo ya que, de lo contrario, puede haber una situación en la cual un plazo de dos días laborales sea más extenso que un plazo de tres días calendario, lo cual impediría al Proveedor de servicios de UDRP efectuar los controles administrativo dentro del plazo designado.

10 La justificación para agregar esta recomendación es abordar las preocupaciones expresadas en el foro de comentarios públicos sobre la pérdida de tiempo de respuesta informal como resultado del cambio propuesto de no exigir que el Demandante notifique al Demandado al momento de la presentación y ofrecer a aquellos Demandados que en realidad necesiten esos días extra, la comodidad de un certeza sin costo ante la solicitud, sin afectar los plazos de la UDRP en general.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."