Seção I A ICANN e o ‘governo’ da Internet

A Internet não passa de “um sistema aberto que leva pacotes IP a partir de um endereço original de IP para o endereço de um destinatário” (ver também [1]). No entanto, também é um sistema social, político e econômico que provoca erosão nas soberanias nacionais. Mas os poderes que elas detinham não desaparecem, não se ‘dissolvem magicamente no ar’. Eles estão fluindo para mãos privadas: as corporações, as parcerias intercorporativas, organizações quase-não-governamentais (às vezes disfarçadas de multilaterais, como a WTO, a WIPO ou a WEF). Os órgãos de governo da Internet fazem parte dos fenômenos gerados por esse fluxo.

Não sou um fanático da ICANN, pelo contrário. Considero que, para servir ao interesse público (e não a interesses corporativos) será necessário primeiro destruí-la e reconstruí-la como um sistema coordenado (mas não fortemente acoplado) de organizações internacionais, multilaterais, democráticas e não-burocráticas [2].

Existe o mito de que a ICANN se ocupa apenas de ‘questões técnicas’, quando na verdade ela não faz praticamente nada que possa ser ligado, nem sequer de forma remota, a questões técnicas. A existência da ICANN dependeu da promoção dos planos de certos interesses comerciais seletos (particularmente dos Estados Unidos e da Europa), evitando se envolver em questões que levem em consideração (ou promovam) a estabilidade técnica da Internet. Costuma-se dizer que a ICANN ‘administra, coordena e atribui endereços IP’. Não é verdade. Costuma-se dizer que a ICANN ‘administra e coordena o sistema de servidores raiz’. Também não é verdade. Alguns afirmam que a tarefa de ‘promover a concorrência no espaço de domínios genéricos de nível superior (gTLD)’ é uma tarefa de coordenação técnica. Isto é uma brincadeira de mau gosto. E, por fim, a ICANN criou uma política global de resolução de conflitos sobre nomes de domínios que não possui nenhum componente técnico e é um ato regulatório supranacional baseado na coerção.

Entretanto, receio que haja males ainda piores que a ICANN:

o governo da Internet por parte dos governos [3]; o governo da Internet por parte de órgãos intergovernamentais (como a ITU, por exemplo).

No caso de adotar alguma dessas opções, aos males atuais deveríamos acrescentar a ineficiência e, em um número não trivial de casos, a censura. Como prova disso, remeto-me à história.

Poderia ser ainda pior. Poderia ser uma “public private partnership”, frase de efeito que entrou recentemente na moda. Na prática, essas PPP implicam a transferência de poderes estatais para mãos privadas sem lhes impor as condições de devido processo, supervisão pública e obrigação de prestar contas que caracterizam os governos democráticos.

Pouco importa se um órgão de governo é público, privado ou misto em qualquer forma. Seus papéis devem ser cuidadosamente definidos e limitados para evitar que, como no caso da ICANN, seja ‘capturado’ por aqueles aos quais supostamente deve supervisionar, ou por outros que considerem esse órgão útil para promover uma agenda em prol de um interesse setorial privado.

Governo é poder. E poder é poder em qualquer parte em que for usado, sofrido ou onde se resista a ele. Não devemos nos enganar e supor que a adição do complemento ‘da Internet’ de alguma forma reduz ou elimina os riscos e perigos desse poder. É indispensável que o poder para governar os aspectos ‘governáveis’ da Internet seja limitado, restrito e sujeito à indagação pública, do mesmo modo que, nos Estados democráticos de direito, são estabelecidos limites precisos a qualquer poder governamental.

O governo deve se estruturar de tal maneira que o poder seja dividido e não se concentre; e que permita a existência de tensões por oposição de interesses, o que garante que não será simples para nenhum ator apossar-se de uma parcela de poder maior que a que lhe corresponde.

