Lineamientos de Re/Delegación para Administradores de ccTLD


Documento de Trabajo del Grupo de Trabajo de Mejores Prácticas y Redelegación de los constituyentes del ccTLD del DNSO, parte de ICANN

18 de junio de 2000
Versión 2.0, para comentarios por los constituyentes de ccTLD

CONTENIDO

Introducción

Antecedentes

Observación sobre la intervención del gobierno en la Administración de un ccTLD

1. Definiciones
2. Principios
3. Lineamientos Generales
4. Procedimiento Para Presentación de Quejas
4.1 Procedimiento para Presentación de Quejas
4.2 Tipos de quejas
4.3 Quejas relativas a violaciones de las operaciones técnicas
4.4 Quejas relativas a violaciones de operaciones no técnicas.
4.4.1 Solución de la Queja
4.4.2 Falta de Solución de la Queja
5. Mediación
6. Proceso de Redelegación
6.1 Organismo para Resolución de Disputas de ccTLD
6.1.1 Integrantes y Conformación del Organismo Para Resolución de Disputas de ccTLD
6.2 Principios de la Redelegación
6.3 Trámites del Organismo de Resolución de Disputas de ccTLD
6.3.1 Deliberaciones
6.3.2 Criterios
6.3.3 Decisiones y Votación
6.3.4 Acceso a Expedientes
6.4 Apelaciones
7. Implementación de la Redelegación

 

Introducción

En la medida en que el Internet se transforma en un medio vital para la educación y los negocios, y dado que los nombres de dominio han adquirido valor como medios de identificación en el Internet, la responsabilidad y autoridad para administrar los dominios de alto nivel se han convertido en un punto de acalorada contienda. A instancias del Departamento de Comercio de los Estados Unidos, de la Autoridad Encargada de la Asignación de Nombres y Números del Internet (IANA), así como de huestes de otras organizaciones e individuos, se conformó la Corporación de Internet Para la Asignación de Nombres y Números (ICANN) para garantizar la estabilidad del Internet. Este es un proceso profundo dirigido a la institución del cambio y a evitar el abuso del poder monopolista.

Durante su período de ejercicio de poder, ICANN ha enfocado sus esfuerzos en lograr que el espacio genérico de alto nivel sea confiable y abierto. Mientras tanto, continúa la controversia en el espacio de alto nivel de dominio de país-código. Dentro del espíritu del mandato de auto-regulación de ICANN, los constituyentes del Alto Nivel de Dominio de País-Código (constituyentes del ccTLD) de la Organización de Apoyo del Nombre de Dominio (DNSO) de ICANN, han manifestado su intención de resolver las controversias que han surgido sobre la autoridad que debe administrar los dominios de alto nivel de país-código aplicando los principios y procedimientos que se establecen en este documento.

Antecedentes

Desde 1985, los administradores de ccTLD fueron sido delegados por IANA para administrar los ccTLD, o por el Dr. Jon Postel como cabeza de IANA, sobre la base de criterios no oficiales. En términos generales, a estos administradores se les reconocía como autoridad del Internet dentro del territorio descrito por el código de ccTLD, ya fuera sobre la base de sus conocimientos técnicos, su reputación en la comunidad global del Internet, o debido a su posición dentro del territorio pertinente del Internet. En 1994, el Dr. Postel y otros crearon el RFC 1591, que estableció los criterios para delegar un ccTLD a un administrador. Sobre esta base, todos los ccTLD subsecuentes fueron delegados a sus administradores. En ambos casos, las dos piedras angulares de la delegación de cualquier ccTLD por IANA a sus administradores eran la estabilidad del funcionamiento técnico de la zona delegada, y el servicio a la comunidad del Internet, tanto local como global. Esta doble tarea sigue siendo la principal responsabilidad de Administradores de ccTLD hasta la fecha y en el futuro previsible.

En 1998, IANA se fusionó con la recién conformada ICANN, y sus actividades se subordinaron a la mayor esfera de actividad de ICANN. Debido por una parte a la divergencia entre los principios de RFC 1591, y las prácticas de IANA por la otra, la gerencia de ICANN, durante su junta en Berlin en marzo de 1999, promulgó el IPC-1, que estableció la actual actividad de IANA. Desde entonces, RFC1591 y IPC-1 conjuntamente han sido los documentos cuyas instrucciones siguen los Administradores de ccTLD, cuando menos oficialmente..

