[Lac] Documento de posición de Enrique Chaparro
Valeria Betancourt
valeriab at apc.org
Fri Feb 27 15:49:33 GMT 2004
uy! tuve problemas con el servidor de correo esta mañana y envié los mensajes
de Enrique antes de ver que Beatriz ya lo había hecho.
Disculpen la duplicación!
En Ecuador decimos que en la repetición está gusto! ;) (no en todo, por
supuesto) :)
Muchos saludos,
Valeria
On Thursday 26 February 2004 09:56 pm, Beatriz Busaniche wrote:
> Se que Enrique envio esto a nuestro caucus esta mañana y por alguna
> misteriosa razón no ha llegado.
> Reenvio entonces en su nombre, ambos mensajes de Enrique,
> primero una introducción al tema, y
> más abajo el documento de posición
> redactado sobre el tema de "gobierno" de Internet.
>
> De todos modos, también se que Katitza lo ha publicado en el sitio
> de CPSR Perú apenas llegó a sus manos.
> http://peru.cpsr.org
>
> Saludos
> Beatriz
>
> ============================= Begin forwarded message:
>
> Date: Thu, 26 Feb 2004 10:48:11 -0300
> From: Enrique A. Chaparro <echaparro at uolsinectis.com.ar>
> To: lac at wsis-cs.org
> Subject: Documento de posición
>
>
>
> Parece que cada vez que tengo la lista fuera de sintonía por un par de
> semanas suceden cosas interesantes :)
>
> A quienes consideraron postularme para hablar en nombre de este grupo en
> la reunión de LACNIC, mi agradecimiento. Mientras leía el (largo)
> `backlog'
> de mensajes que esperaban en mi casilla, caí en la cuenta de que cosas que
> he escrito sobre el `gobierno' de Internet estaban desperdigadas, o
> desactualizadas (o ambas cosas).
>
> Así pues, decidí llevar a cabo un reordenamiento de ideas, y escribir
> (o re-escribir) un documento de posición. Este tiene la doble intención
> de satisfacer la legítima inquietud de quienes se preguntaron cuál era
> mi posición al respecto, y servir de borrador para un trabajo en
> evolución.
>
> Va en un mensaje separado, y les ruego disculpar la longitud (por ahora,
> no he tenido tiempo de subirlo a un sitio web).
>
> El documento establece mi visión respecto de qué y como debe `gobernarse'
> en la Internet. Cualquiera que adhiera a lo allí expresado, cuenta con mi
> mas cálida adhesión para representar a este pequeño sector de la sociedad
> civil de LAC en la reunión de LACNIC.
>
> En muchos aspectos, coincido con las opiniones vertidas por Carlos Afonso.
> Discrepo en otras, lo que resultará evidente de la lectura del documento.
> Me parece que la diferencia estriba, sobre todo, en la interpretación del
> rol de la comunidad de usuarios y usuarias.
>
> Así pues, me sentiré bien representado por cualquiera que adhiera a los
> lineamientos generales expresados en el documento. No obstante ello, me
> sentiría mucho más tranquilo si quien llevase la voz de este grupo a la
> reunión de LACNIC no perteneciese a la estructura formal de ICANN.
> Miembros
> de esta lista que pertenecen a dichas estructuras (Erick Iriarte Ahon,
> miembro del Interim At-Large Advisory Committee elegido por el Board de
> ICANN, y Carlos Afonso, miembro del Council de GNSO), han tenido la
> encomiable actitud ética de renunciar a sus postulaciones. A ellos, mis
> felicitaciones.
>
> Saludos,
>
> Enrique
>
> ============================= End forwarded message
>
> ============================= Begin forwarded message:
>
> Date: Thu, 26 Feb 2004 10:52:46 -0300
> From: Enrique A. Chaparro <echaparro at uolsinectis.com.ar>
> To: lac at wsis-cs.org
> Subject: Documento de posición [2]
>
>
>
> Una vez más, les pido que acepten mis disculpas por la extensión del
> documento. Como el documento es sólo texto, con indentaciones basadas
> en espacios, les aconsejo verlo con una fuente equiespaciada (por
> ejemplo, Courier). Configurar su cliente de correo para que represente
> los mensajes en una fuente equiespaciada es normalmente una tarea
> sencilla.
>
> Saludos,
>
> Enrique
>
> :::DRAFT:::DRAFT:::DRAFT:::DRAFT:::DRAFT:::DRAFT:::DRAFT:::DRAFT
>
> Febrero 2004
> v0.2
>
> Un documento de posición sobre
> el `gobierno' de la Internet
>
> Enrique A. Chaparro
>
>
> Sección I
> La ICANN y el `gobierno' de Internet
> -------------------------------------------------
>
> La Internet no es más que ``un sistema abierto que lleva paquetes
> IP desde una dirección IP de origen a una dirección IP de destino''
> (ver también [1]). Y, sin embargo, es también un sistema social,
> político y económico que erosiona las soberanías nacionales. Pero los
> poderes que ellas detentaban no desaparecen, no `se disuelven en el
> aire' mágicamente. Están fluyendo hacia manos privadas: las corpora-
> ciones, las alianzas intercoporativas, organizaciones cuasi-no-
> gubernamentales (a veces disfrazadas de multilaterales como WTO, WIPO
> o WEF). Los órganos de gobierno de Internet son parte de los fenómenos
> generados por este flujo.
>
> No soy un fanatico de la ICANN. Mas bien, todo lo contrario. Creo
> que si alguna vez ha de servir al interes publico (y no a intereses
> corporativos), sera necesario previamente deshacerla y reconstruirla
> como un sistema coordinado (pero no fuertemente acoplado) de
> organizaciones internacionales, multilaterales, democraticas y
> no-burocraticas [2].
>
> Existe el mito de que ICANN solo se ocupa de `cuestiones técnicas',
> cuando en realidad no hace practicamente nada que pueda vicularse
> siquiera remotamente con cuestiones tecnicas. La existencia de ICANN
> ha transcurido en la promocion de los planes de ciertos selectos
> intereses comerciales (particularmente, de Estados Unidos y Europa),
> y evitando involucrarse en cuestiones que atiendan (y, mucho menos,
> promuevan) la estabilidad técnica de la Intenet. Se dice que ICANN
> `administra, coordina y asigna direcciones IP'. Falso. Se dice que
> ICANN `administra y coordina el sistema de servidores raiz'. Falso
> tambien. Algunos sostienen que la tarea de `promover la competencia
> en el espacio de dominios genéricos de nivel superior (gTLD)' es una
> tarea de coordinación técnica. Eso es una broma de mal gusto. Y, por
> último, ICANN ha creado una política global de resolución de disputas
> sobre nombres de dominio que no tiene el más mínimo componente técnico
> y es un acto regulatorio supranacional basado en la coerción.
>
> Sin embargo, me temo, hay males peores que la ICANN:
> - el gobierno de la Internet por parte de los gobiernos[3];
> - el gobierno de la Internet por parte de organismos inter-
> gubernamentales (e.g., ITU)
> Si cayeramos en alguna de estas opciones, a los males actuales habria
> que sumar la ineficiencia y, en un numero no trivial de casos, la
> censura. Como prueba, a la historia me remito.
>
> Hasta podría ser peor. Podría ser una ``public private partner-
> ship'', frase rimbombante que se ha puesto de moda recientemente. En
> la práctica, estas PPP implican la transferencia de poderes estatales
> a manos privadas sin imponerles al mismo tiempo las condiciones de
> debido proceso, supervisión pública y obligación de rendir cuentas
> que caracterizan a los gobiernos democráticos.
>
> Poco importa si un órgano de gobierno es público, privado, o mixto
> en cualquier forma. Sus roles deben ser cuidadosamente definidos y
> limitados para evitar que, como en el caso de la ICANN, sea `capturado'
> por aquellos a los que se supone debe supervisar, o por otros que
> hallen ese órgano útil para promover una agenda en favor de un interés
> sectorial privado.
>
> Gobierno es poder. Y poder es poder dondequiera que se lo use, se
> lo sufra o se lo resista. No debemos engañarnos y suponer que la
> adición del complemento ``de internet'' de alguna forma atempera o
> elimina los riesgos y los peligros de dicho poder. Resulta indispen-
> sable que el poder para gobernar los aspectos `gobernables' de la
> Internet sea limitado, constreñido, y sujeto a la indagación pública
> del mismo modo en que, en los estados democráticos de derecho, se
> establecen límites precisos a cualquier poder gubernamental.
>
> El gobierno debe estructurarse de modo tal que el poder esté
> dividido, no concentrado; que se construyan tensiones por oposición
> de intereses garantizando que no resultará sencillo para ningún
> actor hacerse de una cuota de poder mayor a la que le corresponde.
>
> Las estructuras de gobierno de la Internet deben estar sujetas a
> supervisión y revisión; deben estar abiertas a todos los que se
> sientan afectados por las cuestiones objeto de gobierno. Deben
> construirsee sobre la comunidad universal de usuarios de la Internet.
> Y, por supuesto, deben ser responsables ante esa comunidad sin que
> haya más de un nivel de representación entre los miembros de la
> comunidad y las personas a quienes se han confiado los poderes de
> gobierno.
>
> Si algo hemos aprendido de la ICANN, es que los conceptos
> `consenso' y `stakeholder'[4] son demasiado vagos, y propician situa-
> ciones en que los conflictos de poder se resuelven por selección y
> manipulación en sustitución de la argumentación razonada. Cualesquiera
> sean las nuevas estructuras de gobierno que haya que crear (y sustento
> la esperanza de que sean mínimas), deberán usar mecanismos de votación
> y permitir la participación de todos los interesados en las cuestiones
> que se traten, en lugar de encasillarlos en tal o cual grupo de
> `stakeholders'.
>
> Pretendo una Internet anárquica[5]. Las regulaciones en ella
> deben ser las necesarias para distribuir racionalmente recursos escasos
> y administrar infraestructura comun, pero ni un grano mas.
>
>
> Sección II
> Qué es lo que hay que `gobernar'?
> -----------------------------------------------
>
> Ahora bien, que aspectos de la Internet podrian llegar a necesitar
> alguna forma de `gobierno'? A mi juicio, los siguientes:
>
> 1) Un sistema de normas tecnicas (estándares) que constituyen el
> `pegamento' de interoperabilidad de toda la red;
> 2) Un sistema de asignación de direcciones IP que opere en forma
> consistente a traves de los sistemas de enrutamientos de
> paquetes IP[6];
> 3) Un sistema de intercambio de trafico entre 'carriers'/ISPs que
> brinde a los usuarios finales razonable aseguramiento de que
> los flujos de trafico obtendran los niveles de servicio
> especificados.
> 4) Un sistema de asignación de números de protocolo y otros
> identificadores.
>
> En la situacion actual, con un sistema de nombres de dominio
> fuertemente jerarquizado y dependiente de los servidores raíz (root
> servers), existen otros dos aspectos que requeririan `gobierno':
>
> 5) La supervisión responsable, y con obligacion de rendir cuentas
> públicamente, del conjunto de servidores raiz del sistema de
> nombres de dominio (DNS);
> 6) La gestión del archivo de zonas raiz (DNS root zone file),
> incluyendo la tarea de prepararlo y distribuirlo a los servidores
> raiz, y el desarrollo y la aplicación de políticas de incoporación
> de nuevos dominios de nivel superior (TLDs) a la zona raíz.
>
> En este segmento hay, sin duda, TLDs cuya administracion es
> cuestion soberana de los Estados (.mil, .gov en el caso de los Estados
> Unidos, y sus equivalentes en cada pais), o corresponde a organismos
> multilaterales (.int). Resultaria admisible, aunque el debate debe
> darse tanto a nivel global como nacional, que ciertos TLDs sean
> manejados por el sector de interes especifico (edu, net y sus
> equivalentes locales).
>
> ¿Por qué relativizo ``en la situacion actual''? Porque es
> tecnicamente posible tener un sistema de nombres de dominio federado y
> debilmente acoplado, en lugar de uno jerarquico. Inclusive seria
> posible `federar' la zona in-addr.arpa raiz. En la practica, con solo
> construir los acuerdos minimos necesarios para que no existan dos TLDs
> iguales con asignaciones de nombre distintas, es tecnicamente posible
> (y no hay norma que lo impida) que coexista un gran numero de TLDs
> (tanto gTLDs como ccTLDs). La existencia de OpenNIC prueba suficiente-
> mente mi punto: no necesitamos de ICANN o cualquier sustituto que
> podamos inventar en el futuro para administrar los TLDs. Este mito,
> que ICANN y sus partidarios se han empeñado en difundir, debe ser
> enterrado.
>
> Pero (y siempre hay un `pero'), ``Architecture is politics'' como
> dice Mitch Kapor, asi que en el análisis de las secciones siguientes
> supondremos que esa arquitectura jerárquica continuará existiendo,
> al menos por un tiempo.
>
> Finalmente, hay una actividad actualmente asumida por la ICANN que
> _definitivamente_ esta fuera de lo `gobernable':
>
> 7) El establecimiento de una politica coercitiva para la resolucion
> de disputas sobre los nombres de dominio.
> Para ello existen mecanismos legales precisos en las legislaciones
> de cada pais, sin necesidad de recurrir a este engendro compulsivo
> que deja muy, pero muy mal paradas a las normas del debido proceso.
>
>
> Sección III
> ¿Cómo `gobernar'?
> ---------------------------------
>
> Sostengo que la manera más adecuada de gobernar Los `aspectos
> gobernables' de la Internet es mediante órganos distintos, cada uno de
> los cuales se ocupe de un conjunto único de tareas administrativas o
> de definición de políticas. Esta estructura modular no sólo contempla-
> ría mucho mejor los intereses de la comunidad usuaria; también
> resultaría, probablemente, en una reducción sustantiva de costos y
> esfuerzos.
>
> Hasta donde resulte practicable, cada uno de los órganos de
> gobierno debe ser diferenciado y separado. Cada uno de ellos debe
> tener su propia estructura jurídica. No debe haber directores,
> ejecutivos, empleados o fuentes de financiamients comunes entre ellos.
> Toda comunicación entre órganos de gobierno debe ser escrita, y
> ponerse a disposición del público en la Internet simultáneamente con
> su comunicación al destinatario.
>
> Como verán en la enumeración que aparece más abajo, el conjunto de
> actividades requeridas para gestionar eficientemente los aspectos que
> antes mencionábamos implican distintos grados de discrecionalidad. En
> función de estos grados de discrecionalidad, es posible imaginar tres
> sistemas para la toma de decisiones:
>
> - En los casos en que el grado de discrecionalidad es muy limitado,
> o en que las consecuencias del abuso de dicha discrecionalidad son
> restringidas (o fácilmente reversibles), un sistema de revisión
> pública `ex-post'. Las acciones se publicitarán después de tomadas,
> y por un período luego de la publicación, todo aquel que se sienta
> afectado podrá impugnarla.
>
> - En los casos en que el grado de discrecionalidad sea mayor (aunque
> en cualquier circunstancia limitado), un sistema de control público
> `ex-ante'. La decisión propuesta se hace pública, se abre un período
> de comentarios, estos son considerados, y finalmente se publica la
> decisión basada en dichos comentarios. Este sistema debe tener
> mecanismos de supervisión externa y de revisión que permitan manejar
> las situaciones extraordinarias de arbitrariedad o violación de
> los procedimientos establecidos.
>
> - Finalmente, en los casos en que la discrecionalidad es amplia o haye
> un impacto público significativo, será necesario diseñar sistemas de
> gobierno de mayor complejidad. Por ejemplo, las creación de políticas
> respecto del sistema de nombres de dominio exige que todas las partes
> potencialmente afectadas tengan derecho a participar en el debate y
> en la decisión en pie de igualdad con todas las demás partes.
>
> En los dos primeros sistemas, además, será necesario que recaiga
> en quien toma la decisión la carga de la prueba de demostrar que las
> presentaciones o los comentariso han sido debidamente revisados y
> considerados.
>
>
> Sección IV
> Actividades que requieren gobierno
> -----------------------------------------------
>
> 1. Estándares
> -------------
>
> Los estándares son lo que hace posible la Internet. Ningún otro
> componente es más crucial, pues ellos mantienen acoplada toda la
> estructura que hace posible la existencia misma de la red de redes.
> Por más de 30 años[7], el IAB, la IETF y el IESG han hecho un trabajo
> extraordinario. El proceso de generación de estándares (RFC-2026,
> BCP-9) es abierto a toda la comunidad, con múltiples instancias de
> revisión.
>
> Otros órganos normalizadores, como el W3C (World Wide Web
> Consortium) han hecho también un excelente trabajo, dentro de un
> modelo de proceso muy parecido al de IETF/IESG, para establecer
> estándares que hacen posible la existencia de aplicaciones de uso
> masivo e interoperables. La diferencia esencial es obvia: es posible
> la existencia de la Web sin que todos los actores respeten a pies
> juntillas las normas del W3C[8], aunque ello resulte en discriminación
> de algunos usuarios; pero no es posible la existencia de la Internet
> sin los STD[9] de la IETF.
>
> *Conclusión*: Aquí no parece necesario hacer nada, salvo respetar
> el viejo axioma: ``if it isn't broken, don't fix it''. Sin embargo,
> dada la creciente amenaza que representan las patentes de software,
> habría que presionar en favor de la revisión del proceso de creación
> de estándares para que se incluya una política respecto de las patentes
> de software similar a la adoptada por el W3C [10].
>
> 2. Asignacion de direcciones IP
> -------------------------------
> Antes de entrar en el detalle, una advertencia: la escasez relativa
> de direcciones IP es un fenómeno circunstancial. El despliegue de la
> infraestructura IPv6 resuelve el problema[11], por lo menos por largo
> tiempo. Pero también es de notar que subsisten aún inconvenientes para
> la implantación de IPv6 a escala; algunos de ellos son técnicos, pero
> buena parte tiene que ver con el interés corporativo, del mismo tipo
> que los que impiden el establecimiento de nuevos gTLDs (cuestión que
> trataremos más adelante). Mientras esta escasez subsista, es posible
> identificar dentro de esta función tres actividades centrales:
>
> a) Formulación de políticas para la asignación de direcciones
> ..............................................................
>
> Las decisiones que se toman en este terreno tienen no sólo impacto
> técnico, sino también, y de modo mucho más significativo, impacto
> social y económico. Los países o instituciones que pueden obtener
> asignaciones tienen una ventaja competitiva frente a los que no pueden
> obtenerlas. Muchas de las decisiones sobre asignación que se adoptan
> hoy se basan en supuestos implícitos sobre su impacto, y este se mide
> sólo en términos de sus efectos en los ISP y los provedores de equipo
> en lugar de tomar en cuenta a la comunidad de usarios de Internet en
> general.
>
> Es bastante improbable que la cuestión de la asignación de
> direcciones IP pueda permanecer aislada de un debate más general. Al
> mismo tiempo, la creación de políticas de asignación de direcciones IP
> requerirá en el futuro mayor supervisión (y escutinio público) que la
> que se requiere hoy.
>
> Si bien, como lo señalaba más arriba, la creación de políticas de
> asignación tiene muchos efectos sociales y económicos, es probable que
> muy pocas personas e instituciones aparte de los ISPs, los grandes
> consumidores de espacio de direcciones o los fabricantes de routers
> deseen asumir los tiempos y los esfuerzos que implica una participa-
> ción activa en este campo. Por lo tanto, el esquema actual de
> establecimiento de políticas que usan los RIRs (registros regionales
> de direcciones IP: APNIC, ARIN, RIPE, LACNIC) podría continuar sin
> grandes variantes hasta que aparezcan las dificultades.
>
> No obstante ello, será necesario:
> - Establecer un proceso de revisión periódica, por un órgano de
> control sujeto a escrutinio público, para determinar si las mencio-
> nadas dificultades han aparecido y, dado el caso, si se requiere
> establecer un sistema de gobierno más complejo;
>
> - Establecer un sistema de control público `ex-ante' sobre las
> políticas de asignación; y
>
> - Democratizar la estructura de los RIRs, de modo que segarantice la
> participación con voz y voto, en pie de igualdad, de la comunidad
> de usuarios de Internet de la correspondiente región.
>
> *Conclusión*: Dejemos esta función en manos de los RIRs, pero
> revisemos periódicamente la situación (con una periodicidad no mayor
> a dos años). Al mismo tiempo, hagamos transparente la formulación de
> políticas y democraticemos los RIRs.
>
> b) Asignación de grandes bloques de direcciones IPv4 o IPv6
> ...........................................................
> Este es el proceso mecánico de poner en práctica las políticas de
> asignación de direcciones[12]. Dependiendo de la precisión de las
> políticas de asignación, la tarea de administrar dichas políticas
> puede ser predecible, con un grado muy reducido de discrecionalidad
> administrativa. Teniendo en cuenta el impacto de las decisiones sobre
> asignación, resultaría razonable aplicar un sistema de control `ex-
> ante'; pero como muy habitualmente el tiempo es un factor importante
> en el proceso de asignación, tal vez resulte suficiente con un sistema
> de revisión 'ex-post'.
>
> *Conclusión*: Con las salvedades del ítem a) anterior, esta
> función puede quedar en manos de los RIRs.
>
> c) Mantenimiento de la zona in-addr.arpa
> ........................................
>
> En cada capa de la jerarquía de asignación de direcciones IP es
> necesario construir las entrada apropiadas en la jerarquía de DNS
> in-addr.arpa. Esta tarea, normalmente, es llevada a cabo por la
> persona o entidad que realiza la delegación de direcciones. En los
> niveles superiores es ejecutada por los RIRs, y en los inferiores por
> las instituciones o las personas a quienes se han delegado bloques de
> direcciones.
>
> Esta es, esencialmente, una tarea sin discrecionalidad. Para las
> asignaciones por los RIRs, resultaría apropiada emplear un sistema de
> control `ex-post'; en los niveles inferiores no debería imponerse
> ningún sistema de gobierno.
>
> *Conclusión*: Con las salvedades del ítem a) anterior, esta
> función puede quedar en manos de los RIRs.
>
> 3. Ruteo y niveles de servicio
> ------------------------------
>
> Poco o nada se ha discutido en esta área. Es de esperar, sin
> embargo, que los ISPs y los `carriers' se opondrán a cualquier
> intento de imponer algún gobierno sobre las cuestiones de enrutamiento
> de paquetes, filtrado, y reconocimiento entre `carriers' de las
> obligaciones de nivel de servicio de extremo a extremo.
>
> Resulta esencial discutir abierta y democráticamente estas
> cuestiones, y dotar a la comunidad usuaria de herramientas potentes
> para el aseguramiento de la calidad de servicio. Al mismo tiempo,
> será necesario contemplar el equilibrio de numerosas cuestiones
> técnicas, económicas y sociales, teniendo en cuenta que estos
> equilibrios pueden determinar completamente el destino de segmentos
> o servicios completos, como por ejemplo voz sobre IP. Por ello, es
> probable que se requiera una estructura de gobierno compleja, que
> reúna los aspectos positivos de:
> - las estructuras que supervisan la conectividad y la calidad de
> extremo a extremo en las redes telefónicas; y
> - los mecanismos de regulación/supervisión que se imponen a las
> empresas prestadoras de servicios públicos.
>
> No tengo opinión formada sobre cómo estructurar este órgano de
> gobierno. Pero sí estoy definitivamente convencido de que nada se
> logrará si no se da un lugar preponderante a la comunidad usuaria
> como actor en la toma de decisiones.
>
> 4. Asignación de números de protocolo y otros identificadores
> -------------------------------------------------------------
>
> Para los estándares de la IETF, la ejecución de esta tarea exige
> el grado de coordinación suficiente con la IETF para procesar correcta-
> mente las `IANA Considerations' de aquellas RFC que las contengan, y
> manejar las situaciones en las que esta guía no exista. Deberían
> establecerse Similares formas de coordinación con otras organizacioness
> normalizadoras.
>
> La función no es suceptible de discrecionalidad significativa, y
> los sistemas de revisión intrínsecos de las organizaciones normaliza-
> doras parecen ser un modo de gobierno adecuado y suficiente.
>
> *Conclusión*: La IETF, y otras organizaciones normalizadoras según
> corresponda, asumirán la tarea dentro de su proceso normal de creación
> de estándares.
>
> 5. Supervisión de los servidores DNS raiz
> -----------------------------------------
>
> Esta función, y la que sigue, son de gran utilidad para quienes
> usan la Internet. Pero no son indispensables. Las analizaremos, sin
> embargo, porque surgen del hecho consumado de la arquitectura política
> actual de la Internet.
>
> El sistema de servidores root opera adecuadamente. Hoy en día, se
> coordinan entre sí mediante una federación informal de entidades de
> Estados Unidos, Europa y Japón; y es justo reconocer que hasta el
> momento han realizado su trabajo de manera excelente. La RFC2870
> establece un conjunto razonable de requerimientos operativos para los
> root servers de DNS; pero no es vinculante, ni está completa.
>
> Existe, pues, un vacío de supervisión. Ningún órgano ha fijadoo
> estándares para operación de los root servers; ni hay autoridad alguna
> que pueda requerir el cumplimiento de esos estándares en caso que
> existieran. Este vacío sugiere la necesidad de crear un órgano de
> supervisión, o asignar la función a una entidad existente.
>
> Propongo une órgano de supervisión (llamémosle provisionalmente
> `DNS Root Services Comptroller', DRSC) para llenar ese vacío. El DRSC
> establecería contratos con los operadores de los root servers, en los
> que se establecerían estándares, niveles de servicio, y otras obliga-
> ciones del operador respecto de seguridad, disponibilidad, etc. Estos
> contratos estarían basados en la RFC2870, y la extenderían.[13]
>
> Si bien hay una discrecionalidad bastante amplia para las
> acciones del DRSC, en particular para establecer los niveles de
> servicio que deberían alcanzar los operadores de los servidores raiz,
> las cuestiones son en gran medida técnicas. Por ello, un sistema de
> gobierno basado en el control `ex-ante' debería bastar.
>
> *Conclusion*: Debe crearse un órgano supervisor. Este órgano
> debe representar acabadamente el interés de la comunidad en el
> suministro estable de servicios de los root servers. De ello resulta
> obvio que los operadores de los root servers no pueden al mismo
> tiempo formar parte del DRSC. Este DSRC debe a su vez ser responsable
> ante los gobiernos y la comunidad de usuarios de la Internet.
>
> '
> 6. Gestión del `root zone file'
> ------------------------------
> La gestión de la zona raíz comprende un número de tareas dife-
> rentes. Muchas de ellas son puramente administrativas, consisten en
> ejecutar instrucciones recibidas de otros órganos conforme a un
> procedimiento predefinido. Otras, las menos pero las más visibles,
> implican resolver conflictos entre intereses de un modo equilibrado
> y en beneficio de la comunidad usuaria.
>
> Propongo la existencia de órganos de gobierno separados:
> - Uno que supervise la preparación y distribución del DNS root zone
> file (llamémosle Root Zone Administrator, RZA);
> - Otro (llamémosle ccTLD Policy Board, ccPB) que promulgue procedi-
> mientos adecuados (RFC1591?) que el RZA ejecutará respecto de los
> ccTLDs;
> - Otro (gTLD Policy Board, gPB), que establezaca procedimientos que
> el RZA ejecutará respecto de los gTLDs;
> - Otro (Registration Policy Board, RPB), que establezca las políticas
> generales de registro de nombres de dominio (Advertencia: las
> atribuciones de este cuerpo deben ser claramente limitadas. Véase
> d) más abajo)
>
> a) Mantenimiento y publicación del archivo de zona raiz
> .......................................................
> El `root zone file' es un archivo de texto relativamente pequeño
> que lista los nombres de cada uno de los TLDs así como las direcciones
> IP de los servidores de nombre para cada uno de ellos. El trabajo del
> RZA consistirá en el mantenimiento de este archivo, en función de las
> instrucciones que reciba de los Policy Boards.
>
> La tarea es sencilla, y no involucra el manejo de gran números
> de datos. Pero requiere extremo cuidado y diligencia para protegerse
> contra erores humanos, procedimentales o técnicos. Un pequeño error
> puede hacer que un país entero `desaparezca' de la Internet. Por lo
> tanto, la sensibilidad de este trabajo requiere adecuada protección
> contra manipulaciones, e inmunidad contra presiones políticas o
> económicas.
>
> El control que se requiere para esta tarea es asegurarse de que
> es ejecutada por personas competentes de acuerdo con procedimientos
> bien definidos. Estos procedimientos deberán ser publicados para que
> la comunidad pueda sugerir mejoras.
>
> La tarea ha sido efectuada hasta ahora por Verisign, Inc. Esta
> corporación, con otros numerosos intereses privados en la Internet,
> ha demostrado que es proclive a aprovecharla indebidamente en su
> propio beneficio. La asignación de la tarea es manejada mediante
> memorandos de entendimiento (MoU), acuerdos de cooperación o simple-
> mente órdenes de compra del Departamento de Comercio de los Estados
> Unidos, lo que provoca la legítima preocupación de que el sistema
> actual da al gobierno estadounidense una inmoderada cuota de poder.
>
> *Conclusión*: algún organismo internacional aceptable deberá
> establecer y financiar[14] el RZA. En la tarea no existe discreciona-
> lidad, por lo que un sistema de revisión `ex-post' bastará, y no se
> requerirá significativa presencia pública en el órgano de gobierno.
>
> b) Definir y aplicar reglas para establecer,
> remover o transferir ccTLDs
> ............................................
>
> El propuesto ccPB será responsable por crear políticas que
> determinen cuando deben crearse nuevos ccTLDs, cuándo deben removerse
> los viejos, y cómo debe realizarse la transferencia de control de
> ccTLDs. Instruirá al RZA acerca de cuáles son la entidades que contro-
> lan cada ccTLD.
>
> Este órgano requerirá un proceso de toma de decisiones relativa-
> mente complejo, en el que se prevea sufiente tiempo para discutir y
> considerar los puntos de vista de todos los sectores. La ccNSO de
> ICANN existente puede proporcionar un punto de arranque, pero será
> necesario asegurar la participación equilibrada de los operadores de
> ccTLDs, los representantes de los gobiernos nacionales[15], y la
> comunidad usuaria.
>
> *Conclusión*: debe establecerse un organismo específico de
> gestión de políticas de ccTLD.
>
> c) Definir y aplicar reglas para establecer,
> remover o transferir gTLDs
> ............................................
>
> ICANN ha tratado de llevar a cabo esta tarea. Después de casi
> seis años, es evidente que ha fallado miserablemente: no ha creado
> ninguna política coherente en esta área, salvo dos reglas extraordi-
> narias que reflejan dos elecciones no técnicas (y fuertemente
> `políticas'): 1) Favorecer la protección de la `propiedad intelectual'
> sobre el uso de nombres; y 2) proteger a los actuales operadores de
> gTLDs haciendo prácticamente imposible el ingreso de nuevos operadores
> al mercado.
>
> El gPB propuesto sería responsable por crear las políticas, e
> instruir al RZA sobre las modificaciones requiridas en la zona raiz.
>
> Permítanme recordar que, desde un punto de vista técnico, la
> root zone puede crecer enormemente. Podría albergar centenares de miles,
> si no millones, de TLDs. El impacto de este crecimiento no sería
> significativo en los servidores como tales, sino mas bien en los
> procedimientos humanos y los tiempos requeridos para transferir y
> cargar las actualizaciones. Es absolutamente falso que los TLDs sean
> un recurso tan escaso y valioso, como ICANN pretende, que requieran un
> seguimiento delicadísimo.
>
> En el régimen actual, las políticas relativas gTLDs no están
> basadas en ninguna consideración técnica, sino en posiciones
> económicas y políticas diseñadas para preservar el status quo de
> los pocos actores, y proteger intereses de un sector privado en
> desmedro de otros y de la comunidad. Debemos poner el mayor de los
> cuidados para lograr que las nuevas estructuras de gobierno sirvan
> al interés público, y no a los objetivos de unos pocos.
>
> *Conclusión*: Debe crearse una nueva entidad para esta tarea.
> ICANN, y la GNSO de la ICANN, deben ser eliminadas (no hay ocasión
> de `reciclarlas'). La nueva entidad debe ser guida por el interés
> de la comunidad usuaria.
>
> d) Definir reglas para el registro de nombres
> de dominio con los gTLDs
> .............................................
>
> En primer lugar, sostengo que el gobierno de Internet *no debe*
> incluir cuestiones cuyo lugar de pertenencia está en los cuerpos
> legislativos y judiciales establecidos. Por ello, todo lo relacionado
> con la creación de leyes supranacionales, como la UDRP o el sistema
> cuasijudicial que la acompaña, no pertenecen al ámbito de los óprganos
> de gobierno de Internet que aquí discutimos.
>
> El sistema de nombres de dominio (DNS) es un medio sencillo para
> que ciertos intereses ejerzan un fuerte control a nivel mundial, a un
> costo bajísimo. Es posible predecir, entonces, que el órgano de
> gobierno que proponemos (RPB) recibirá grandes presiones para incursio-
> nar en la gestión de políticas en terrenos mucho más allá de lo
> que por definición le correspondería.
>
> Por ello, recomiendo que los documentos orgánicos del RPB fijen
> limitaciones específicas. Es necesario costreñir sus poderes legisla-
> tivos, así como impedirle adoptar políticas respecto de prácticas de
> negocio, excepto las necesarias para asegurar que cualquier registro
> o `registrar' mantiene suficientes activos e información recuperable
> para que, en caso de quiebra, su sucesor pueda continuar el servicio
> a los clientes de la entidad quebrada.
>
> Las políticas que este órgano debería considerar incluyen las
> medidas para proteger a los registrantes en el caso de quiebra o
> disolución del registro o del `registrar' del que han obtenido su
> nombre de dominio, el grado de protección a la privacidad que debe
> ser otorgado a los datos de quienes registran nombres de dominio,
> períodos de gracia para recuperar nombres para aquellos que olvidaron
> renovarlos, transferencias de nombres, etc. Muchas de estas políticas
> han sido discutidas por la GNSO de la ICANN, y su predecesora DNSO,
> por lo cual sería posible construir el RPB `reciclando' partes del
> trabajo de la GNSO. Sin embargo, tal como señalábamos antes, la
> GNSO como organización carga con un pasado demasiado compromentido
> como para que pueda encargársele la tarea.
>
> *Conclusión*: Debe crearse un organismo de políticas de registro.
> Este podría aprovechar, previo análisis crítico, el resultado de los
> trabajos llevados a cabo por la GNSO. La comunidad usuaria debe tener
> una representación al menos paritaria en la mesa de decisiones del
> organismo.
>
> e) Definir las reglas para establecer, remover,
> transferir y mantener TLDs de infraestructura
> ................................................
>
> Existen TLDs de infraestructura. El más común es .arpa (habitual-
> mente en la forma in-addr.arpa para el mapeo de direcciones a nombres).
> El TLD de infraestructura .int también existe, y se ha usado con
> distintos propósitos.
>
> Es muy improbable que estas cuestiones se tornen contenciosas.
> Lo más sencillo e inteligente parecería ser sumar esta tarea a la
> previamente discutida de asignar y registrar números de protocolo.
>
> *Conclusión*: Si la IETF y otros organismos normalizadores lo
> admiten, es razonable subsumir esta tarea en la de asignación y
> registro de números de protocolo.
>
> Sección V
> A nivel nacional
> ------------------------
>
> Este documento se ocupa, en términos generales, de la gobernabi-
> lidad global de la Internet. En los niveles nacionales existen
> procesos y prácticas diferentes, con actores distintos. Hay modeloss
> de gestión gubernamentales, o liderados por el sector académico, o
> encabezados por el sector privado, o controlados por empresas que ni
> siquera están en el país.
>
> Sin embargo, creo que los lineamientos expresados en este
> documento son traducibles a los marcos de referencia nacionales, sin
> pérdida de generalidad. En versiones posteriores intentaré abordar
> con más detalle la cuestión, y profundizar en particular algunos
> casos.
>
>
> Copyright(C)2004 Enrique A. Chaparro/Fundación Vía Libre
>
> This work is licensed under the Creative Commons Attribution-
> NonCommercial-ShareAlike License. To view a copy of this license,
> visit http://creativecommons.org/licenses/by-nc-sa/1.0/ or send a
> letter to Creative Commons, 559 Nathan Abbott Way, Stanford,
> California 94305, USA.
>
> ---------
> Notas:
>
> [1] ``The Internet, a loosely-organized international collaboration of
> autonomous, interconnected networks, supports host-to-host
> communication through voluntary adherence to open protocols and
> procedures defined by Internet Standards.'' (RFC-2026).
>
> [2] en otros terminos, ``rough consensus and running code''
>
> [3] Esto, claro, incluye al gobierno de los Estados Unidos que
> de facto y de jure `gobierna' actualmente muchos de los aspectos
> `gobernables' de la Internet. No olvidemos que la ICANN no es mas
> que una _contratista_ del Department of Commerce.
>
> [4] Acepten mis disculpas por no haber encontrado un buen término
> en español que sintetice el significado de la palabra inglesa
> `stakeholder'. Si me permiten la broma, la importancia de los
> stakeholders en estos procesos suele ser directamente propocional al
> tamaño de la estaca.
>
> [5] No ofendere la inteligencia de los lectores con una larga
> argumentacion sobre el tema. Recordare simplemente que `anarquia'
> no significa `caos', y que los anarquistas no pretenden crear
> caos o desorden. Pretendemos crear una sociedad basada en la libertad
> individual y la cooperacion voluntaria; crear orden desde abajo hacia
> arriba, en lugar del desorden impuesto desde arriba hacia abajo por
> la autoridad.
>
> [6] Por ahora, me referire solo a direcciones unicast. Ya bastante
> baile tenemos con ellas ;)
>
> [7] RFC-0001 Host Software. S. Crocker. Apr-07-1969; hasta RFC-3728
> Definitions of Managed Objects for Very High Speed Digital Subscriber
> Lines (VDSL). B. Ray, R. Abbi. February 2004.
>
> [8] Para comprobar sencillamente esta afirmación, tome una muestra al
> azar de páginas web y sométalas al validador del W3C,
> http://validator.w3.org/
>
> [9] Una RFC puede convertirse en un Internet Standard (aunque la
> mayoría pertenecen al `non-standards tack'). En ese caso, conservará
> su número de RFC y agregará un número STD. Por ejemplo, la RFC 822
> es al mismo tiempo STD 0011.
>
> [10] http://www.w3.org/Consortium/Patent-Policy-20040205/
>
> [11] Con IPv6, es posible asignar una subred /48 (65536 direcciones)
> a cada mujer, hombre y niño del planeta... empleando solamente el
> 0.003 % del espacio de numeración disponible.
>
> [12] Este es un sistema multinivel, en cuya cúspide se encuentra
> la IANA, que realiza asignaciones muy grandes a los RIRs. Los RIRs,
> a su vez, asignan bloques a los grandes usuarios (ISPs, países,
> corporaciones). De ser necesario, se suceden otros niveles de
> asignación.
>
> [13] La operación de un root server implica costos significativos. La
> estabilidad de este componente crítico de la Internet no puede
> de donaciones voluntarias de tiempo, equipo, espacio, conectividad,
> dinero y recursos humanos.
>
> [14] En la situación actual, la tarea implica algunas pocas horas
> semanales. Aún cuando la tasa de incorporación de TLDs creciera
> enormemente (digamos, unos 100 nuevos TLDs por día), la tarea podría
> ser manejada con un esfuerzo menos a las 200 horas/persona semanales.
> Hay o es posible crear herramientas de software que realicen la mayor
> parte de la edición, verificación formal y control de contenidos.
>
> [15] Los ccTLDs están estrechamente ligados a la existencia de
> soberanías nacionales, y por lo tanto los gobiernos tienen legítimo
> interés en particpar la función de supervisión. Desde luego, aún
> queda por responder la pregunta ``¿Qué es un ccTLD? ¿Es un aspecto
> de la soberanía nacional? ¿O es un registro en una base de datos que
> por coincidencia refleja (con algunas inexactitudes) la existencia
> de países?
>
> =========================== End forwarded message
>
> _______________________________________________
> Lista Caucus Lac
> Lac at wsis-cs.org
> Página de Información: http://mailman.greennet.org.uk/mailman/listinfo/lac
--
---------------------------------------------------------
Valeria Betancourt
Coordinadora
Monitor de Políticas de TIC en América Latina y El Caribe
http://lac.derechos.apc.org
Tel: +593 (2) 2-234447 Fax: +593 (2) 2-559440
APC ~ La Asociación para el Progreso de las Comunicaciones
http://www.apc.org
More information about the Lac
mailing list