As estruturas de governo da Internet devem estar sujeitas a supervisão e revisão; devem estar abertas a todos os que se sentirem afetados pelas questões que são objeto de governo. Devem se construir em função da comunidade universal de usuários da Internet. E, naturalmente, devem ser responsáveis ante essa comunidade sem que exista mais de um nível de representação entre os membros da comunidade e as pessoas a quem foram confiados os poderes de governo.

Se aprendemos algo com a ICANN foi que os conceitos ‘consenso’ e ‘stakeholder’ [4] são vagos demais, e propiciam situações em que os conflitos de poder são resolvidos por meio de seleção e manipulação, e não por uma argumentação razoável. Sejam quais forem as novas estruturas de governo a serem criadas (e tenho a esperança de que elas sejam mínimas), deverão usar mecanismos de votação e permitir a participação de todos os interessados nas questões tratadas, em vez de enquadrá-los neste ou naquele grupo de ‘stakeholders’.

Pretendo uma Internet anárquica [5]. Suas regulações devem ser as necessárias para distribuir racionalmente recursos escassos e para administrar uma infra-estrutura comum, nada além disso.

Seção II

Que deve ser ‘governado’?

Pois bem, que aspectos da Internet precisariam de alguma forma de ‘governo’? A meu ver, os seguintes:

1)Um sistema de normas técnicas (padrões) que constituem a ‘cola’ de inter-operabilidade de toda a rede; 2)Um sistema de alocação de endereços IP que opere de forma consistente através dos sistemas de roteamentos de pacotes IP [6]; 3)Um sistema de intercâmbio de tráfego entre ‘carriers’/ISPs, que ofereça aos usuários finais uma garantia razoável de que os fluxos de tráfego obterão os níveis de serviço especificados. 4)Um sistema de alocação de números de protocolo e outros identificadores.

Na situação atual, com um sistema de nomes de domínio altamente hierarquizado e dependente dos servidores raiz (root servers), dois outros aspectos também precisariam de ‘governo’:

5)A supervisão responsável e com obrigação de prestar contas publicamente do conjunto de servidores raiz do sistema de nomes de domínio (DNS); 6)A gestão do arquivo de zonas raiz (DNS root zone file), incluindo aí a tarefa de prepará-lo e distribui-lo aos servidores raiz, e o desenvolvimento e aplicação de políticas de incorporação de novos domínios de nível superior (TLDs) à zona raiz.

Sem dúvida, neste segmento existem TLDs cuja administração é questão soberana dos Estados (.mil, .gov no casos dos Estados Unidos e seus equivalentes em cada país) ou corresponde a organismos multilaterais (.int). Embora isso deva ser debatido tanto em nível global como nacional, seria admissível que certos TLDs sejam manejados pelo setor de interesse específico (edu, net e seus equivalentes locais).

Por que especifico ‘na situação atual’? Porque é tecnicamente possível ter um sistema de domínio federal e debilmente acoplado, em vez de um hierárquico. Também seria possível ‘federar’ a zona in-addr.arpa raiz. Na prática, construindo os acordos mínimos necessários para que não existam dois TLDs iguais com atribuições diferentes de nome, é tecnicamente possível (e não existe nenhuma norma que impeça isto) a coexistência de um grande número de TLDs (tanto gTLDs quanto ccTLDs). A existência da OpenNIC comprova minha afirmação: não precisamos de ICANN nem de qualquer substituto a ser inventado futuramente para administrar os TLDs. Esse mito, que a ICANN e seus partidários se encarregaram de difundir, deve ser enterrado.

Porém (e sempre existe um ‘porém’), “Architecture is politics”, como diz Mitch Kapor; por isso, na análise das seguintes seções vamos supor que essa arquitetura hierárquica vai continuar existindo, pelo menos durante um certo tempo.

Finalmente, outra atividade atualmente assumida pela ICANN está – sem dúvida – fora do ‘governável’:

7)O estabelecimento de uma política coercitiva para resolver disputas sobre os nomes de domínio.

Para isso existem mecanismos legais precisos nas legislações de cada país, e portanto não é necessário recorrer a este engendro compulsivo que afeta de forma muito negativa as normas do devido processo.

Seção III

Como ‘governar’?