Sin embargo, la realidad es que la fuente de autoridad para las operaciones de ccTLD era el Dr.Postel mismo. Su muerte prematura en 1998 dejó un vacío que no ha sido llenado por ICANN, que se ha dedicado a su tarea primordial de abrir el espacio de nombres de gTLD a la competencia. ICANN tampoco ha disfrutado de la confianza que los Administradores de ccTLD otorgaron al Dr. Postel. Durante sus últimos años, el Dr. Postel también estuvo muy ensimismado con el embrollo de gTLD, y no se ocupó mucho de los ccTLD, que en su mayoría se mantenían estables y cuyos problemas no lo inquietaban tanto. Por tanto, por algún tiempo los ccTLD se han regulado a sí mismos, con resultados generalmente positivos pero no totalmente libres de problemas. Por una parte, la mayoría de los Administradores de ccTLD se han establecido a sí mismos institucionalmente de una manera que ha sido aceptada —si no unánimemente, sí ampliamente— por las comunidades tanto globales como locales del Internet. Estos Administradores han solicitado asesoría de sus gobiernos, de proveedores de servicios de Internet, empresas, instituciones educativas, defensores del consumidor y otros, y se han ganado la aprobación y consentimiento de éstos y otros elmentos de su comunidad de Internet local. Estos ccTLD, tomando en cuenta las costumbres y situación de su localidad, han evolucionado para convertirse orgánicamente en instituciones vitales para Internet, y han logrado un consenso local que muy probablemente no hubieran podido obtener gradualmente de IANA, a pesar de las buenas intenciones de ésta. Estos relatos de logros indican que se sigue adelante. Por otra parte, IANA delegó algunos ccTLD a Administradores que hasta ahora no han logrado un consenso con la comunidad local de Internet, o que no han ejecutado su trabajo a satisfacción de IANA. Existen diversas causas: oposición a las políticas del Administrador; falta de una comunidad local de Internet reconocible con la que el Administrador pueda tratar exitosamente, especialmente en el caso de países subdesarrolados; y la influencia desestabilizadora del potencial de grandes utilidades, que ha llevado a algunos Administradores de ccTLD a seguir políticas impopulares, y, lo que es igualmente dañino, ha llevado a otros a impugnar la legitimidad del Administrador de ccTLD esperando obtener la delegación para su propio provecho.

En algunos casos, la mala administración de un ccTLD puede requerir que sea relevado de su cargo el Administrador , lo que se conoce como redelegación. Según la definición contenida en los Lineamientos de Mejores Prácticas de los constituyentes del ccTLD, el desempeño exitoso de un Administrador de ccTLD depende de la aprobación y aceptación de las comunidades de Internet locales y globales, así como del cumplimiento competente de las operaciones técnicas del ccTLD. Este documento establece los pasos y procedimientos que deben seguirse en el caso de que se contemple una delegación del ccTLD.

Nota Relativa a la Injerencia del Gobierno en la Administración de un ccTLD

El papel del gobierno en la administración de un ccTLD ha sido el objeto de considerable debate y resentimiento en diversas áreas, tanto dentro de ICANN como en el exterior, además de ser causa de incertidumbre entre los Administradores de ccTLD .

Es importante hacer notar que la comunidad local de Internet incluye —y debe incluir— al gobierno del territorio asociado con el código de país del ccTLD, y es también importante tomar en cuenta y dar gran peso a los deseos del gobierno en lo que respecta a un ccTLD, tanto por parte del actual Administrador del ccTLD como por parte de la comunidad global del Internet. Los gobiernos, sean buenos, malos o indiferentes, representan los intereses de un territorio en la arena global y, de una forma u otra, son responsables de que exista un entorno sano en lo económico, lo social y lo político, que permita la operación estable de cualquier empresa en el territorio.

