Skip to main content

La transición del gobierno de Estados Unidos consta de cuatro vías de trabajo

Ntia stewardship transition work tracks 1200x762 20may14 es

Hace nueve semanas, Estados Unidos anunció la intención del gobierno de supervisar la transición de la custodia de la función de la IANA a la comunidad global. Este anuncio importante exige un enfoque cuidadoso y considerado para determinar la manera en que nosotros, la comunidad de Internet, trazaremos la ruta hacia una transición exitosa. Juntos, debemos aunar nuestros esfuerzos con el objetivo de desarrollar una propuesta aceptable y oportuna para una transición sin complicaciones.

Lo más importante es que nuestro proceso de transición se encuentra abierto y es inclusivo, al mismo tiempo que mantiene una disciplina y un enfoque que asegurará nuestro éxito dentro de un periodo razonable de tiempo. Considero que nuestro trabajo a futuro está dividido en cuatro vías simultáneas y mi deseo es mantenerlos actualizados sobre la posición donde nos encontramos en cada vía.

1. Transición de la custodia del gobierno de Estados Unidos de las funciones de la IANA en la ICANN

Al final del día jueves 8 de mayo, la comunidad envió más de 1000 correos electrónicos y comentarios con una retroalimentación al marco del proceso propuesto para la transición de la administración del gobierno de Estados Unidos que la ICANN está facilitando. Se recibieron comentarios en línea, a través de las redes sociales, de correos electrónicos, así como también a través de dos diálogos públicos de la ICANN 49 en Singapur y en NETmundial en Brasil.  Estos comentarios llevarán a un marco revisado del proceso de transición.

El objetivo del proceso es que la comunidad global desarrolle una propuesta de transición para el gobierno de Estados Unidos. De acuerdo con la Administración Nacional de Telecomunicaciones e Información de los Estados Unidos (NTIA), esta propuesta debe contar con un amplio apoyo de la comunidad y no debe reemplazar a la NTIA con una solución guiada por el gobierno ni con una solución intergubernamental.

Durante las próximas semanas, se leerán y analizarán todos los aportes y, por último, se creará un marco revisado del proceso de transición antes de la ICANN 50 en junio de 2014.

2. Fortalecer la responsabilidad de la ICANN

Hace dos semanas, comenzamos un debate comunitario para mejorar la responsabilidad de la ICANN por medio de la publicación de un documento de referencia y preguntas para los aportes. Este diálogo se encuentra abierto a todos. Por favor, envíen sus comentarios antes del 27 de mayo, acerca de cómo la ICANN (la organización) debería ser responsable ante ustedes luego de la transición de la administración de la IANA. Se recibirá con agrado su opinión acerca de cómo podemos fortalecer los mecanismos de responsabilidad existentes como la Afirmación de Compromisos. Asimismo, sus perspectivas nos ayudarán a evaluar los mecanismos de reparación de la ICANN y explorar nuevos mecanismos de responsabilidad en caso de ser necesarios. Esperamos que las Organizaciones de Apoyo y los Comités Asesores de la ICANN determinen los participantes de un nuevo Grupo de Trabajo comunitario, que guiará este proceso, de modo que el trabajo pueda comenzar durante la Reunión Pública ICANN 50, en Londres, en junio.

3. Mantener la seguridad y la estabilidad de la implementación de las actualizaciones de la zona raíz

En la actualidad, el flujo de procesos para la gestión de la zona raíz incluye tres funciones que desempeñan tres entidades diferentes: la NTIA como Administrador, la ICANN como Operador, y Verisign como Mantenedor. Luego de la transición, el rol de la NTIA como Administrador se reemplazará por mecanismos a ser determinados por ustedes, la comunidad global, para asegurar la responsabilidad de la ICANN frente a la comunidad en cada solicitud para actualizar la zona raíz. La ICANN permanecerá en su rol de Operador y establecerá una relación directa con la tercera parte, el Mantenedor.

Como un medio para ayudar a asegurar la estabilidad, la opción de implementación que recomienda la ICANN es que Verisign continúe en su rol de Mantenedor. No obstante, estaremos trabajando estrechamente con todas las partes interesadas, inclusive los Operadores de la Zona Raíz, para asegurar que existan opciones de contingencia listas para cumplir nuestro compromiso absoluto por la estabilidad, seguridad y flexibilidad del Sistema de Nombres de Dominio.

4. Fortalecer relaciones bilaterales con organismos políticos

El personal de la ICANN comenzó un trabajo inicial para revisar y fortalecer los compromisos formales e informales existentes entre la ICANN y los organismos que desarrollan políticas que implementa el departamento de la IANA. Permítanme ser claro: las políticas que implementa la IANA las desarrolla el Grupo de Trabajo en Ingeniería de Internet (para parámetros de protocolo), la Organización de Apoyo para Direcciones (para direcciones IP), la Organización de Apoyo para Nombres Genéricos (para nombres de dominio genéricos) y la Organización de Apoyo para Dominios de Alto Nivel con Código de País y Nombres de Dominio con Código de País (para nombres de dominio con código de país). Su ayuda es bienvenida para fortalecer estas relaciones y las garantías de una clara división entre los procesos que desarrollan las políticas y su implementación.

Puede consultar los compromisos existentes con los organismos políticos en la siguiente página: Acuerdos Importantes e Informes Relacionados de la ICANN.

Además, aquí hay otros enlaces de acuerdos importantes y documentos relacionados:

Tenemos mucho por hacer en los próximos 15 meses. Juntos, debemos administrar con detenimiento estas cuatro vías simultáneas e interrelacionadas. Y, mientras que septiembre de 2015 no es una fecha límite, debemos organizarnos bajo un plan definido para tener éxito. Éste es un trabajo importante y estoy seguro de que, unidos, podremos realizarlo.

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