Afirmo que a maneira mais adequada de governar os ‘aspectos governáveis’ da Internet é mediante órgãos diferentes, para que cada um deles se ocupe de um conjunto único de tarefas administrativas ou de definição de políticas. Além de contemplar melhor os interesses da comunidade usuária, provavelmente essa estrutura modular também provocaria uma redução substantiva de custos e esforços.

Dentro do possível, cada órgão de governo deve ser diferenciado e separado. Cada um deles deve ter sua própria estrutura jurídica. Não deve haver diretores, executivos, funcionários ou fontes de financiamento comuns entre eles. Toda comunicação entre órgãos de governo deve ser escrita e colocada à disposição do público na Internet, junto com sua comunicação ao destinatário.

Como poderão ver na enumeração abaixo, o conjunto de atividades necessárias para gerir de forma eficiente os aspectos antes mencionados implicam diferentes graus de discricionariedade. Em função desses graus é possível imaginar três sistemas para a tomada de decisões:

Nos casos em que o grau de discricionariedade é muito limitado, ou quando as conseqüências do abuso dessa discricionariedade são restritas (ou facilmente reversíveis), haveria um sistema de revisão pública ‘ex-post’. As ações seriam divulgadas depois de serem tomadas, e durante um certo período após sua publicação todos os afetados poderiam impugná-las. Nos casos em que o grau de discricionariedade fosse maior (embora limitado, em qualquer circunstância), haveria um sistema de controle público ‘ex-ante’. A decisão proposta se torna pública, abre-se um período de comentários, estes são considerados e finalmente se publica a decisão baseada nesses comentários. Esse sistema deve contar com mecanismos de supervisão externa e revisão que permitam lidar com as situações extraordinárias de arbitrariedade ou violação dos procedimentos estabelecidos. Finalmente, nos casos em que a discricionariedade for ampla ou houver um impacto público significativo, será preciso desenhar sistemas de governo mais complexos. Por exemplo, a criação de políticas relativas ao sistema de nomes de domínio exige que todas as partes potencialmente afetadas tenham direito de participar do debate e da decisão em pé de igualdade com todas as outras partes.

Nos dois primeiros sistemas o ônus da prova de demonstrar que as apresentações ou os comentários foram devidamente revisados e considerados também deverá caber ao tomador de decisão.

Seção IV

Atividades que requerem governo

1.Padrões

Os padrões tornam a Internet possível. Nenhum outro componente é tão crucial, pois eles mantêm acoplada toda a estrutura que possibilita a própria existência da rede de redes. Durante mais de 30 anos [7], o IAB, a IETF e o IESG realizaram um trabalho extraordinário. O processo de geração de padrões (RFC-2026, BCP-9) é aberto a toda a comunidade, com diversas instâncias de revisão.

Outros órgãos normativos, como o W3C (World Wide Web Consortium) também realizaram um excelente trabalho, com um modelo de processo muito parecido com o da IETF/IESG, para estabelecer padrões que possibilitassem a existência de aplicativos de uso maciço e inter-operáveis. A diferencia essencial é óbvia: a existência da Web é possível sem que todos os atores respeitem escrupulosamente todas as normas do W3C [8], embora isto provoque a discriminação de alguns usuários; no entanto, a existência da Internet não é possível sem os STD [9] da IETF. * Conclusão * : Aqui não parece necessário fazer nada, exceto respeitar o velho axioma: “if it isn’t broken, don’t fix it”. No entanto, devido à crescente ameaça representada pelas patentes de software, seria preciso pressionar em prol da revisão do processo de criação de padrões para incluir uma política relacionada às patentes de software similar à adotada pelo W3C [10].

2.Alocação de endereços IP

Antes de entrar em maiores detalhes, uma advertência: a relativa escassez de endereços IP é um fenômeno circunstancial. O desenvolvimento da infra-estrutura Ipv6 resolve o problema [11], pelo menos durante muito tempo. Mas é preciso ressaltar que subsistem alguns inconvenientes para a implantação de Ipv6 a escala; alguns deles são técnicos, mas uma grande parte tem a ver com o interesse corporativo, do mesmo tipo que os que impedem o estabelecimento de novos gTLDs (questão que será tratada mais para a frente). Enquanto houver essa escassez será possível identificar dentro desta função três atividades centrais:

a)Formulação de políticas para a alocação de endereços

As decisões tomadas neste âmbito não provocam apenas um impacto técnico, mas também – e de uma maneira muito mais significativa – um impacto social e econômico. Os países ou instituições que podem obter alocações têm uma vantagem competitiva com relação aos que não as podem obter. Muitas decisões sobre alocação adotadas atualmente baseiam-se em supostos implícitos sobre seu impacto, e isto só pode ser medido em termos de seus efeitos nos ISP e nos provedores de equipamento, em vez de levar em consideração a comunidade de usuários da Internet em geral.

É bastante improvável que a questão da alocação de endereços IP possa permanecer isolada de um debate mais geral. Ao mesmo tempo, futuramente a criação de políticas de alocação de endereços IP exigirá uma maior supervisão (e escrutínio público) que a exigida hoje em dia.

Embora, como já foi frisado, a criação de políticas de alocação provoca muitos efeitos sociais e econômicos, é provável que muito poucas pessoas e instituições, com exceção dos ISPs, dos grandes consumidores de espaço de endereços ou dos fabricantes de routers desejem assumir os tempos e os esforços envolvidos em uma participação ativa nesse campo. Portanto, o atual esquema de estabelecimento de políticas que usam os RIRs (registros regionais de endereços IP: APNIC, ARIN, RIPE, LACNIC) poderia se manter sem grandes variantes até aparecerem as dificuldades.

Apesar disso, será necessário: Estabelecer um processo de revisão periódica realizado por um órgão de controle sujeito a escrutínio público, para determinar se as mencionadas dificuldades surgiram e, em função do caso, se é preciso estabelecer um sistema de governo mais complexo; Estabelecer um sistema de controle público ‘ex-ante’ sobre as políticas de alocação; Democratizar a estrutura dos RIRs para garantir a participação com voz e voto, em pé de igualdade, da comunidade de usuários de Internet da correspondente região.

* Conclusão* : Deixemos esta função nas mãos dos RIRs, mas revisemos periodicamente a situação (com uma periodicidade não superior aos dois anos). Ao mesmo tempo, devemos tornar transparente a formulação de políticas e democratizar os RIRs.

b)Alocação de grandes blocos de endereços Ipv4 ou Ipv6

Este é o processo mecânico em colocar em prática as políticas de alocação de endereços [12]. Dependendo da precisão das políticas de alocação, a tarefa de administrar essas políticas pode ser previsível, com um grau muito reduzido de discricionariedade administrativa. Levando em conta o impacto das decisões sobre alocação, seria razoável aplicar um sistema de controle ‘ex-ante’, mas como geralmente o tempo é um fator importante no processo de alocação, talvez seja suficiente contar com um sistema de revisão ‘ex-post’.

* Conclusão* : Com as exceções do item a) anterior, esta função pode ser exercida pelos RIRs.

c)Manutenção da zona in-addr-arpa

Em cada etapa da hierarquia de alocação de endereços IP é preciso construir as entradas apropriadas na hierarquia de DNS in-addr.arpa. Geralmente esta tarefa é realizada pela pessoa ou entidade encarregada da delegação de endereços. Nos níveis superiores é executada pelos RIRs, e nos inferiores pelas instituições ou pessoas às quais foram delegados blocos de endereços.

Em sua essência, esta é uma tarefa sem discricionariedade. Para as alocações pelos RIRs seria apropriado utilizar um sistema de controle ‘ex-post’; nos níveis inferiores não deveria ser imposto nenhum sistema de governo.

* Conclusão* : Com as exceções do item a) anterior, esta função pode ser exercida pelos RIRs.