Sin embargo, proteger a un Administrador ccTLD contra los tornadizos vientosde la política es igualmente importante. La estabilidad del ccTLD, que es la principal responsabilidad del Administrador de ccTLD, necesita estar a salvo de la caprichosa interferencia personal de alguna figura política; de distracciones causadas por maquinaciones para hacer dinero respaldadas por la influencia de un político; y de la pérdida de los derechos de la franquicia y pérdidas monetarias debidas a cambios en el gobierno. La voluntad del gobierno debe ser expresada en tal forma que garantice que se trata realmente de la voluntad del gobierno, y no de la de uno o más individuos dentro de un gobierno. El funcionamiento sin tropiezos de un ccTLD es parte del funcionamiento sin tropiezos del Internet como un todo. La estabilidad del ccTLD es parte de la estabilidad del Internet como un todo. Por tanto, las acciones de un gobierno en lo concerniente a un ccTLD no pueden verse simplemente como actos puramente locales, así como un gobierno no puede ser visto como el único interés al que debe servir el ccTLD. Un ccTLD pertenece a la comunidad local de Internet, de la cual el gobierno es una parte; pero también pertenece a la comunidad global del Internet.

El gobierno de un territorio indirectamente asume un poder substancial sobre el ccTLD, dado que RFC1591 y el IPC 1 requieren que el ccTLD tenga el contacto gubernamental, y por lo tanto está sujeto a las leyes de dicho territorio.

 

