|
Informativo sobre contratos de ccTLDs Um dos tópicos da pauta do Fórum Público da ICANN em Montevidéu em 9 de setembro de 2001 é um informativo sobre os contratos de domínios de alto nível com código por país (ccTLDs). Vários fóruns discutiram contratos de ccTLDs, incluindo modelos, conceitos, etc., e produziram vários documentos muito úteis. O informativo oferece uma boa oportunidade para começar a consolidar algumas das idéias desenvolvidas ao longo dos últimos anos com o objetivo de formalizar contratos (independentemente de sua forma) entre ICANN e ccTLDs. Para auxiliar nessa consolidação, esta página reflete:
Em relação ao último ponto, prevê-se que em sua reunião de 10 de setembro de 2001 ICANN deverá analisar a formalização de um Contrato de Patrocínio de ccTLD entre ICANN e .au Domain Administration Limited (auDA), que foi analisado e apoiado pelo governo da Austrália e que representa o ponto decisivo de um longo processo entre a comunidade da Internet na Austrália para criar uma entidade confiável do setor privado para administrar o ccTLD .au. A. Histórico do desenvolvimento de políticas de delegação e administração de ccTLDs Como dado histórico, o sistema de nomes de domínio (DNS) foi implementado em meados da década de 80 e agora consiste de aproximadamente 250 "domínios de alto nível" ou "TLDs" (a seqüência, como .com, à direita do último período em um nome de domínio). No momento, estes TLDs consistem de duas ou mais letras. TLDs de duas letras são chamados de "domínios de alto nível por código de país" ou "ccTLDs," porque estes códigos correspondem às abreviações de duas letras para países (como .dk para Dinamarca) ou territórios externos (como .gl para Groelândia), relacionadas na lista ISO 3166-1, mantida por um departamento da Organização Internacional de Padronização (ISO). Os ccTLDs foram criados pela Internet Assigned Numbers Authority (IANA - Autoridade da Internet para Atribuição de Números)1 com o objetivo de facilitar e promover a disseminação da Internet em todo o mundo. Eles são delegados a gerentes designados, que operam os ccTLDs segundo políticas locais, adaptadas para melhor atender às circunstâncias econômicas, culturais e lingüísticas do país ou território envolvido. A lista ISO 3166-1 tem sido usada como a fonte oficial dos códigos de duas letras para países porque, como declara a RFC 1591, "não é responsabilidade de IANA decidir o que é e o que não é um país". Logo depois da criação do DNS em 1985, IANA começou
a delegar a responsabilidade pelo gerenciamento de ccTLDs, em geral a
pioneiros voluntários da Internet nos respectivos países ou territórios,
seguindo normas para a administração e delegação de TLDs em geral, e ccTLDs
em particular. Essas políticas incluíam requisitos técnicos fundamentais e
detalhavam as circunstâncias para que IANA efetuasse ou alterasse uma
delegação. Desde o princípio, as políticas para administração de ccTLDs
partiram da premissa de que cada ccTLD deveria ser operado a serviço da
comunidade local da Internet para a qual fora criado, dentro da estrutura das
necessidades de uma rede global.2
Como a Internet se espalhou para todos os recantos do mundo, tornando-se um meio de comunicação essencial para centenas de milhões de usuários, e passou a abrigar vários níveis de uso comercial, as políticas de IANA também evoluíram. Em março de 1994, o Dr. Jon Postel de IANA publicou a RFC 1591, que faz uma descrição geral da "Estrutura e Delegação do Sistema de Nomes de Domínio", incluindo ccTLDs e gTLDs. Depois da publicação dessa RFC, IANA ajustou suas políticas periodicamente, tendo também publicado memorandos (como a série ccTLD's News) que documentavam as novas políticas, partindo do princípio básico de idoneidade para com a comunidade local e global da Internet. No segundo semestre de 1998, ICANN foi formada pela comunidade global da Internet como uma corporação sem fins lucrativos do setor privado, para assumir a responsabilidade pela coordenação técnica do DNS da Internet, incluindo as funções de IANA, na época desempenhadas pela Universidade do Sul da Califórnia de acordo com um contrato com o governo dos EUA. Em novembro de 1998, ICANN firmou um Protocolo de Intenções com o Departamento de Comércio dos EUA, segundo o qual essas responsabilidades de coordenação seriam transferidas gradualmente para o setor privado, sob os auspícios da ICANN. Em dezembro de 1998, ICANN firmou um acordo de transição com ISI, segundo o qual assumiria a responsabilidade pela operação de IANA, sujeita à aprovação do governo dos EUA. Em fevereiro de 2000, ICANN assinou um contrato com o governo americano para a operação de IANA por ICANN. Entre outras coisas, esse contrato aprovou a transição de ISI. Entretanto, antes disso, em maio de 1999, ICANN e IANA editaram em conjunto um documento intitulado "Estrutura e Delegação do Sistema de Nomes de Domínio na Internet", mais conhecido como "ICP-1." Esse documento contém uma especificação das políticas seguidas na época por IANA em relação a ccTLDs. Essas políticas continuam válidas até hoje, de modo que ICP-1 é a melhor referência para as atuais políticas e um ponto de partida para a análise de mudanças nas políticas para ccTLDs. No cumprimento de sua função de selecionar e, quando necessário, substituir,3 os gerentes apropriados para ccTLDs, IANA se baseou na comunidade local da Internet de cada país para atingir um consenso sobre como o ccTLD deveria ser operado. Na questão de delegação e redelegação de um ccTLD, IANA espera a cooperação de pessoas envolvidas ou afetadas pela transferência, especialmente aquelas que moram no país ou território para o qual o ccTLD foi criado. Conforme explica RFC 1591: As partes interessadas no domínio deve concordar que o gerente designado é a parte apropriada. IANA procura fazer com que todas as partes em contenda cheguem a um acordo entre si, e em geral não toma nenhuma providência para interferir, a menos que todas as partes em contenda concordem com a interferência; IANA apenas interferirá se o gerente designado de fato proceder mal. Contudo, também é aconselhável que as partes interessadas tenham alguma participação na escolha do gerente designado. Conforme observou o Dr. Postel no Memo # 1 de ccTLD's News, e se reitera em ICP-1, os pontos de vista do governo ou autoridade pública do país ou território afetado são levados muito a sério neste aspecto. As opiniões governamentais são particularmente pertinentes quando o governo está cumprindo sua função de promover o gerenciamento de um ccTLD no interesse do público.4 Mesmo confiando que a comunidade local da
Internet adotará normas baseadas em consenso para a administração de ccTLDs,
IANA concluiu que a responsabilidade geral de garantir que os interesses da
comunidade local da Internet sejam atendidos é uma função difícil. Os casos
nos quais não se chega a um consenso representam um grande desafio para
investigar e determinar a melhor maneira de atender os interesses da Internet
local. Esses desafios fizeram com que muitas vezes o processo de investigação
de pedidos de redegação se prolongasse.5 B. A necessidade de instituir arranjos mais formais Embora os princípios fundamentais das políticas para delegação e administração de ccTLDs continuem sendo aplicados bem, a forma informal de sua documentação não é adequada à estrutura cada vez mais formal dentro da qual os ccTLDs e IANA devem operar. Como a Internet e os ccTLDs cresceram no tamanho (um ccTLD agora tem mais de quatro milhões de registros) e na importância para a economia global, a necessidade de compromissos claramente definidos tornou-se evidente. Agora, mais de 15 anos depois da criação do DNS, aparentemente uma opinião amplamente disseminada entre a comunidade da Internet é que as relações descritas nos documentos históricos de IANA (RFCs, ICPs, novos memorandos e relatórios) deveriam ser formalizadas para que se tornem mais transparentes, mais previsíveis e mais confiáveis perante a comunidade da Internet, preservando ao mesmo tempo a abordagem privada, da base para o topo. Esta idéia corresponde às exigências daà comunidade para que se conclua a transferência da coordenação técnica da Internet para o setor privado, através da ICANN. Uma das exigências para concluir a transferência, conforme o Protocolo de Intenções com o governo dos EUA, é que ICANN estabeleça relacionamentos apropriados com as outras entidades envolvidas na operação da Internet para cumprir sua responsabilidade de gerenciamento técnico, de forma a garantir que a Internet continue operando de maneira estável. Essas entidades incluem os gerentes dos ccTLDs, bem como os governos dos países ou territórios afetados que estão preparados para contribuir com o esforço de coordenação geral. Mais especificamente, segundo uma atualização do Protocolo de Intenções de setembro de 2000, o final da transferência da coordenação para o setor privado exige a formalização de "acordos estáveis com as organizações que operam domínios de alto nível por código de país", incluindo tópicos como redelegação, atribuição das responsabilidades normativas, e relacionamentos com os governos ou autoridades públicas em questão. Em reuniões passadas, o Conselho Administrativo destacou a necessidade de prosseguir com acordos com gerentes de ccTLDs. Durante a reunião no Cairo (março de 2000), o Conselho Administrativo ouviu várias apresentações e promoveu uma exaustiva discussão sobre políticas de administração e delegação de ccTLDs. Nessa reunião o Conselho resolveu que o Presidente e a equipe estão autorizados a trabalhar com os gerentes de ccTLDs, o Comitê Consultivo para Assuntos Governamentais e outras partes interessadas para preparar o esboço de contratos, especificações de políticas e/ou comunicados, incluindo as disposições apropriadas para financiamento, devendo apresentá-lo ao Conselho Administrativo e publicá-lo para comentário público o mais rapidamente possível. Durante a reunião em Melbourne (março de 2001), o Conselho Administrativo da ICANN discutiu os tópicos relativos a ccTLDs, e na resolução 01.37 determinou que a administração da ICANN está orientada a prosseguir com vigor renovado, com o objetivo de concluir os esboços de acordos de legado e, conforme necessário, procurar firmar acordos de ccTLDs em situações triangulares. Pessoas interessadas dentro da comunidade da ICANN aceitaram esses desafios e trabalharam arduamente para elaborar propostas para formalizar e, em alguns casos ajustar, as atuais políticas para administração e delegação de ccTLDs. Praticamente todas as propostas se baseiam na criação de uma estrutura de acordos ou outros instrumentos escritos que especifiquem claramente os compromissos das partes envolvidas na administração de ccTLDs. Durante quase 2 anos, ICANN e gerentes de ccTLDs têm participado de amplas discussões sobre a forma e o conteúdo apropriados dos relacionamentos entre ICANN, o gerente de ccTLD e o governo ou autoridade pública em questão. Igualmente houve numerosas discussões entre governos e gerentes de ccTLDs e entre ICANN e os governos. Trabalhando em conjunto, gerentes de ccTLDs prepararam vários esboços de documentos e melhores práticas. Ao reconhecerem a grande responsabilidade de um gerente de ccTLD perante as comunidades local e global da Internet, os gerentes tomaram a iniciativa de se organizarem e estabelecerem princípios e práticas comuns a todos que atendam aos interesses das diversas comunidades locais da Internet. Esses esforços estão documentados nas Diretrizes para Melhores Práticas para Gerentes de ccTLDs (Versão 4.1, 1 de junho de 2001). Em fevereiro de 2000, o Comitê Consultivo para Assuntos Governamentais (GAC) editou um documento intitulado "Princípios para delegação e administração de domínios de alto nível por código de país," mais conhecido como os "Princípios do GAC". Estes princípios funcionam como "melhores práticas" ao descreverem o papel dos governos em relação ao sistema de atribuição de nomes da Internet que, como observou o GAC, é um recurso público a ser administrado no interesse do público. Assim como as Diretrizes para Melhores Práticas do Grupo Constituinte para ccTLDs, os Princípios do GAC reafirmam a solidez dos fundamentos das políticas de IANA para ccTLDs já existentes: que "o gerente de um ccTLD desempenha um serviço público, no interesse da comunidade local relevante e, como tal, o gerente designado tem o dever de servir a essa comunidade". Os Princípios do GAC reconhecem que, coerentemente com o princípio da ICANN de liderança pelo setor privado, a administração de um ccTLD deve ser conduzida dentro de uma "estrutura tripartite de confiabilidade", na qual o gerente do ccTLD, o governo correspondente e ICANN trabalham em conjunto para promover a administração estável do ccTLD, da maneira que melhor atender à comunidade local. O gerente tem as responsabilidades administrativas e normativas básicas de um ccTLD, que ele deve cumprir no interesse da comunidade local e responder perante o governo e ICANN. Os Princípios do GAC reconhecem que cada governo é o responsável final dentro de seu território pelos objetivos públicos nacionais e que ICANN é responsável por garantir que o sistema de nomes de domínio da Internet continue oferecendo um sistema global de atribuição de nomes efetivo e interoperável. Embora o Grupo Constituinte para ccTLDS e o GAC tenham alguns pontos de vista diferentes sobre certos pontos específicos, ambos apóiam claramente dois pontos fundamentais: (a) A premissa histórica fundamental da política para ccTLDs, de que o gerente delegado atua como um curador a serviço da comunidade local da Internet, permanece válida.7 (b) Há necessidade de uma documentação mais formal, seja através de acordos ou instrumentos escritos equivalentes, para o compromisso mútuo das diversas entidades envolvidas na administração de ccTLDs. C. Elementos essenciais de futuros acordos Qualquer acordo firmado entre ICANN e um gerente de ccTLD deve incluir o compromisso do gerente de ccTLD de que ele irá desempenhar suas responsabilidades para com a comunidade local e global da Internet, dentro de um arcabouço de confiabilidade. Todos os acordos entre ICANN e gerentes de ccTLDs devem levar em conta as seguintes áreas: 1. Delegação, incluindo as circunstâncias em que o gerente designado de um ccTLD deve ser substituído, e os princípios aplicáveis. 2. Deveres do gerente de ccTLD relativos às políticas locais e globais e aos serviços públicos, para que ele administre e opere o ccTLD no interesse e em consulta à comunidade local da Internet, levando em conta a comunidade global da Internet e seus interesses. 3. Relacionamentos entre o ccTLD e ICANN e IANA, e as respectivas responsabilidades. 4. Financiamento da ICANN, para que a entidade possa supervisionar a estabilidade e a interoperabilidade globais. O cumprimento desses quatro tópicos genéricos da maneira que melhor atende aos propósitos gerais das políticas para ccTLDs exige uma atenção cuidadosa às circunstâncias específicas de cada ccTLD. Em todos os casos, os tópicos acima devem ser incluídos em um acordo (ou protocolo de intenções) entre ICANN e o gerente do ccTLD, de modo a determinar o papel e as responsabilidades de cada parte, oferecer uma pista de auditoria das decisões e transações, e esclarecer os termos da delegação perante a comunidade local e global da Internet. Variações de acordos: Situações de legado e situações triangulares Ao longo dos dois últimos anos, tornou-se evidente que não havia um acordo único - na verdade, nem uma estrutura de acordo única - apropriado para todos os ccTLDs. Embora inicialmente o objetivo das discussões fosse tentar desenvolver um modelo único de acordo, que pudesse ser usado para todos os gerentes de ccTLDs, o tempo mostrou que a enorme diversidade das situações dos ccTLDs e suas comunidades locais tornavam esse objetivo irreal. A comunidade de ccTLDs compreende uma enorme variedade de estruturas gerenciais, formas organizacionais, políticas de registro, mecanismos de imputabilidade e relacionamentos com governos. Conseqüentemente, ao longo de muitas horas, semanas e meses de discussão, destacaram-se duas situações estruturais primárias que exigem tratamento diferenciado, e que se diferenciam pelo envolvimento ou não-envolvimento do governo ou autoridade pública local. Essas circunstâncias são conhecidas como a situação triangular (envolvendo o governo ou autoridade pública relevante) e situação de legado (não envolvendo o governo ou autoridade pública relevante). Nessa altura, parece conveniente tentar consolidar alguns desses conceitos. Na forma mais simples, na situação de legado, assim como no passado, o gerente de ccTLD opera de acordo com as leis de seu país mas, por outro lado, sujeito apenas à supervisão de IANA e da ICANN. Na situação de legado, a responsabilidade de IANA, assegurando que o gerente de ccTLD atue como o curador indicado perante as comunidades locais e global da Internet, permanece a mesma que no passado. A situação triangular se configura quando o governo ou autoridade pública relevante está preparado para desempenhar o seu papel em garantir que os interesses da comunidade local sejam atendidos. Essa situação se beneficia da autoridade final do governo sobre políticas públicas dentro de suas fronteiras nacionais, atribuindo-lhe a responsabilidade de supervisionar se o gerente do ccTLD está cumprindo sua obrigação de atender à comunidade local da Internet. Na situação triangular, ICANN exerce a responsabilidade de garantir que a operação do ccTLD promova os interesses da comunidade global da Internet quanto à estabilidade e interoperabilidade e alguns outros assuntos, se o ccTLD encorajar o registro de pessoas ou entidades não-residentes daquele país. Esse arranjo tem a vantagem de atribuir ao governo local (isto é, nacional) a supervisão do serviço do gerente de ccTLD junto à comunidade local. Com certeza, do ponto de vista institucional esse governo ou autoridade pública está mais preparado do que ICANN para realizar essa supervisão. As situações triangulares e de legado foram exaustivamente discutidas e é aconselhável examiná-las em detalhes para avaliar quais modelos de acordos entre ICANN e gerentes de ccTLDs poderiam ser adequados. O objetivo do texto abaixo é apenas este, porém deve-se ter em mente que, mesmo com os dois modelos, provavelmente haverá variações das duas situações que exigirão ajustes. Da mesma forma, sem dúvida haverá situações que ficarão entre os dois modelos. A escolha de um arranjo de legado ou triangular dependerá das circunstâncias particulares de cada ccTLD e de seu relacionamento com o governo correspondente. A escolha do arranjo a ser seguido é um assunto exclusivo do governo e do gerente do ccTLD, em consulta à comunidade local da Internet, quando for conveniente. O teor das discussões da comunidade é que ICANN deve acomodar todos os tipos de arranjos (se as condições necessárias forem cumpridas), mas deve manter-se neutra e permitir que o governo e o gerente do ccTLD decidam entre si qual modelo seguir no contexto da legislação e das políticas de seu país. Aplicação do modelo triangular Em geral, para que se configure a situação triangular, ocorrerá a seguinte seqüência: 1. O governo ou autoridade pública relevante deve ter interesse em participar da estrutura cooperativa de responsabilidade desejada no modelo triangular. 2. O governo ou autoridade pública relevante deve ser capaz de desempenhar este papel. Em muitos casos, os governos indicaram que não têm condições de participar de um relacionamento triangular por não haver uma legislação autorizando essa participação, e que levará tempo para que esta seja aprovada. 3. O governo ou autoridade pública relevante e o gerente de ccTLD devem firmar um acordo ou outra comunicação apropriada quanto aos assuntos descritos na cláusula 9 dos Princípios do GAC. De maneira geral, a forma exata para as comunicações entre o governo e o gerente de ccTLD tratarem esse assunto ficará a critério dessas partes, em consulta correspondente à comunidade local da Internet. 4. O governo ou autoridade pública relevante devem notificar ICANN formalmente (em geral através de carta) de sua designação do gerente do ccTLD. Nessa carta, o governo também deve comunicar a ICANN como exigirá que o gerente cumpra os termos e condições descritos na cláusula 9 dos Princípios do GAC (o conteúdo das comunicações entre governo e gerente de ccTLD), expressar seu compromisso em garantir que os interesses locais (ou seja, nacionais) e as políticas públicas sejam atendidos, reconhecendo a responsabilidade da ICANN por coordenar o DNS (incluindo ccTLDs) de forma a assegurar a estabilidade e interoperabilidade de toda a Internet. 5. Para concluir as comunicações que formam a situação triangular, depois de receber os elementos das comunicações do governo a ICANN (item 4 acima), ICANN procuraria elaborar um acordo apropriado com o gerente de ccTLD, conforme descrito abaixo. Disposições do "Contrato de Patrocínio de ccTLD" em situações triangularesContrato de Patrocínio de ccTLDs". Esse modelo de acordo, já publicado, segue o plano geral da cláusula 10 dos Princípios do GAC. Ele também leva em consideração vários documentos sobre mecanismos para resolução de disputas reunidos pelo grupo constituinte para ccTLDs, incluindo materiais recebidos da Câmara Internacional de Comércio. Em resumo, o modelo para Contrato de Patrocínio de ccTLDs trata como segue os quatro tópicos principais descritos acima: 1. Delegação e redelegação: o acordo determina que a organização patrocinadora atuará como gerente do ccTLD até a rescisão do acordo, o que poderá ocorrer porque a organização rompeu suas comunicações com o governo (relativas a interesses nacionais), ou porque rompeu seu compromisso com ICANN referente a interesses globais, como o cumprimento de políticas que promovem a interoperabilidade. (Seções 2.10, 3.1 e 6.2.) 2. Responsabilidades políticas locais e globais: O gerente do ccTLD, sob supervisão governamental, tem autonomia para estabelecer políticas voltadas para os interesses locais. Ele concorda em cumprir políticas da ICANN referentes a interoperabilidade, capacidade operacional, desempenho do ccTLD e transparência dos dados de delegação e registro. Quando as políticas do ccTLD encorajarem ou promoverem registros de entidades ou indivíduos não-residentes, o gerente seguirá as políticas da ICANN especificamente aplicáveis, a menos que o governo determine que ele não deverá segui-las (Seção 4.5.) 3. Relacionamento entre ccTLD-ICANN/IANA: A Seção 3 determina que ICANN oferecerá serviços de zona de raiz para o ccTLD, segundo várias especificações. O gerente do ccTLD concorda com as diversas exigências operacionais para promover a estabilidade e a interoperabilidade, citadas na Seção 4. 4. Financiamento da ICANN: o gerente do ccTLD concorda em contribuir com o financiamento da ICANN "segundo uma escala eqüitativa, baseada nas necessidades totais de fundos da ICANN (incluindo reservas), estabelecidas por ICANN com base em consenso." (Seção 4.6.)
Nas situações em que o governo ou autoridade pública relevante não está interessado em participar de uma situação triangular, ou não pode fazê-lo por falta de uma legislação que o autorize, ou por outros fatores, é possível estabelecer um acordo de duas partes entre ICANN e o gerente do ccTLD. Estas situações são chamadas de situações de "legado". Com base nas discussões entre o Grupo Constituinte para ccTLDs e o Comitê Consultivo para Assuntos Governamentais, entretanto, existem diversas limitações sobre a aplicação do modelo de legado. Algumas possíveis limitações são: 1. Para permitir que os governos analisem se desejam e se são capazes ou não de participar de uma situação triangular, ICANN, em cooperação com o gerente de ccTLD, comprometeu-se a informar o governo que se discutirá o fato de que a situação em cada ccTLD e país é única, e precisará ser levada em consideração. 2. Enquanto um pedido de redelgação estiver pendente, em geral não seria indicado formalizar qualquer acordo, seja na situação de legado ou triangular, antes que o pedido seja resolvido. 3. Além disso, a opinião preponderante entre os gerentes e os governos é que não se devem firmar acordos segundo o modelo de legado quando o gerente do ccTLD não pertence à jurisdição do governo ou autoridade pública relevante, a menos que este/esta concorde com este acordo. Em seu comunicado de Melbourne, o GAC também expressou seu ponto de vista de que todos os acordos de "legado" devem ter caráter provisório e interino, aguardando a manifestação apropriada do governo ou autoridade pública para participar de uma situação triangular. Esta opinião é controvertida para alguns integrantes do Grupo Constituinte para ccTLDs, de modo que ainda serão necessárias algumas discussões entre o Grupo Constituinte para ccTLDs, o Comitê Consultivo para Assuntos Governamentais e outros membros da comunidade da Internet. Para promover relacionamentos definidos e estáveis, porém, nesse ínterim seria desejável definir documentos provisórios para refletir compromissos bilaterais interinos nessas situações em que os governos ainda não estão preparados para participar de uma situação triangular. Com essa finalidade, a equipe jurídica da ICANN preparou um modelo de Protocolo de Intenções que poderá ser considerado em situações de legado. Na preparação desse esboço, entre outros documentos a equipe jurídica faz referência ao esboço de 26 de novembro de 2001, do grupo constituinte para ccTLDs, "Contrato de serviços entre gerentes de ccTLD e ICANN" (e aos assuntos abordados) e à versão 4.0 das "Diretrizes de Melhores Práticas para gerentes de ccTLDs". Este modelo de Protocolo de Intenções (com link abaixo) foi elaborado para permitir que qualquer uma das partes possa rescindi-lo após notificação, e não cria nenhuma obrigação vinculada ao sistema jurídico. No entanto, mesmo esse tipo de Protocolo de Intenções (MoU) não-vinculativo tem a vantagem de formalizar as intenções da ICANN e do gerente do ccTLD, oferecer uma medida adicional para clareza e estabilidade dos relacionamentos na situação de legado. Não havendo uma objeção explícita do governo ou autoridade pública relevante, a adoção dessa forma de MoU promoverá a missão geral da ICANN, que é manter a estabilidade do DNS.
Em circunstâncias específicas, e com a aprovação do governo ou autoridade pública relevante, também poderá ser aconselhável firmar acordos com obrigações maiores e posse da delegação em situações de legado. O teor exato desses acordos inevitavelmente exigirá discussões entre as partes do país específico envolvido. D. Progresso até o momento e próximos passos A equipe jurídica da ICANN tem participado de discussões com gerentes de ccTLDs em três países (Austrália, Canadá e Japão) a respeito dos termos dos acordos entre ICANN e o gerente. Em cada um dos casos, os responsáveis do governo em questão foram notificados no início dessas discussões legais e foram mantidos a par do status. Em muitos outros casos, outros responsáveis da equipe da ICANN pelo contato com questões relativas a ccTLD realizaram discussões preliminares com gerentes de ccTLDs e executivos do governo. Essas discussões preliminares indicam que em muitos países os gerentes de ccTLDs estão preparados para aprofundar as discussões sobre a redação adequada de um acordo com ICANN. No caso da Austrália, as discussões levaram à conclusão dos termos de um Contrato de patrocínio de ccTLDs entre ICANN e au Domain Administration Limited, (auDA), sujeito à aprovação dos conselhos administrativos dessas organizações. Esta é uma situação triangular, na qual auDA estabeleceu as comunicações apropriadas com o governo da Austrália. O governo da Austrália, por sua vez, endossou auDA como o delegado para o ccTLD .au e comprometeu-se a cumprir sua responsabilidade na situação triangular, supervisionando o serviço de auDA para a comunidade local da Internet, reconhecendo ao mesmo tempo a responsabilidade da ICANN para "supervisionar a coordenação técnica da Internet, de maneira a preservá-la como um mecanismo efetivo e conveniente para comunicação e o comércio globais." Espera-se que o Contrato proposto para Patrocínio de ccTLDs seja submetido à consideração do Conselho Administrativo da ICANN durante sua reunião de 10 de setembro de 2001. (Além disso, desde a reunião de Montevidéu a equipe da ICANN tem feito várias apresentações do status dos acordos. Na reunião de CENTR em 20-21 de setembro de 2001, o contato para ccTLDs, Herbert Vitzthum, fez uma apresentação intitulada "Contratos da ICANN com ccTLDs.") Notas: 1 Conforme observação em RFC 1591, depois de desenvolver o DNS em 1985, IANA assumiu a responsabilidade geral pela administração do DNS como parte de sua missão de administrar os espaços de identificadores exclusivos da Internet no interesse do público: " A Internet Assigned Numbers Authority (IANA - Autoridade da Internet para Atribuição de Números) é responsável pela coordenação geral e gerenciamento do Sistema de Nomes de Domínio (DNS), especialmente a delegação de porções do espaço de nomes denominado domínios de alto nível". 2 Conforme declara RFC 1591: Essas autoridades designadas são curadores do domínio delegado, e têm o dever de servir à comunidade. O gerente designado é o curador do domínio de alto nível tanto perante a nação, no caso de um código de país, quanto perante a comunidade da Internet. Preocupações sobre "direito" e "propriedade" de domínios não são apropriadas. A preocupação deve voltar-se para "responsabilidades" e "serviço" à comunidade. 3 "Nos casos em que houver problemas persistentes com a operação apropriada de um domínio, a delegação pode ser revogada, e possivelmente delegada a outro gerente designado." RFC 1591. 4 Relatório de IANA sobre o pedido de redelegação do domínio de alto nível .pn (11 de fevereiro de 2000). 5 Conforme observação no Memo #1 do ccTLD News: Em algumas poucas ocasiões, as partes envolvidas não foram capazes de chegar a um acordo, e IANA foi convocada a resolver a questão. Em geral, este é um processo demorado, deixando pelo menos uma das partes insatisfeita, de modo que é muito melhor quando as partes conseguem chegar a um acordo entre si. 6 Em junho de 2001, IANA também editou um relatório concluindo que o ccTLD para o país antes denominado Zaire (.zr) deveria ser excluído. Essa decisão também foi implementada sem demora. 7 Das Diretrizes para Melhores Práticas para gerentes de ccTLD, do Grupo Constituinte para ccTLDs (Versão 4.1 - 1 de junho de 2001): Um gerente de ccTLD é um curador do domínio delegado, e tem o dever de servir à comunidade que representa, bem como à comunidade global da Internet. Preocupações sobre "diretos" e "propriedade" de domínios de alto nível são inadequadas. A preocupação deve voltar-se para "responsabilidades" e "serviço" à comunidade. Dos Princípios do GAC (23 de fevereiro de 2000): O princípio da RFC 1591 permanece o mesmo: o gerente de um ccTLD desempenha um serviço público no interesse da comunidade relevante local, e como tal, o gerente designado tem o dever de servir a essa comunidade. O gerente designado também é responsável perante a comunidade global da Internet. Comentários sobre o layout,
estrutura e funcionalidade deste site Página atualizada em 20 de
setembro de 2001 |