3.Roteamento e níveis de serviço Nesta área, pouco ou nada foi discutido. No entanto, é de se esperar que os ISPs e os ‘carriers’ se oponham a qualquer tentativa de impor algum governo sobre as questões de roteamento de pacotes, filtragem e reconhecimento entre os ‘carriers’ das obrigações de nível de serviço de uma extremidade à outra.

É essencial discutir de forma aberta e democrática estas questões e oferecer à comunidade usuária ferramentas potentes para assegurar qualidade de serviço. Ao mesmo tempo, será preciso considerar o equilíbrio de numerosas questões técnicas, econômicas e sociais, levando em conta que esses equilíbrios podem determinar completamente o destino de segmentos ou serviços completos, como a voz sobre o IP. Por isso é provável que seja preciso contar com uma estrutura de governo complexa, que reúna os aspectos positivos:

das estruturas que supervisionam a conectividade e a qualidade de extremo a extremo nas redes telefônicas; dos mecanismos de regulação/supervisão impostos às empresas prestadoras de serviços públicos.

Não tenho opinião formada sobre a forma de estruturar esse órgão de governo, mas estou plenamente convencido de que nada será conseguido se não se der um lugar preponderante à comunidade usuária como ator na tomada de decisões.

4.Alocação de números de protocolo e outros identificadores

Para os padrões da IETF, a execução desta tarefa exige um grau de coordenação suficiente com a IETF para processar corretamente as ‘IANA Considerations’ das RFC que as tiverem, e lidar com as situações em que esse guia não existir. Formas semelhantes de coordenação deveriam ser estabelecidas com outras organizações normativas.

A função não pode dar origem a uma significativa discricionariedade, e os sistemas de revisão intrínsecos das organizações normativas parecem ser um modo de governo adequado e suficiente.

* Conclusão * : A IETF e suas correspondentes organizações normativas assumirão a tarefa dentro de seu processo normal de criação de padrões.

5.Supervisão dos servidores DNS raiz

Esta função, assim como a seguinte, são muito úteis para os usuários da Internet, porém não são indispensáveis. No entanto, nós as analisaremos porque surgem do fato consumado da arquitetura política atual da Internet.

O sistema de servidores root opera de forma adequada. Hoje em dia eles estão coordenados entre si mediante uma federação informal de entidades dos Estados Unidos, Europa e Japão; e devemos reconhecer que, até o momento, realizaram seu trabalho de forma excelente. A RFC2870 estabelece um conjunto razoável de requerimentos operacionais para os root servers de DNS, porém eles não são vinculantes nem completos.

Existe, portanto, um vácuo na supervisão. Nenhum órgão estipulou padrões para a operação dos root servers; não há nenhuma autoridade que possa exigir o cumprimento desses padrões caso eles existissem. Este vácuo sugere a necessidade de criar um órgão de supervisão, ou atribuir essa tarefa a uma entidade já existente.

Proponho um órgão de supervisão (vamos chamá-lo provisoriamente de ‘DNS Root Services Comptroller’, DRSC) para preencher esse vácuo. O DRSC estabeleceria contratos com os operadores dos root servers, nos quais seriam estipulados padrões, níveis de serviço e outras obrigações do operador com relação a segurança, disponibilidade etc. Estes contratos estariam baseados na RFC2870 e a ampliariam [13].

Embora haja uma discricionariedade bastante ampla para as ações do DRSC, especialmente para estabelecer os níveis de serviço a serem alcançados pelos operadores dos servidores raiz, em grande parte os problemas são técnicos. Por isso consideramos que seria suficiente um sistema de governo baseado no controle ‘ex-ante’.

* Conclusão *: Deve-se criar um órgão supervisor. Este órgão deve representar plenamente o interesse da comunidade no fornecimento estável de serviços dos root servers. É óbvio, portanto, que os operadores dos root servers não podem ao mesmo tempo fazer parte do DRSC. Esse DRSC deve ser responsável perante os governos e a comunidade de usuários da Internet.

6.Gestão do ‘root zone file’