1. Definiciones
ccTLD — Un dominio de alto nivel de código de país en el nivel más alto del sistema de nombre del dominio global, asignado conforme al código de dos letras en los códigos estándar de ISO3166-1 para la representación de nombres de países o territorios.
Registro ccTLD - Entidad que registra nombres como nombres de dominio en un registro de nombres de dominio, para el nombre de dominio de alto nivel de código del país, de acuerdo con las políticas y reglamentos establecidos por el Administrador de ccTLD en concierto con las comunidades locales y globales de Internet, y de conformidad con los Lineamientos de Las Mejores Prácticas establecidos por la comunidad de ccTLD.
Administrador ccTLD. Empresa, organización o individuo que administra un registro de ccTLD.
Registrado — Empresa, organización o individuo para quien se ha registrado un nombre como nombre de dominio en el registro de nombres de dominio de ccTLD.
ICANN — Corporación de Internet Para Nombres y Números Asignados.
IANA — Autoridad que rige los Números Asignados de Internet (incoporada a ICANN en1999).
Comunidad Local de Internet — La industria de Internet y sus usuarios (por ejemplo, la comunidad educativa, el sector privado, las sociedas de Internet, usuarios individuales, etc.), así como el gobierno y oficiales del estado o territorio con el que está asociado el ccTLD.
Organismo Para Resolver Disputas de ccTLD - Un organismo —que se define más adelante en este documento— que ejercerá las funciones de grupo consultor para adjudicar disputas relativas a la administración de un ccTLD o al derecho de administrar un ccTLD.
2. Principios
3. Lineamientos Generales
Cuando surja la necesidad de redelegar un ccTLD o reemplazar un Administrador de ccTLD, dicha necesidad deberá surgir de una queja sobre un desempeño no satisfactorio por parte de un Administrador . Por tanto, cualesquier acción de redelegación ocurrirá únicamente cuando se hayan seguido los siguientes pasos:
a. Queja.
b. Dar oportunidad al Administrador de ccTLD de que resuelva la queja o elimine su causa, o de que notifique que considera que la queja no procede.
c. Mediación
d. Proceso oficial de redelegación
4. Proceso para la Queja
4.1 Proceso para la Queja.
Cualesquier parte que trate con un ccTLD puede presentar una queja ante IANA respecto al comportamiento del Administrador de ccTLD..
4.2 Tipos de Quejas
Cualesquier queja relativa al desempeño de un Administrador de ccTLD caerá dentro de una de las dos categorías siguientes:
4.2.1 Quejas concernientes a la operación técnica del ccTLD.
4.2.2 Quejas concernientes a la administración no técnica del ccTLD, incluyendo aquéllas acerca de las políticas o procedimientos de un ccTLD
4.3 Quejas de violaciones de operaciones técnicas.
En el caso de que se presente una queja concerniente a la operación técnica de un ccTLD, y cuando IANA considere que la supuesta violación sea una amenaza para la estabilidad del DNS, IANA puede exigir que sus estándares técnicos sean puestos en vigor inmediatamente, incluyendo la suspensión temporal de las operaciones del ccTLD. Tal supensión puede utilizarse solamente como una medida temporal, y puede mantenerse únicamente mientras IANA determine que levantar la suspensión representaría una amenaza a la buena operación del DNS.
4.4 Quejas de violaciones a operaciones no técnicas.
En el caso de que IANA considere como seria la queja sobre una supuesta violación no técnica, y considere que infringe los Lineamientos de Las Mejores Prácticas establecidos por los constituyentes del ccTLD, informará por escrito a dichos constituyentes lo relativo a la queja, y podrá ponerse en contacto con el Administrador del ccTLD para solicitar una explicación. Los constituyentes del ccTLD podrá dar a IANA su propio punto de vista sobre el asunto. Si se demuestra que la administración del ccTLD no ha operado el dominio según lo desea la comunidad local de Internet, o se niega a hacerlo, si tal deseo es consistente con los Lineamientos de las Mejores Prácticas, esto será suficiente para establecer la seriedad de la queja.
4.4.1 Cura de la Queja. Si una vez que IANA haya solicitado del Administrador de ccTLD una explicación sobre la aparente violación, IANA encuentra que dicha explicación es inadecuada; o si IANA recibe una queja sobre una violación seria de los Lineamientos de las Mejores Prácticas que requiere acción inmediata, puede dar instrucciones al Administrador del ccTLD para que rectifique el problema. IANA emitirá dichas instrucciones por escrito, y sugerirá el curso a seguir para rectificar la violación..
4.4.2 Si No Tiene Lugar la Cura. Si el Administrador del ccTLD se niega a curar una violación, o simplemente no lo hace, IANA emitirá una notificación escrita estableciendo que el Administrador está violando los lineamientos de las Mejores Prácticas. Tal notificación escrita será causa suficiente, a discreción de IANA en concierto con los constitulyentes del ccTLD, para iniciar las actividades de Mediación, como se describe más adelante. Ni IANA ni ICANN tomarán acción alguna para redelegar el dominio o reemplazar el Administrador del ccTLD sin antes iniciar los procesos de Mediación y Redelegación.
5. Mediación
En el caso de que aún ante violaciones serias y continuas el ccTLD sigue violando los Lineamientos de Las Mejores Prácticas, la Comunidad Local del Internet puede recusar la redelegación del ccTLD al Administrador del ccTLD y puede exigir que el Administrador sea reemplazado.
En tal caso, IANA intentará mediar la disputa. Será política de IANA insistir en que las partes pertinentes en una disputa sobre la administación de un ccTLD intenten de buena fe consultar una con otra de manera constructiva para resolver disputas concernientes a la administración del ccTLD, incluyendo la mediación de una tercera parte cuando proceda. El objetivo de la mediación deberá ser que las partes entiendan mejor los legítimos deseos, intenciones y actividades de la otra parte, y que estén de acuerdo en ajustar sus políticas y prácticas cuando sea necesario para dar cabida a los legítimos intereses de las otras partes. La mediación buscará instruir a todas las partes involucradas en lo concerniente a las mejores prácticas de la Comunidad de Internet y los métodos a seguir para que dichas Mejores Prácticas se ajusten a las circunstancias del ccTLD en cuestión. El objetivo primario de la mediación será asegurar que la operación de un ccTLD cumpla con los Lineamientos de Las Mejores Prácticas, que incluyen que el dominio se opere de acuerdo con los deseos de la comunidad local del Internet, cuando tales deseos sean consistentes con los Lineamientos de Las Mejores Prácticas.
IANA mantendrá minutas por escrito de toda mediación, para que en caso necesario se utilicen para el proceso de redelegación.
Una vez que se compruebe que se han hecho esfuerzos de buena fe para resolver el caso, pero se demuestre también que tales esfuerzos han sido en vano y no se ha llegado a una resolución satisfactoria de la disputa, IANA invocará el mecanismo de resolución de disputa que se describe a continuación. La sanción final de redelegación será considerada únicamente cuando se hayan agotado las alternativas para lograr que el ccTLD cumpla con los Lineamientos de Las Mejores Prácticas.
6. Procesos de Redelegación.
En el caso de que los intentos de mediación de buena fe no obtengan resultados, IANA invocará el proceso formal de redelegación. .
6.1 Organismo de Resolución de Disputas de ccTLD
El proceso de redelegación será dirigido por el Organismo de Resolución de Disputas, el cual adoptará los procedimientos necesarios para garantizar un proceso claro y justo para todas las partes, incluyendo audiencias abiertas con el derecho de tener la oportunidad por adelantado de hacer una revisión importante de toda la evidencia que se presentará en el proceso, presentar evidencia por escrito y por medio de testigos, y confrontar a los testigos que presenten evidencia adversa a una de las partes.
6.1.1 Lista de Miembros y Conformación del Organismo Para Resolución de Disputas del ccTLD.
El Organismo de Resolución de Disputas consistirá de un grupo de siete miembros, que serán designados como sigue:
a) Un miembro designado por la Comunidad Local de Internet.
b) Un miembro designado por el gobierno del territorio asociado con el código de país del ccTLD
c) Un miembro designado por los constituyentes del ccTLD.
d) Un miembro designado por el Administrador del ccTLD
e) Dos miembros designados por IANA
f) Un miembro, electo por IANA, que será "tercera parte confiable". IANA intentará encontrar una persona que sea una figura reconocida con experiencia en la resolución de disputas, que no esté involucrada ni con el territorio en cuestión ni con el Administrador del ccTLD ..
6.2 Principos de la Redelegación
Los principios que se presentan a continuación en forma de pregunta, deberán ser considerados antes de que el Organismo de Resolución de Disputas comunique su decisión:
a) ¿Podría suceder que la decisión del Organismo de Resolución de Disputas sea le origen de una injusticia fundamental, o el fundamento de tal injusticia?
b) ¿Podrá tal decisión constituir una desventaja para la comunidad local o global de Internet a un grado mayor que el de alguna ventaja percibida que pueda resultar de su implementación?
c) ¿Irá tal decisión contra las leyes del país en cuestión?
d) ¿Constituirá tal decisión una amenaza contra la estabilidad del DNS?
6.3 Procedimientos del Organismo de Resolución de Disputas de ccTLD

