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 corporaaciones, 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 vincularse 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 situaciones 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 suficientemente 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 contemplarí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 participació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 `exante'; 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, escprobable 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 correctamente 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?