A gestão da zona raiz abrange um grande número de tarefas diferentes. Muitas delas são meramente administrativas, pois consistem em executar instruções recebidas de outros órgãos, de acordo com um procedimento pré-definido. Outras, em menor número, porém mais visíveis, implicam a resolução de conflitos de interesses entre os usuários de forma equilibrada e em beneficio de toda a comunidade usuária.

Proponho a criação de órgãos de governos separados:

Um deles deve supervisionar a preparação e distribuição do DNS root zone file (vamos chamá-lo de Root Zone Administrator, RZA); Outro (vamos denominá-lo ccTLD Policy Board, ccPB) deve promulgar os procedimentos adequados (RFC1591) que o RZA deve executar com relação aos ccTLDs; Outro (gTLD Policy Board, gPB) deve estabelecer os procedimentos que o RZA deve executar com relação aos gTLDs; Outro (Registration Policy Board, RPB) deve estabelecer as políticas gerais de registro de nomes de domínio (Advertência: as atribuições desse corpo devem ser claramente limitadas. Ver d) abaixo).

a)Manutenção e publicação do arquivo da zona raiz

O ‘root zone file’ é um arquivo de texto relativamente pequeno que lista os nomes de cada TLD, bem como os endereços IP dos servidores de nome para cada um deles. O trabalho do RZA consistirá em manter esse arquivo, em função das instruções que receber dos Policy Boards.

A tarefa é simples e não envolve a gestão de um grande número de dados, mas requer um extremo cuidado e diligência para se proteger contra erros humanos, procedimentais ou técnicos. Um pequeno erro pode fazer com que um país inteiro ‘desapareça’ da Internet. Portanto, a sensibilidade deste trabalho requer uma adequada proteção contra manipulações, assim como imunidade contra pressões políticas ou econômicas.

Para desempenhar essa tarefa é preciso garantir que ela seja executada por pessoas competentes, de acordo com procedimentos bem definidos. Esses procedimentos deverão ser publicados para que a comunidade possa sugerir melhoras.

Até agora a tarefa tem sido realizada pela Verisign, Inc. Essa corporação, que possui diversos outros interesses privados na Internet, tem demonstrado uma tendência a aproveitá-la de forma indevida em seu próprio beneficio. Lida-se com a alocação da tarefa mediante memorandos de entendimento (MoU), acordos de cooperação ou simplesmente ordens de compra do Departamento de Comércio dos Estados Unidos, o que suscita a legítima preocupação de que o sistema atual dá ao governo desse país uma ilimitada parcela de poder.

* Conclusão *: algum organismo internacional aceitável deverá estabelecer e financiar [14] o RZA. Nessa tarefa não existe discricionariedade, e portanto será suficiente um sistema de revisão ‘ex-port’, e não será preciso que haja uma significativa presença púbica no órgão de governo.

b)Definir e aplicar regras para estabelecer, remover ou transferir ccTLDs O ccPB proposto será responsável pela criação de políticas que determinem quando devem ser criados novos ccTLDs, quando os velhos devem ser removidos e como deve ser realizada a transferência de controle dos ccTLDs. Também instruirá a RZA sobre quais são as entidades que controlam cada ccTLD.

Este órgão exigirá um processo de tomada de decisões relativamente complexo, que deverá ter tempo suficiente para discutir e considerar os pontos de vista de todos os setores. A ccNSO de ICANN existente pode representar um ponto de partida, mas será preciso garantir a participação equilibrada dos operadores de ccTLDs, dos representantes dos governos nacionais [15] e da comunidade usuária.

* Conclusão *: deve ser criado um organismo específico de gestão de políticas de ccTLD.

c)A definição e aplicação de regras para estabelecer, remover ou transferir gTLDs

O ICANN tem tentado realizar essa tarefa. Depois de quase seis anos é evidente que falhou totalmente: não criou nenhuma política coerente nessa área, exceto suas regras extraordinárias que refletem duas escolhas não técnicas (e fortemente ‘políticas’): 1) favorecer a proteção da ‘propriedade intelectual’ sobre o uso de nomes; 2) proteger os atuais operadores de gTLDs tornando praticamente impossível a entrada no mercado de novos operadores.