6.3.1 Deliberaciones

El Organismo de Resolución de Disputas se reunirá para deliberar, ya sea personalmente o por otros medios aceptables para los miembros del grupo y para los contendientes. Durante sus deliberaciones, el Organismo de Resolución de Disputas deberá:

a) Solicitar de IANA un pormenor escrito de todos los procedimientos previos relativos al debate, los cuales serán suministrados por IANA

b) Mantener una minuta escrita de todos los trámitess.

c) Incluir en las minutas todas las comunicaciones con los contendientes y con otras partes involucradas con las que se comuniquen dentro de sus actividades de descubrimiento de hechos y sus deliberaciones, y anotar en el expediente toda comunicación, solicitada o no solicitada que reciba de terceras partes

d) Intentar reunir toda la información pertinente, como obligación afirmativa.

e) Conceder a cada una de las partes en disputa la oportunidad de presentar evidencia y testigos en apoyo de su caso.

6.3.2 Criterios

El Organismo de Resolución de Disputas deberá tomar en cuenta los siguientes criterios, entre otros que considere apropiados:

a) El apego del Administrador a los Lineamientos de Las Mejores Prácticas o a otras normas de Internet.

b) La reputación del Administrador en la comunidad local (usuario) de Internet.

c) Las bases legales para la delegación original hecha al Administrador actual.

d) Investigar si el Administrador está haciendo mal uso de una posición dominante en el mercado.

e) Constatar si existe una alternativa aceptable para el Administrador actual. Un candidato optativo deberá:

1) Contar con una estructura o proceso que garantice que en el futuro no se presentará una situación de mal uso monopolista.

2) Tener acceso a la tecnología necesaria para operar un ccTLD de tal manera que la operación estable del DNS sea garantizada.

3) Ser viable financieramente

4) Ser aceptable para las comunidades local y global del Internet.

6.3.3 Decisiones y Votación.

Buscando una estabilidad continuada, el Organismo de Resolución de Disputas de ccTLD procurará llegar a una decisión unánime al finalizar sus deliberaciones. Sin embargo, de no ser posible llegar a tal decisión unánime, el Organismo de Resolución de Disputas de ccTLD requerirá por lo bajo una mayoría afirmativa de dos terceras partes de los miembros, incluyendo a los miembros sin voto.

