[Lac] Documento de posición [2]
Enrique A.Chaparro
echaparro at uolsinectis.com.ar
Thu Feb 26 13:52:46 GMT 2004
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://mailman-new.greennet.org.uk/pipermail/lac/attachments/20040226/bc97d410/attachment.pgp
More information about the Lac
mailing list