O gPB proposto seria responsável por criar as políticas e instruir o RZA sobre as modificações necessárias na zona raiz.

Permitam-me lembrar que, de um ponto de vista técnico, a root zone pode crescer enormemente. Poderia conter centenas de milhares – ou milhões – de TLDs. O impacto desse crescimento não seria significativo nos servidores como tais, mas nos procedimentos humanos e nos tempos necessários para transferir e carregar as atualizações. É totalmente falso que os TLDs sejam um recurso tão escasso e valioso, como a ICANN pretende que sejam, e que exijam um acompanhamento muito delicado.

No atual regime, as políticas relativas a gTLDs não se baseiam em nenhuma consideração técnica, mas em posições econômicas e políticas projetadas para preservar o status quo dos poucos atores, assim como para proteger interesses de um setor privado contra os interesses de outros e da comunidade. Devemos ter muito cuidado para que as novas estruturas de governo sirvam ao interesse público e não aos objetivos de poucos.

* Conclusão *: Deve ser criada uma nova entidade para essa tarefa. A ICANN e a GNSO da ICANN devem ser eliminadas (não é possível ‘reciclá-las’). A nova entidade deve ser guiada pelo interesse da comunidade usuária.

d)A definição de regras para o registro de nomes de domínio com os gTLDs

Em primeiro lugar, considero que o governo da Internet * não deve * incluir questões que pertencem aos corpos legislativos e judiciais estabelecidos. Por isso, tudo o que se relaciona à criação de leis supranacionais, como a UDRP ou o sistema quase judicial que a acompanha, não pertencem ao âmbito dos órgãos de governo da Internet que discutimos aqui.

O sistema de nomes de domínio (DNS) é um meio simples para que certos interesses exerçam um forte controle em nível mundial, a um custo baixíssimo. Portanto, é possível prever que o órgão de governo que propomos (RPB) sofrerá grandes pressões para se dedicar à gestão de políticas que não lhe correspondem.

Por isso recomendo que os documentos orgânicos da RPB estipulem limitações específicas. É preciso limitar seus poderes legislativos, bem como impedir que adotem políticas relacionadas às práticas de negócio, exceto as necessárias para garantir que qualquer registro ou ‘registrar’ mantém suficientes ativos e informação recuperável para que, em caso de falência, seu sucessor possa continuar a servir aos clientes da entidade falida.

As políticas que esse órgão deveria considerar incluem as medidas para proteger os registrantes em caso de falência ou dissolução do registro ou do ‘registrar’ através do qual obtiveram seu nome de domínio, o grau de proteção à privacidade que deve ser concedido aos dados dos que registram nomes de domínio, períodos de carência para recuperar nomes dos que se esqueceram de renová-los, transferências de nomes etc. Muitas dessas políticas foram discutidas pela GNSO da ICANN, e por sua antecessora, a DNSO, e por isso seria possível construir o RPB ‘reciclando’ partes do trabalho da GNSO. Entretanto, como já frisamos, a GNSO como organização tem um passado altamente comprometido, e por isso dificilmente poderia se encarregar dessa tarefa.

* Conclusão *: Deve ser criado um órgão de políticas de registro. Após uma análise crítica, este poderia aproveitar o resultado dos trabalhos realizados pela GNSO. A comunidade usuária deve ter uma representação pelo menos paritária na mesa de decisões desse órgão.

e)A definição de regras para estabelecer, remover, transferir e manter TLDs de infra-estrutura

Existem TLDs de infra-estrutura. O mais comum é .arpa (habitualmente na forma in-addr.arpa para o mapeamento de endereços a nomes). Também existe o TLD de infra-estrutura .int, utilizado com diferentes propósitos.

É muito improvável que essas questões se tornem contenciosas. O mais simples e inteligente pareceria ser acrescentar essa tarefa à previamente discutida de alocar e registrar números de protocolo.

