Skip to main content

Una actualización sobre el progreso: Garantizar la Seguridad, Estabilidad y Flexibilidad del mantenimiento de la zona raíz

El 10 de marzo de 2016, un plan para la transición de la custodia de la IANA de la supervisión del gobierno de EE. UU. a una comunidad global de múltiples partes interesadas se presentó a la NTIA para su consideración. Ser testigo de los extraordinarios esfuerzos de la comunidad de múltiples partes interesadas para desarrollar estas propuestas ha sido impresionante y aleccionador.

Si bien la comunidad ha trabajado arduamente para finalizar las propuestas incluidas en el plan, mi equipo y yo nos hemos estado preparando de manera diligente para la fase de implementación de la transición anticipada de la custodia de la IANA. Una de las tareas que deben completarse es que la ICANN y Verisign celebren un Acuerdo de Entidad Encargada del Mantenimiento de la Zona Raíz (RZMA). Otra es extender el Acuerdo de Registro de .com para que se ejecute por el mismo plazo que el RZMA, lo que la ICANN y Verisign consideran que mejora la seguridad, estabilidad y flexibilidad de la infraestructura de la zona raíz. Hoy, deseo brindarles algunos datos contextuales sobre el RZMA y una actualización sobre nuestro progreso.

Como se destacó en la propuesta del Grupo de Coordinación de la Transición de la Custodia de las Funciones de la IANA (ICG), una transición completa y definitiva requiere la revisión de la relación entre la actual entidad operadora de las funciones de la IANA (ICANN), la RZM actual (Verisign) y la actual entidad administradora de la Zona Raíz (NTIA). Específicamente, el rol de la NTIA será eliminado y se debe implementar un acuerdo por escrito entre la ICANN y Verisign que establezca el rol de cada una de las partes una vez que eso suceda.

El 4 de marzo de 2015, la NTIA solicitó oficialmente que la ICANN y Verisign trabajen conjuntamente para elaborar una propuesta sobre la mejor forma de realizar la transición del rol administrativo de la NTIA asociado con la gestión de la Zona Raíz. De suma importancia es lograr esto de manera tal que se mantenga la Seguridad, Estabilidad y Flexibilidad del proceso de gestión de la Zona Raíz. La ICANN y Verisign están cerca de tener los términos y condiciones que cumplen este objetivo esencial y que claramente definen los respectivos roles y responsabilidades de cada una de las partes.

En general, ya hemos acordado que Verisign será remunerado por el desempeño de la función de entidad mantenedora y tendrá obligaciones que cumplir con ciertos Acuerdos de Nivel de Servicio (SLA) que las partes pueden adaptar para abordar las recomendaciones del Comité Permanente de Clientes de conformidad con un proceso de control de cambios anticipado en el acuerdo. Este proceso de cambios se está definiendo con el fin de permitir que la comunidad, a través de la ICANN, incorpore mejoras al Sistema de Gestión de la Zona Raíz también. Si bien el plazo del RZMA está destinado a promover la Seguridad, Estabilidad y Flexibilidad de las operaciones de mantenimiento de la zona raíz al hacer que Verisign continúe en su rol, el acuerdo también brinda la capacidad para que la comunidad, a través de un proceso impulsado por la comunidad y basado en consenso haga que la ICANN realice la transición de la función a otro proveedor de servicios después de una cantidad de años acordada.

Hay algunas cuestiones pendientes que deben resolverse antes de que finalicemos una versión preliminar del acuerdo. Es difícil enumerar estas cuestiones porque hay discusiones en curso y el estado de las cuestiones cambia con frecuencia. Sin embargo, estamos realizando buenos avances y esperamos finalizar una versión preliminar pronto.

Una vez que la ICANN y Verisign hayan finalizado el acuerdo preliminar, éste será publicado durante un período de 30 días para ser revisado por la comunidad. Esto está de conformidad con la transparencia de la ICANN así como con mantener la recomendación contenida en la propuesta del ICG de hacer que la propuesta preliminar esté disponible para revisión pública antes de su ejecución.

Aún hay trabajo por hacer pero estamos realizando buenos avances. Les recomiendo visitar las páginas web mencionadas más abajo para obtener más información y mantenerse al tanto de los avances más recientes.

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