El Organismo de Resolución de Disputas de ccTLD podrá llegar a una de las siguientes decisiones:

a) El Administrador actual de ccTLD retiene la delegación.

b) El ccTLD se redelega al la alternativa propuesta por el demandante.

c) Una de las anteriores, con modificaciones al método de alternativa del demandante o del actual Administrador

d) Se ordena que se establezcan las restricciones y condiciones que el Organismo de Resolución de Disputas de ccTLD considere apropiadas y justas bajo las circunstancias.

6.3.4 Acceso a los Registros

Para mantener la reserva, y propiciar un entorno que conduzca a un trabajo productivo, libre de interferencia exterior, el Organismo de Resolución de Disputas de ccTLD llevará a cabo sus diligencias en privado, pero pondra a la disposición de quien lo requiera su registros completos en el caso de que exista una apelación, o a solicitud de cualquiera de las partes, una vez que haya completado sus diligencias.

6.4 Apelaciones

Cualquiera de las partes en disputa puede apelar la decisión del Organismo de Resolución de Disputas de ccTLD ante un Tribunal de Apelaciones. La apelación será vista por seis miembros del la Mesa Directiva de ICANN, los cuales serán seleccionados como sigue:

a) Dos miembros seleccionados por el Administrador de ccTLD en funciones.

b) Dos miembros seleccionados por la Comunidad Local de Internet.

c) Dos miembros seleccionados por la Mesa Directiva de ICANN misma.

El Tribunal de Apelaciones recibirá el expediente completo de la disputa, y podrá recolectar nuevas pruebas y entrevistar a nuevos testigos si así lo estima necesario. El Tribunal de Apelaciones deberá mantener un expediente de todas sus deliberaciones, que estará a disposición del público una vez terminado el proceso de apelación. El Tribunal de Apelaciones podrá, con voto de dos terceras partes, decidir si toma una de las siguientes acciones:

a) Respaldar los resultados obtenidos y decisiones del Organismo de Resolución de Disputas de ccTLD.

b) Rechazar el fallo y decisiones del Organismo de Resolución de Disputas de ccTLD, en cuyo caso se reunirá un nuevo Organismo de Resolución de Disputas de ccTLD, para examinar nuevamente la disputa y tomar su propia decisión sobre la base de las reglas, principios y criterios establecidos en este documento.

Si llegara a suceder que el Tribunal de Apelaciones no pueda alcanzar una mayoría de votos de dos tercios, la decisión del Organismo de Resolución de Disputas de ccTLD será respetada.

7. Implementación de la Redelegación
En el caso de que sea necesaria la redelegación de un ccTLD, ya sea porque el Administrador previo de ccTLD no desee continuar, o se ordene una redelegación por el Organismo de Resolución de Disputas de ccTLD después de seguir los procesos descritos en este documento, IANA publicará un proceso para la selección de un nuevo Administrador para el ccTLD.
Para obtener la calificación y ser tomado en cuenta como nuevo Administrador, el candidato deberá demostrar que cuenta con cuando menos un contacto en el gobierno del país en cuestión; que está calificado técnicamente; que cuenta con el apoyo financiero necesario para administrar el dominio según lo requieren Las Mejores Prácticas definidas en los Lineamientos de las Mejores Prácticas; y que cuenta con la pericia, la visión, y la capacidad necesarias para servir los intereses de la Comunidad global del Internet; y de que está tan bien calificado o más calificado que cualquier otro solicitante para proteger los intereses de la comunidad local.

En su calidad de representante de la Comunidad Internacional del Internet, IANA aplicará su mejor juicio para seleccionar el Administrador que mejor pueda servir a la comunidad global y local del Internet representada por el ccTLD. Antes de anunciar su decisión final, IANA también solicitará y tomará en cuenta las opiniones de toda persona u organización que desee ofrecer sus comentarios. IANA también solicitará y tomará en cuenta las opiniones de la comunidad local de Internet hasta donde tales opiniones puedan ser consistentemente confirmadas.

Si desea mayor información, póngase en contacto con avc@iatld.org