* Conclusão *: Se a IETF e outros organismos normativos admitirem esse ponto, seria razoável incluir essa tarefa na de alocação e registro de números de protocolo.

Seção V

Em nível nacional

Este documento se ocupa, em linhas gerais, da governabilidade global da Internet. Nos níveis nacionais existem processos e práticas diferentes, com distintos atores. Existem modelos de gestão governamentais liderados pelo setor acadêmico, ou pelo setor privado, ou controlados por empresas que nem sequer estão no país.

No entanto, considero que as propostas deste documento podem ser traduzidas para os contextos de referência nacional, sem perda de generalidade. Em versões posteriores tentarei abordar de forma mais detalhada essa questão, aprofundando alguns casos particulares.

Copyright©2004. Enrique A. Chaparro/Fundación Vía Libre

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] Em outros termos, ``rough consensus and running code''

[3] É claro que isto inclui o governo dos Estados Unidos que, de facto e de jure, atualmente ‘governa’ muitos dos aspectos ‘governáveis’ da Internet. Não devemos esquecer que a ICANN não passa de uma ‘empreiteira’ do Department of Commerce.

[4] Queiram aceitar minhas desculpas por não ter encontrado um termo que possa sintetizar o significado da palavra inglesa ‘stakeholder’. Se me permitirem uma brincadeira, a importância dos stakeholders nesse processo costuma ser diretamente proporcional ao tamanho da estaca.

[5] Não ofenderei a inteligência dos leitores com uma longa argumentação sobre o tema. Apenas lembrarei que ‘anarquia’ não significa ‘caos’, e que os anarquistas não pretendem criar caos nem desordem. Pretendemos criar uma sociedade baseada na liberdade individual e na cooperação voluntária; criar ordem de baixo para cima, em vez da desordem imposta de cima para baixo pela autoridade.

[6] Por enquanto vou me referir apenas a endereços unicast, que já nos dão suficiente trabalho...

[7] RFC-0001 Host Software. S. Crocker. Apr-07-1969; até RFC-3728 Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL). B. Ray, R. Abbi. February 2004.

[8] Para comprovar esta afirmação de uma forma bem simples, tome qualquer página web por acaso e submeta-a ao validador do W3C, http://validator.w3.org/

[9] Uma RFC pode se transformar em um Internet Standard (embora a maioria pertença ao ‘non-standards tack’). Nesse caso, conservará seu número de RFC e acrescentará um número STD. Por exemplo, a RFC 822 é ao mesmo tempo a STD 0011.

[10] http://www.w3.org/Consortium/Patent-Policy-20040205/

[11] Com Ipv6 é possível alocar uma subrede/48 (65536 endereços) a cada mulher, homem e criança do planeta... utilizando apenas 0,003% do espaço de numeração disponível.

[12] Este é um sistema multinível, em cuja cúspide está a IANA, que realiza alocações muito grandes para os RIRs. Os RIRs, por sua vez, alocam blocos aos grandes usuários (ISPs, países, corporações). Em caso de necessidade, sucedem-se outros níveis de alocação.

[13] A operação de um root server implica custos significativos. A estabilidade desse componente crítico da Internet não pode depender de doações voluntárias de tempo, equipamento, espaço, conectividade, dinheiro e recursos humanos.

[14] Na situação atual, a tarefa envolve poucas horas semanais. Mesmo que o índice de incorporação dos TLDs crescesse enormemente (digamos, cerca de 100 novos TLDs por dia), a tarefa poderia ser realizada com um esforço menor que 200 horas/pessoa semanais. Existem ou é possível criar ferramentas de software que realizem a maior parte da edição, verificação formal e controle de conteúdos.

[15] Os ccTLDs estão intimamente ligados à existência de soberanias nacionais, e portanto os governos têm legítimo interesse em participar da função de supervisão. Naturalmente, ainda não foi respondida a seguinte pergunta: ‘Que é um ccTLD? É um aspecto da soberania nacional? Ou é um registro numa base de dados que, por coincidência, reflete (com algumas inexatidões) a existência de países? ------------------------------------------------------------ Original em Castellano