Skip to main content

Construcción de un Centro de Información y Protección de Marcas Seguro y Confiable

La semana pasada invité a un grupo de representantes de las partes interesadas a trabajar con la ICANN en soluciones de arquitectura e implementación para el Centro de Información y Protección de Marcas. Entre los problemas que pudimos abordar, se incluyeron:

  • Registro: Cómo se verificarán y registrarán los datos de marcas en el Centro de Información y Protección.
  • Gestión del Pre-registro (Sunrise): Cómo los registros de nuevos gTLD utilizarán datos del Centro de Información y Protección para confirmar si son elegibles para el registro temprano de nombres de dominio.
  • Gestión de Reclamos: Cómo los registros y registradores de nuevos gTLD facilitarán las notificaciones requeridas de registros del Centro de Información y Protección de Marcas durante el proceso de registro de nombres de dominio.

Los miembros de las unidades constitutivas Empresariales, de Propiedad Intelectual y de Usuarios No Comerciales, así como también el Grupo de Partes Interesadas de Registradores (RrSG) y el Grupo de Partes Interesadas de Registros (RySG), contribuyeron a una discusión constructiva sobre los enfoques para la implementación y se han puesto de acuerdo en varias áreas.

A continuación hay un resumen de nuestros hallazgos:

Presentación y Verificación de Marcas

Publicación de Especificaciones Funcionales

En diciembre de 2012, la ICANN proporcionará una guía para el desarrollo de los componentes para la presentación y verificación de marcas del Centro de Información y Protección. Ésta definirá de forma clara las capacidades que estarán disponibles en la publicación inicial, la cual está programada para principios de 2013, para brindar apoyo a aquellas partes que estarán implementando y construyendo procesos y sistemas internos para trabajar con este elemento del Centro de Información y Protección.

Lanzamiento de TLD e Información de Pre-registro (Sunrise)

La ICANN está analizando alternativas para ayudar a garantizar la disponibilidad de información oportuna y acertada sobre el lanzamiento de nuevos gTLD. Entre las opciones que hemos discutido se incluye el requisito de un preaviso y un portal web central que rastree las fechas y requisitos de cada período de pre-registro (sunrise) de nuevo gTLD. La organización oportuna de esta información mantendrá informados a los usuarios sobre actividades actuales y los ayudará a prepararse de manera efectiva para los próximos lanzamientos. La ICANN entregará tales servicios el año que viene, antes de delegar los nuevos gTLD.

Comunicaciones y Actividades de Entrenamiento

Hemos acordado que se deberían realizar seminarios de implementación de manera periódica para asegurar que exista un diálogo constante entre los implementadores y los diferentes tipos de usuarios. Dada la diversidad de usuarios que esperamos que ingresarán al Centro de Información y Protección (incluyendo un rango del volumen y funciones de servicios), el uso de “rutas” de entrenamiento los ayudará a familiarizarse con aquellas características específicas que les pueden ser de mayor utilidad. También se harán disponibles materiales educativos, incluyendo una guía que indique, paso a paso, el proceso de verificación. En el futuro cercano, la ICANN coordinará la entrega de tales servicios junto con su socio de entrega.

Implementación del Pre-registro (Sunrise)

Uso de Archivos de Datos de Pre-registro (Sunrise) Firmados

El grupo acordó apoyar un modelo de pre-registro en donde el registro de datos del Centro de Información y Protección se proporcione a titulares de derechos en la forma de un archivo de datos que este firmado de manera criptográfica con una llave pública del Centro de Información y Protección. El mismo puede ser utilizado para permitir el registro de un nombre de dominio durante el período de pre-registro (sunrise). El tema de los campos específicos a ser incluidos en el archivo se discutirá durante las próximas reuniones de seguimiento.

Flexibilidad para Titulares de Derechos en el Período de Pre-registro (Sunrise)

