Skip to main content

Welcome to the new ICANN.org! Learn more, and send us your feedback. Dismiss

ICANN formaliza relación con el administrador del ccTLD .br (Brasil)

This page is available in:

ICANN ha anunciado el día de hoy un intercambio de cartas con el administrador del registro del código de país (ccTLD) .br — Comite Gestor da Internet no Brasil (CGI.br) y administrado a través del NIC.br (Núcleo de Informação e Coordenação do .br, en portugués).

El programa de "Accountability Framework" provee dos mecanismos a través de los cuales los administradores de ccTLD pueden formalizar su relación con ICANN. El primero es el documento "Accountability Framework" que describe las obligaciones que desempeñan el administrador del ccTLD y también ICANN. Asimismo incluye provisiones para la resolución de conflictos y terminación de relaciones y está diseñado para aquellos administradores que requieren un documento formal con ICANN.

El segundo es un intercambio de cartas entre ICANN y el administrador del ccTLD diseñado para aquellos que prefieren un mecanismo más sencillo para el establecimiento de ciertos compromisos.

Los documentos que ha firmado ICANN con diversos ccTLDs, incluido el "Accountability Framework" con CGI.br, pueden encontrarse en: http://www.icann.org/cctlds/agreements.html

Demi Getshko (Contacto Administrativo del .br) y Pablo Hinojosa de ICANN en el intercambio de cartas durante la reunión de LACTLD en Isla Margarita, Venezuela.

Demi Getshko (Contacto Administrativo del .br) y Pablo Hinojosa de ICANN en el intercambio de cartas durante la reunión de LACTLD en Isla Margarita, Venezuela.

ANTECEDENTES

Una de las principales áreas de interés que han mostrado los actores involucrados en el desarrollo de Internet ha sido el establecimiento de mecanismos para reflejar de forma más apropiada las relaciones informales existentes y así reconocer con mayor claridad sus roles y responsabilidades.

Desde el año 2000, ICANN ha trabajado con los administradores de ccTLDs (los códigos de dos letras que identifican países y algunos territorios) para documentar el tipo de relación que estos tienen con ICANN. Estas relaciones son complejas debido a diversas circunstancias (económicas, legales, culturales, políticas, lingüísticas, organizacionales, procedimentales, entre otras) y que son únicas a cada ccTLD.

ICANN ha formalizado relaciones con varios ccTLDs, por ejemplo, .au, .jp y .ke a través de acuerdos llamados "de patrocinio". Sin embargo, es de reconocerse que estos acuerdos son muy detallados y por eso ICANN buscó la asesoría de ccNSO (la organización de soporte de los códigos de país) para generar una serie de criterios que fueran aceptables para una base amplia de ccTLDs. Fue así que ICANN desarrolló el documento de "Accountability Framework" basado en estas recomendaciones y que cuenta con la flexibilidad de poderse acomodar a las circunstancias individuales de cada ccTLD. Este documento puede ser tan sencillo como se desee.

La asistencia de la ccNSO fue inicialmente solicitada por ICANN en la reunión de Kuala Lumpur en Julio de 2004. En consecuencia, la ccNSO formó un grupo de trabajo en "Accountability Frameworks", cuyos miembros eran tanto internos de la ccNSO así como de la comunidad más amplia de ccTLDs. Adicionalmente a las discusiones ocurridas dentro del grupo de trabajo, también tuvieron lugar diversos intercambios en las reuniones de Cape Town, Mar del Plata y Luxemburgo.

El 14 de diciembre de 2005, el Consejo de ccNSO publicó el reporte del grupo de trabajo y generó una serie de guías para los administradores de ccTLDs con el fin de ser consideradas a la hora de discutir un "Accountability Framework" con ICANN. El 19 de diciembre de 2005, el Consejo publicó una resolución donde se hacían operativas dichas guías al no haber sido objetadas por ninguno de sus miembros. Estas guías fueron publicadas en el sitio web de ccNSO dentro de ICANN el 6 de enero de 2006.


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