Skip to main content

Una política es tan solo una idea si no se implementa de forma efectiva

Incluso las mejores políticas pueden tener dificultades a la hora de su implementación. Por esto motivo, las políticas deberían considerarse como “documentos vivientes”. Necesitan liderazgo, recursos, supervisión y otras contribuciones para prosperar y cumplir con sus objetivos 1.

Las normas para el desarrollo formal de políticas de la ICANN están claramente definidas en los Estatutos de la ICANN, pero los procesos y procedimientos que rodean la implementación de las políticas no son tan claros. En consecuencia, las recientes discusiones en la ICANN (particularmente en lo que respecta a los esfuerzos sobre los nuevos gTLD) se han centrado en una pregunta fundamental: ¿Cuándo se convierte una acción en parte del proceso de implementación de una política y cuándo se convierte una implementación en el desarrollo de una política?

Aunque muchos creen que no es posible desarrollar una norma con límites claros con respecto a lo que es una política o una implementación, parece que existe un amplio margen para aclarar actividades existentes y para definir de mejor manera las funciones de las diferentes partes interesadas de la ICANN que están involucradas en el proceso de implementación.

Como resultado de estas inquietudes, hace poco el Personal inició un esfuerzo para discutir sobre este dilema más a fondo con la comunidad. Dentro de pocos días cerrará un Foro de Comentario Público de 42 días de duración, “Política versus Implementación” , que se lanzó para solicitar las últimas opiniones de la comunidad con respecto a este tema. Además, se está planeando realizar un Taller Público especial para abordar este tema en la próxima reunión pública de la ICANN que se llevará a cabo en Pekín. Espero que muchos de ustedes participen de esta discusión.

El panorama actual:

Actualmente existen diferentes tipos de “políticas” en el mundo de la ICANN. Por ejemplo, en los Estatutos se presentan los procesos formales de desarrollo de políticas (PDP).  También existen políticas operativas que generalmente no están sujetas a un PDP o no son consideradas como una cuestión de implementación (tales como la Política sobre Conflictos de Intereses), para las cuales se solicita y considera el comentario público, aunque no necesariamente sea obligatorio. Además, hay prácticas generales de la comunidad a las que a veces se las conoce como políticas “de p pequeña” o, dicho en términos más precisos, “procedimientos” (como por ejemplo, el requisito de realizar un período de comentario público de 30 días en los casos en los que se realizan cambios en los Estatutos).

En lo que respecta a las políticas desarrolladas formalmente, el grupo responsable por el desarrollo de las recomendaciones de políticas podría ofrecer orientación sobre la implementación, pero en la mayoría de los casos la Junta Directiva de la ICANN le asigna la responsabilidad del desarrollo de un plan de implementación al Personal de la ICANN. Dependiendo de los detalles que se hayan proporcionado en las recomendaciones de políticas, esto podría ser un proceso sencillo, pero en algunos casos se desea o necesitan realizar consultas, aclaraciones o aportes adicionales.

A pesar de que se hayan llevado a cabo mejoras importantes en ciertas áreas, tales como el uso de los Equipos de Revisión de Implementación de la comunidad en el marco de las recomendaciones sobre políticas que brindó la GNSO, en la actualidad no existe un marco general organizativo que describa los pasos y oportunidades para realizar aportes sobre preguntas relativas a la implementación o cómo tratar las diferentes opiniones de las partes interesadas afectadas acerca de la manera en que se debería gestionar un esfuerzo para realizar una implementación.

De acuerdo a la posición o perspectiva de una persona, la diferencia entre una política y una implementación, a menudo, puede ser confusa. El desarrollo de políticas es una ciencia imprecisa. Las decisiones generales que se toman durante las negociaciones de políticas pueden ser difíciles de interpretar cuando se las enfrenta a los aspectos prácticos de la implementación.

Recientemente, se han presentado preguntas (como por ejemplo, durante la evolución de la guía para el solicitante para el Programa de Nuevos gTLD y también durante la negociación sobre contratos claves, tales como los de los acuerdos de los registros .com y .net, en lo que respecta al impacto de la posible incorporación de un modelo de registro de WHOIS “amplio”) sobre el momento en que ciertos problemas de implementación necesitan ser examinados con un nuevo PDP y el momento en que sería adecuado utilizar un proceso de comentario público para examinar un cambio que se propuso llevar a cabo.

Otros han preguntado cómo abordar “nuevos” problemas que posiblemente no fueron considerados plenamente durante la etapa del desarrollo de la política, cuándo la solución para un nuevo problema debería contar con el apoyo del consenso de la comunidad de la ICANN y cuándo debería la Junta Directiva o el Personal efectuar la resolución de un nuevo problema que surja de la implementación de una política con la toma de una serie de consejos, incluso si no hay un consenso de parte de la comunidad de la ICANN.

No existen soluciones fáciles para estas cuestiones, pero necesitan de una mayor consideración en tanto el modelo de múltiples partes interesadas de la ICANN continúe madurando.

Trabajando para lograr un mayor entendimiento

Así, en el espíritu de mejorar las políticas que precisan de liderazgo y contribuciones para prosperar y cumplir con sus objetivos y para lograr que estas discusiones sean más fáciles de abordar, bajo mi dirección, el Personal de Políticas ha desarrollado un marco preliminar para el debate de la comunidad que identifica una serie de pasos y criterios que podrían facilitar el trato de estas preguntas en el futuro. Este documento (http://gnso.icann.org/en/correspondence/policy-implementation-framework-08jan13-en.pdf [PDF, 195 KB]) brinda un resumen sobre los problemas a tener en cuenta en este contexto y también algunas sugerencias para llevar a cabo mejoras en el corto plazo.

Ya se han recibido comentarios constructivos de parte de varios grupos en respuesta al foro de comentario público (consulte el siguiente enlace: http://www.icann.org/en/news/public-comment/policy-implementation-31jan13-en.htm). Se programó una sesión sobre este tema para la reunión de la ICANN que se llevará a cabo en Pekín (a realizarse el miércoles, 10 de abril, de 9:00 a 10:30 am hora local) para continuar con este debate e identificar posibles próximos pasos a seguir.

Espero con ansias sus comentarios mientras continuamos promoviendo la participación activa de la comunidad en el modelo ascendente, orientado al consenso, de múltiples partes interesadas.


1 Iniciativa para la salud de las políticas de USAID: “Tomándole el pulso a las políticas” –Véase http://futuresgroup.com/files/publications/Taking_the_Pulse_of_Policy.pdf [PDF, 682 KB]

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