El grupo analizó el grado de “coincidencia” que debería ser requerido entre el registro del Centro de Información y Protección y los datos WHOIS para el registro de un nombre de dominio que esté basado en su elegibilidad para el período de pre-registro (sunrise). Dado que un archivo de datos válido implica que el Centro de Información y Protección ha verificado la información, y teniendo en cuenta que la flexibilidad es importante para los titulares de derechos, no hemos llegado a un acuerdo con respecto a este requisito de coincidencias. Sin embargo, los registros tienen la libertad para realizar pasos adicionales de verificación de acuerdo a su criterio. Los procedimientos de resolución de disputas están disponibles para abordar casos de fraude u otros abusos relacionados a pre-registros (sunrise).

Implementación de los Reclamos de Marcas

Características de centralización y descentralización

Los participantes revisaron las características de posibles sistemas centralizados y descentralizados, y aceptaron realizar un sistema “mixto” para el Reclamo de Marcas. En este sistema, el archivo de etiquetas de nombres de dominios derivado de los registros del Centro de Información y Protección (y por lo tanto, sujeto a una Notificación de Reclamo) se distribuiría a todos los registros y sería actualizado periódicamente. También se utilizaría un sistema de preguntas en tiempo real para recuperar datos detallados del Centro de Información y Protección, cuando sea necesario, para mostrar una Notificación de Reclamo a un posible registrante. Para garantizar la exactitud y consistencia en los TLD, se acordó que debería existir un requisito de cumplimiento en donde el Centro de Información y Protección informe a la ICANN cuando los registros no descarguen la lista de nombres de acuerdo a la frecuencia requerida.

Directrices de registros

Todos los registros de nuevos gTLD deben ofrecer un período de pre-registro (sunrise) mínimo de 30 días y un servicio de reclamo de marcas durante los primeros 60 días, como mínimo, a partir del registro inicial. Los participantes acordaron colaborar en la elaboración de recomendaciones de definiciones que ayuden a brindar mayor claridad sobre estos períodos, en relación con la publicación de la ICANN sobre las directrices para los registros acerca de los servicios de pre-registro y reclamos. Los períodos de 30 y 60 días mencionados anteriormente son los períodos mínimos requeridos, y los registros tienen la posibilidad de extenderlos de acuerdo a su criterio.

Protección de datos

Hubo una discusión sobre la implementación de un marco apropiado para el acceso y uso de los datos. El grupo consideró si las medidas eran necesarias, específicamente para abordar posibles extracciones de la base de datos del Centro de Información y Protección para fines distintos al apoyo de mecanismos de protección de datos. Dado que el Centro de Información y Protección de Marcas está diseñado para brindar datos de marcas para fines particulares, se acordó que la mayoría de los controles serían ineficaces si se intentaran controlar los elementos de datos una vez que los mismos fueran proporcionados a otras partes.

Próximos pasos

El trabajo que hemos logrado la semana pasada en Bruselas nos ubica sobre una base firme para seguir avanzando. La semana que viene llevaremos a cabo reuniones de seguimiento en Los Ángeles junto con grupos de partes interesadas a los que se los invitó a enviar a sus representantes. Se realizará una sesión técnica con el proveedor de servicio para el Centro de Información y Protección, y se abordará el tema de la arquitectura para la implementación del período de Pre-registro (Sunrise) y de los Reclamos de Marcas. También se llevará a cabo una segunda reunión en la que se discutirá la reciente propuesta de IPC/BC para realizar Mejoras y Avances a los Mecanismos de Protección de Derechos (RPM) para nuevos gTLDs [PDF, 68 KB], el cual está enfocado principalmente en la implementación en oposición a cuestiones de políticas, y también en el marco comercial y contractual del Centro de Información y Protección, incluyendo los acuerdos de nivel de servicios y la fijación de precios.

Le doy gracias a las partes interesadas y al equipo de la ICANN por sus contribuciones a este esfuerzo. ¡Hemos hecho un gran progreso!

Saludos,

Fadi

Comments

    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."