ESTATUTO DA CORPORAÇÃO DA INTERNET PARA ATRIBUIÇÃO DE NOMES E NÚMEROS | Com vigência a partir de 15 de fevereiro de 2008
Esta página também está disponível em:
Note: this page is an archive of an old version of the bylaws. The current ICANN bylaws are always available at: https://www.icann.org/resources/pages/governance/bylaws-en
Uma organização da Califórnia sem fins lucrativos que visa benefícios públicos
Com vigência a partir de 15 de fevereiro de 2008
| Observação sobre as traduções A versão original deste documento é em inglês, disponível em http://www.icann.org/en/general/bylaws.htm. Quando houver uma diferença de interpretação entre a versão deste documento traduzida do inglês e o texto original, o texto original prevalecerá. |
ARTIGO I: MISSÃO E VALORES PRINCIPAIS
ARTIGO II: PODERES
ARTIGO III: TRANSPARÊNCIA
ARTIGO IV: RESPONSABILIDADE E REVISÃO
ARTIGO V: OMBUDSMAN
ARTIGO VI: CONSELHO DE DIRETORES
ARTIGO VII: COMITÊ DE NOMEAÇÃO
ARTIGO VIII: ORGANIZAÇÃO DE SUPORTE A ENDEREÇOS
ARTIGO IX: ORGANIZAÇÃO DE SUPORTE A NOMES DE CÓDIGOS DE PAÍSES
ARTIGO X: ORGANIZAÇÃO DE SUPORTE A NOMES GENÉRICOS
ARTIGO XI: COMITÊS CONSULTIVOS
ARTIGO XI-A: OUTROS MECANISMOS CONSULTIVOS
ARTIGO XII: COMITÊS DO CONSELHO E TEMPORÁRIOS
ARTIGO XIII: ADMINISTRADORES
ARTIGO XIV: INDENIZAÇÃO DE DIRETORES, EXECUTIVOS, FUNCIONÁRIOS E OUTROS AGENTES
ARTIGO XV: DISPOSIÇÕES GERAIS
ARTIGO XVI: QUESTÕES FISCAIS
ARTIGO XVII: MEMBROS
ARTIGO XVIII: CARGOS E SELO
ARTIGO XIX: EMENDAS
ARTIGO XX: ARTIGO DE TRANSIÇÃO
ANEXO A: PROCESSO DE DESENVOLVIMENTO DE POLÍTICA DA GNSO
ANEXO B: PROCESSO DE DESENVOLVIMENTO DE POLÍTICA DA ccNSO (ccPDP)
ANEXO C: O ESCOPO DA ccNSO
ARTIGO I: MISSÃO E VALORES PRINCIPAIS
A missão da Corporação da Internet para Atribuição de Nomes e Números ("ICANN") é coordenar, de forma geral, os sistemas de identificadores exclusivos da Internet globais e, particularmente, garantir a operação estável e segura dos sistemas de identificadores exclusivos da Internet. Em especial, a ICANN:
1. Coordena a alocação e a atribuição dos três conjuntos de identificadores exclusivos da Internet, que são
a. Nomes de domínio (que formam um sistema chamado de "DNS");
b. Endereços de protocolo da Internet ("IP") e números de sistema autônomo ("AS"); e
2. Coordena a operação e a evolução do nome do sistema de servidor da raiz do DNS.
3. Coordena o desenvolvimento da política de forma razoável e de acordo com essas funções técnicas.
Para cumprir sua missão, a ICANN deve ter suas decisões e ações orientadas pelos seguintes valores:
1. Preservar e aprimorar a segurança, a credibilidade e a estabilidade operacional e a interoperabilidade global da Internet.
2. Respeitar a criatividade, a inovação e o fluxo de informações disponibilizados pela Internet, limitando as atividades da ICANN às questões relacionadas à sua missão, exigindo ou tirando proveito significativo da coordenação global.
3. Na medida do possível, delegar as funções de coordenação a outras entidades responsáveis que reflitam os interesses das partes envolvidas, ou reconhecer as funções de política destas entidades.
4. Buscar e apoiar uma participação ampla e informada, refletindo as diversidades funcionais, geográficas e culturais da Internet, nos níveis de desenvolvimento de política e tomada de decisões.
5. Quando possível, utilizar mecanismos de mercado para estimular e manter um ambiente competitivo.
6. Introduzir e promover a competição no registro de nomes de domínio, quando for possível e benéfico para o público.
7. Utilizar mecanismos de desenvolvimento de política abertos e transparentes que (i) promovam decisões bem informadas, baseadas na orientação de especialistas, e (ii) garantam que as entidades mais afetadas possam participar do processo de desenvolvimento de política.
8. Tomar decisões aplicando políticas documentadas de forma neutra, objetiva, íntegra e justa.
9. Agir com uma rapidez que atenda as necessidades da Internet, ao mesmo tempo em que, como parte do processo de tomada de decisões, obtém informações sobre as entidades mais afetadas.
10. Manter-se responsável pela comunidade da Internet, através de mecanismos que melhorem a eficiência da ICANN.
11. Embora estabelecida no setor privado, reconhecer que os governos e as autoridades públicas são responsáveis pela política pública e levar devidamente em consideração as recomendações do governo ou de autoridades públicas.
Esses valores principais são expressos em termos bastante gerais, para que possam fornecer uma orientação útil e relevante na maior variedade possível de circunstâncias. Como sua prescrição não é limitada, a forma específica como esses valores são aplicados, individual ou coletivamente, a cada nova situação irá depender de vários fatores que não podem ser totalmente previstos ou enumerados e, como são questões mais de princípio do que de prática, haverá situações em que não será possível atingir uma completa fidelidade a todos os onze valores. O órgão da ICANN que estiver fazendo uma recomendação ou tomando uma decisão deverá fazer uma avaliação para determinar quais desses valores são mais relevantes e como eles devem ser aplicados às circunstâncias específicas de um determinado caso. Além disso, deverá definir, se necessário, um equilíbrio adequado e defensável entre valores competitivos.
Exceto se definido em contrário nos Artigos de Registro ou neste Estatuto, os poderes da ICANN deverão ser exercidos pelo Conselho, que também deverá controlar a propriedade da ICANN e conduzir ou gerenciar seus negócios e questões. Com relação às questões que se enquadrem nas provisões do artigo III, seção 6, a atuação do Conselho irá depender do voto da maioria de todos os membros do Conselho. Em todas as outras questões, exceto se definido em contrário neste Estatuto ou na legislação, o Conselho poderá atuar segundo o voto de maioria de membros do Conselho presentes em encontros especiais, regulares ou anuais. Quaisquer referências contidas neste Estatuto sobre um voto do Conselho deverão ser entendidas como voto somente dos membros presentes em uma reunião com presença de quorum, a menos que seja especificado de outra forma neste Estatuto, referindo-se a "todos os membros do Conselho".
A ICANN não deve atuar como um Registro de Sistema de Nomes de Domínio ou Registradora ou Registro de Endereço de Protocolo da Internet competindo com entidades afetadas pelas políticas da ICANN. Nada desta seção visa impedir a ICANN de realizar as etapas necessárias para proteger a estabilidade operacional da Internet em caso de falência de um registro ou registrador ou outra emergência.
Seção 3. TRATAMENTO NÃO-DISCRIMINATÓRIO
A ICANN não pode utilizar seus padrões, políticas ou práticas de forma desigual ou discriminar uma determinada parte aplicando um tratamento diferenciado, a menos que haja uma causa substancial e razoável, como a promoção de competição eficiente.
A ICANN e seus órgãos constituintes devem atuar de forma aberta e transparente, de acordo com procedimentos designados para assegurar justiça.
A ICANN deve manter uma página na World Wide Web da Internet ( o "site") que contenha, entre outras coisas, (i) um calendário das reuniões agendadas para o Conselho, as Organizações de Apoio e os Comitês Consultivos; (ii) um sumário de todas as questões pendentes sobre o desenvolvimento de políticas, incluindo a programação e o status atual; (iii) notas e programações sobre reuniões específicas, como descrito abaixo; (iv) informações sobre o orçamento, a auditoria anual e contribuidores financeiros da ICANN, bem como a quantidade de contribuições e questões relacionadas; (v) informações sobre a disponibilidade de mecanismos de responsabilidade, incluindo reconsideração, revisão independente e atividades do Ombudsman, bem com informações sobre os resultados de solicitações e reclamações específicas, relacionadas a esses mecanismos; (vi) anúncios sobre as atividades da ICANN que sejam de interesse de segmentos importantes da comunidade da ICANN; (vii) comentários recebidos da comunidade a respeito das políticas sendo desenvolvidas e outras questões; (viii) informações sobre reuniões físicas e fóruns públicos da ICANN; e (ix) outras informações de interesse da comunidade da ICANN.
Seção 3. GERENTE DE PARTICIPAÇÃO PÚBLICA
Deve haver um cargo designado Gerente de Participação Pública, ou outro título parecido definido pelo Presidente, que seja responsável, sob orientação do Presidente, pela coordenação de vários aspectos da participação pública na ICANN, incluindo o site e vários outros meios de comunicação, e a participação da comunidade geral de usuários da Internet.
Seção 4. NOTAS E PROGRAMAÇÕES SOBRE REUNIÕES
Pelo menos sete dias antes de cada reunião do Conselho (se não for possível, com o máximo de antecedência possível), uma nota sobre a reunião, bem como sua programação, deverão ser postadas.
Seção 5. ATAS E RELATÓRIOS PRELIMINARES
1. Todas as atas de reuniões do Conselho e Organizações de Apoio (e quaisquer conselhos relacionados) deverão ser aprovadas imediatamente pelo órgão de origem e entregues ao Secretário da ICANN para que sejam postadas no site.
2. No máximo cinco (5) dias úteis após cada reunião (cálculo feito segundo a hora local de onde o escritório principal da ICANN está localizado), todas as ações do Conselho deverão ser disponibilizadas em um relatório preliminar no site; no entanto, ações relacionadas a questões empregatícias ou funcionários, questões legais (aquelas que o Conselho determinar serem necessárias ou apropriadas para proteger os interesses da ICANN), questões que a ICANN esteja proibida de disponibilizar para o público, devido a leis ou contratos, e outras questões que o Conselho definir, com três quartos (3/4) dos votos dos diretores votantes presentes na reunião, como não indicadas para distribuição para o público, não deverão ser incluídas no relatório preliminar disponibilizado para o público. Toda vez que não permitir a divulgação de alguma questão, o Conselho deverá explicar no relatório preliminar, em termos gerais, a razão da não divulgação.
3. No máximo no dia seguinte à aprovação formal das atas pelo Conselho (ou, se não se tratar de um dia útil de acordo com a hora local de onde o escritório principal da ICANN está localizado, no primeiro dia útil seguinte), as atas deverão ser disponibilizadas no site; no entanto, atas relacionadas a questões empregatícias ou funcionários, questões legais (aquelas que o Conselho determinar serem necessárias ou apropriadas para proteger os interesses da ICANN), questões que a ICANN esteja proibida de disponibilizar para o público, devido a leis ou contratos, e outras questões que o Conselho definir, com três quartos (3/4) dos votos dos diretores votantes presentes na reunião, como não indicadas para distribuição para o público, não deverão ser incluídas nas atas disponibilizadas para o público. Toda vez que não permitir a divulgação de alguma questão, o Conselho deverá explicar no relatório preliminar, em termos gerais, a razão da não divulgação.
Seção 6. NOTIFICAÇÕES E COMENTÁRIOS SOBRE AÇÕES RELACIONADAS A POLÍTICAS
1. Com relação a políticas que o Conselho considere utilizar e que possam afetar de forma significativa a operação da Internet ou de terceiros, incluindo a obrigatoriedade de custos ou taxas, a ICANN deverá:
a. fazer uma notificação pública no site, explicando quais políticas estão sendo consideradas para utilização e as razões, pelo menos vinte e um dias (e, se possível, antes) antes de qualquer ação do Conselho;
b. proporcionar uma oportunidade razoável para que as partes comentem sobre a adoção das políticas propostas, vejam os comentários dos outros e respondam a esses comentários, antes de qualquer ação do Conselho; e
c. nos casos em que a ação de política afetar os interesses da política pública, solicitar a opinião do Comitê Consultivo Governamental e levar devidamente em consideração quaisquer conselhos fornecidos por ele por iniciativa própria ou atendendo a uma solicitação do Conselho.
2. Quando for possível e coerente com o processo de desenvolvimento de política, um fórum público deverá ser realizado presencialmente para que seja feito um debate sobre as políticas propostas descritas na seção 6(1)(b) deste artigo, antes que o Conselho realize qualquer ação.
3. Depois de qualquer ação referente às políticas desta seção, o Conselho deverá publicar nas atas das reuniões as razões dessas ações, o voto de cada diretor votante na ação e a declaração separada dos diretores que desejarem publicar suas declarações.
Seção 7. TRADUÇÃO DE DOCUMENTOS
Conforme necessário, e se o orçamento permitir, a ICANN deverá providenciar a tradução de documentos finais publicados para vários idiomas.
ARTIGO IV: RESPONSABILIDADE E REVISÃO
A fim de cumprir sua missão, definida neste Estatuto, a ICANN deve ser responsável pela comunidade, operando de forma consistente com este Estatuto e seguindo fielmente os valores principais definidos no Artigo I deste Estatuto. As provisões deste artigo, a criação de processos para reconsideração e revisão independente das ações da ICANN e a revisão periódica da estrutura e dos procedimentos da ICANN têm por objetivo consolidar os vários mecanismos de responsabilidade definidos neste Estatuto, incluindo as provisões de transparência do artigo III e do Conselho e outros mecanismos de seleção definidos neste Estatuto.
1. A ICANN deve possuir um processo através do qual uma pessoa ou entidade afetada materialmente por uma ação da ICANN possa solicitar uma revisão ou reconsideração de uma ação do Conselho.
2. Qualquer pessoa ou entidade pode enviar uma solicitação de reconsideração ou revisão de uma ação ou inação da ICANN ("Solicitação de Reconsideração"), desde que tenham sido afetadas negativamente por:
a. uma ou mais ações ou inações da equipe que contradigam políticas estabelecidas da ICANN; ou
b. uma ou mais ações ou inações do Conselho da ICANN que tenham sido realizadas ou recusadas sem informações relevantes, exceto quando a parte que envia a solicitação tem a possibilidade de enviar as informações para consideração do Conselho no momento da ação ou da recusa de ação, mas não as envia.
3. Deve haver um Comitê do Conselho, composto de, pelo menos, três diretores, para avaliar e considerar estas solicitações ("Comitê de Reconsideração"). O Comitê de Reconsideração deve ter autoridade para:
a. avaliar solicitações de revisão ou reconsideração;
b. determinar se é adequado suspender a ação de contestação com resolução pendente;
c. conduzir investigações factuais quando conveniente;
d. solicitar documentos por escrito adicionais da parte afetada, ou de outras partes; e
e. fazer uma recomendação para o Conselho de Diretores sobre os méritos de uma solicitação.
4. A ICANN deverá assumir os custos administrativos normais do processo de reconsideração. Ela se reserva o direito de cobrar da parte que solicitar uma revisão ou reconsideração todos os custos considerados extraordinários. Quando for possível prever estes custos extraordinários, o fato e as razões destes custos serem adequados e necessários para a avaliação da Solicitação de Reconsideração deverão ser comunicados para a parte que busca a reconsideração, que deverá, então, ter a opção de retirar a solicitação ou assumir tais custos.
5. Todas as Solicitações de Reconsideração deverão ser enviadas para um endereço eletrônico definido pelo Comitê de Reconsideração do Conselho em até trinta dias após:
a. para solicitações que contestem ações do Conselho, a data em que as informações sobre a ação contestada tiverem sido publicadas pela primeira vez em um relatório preliminar ou nas atas das reuniões do Conselho; ou
b. para solicitações que contestem ações da equipe, a data em que a parte que enviou a solicitação tomou conhecimento, ou deveria ter tomado conhecimento, da ação contestada da equipe; ou
c. para solicitações que contestem inações do Conselho ou da equipe, a data em que a pessoa afetada percebeu, ou deveria ter percebido, que a ação não seria realizada em tempo hábil.
6. Todas as Solicitações de Reconsideração devem incluir as informações solicitadas pelo Comitê de Reconsideração, pelo menos as informações a seguir:
a. nome, endereço e informações de contato da parte solicitante, incluindo endereço postal e endereço eletrônico;
b. a ação ou inação específica da ICANN que gerou uma solicitação de revisão ou reconsideração;
d. o impacto da ação ou inação na parte solicitante;
e. de que forma, na opinião da parte que faz a Solicitação de Reconsideração, a ação ou inação reclamada afeta negativamente terceiros;
f. se uma suspensão temporária de uma ação reclamada é solicitada e, em caso afirmativo, os danos resultantes da não suspensão da ação;
g. no caso de ação ou inação da equipe, uma explicação detalhada dos fatos que foram apresentados à equipe e as razões pelas quais sua ação ou inação não foi coerente com as políticas estabelecidas da ICANN;
h. no caso de uma ação ou inação do Conselho, uma explicação detalhada das informações materiais não consideradas pelo Conselho e, se as informações não tiverem sido apresentadas ao Conselho, as razões que fizeram com que a parte solicitante não as enviasse para o Conselho antes de ele agir ou deixar de agir;
i. as etapas específicas que a parte solicitante pede que a ICANN realize – ou seja, se e como a ação deve ser revertida, cancelada ou modificada, ou qual ação específica deve ser tomada;
j. as condições em que a ação solicitada deve ser realizada; e
k. quaisquer documentos que a parte solicitante deseje enviar como apoio à sua solicitação.
7. Todas as Solicitações de Reconsideração devem ser postadas no site.
8. O Comitê de Reconsideração deve ter autoridade para considerar Solicitações de Reconsideração de diferentes partes no mesmo procedimento, desde que (i) as solicitações envolvam a mesma ação ou inação geral e (ii) as partes sejam afetadas de forma semelhante pela ação ou inação.
9. O Comitê de Reconsideração deve avaliar Solicitações de Reconsideração assim que forem recebidas e deve anunciar, em até trinta dias, sua intenção de recusar ou aceitar a Solicitação. A divulgação deverá ser postada no site.
10. A divulgação de uma decisão do Comitê de Reconsideração de não atender a uma Solicitação deverá conter uma explicação sobre as razões desta decisão.
11. O Comitê de Reconsideração pode solicitar informações ou esclarecimentos adicionais da parte que faz a Solicitação de Reconsideração.
12. O Comitê de Reconsideração pode consultar as impressões da equipe da ICANN a respeito da questão; estes comentários deverão ser disponibilizados para o público no site.
13. Se o Comitê de Reconsideração solicitar informações adicionais, ele poderá realizar uma reunião com a parte solicitante da Reconsideração por telefone, e-mail ou, se possível para a parte solicitante, uma reunião pessoalmente. Se as informações coletadas nessas reuniões forem relevantes para recomendações do Comitê de Reconsideração, elas deverão, então, ser incluídas nestas recomendações.
14. O Comitê de Reconsideração também pode solicitar de terceiros informações relevantes para a solicitação. Se as informações coletadas forem relevantes para recomendações do Comitê de Reconsideração, elas deverão, então, ser incluídas nestas recomendações.
15. O Comitê de Reconsideração deve trabalhar em uma Solicitação de Reconsideração com base no registro escrito público, incluindo informações enviadas pela parte solicitante da reconsideração ou revisão, pela equipe da ICANN e por terceiros.
16. Para evitar abusos no processo de reconsideração, uma solicitação de reconsideração poderá ser recusada pelo Comitê de Reconsideração quando for repetitiva, frívola, sem embasamento, ou que apresente qualquer outro tipo de abuso, ou quando a parte afetada tiver a ciência e a oportunidade de participar, mas não participar, do período de comentários públicos relacionados à ação contestada, se aplicável. Da mesma forma, o Comitê de Reconsideração poderá recusar uma solicitação quando a parte solicitante não provar que será afetada pela ação da ICANN.
17. O Comitê de Reconsideração deve fazer uma recomendação final para o Conselho com relação a uma Solicitação de Reconsideração em até 90 dias após o recebimento da solicitação, a menos que não seja possível. Neste caso, ele deverá relatar para o Conselho as circunstâncias que impediram a realização desta recomendação final e sua estimativa para produzi-la. A recomendação final deverá ser postada no site.
18. O Conselho não tem obrigação de seguir as recomendações do Comitê de Reconsideração. A decisão final do Conselho deve ser disponibilizada para o público como parte do relatório preliminar e das atas da reunião do Conselho em que a ação for realizada.
19. O Comitê de Reconsideração deve enviar um relatório para o Conselho anualmente, contendo pelo menos as seguintes informações a respeito do ano anterior:
a. o número e a natureza geral das Solicitações de Reconsideração recebidas;
b. o número de Solicitações de Reconsideração para as quais o Comitê realizou ações;
c. o número de Solicitações de Reconsideração que permaneceram pendentes ao final do ano e por quanto tempo ficaram pendentes;
d. descrições das Solicitações de Reconsideração pendentes ao final do ano há mais de 90 dias e as razões pelas quais o Comitê não realizou ações sobre elas;
e. o número e a natureza das Solicitações de Reconsideração que o Comitê recusou, por não atenderem aos critérios estabelecidos nesta política;
f. no caso de Solicitações de Reconsideração recusadas, uma explicação sobre outros mecanismos disponíveis para assegurar que a ICANN seja responsável por aqueles afetados materialmente por suas decisões; e
g. se, de acordo com a posição do Comitê, os critérios para solicitação de reconsideração devem ou não ser revisados, ou outro processo deve ser adotado ou modificado, para garantir que todas as pessoas afetadas materialmente pelas decisões da ICANN tenham acesso a um processo de revisão que assegure justiça, enquanto limita reclamações frívolas.
20. Os relatórios anuais também devem conter as informações dos tópicos listados no parágrafo 19(a)-(e) desta seção para o período com início em 1º de janeiro de 2003.
Seção 3. REVISÃO INDEPENDENTE DAS AÇÕES DO CONSELHO
1. Além do processo de reconsideração descrito na seção 2 deste artigo, a ICANN deve possuir um processo separado para revisão independente de terceiros sobre ações do Conselho que sejam consideradas por uma parte afetada como inconsistentes com os Artigos de Incorporação ou o Estatuto.
2. Qualquer pessoa afetada materialmente por uma decisão ou ação do Conselho, que ela afirme ser inconsistente com os Artigos de Incorporação ou o Estatuto, deverá enviar uma solicitação para revisão independente da decisão ou ação.
3. As solicitações de revisão independente devem ser encaminhadas para um Painel de Revisão Independente ("IRP"), que deverá comparar as ações contestadas do Conselho aos Artigos de Incorporação ou Estatutos, e declarar se o Conselho agiu de forma consistente com as provisões desses Artigos de Incorporação e Estatutos.
4. O IRP deve ser operado por um provedor de arbitragem internacional, selecionado de tempos em tempos pela ICANN ("o Provedor do IRP") dentre arbitradores que possuam contrato com o provedor ou sejam nomeados por ele.
5. Sujeito à aprovação do Conselho, o Provedor do IRP deverá estabelecer regras e procedimentos operacionais, que deverão ser implementados e estar de acordo com esta seção 3.
6. Cada parte pode votar se a solicitação para revisão independente deve ser considerada por um painel composto por três membros; na ausência desta votação, a questão poderá ser considerada por um painel composto por um único membro.
7. O Provedor do IRP deve definir um procedimento para atribuição de membros a painéis individuais; desde que a ICANN oriente desta forma, o Provedor do IRP deverá estabelecer um painel assessor para atender a estas reclamações.
8. O IRP deve ter autoridade para:
a. solicitar documentos por escrito adicionais da parte solicitante da revisão, do Conselho, das Organizações de Apoio ou de outras partes;
b. declarar se uma ação ou inação do Conselho foi ou não inconsistente com os Artigos de Incorporação ou o Estatuto; e
c. recomendar que o Conselho suspenda uma ação ou decisão, ou que o Conselho tome alguma ação temporária até que revise e aja de acordo com a opinião do IRP.
9. Os indivíduos que possuem uma posição ou um cargo oficial dentro da estrutura da ICANN não podem se candidatar para participar do IRP.
10. A fim de minimizar os custos e encargos de revisões independentes, o IRP deverá conduzir seus procedimentos por e-mail ou outro meio através da Internet o máximo possível. Quando necessário, o IRP poderá realizar reuniões por telefone.
11. O IRP deve aderir à política de conflitos de interesse contida nas regras e procedimentos operacionais do Provedor do IRP, conforme aprovado pelo Conselho.
12. As declarações do IRP devem ser feitas por escrito. O IRP deve fazer sua declaração baseando-se somente na documentação, nos materiais de apoio e nos argumentos enviados pelas partes; deve especificar também a parte dominante. A parte não dominante normalmente deve ser responsável por assumir todos os gastos do Provedor do IRP, mas, em casos extraordinários, o IRP pode definir em sua declaração que a parte dominante assuma metade dos gastos, dependendo das circunstâncias, incluindo uma consideração de razoabilidade das posições das partes e sua contribuição para o interesse público. Cada parte envolvida nos procedimentos do IRP deve assumir suas despesas.
13. Os procedimentos operacionais do IRP, bem como todas as petições, reclamações e declarações devem ser postados no site assim que são disponibilizados.
14. O IRP pode, a seu critério, acatar a solicitação de uma parte que peça o sigilo de certas informações, como segredos comerciais.
15. Quando possível, o Conselho deve considerar a declaração do IRP na próxima reunião do Conselho.
Seção 4. REVISÃO PERIÓDICA DA ESTRUTURA E DAS OPERAÇÕES DA ICANN
1. O Conselho deve realizar uma revisão periódica, se possível pelo menos a cada três anos, do desempenho e da operação de cada Organização de Suporte, cada Conselho de Organização de Suporte, cada Comitê Consultivo (além do Comitê Consultivo Governamental), e do Comitê de Nomeação, através de entidades independentes da organização sendo revisada. O objetivo da revisão, que deve ser realizada de acordo com os critérios e padrões estabelecidos pelo Conselho, é determinar (i) se a organização tem motivos para continuar na estrutura da ICANN, e, (ii) em caso afirmativo, se alguma mudança na estrutura ou nas operações é necessária para melhorar sua eficácia. Os resultados das revisões deverão ser postados no site para que o público possa consultar e fazer comentários, e deverão ser considerados pelo Conselho no máximo na segunda reunião agendada do Conselho depois que estes resultados estiverem postados há 30 dias. A consideração do Conselho inclui a habilidade de revisar a estrutura ou a operação das partes da ICANN sendo revisadas, por aprovação de dois terços dos votos de todos os membros do Conselho.
2. A primeira revisão, a ser iniciada no máximo em 15 de dezembro de 2003 e que deve ser concluída a tempo para consideração do Conselho na reunião anual da ICANN em 2004, deve ser do Conselho da GNSO e do Comitê Consultivo de Sistema de Servidor Raiz da ICANN. A segunda revisão, a ser iniciada no máximo em 15 de novembro de 2004 e que deve ser concluída a tempo para consideração do Conselho na reunião anual da ICANN em 2005, deve ser da ccNSO, do Conselho da ccNSO e de outras organizações deste tipo definidas pelo Conselho.
3. O Comitê Consultivo Governamental deve fornecer seus próprios mecanismos de revisão.
1. Deve haver um Cargo de Ombudsman, a ser gerenciado por um Ombudsman, para incluir o apoio desta equipe conforme o Conselho julgar possível e apropriado. O Ombudsman deve ser um cargo de horário integral, com salário e benefícios adequados para a função, conforme definido pelo Conselho.
2. O Ombudsman deve ser indicado pelo Conselho para um mandato inicial de dois anos, que poderá ser renovado pelo Conselho.
3. O Ombudsman só poderá ser demitido pelo Conselho se houver aprovação de três quartos (3/4) dos votos de todos os membros do Conselho.
4. O orçamento anual do Cargo de Ombudsman deve ser estabelecido pelo Conselho como parte do processo de orçamento anual da ICANN. O Ombudsman deve enviar uma proposta de orçamento para o Presidente, que deverá incluí-la em sua totalidade e sem alterações no orçamento geral da ICANN recomendado pelo Presidente da ICANN para o Conselho. Nada deste artigo impede que o Presidente forneça impressões separadas sobre o conteúdo, o tamanho ou outras características do orçamento proposto pelo Ombudsman para o Conselho.
A função do Ombudsman deve ser agir como um profissional neutro para resolução de disputas nos casos em que as provisões da Política de Reconsideração definida na seção 2 do artigo IV ou da Política de Revisão Independente definida na seção 3 do artigo IV não forem solicitadas. A principal função do Ombudsman deve ser fornecer uma avaliação interna independente de reclamações feitas por membros da comunidade da ICANN que acreditem ter sido tratados de forma injusta pela equipe da ICANN, pelo Conselho ou por um órgão constituinte da ICANN. O Ombudsman deve atuar como um defensor da justiça e deve avaliar e, sempre que possível, resolver reclamações sobre tratamentos injustos ou inadequados por parte da equipe da ICANN, do Conselho ou de órgãos constituintes da ICANN, esclarecendo as questões e usando ferramentas de resolução de conflitos, como negociação, facilitação e "diplomacia itinerante" para obter estes resultados.
O Cargo de Ombudsman deve:
1. facilitar a resolução rápida, justa e imparcial de problemas e reclamações feitas por membros afetados da comunidade da ICANN (exceto funcionários e vendedores/fornecedores da ICANN), relacionadas a ações ou inações do Conselho ou da equipe da ICANN que não se tornaram o assunto da Reconsideração ou das Políticas de Revisão Independentes;
2. ter discernimento para aceitar ou recusar uma reclamação ou questão, inclusive pelo desenvolvimento de procedimentos para descartar reclamações que não sejam suficientemente concretas, substanciais ou relacionadas a interações da ICANN com a comunidade, casos em que não é adequado solicitar a atuação do Ombudsman. Além disso, o Ombudsman não deve ter autoridade para atuar em questões administrativas internas, questões pessoais, problemas relacionados à afiliação ao Conselho ou problemas que envolvam relações vendedor/fornecedor;
3. ter direito de acesso (mas não o direito de publicar, em caso de material confidencial) a todas as informações e registros necessários da equipe e de órgãos constituintes da ICANN, para permitir uma avaliação embasada da reclamação e ajudar na resolução de disputas quando possível (sujeito apenas a obrigações de confidencialidade impostas pelo reclamante ou às políticas de confidencialidade gerais adotadas pela ICANN);
4. aumentar a divulgação do programa e das funções do Ombudsman através da interação de rotina com a comunidade da ICANN e da disponibilidade on-line;
5. manter a neutralidade e a independência e não realizar ações tendenciosas ou pessoais que influenciem resultados; e
6. agir em conformidade com todas as políticas de confidencialidade e de conflitos de interesse da ICANN.
Seção 4. INTERAÇÃO COM A ICANN E ENTIDADES EXTERNAS
1. Nenhum funcionário da ICANN, membro do Conselho ou outro participante das Organizações de Apoio ou Comitês Consultivos pode evitar ou impedir o contato do Ombudsman com a comunidade da ICANN (incluindo funcionários da ICANN). Os funcionários da ICANN e os membros do Conselho devem orientar os membros da comunidade da ICANN que repassam problemas, preocupações ou reclamações sobre a ICANN para o Ombudsman, que deverá alertar os reclamantes sobre as várias opções disponíveis para revisão desses problemas, preocupações ou reclamações.
2. A equipe da ICANN e outros participantes da ICANN devem observar e respeitar determinações feitas pelo Cargo de Ombudsman sobre a confidencialidade das reclamações recebidas por esse Cargo.
3. O contato com o Ombudsman não deve significar que a ICANN esteja ciente de alguma ação específica ou causa de ação.
4. O Ombudsman deve receber autorização específica para fazer relatos ao Conselho, conforme julgar apropriado, de acordo com a questão e sua resolução, ou incapacidade de resolvê-la. Sem uma determinação do Ombudsman, a seu próprio critério, de que isso seria inadequado, esses relatórios deverão ser postados no site.
5. O Ombudsman não deve realizar nenhuma ação que não seja autorizada neste Estatuto e, em especial, não deve estabelecer, participar ou oferecer suporte de nenhuma forma a ações legais que desafiem a estrutura, os procedimentos os processos da ICANN ou qualquer conduta do Conselho, da equipe ou dos órgãos constituintes da ICANN.
O Cargo de Ombudsman deve publicar anualmente uma análise consolidada das reclamações e resoluções do ano, respeitando obrigações de confidencialidade. Estes relatórios anuais devem incluir uma descrição de tendências ou elementos comuns das reclamações recebidas durante o período em questão, bem como recomendações a respeito de etapas que devem ser realizadas para reduzir reclamações futuras. O relatório anual deverá ser postado no site.
ARTIGO VI: CONSELHO DE DIRETORES
Seção 1. COMPOSIÇÃO DO CONSELHO
O Conselho de Diretores da ICANN ("Conselho") deve ser composto por quinze membros votantes ("Diretores"). Além disso, seis contatos não-votantes ("Contatos") devem ser definidos para as finalidades definidas na seção 9 deste artigo. Somente os Diretores podem participar da determinação de existência de quorum e do estabelecimento de validade dos votos do Conselho da ICANN.
Seção 2. DIRETORES E SUAS SELEÇÕES; ELEIÇÃO DE PRESIDENTE E VICE-PRESIDENTE
1. Os Diretores devem ser compostos por:
a. Oito membros votantes selecionados pelo Comitê de Nomeação estabelecido pelo artigo VII deste Estatuto. Neste Estatuto, esses Assentos no Conselho de Diretores são chamados de Assentos 1 a 8.
b. Dois membros votantes selecionados pela Organização de Suporte a Endereços de acordo com as provisões do artigo VIII deste Estatuto. Neste Estatuto, esses Assentos no Conselho de Diretores são chamados de Assentos 9 e 10.
c. Dois membros votantes selecionados pela Organização de Suporte a Nomes de Códigos de Países de acordo com as provisões do artigo IX desse Estatuto. Neste Estatuto, esses Assentos no Conselho de Diretores são chamados de Assentos 11 e 12.
d. Dois membros votantes selecionados pela Organização de Suporte a Nomes Genéricos de acordo com as provisões do artigo X deste Estatuto. Neste Estatuto, esses assentos no Conselho de Diretores são chamados de Assentos 13 e 14.
2. Para cumprir com sua responsabilidade de preencher os Assentos de 1 a 8, o Comitê de Nomeação deve assegurar-se de que o Conselho da ICANN seja composto de membros que representem diversidade geográfica, cultural, de capacitação, de experiência e de perspectivas, aplicando os critérios definidos na seção 3 deste artigo. Em nenhum momento o Comitê de Nomeação poderá selecionar um Diretor para suprir uma vacância ou um mandato expirado se esta seleção fizer com que o número total de diretores (sem incluir o Presidente) que sejam cidadãos de países em uma única região geográfica (conforme definido na seção 5 deste artigo) exceda cinco; e o Comitê de Nomeação deverá assegurar, através de suas seleções, que o Conselho sempre possua pelo menos um Diretor que seja cidadão de um país de cada região geográfica da ICANN.
3. Para cumprir com sua responsabilidade de preencher os Assentos de 9 a 14, as Organizações de Apoio devem assegurar-se de que o Conselho da ICANN seja composto de membros que representem diversidade geográfica, cultural, de capacitação, de experiência e de perspectivas, aplicando os critérios definidos na seção 3 deste artigo. Em nenhum momento deverá haver dois diretores selecionados por uma Organização de Suporte que sejam cidadãos do mesmo país ou de países localizados na mesma região geográfica.
4. O Conselho deverá fazer uma eleição anual para Presidente e Vice-Presidente dentre os diretores, excluindo o Presidente.
Seção 3. CRITÉRIOS PARA SELEÇÃO DE DIRETORES
Os diretores da ICANN devem ser:
1. Pessoas com integridade, objetividade e inteligência, com reputação para bom julgamento e mente aberta, e com competência comprovada para tomada de decisões em grupo;
2. Pessoas com compreensão da missão da ICANN e do impacto em potencial das decisões da ICANN na comunidade global da Internet, comprometidas com o sucesso da ICANN;
3. Pessoas que possam produzir a mais ampla diversidade cultural e geográfica no Conselho, de acordo com os outros critérios definidos nesta seção;
4. Pessoas que, no geral, possuam familiaridade com a operação de registros e registradores de gTLD; com registros de ccTLD; com registros de endereço IP; com padrões e protocolos técnicos da Internet; com procedimentos de desenvolvimento de políticas, tradições legais e interesse público; e com a ampla gama de usuários comerciais, individuais, acadêmicos e não-comerciais da Internet;
5. Pessoas que desejem trabalhar como voluntárias, sem nenhuma remuneração, a não ser o reembolso de algumas despesas; e
6. Pessoas que sejam capazes de trabalhar e se comunicar em inglês falado e escrito.
Seção 4. QUALIFICAÇÕES ADICIONAIS
1. Não obstante algo em contrário neste documento, nenhum oficial de uma entidade do governo nacional ou multinacional estabelecida por tratado ou outro acordo entre governos nacionais pode atuar como um Diretor. Como usado neste documento, o termo "oficial" significa uma pessoa (i) que mantém um cargo governamental eleitoral ou (ii) que é funcionária da entidade governamental ou multinacional e cuja principal função é desenvolver ou influenciar políticas públicas ou governamentais.
2. Nenhuma pessoa que exerça uma função (incluindo a de Contato) em algum Conselho de Organização de Suporte deverá atuar simultaneamente como um Diretor ou Contato para o Conselho. Se esta pessoa aceitar uma nomeação do Conselho de Organização de Suporte para fazer parte de uma seleção para Diretor, ela não deverá, após a nomeação, participar de discussões ou votações do Conselho que sejam relativas à seleção de Diretores, até que o Conselho selecione todos os Diretores que tem responsabilidade de selecionar. Caso alguma pessoa que exerça função em um Conselho de Organização de Suporte aceite uma nomeação para fazer parte de uma seleção para Diretor, o grupo constituinte ou outro grupo ou entidade que tenha selecionado essa pessoa deverá escolher um substituto para participar do processo de seleção do Conselho.
3. Pessoas que exerçam alguma função no Comitê de Nomeação são inelegíveis em seleções para cargos do Conselho, conforme definido no artigo VII, seção 8.
Seção 5. REPRESENTAÇÃO INTERNACIONAL
De forma a assegurar uma ampla representação internacional no Conselho, a seleção de diretores pelo Comitê de Nomeação e por cada Organização de Suporte deverá ser realizada de acordo com todas as provisões de diversidade aplicáveis deste Estatuto, ou de algum Memorando de Entendimento mencionado neste Estatuto, relacionadas à Organização de Suporte. Uma das intenções destas provisões de diversidade é garantir que sempre haja pelo menos um Diretor de cada região geográfica e que nunca uma região tenha mais de cinco diretores no Conselho (excluindo o Presidente). Neste Estatuto, cada item a seguir é considerado uma "região geográfica": Europa; Ásia/Austrália/Pacífico; América Latina/Ilhas do Caribe; África; e América do Norte. Os países específicos em cada região geográfica deverão ser definidos pelo Conselho e esta seção deverá ser revisada pelo Conselho de tempos em tempos (pelo menos a cada três anos) para determinar se alguma alteração é necessária, levando em consideração a evolução da Internet.
Seção 6. CONFLITOS DE INTERESSE DE DIRETORES
Mediante um comitê designado para esse fim, o Conselho deverá exigir que, pelo menos uma vez ao ano, todos os administradores apresentem uma declaração descrevendo todos os negócios e outras afiliações que de alguma maneira estejam relacionadas com as atividades e afiliações da ICANN. Cada Diretor deve ser responsável por informar a ICANN sobre qualquer questão que possa ser considerada para torná-lo um "diretor interessado", de acordo com a seção 5233 da Legislação da organização da Califórnia sem fins lucrativos que visa benefícios públicos ("CNPBCL"). Além disso, cada Diretor deve ser responsável por informar a ICANN sobre quaisquer relações ou outros fatores que possam fazer com que o Diretor possa ser considerado uma "pessoa interessada", de acordo com a seção 5227 da CNPBCL. O Conselho deve adotar políticas relacionadas especificamente aos conflitos de interesse do Diretor, do Administrador e da Organização de Suporte. Nenhum Diretor deverá votar em questões sobre as quais tenha interesse material ou financeiro direto que seria influenciado pelo resultado da votação.
Seção 7. DEVERES DOS DIRETORES
Os diretores devem atuar como indivíduos cujo dever é agir de acordo com o que acreditam ser os interesses da ICANN e não como representantes da entidade que os selecionou, selecionou seus funcionários ou outras organizações ou constituintes.
Seção 8. MANDATOS DE DIRETORES
1. Sujeito ao disposto no Artigo de Transição deste Estatuto, o mandato regular dos Assentos de Diretor de 1 a 14 deve ser iniciado da seguinte forma:
a. O mandato regular dos Assentos 1 a 3 deve começar na conclusão da reunião anual da ICANN de 2003 e a cada reunião anual da ICANN de três em três anos após 2003;
b. O mandato regular dos Assentos 4 a 6 deve começar na conclusão da reunião anual da ICANN de 2004 e a cada reunião anual da ICANN de três em três anos após 2004;
c. O mandato regular dos Assentos 7 e 8 deve começar na conclusão da reunião anual da ICANN de 2005 e a cada reunião anual da ICANN de três em três anos após 2005;
d. O mandato regular dos Assentos 9 e 12 deve começar seis meses após a conclusão da reunião anual da ICANN de 2002 e a cada reunião anual da ICANN de três em três anos após 2002;
e. O mandato regular dos Assentos 10 e 13 deve começar seis meses após a conclusão da reunião anual da ICANN de 2003 e a cada reunião anual da ICANN de três em três anos após 2003; e
f. O mandato regular dos Assentos 11 e 14 deve começar seis meses após a conclusão da reunião anual da ICANN de 2004 e a cada reunião anual da ICANN de três em três anos após 2004.
2. Todo Diretor que ocupa um dos Assentos de 1 a 14, incluindo um Diretor selecionado para ocupar uma vacância, deve exercer seu mandato até que tenha início o mandato seguinte de seu Assento e até que um sucessor tenha sido selecionado e qualificado, ou até que o Diretor renuncie ou seja demitido de acordo com este Estatuto.
3. Pelo menos um mês antes do início de cada reunião anual, o Comitê de Nomeação deve fornecer ao Secretário da ICANN uma notificação por escrito de sua seleção de diretores para assentos com mandatos que se iniciam na conclusão da reunião anual.
4. No máximo cinco meses após a conclusão de cada reunião anual, a Organização de Suporte responsável por selecionar um Diretor para um Assento com mandato a ser iniciado seis meses após a conclusão da reunião anual deverá fornecer ao Secretário da ICANN uma notificação por escrito de sua seleção.
5. Sujeito ao disposto no Artigo de Transição deste Estatuto, nenhum Diretor deverá exercer mais de três mandatos consecutivos. Por esse motivo, uma pessoa selecionada para ocupar uma vacância de um mandato não deverá ser considerada como tendo exercido aquele mandato.
6. O mandato como Diretor de uma pessoa que tenha o cargo de Presidente só poderá existir se essa pessoa tiver o cargo de Presidente.
Seção 9. CONTATOS NÃO-VOTANTES
1. Os contatos não-votantes devem incluir:
a. Um contato indicado pelo Comitê Consultivo Governamental;
b. Um contato indicado pelo Comitê Consultivo de Sistema de Servidor Raiz estabelecido pelo artigo XI deste Estatuto;
c. Um contato indicado pelo Comitê Consultivo de Segurança e Estabilidade estabelecido pelo artigo XI deste Estatuto;
d. Um contato indicado pelo Grupo de Contato Técnico estabelecido pelo artigo XI-A deste Estatuto;
e. Um contato indicado pelo Comitê Consultivo Geral (At-Large) estabelecido pelo artigo XI deste Estatuto; e
f. Um contato indicado pela Força-tarefa para Engenharia da Internet.
2. Sujeito ao disposto no Artigo de Transição deste Estatuto, os contatos não-votantes devem exercer mandatos que se iniciem na conclusão de cada reunião anual. Pelo menos um mês antes do início de cada reunião anual, cada órgão responsável por indicar um contato não-votante deve fornecer ao Secretário da ICANN uma notificação por escrito de sua indicação.
3. Os contatos não-votantes deverão trabalhar como voluntários, sem nenhuma remuneração, a não ser o reembolso de algumas despesas.
4. Cada contato não-votante pode ser indicado novamente e deve permanecer em sua função até que um sucessor seja selecionado ou até que o contato renuncie ou seja demitido de acordo com este Estatuto.
5. Os contatos não-votantes devem participar de reuniões, discussões e deliberações do Conselho e ter acesso (de acordo com as condições estabelecidas pelo Conselho) aos materiais utilizados pelos Diretores nestas ocasiões. No entanto, eles não possuem nenhum dos direitos e privilégios dos diretores. De acordo com esta seção, os contatos não-votantes devem ter o direito (de acordo com as condições estabelecidas pelo Conselho) de usar materiais fornecidos a eles em consultas com seus comitês ou organizações respectivas.
Seção 10. RENÚNCIA DE UM DIRETOR OU CONTATO NÃO-VOTANTE
Sujeito à seção 5226 da CNPBCL, qualquer Diretor ou contato não-votante pode renunciar a qualquer momento, seja oralmente, em uma das reuniões do Conselho (imediatamente seguida de uma notificação por escrito para o Secretário da ICANN), ou através de notificação por escrito para o Presidente ou o Secretário da ICANN. A renúncia deve entrar em vigor no tempo especificado e, a menos que especificado em contrário, a aceitação da renúncia não significa necessariamente que ela entre em vigor. O sucessor deverá ser selecionado de acordo com a seção 12 deste artigo.
Seção 11. DEMISSÃO DE UM DIRETOR OU CONTATO NÃO-VOTANTE
1. Qualquer Diretor pode ser demitido após receber uma notificação e, se selecionado por uma Organização de Suporte, após essa Organização receber uma notificação, pelo voto de maioria de três quartos (3/4) de todos os diretores; desde que, no entanto, o Diretor a ser demitido não vote nesta ação ou seja contado como membro votante do Conselho no cálculo dos três quartos (3/4) necessários da votação; e, contanto que cada voto para demitir um Diretor seja um voto isolado sobre a questão de demissão deste Diretor específico.
2. Com exceção do contato não-votante indicado pelo Comitê Consultivo Governamental, todos os outros contatos podem ser demitidos, após o envio de notificação para o contato e para a organização que o selecionou, pelo voto de maioria de três quartos (3/4) de todos os diretores, se a organização de seleção não demitir imediatamente o contato após a notificação. O Conselho pode solicitar que o Comitê Consultivo Governamental considere a substituição do contato não-votante indicado pelo Comitê, se o Conselho, pelo voto de maioria de três quartos (3/4) de todos os diretores, determinar que esta ação é apropriada.
1. Poderão ocorrer vacâncias no Conselho de Diretores em caso de morte, renúncia ou demissão de algum Diretor; se houver um aumento no número autorizado de diretores; ou se um Diretor for declarado mentalmente incapaz ou for condenado por crime doloso ou preso por mais de 90 dias como resultado de uma condenação criminal, ou for considerado culpado em julgamento por violar um dever das seções 5230 et seq. da CNPBCL. Qualquer vacância no Conselho de Diretores deve ser ocupada pelo Comitê de Nomeação, a menos que (a) o Diretor tenha sido selecionado por uma Organização de Suporte, sendo necessário que a vacância seja preenchida por essa Organização, ou (b) o Diretor fosse o Presidente, sendo necessário preencher a vacância de acordo com as provisões do artigo XIII deste Estatuto. O órgão de seleção deve fornecer notificação por escrito ao Secretário da ICANN de suas indicações para preencher vacâncias. Um Diretor selecionado para preencher uma vacância no Conselho deverá exercer o mandato pendente de seu predecessor no cargo até que um sucessor seja selecionado e qualificado. Nenhuma redução no número autorizado de diretores deverá acarretar na demissão de um Diretor antes do final de seu mandato.
2. As organizações, ao selecionar os contatos não-votantes identificados na seção 9 deste artigo, são responsáveis pela determinação da existência, e pelo preenchimento, de todas as vacâncias nessas posições. Elas devem fornecer notificação por escrito ao secretário da ICANN sobre suas indicações para preencher as vagas.
As reuniões anuais da ICANN devem ser feitas com a finalidade de eleger Executivos e para a transação de outros negócios anteriores à reunião. Cada reunião anual da ICANN deve ser feita no escritório principal da ICANN ou em qualquer outro local apropriado de escolha do Conselho, desde que a reunião anual seja feita dentro de 14 meses da reunião anual imediatamente anterior. Se o Conselho determinar viável, a reunião anual deve ser realizada em tempo real e arquivada em formatos de áudio e vídeo na Internet.
As reuniões regulares do Conselho devem ser feitas em datas a serem determinadas pelo Conselho. Na ausência de outra designação, as reuniões regulares devem ser feitas no escritório principal da ICANN.
As reuniões especiais do Conselho devem ser solicitadas por um quarto (1/4) dos membros do Conselho ou pelo Presidente. Uma solicitação de uma reunião especial deve ser feita pelo secretário da ICANN. Na ausência de outra designação, as reuniões especiais devem ser feitas no escritório principal da ICANN.
Seção 16. NOTIFICAÇÃO DAS REUNIÕES
A notificação de data, hora e local de todas as reuniões devem ser comunicadas pessoalmente ou por telefone ou por e-mail a cada diretor e contato não-votante ou enviada por correio de primeira classe (correio aéreo para endereços fora dos Estados Unidos) ou facsímile, despesas pré-pagas, endereçada a cada diretor e contato não-votante em seus endereços conforme demonstrado nos registros da ICANN. No caso da notificação ser enviada por correio, ela deve ser depositada no correio dos Estados Unidos pelo menos 14 (quatorze) dias antes da data da reunião. No caso da notificação ser feita pessoalmente ou por telefone, facsímile ou e-mail, ela deve ocorrer pelo menos quarenta e oito (48) horas antes da data da reunião. Não obstante a ausência de disposição contrária nesta seção, a notificação de uma reunião não precisa ser feita a nenhum Diretor que tenha assinado uma renúncia à notificação ou fornecido um consentimento por escrito, confirmando a reunião uma aprovação das respectivas atas, seja antes ou depois da reunião, ou a quem participar da reunião sem protestar, antes dela ou em seu início, contra a ausência de notificação. Todas essas renúncias, consentimentos ou aprovações devem ser escritas nos registros corporativos ou nas atas das reuniões.
Nas reuniões anuais, regulares e especiais do Conselho, uma maioria do número total de Diretores em exercício deve constituir um quorum para a transação de negócios, e o ato de uma maioria de Diretores presentes em uma reunião em que há um quorum deverá ser o ato do Conselho, a menos que o contrário seja disposto aqui ou por lei. Se o quorum não estiver presente em qualquer reunião do Conselho, os Diretores presentes poderão adiar a reunião para outro local, data e hora. Se a reunião for adiada por mais de vinte e quatro (24) horas, uma notificação deverá ser entregue aos Diretores ausentes na reunião sobre o adiamento.
Seção 18. AÇÃO POR REUNIÃO POR TELEFONE OU OUTRO EQUIPAMENTO DE COMUNICAÇÃO
Os membros do Conselho ou de qualquer comitê do Conselho podem participar de uma reunião do Conselho ou Comitê do Conselho usando (i) conferência por telefone ou equipamento de comunicação semelhante, desde que todos os Diretores participantes possam falar e ouvir uns aos outros ou (ii) comunicação por tela de vídeo ou outro equipamento de comunicação, desde que (a) todos os Diretores participantes possam falar e ouvir uns aos outros, (b) todos os Diretores sejam providos de meios para participar totalmente de todos os assuntos antes da reunião e (c) a ICANN adote e implemente meios de verificar se (x) uma pessoa participante da reunião é um Diretor ou outra pessoa com direito a participar da reunião e (y) todas as ações, ou votos a favor, do Conselho ou do comitê do Conselho forem aceitos ou rejeitados apenas pelos membros do Conselho ou do comitê e não por pessoas que não sejam membros. A participação em uma reunião desta Seção constitui presença em pessoa em tal reunião. A ICANN deve disponibilizar no local da reunião do Conselho o equipamento de telecomunicação necessário para permitir que os membros do Conselho participem por telefone.
Qualquer ação necessária ou permitida a ser tomada pelo Conselho ou um Comitê do Conselho poderá ser tomada sem uma reunião se todos os Diretores com direito a voto consentirem individualmente ou coletivamente por escrito com tal ação. Esse consentimento por escrito deve ter a mesma força e efeito do voto unânime de tais Diretores. Tal consentimento por escrito deve ser registrado nas atas dos procedimentos do Conselho.
Se permitido pela lei vigente, a comunicação por e-mail deve ser considerada equivalente a qualquer comunicação escrita. A ICANN deve executar as ações apropriadas, de acordo com as circunstâncias, para assegurar-se de que as comunicações por e-mail sejam autênticas.
Seção 21. DIREITOS DE INSPEÇÃO
Cada Diretor terá o direito em qualquer momento razoável de inspecionar e copiar todos os livros, registros e documentos de todos os tipos, bem como de inspecionar as propriedades físicas da ICANN. A ICANN deve estabelecer procedimentos razoáveis para proteger-se de divulgação inapropriada de informações confidenciais.
Os Diretores não devem receber remuneração por seus serviços como Diretores. O Conselho pode, entretanto, autorizar o reembolso de despesas razoáveis reais e necessárias incorridas pelos Diretores e contatos não-votantes no exercício de seus deveres como Diretores ou contatos não-votantes.
Seção 23. PRESUNÇÃO DE CONSENTIMENTO
Um Diretor, presente em uma reunião do Conselho na qual uma ação ou assunto corporativo é tratado, deverá ter seu consentimento presumido em relação à ação tomada, a menos que sua discordância ou abstenção seja registrada nas atas da reunião, ou a menos que tal Diretor preencha, por escrito, uma discordância ou abstenção de tal ação e entregue-a ao secretário da reunião antes de seu término, ou encaminhe tal discordância ou abstenção por carta registrada ao secretário da ICANN imediatamente após o término da reunião. O direito de discordar ou abster-se não deve se aplicar a um Diretor que tenha votado a favor de tal ação.
ARTIGO VII: COMITÊ DE NOMEAÇÃO
Deve haver um Comitê de Nomeação da ICANN responsável pela seleção de todos os Diretores da ICANN, exceto o Presidente e os Diretores selecionados pelas organizações de suporte da ICANN e por outras seleções definidas por este Estatuto.
O Comitê de Nomeação deve ser composto pelas seguintes pessoas:
1. Um Presidente não-votante, apontado pelo Conselho da ICANN;
2. O Presidente do Comitê de Nomeação imediatamente anterior, como um conselheiro não-votante;
3. Um contato não-votante apontado pelo Comitê Consultivo do Sistema de Servidor-Raiz da ICANN estabelecido pelo artigo XI deste Estatuto;
4. Um contato não-votante apontado pelo Comitê Consultivo de Segurança e Estabilidade da ICANN estabelecido pelo artigo XI deste Estatuto;
5. Um contato não-votante apontado pelo Comitê Consultivo Governamental;
6. Sujeito às determinações do Artigo de Transição deste Estatuto, cinco delegados com direito a voto selecionados pelo Comitê Consultivo Geral (At-Large) pelo artigo XI deste Estatuto;
7. Dois delegados com direito a voto, um representando usuários de pequenas empresas e um representando usuários de grandes empresas, selecionados pelo Grupo Constituinte de Usuários de Negócios da Organização de Suporte a estabelecido pelo artigo X deste Estatuto;
8. Um delegado com direito a voto selecionado pelas seguintes entidades:
a. O Grupo Constituinte de Registro gTLD da Organização de Suporte a Nomes Genéricos definido pelo artigo X deste Estatuto;
b. O Grupo Constituinte de Autoridades de Registro gTLD da Organização de Suporte a Nomes Genéricos definido pelo artigo X deste Estatuto;
c. O Conselho da Organização de Suporte a Nomes de Códigos de Países estabelecido pelo artigo IX desse Estatuto;
d. O Grupo Constituinte de Provedores de Serviços de Internet da Organização de Suporte a Nomes Genéricos definido pelo artigo X deste Estatuto;
a. O Grupo Constituinte de Propriedade Intelectual da Organização de Suporte a Nomes Genéricos definido pelo artigo X deste Estatuto;
f. O Conselho da Organização de Suporte de Endereço estabelecido pelo artigo VIII deste Estatuto;
g. Uma entidade designada pelo Conselho representando as organizações acadêmicas e semelhantes;
h. Grupos de consumidores e da sociedade civil, selecionados pelo Grupo Constituinte de Usuários Não-Comerciais da Organização de Suporte a Nomes Genéricos estabelecido pelo artigo X deste Estatuto;
i. A Internet Engineering Task Force e
j. O ICANN Technical Liaison Group estabelecidos pelo artigo XI-A deste Estatuto; e
9. Um Presidente Associado não-votante, que pode ser apontado pelo Presidente, a critério deste, para auxiliar durante todo ou parte do mandato do Presidente. O Presidente Associado não pode ser uma pessoa que já seja membro do mesmo Comitê de Nomeação. O Presidente Associado deve ajudar o Presidente no desempenho de seus deveres, mas não deve assumir, temporária ou eventualmente, o lugar do Presidente.
Sujeito ao disposto no Artigo de Transição deste Estatuto:
1. Cada delegado com direito a voto deve exercer um mandato de um ano. Um delegado pode exercer no máximo dois mandatos de um ano consecutivos; após esses mandatos, devem decorrer pelos menos dois anos antes que ele esteja qualificado para exercer outro mandato.
2. O mandato regular de cada delegado com direito a voto deve começar na conclusão de uma reunião anual da ICANN e terminar na conclusão da reunião anual da ICANN imediatamente seguinte.
3. Os contatos não-votantes devem exercer o mandato designado pela entidade que os nomeou. O Presidente, o Presidente imediatamente anterior com função de conselheiro e qualquer Presidente Associado devem exercer seus mandatos até a conclusão da próxima reunião anual da ICANN.
4. As vacâncias nos cargos de delegado, contato não-votante ou Presidente devem ser preenchidas pela entidade com direito de selecionar o delegado, o contato não-votante ou o Presidente envolvido. Uma vacância no cargo de conselheiro não-votante (Presidente imediatamente anterior) pode ser preenchida pelo Conselho dentre pessoas com serviços anteriores no Conselho ou pelo Comitê de Nomeação. Uma vacância no cargo de Presidente Associado pode ser preenchida pelo Presidente de acordo com os critérios estabelecidos pela seção 2(9) deste artigo.
5. A existência de quaisquer vacâncias não deve afetar a obrigação do Comitê de Nomeação de arcar com as responsabilidades atribuídas a ele por este Estatuto.
Seção 4. CRITÉRIOS DE SELEÇÃO DOS DELEGADOS DO COMITÊ DE NOMEAÇÃO
Os delegados do Comitê de Nomeação da ICANN devem ser:
1. Pessoas com integridade, objetividade e inteligência, com reputação para bom julgamento e mente aberta, e com experiência e competência para tomadas de decisão em grandes grupos colegiados;
2. Pessoas com amplos contatos, larga experiência na comunidade de Internet e comprometidas com o sucesso da ICANN;
3. Pessoas de confiança do corpo de seleção serão amplamente consultadas e aceitarão adições a suas responsabilidades;
4. Pessoas que sejam neutras e objetivas, sem quaisquer compromissos pessoais com indivíduos, organizações e objetivos comerciais particulares no cumprimento de suas responsabilidades no Comitê de Nomeação;
5. Pessoas com compreensão da missão da ICANN e do impacto em potencial das atividades da ICANN na ampla comunidade da Internet que queiram trabalhar como voluntárias, sem remuneração, a não ser o reembolso de determinadas despesas e
6. Pessoas que sejam capazes de trabalhar e se comunicar em inglês falado e escrito.
No cumprimento de suas responsabilidades para selecionar membros do Conselho da ICANN (e seleções de qualquer outro órgão da ICANN pelas quais o Comitê de Nomeação seja responsável de acordo com este Estatuto), o Comitê de Nomeação deve levar em conta a afiliação do Conselho da ICANN (e de outros órgãos) e buscar assegurar que as pessoas selecionadas para preencher as vacâncias no Conselho da ICANN (e de todos os demais órgãos) na medida da viabilidade e consistente com outros critérios necessários a serem aplicados pelo seção 4 deste artigo, façam as seleções orientadas pelo Valor Principal 4 no artigo I, seção 2 .
Seção 6. SUPORTE ADMINISTRATIVO E OPERACIONAL
A ICANN deve fornecer o suporte administrativo e operacional necessário para que o Comitê de Nomeação cumpra suas responsabilidades.
O Comitê de Nomeação deve adotar tais procedimentos de operação conforme necessário, os quais devem ser publicados no site da Web.
Seção 8. INELEGIBILIDADE PARA SELEÇÃO PELO COMITÊ DE NOMEAÇÃO
Nenhuma pessoa que trabalha no Comitê de Nomeação em qualquer capacidade deve ser elegível para, por qualquer meio, qualquer cargo no Conselho ou em qualquer outro órgão da ICANN com uma ou mais posições de afiliação pelas quais o Comitê de Nomeação seja responsável por preencher, até a conclusão da reunião anual da ICANN que coincida com, ou seja posterior, à conclusão do serviço dessa pessoa no Comitê de Nomeação.
Seção 9. INELEGIBILIDADE PARA O SERVIÇO NO COMITÊ DE NOMEAÇÃO
Nenhuma pessoa que seja um funcionário ou consultor pago da ICANN (incluindo o Ombudsman) deve trabalhar simultaneamente em qualquer dos cargos do Comitê de Nomeação descritos na seção 2 deste artigo.
ARTIGO VIII: ORGANIZAÇÃO DE SUPORTE A ENDEREÇOS
1. A Organização de Suporte a Endereços (ASO) deve aconselhar o Conselho a respeito das questões políticas relacionadas à operação, à atribuição e ao gerenciamento de endereços da Internet.
2. A ASO deve ser a entidade estabelecida pelo Memorando de Entendimento firmado em 21 de outubro de 2004 entre a ICANN e a Organização de Recursos de Número (NRO), uma organização dos registros de Internet regionais (RIRs).
Seção 2. CONSELHO DE ENDEREÇOS
1. A ASO deve ter um Conselho de Endereços, consistindo em membros do Conselho de Números NRO.
2. O Conselho de Endereços deve selecionar Diretores para as vagas no Conselho designadas a serem preenchidas pela ASO.
ARTIGO IX: ORGANIZAÇÃO DE SUPORTE A NOMES DE CÓDIGOS DE PAÍSES
Deve haver um órgão de desenvolvimento de políticas conhecido como Organização de Suporte a Nomes de Códigos de Países (ccNSO), que deve ser responsável pelo:
1. desenvolvimento e recomendação ao Conselho de políticas globais relacionadas a domínios de nível superior de códigos de países;
2. Criação de consenso ao longo da comunidade ccNSO, incluindo as atividades relacionadas a nome de ccTLDs; e
3. Coordenação com outras organizações de suporte ICANN, comitês e Grupos Constituintes na ICANN.
Políticas que se aplicam aos membros da ccNSO devido a sua afiliação são apenas aquelas políticas desenvolvidas de acordo com a seção 4.10 e 4.11 deste artigo. Entretanto, a ccNSO pode também se engajar em outras atividades autorizadas por seus membros. A observação dos resultados dessas atividades será voluntária e tais atividades podem incluir: procurar desenvolver voluntariamente as melhores práticas para gerentes ccTLD, ajudando na criação de habilidades dentro da comunidade global dos gerentes ccTLD e aprimorar a cooperação operacional e técnica entre os gerentes ccTLD.
A ccNSO deve consistir em (i) gerentes ccTLD que concordam por escrito em ser membros da ccNSO (consulte a Seção 4(2) deste Artigo) e (ii) um Conselho da ccNSO responsável pelo gerenciamento do processo de desenvolvimento de políticas da ccNSO.
1. O Conselho da ccNSO deve consistir em (a) três membros do Conselho da ccNSO selecionados pelos membros da ccNSO em cada Região Geográfica da ICANN da maneira descrita na Seção 4(7) a (9) deste Artigo; (b) três membros do Conselho da ccNSO selecionados pelo Comitê de Nomeação ICANN; (c) contatos conforme descrito no parágrafo 2 desta seção; e (iv) observadores conforme descrito no parágrafo 3 desta seção.
2. Deve haver também um contato no Conselho da ccNSO de cada uma das seguintes organizações, sendo assim eles escolhem apontar um contato: (a) o Comitê Consultivo Governamental; (b) o Comitê Consultivo Geral (At-Large); e (c) cada uma das organizações regionais descritas na seção 5 deste artigo. Esses contatos não devem ser membros ou ter direito a voto no Conselho da ccNSO, mas devem ter direito a participar em pé de igualdade com membros do Conselho da ccNSO. As indicações de contatos devem ser feitas por notificação por escrito ao secretário da ICANN, com uma cópia da notificação ao Presidente do Conselho da ccNSO e deve ser feita para o mandato designado pela organização indicadora conforme constante na notificação por escrito. A organização indicadora pode oficializar ou substituir seu contato a qualquer momento fornecendo uma notificação por escrito da confirmação ou substituição ao secretário da ICANN, com uma cópia da notificação ao Presidente do Conselho da ccNSO.
3. O Conselho da ccNSO pode concordar com o conselho de qualquer outra organização de suporte ICANN quanto a substituir observadores. Esses observadores não devem ser membros ou ter direito a voto no Conselho da ccNSO, mas devem ter direito a participar em pé de igualdade com os membros do Conselho da ccNSO. O Conselho indicador pode designar seu observador (ou revogar ou alterar a designação de seu observador) no Conselho da ccNSO a qualquer momento fornecendo uma notificação por escrito ao secretário da ICANN, com uma cópia da notificação ao Presidente da ccNSO.
4. Sujeito ao disposto no Artigo de Transição deste Estatuto: (a) o mandato regular de cada membro do Conselho da ccNSO deve começar na conclusão da reunião anual da ICANN e deve terminar na conclusão da terceira reunião anual da ICANN posterior; (b) os mandatos regulares de três membros do Conselho da ccNSO selecionados pelos membros da ccNSO dentro de cada Região Geográfica da ICANN devem ser organizados de modo que o mandato de um membro comece em um ano divisível por três e o mandato do terceiro membro comece no segundo ano seguinte ao ano divisível por três e (c) os mandatos regulares dos três membros do Conselho da ccNSO selecionados pelo Comitê de Nomeação devem ser organizados da mesma maneira. Cada membro do Conselho deverá exercer seu mandato até que um sucessor seja selecionado e qualificado ou até que o membro demita-se ou seja removido de acordo com este Estatuto.
5. Um membro do Conselho da ccNSO pode se demitir a qualquer momento enviando uma notificação por escrito ao secretário da ICANN, com uma cópia da notificação ao Presidente do Conselho da ccNSO.
6. Os membros do Conselho da ccNSO devem ser removidos por não comparecerem a três reuniões consecutivas do Conselho da ccNSO sem motivo suficiente ou por comportamento inapropriado, ambos determinados por, pelo menos, 66% dos votos de todos os membros do Conselho da ccNSO.
7. Uma vacância no Conselho da ccNSO ocorrerá em caso de morte, demissão ou remoção de qualquer membro do Conselho da ccNSO. As vacâncias nos cargos dos três membros selecionados pelo Comitê de Nomeação devem ser preenchidas, pelo tempo remanescente do mandato, pelo Comitê de Nomeação, fornecendo ao secretário da ICANN notificação por escrito da seleção, com uma cópia da notificação para o Presidente do Conselho da ccNSO. Vacâncias nos cargos dos membros do Conselho da ccNSO selecionados por membros da ccNSO devem ser preenchidas pelo tempo remanescente do mandato, conforme procedimento descrito na seção 4(7) a (9) deste artigo.
8. A função do Conselho da ccNSO é administrar e coordenar os assuntos da ccNSO (incluindo coordenação das reuniões, inclusive da reunião anual, dos membros da ccNSO conforme descrito na seção 4(6) deste artigo) e gerenciar o desenvolvimento das recomendações de política de acordo com a seção 6 deste artigo. O Conselho da ccNSO deve também assumir outras funções conforme decisão dos membros da ccNSO de tempos em tempos.
9. O Conselho da ccNSO deve fazer seleções para preencher os lugares 11 e 12 do Conselho por voto escrito ou por ação em uma reunião; qualquer seleção deve ter votos afirmativos de uma maioria de todos os membros do Conselho da ccNSO em exercício. A notificação das seleções do Conselho da ccNSO deve ser dada pelo Presidente do Conselho da ccNSO por escrito ao secretário ICANN, consistente com o artigo VI, seções 8(4) e 12(1).
10. O Conselho da ccNSO deve selecionar dentre seus membros o Presidente do Conselho da ccNSO e seu Vice-presidente conforme apropriado. O Conselho da ccNSO deve fazer seleções para preencher os lugares 11 e 12 do Conselho por voto escrito ou por ação em uma reunião; qualquer seleção deve ter votos afirmativos de uma maioria de todos os membros do Conselho da ccNSO em exercício. O mandato do Presidente do Conselho da ccNSO e de qualquer Vice-presidente deve ser especificado pelo Conselho da ccNSO no momento em que a seleção for feita ou antes. O Presidente do Conselho da ccNSO ou qualquer Vice-presidente pode ser retirado do mandato pelo mesmo procedimento usado para seleção.
11. O Conselho da ccNSO, sujeito à direção dos membros da ccNSO, deve adotar tais regras e procedimentos para a ccNSO conforme necessário, desde que seja consistente com este Estatuto. As regras para afiliação à ccNSO e procedimentos de operação adotados pelo Conselho da ccNSO devem ser publicados no site da Web.
12. Com exceção do disposto nos parágrafos 9 e 10 desta seção, o Conselho da ccNSO deve deliberar nas reuniões. O Conselho da ccNSO deve se reunir regularmente em uma agenda determinada, mas não menos de quatro vezes por ano. A critério do Conselho da ccNSO, as reuniões deve ser feitas em pessoa ou por outros meios, desde que todos os membros do Conselho da ccNSO possam participar por pelo menos um dos meios descritos no parágrafo 14 desta seção. Exceto quando determinado pelo voto da maioria dos membros presentes do Conselho da ccNSO que uma sessão fechada é apropriada, as reuniões físicas devem ser abertas à participação de pessoas interessadas. Na medida do possível, as reuniões do Conselho da ccNSO devem ser feitas em conjunto com as reuniões do Conselho ou de uma ou mais organizações de suporte da ICANN.
13. A notificação de data, hora e local (e informações sobre meios de participação que não pessoais) de todas as reuniões do Conselho da ccNSO deve ser fornecida a cada membro do Conselho da ccNSO, contato e observador por e-mail, telefone, facsímile ou notificação em papel entregue pessoalmente ou por correio. No caso de a notificação ser enviada por correio, ela deve ser enviada, pelo menos, 21 (vinte e um) dias antes da data da reunião. No caso de a notificação ser entregue pessoalmente ou por telefone, facsímile ou e-mail, ela deve ocorrer, pelo menos, sete dias antes da data da reunião. Pelo menos sete dias antes de cada reunião do Conselho da ccNSO (se isso não for possível, com o máximo de antecedência possível), uma notificação sobre a reunião, bem como sua programação, deverão ser postadas.
14. Os membros do Conselho da ccNSO devem participar de uma reunião do Conselho da ccNSO por meio de participação pessoal ou uso de comunicação eletrônica (como telefone ou videoconferência), desde que (a) todos os membros do Conselho da ccNSO participantes possam falar e ouvir uns aos outros, (b) todos os membros do Conselho da ccNSO participantes da reunião sejam providos de meios para participar de forma integral de todos os assuntos, antes do Conselho da ccNSO e (c) haja meios razoáveis de verificar a identidade dos membros do Conselho da ccNSO participantes da reunião e seus votos. A maioria dos membros do Conselho da ccNSO (ou seja, aqueles com direito a voto) em exercício deve constituir um quorum para a transação de negócios, e as ações pelo voto da maioria dos membros do Conselho da ccNSO presentes em qualquer reunião em que haja quorum serão ações do Conselho da ccNSO, a menos que haja disposição contrária neste Estatuto. O Conselho da ccNSO deve transmitir as atas de suas reuniões ao secretário da ICANN, que deve fazer com que essas atas sejam inseridas no site da Web o mais breve possível após a reunião, e não mais que 21 dias após a reunião.
1. A ccNSO deve ter uma afiliação constituída por gerentes ccTLD. Qualquer gerente ccTLD que atenda às qualificações de afiliação dispostas no parágrafo 2 desta seção deve ter o direito de ser membro da ccNSO. Para fins deste artigo, um gerente ccTLD é a organização ou a entidade responsável pelo gerenciamento do domínio de nível superior de código de país ISSO 3166 e mencionado no banco de dados IANA como "Organização Patrocinadora", ou qualquer variação posterior, do domínio de nível superior de código de país.
2. Qualquer gerente ccTLD pode tornar-se um membro da ccNSO enviando uma candidatura a uma pessoa designada pelo Conselho da ccNSO para receber candidaturas. Sujeita às determinações do Artigo de Transição deste Estatuto, a solicitação deve ser por escrito em um formulário designado pelo Conselho da ccNSO. A solicitação deve incluir o reconhecimento pelo gerente ccTLD da função da ccNSO dentro da estrutura da ICANN bem como da concordância do gerente ccTLD, durante sua afiliação à ccNSO, de (a) observar as regras da ccNSO, incluindo as regras de afiliação, (b) obedecer às políticas desenvolvidas e recomendadas pela ccNSO e adotadas pelo Conselho na maneira descrita pelos parágrafos 10 e 11 desta seção e (c) pagar as taxas de afiliação da ccNSO estabelecidas pelo Conselho da ccNSO na seção 7(3) deste artigo. Um membro do Conselho da ccNSO pode se demitir a qualquer momento enviando uma notificação por escrito ao secretário da ICANN, com uma cópia da notificação ao Presidente do Conselho da ccNSO. Com a demissão do gerente TLD extingue-se a concordância em (a) observar as regras da ccNSO, incluindo as regras de afiliação, (b) obedecer às políticas desenvolvidas e recomendadas pela ccNSO e adotadas pelo Conselho na maneira descrita pelos parágrafos 10 e 11 desta Seção e (c) pagar as taxas de afiliação da ccNSO estabelecidas pelo Conselho da ccNSO na Seção 7(3) deste Artigo. Na ausência de designação pelo Conselho da ccNSO de uma pessoa para receber candidaturas e notificações de demissão, essas devem ser enviadas ao secretário da ICANN, que notificará o Conselho da ccNSO do recebimento de tais candidaturas e notificações.
3. Nem a afiliação à ccNSO nem a afiliação a qualquer organização regional descrita na seção 5 deste artigo deve ser uma condição de acesso ou registro no banco de dados IANA. Nenhum relacionamento individual de um gerente ccTLD com a ICANN ou recebimento de serviços IANA pelo gerente ccTLD não constituem de forma alguma um contingente na afiliação à ccNSO.
4. As regiões geográficas de ccTLDs devem ser descritas no artigo VI, seção 5 deste Estatuto. Para fins deste artigo, os gerentes ccTLDs em uma região geográfica que sejam membros da ccNSO são mencionados como membros da ccNSO “dentro” da região geográfica, independentemente do local físico do gerente ccTLD. Nos casos em que a região geográfica de um membro da ccNSO não esteja clara, o membro ccTLD deverá selecioná-la, de acordo com os procedimentos adotados pelo Conselho da ccNSO.
5. Cada gerente ccTLD pode designar por escrito uma pessoa, organização ou entidade para representá-lo. Na ausência de tal designação, o gerente ccTLD deve ser representado pela pessoa, organização ou entidade listada como contato administrativo no banco de dados IANA.
6. Haverá uma reunião anual dos membros da ccNSO, coordenada pelo Conselho da ccNSO. As reuniões anuais devem ser abertas à participação de todos, e uma oportunidade razoável de participar da reunião deve ser oferecida aos gerentes ccTLD que não sejam membros da ccNSO, bem como a outros não-membros da ccNSO. Na medida do possível, as reuniões anuais dos membros da ccNSO devem ser feitas em pessoa e em conjunto com as reuniões do Conselho ou de uma ou mais organizações de suporte da ICANN.
7. Os membros do Conselho da ccNSO selecionados pelos membros da ccNSO de cada região geográfica (consulte a seção 3(1)(a) deste artigo) devem ser selecionados por nomeação e, se necessário, eleição, pelos membros da ccNSO dentro da região geográfica. Pelo menos 90 dias antes do término do mandato regular de qualquer membro selecionado por um membro da ccNSO do Conselho da ccNSO ou na ocorrência de vacância do lugar de tal membro do Conselho da ccNSO, o Conselho da ccNSO deve estabelecer uma agenda de nomeação e eleição, que será enviada a todos os membros da ccNSO dentro da região geográfica do site da Web.
8. Qualquer membro da ccNSO pode nomear um indivíduo para trabalhar como membro do Conselho da ccNSO representando a região geográfica do membro da ccNSO. As nomeações devem ser apoiadas por outro membro da ccNSO da mesma região geográfica. Aceitando a nomeação, os indivíduos nomeados ao Conselho da ccNSO concordam em apoiar as políticas assumidas pelos membros da ccNSO.
9. Se no encerramento das nomeações não houver mais candidatos nomeados (com apoios e aceitações) em uma determinada região geográfica que lugares disponíveis no Conselho da ccNSO da região geográfica, os candidatos nomeados serão selecionados para trabalhar no Conselho da ccNSO. Caso contrário, uma eleição por voto escrito (que pode ser por e-mail) deve ser feita para selecionar os membros do Conselho da ccNSO dentre os nomeados (com apoios e aceitações), com os membros da ccNSO da região geográfica tendo direito a voto na eleição por meio de seus representantes designados. Nessa eleição, a maioria de todos os membros da ccNSO na região geográfica com direito a voto devem constituir um quorum, e o candidato selecionado deve receber os votos da maioria dos membros da ccNSO na região geográfica. O Presidente do Conselho da ccNSO deve fornecer ao secretário da ICANN uma notificação por escrito da seleção dos membros do Conselho da ccNSO de acordo com este parágrafo.
10. De acordo com a cláusula 4(11), as políticas da ICANN devem se aplicar aos membros da ccNSO apenas na medida de sua afiliação, sendo que as políticas (a) apenas tratam de questões dentro do escopo da ccNSO, de acordo com o artigo IX, seção 6 e anexo C; (b) foram desenvolvidas por meio do ccPDP, conforme descrito na seção 6 deste artigo, e (c) foram recomendadas pela ccNSO ao Conselho e (d) são adotadas pelo Conselho como políticas, desde que essas políticas não estejam em conflito com a lei aplicável ao gerente ccTLD que, sempre, permanecerá soberana. Além disso, tais políticas devem se aplicar à ICANN em suas atividades relacionadas a ccTLDs.
11. Um membro da ccNSO não estará obrigado se fornecer uma declaração ao Conselho da ccNSO atestando que (a) a implementação da política requer que o membro desrespeite uma política pessoal, religiosa ou pública (não amparada na lei vigente descrita no parágrafo 10 desta seção) e (b) a falha na implementação da política não prejudica as operações DNS ou a interoperabilidade, fornecendo motivos detalhados que fundamentem suas declarações. Após investigação, o Conselho da ccNSO fornecerá uma resposta à declaração do membro da ccNSO. Se houver um consenso do Conselho da ccNSO discordando da declaração, o que pode ser demonstrado pelo voto de 14 ou mais membros do Conselho da ccNSO, a resposta atestará a discordância do Conselho da ccNSO com a declaração e os motivos da discordância. Caso contrário, a resposta atestará a concordância do Conselho da ccNSO com a declaração. Se o Conselho da ccNSO discordar, a situação será revista após um período de seis meses. Ao término desse período, o Conselho da ccNSO decidirá se (a) a implementação da política dos membros da ccNSO requer que o membro desrespeite uma política pessoal, religiosa ou pública (não amparada na lei vigente descrita no parágrafo 10 desta seção) e (b) se a falha na implementação da política prejudica operações DNS ou a interoperabilidade. Decidindo discordar da declaração, o Conselho da ccNSO procederá por consenso, o que pode ser demonstrado pelo voto de 14 ou mais membros do Conselho da ccNSO.
Seção 5. ORGANIZAÇÕES REGIONAIS
O Conselho da ccNSO pode designar uma organização regional para cada região geográfica ICANN, desde que a organização regional esteja aberta a afiliação total a todos os membros da ccNSO dentro da região geográfica. As decisões para designar ou remover a designação de uma organização regional requer 66% dos votos de todos os membros do Conselho da ccNSO e devem estar sujeitas à revisão de acordo com os procedimentos estabelecidos pelo Conselho.
Seção 6. PROCESSO E ESCOPO DE DESENVOLVIMENTO DE POLÍTICAS ccNSO
1. O escopo da função de desenvolvimento de políticas ccNSO deve ser declarado no Anexo C deste Estatuto; quaisquer modificações no escopo devem ser recomendadas ao Conselho pela ccNSO por uso dos procedimentos de ccPDP e devem estar sujeitos a aprovação do Conselho.
2. Ao desenvolver políticas globais dentro do escopo da ccNSO e recomendá-las ao Conselho, a ccNSO deve seguir o processo de desenvolvimento de políticas ccNSO(ccPDP). O ccPDP deve ser conforme o disposto no Anexo B deste Estatuto; modificações devem ser recomendadas ao Conselho pela ccNSO por uso dos procedimentos de ccPDP e devem estar sujeitas à aprovação do Conselho.
Seção 7. SUPORTE E FINANCIAMENTO DA EQUIPE
1. Sob solicitação do Conselho da ccNSO, um membro da equipe da ICANN pode ser atribuído para apoiar a ccNSO e deve ser designado como gerente de pessoal ccNSO. Como alternativa, o Conselho da ccNSO pode designar, às custas da ccNSO, outra pessoa para trabalhar como gerente de pessoal da ccNSO. O trabalho do gerente de pessoal da ccNSO em assuntos importantes deve ser atribuído pelo Presidente do Conselho da ccNSO e pode incluir os deveres do gerente de emissão ccPDP.
2. Sob solicitação do Conselho da ccNSO, a ICANN deve fornecer suporte administrativo e operacional necessários para que a ccNSO cumpra suas responsabilidades. Tal suporte não deve incluir uma obrigação da ICANN de custear despesas incorridas por participantes da ccNSO quanto a viagens a qualquer reunião da ccNSO ou para qualquer outra finalidade. O Conselho da ccNSO deve fazer uma provisão, às custas da ccNSO, para suporte administrativo e operacional em adição ou como uma alternativa ao suporte fornecido pela ICANN.
3. O Conselho da ccNSO deve estabelecer taxas a serem pagas pelos membros da ccNSO para custear despesas da ccNSO conforme descrito nos parágrafos 1 e 2 desta seção, conforme aprovado pelos membros da ccNSO.
4. Notificações por escrito fornecidas ao secretário da ICANN sob este artigo devem ser mantidas permanentemente e devem ser disponibilizadas para análise do Conselho da ccNSO por solicitação. O secretário da ICANN deve também manter a lista de membros da ccNSO, que deve incluir o nome de cada representante designado pelo gerente ccTLD e deve ser publicada no site da Web.
ARTIGO X: ORGANIZAÇÃO DE SUPORTE A NOMES GENÉRICOS
Haverá um órgão de desenvolvimento de políticas conhecido como Organização de Suporte a Nomes Genéricos (GNSO), que deve ser responsável pelo desenvolvimento e recomendação ao Conselho da ICANN de políticas importantes relacionadas a domínios de nível superior genéricos.
A GNSO deve consistir de (i) vários Grupos Constituintes representando grupos particulares de interessados, conforme descrito na seção 5 deste artigo e (ii) um Conselho da GNSO responsável pelo gerenciamento do processo de desenvolvimento de políticas da GNSO.
1. Sujeito ao disposto no Artigo de Transição deste Estatuto, o Conselho da GNSO deve consistir de três representantes selecionados por cada Grupo Constituinte descrito na seção 5 deste artigo, e três pessoas selecionadas pelo Comitê de Nomeação ICANN. Não deve haver dois representantes selecionados por um Grupo Constituinte que sejam cidadãos do mesmo país ou países localizados na mesma região geográfica. Deve haver dois contatos do Conselho da GNSO, indicados pelo Comitê Consultivo Governamental e pelo Comitê Consultivo Geral (At-Large) de tempos em tempos, que não devem ser membros ou ter direito a voto no Conselho da GNSO, mas devem ter direito a participar em pé de igualdade com os membros do Conselho da GNSO. O Comitê Consultivo deve designar seu contato (ou revogar ou altera a designação de seu contato) no Conselho da GNSO fornecendo notificação por escrito ao Presidente do Conselho da GNSO e ao secretário da ICANN. O Conselho da GNSO pode também ter observadores conforme descrito no parágrafo 9 desta seção.
2. Sujeito ao disposto no Artigo de Transição deste Estatuto: (a) o mandato regular de cada membro do Conselho da GNSO deve começar na conclusão da reunião anual da ICANN e deve terminar na conclusão da segunda reunião anual da ICANN posterior; (b) o mandato regular de um representante selecionado por cada Grupo Constituinte começará em um ano par e o mandato regular de outro representante selecionado pelo Grupo Constituinte começará em um ano ímpar; e (c) o mandato regular de um dos três membros selecionados pelo Comitê de Nomeação começará em anos pares e o mandato regular de dois dos três membros selecionados pelo Comitê de Nomeação começarão em anos ímpares. Cada membro do Conselho da GNSO deverá exercer seu mandato até que um sucessor seja selecionado e qualificado ou até que o membro demita-se ou seja removido de acordo com este Estatuto.
3. Um membro do Conselho da GNSO pode se demitir a qualquer momento enviando uma notificação por escrito ao secretário da ICANN. Um membro do Conselho da GNSO selecionado por um Grupo Constituinte pode ser removido por esse Grupo Constituinte de acordo com os procedimentos publicados. Um membro do Conselho da GNSO selecionado pelo Comitê de Nomeação pode ser removido por motivo declarado por três quartos (3/4) dos votos (consulte Seção 5(2) deste artigo) de todos os membros do Conselho da GNSO (excluindo o membro a ser removido), sujeito à aprovação do Conselho da ICANN. Uma vacância no Conselho da ccNSO deve ser avaliada em caso de morte, demissão ou remoção de qualquer membro do Conselho da ccNSO. As vacâncias devem ser preenchidas por mandato não expirado envolvido pelo Comitê de Nomeação enviando ao secretário da ICANN notificação por escrito da seleção, a menos que o membro que ocupava o cargo antes da ocorrência da vacância tenha sido selecionado por um Grupo Constituinte, caso em que o Grupo Constituinte deve preencher o mandato não expirado enviando ao secretário da ICANN notificação por escrito da seleção.
4. O Conselho da GNSO é responsável pelo gerenciamento do processo de desenvolvimento de políticas da GNSO. Ele deve adotar tais procedimentos conforme adequado para cuidar dessa responsabilidade, desde que tais procedimentos sejam aprovados pelo Conselho e também desde que, até que qualquer modificação seja recomendada pelo Conselho da GNSO e aprovada pelo Conselho, os procedimentos aplicáveis devem ser os definidos na seção 6 deste artigo. Além disso, o Conselho da GNSO é responsável pelo gerenciamento de fóruns abertos, na forma de listas de correspondência ou da participação de todos que desejem contribuir com o trabalho da GNSO; tais fóruns devem ser moderados apropriadamente para garantir foco máximo nos objetivos da GNSO e para minimizar publicações sem conteúdo e abusivas.
5. Não mais do que um executivo, diretor ou funcionário de qualquer empresa ou organização (incluindo suas subsidiárias e afiliadas) deve trabalhar no Conselho da GNSO em um determinado momento.
6. O Conselho da GNSO deve fazer seleções para preencher os Assentos 13 e 14 do Conselho da ICANN por voto escrito ou por ação em uma reunião; qualquer seleção deve ter votos afirmativos de uma maioria de todos os membros do Conselho da GNSO. A notificação das seleções do Conselho da GNSO deve ser dada pelo Presidente da GNSO por escrito ao secretário ICANN, de acordo com o artigo VI, seções8(4) e 12(1).
7. O Conselho da GNSO deve selecionar seu Presidente para um mandato não superior a um ano, por voto escrito ou por ação em uma reunião. Qualquer seleção desse tipo deve ter votos afirmativos compreendendo a maioria dos votos de todos os membros do Conselho da GNSO.
8. Com exceção do disposto no parágrafo 6 desta seção, o Conselho da GNSO deve deliberar nas reuniões. Os membros do Conselho da GNSO podem participar de uma reunião do Conselho da GNSO usando (i) conferência por telefone ou equipamento de comunicação semelhante, desde que todos os Diretores participantes possam falar e ouvir uns aos outros ou (ii) comunicação por tela de vídeo ou outro equipamento de comunicação, desde que (a) todos os Diretores participantes possam falar e ouvir uns aos outros, (b) todos os Diretores sejam providos dos meios para participar totalmente de todos os assuntos antes do Conselho da GNSO e (c) a ICANN adote e implemente meios de verificar se (x) uma pessoa participando da reunião é um membro do Conselho da GNSO ou outra pessoa com direito a participar dessa reunião e (y) todas as ações de, ou votos a favor, do Conselho da GNSO forem aceitos ou rejeitados apenas pelos membros do Conselho da GNSO, e não por pessoas que não sejam membros. Membros qualificados para formar uma maioria do número total de votos de membros do Conselho da GNSO em exercício deverão constituir um quorum para a transação de negócios, e atos por meio de um voto majoritário dos membros do Conselho da GNSO presentes em qualquer reunião em que houver um quorum deverão ser atos do Conselho da GNSO, salvo quando especificado em contrário neste documento. (Consulte seção 5(2) deste artigo a respeito no número de votos que os membros do Conselho da GNSO podem efetuar.) Notificação antecipada de tais reuniões devem ser publicadas no site da Web, se razoavelmente possível, pelo menos 7 dias antes da reunião. Exceto quando determinado pelos votos da maioria (consulte seção 5(2) deste artigo) dos membros do Conselho da GNSO presentes que uma sessão fechada é apropriada, as reuniões devem ser abertas à participação física ou eletrônica de todas as pessoas interessadas. O Conselho da GNSO deve transmitir as atas de suas reuniões ao secretário da ICANN, que deve fazer com que essas atas sejam inseridas no site da Web o mais breve possível após a reunião, e não mais que 21 dias após a reunião.
9. O Conselho da GNSO pode concordar com o conselho de qualquer outra organização de suporte da ICANN quanto à troca de observadores. Esses observadores não devem ser membros ou ter direito a voto no Conselho da GNSO, mas devem ter direito a participar em pé de igualdade com os membros do Conselho da GNSO. O Comitê deve designar seu observador (ou revogar ou alterar a designação de seu observador) no Conselho da GNSO fornecendo notificação por escrito ao Presidente do Conselho da GNSO e ao secretário da ICANN.
Seção 4. SUPORTE E FINANCIAMENTO DA EQUIPE
1. Um membro da equipe da ICANN deve ser atribuído para apoiar a GNSO, cujo trabalho em assuntos importantes deve ser atribuído ao Presidente do Conselho da GNSO e deve ser designado como o gerente de pessoal GNSO (gerente de pessoal).
2. A ICANN deve fornecer o suporte administrativo e operacional necessário para que a GNSO cumpra suas responsabilidades. Tal suporte não deve incluir uma obrigação da ICANN de custear despesas incorridas por participantes da GNSO quanto a viagens a qualquer reunião da GNSO ou para qualquer outra finalidade.
1. Os Grupos Constituintes auto-organizados a seguir são reconhecidos, por meio deste, como representantes de um grupo específico e significativo de acionistas e estão sujeitos às disposições do Artigo de Transição deste Estatuto.Cada Grupo Constituinte deve selecionar dois representantes para o Conselho da GNSO:
a. Registros de gTLD (representando todos os registros de gTLD sob contrato da ICANN);
b. Registradores (representando todos os registradores acreditados sob contrato da ICANN);
c. Provedores de serviços e conectividade com a Internet (representando todas as entidades que fornecem serviço e conectividade a usuários da Internet);
d. Usuários comerciais e de negócios (representando usuários de grandes e pequenas entidades comerciais da Internet);
e. Usuários não comerciais (representando todo o conjunto de usuários de entidades não comerciais da Internet) e
f. Os interesses de propriedade intelectual (representando o conjunto completo de marcas registradas e outros interesses de propriedade intelectual relacionados a DNS).
2. O número de votos que os membros do Conselho da GNSO podem efetuar deve ser equalizado para que o número de votos dos representantes selecionados pelos Grupos Constituintes (atualmente registradores e registros de gTLD) sob contrato com a ICANN, com a imposição de implementar as políticas adotadas pela ICANN, seja igual ao número de votos de representantes selecionados por outros Grupos Constituintes. Inicialmente, cada membro do Conselho da GNSO selecionado pelo Grupo Constituinte de registros de gTLD ou registradores deve ter direito a efetuar dois votos e todos os demais membros (incluindo os selecionados pelo Comitê de Nomeação) devem ter direito a efetuar um voto. No caso de haver uma mudança nos Grupos Constituintes com direito a selecionar membros com direito a voto do Conselho da GNSO, o Conselho deve rever a alteração nas circunstâncias e, por resolução, revisar o procedimento para igualdade de votos de uma maneira consistente com o parágrafo 2.
3. Cada Grupo Constituinte identificado no parágrafo 1 desta seção deve manter seu reconhecimento e, também, sua habilidade em selecionar representantes do Conselho da GNSO, apenas até quando de fato representarem os interesses globais das comunidades de interessados e deve funcionar com o máximo possível de maneira aberta e transparente e consistente com os procedimentos designados para assegurar justiça. Nenhum indivíduo ou entidade deve ser excluído da participação de um Grupo Constituinte meramente por participar de outro Grupo Constituinte.
4. Qualquer grupo de indivíduos ou entidades pode enviar uma petição ao Conselho para reconhecimento como um Grupo Constituinte novo ou independente. Qualquer petição deve conter uma explicação detalhada de:
a. Por que a adição de tal Grupo Constituinte melhorará a habilidade da GNSO em cumprir suas responsabilidades de desenvolvimento de políticas e
b. Por que o novo Grupo Constituinte proposto representaria adequadamente, de uma maneira global, os acionistas que busca representar.
Qualquer petição para o reconhecimento de um novo Grupo Constituinte deve ser publicada para comentário público.
5. O Conselho pode criar novos Grupos Constituintes em resposta a tal petição, ou por conta própria, se determinar que tal ação serve aos propósitos da ICANN. No caso de o Conselho estar considerando agir por conta própria, ela deve publicar uma explicação detalhada de por que tal ação é necessária ou desejável, definir um tempo razoável para comentários públicos e não tomar uma decisão final sobre o assunto até analisar todos os comentários recebidos. Se o Conselho publicar uma petição ou recomendação de um novo Grupo Constituinte para comentários públicos, ele deve notificar o Conselho da GNSO e considerar qualquer resposta a essa notificação antes de executar a ação.
Seção 6. PROCESSO DE DESENVOLVIMENTO DE POLÍTICAS
Inicialmente, os procedimentos de desenvolvimento de políticas a serem seguidos pela GNSO deve ser os constantes no Anexo A deste Estatuto. Esses procedimentos devem ser complementados ou revisados da maneira disposta na seção 3(4) deste artigo.
ARTIGO XI: COMITÊS CONSULTIVOS
O Conselho pode criar um ou mais Comitês Consultivos além dos definidos neste artigo. A afiliação ao Comitê Consultivo pode consistir em somente Diretores, Diretores e não-diretores ou somente não-diretores e pode também incluir membros não-votantes ou membros alternativos. Os Comitês Consultivos não devem possuir autoridade legal para atuar em nome da ICANN, porém devem encaminhar suas conclusões e recomendações ao Conselho da ICANN.
Seção 2. COMITÊS CONSULTIVOS ESPECÍFICOS
Haverá, pelo menos, os seguintes Comitês Consultivos:
1. Comitê Consultivo Governamental
a. O Comitê Consultivo Governamental deve considerar e aconselhar sobre as atividades da ICANN relacionadas aos assuntos governamentais, principalmente aqueles que podem ter uma interação com as políticas da ICANN e várias leis e acordos internacionais ou que podem afetar políticas públicas.
b. A afiliação ao Comitê Consultivo Governamental deve estar aberta a todos os governos nacionais. A afiliação também deve estar aberta a economias distintas, conforme reconhecidas em fóruns internacionais e organizações governamentais multinacionais e organizações de tratados no convite do Comitê Consultivo Governamental por meio de seu Presidente.
c. O Comitê Consultivo Governamental pode adotar seu próprio regulamento e princípios internos ou procedimentos de funcionamento para dirigir suas operações, a serem publicados no site da Web.
d. O Presidente do Comitê Consultivo Governamental deve ser eleito pelos membros do Comitê Consultivo Governamental de acordo com os procedimentos adotados por tais membros.
e. Cada membro do Comitê Consultivo Governamental deve indicar um representante acreditado pelo Comitê. O representante acreditado de um membro deve manter uma posição oficial formal com a administração pública do membro. O termo “oficial” inclui uma pessoa que mantém um cargo governamental eleitoral, ou seja funcionária de autoridade pública governamental ou multinacional, ou uma organização de tratado, cuja principal função seja desenvolver ou influenciar políticas públicas ou governamentais.
f. O Comitê Consultivo Governamental deve indicar anualmente um contato não-votante ao Conselho da ICANN, sem limitação de nova indicação, e deve indicar anualmente um contato não-votante ao Comitê de Nomeação da ICANN.
g. O Comitê Consultivo Governamental pode designar um contato não-votante para cada Conselho de Organização de Suporte e Comitê Consultivo, na medida em que o Comitê Consultivo Governamental considere apropriado e útil.
h. O Conselho deve notificar o Presidente do Comitê Consultivo Governamental oportunamente sobre qualquer proposta que interfira na política pública sobre a qual ela ou qualquer organização de suporte da ICANN ou comitê consultivo procure comentários públicos e deve levar em conta qualquer resposta oportuna a essa notificação antes de executar alguma ação.
i. O Comitê Consultivo Governamental pode enviar questões ao Conselho diretamente, por comentário ou conselho ou por recomendação específica de ação ou novo desenvolvimento de política ou revisão das políticas existentes.
j. O conselho do Comitê Consultivo Governamental sobre assuntos de política pública deve ser devidamente levado em conta, tanto na formulação quanto na adoção de políticas. No caso de o Conselho da ICANN decidir executar uma ação que não seja consistente com a opinião do Comitê Consultivo Governamental, ele deverá informar o Comitê e declarar os motivos pelos quais decidiu não seguir referida opinião. O Comitê Consultivo Governamental e o Conselho da ICANN tentarão, assim, de boa fé e de uma maneira oportuna e eficiente, encontrar uma solução de aceitação mútua.
k. Se tal solução não puder ser encontrada, o Conselho da ICANN declarará em sua decisão final os motivos pelos quais o conselho do Comitê Consultivo Governamental não foi seguido e tal declaração não prejudicará os direitos ou obrigações dos membros do Comitê Consultivo Governamental a respeito de questões de políticas públicas de sua responsabilidade.
2. Comitê Consultivo para Segurança e Estabilidade
a. A função do Comitê Consultivo para Segurança e Estabilidade (“SAC”) é aconselhar a comunidade e o Conselho da ICANN sobre assuntos relacionados a segurança e integridade dos sistemas de alocação de endereços e nomes da Internet. Ele tem as seguintes responsabilidades:
1. Desenvolver uma estrutura de segurança para serviços de alocação de nomes e endereços da Internet que defina as áreas de foco principais e identifique onde as responsabilidades de cada área estão. O comitê deve focalizar as considerações operacionais da infra-estrutura de nomes crítica.
2. Comunicar-se sobre assuntos de segurança com a comunidade técnica da Internet e os operadores e gerentes de serviços de infra-estrutura DNS crítica, para incluir a comunidade do operador do servidor de nome-raiz, os registros e registradores de domínio de nível superior, os operadores das árvores de delegação reversa, como in-addr.arpa and ip6.arpa, e outros como eventos e desenvolvimentos. O Comitê deve reunir e articular requerimentos a serem oferecidos aos engajados na revisão técnica dos protocolos relacionados a DNS e alocação de endereços aos engajados no planejamento de operações.
3. Engajar-se na avaliação constante de ameaças e análise de riscos da alocação de endereços e nomes da Internet para avaliar onde estão as principais ameaças à estabilidade e segurança e para aconselhar a comunidade ICANN apropriadamente. O Comitê deve recomendar qualquer atividade de auditoria necessária para avaliar o status atual da segurança de alocação de endereços e DNS em relação à identificação de riscos e ameaças.
4. Comunicar-se com aqueles que tenham responsabilidade direta por assuntos de segurança de alocação de nomes e endereços da Internet (IETF, RSSAC, RIRs, registros de nomes etc.), para assegurar que seu conselho sobre riscos, questões e prioridades de segurança estejam apropriadamente sincronizados com as atividades de padronização, implementação, operacionais e de coordenação existentes. O Comitê deve monitorar essas atividades e informar a comunidade e o Conselho da ICANN sobre seu andamento, conforme apropriado.
5. Reportar periodicamente suas atividades ao Conselho.
6. Fazer recomendações de políticas à comunidade e ao Conselho da ICANN.
b. O Presidente e membros do SAC devem ser indicados pelo Conselho.
c. O SAC deve indicar anualmente um contato não-votante ao Conselho da ICANN de acordo com a seção 9 do artigo VI.
3. Comitê Consultivo para o Sistema de Servidor-Raiz
a. A função do Comitê Consultivo para o Sistema de Servidor-Raiz ("RSSAC") deve aconselhar o Conselho sobre a operação de servidores de nome raiz do sistema de nomes de domínio. O RSSAC deve considerar e oferecer conselhos sobre os requisitos operacionais de servidores de nomes de raiz, incluindo as capacidades de hardware de host, sistemas operacionais e versões de software de servidor de nome, conectividade de rede e ambiente físico. O RSSAC deve examinar e aconselhar sobre aspectos de segurança do sistema de servidor de nomes de raiz. Além disso, o RSSAC deve analisar o número, local e distribuição de servidores de nome de raiz considerando o desempenho, robustez e confiabilidade total do sistema.
b. A afiliação ao RSSAC deve consistir em (i) cada operador de um servidor de nome de raiz autorizado (conforme listado em <> ) e (ii) outras pessoas indicadas pelo Conselho da ICANN.>
c. O Presidente inicial do Comitê Consultivo do Sistema de Servidor-Raiz DNS deve ser indicado pelo Conselho; os Presidentes subseqüentes devem ser eleitos pelos membros do Comitê Consultivo do Sistema de Servidor-Raiz DNS de acordo com os procedimentos adotados pelos membros.
f. O Comitê Consultivo do Sistema de Servidor-Raiz deve indicar anualmente um contato não-votante ao Conselho da ICANN, sem limitação de nova indicação e deve indicar anualmente um contato não-votante ao Comitê de Nomeação da ICANN.
4. Comitê Consultivo Geral (At-Large)
a. A função do Comitê Consultivo Geral At-Large (ALAC) deve ser considerar e aconselhar sobre atividades da ICANN no que se refere a interesses de usuários individuais da Internet.
b. O ALAC consiste em (i) dois membros selecionados por cada uma das Organizações Gerais Regionais (“RALOs”) definidas de acordo com o parágrafo 4(g) desta seção, e (ii) cinco membros selecionados pelo Comitê de Nomeação. Os cinco membros selecionados pelo Comitê de Nomeação devem incluir um cidadão de um país de cada uma das cinco regiões geográficas definidas de acordo com a seção 5 do artigo VI.
c. Sujeito ao disposto no Artigo de Transição deste Estatuto, os mandatos regulares dos membros do ALAC devem ser os seguintes:
1. O mandato de um membro selecionado por cada RALO deve começar na conclusão de uma reunião anual da ICANN em um ano de número par.
2. O mandato de outro membro selecionado por cada RALO deve começar na conclusão de uma reunião anual da ICANN em um ano de número ímpar.
3. Os mandatos dos três membros selecionados pelo Comitê de Nomeação devem começar na conclusão de uma reunião anual em um ano de número ímpar e os mandatos dos outros dois membros selecionados pelo Comitê de Nomeação devem começar na conclusão de uma reunião anual em um ano de número par.
4. O mandato regular de cada membro deve terminar na conclusão da segunda reunião anual da ICANN após o início do mandato.
d. O Presidente do ALAC deve ser eleito pelos membros do ALAC de acordo com os procedimentos adotados pelo Comitê.
e. O ALAC deve indicar anualmente um contato não-votante ao Conselho da ICANN, sem limitação de nova indicação, e deve, após consultar cada RALO, indicar anualmente cinco delegados com direito a voto (sendo que dois deles não poderão ser cidadãos de país na mesma região geográfica, conforme definido pela seção 5 do artigo VI) do Comitê de Nomeação.
f. Sujeito ao disposto no Artigo de Transição deste Estatuto, o Comitê Consultivo Geral (At-Large) pode designar contatos não-votantes para cada Conselho da ccNSO e Conselho da GNSO.
g. Deve haver uma RALO para cada região geográfica de acordo com a seção 5 do artigo VI. Cada RALO funcionará como fórum e ponto de coordenação principal para a entrada pública do ICANN em sua região geográfica e deve ser uma organização sem fins lucrativos certificada pela ICANN de acordo com os critérios e padrões definidos pelo Conselho com base nas recomendações do Comitê Consultivo Geral (At-Large). Uma organização deve tornar-se uma RALO reconhecido por sua região geográfica ao enviar um Memorando de Entendimento com a ICANN, tratando das respectivas funções e responsabilidades da ICANN e da RALO, a respeito do processo de seleção de membros do ALAC e requisitos para abertura, oportunidades de participação, transparência, contabilidade e diversidade na estrutura e procedimentos da RALO, bem como critérios e padrões para o Grupo Constituinte da RALO em estruturas gerais.
h. Cada RALO deve oferecer apoio a estruturas gerais em sua região geográfica que tenham sido certificadas para atender aos requisitos do Memorando de Entendimento da RALO com a ICANN de acordo com o parágrafo 4 (i) desta seção. Se assim compreendido no Memorando de Entendimento com a ICANN, uma RALO pode também incluir usuários da Internet individuais que sejam cidadãos ou residentes em países dentro da região geográfica da RALO.
i. Afiliação na Comunidade Geral
- Os critérios e parâmetros para certificação de Estruturas At-Large em cada região geográfica serão definidos pelo Conselho, com base nas recomendações do ALAC, e serão descritos no Memorando de Entendimento entre a ICANN e a RALO de cada região geográfica.
- Os critérios e parâmetros para a certificação de Estruturas At-Large serão definidos de tal maneira que a participação de usuários individuais da Internet que são cidadãos ou moradores de países pertencentes à região geográfica (conforme definição na seção 5 do artigo VI) da RALO predominará na operação de cada Estrutura At-Large naquela RALO, sem necessariamente excluir a participação de outros, desde que seja compatível com os interesses dos internautas individuais da região.
- Os Memorandos de Entendimento com cada RALO também incluirão disposições cujo propósito é permitir que na medida do possível, cada usuários individual da Internet que é cidadão de um país pertencente à região geográfica da RALO possa participar em pelo menos uma das Estruturas At-Large da RALO.
- Na medida em que isso for compatível com esses objetivos, os critérios e padrões também devem possibilitar que cada RALO adote o tipo de estrutura que mais se adapta aos costumes e ao caráter da sua região geográfica.
- Assim que se definirem os critérios e padrões conforme estabelece essa Cláusula I, o ALAC, com a assessoria e participação da RALO em que o candidato atua, será responsável por certificar organizações que satisfizerem os critérios e parâmetros para o credenciamento como Estrutura At-Large.
- As decisões de credenciar ou descredenciar uma Estrutura At-Large sempre seguirão as decisões do ALAC em suas Normas de Procedimento, observando-se sempre que todas as mudanças efetuadas nas Normas de Procedimento referentes a candidaturas de ALS estarão sujeitas à análise pelas RALOS e pelo Conselho da ICANN.
- As decisões de credenciar, não credenciar ou descredenciar uma Estrutura At-Large estarão sujeitas a revisão, de acordo com os procedimentos definidos pelo Conselho.
- A qualquer momento o ALAC também pode avaliar se uma Estrutura At-Large em potencial satisfaz os critérios e parâmetros aplicáveis.
j. O ALAC e as RALOs também serão responsáveis pela coordenação das seguintes atividades:
1. Manter a comunidade de usuários individuais da Internet de sua região informada sobre as novidades mais importantes da ICANN;
2. Divulgar (através de publicação ou de outra forma), novidades sobre a ICANN e informações sobre itens do processo normativo da ICANN;
3. Promover atividades de divulgação entre a comunidade de usuários individuais da Internet;
4. Desenvolver e manter programas contínuos de informação sobre a ICANN e seu trabalho;
5. Estabelecer uma estratégia de divulgação de assuntos da ICANN em cada região da RALO;
6. Publicar e analisar as políticas propostas pela ICANN, suas decisões, seus possíveis impactos regionais e efeitos sobre os indivíduos na região;
7. Oferecer mecanismos on-line que promovam a discussão entre os membros das estruturas At-Large em sua região; e
8. Criar mecanismos e processos que possibilitem uma comunicação de duas vias entre os membros das estruturas At-Large em sua região e aqueles indivíduos envolvidos na tomada de decisões da ICANN, de modo que os indivíduos interessados possam compartilhar pontos de vista sobre assuntos pendentes da ICANN.
Cada Comitê Consultivo deverá determinar suas próprias normas de procedimento e exigências de quorum.
O presidente e cada membro de um comitê exercerão o mandato até que seu sucessor seja indicado ou até que este comitê seja dissolvido, ou ainda até que ele ou ela seja afastado(a), renuncie ou deixe de atuar como membro do comitê.
As vacâncias em qualquer comitê devem ser preenchidas da mesma forma que no caso de indicações originais.
Os membros de um comitê não receberão remuneração por seus serviços como membros de um comitê. Entretanto, o Conselho pode autorizar o reembolso de despesas legítimas e necessárias feitas pelos membros do comitê, inclusive seus Diretores, no desempenho de seus deveres como membros do comitê.
ARTIGO XI-A: OUTROS MECANISMOS CONSULTIVOS
Seção 1. CONSULTORIA DE ESPECIALISTAS EXTERNOS
1. Objetivo. O objetivo da busca de consultoria externa é permitir que o processo normativo da ICANN se beneficie com a experiência acumulada no setor público ou privado fora dos limites da ICANN. Nos casos em que existem entidades públicas com conhecimento no assunto, ou nos casos em que o acesso a entidades ou indivíduos do setor privado com experiência seria proveitoso, o Conselho e os grupos constituintes devem ser estimulados a recorrer a eles.
2. Tipos de painéis consultivos de especialistas.
a. Seja por iniciativa própria ou por sugestão de alguma entidade da ICANN, o Conselho poderá indicar ou autorizar o Presidente a indicar painéis consultivos de especialistas, constituídos de indivíduos ou entidades do setor público ou privado. Se a assessoria procurada junto a esses painéis referir-se a políticas públicas, aplicar-se-ão as disposições da seção 1(3)(b) deste artigo .
b. Além disso, em concordância com a seção 1(3) deste artigo, o Conselho poderá encaminhar assuntos relativos a políticas públicas pertinentes à missão da ICANN a uma organização governamental multinacional ou organização criada por tratado.
3. Processo de solicitação de assessoria para questões de políticas públicas.
a. A qualquer momento, o Comitê Consultivo para Assuntos Governamentais poderá recomendar que o Conselho solicite a assessoria de uma fonte externa sobre uma ou mais questões relativas a políticas públicas, conforme determinação acima.
b. Na eventualidade de o Conselho determinar, seja após esse tipo de recomendação ou por outro motivo, que a assessoria externa para uma ou mais questões relativas a políticas públicas seria conveniente, o Conselho deverá consultar o Comitê Consultivo para Assuntos Governamentais a fim de definir qual a fonte de consultoria apropriada e quais as providências necessárias, incluindo a definição de escopo e processo, para solicitar e obter essa assessoria.
c. Quando apropriado, o Conselho deverá transmitir ao Comitê Consultivo Governamental todos os pedidos de assessoria de uma organização governamental multinacional ou criada por tratado, incluindo os termos de referência específicos, com a sugestão de que o Conselho transmita o pedido à organização governamental multinacional ou organização criada por tratado.
4. Processo de solicitação de assessoria para outros assuntos. Sempre que o Conselho ou o Presidente encaminhar assuntos não relacionados a políticas públicas a um painel consultivo de especialistas segundo a seção 1(2)(a) deste artigo esse processo obedecerá os termos de referência que descrevem os assuntos para os quais se solicitam sugestões e recomendações, e os procedimentos e o cronograma a serem seguidos.
5. Recebimento das recomendações de especialistas e seus efeitos. A assessoria externa segundo esta seção será feita por escrito. Essa assessoria constituirá apenas uma recomendação e não será obrigatória, e seu propósito é aumentar as informações disponíveis para o Conselho ou outra entidade da ICANN no desempenho de suas responsabilidades.
6. Oportunidade para comentários. O Comitê Consultivo para Assuntos Governamentais, além das Organizações de Apoio e outros Comitês Consultivos, terá oportunidade de comentar as recomendações externas recebidas antes que o Conselho tome qualquer decisão.
Seção 2. GRUPO DE CONTATOS TÉCNICOS
1. Objetivo. A qualidade do trabalho da ICANN depende do acesso a informações completas e oficiais sobre os parâmetros técnicos que fundamentam as atividades da ICANN. Portanto, o relacionamento da ICANN com as organizações que estabelecem esses parâmetros é muito importante. O Grupo de Contatos Técnicos (TLG) colocará o Conselho em contato com as fontes apropriadas de assessoria técnica quando se tratar de assuntos específicos pertinentes às atividades da ICANN.
2. Organizações de TLG. O TLG se constituirá de quatro organizações: O Instituto Europeu de Padrões para Telecomunicações (ETSI), o Setor de Padronização de Telecomunicações da União Internacional de Telecomunicações (ITU-T), o World Wide Web Consortium (W3C) e o Conselho de Arquitetura da Internet (IAB).
3. Função. A função das organizações do TLG será conduzir informações e orientações técnicas ao Conselho e a outras entidades da ICANN. Essa função tem um componente responsivo e também um componente ativo de "cão de guarda", que envolve as seguintes responsabilidades:
a. Quando houver um pedido de informação, colocar o Conselho ou outra entidade da ICANN em contato com as fontes de conhecimento técnico apropriadas. Esse componente da função do TLG inclui circunstâncias nas quais a ICANN precisa de uma resposta definitiva a uma pergunta técnica específica. Quando se tratar de uma informação sobre um determinado parâmetro técnico sob responsabilidade de uma das organizações do TLG, esse pedido será encaminhado diretamente a essa organização.
b. Como atividade de "guarda" permanente, assessorar o Conselho sobre a importância e o progresso de evoluções técnicas nas áreas cobertas pelo escopo de cada organização que poderiam afetar as decisões do Conselho ou outras decisões da ICANN, bem como dirigir a atenção a padrões técnicos globais que afetam o desenvolvimento de diretrizes dentro da área de atuação da ICANN. Esse componente do papel do TLG envolve circunstâncias nas quais a ICANN não tem conhecimento de uma nova evolução e, portanto, não poderia resolver eventuais dúvidas.
4. Procedimentos do TLG. O TLG não terá executivos, não realizará reuniões, nem fornecerá consultoria normativa ao Conselho como um comitê (embora o Conselho possa solicitar individualmente às organizações do TLG que o assessorem, quando houver necessidade, em áreas relevantes às respectivas pautas individuais). Além disso, o TLG também não discutirá ou coordenará assuntos técnicos entre as organizações do TLG; não criará nem tentará criar posições unificadas; não criará nem tentará criar camadas ou estruturas adicionais no TLG para desenvolver padrões técnicos ou para qualquer outra finalidade.
5. Trabalho técnico da IANA. O TLG não terá envolvimento com o trabalho da IANA para a Força-tarefa para Engenharia da Internet, Força-tarefa para Pesquisa da Internet ou para o Conselho de Arquitetura da Internet, conforme descreve o Memorando de Entendimento sobre o Trabalho Técnico da Autoridade para Atribuição de Números da Internet, ratificado pelo Conselho em 10 de março de 2000.
6. Especialistas técnicos individuais. Cada organização do TLG designará dois especialistas técnicos familiarizados com os padrões técnicos relevantes para as atividades da ICANN. Esses oito especialistas estarão disponíveis, quando necessário, para indicar através de uma troca de mensagens de e-mail, para onde encaminhar uma pergunta técnica da ICANN quando ICANN não se dirigir diretamente a uma organização do TLG.
7. Contato junto à Diretoria e Delegado junto ao Comitê de Nomeação. Anualmente, uma organização do TLG, determinada por rodízio, indicará um contato não-votante junto ao Conselho, de acordo com o artigo VI, seção 9(1)(d).. Anualmente, uma organização do TLG, determinada por rodízio, indicará um delegado votante junto ao Comitê de Nomeação, de acordo com o artigo VII, seção 2(8)(j).. A ordem do rodízio para a indicação do contato não-votante junto ao Conselho será ETSI, ITU-T e W3C. A ordem do rodízio para a escolha do delegado junto ao Comitê de Nomeação será W3C, ETSI e ITU-T. (A IAB não participa desses rodízios porque a IETF já indica um contato não-votante para o Conselho e seleciona um delegado para o Comitê de Nomeação da ICANN).
ARTIGO XII: COMITÊS DO CONSELHO E TEMPORÁRIOS
O Conselho poderá criar um ou mais comitês do Conselho, que continuarão existindo até que o Conselho determine o contrário. Apenas Diretores poderão ser indicados para um Comitê do Conselho. Se uma pessoa indicada para um Comitê do Conselho deixar de ser Diretor, essa pessoa também deixará de ser membro de um Comitê do Conselho. Cada Comitê do Conselho se constituirá de dois ou mais Diretores. O Conselho poderá designar um ou mais Diretores como membros alternativos desse comitê, que poderão substituir qualquer membro ausente a uma reunião do comitê. Os membros de um comitê poderão ser afastados do comitê a qualquer momento pelo voto da maioria de dois terços (2/3) de todos os membros do Conselho, contanto que, porém, aquele Diretor ou aqueles Diretores que são objeto da ação de afastamento não tenham direito de votar essa decisão ou de serem contados como membros do Conselho na contagem dos dois terços (2/3) necessários dos votos; e também desde que em hipótese alguma um Diretor seja afastado de um comitê sem que esse afastamento tenha a aprovação de no mínimo a maioria de todos os membros do Conselho.
Seção 2. PODERES DOS COMITÊS DO CONSELHO
1. O Conselho poderá delegar aos Comitês do Conselho toda a sua autoridade legal, exceto em relação a:
a. o preenchimento de vacâncias no Conselho ou em algum comitê;
b. emendas, substituição ou adoção de novo Estatuto ou Artigos de Incorporação;
c. emendas ou substituição de alguma resolução do Conselho que expressamente não está sujeita a emendas ou substituições;
d. a indicação de comitês do Conselho ou seus respectivos membros;
e. a aprovação de alguma transação auto-instituída, conforme definição na seção 5233(a) da CNPBCL;
f. a aprovação do orçamento anual, exigida pelo artigo XVI; ou
g. a remuneração de algum executivo, descrita no artigo XIII..
2. O Conselho terá autoridade para prescrever os procedimentos de qualquer Comitê do Conselho. Na ausência desse tipo de prescrição, o comitê terá autoridade para prescrever a maneira pela qual seus procedimentos serão conduzidos. A menos que esse Estatuto, o Conselho ou esse comitê determinem o contrário, as reuniões ordinárias e extraordinárias serão regidas pelas disposições do artigo VI aplicáveis a reuniões e decisões do Conselho. Cada comitê manterá as atas regulares de seus procedimentos e deverá reportá-las periodicamente ao Conselho, quando esse assim o exigir.
O Conselho poderá criar os comitês temporários que julgar necessários, com afiliações, deveres e responsabilidades, conforme determinarem as resoluções ou os regulamentos adotados pelo Conselho na criação desses comitês.
Os executivos da ICANN serão um Presidente (que atuará como Diretor-executivo - CEO) e um diretor-executivo financeiro. A critério do Conselho, a ICANN também poderá contar com todos os executivos adicionais que considerar apropriados. Qualquer pessoa, exceto o Presidente, poderá deter mais de um cargo, observando-se porém que nenhum membro do Conselho (exceto o Presidente) poderá servir simultaneamente como executivo da ICANN.
Seção 2. ELEIÇÃO DE EXECUTIVOS
O Conselho elegerá anualmente os executivos da ICANN, de acordo com a recomendação do Presidente ou, no caso do Presidente, do Presidente do Conselho da ICANN. Cada executivo permanecerá no cargo até que renuncie, seja afastado, não esteja mais qualificado para servir ou até que seu sucessor seja eleito.
Seção 3. AFASTAMENTO DE EXECUTIVOS
Qualquer executivo pode ser afastado, com ou sem motivo, pelo voto majoritário de dois terços (2/3) de todos os membros do Conselho. Se ocorrer uma vacância em algum cargo como em caso de morte, renúncia, afastamento, desqualificação ou qualquer outro motivo, o Conselho poderá delegar os poderes e deveres desse cargo a qualquer Executivo ou Diretor, até que o sucessor para o cargo seja eleito.
O Presidente será o Diretor-executivo (CEO) da ICANN, encarregado de todas as suas atividades e negócios. Todos os outros executivos e funcionários deverão reportar-se ao Presidente ou ao seu delegado, a menos que haja disposição em contrário neste Estatuto. O Presidente atuará como membro ex officio do Conselho e terá os mesmos direitos e privilégios de qualquer membro do Conselho. O Presidente estará autorizado a convocar reuniões extraordinárias do Conselho, conforme determina esse documento, e cumprirá todos os outros deveres exigidos por esse Estatuto e aqueles que eventualmente o Conselho determinar.
O Secretário deverá manter ou cuidar para que sejam mantidas as atas do Conselho em um ou mais livros destinados para esse fim, verificar se todas as informações foram fornecidas com exatidão, de acordo com as determinações deste Estatuto ou conforme exigido por lei e, de modo geral, desempenhar todas as tarefas que o Presidente ou o Conselho eventualmente solicitar.
Seção 6. DIRETOR-EXECUTIVO FINANCEIRO
O Diretor-executivo Financeiro (Chief Financial Officer - "CFO") será o diretor financeiro da ICANN. Se o Conselho solicitar, o CFO deverá fornecer uma caução pelo cumprimento consciencioso de seus deveres na forma e com a garantia ou garantias determinadas pelo Conselho. O CFO estará encarregado da custódia e guarda de todos os fundos da ICANN e deverá registrar ou providenciar o registro, em livros pertencentes a ICANN, dos montantes integrais e exatos de todas as receitas e despesas, e deverá depositar todo o dinheiro e outros valores em nome da ICANN nas contas destinadas a este fim pelo Conselho. O CFO deverá liberar os fundos da ICANN conforme determinar o Conselho ou o Presidente e, quando estes o solicitarem, deverá prestar contas ao Conselho e ao Presidente de todas as suas atividades como CFO e das condições financeiras da ICANN. O CFO será responsável pelo planejamento e programação financeiros da ICANN, devendo assistir o Presidente na preparação do orçamento anual da ICANN. O CFO deverá coordenar e supervisionar os fundos da ICANN, inclusive auditorias ou outras revisões por parte da ICANN ou suas Organizações de Apoio. O CFO será responsável por todos os outros assuntos relativos às operações financeiras da Corporação.
Seção 7. EXECUTIVOS ADICIONAIS
Além dos executivos descritos acima, todos os executivos adicionais ou auxiliares eleitos ou indicados pelo Conselho deverão cumprir os deveres que eventualmente lhes forem atribuídos pelo Presidente ou pelo Conselho.
Seção 8. REMUNERAÇÃO E DESPESAS
O Conselho aprovará a remuneração de qualquer executivo da ICANN. Despesas incorridas no cumprimento dos seus deveres poderão ser restituídas aos executivos após aprovação pelo Presidente (exceto no caso do Presidente), por outro executivo designado pelo Conselho (no caso do Presidente), ou pelo Conselho.
Seção 9. CONFLITOS DE INTERESSE
Mediante um comitê designado para esse fim, o Conselho estabelecerá uma norma exigindo que, pelo menos uma vez ao ano, todos os Executivos apresentem uma declaração descrevendo todos os negócios e outras afiliações que de alguma maneira estejam relacionadas com atividades e afiliações da ICANN.
ARTIGO XIV: INDENIZAÇÃO DE DIRETORES, EXECUTIVOS, FUNCIONÁRIOS E OUTROS AGENTES
Na medida do que permite a CNPBCL, a ICANN deverá reembolsar cada um dos seus agentes por suas despesas, audiências judiciais, penas, quitações e outros valores gastos de forma legítima e razoável, relacionados a qualquer procedimento decorrente do fato de essa pessoa ser ou ter sido um agente da ICANN, desde que a pessoa indenizada tenha agido de boa-fé e de maneira que acreditava atender aos melhores interesses da ICANN e não de maneira criminosa. No sentido deste Artigo, um "agente" da ICANN inclui qualquer pessoa que é ou foi Diretor, Executivo, funcionário ou qualquer outro agente da ICANN (inclusive membros de qualquer Organização de Suporte, Comitê Consultivo, Comitê de Nomeação, outro comitê da ICANN ou do Grupo de Contato Técnicos), agindo no âmbito de suas responsabilidades e no interesse da ICANN, ou que está ou esteve servindo a pedido da ICANN como Diretor, Executivo, funcionário ou agente de outra corporação, parceria, joint venture, fideicomisso ou outro empreendimento. O Conselho pode adotar uma resolução autorizando a aquisição e a manutenção de um seguro em favor de qualquer agente da ICANN contra qualquer responsabilidade da qual o agente é acusado ou na qual tenha incorrido, ou que tenha surgido em razão da posição do agente, tendo ou não a ICANN o poder de indenizar o agente por estas responsabilidades, de acordo com as disposições deste artigo.
O Conselho pode autorizar qualquer diretor-executivo ou diretores executivos, agente ou agentes, a participar de qualquer contrato, executar ou entregar qualquer instrumento em nome e no interesse da ICANN, sendo que esta autorização pode ser geral ou limitada a casos específicos. Na ausência de disposição contrária do Conselho, contratos e instrumentos só poderão ser executados pelos seguintes Executivos: Presidente, qualquer Vice-presidente, ou o CFO. A menos que seja autorizado ou ratificado pelo Conselho, nenhum outro executivo, agente ou funcionário terá poder ou autoridade para onerar ICANN ou responsabilizá-la por quaisquer dívidas ou obrigações.
Todos os fundos da ICANN que não tenham sido empregados de outra forma serão depositados periodicamente a crédito da ICANN nos bancos, companhias fiduciárias ou outros depositários indicados pelo Conselho ou pelo Presidente, a requerimento do Conselho.
Todos os cheques, títulos ou outras ordens para o pagamento em dinheiro, notas ou outras evidências de débito emitidos em nome da ICANN serão assinados pelo(s) executivo(s) ou agente(s) da ICANN, eventualmente indicados por resolução do Conselho.
Nenhum empréstimo será feito por ou para ICANN, e nenhum documento de dívida será emitido em seu nome, exceto quanto autorizado por uma resolução do Conselho. Esta autorização pode ser geral ou limitada a casos específicos, desde que nenhum empréstimo seja feito por ICANN para seus Diretores e Executivos.
O Conselho determinará o final do exercício fiscal da ICANN.
No encerramento do exercício fiscal, os livros da ICANN serão fechados e auditados por contadores públicos credenciados. A indicação dos auditores fiscais será responsabilidade do Conselho.
Seção 3. RELATÓRIO E BALANÇO ANUAIS
Ao menos uma vez por ano, o Conselho publicará um relatório descrevendo suas atividades, inclusive um balanço financeiro auditado e uma descrição de todos os pagamentos efetuados por ICANN aos Diretores (incluindo a restituição de despesas). A ICANN deverá elaborar o relatório anual e o levantamento anual de determinadas transações, conforme exigência da CNPBCL, e enviá-los a todos os membros do Conselho e às outras pessoas que esta indicar, em no máximo cento e vinte (120) dias após o término do exercício fiscal da ICANN.
O Presidente deverá preparar e submeter ao Conselho a proposta de orçamento anual da Corporação para o ano seguinte, no mínimo quarenta e cinco (45) dias antes do início de cada exercício fiscal, publicando-o no site da ICANN. O orçamento proposto deverá identificar fontes e previsão de rendimentos e, na medida do possível, deverá discriminar possíveis itens de despesas. O Conselho deverá adotar um orçamento anual e publicar o Orçamento adotado em seu Site.
O Conselho estabelecerá honorários e taxas para os serviços e benefícios oferecidos por ICANN, com o objetivo de cobrir integralmente os custos justos de operação da ICANN, estabelecendo reservas razoáveis para despesas e contingências futuras relacionadas às atividades legítimas da ICANN. Esses honorários e taxas deverão ser justos e imparciais e, depois de adotados, devem ser publicados no Site de modo suficientemente detalhado para que possam ser facilmente acessíveis.
A ICANN não terá membros, conforme determina a California Nonprofit Public Benefit Corporation Law ("CNPBCL" - Legislação da Califórnia para corporações sem fins lucrativos em benefício do público), não obstante o uso do termo "Membro" neste Estatuto, em qualquer documento da ICANN ou em qualquer decisão do Conselho ou equipe da ICANN.
A sede para a realização dos negócios da ICANN localizar-se-á no município de Los Angeles, Estado da Califórnia, Estados Unidos da América. A ICANN também poderá ter um ou vários escritórios adicionais dentro ou fora dos Estados Unidos da América, conforme o Conselho eventualmente decidir.
O Conselho poderá adotar um selo corporativo e usá-lo produzindo-o ou empregando um fac-símile a ser impresso, afixado ou reproduzido, ou de qualquer outra forma.
Exceto no caso de disposição em contrário nos Artigos de Incorporação ou neste Estatuto, só será possível alterar, acrescentar emendas ou recusar Artigos de Incorporação ou Estatuto da ICANN, e adotar novos Artigos de Incorporação ou Estatuto com a aprovação de dois terços (2/3) de todos os membros do Conselho.
ARTIGO XX: ARTIGO DE TRANSIÇÃO
Este Artigo de Transição estabelece as disposições para a transição dos processos e estruturas definidos pelo Estatuto da ICANN, conforme emendas e reapresentação em 29 de outubro de 1999 e emendas de 12 de fevereiro de 2002 (os "Antigo Estatuto"), para os processos e estruturas definidos pelo Estatuto dos quais este artigo é uma das partes (os "Novo Estatuto.").
Seção 2. CONSELHO DE DIRETORES
1. Durante o período com início na data de adoção deste Artigo de Transição e término na Data e Horário Efetivos do Novo Conselho, conforme definição no parágrafo 5 desta seção 2, o Conselho de Diretores da Corporação ("Conselho de Transição") se comporá dos membros do Conselho que foram diretores segundo o Antigo Estatuto imediatamente após a conclusão da reunião anual de 2002. Excetuam-se os membros At-Large pertencentes ao Conselho de acordo com as disposições do Antigo Estatuto, que notificarem o Secretário do Conselho em 15 de dezembro de 2002 (ou por escrito via e-mail, até no máximo 23 de dezembro de 2002), e que também servirão como membros do Conselho de Transição. Não obstante as disposições do artigo VI, seção 12 do Novo Estatuto, vacâncias no Conselho de Transição não serão ocupadas. O Conselho de Transição não terá contatos como estabelece o artigo VI, seção 9 do Novo Estatuto.. Os Comitês do Conselho existentes na data de adoção desse Artigo de Transição continuarão existindo, sujeitos a todas as mudanças nos Comitês do Conselho ou respectivas afiliações que o Conselho de Transição eventualmente adotar por resolução.
2. O Conselho de Transição elegerá um Presidente e um Vice-presidente que servirão até a Data e Horário Efetivo do Novo Conselho.
3. O "Novo Conselho" é o Conselho descrito no artigo VI, seção 2(1) do Novo Estatuto..
4. Prontamente após a adoção deste Artigo de Transição, formar-se-á um Comitê de Nomeação que, na medida do possível, incluirá os delegados e contatos descritos no artigo VII, seção 2 do Novo Estatuto, cujos mandatos terminarão no final da reunião anual da ICANN em 2003. O Comitê de Nomeação procederá sem demora para selecionar os Diretores que ocuparão os Assentos 1 a 8 do Novo Conselho, cujos mandatos terminarão com o início dos primeiros mandatos especificados para estes Assentos no artigo VI, seção 8(1)(a)-(c) do Novo Estatuto, e notificará formalmente o Secretário da ICANN dessa seleção.
5. A Data e o Horário Efetivos do Novo Conselho referem-se ao momento durante a primeira reunião ordinária da ICANN em 2003 que se iniciará pelo menos sete dias corridos depois de o Secretário da ICANN ter recebido a notificação formal da escolha dos Diretores que ocuparão no mínimo dez dos Assentos 1 a 14 do Novo Conselho. Na Data e Horário Efetivos do Novo Conselho, este receberá do Conselho de Transição todos os direitos, deveres e obrigações do Conselho de Diretores da ICANN. De acordo com a seção 4 deste artigo, os Diretores (artigo VI, seção 2(1)(a)-(d)) e contatos não-votantes (artigo VI, seção 9) cuja seleção foi notificada formalmente ao Secretário da ICANN, serão empossados na Data e Horário Efetivos do Novo Conselho juntamente com o presidente (artigo VI, seção 2(1)(e)), e depois disso todos os Diretores e contatos não-votantes adicionais assumirão seus cargos depois que o Secretário ’receber a notificação formal de sua seleção.
6. A primeira medida do Novo Conselho será eleger um Presidente e um Vice-presidente. Os mandatos desses membros do Conselho expirarão no final da reunião anual de 2003.
7. Os Comitês do Conselho existentes na Data e no Horário Efetivos do Novo Conselho continuarão em existência de acordo com suas pautas, mas os mandatos de todos os membros destes comitês se encerrarão na data e Horário Efetivos do Novo Conselho. Comitês temporários existentes na Data e Horário Efetivos do Novo Conselho continuarão em existência com sua pauta e afiliação, sujeitos a todas as mudanças que o Novo Conselho eventualmente adotar por resolução.
8. Quando se aplicar a disposição para limitação de mandato da seção 8(5) do artigo VI, o serviço de um Diretor junto ao Conselho antes da Data e Horário Efetivos do Novo Conselho contará como um mandato.
Seção 3. ORGANIZAÇÃO DE SUPORTE A ENDEREÇOS
A Organização de Suporte a Endereços continuará em operação de acordo com as disposições do Memorando de Entendimento, firmado originalmente em 18 de outubro de 1999 entre a ICANN e um grupo de registros regionais da Internet (RIRs) e acrescido de emendas em outubro de 2000, até que um substituto do Memorando de Entendimento entre em vigor. Imediatamente após a adoção deste Artigo de Transição, a Organização de Suporte a Endereços fará suas seleções e informará formalmente o Secretário da ICANN da seleção de:
1. Diretores que ocuparão os Assentos 9 e 10 do Novo Conselho, cujos mandatos se encerrarão no início dos primeiros mandatos normais especificados para cada um desses Assentos no artigo VI, seção 8(1)(d) e (e) do Novo Estatuto; e
2. o delegado junto ao Comitê de Nomeação selecionado pelo Conselho da Organização de Suporte a Endereços, conforme determina o artigo VII, seção 2(8)(f) do Novo Estatuto..
Quanto aos Diretores da ICANN que a Organização de Suporte a Endereços está autorizada a selecionar, e tendo em vista a necessidade de uma seleção rápida para que o Novo Conselho entre em operação o mais depressa possível, a Organização de Suporte a Endereços poderá escolher seus Diretores entre as pessoas que já havia selecionado anteriormente como Diretores da ICANN conforme o Antigo Estatuto. Se a Organização de Suporte a Endereços não informar formalmente, o Secretário da ICANN de sua seleção para os Assentos 9 e 10 até 31 de março de 2003, considerar-se-á que a Organização de Suporte a Endereços selecionou para o Assento 9 a pessoa que selecionou como Diretor da ICANN segundo o Antigo Estatuto para o mandato com início em 2001 e, para o Assento 10, a pessoa que selecionou como Diretor da ICANN segundo o Antigo Estatuto, para o mandato com início em 2002.
Seção 4. ORGANIZAÇÃO DE SUPORTE A NOMES COM CÓDIGOS DE PAÍSES
1. Após a inscrição de trinta gerentes de ccTLDs (sendo pelo menos quarto de cada Região Geográfica) como membros da ccNSO, o Site publicará uma notificação. Tão logo quanto possível após essa notificação, os membros da ccNSO selecionarão os membros do Conselho da ccNSO de acordo com os procedimentos estabelecidos no artigo IX, seção 4(8) e (9).. Após a conclusão desse processo de seleção, o Site publicará uma notícia de que o Conselho da ccNSO foi constituído. Em cada Região Geográfica, os membros da ccNSO selecionarão três membros para o Conselho da ccNSO, sendo que um membro servirá por um mandato que terminará no final da primeira reunião anual da ICANN após a constituição do Conselho da ccNSO, um segundo membro servirá por um mandato que terminará no final da segunda reunião anual da ICANN após a constituição do Conselho da ccNSO e o terceiro membro servirá por um mandato que terminará no final da terceira reunião anual da ICANN após a Constituição do Conselho da ccNSO. (Esta seção 4 do artigo XX segue a definição de "gerente de ccTLD" especificada no artigo IX, seção 4(1) e as definições no artigo IX, seção 4(4). )
2. Após a adoção do artigo IX desse Estatuto, o Comitê de Nomeação selecionará os três membros do Conselho da ccNSO descritos no artigo IX, seção 3(1)(b).. Quando selecionar três indivíduos que servirão junto ao Conselho da ccNSO, o Comitê de Nomeação designará um para servir por um mandato com término após a conclusão da primeira reunião anual da ICANN, após a constituição do Conselho da ccNSO, um segundo membro que servirá por um mandato com término após a conclusão da segunda reunião anual da ICANN, após a constituição do Conselho da ccNSO, e um terceiro membro, que servirá por um mandato com término após a conclusão da terceira reunião da ICANN depois da constituição do Conselho da ccNSO. Os três membros do Conselho da ccNSO selecionados pelo Comitê de Nomeação não assumirão os seus assentos antes que o Conselho da ccNSO seja constituído.
3. Assim que o Conselho da ccNSO estiver constituído, o Comitê Consultivo Geral (At-Large) e o Comitê Consultivo para Assuntos Governamentais poderão designar, cada um, um contato junto ao Conselho da ccNSO, conforme estabelece o artigo IX, seção 3(2)(a) e (b)..
4. Assim que o Conselho da ccNSO estiver constituído, o Conselho poderá designar Organizações Regionais, conforme estabelece o artigo IX, seção 5. Após a sua designação, uma Organização Regional poderá indicar um contato junto ao Conselho da ccNSO.
5. Até o Conselho da ccNSO ser constituído, os Assentos 11 e 12 no Novo Conselho permanecerão vagos. Imediatamente após a constituição do Conselho da ccNSO, este selecionará os Diretores que ocuparão os Assentos 11 e 12 no Novo Conselho, com mandatos que terminarão no início do próximo mandato regular especificado para cada um desses Assentos no artigo VI, seção 8(1)(d) e (f) do Novo Estatuto, e notificará formalmente o Secretário da ICANN dessas seleções.
6. Até o Conselho da ccNSO ser constituído, o Conselho de Transição ou o Novo Conselho (dependendo de qual existir no momento em que se exige uma indicação específica), depois de consultar os membros da comunidade de ccTLDs, indicará o delegado junto ao Comitê de Nomeação que deveria ser indicado pela ccNSO. Depois que o Conselho da ccNSO tiver sido constituído, o delegado junto ao Comitê de Nomeação escolhido pelo Conselho de Transição ou pelo Novo Conselho segundo esta seção 4(9) que estiver em exercício permanecerá no cargo. Note-se, porém, que o Conselho da ccNSO poderá substituir esse delegado por um delegado de sua escolha no prazo de três meses após o encerramento da reunião anual da ICANN ou no caso de uma vacância. As indicações subseqüentes do delegado junto ao Comitê de Nomeação descrito no artigo VII, seção 2(8)(c), serão feitas pelo Conselho da ccNSO.
Seção 5. ORGANIZAÇÃO DE SUPORTE A NOMES GENÉRICOS
1. A Organização de Suporte a Nomes de Domínio cessará suas operações após a adoção deste Artigo de Transição, com a ressalva de que o Conselho de Nomes da Organização de Suporte a Nomes de Domínio poderá agir unicamente com a finalidade limitada de autorizar a transferência dos fundos por ele reunidos para a Organização de Suporte a Nomes Genéricos.
2. A Organização de Suporte a Nomes Genéricos ("GNSO") iniciará suas operações após a adoção deste Artigo de Transição, e os seis grupos constituintes da DNSO abaixo passarão a ser automaticamente grupos constituintes da GNSO, inicialmente ainda sujeitos às suas pautas atuais:
a. O grupo constituinte das entidades comerciais e empresariais da DNSO passará a ser o grupo constituinte de Usuários Comerciais e Empresariais da GNSO..
b. O grupo constituinte dos registros de gTLDs da DNSO passará a ser o grupo constituinte dos Registros de gTLDs da GNSO..
c. O grupo constituinte dos provedores de ISP e conectividade da DNSO passará a ser o grupo constituinte dos Provedores de Serviços e Conectividade da Internet da GNSO..
d. O grupo constituinte dos detentores de nomes de domínio não-comerciais da DNSO passará a ser o grupo constituinte de Usuários Não Comerciais da GNSO..
e. O grupo constituinte de registradores da DNSO passará a ser o grupo constituinte de Registradores da GNSO..
f. O grupo constituinte de interessados em marcas registradas, propriedade intelectual e combate à apropriação indébita da DNSO passará a ser o grupo constituinte de Interesses em Propriedade Intelectual da GNSO..
3. Não obstante a adoção ou validade do Novo Estatuto, cada grupo constituinte da GNSO descrito no parágrafo 2 desta seção 5 continuará em operação como antes, e nenhum membro, força-tarefa ou outra atividade do grupo será substituído ou alterado até que o grupo constituinte tome novas providências, contanto que até 15 de julho de 2003 cada grupo da GNSO envie ao Secretário da ICANN uma nova pauta e uma especificação dos procedimentos operacionais, adotados segundo os processos do grupo e compatíveis com o Novo Estatuto.
4. Até o final da reunião anual da ICANN em 2003, o Conselho da GNSO consistirá de três representantes de cada grupo constituinte da GNSO além de três pessoas selecionadas pelo Comitê de Nomeação. O Conselho da GNSO poderá incluir também contatos indicados pelo comitê Consultivo para Assuntos Governamentais e pelo Comitê Consultivo Geral (At-Large) (Interino), conforme estabelece o artigo X, seção 3(1) do Novo Estatuto.. Portanto, a composição do Conselho da GNSO seguirá as determinações do Novo Estatuto, que eventualmente poderão receber emendas, sem levar em conta este Artigo de Transição. Todos os comitês, forças-tarefa, grupos de trabalho, comitês de elaboração e grupos semelhantes criados pelo Conselho de Nomes da DNSO existentes imediatamente antes da adoção deste Artigo de Transição continuarão em existência como grupos com Conselho da GNSO com as mesmas pautas, membros e atividades, e estarão sujeitos a alterações por decisão do Conselho da GNSO.
5. Após a adoção deste Artigo de Transição, os três representantes de cada um dos seis grupos constituintes da DNSO no Conselho de Nomes da Organização de Suporte a Nomes de Domínio ("DNSO") serão empossados como representantes de grupos constituintes junto ao Conselho da GNSO, como segue:
a. Os três representantes do grupo constituinte de entidades comerciais e empresariais da DNSO serão empossados como representantes do grupo constituinte de Usuários Comerciais e Empresariais da GNSO.
b. Os três representantes do grupo constituinte de registros de gTLDs da DNSO serão empossados como representantes do grupo constituinte de registros de gTLDs da GNSO.
c. Os três representantes dos provedores de ISP e conectividade da DNSO serão empossados como representantes do grupo constituinte de Provedores de Serviços e Conectividade da Internet da GNSO.
d. Os três representantes do grupo constituinte de detentores de nomes de domínio não-comerciais da DNSO serão empossados como representantes do Grupo de Usuários Não-Comerciais da GNSO.
e. Os três representantes do grupo constituinte de registradores da DNSO serão empossados como representantes do grupo constituinte de Registradores da GNSO.
f. Os três representantes do grupo constituinte de interessados em marcas registradas, propriedade intelectual e combate à apropriação indébita da DNSO serão empossados como representantes do grupo constituinte de Interesses para Propriedade Intelectual da GNSO.
6. Os mandatos dos membros do Conselho da GNSO descritos no parágrafo 5 desta seção 5 estender-se-ão até o final dos seus mandatos segundo o Antigo Estatuto, com a ressalva que os mandatos de todos esses membros do Conselho da GNSO se encerrarão no final da reunião anual da ICANN em 2003. Se houver vacâncias antes dessa data em um cargo do Conselho da GNSO descrito no parágrafo 5 desta seção 5, o grupo constituinte correspondente ao cargo vago preencherá a vacância durante o período restante até a reunião anual da ICANN em 2003. Quando selecionar três indivíduos que servirão no conselho da GNSO, o Comitê de Nomeação inicial designará um indivíduo que servirá por um mandato até o final da conclusão da reunião anual da ICANN em 2004 e os outros dois, que servirão por mandatos até o final da reunião anual da ICANN em 2005.
7. Prontamente após a adoção deste Artigo de Transição, a Organização de Suporte a Nomes Genéricos, através do Conselho da GNSO, selecionará os Diretores que ocuparão os Assentos 13 e 14 do Novo Conselho, cujos mandatos se encerrarão com o início dos primeiros mandatos normais especificados para cada um desses Assentos no artigo VI, seção 8(1)(d) e (e) do Novo Estatuto, e notificará formalmente o Secretário da ICANN dessas seleções.
8. Na ausência de outra decisão do Novo Conselho sobre o assunto, cada um dos grupos constituintes da GNSO escolherá dois representantes para o Conselho da GNSO, até 1 de outubro de 2003, notificando formalmente o Secretário da ICANN de suas seleções. Cada grupo constituinte designará um desses representantes para servir por um mandato de um ano, e ou outro para servir por um mandato de dois anos. Cada sucessor desses representantes servirá por mandatos de dois anos.
9. Após a adoção deste Artigo de Transição e até o Conselho da ICANN tomar outra providência, o Conselho da GNSO assumirá a responsabilidade pelas listas de e-mail para anúncios e discussões da Assembléia Geral da DNSO.
10. Imediatamente após a adoção deste Artigo de Transição, cada um grupos constituintes identificados no parágrafo 5 desta seção 5 encarregado de escolher um delegado junto ao Comitê de Nomeação segundo o artigo VII, seção 2 do Novo Estatuto deverá notificar prontamente o Secretário da ICANN sobre a(s) pessoa(s) selecionada(s) para atuar como delegado.
Seção 6. ORGANIZAÇÃO DE SUPORTE A PROTOCOLOS
A Organização de Suporte a protocolos citada no Antigo Estatuto foi dissolvida.
Seção 7. COMITÊS CONSULTIVOS E GRUPO DE CONTATO TÉCNICO
1. Após a adoção do Novo Estatuto, o Comitê Consultivo para Assuntos Governamentais continuará em operação de acordo com seus princípios e práticas operacionais existentes, até que o comitê tome outras providências. O Comitê Consultivo para Assuntos Governamentais poderá designar contatos que servirão junto a outras entidades da ICANN conforme determinação nesse Novo Estatuto, notificando formalmente o Secretário da ICANN. Imediatamente após a adoção deste Artigo de Transição, o Comitê Consultivo para Assuntos Governamentais informará o Secretário da ICANN da pessoa selecionada como seu delegado junto ao Comitê de Nomeação, como estabelece o artigo VII, seção 2 do Novo Estatuto..
2. Cada organização designada como membro do Grupo de Contato Técnico segundo o artigo XI-A, seção 2(2) do Novo Estatuto indicará os dois especialistas técnicos descritos no artigo XI-A, seção 2(6) do Novo Estatuto, notificando formalmente o Secretário da ICANN. Tão logo quanto possível, o Grupo de Contato Técnico selecionará o seu delegado junto ao Comitê de Nomeação de acordo com o artigo XI-A, seção 2(7) do Novo Estatuto..
3. Após a adoção do Novo Estatuto, o Comitê Consultivo para Segurança e Estabilidade continuará em operação de acordo com seus atuais princípios e práticas operacionais, até que o comitê tome outra providência. Imediatamente após a adoção desse Artigo de Transição, o Comitê Consultivo para Segurança e Estabilidade informará o Secretário da ICANN sobre a pessoa selecionada como seu delegado junto ao Comitê de Nomeação, conforme determina o artigo VII, seção 2(4) do Novo Estatuto..
4. Após a adoção do Novo Estatuto, o Comitê Consultivo para o Sistema de Servidor-Raiz continuará em operação de acordo com seus atuais princípios e práticas operacionais, até que o comitê tome outra providência. Imediatamente após a adoção desse Artigo de Transição, o Comitê Consultivo para Servidor-Raiz informará o Secretário da ICANN sobre a pessoa selecionada como seu delegado junto ao Comitê de Nomeação, conforme determina o artigo VII, seção 2(3) do Novo Estatuto..
5. Comitê Consultivo Geral (At-Large)
a. Haverá um Comitê Consultivo Geral Interino (At-Large) até que, por meio de um Memorando de Entendimento, a ICANN reconheça todas as Organizações At-Large Regionais (RALOs) identificadas no artigo XI, seção 2(4) do Novo Estatuto.. O Comitê Consultivo Geral Interino (At-Large) se comporá de (i) dez indivíduos (dois de cada região da ICANN) selecionados pelo Conselho da ICANN segundo indicações do Comitê de Organização At-Large e (ii) cinco indivíduos adicionais (um de cada região da ICANN) selecionados pelo Comitê de Nomeação inicial, tão logo quanto possível, em conformidade com os princípios estabelecidos no artigo VII, seção 5 do Novo Estatuto.. O Comitê de Nomeação inicial designará dois desses indivíduos para servirem até o final da reunião anual da ICANN em 2004, e dois indivíduos para servirem por mandatos até o final da reunião anual da ICANN em 2005.
b. Assim que cada uma das RALOs assinar esse Memorando de Entendimento, esta entidade estará qualificada para selecionar duas pessoas que sejam cidadãos e residentes da Região, para serem membros do Comitê Consultivo Geral (At-Large) estabelecido pelo artigo XI, seção 2(4) do Novo Estatuto.. Assim que esta entidade notificar formalmente o Secretário da ICANN dessas seleções, essas pessoas assumirão imediatamente os assentos antes ocupados pelos membros do Comitê Consultivo Geral Interino (At-Large), selecionados pelo Conselho entre as pessoas daquela Região.
c. Assim que as pessoas selecionadas pelas cinco RALOs tomarem posse dos seus cargos, o Comitê Consultivo Geral Interino (At-Large) passará a ser o Comitê Consultivo Geral (At-Large), como estabelece o artigo XI, seção 2(4) do Novo Estatuto.. Os cinco indivíduos selecionados pelo Comitê de Nomeação para o Comitê Consultivo Geral Interino (At-Large) passarão a ser membros do Comitê Consultivo Geral (At-Large) durante o restante do mandato para o qual foram selecionados.
d. Imediatamente após a sua criação, o Comitê Consultivo Geral Interino (At-Large) notificará o Secretário da ICANN das pessoas escolhidas como seus delegados junto ao Comitê de Nomeação, como determina o artigo VII, seção 2(6) do Novo Estatuto..
Os executivos da ICANN (segundo definição do artigo XIII do Novo Estatuto) serão eleitos pelo Conselho da ICANN em exercício por ocasião da reunião anual de 2002, e servirão até a reunião anual de 2003.
Seção 9. GRUPOS INDICADOS PELO PRESIDENTE
Não obstante a adoção ou vigência do Novo Estatuto, as forças-tarefa e outros grupos indicados pelo Presidente da ICANN não alterarão sua afiliação, seu escopo e sua operação até que o Presidente faça as eventuais mudanças.
Não obstante a adoção ou vigência do Novo Estatuto, todos os contratos, inclusive contratos de emprego e consultoria, firmados pela ICANN continuarão em efeito de acordo com a sua vigência.
Anexo A: Processo Normativo da GNSO
O seguinte processo regerá o processo normativo ("PDP") da GNSO até que o Conselho de Diretores da ICANN (o "Conselho de Diretores") receba recomendações e aprove modificações.
Qualquer um dos grupos abaixo pode apresentar um assunto como parte do PDP:
a. Iniciativa do Conselho de Diretores. O Conselho de Diretores pode iniciar o PDP instruindo o Conselho da GNSO ("Conselho") a começar o processo descrito neste Anexo.
b. Iniciativa do Conselho. O Conselho da GNSO pode dar início ao PDP pelo voto de pelo menos vinte e cinco por cento (25%) dos membros do Conselho presentes a qualquer reunião em que se apresentar uma moção para iniciar o PDP.
c. Iniciativa de um Comitê Consultivo. Um Comitê Consultivo pode apresentar um assunto para elaboração de políticas por decisão desse comitê em iniciar o PDP e transmissão desse pedido ao Conselho da GNSO.
2. Criação do Relatório de Assunto
No prazo de quinze (15) dias depois de receber (i) uma instrução do Conselho de Diretores; ou (ii) uma moção devidamente fundamentada de um membro do Conselho; ou (iii) uma moção devidamente fundamentada de um Comitê Consultivo, o Gerente da Equipe criará um relatório (um "Relatório de Assunto"). Cada Relatório de assunto conterá pelo menos os seguintes tópicos:
a. O assunto proposto submetido à consideração;
b. A identidade da parte que está submetendo o assunto;
c. Como a parte é afetada pelo assunto;
d. Apoio ao assunto para iniciar o PDP;
e. Uma recomendação do Gerente da Equipe sobre se o Conselho deve iniciar o PDP para esse tópico (a "Recomendação da Equipe"). Cada Recomendação da Equipe incluirá o parecer do Conselheiro Geral da ICANN sobre se o assunto pertence ao escopo do processo político da ICANN e se está dentro do âmbito da GNSO. Para chegar à sua conclusão, o Conselheiro Geral deverá verificar se o assunto:
1. pertence ao escopo da especificação da missão da ICANN;
2. pode ser aplicado genericamente a várias situações ou organizações;
3. potencialmente possui valor ou aplicabilidade duradouros, apesar da necessidade de atualizações ocasionais;
4. estabelecerá uma orientação ou arcabouço para as futuras tomadas de decisão; ou
5. se interfere com ou afeta uma política já existente da ICANN.
f. Antes ou até o prazo de quinze (15) dias, o Gerente da Equipe distribuirá o Relatório de Assunto a todo o Conselho, que decidirá o início ou não do PDP, conforme explanação abaixo.
O Conselho iniciará o PDP como segue:
a. Assunto apresentado pelo Conselho de Diretores. Se o Conselho de Diretores incumbir o Conselho de iniciar o PDP, o Conselho deverá encontrar-se e cumprir a incumbência no prazo de quinze (15) dias corridos, sem votações intermediárias do Conselho.
b. Assunto apresentado por outro grupo além do Conselho de Diretores. Se o Conselho receber um assunto normativo em relatório de Assunto para apreciação, o Conselho deverá reunir-se no prazo de quinze (15) dias corridos depois de receber o Relatório a fim de decidir se iniciará ou não o PDP. Esse encontro pode ser realizado da maneira mais conveniente para o Conselho, seja ao vivo, por teleconferência ou correio eletrônico.
c. Voto do Conselho. O voto de mais de 33% dos membros do Conselho presentes a favor do início do PDP será suficiente para iniciá-lo, a menos que a Recomendação da Equipe especifique que o assunto não pertence ao escopo do processo normativo da ICANN ou da GNSO. Nesse caso, o início do PDP exigirá a aprovação da supermaioria dos membros do Conselho presentes.
Durante a reunião do Conselho em que se iniciar o PDP, o Conselho decidirá, pelo voto da maioria dos membros presentes à reunião, se indicará ou não uma força-tarefa para tratar do assunto. Se o Conselho votar:
a. A favor da criação de uma força-tarefa, ele deverá fazê-lo de acordo com as disposições do Item 7 abaixo..
b. Contra a criação de uma força-tarefa, ele reunirá informações sobre o assunto, de acordo com as disposições do Item 8 abaixo..
5. Composição e seleção de forças-tarefa
a. Depois de votar para indicar uma força-tarefa, o Conselho convidará cada um dos grupos constituintes da GNSO para indicar um indivíduo que participe da força-tarefa. Além disso, o Conselho poderá indicar até três consultores externos a tomarem parte da força-tarefa. (Neste Anexo, cada membro da força-tarefa é denominado "Representante", e coletivamente, "os Representantes"). Se o Conselho considerar necessário ou conveniente, ele poderá aumentar o número de Representantes por grupo constituinte que participam de uma força-tarefa.
b. Qualquer grupo constituinte que desejar indicar um Representante para a força-tarefa deverá fornecer o nome dessa pessoa ao Gerente da Equipe no prazo de dez (10) dias corridos após o pedido, de modo que seja incluído na força-tarefa. Esse Representante não precisa ser membro do Conselho, mas deve ser um indivíduo com interesse e, de preferência, conhecimento e experiência no assunto em questão, além de ser capaz de dedicar uma quantidade significativa de tempo às atividades da força-tarefa.
c. O Conselho também pode empreender outras ações que julgar apropriadas para auxiliar no PDP, tais como indicar um determinado indivíduo ou organização para reunir informações sobre o assunto ou agendar reuniões para deliberação ou comunicação. Todas essas informações serão submetidas ao Gerente da Equipe no prazo de trinta e cinco (35) dias após o início do PDP.
6. Notificação do público sobre o início do PDP
Após o início do PDP, a ICANN publicará uma notificação do fato em seu Site. Em seguida, haverá um período de vinte (20) dias corridos para comentário do assunto, depois de iniciado o PDP. O Gerente da Equipe, ou outro representante designado por ICANN analisará os comentários do público e os incorporará em um relatório (o "Relatório de Comentários Públicos"), que será incluído no Relatório Preliminar da Força-tarefa ou no Relatório Inicial, conforme o caso.
a. Papel de uma força-tarefa. Quando se criar uma força-tarefa, a sua função será (i) obter informações que documentem os pontos de vista dos grupos constituintes formais e eventuais grupos constituintes provisórios da GNSO; e (ii) obter outras informações relevantes que permitam que o Relatório da Força-tarefa seja tão completo e informativo quanto possível.
A força-tarefa não terá nenhuma autoridade formal para tomar decisões. Ao contrário, o papel da força-tarefa será reunir informações que documentarão os pontos de vista de diversas partes e grupos, da maneira mais específica e abrangente possível, permitindo que o Conselho tome decisões significativas e bem fundamentadas sobre o assunto.
b. Pauta ou termos de referência da força-tarefa. Com a assistência do Gerente da Equipe, o Conselho elaborará uma pauta ou termos de referência para a força-tarefa (a "Pauta") no prazo de dez (10) dias após início do PDP. Essa pauta incluirá:
1. O assunto que será tratado pela força-tarefa, e como ele foi submetido a votação perante o Conselho que deu início ao PDP;
2. O cronograma específico que a força-tarefa deverá cumprir, conforme descrição abaixo, a menos que o Conselho de Diretores determine que existe um motivo premente para prorrogar o cronograma; e
3. As eventuais instruções específicas do Conselho para a força-tarefa, inclusive se a força-tarefa deve ou não solicitar a assessoria de consultores externos sobre o assunto.
A força-tarefa preparará seu relatório e conduzirá suas atividades em conformidade com a Pauta. Todos os pedidos para que ela se desvie dessa Pauta deverão ser apresentados formalmente ao Conselho, e somente serão atendidos pela força-tarefa com a aprovação da maioria dos membros do Conselho presentes à reunião.
c. Nomeação do presidente da força-tarefa. O Gerente da Equipe convocará a primeira reunião da força-tarefa no prazo de cinco (5) dias corridos após o recebimento da Pauta. Na reunião inicial, entre outras coisas os membros elegerão um presidente da força-tarefa. O presidente será responsável por organizar as atividades da força-tarefa, incluindo a elaboração do Relatório da Força-tarefa. O presidente de uma força-tarefa não precisa ser um membro do Conselho.
1. Declarações de Grupo Constituinte. Cada representante será responsável por solicitar a posição de seus grupos constituintes, pelo menos, e outros comentários que cada Representante julgar apropriado, considerando o assunto. Essa posição e outros comentários devem ser submetidos, conforme aplicável, em uma declaração formal ao presidente da força-tarefa (cada uma delas uma "Declaração de Grupo Constituinte") dentro do prazo de trinta e cinco (35) dias corridos após o início do PDP. Cada Declaração de Grupo Constituinte conterá pelo menos os seguintes tópicos:
(i) Se for alcançado o Voto da Supermaioria, uma declaração clara da posição do grupo constituinte em relação ao assunto;
(ii) Se não for alcançado o Voto da Supermaioria, uma declaração clara de todas as posições adotadas por membros do grupo constituinte;
(iii) Uma declaração clara de como o grupo constituinte chegou a sua(s) posição(ões). Especificamente, a declaração deve detalhar reuniões específicas de grupo constituinte, teleconferências, ou outros meios de deliberar sobre um assunto, e uma lista de todos os membros que participaram ou submeteram suas opiniões de outra forma;
(iv) Uma análise de como o assunto afetaria o grupo constituinte, incluindo qualquer impacto financeiro no grupo constituinte; e
(v) Uma análise do período de tempo que provavelmente seria necessário para implementar a política.
2. Conselheiros Externos. A força-tarefa, caso considere apropriado ou útil, pode solicitar o parecer de conselheiros externos, especialistas ou outros membros do público, além dos membros do grupo constituinte. Esses pareceres devem ser definidos em um relatório preparado pelos conselheiros externos, (i) claramente identificados como oriundos de conselheiros externos; (ii) acompanhados por uma declaração detalhada de (A) qualificações e experiência relevante dos conselheiros; e (B) possíveis conflitos de interesse. Esses relatórios devem ser submetidos em uma declaração formal ao presidente da força-tarefa dentro do prazo de trinta e cinco (35) dias corridos após o início do PDP.
e. Relatório da Força-tarefa. O presidente da força-tarefa, trabalhando com o Gerente da Equipe, compilará as Declarações do Grupo Constituinte, Relatório de Comentários Públicos e outras informações ou relatórios, conforme aplicável, em um único documento (o "Relatório Preliminar da Força-tarefa") e distribuirá o Relatório Preliminar da Força-tarefa para a força-tarefa inteira dentro do prazo de quarenta (40) dias corridos depois do início do PDP. A força-tarefa terá uma reunião de força-tarefa final dentro do prazo de cinco (5) dias depois da data de distribuição do Relatório Preliminar da Força-tarefa para deliberar sobre os assuntos e tentar alcançar o Voto da Supermaioria. Dentro do prazo de cinco (5) dias corridos depois da reunião da força-tarefa, o presidente da força-tarefa e o Gerente da Equipe criarão o relatório final da força-tarefa (o "Relatório da Força-tarefa") e o publicarão no Site de Comentário. Cada Relatório da Força-tarefa deve conter:
1. Uma declaração clara de qualquer posição de Voto da Supermaioria da força-tarefa no assunto;
2. Se não for alcançado o Voto da Supermaioria, uma declaração clara de todas as posições adotadas por membros da força-tarefa submetidas dentro do cronograma de vinte dias para envio de relatórios de grupo constituinte. Cada declaração deve indicar claramente (i) as razões subjacentes à posição e (ii) o(s) grupo(s) constituinte(s) que adota(m) a posição;
3. Uma análise de como o problema afetaria cada grupo constituinte da força-tarefa, incluindo qualquer impacto financeiro no grupo constituinte;
4. Uma análise do período de tempo que provavelmente seria necessário para implementar a política; e
5. A orientação de quaisquer conselheiros externos indicados pelo Conselho para a força-tarefa, acompanhada por uma declaração detalhada de (i) qualificações e experiência relevante dos conselheiros; e (ii) possíveis conflitos de interesse.
8. Procedimento se nenhuma força-tarefa for formada
a. Se o Conselho decidir não convocar uma força-tarefa, ele solicitará que, dentro dos dez (10) dias corridos posteriores, cada grupo constituinte indique um representante para solicitar as opiniões do grupo constituinte sobre o assunto. Deve ser solicitado que cada um desses representantes submeta uma Declaração de Grupo Constituinte ao Gerente da Equipe no prazo de trinta e cinco (35) dias corridos após o início do PDP.
b. O Conselho também pode empreender outras ações que julgar apropriadas para auxiliar no PDP, tais como indicar um determinado indivíduo ou organização para reunir informações sobre o assunto ou agendar reuniões para deliberação ou comunicação. Todas essas informações serão submetidas ao Gerente da Equipe no prazo de trinta e cinco (35) dias após o início do PDP.
c. O Gerente da Equipe tomará todas as Declarações do Grupo Constituinte, Declarações de Comentários Públicos e outras informações e compilará (e publicará no Site de Comentário) um Relatório Inicial dentro do prazo de cinqüenta (50) dias corridos após o início do PDP. Posteriormente, o PDP seguirá as disposições do Item 9 abaixo para criar um Relatório Final.
9. Comentários Públicos ao Relatório da Força-tarefa ou Relatório Inicial
a. Haverá um período de vinte (20) dias corridos para o comentário público, após a publicação do Relatório da Força-tarefa ou Relatório Inicial. Qualquer indivíduo ou organização pode enviar comentários durante o período de comentário público, incluindo qualquer grupo constituinte que não tenha participado da força-tarefa. Todos os comentários serão acompanhados pelo nome do autor, sua experiência relevante e seu interesse no assunto.
b. No fim do período de vinte (20) dias, o Gerente de Equipe será responsável por analisar os comentários recebidos e adicionar os que considerar apropriados a seu critério razoável para inclusão no Relatório da Força-tarefa ou Relatório Inicial (coletivamente, o "Relatório Final"). O Gerente da Equipe não será obrigado a incluir todos os comentários feitos durante o período de comentário, incluindo todos os comentários feitos por qualquer indivíduo ou organização.
c. O Gerente da Equipe preparará o Relatório Final e o submeterá ao presidente do Conselho dentro de dez (10) dias corridos após o fim do período de comentário público.
a. Ao receber um Relatório Final, seja como resultado de uma força-tarefa ou de outra forma, o presidente do Conselho (i) distribuirá o Relatório Final a todos os membros do Conselho; e (ii) convocará uma reunião do Conselho dentro dos dez (10) dias posteriores. O Conselho pode começar sua deliberação sobre o assunto antes da reunião formal, inclusive por meio de reuniões ao vivo, teleconferência, discussões por e-mail ou qualquer outro meio que o Conselho possa escolher. O processo de deliberação culminará em uma reunião do Conselho formal seja ao vivo ou via teleconferência, na qual o Conselho trabalhará para alcançar o Voto da Supermaioria para apresentar à Diretoria.
b. O Conselho pode, se assim escolher, solicitar os pareceres de conselheiros externos em sua reunião final. Os pareceres desses conselheiros, se consultados pelo Conselho, devem ser (i) incorporados ao relatório do Conselho para a Diretoria, (ii) identificados especificamente como oriundos de um conselheiro externo e (iii) acompanhados por uma declaração detalhada de (x) qualificações e experiência relevante dos conselheiros; e (y) possíveis conflitos de interesse.
11. Relatório do Conselho para a Diretoria
O Gerente da Equipe estará presente na reunião final do Conselho e terá cinco (5) dias corridos após a reunião para incorporar os pareceres do Conselho em um relatório a ser submetido à Diretoria (o "Relatório da Diretoria"). Cada Relatório da Diretoria deve conter pelo menos os seguintes tópicos:
a. Uma declaração clara de qualquer recomendação de Voto da Supermaioria do Conselho;
b. Se não for alcançado o Voto da Supermaioria, uma declaração clara de todas as posições adotadas por membros do Conselho. Cada declaração deve indicar claramente (i) as razões subjacentes a cada posição e (ii) o(s) grupo(s) constituinte(s) que adota(m) a posição;
c. Uma análise de como o assunto afetaria cada grupo constituinte, incluindo qualquer impacto financeiro no grupo constituinte;
d. Uma análise do período de tempo que provavelmente seria necessário para implementar a política;
e. A orientação de quaisquer conselheiros externos consultados, que deve ser acompanhada por uma declaração detalhada de (i) qualificações e experiência relevante dos conselheiros; e (ii) possíveis conflitos de interesse.
f. O Relatório Final submetido ao Conselho; e
g. Uma cópia das minutas da deliberação do Conselho sobre o assunto da política, incluindo todas as opiniões expressas durante essa deliberação, acompanhada por uma descrição de quem expressou essas opiniões.
Um Voto da Supermaioria dos membros do Conselho será considerado reflexo da opinião do Conselho e pode ser transmitido à Diretoria como recomendação do Conselho. Abstenções não serão permitidas, assim todos os membros do Conselho devem votar a menos que identifiquem um interesse financeiro no resultado do assunto da política. Não obstante o precedente, conforme declarado acima, todos os pontos de vista expressos pelos membros do Conselho durante o PDP devem ser incluídos no Relatório da Diretoria.
a. A Diretoria se reunirá para discutir as recomendações do Conselho da GNSO assim que for viável, após o recebimento pelo Gerente da Equipe do Relatório da Diretoria.
b. Caso o Conselho alcance o Voto da Supermaioria, a Diretoria adotará a política de acordo com a recomendação do Voto da Supermaioria do Conselho, a menos que uma votação de mais de sessenta e seis por cento (66%) da Diretoria determine que essa política não é o melhor para a comunidade da ICANN ou a ICANN.
c. Caso a Diretoria determine não agir de acordo com a recomendação do Voto da Supermaioria do Conselho, a Diretoria (i) articulará os motivos para suas determinações em um relatório ao Conselho (a "Declaração da Diretoria"); e (ii) enviará a Declaração da Diretoria ao Conselho.
d. O Conselho analisará a Declaração da Diretoria para discussão com a Diretoria dentro do prazo de vinte (20) dias corridos após o recebimento da Declaração da Diretoria pelo Conselho. O Conselho determinará o método (por exemplo, por teleconferência, e-mail ou outro modo) pelo qual o Conselho e a Diretoria discutirão a Declaração da Diretoria.
e. Na conclusão das discussões do Conselho e da Diretoria, o Conselho se reunirá para afirmar ou modificar sua recomendação e comunicar essa conclusão (a "Recomendação Suplementar") à Diretoria, incluindo uma explicação por sua recomendação atual. No caso em que o Conselho possa chegar a um Voto de Supermaioria na Recomendação Suplementar, a Diretoria adotará a recomendação a menos que um voto de mais de sessenta e seis por cento (66%) da Diretoria determine que essa política não é o melhor para a comunidade da ICANN ou a ICANN.
f. Em qualquer caso em que o Conselho não possa alcançar a Supermaioria, uma votação majoritária da Diretoria será suficiente para agir.
g. Quando uma decisão final em uma Recomendação do Conselho da GNSO ou Recomendação Suplementar for oportuna, o Conselho fará um voto preliminar e, quando praticável, publicará uma decisão temporária que permita um período de dez (10) dias de comentário público antes de uma decisão final da Diretoria.
Após a decisão final da Diretoria, ela autorizará ou orientará a equipe da ICANN, conforme apropriado, a tomar todas as medidas necessárias para implementar a política.
Durante o PDP, da sugestão da política a uma decisão final da Diretoria, a ICANN manterá no site uma página de status detalhando o progresso de cada assunto do PDP, que descreverá:
a. A sugestão inicial para uma política;
b. Uma lista de todas as sugestões que não resultam na criação de um Relatório de Assunto;
c. O cronograma a ser seguido para cada política;
d. Todas as discussões entre o Conselho relativas à política;
e. Todos os relatórios de forças-tarefa, o Gerente da Equipe, o Conselho e a Diretoria; e
"Site de Comentário" e "Website" se referem a um ou mais sites da Web designados pela ICANN nos quais notificações e comentários relativos ao PDP serão publicados.
"Gerente da Equipe" significa a(s) pessoa(s) da equipe da ICANN que gerencia(m) o PDP.
"Voto da Supermaioria" significa um voto de mais de sessenta e seis (66) por cento dos membros presentes em uma reunião do corpo aplicável.
Anexo B: Processo de Desenvolvimento de Política da ccNSO (ccPDP)
O processo seguinte governará o processo de desenvolvimento de política da ccNSO ("PDP").
1. Solicitação de um Relatório de Assunto
Um Relatório de Assunto pode ser solicitado por qualquer dos órgãos seguintes:
a. Conselho. O Conselho da ccNSO (neste Anexo B, o "Conselho") pode convocar a criação de um Relatório de Assunto por um voto afirmativo de pelo menos sete dos membros do Conselho presentes em qualquer reunião ou que votem por e-mail.
b. Diretoria. A Diretoria da ICANN pode convocar a criação de um Relatório de Assunto solicitando que o Conselho comece o processo de desenvolvimento de política.
c. Organização Regional. Uma ou mais das Organizações Regionais que representam ccTLDS nas Regiões reconhecidas da ICANN podem convocar a criação de um Relatório de Assunto solicitando que o Conselho comece o processo de desenvolvimento de política.
d. Organização de Suporte ou Comitê Consultivo da ICANN. Uma Organização de Suporte da ICANN ou um Comitê Consultivo da ICANN podem convocar a criação de um Relatório de Assunto solicitando que o Conselho comece o processo de desenvolvimento de política.
e. Membros da ccNSO. Os membros da ccNSO podem convocar a criação de um Relatório de Assunto por um voto afirmativo de pelo menos dez membros da ccNSO presentes em qualquer reunião ou que votem por e-mail.
Qualquer solicitação de um Relatório de Assunto deve ser por escrito e deve definir o assunto no qual um Relatório de Assunto é solicitado em detalhe suficiente para permitir que o Relatório de Assunto seja preparado. Estará a critério do Conselho solicitar informações adicionais ou realizar pesquisa ou investigação adicional com o fim de determinar se o Relatório de Assunto solicitado deve ser criado.
2. Criação do Relatório de Assunto e Limite de Início
Depois de sete dias de um voto afirmativo descrito no Item 1 (a) acima ou do recebimento de uma solicitação conforme descrito nos Itens 1 (b), (c) ou (d) acima, o Conselho indicará um Gerente de Assunto. O Gerente de Assunto pode ser um membro da equipe da ICANN (caso em que os custos do Gerente de Assunto serão assumidos pela ICANN) ou outra(s) pessoa(s) selecionada(s) pelo Conselho (caso em que a ccNSO será responsável pelos custos do Gerente de Assunto).
Dentro do prazo de quinze (15) dias corridos depois da indicação (ou outro período que o Conselho, em consulta ao Gerente de Assunto, considerar apropriado), o Gerente de Assunto criará um Relatório de Assunto. Cada Relatório de Assunto conterá pelo menos os seguintes tópicos:
a. O assunto proposto submetido à consideração;
b. A identidade da parte que está submetendo o assunto;
c. Como a parte é afetada pelo assunto;
d. Apoio ao assunto para iniciar o PDP;
e. Uma recomendação do Gerente de Assunto sobre se o Conselho deve agir para iniciar o PDP para esse assunto (a "Recomendação do Gerente"). Cada Recomendação de Gerente incluirá e será apoiada pelo parecer do Conselheiro Geral da ICANN sobre se o assunto pertence ao escopo do processo da política da ICANN e se está dentro do âmbito da ccNSO. Para chegar ao seu parecer, o Conselheiro Geral examinará se:
1) O assunto pertence ao escopo da declaração da missão da ICANN;
2) A análise dos fatores relevantes de acordo com o Artigo IX, Seção 6(2) e Anexo C demonstra afirmativamente que o assunto está dentro do escopo da ccNSO;
Caso o Conselheiro Geral chegue a um parecer afirmativo com relação aos pontos 1 e 2 acima, o Conselheiro Geral também considerará se o assunto:
3) Implica ou afeta uma política da ICANN existente;
4) É provável que tenha valor ou aplicabilidade duradoura, apesar da necessidade de atualizações ocasionais, e que estabeleça um guia ou estrutura para tomada de decisões futuras.
Em todos os casos, a consideração de revisões à ccPDP (este Anexo B) ou ao escopo da ccNSO (Anexo C) pertencerá ao escopo da ICANN e da ccNSO.
Caso o Conselheiro Geral considere que o assunto não é adequado dentro do escopo da ccNSO, o Gerente de Assunto informará sua opinião ao Conselho. Se depois de uma análise dos fatores relevantes de acordo com o Artigo IX, Seção 6 e Anexo C, uma maioria de 10 ou mais membros do Conselho considerar que o assunto está dentro do escopo, o Presidente da ccNSO informará o Gerente de Assunto adequadamente. O Conselheiro Geral e o Conselho da ccNSO se envolverão em um diálogo de acordo com as normas e procedimentos acordados para resolver o problema. No caso em que nenhum acordo seja alcançado entre o Conselheiro Geral e o Conselho sobre se o assunto está dentro ou fora do Escopo da ccNSO, depois de uma votação de 15 ou mais membros, o Conselho poderá decidir que o assunto está dentro do escopo. O Presidente da ccNSO informará o Conselheiro Geral e o Gerente de Assunto adequadamente. O Gerente de Assunto prosseguirá com a recomendação sobre se o Conselho deve ou não agir para iniciar o PDP, incluindo o parecer e a análise do Conselheiro Geral e do Conselho no Relatório de Assunto.
f. No caso em que a Recomendação do Gerente seja a favor de iniciar o PDP, um cronograma proposto para conduzir cada um dos estágios do PDP descritos neste documento (Cronograma de PDP).
g. Se possível, o relatório de assunto indicará se a saída obtida resultará provavelmente em uma política a ser aprovada pela Diretoria da ICANN. Em algumas circunstâncias, não será possível fazer isso até que discussões substanciais sobre o assunto tenham ocorrido. Nesses casos, o relatório de assunto deve indicar essa incerteza. Ao concluir o Relatório de Assunto, o Gerente de Assunto o distribuirá para o Conselho inteiro para uma votação sobre se o PDP será iniciado.
3. Início do PDP
O Conselho decidirá se o PDP será iniciado da seguinte maneira:
a. Dentro do prazo de 21 dias após o recebimento de um Relatório de Assunto do Gerente de Assunto, o Conselho votará se o PDP deverá ser iniciado. Essa votação deve ser realizada em uma reunião mantida de qualquer maneira considerada apropriada pelo Conselho, incluindo ao vivo ou por teleconferência; porém, se uma reunião não for viável, a votação poderá ocorrer por e-mail.
b. Uma votação de dez ou mais membros do Conselho a favor de iniciar o PDP será necessária para iniciar o PDP, desde que o Relatório de Assunto afirme que o assunto está adequadamente dentro do escopo da declaração de missão da ICANN e do Escopo da ccNSO.
4. Decisão quanto à indicação da força-tarefa; estabelecimento de cronograma
Na reunião do Conselho onde o PDP foi iniciado (ou onde o Conselho utiliza uma votação por e-mail) de acordo com o Item 3 acima, o Conselho decidirá, pelo voto da maioria dos membros presentes à reunião (ou que votem por e-mail), se indicará ou não uma força-tarefa para tratar do assunto. Se o Conselho votar:
a. A favor da criação de uma força-tarefa, ele deverá fazê-lo de acordo com o Item 7 abaixo.
b. Contra a criação de uma força-tarefa, ele reunirá informações sobre o assunto, de acordo com o Item 8 abaixo.
O Conselho também deverá, por um voto da maioria dos membros presentes na reunião ou que votem por e-mail, aprovar ou emendar e aprovar o Cronograma do PDP definido no Relatório de Assunto.
5. Composição e seleção de forças-tarefa
a. Depois de votar para indicar uma força-tarefa, o Conselho convidará cada uma das Organizações Regionais (consulte Artigo IX, Seção 6) para indicar dois indivíduos para participar da força-tarefa (os "Representantes"). Além disso, o Conselho pode indicar até três conselheiros (os "Conselheiros") de fora da ccNSO e, após a solicitação formal para participação do GAC na Força-tarefa, aceitar até dois Representantes do Comitê Consultivo Governamental como membros da força-tarefa. Se a Assembléia considerar necessário ou conveniente, ela poderá aumentar o número de Representantes que participam de uma força-tarefa.
b. Qualquer Organização Regional que desejar indicar Representantes para a força-tarefa deverá fornecer os nomes dos Representantes ao Gerente de Assunto no prazo de dez (10) dias corridos após o pedido, de modo que sejam incluídos na força-tarefa. Esses Representantes não precisam ser membros do Conselho, mas cada um deles deve ser um indivíduo com interesse e, de preferência, conhecimento e experiência no assunto em questão, além de ser capaz de dedicar uma quantidade significativa de tempo às atividades da força-tarefa.
c. O Conselho também pode empreender outras ações que julgar apropriadas para auxiliar no PDP, tais como indicar um determinado indivíduo ou organização para reunir informações sobre o assunto ou agendar reuniões para deliberação ou comunicação. Todas essas informações serão submetidas ao Gerente de Assunto de acordo com o Cronograma do PDP.
6. Notificação pública sobre o início do PDP e período de comentário
Depois do início do PDP, a ICANN publicará uma notificação dessa ação no site e em outras Organizações de Apoio e Comitês Consultivos da ICANN. Um período de comentário (de acordo com o Cronograma do PDP, normalmente com pelo menos 21 dias) será iniciado para o assunto. Os comentários serão aceitos de gerentes da ccTLD, outras Organizações de Apoio, Comitês Consultivos e do público. O Gerente de Assunto, ou outro representante designado pelo Conselho, analisará os comentários e os incorporará em um relatório (o "Relatório de Comentários"), que será incluído no Relatório Preliminar da Força-tarefa ou no Relatório Inicial, conforme adequado.
7. Forças-tarefa
a. Papel de uma força-tarefa. Quando uma força-tarefa for criada, a sua função será (i) coletar informações que documentem os pontos de vista dos membros da ccNSO nas Regiões Geográficas e outras partes ou grupos; e (ii) obter outras informações relevantes que permitam que o Relatório da Força-tarefa seja tão completo e informativo quanto possível para facilitar a deliberação bem fundamentada e significativa do Conselho.
A força-tarefa não terá nenhuma autoridade formal para tomar decisões. Ao contrário, o papel da força-tarefa será reunir informações que documentarão os pontos de vista de diversas partes e grupos, da maneira mais específica e abrangente possível, permitindo que o Conselho tome decisões significativas e bem fundamentadas sobre o assunto.
b. Pauta ou termos de referência da força-tarefa. Com a assistência do Gerente de Assunto, o Conselho elaborará uma pauta ou termos de referência para a força-tarefa (a "Pauta") no prazo designado no cronograma do PDP. Essa pauta incluirá:
1. O assunto que será tratado pela força-tarefa, e como ele foi submetido à votação perante o Conselho que deu início ao PDP;
2. O cronograma específico que a força-tarefa deverá cumprir, conforme descrição abaixo, a menos que o Conselho determine que existe um motivo premente para prorrogar o cronograma; e
3. As eventuais instruções específicas do Conselho para a força-tarefa, inclusive se a força-tarefa deve ou não solicitar a assessoria de consultores externos sobre o assunto.
A força-tarefa preparará seu relatório e conduzirá suas atividades em conformidade com a Pauta. Todos os pedidos para que ela se desvie dessa Pauta deverão ser apresentados formalmente ao Conselho, e somente serão atendidos pela força-tarefa com a aprovação da maioria dos membros do Conselho presentes à reunião ou que votem por e-mail. Os requisitos de quorum do Artigo IX, Seção 3(14) serão aplicados às ações do Conselho de acordo com este Item 7(b).
c. Nomeação do presidente da força-tarefa. O Gerente de Assunto convocará a primeira reunião da força-tarefa no prazo designado no Cronograma do PDP. Na reunião inicial, entre outras coisas, os membros elegerão o presidente da força-tarefa. O presidente será responsável por organizar as atividades da força-tarefa, incluindo a elaboração do Relatório da Força-tarefa. O presidente de uma força-tarefa não precisa ser um membro do Conselho.
d. Coleta de informações.
1. Declarações da Organização Regional. Cada Representante será responsável por solicitar a posição da Organização Regional em relação a sua Região Geográfica, pelo menos, e pode solicitar outros comentários, conforme cada Representante considerar apropriado, incluindo os comentários dos membros da ccNSO na região que não sejam membros da Organização Regional, referentes ao assunto sendo considerado. A posição da Organização Regional e quaisquer outros comentários coletados por Representantes devem ser enviados em uma declaração formal ao presidente da força-tarefa (cada uma delas uma "Declaração Regional") dentro do prazo designado no Cronograma do PDP. Cada Declaração Regional conterá pelo menos os seguintes tópicos:
(i) Se for alcançado o Voto da Supermaioria (conforme definido pela Organização Regional), uma declaração clara da posição da Organização Regional em relação ao assunto;
(ii) Se não for alcançado o Voto da Supermaioria, uma declaração clara de todas as posições adotadas por membros da Organização Regional;
(iii) Uma declaração clara de como a Organização Regional chegou a essa(s) posição(ões). Especificamente, a declaração deve detalhar reuniões específicas, teleconferências ou outros meios de deliberar sobre um problema, e uma lista de todos os membros que participaram ou enviaram suas opiniões de outra forma;
(ii) Uma declaração da posição no assunto de quaisquer membros da ccNSO que não sejam membros da Organização Regional;
(iv) Uma análise de como o assunto afetaria a Região, incluindo qualquer impacto financeiro na Região; e
(vi) Uma análise do período de tempo que provavelmente seria necessário para implementar a política.
2. Conselheiros Externos. A força-tarefa pode solicitar, a seu próprio critério, a opinião de conselheiros externos, especialistas ou outros membros do público. Essas opiniões devem ser definidas em um relatório preparado pelos conselheiros externos, e (i) claramente identificadas como oriundas de conselheiros externos; (ii) acompanhadas por uma declaração detalhada de (a) qualificações e experiência relevante dos conselheiros e (b) possíveis conflitos de interesse. Esses relatórios devem ser submetidos em uma declaração formal ao presidente da força-tarefa dentro do prazo designado do Cronograma do PDP.
e. Relatório da Força-tarefa. O presidente da força-tarefa, trabalhando com o Gerente de Equipe, compilará as Declarações Regionais, o Relatório de Comentários Públicos e outras informações ou relatórios, conforme aplicável, em um único documento (o "Relatório de Força-tarefa Preliminar") e distribuirá o Relatório de Força-tarefa Preliminar para a força-tarefa inteira dentro do prazo designado no Cronograma do PDP. A força-tarefa terá uma reunião da força-tarefa final para considerar os assuntos e tentar alcançar o Voto da Supermaioria. Depois da reunião final da força-tarefa, o presidente da força-tarefa e o Gerente de Assunto criarão o relatório final da força-tarefa (o "Relatório da Força-tarefa") e o publicará no Site e em outras Organizações de Apoio e Comitês Consultivos da ICANN. Cada Relatório da Força-tarefa deve conter:
1. Uma declaração clara de qualquer posição de Voto da Supermaioria (sendo 66% da força-tarefa) da força-tarefa no assunto;
2. Se não for alcançado o Voto da Supermaioria, uma declaração clara de todas as posições adotadas por membros da força-tarefa submetidas dentro do cronograma de envio de relatórios do grupo constituinte. Cada declaração deve indicar claramente (i) as razões subjacentes a cada posição e (ii) as Organizações Regionais que adotam a posição;
3. Uma análise de como o assunto afetaria cada Região, incluindo qualquer impacto financeiro na Região;
4. Uma análise do período de tempo que provavelmente seria necessário para implementar a política; e
5. A orientação de quaisquer conselheiros externos indicados para a força-tarefa pelo Conselho, acompanhada por uma declaração detalhada de (i) qualificações e experiência relevante dos conselheiros e (ii) possíveis conflitos de interesse.
8. Procedimento se nenhuma força-tarefa for formada
a. Se o Conselho decidir não convocar uma força-tarefa, cada Organização Regional indicará, dentro do prazo designado no Cronograma do PDP, um representante para solicitar as opiniões da Região sobre o assunto. Será solicitado que cada um desses representantes submeta uma Declaração Regional ao Gerente de Assunto dentro do prazo designado no Cronograma do PDP.
b. O Conselho também pode, a seu critério, tomar outras medidas para auxiliar no PDP, tais como indicar um determinado indivíduo ou organização para reunir informações sobre o assunto ou agendar reuniões para deliberação ou comunicação. Todas essas informações serão submetidas ao Gerente de Assunto dentro do prazo designado no Cronograma do PDP.
c. O Conselho solicitará formalmente ao Presidente do GAC que ofereça parecer ou orientação.
d. O Gerente de Assunto tomará todas as Declarações Regionais, o Relatório de Comentários e outras informações e compilará (e publicará no Site) um Relatório Inicial dentro do prazo designado no Cronograma do PDP. Posteriormente, o Gerente de Assunto criará, de acordo com o Item 9 abaixo, um Relatório Final.
9. Comentários ao Relatório da Força-tarefa ou Relatório Inicial
a. Um período de comentário (de acordo com o Cronograma do PDP, normalmente com pelo menos 21 dias) será aberto para comentários no Relatório da Força-tarefa ou Relatório Inicial. Os comentários serão aceitos de gerentes da ccTLD, outras Organizações de Apoio, Comitês Consultivos e do público. Todos os comentários conterão o nome do autor, sua experiência relevante e seu interesse no assunto.
b. No fim do período de comentário, o Gerente de Problema analisará os comentários recebidos e pode adicionar os que considerar apropriados a seu critério razoável para inclusão no Relatório de Força-tarefa ou Relatório Inicial, para preparar o "Relatório Final". O Gerente de Assunto não será obrigado a incluir todos os comentários feitos durante o período de comentário, nem será obrigado a incluir todos os comentários enviados por qualquer indivíduo ou organização.
c. O Gerente de Assunto preparará o Relatório Final e o submeterá ao presidente do Conselho dentro do prazo designado no Cronograma do PDP.
10. Deliberação do Conselho
a. Ao receber um Relatório Final, seja como resultado de uma força-tarefa ou de outra forma, o presidente do Conselho (i) distribuirá o Relatório Final a todos os membros do Conselho; (ii) convocará uma reunião do Conselho dentro do prazo designado no Cronograma do PDP, no qual o Conselho trabalhará para chegar a uma recomendação para apresentá-la à Diretoria; e (iii) enviará formalmente ao Presidente do GAC um convite para que o GAC ofereça parecer ou orientação. Essa reunião pode ser realizada de qualquer forma considerada apropriada pelo Conselho, incluindo pessoalmente ou por teleconferência. O Gerente de Assunto estará presente à reunião.
b. O Conselho pode começar sua deliberação sobre o assunto anterior à reunião formal, incluindo por meio de reuniões ao vivo, teleconferências, conversas por e-mail ou qualquer outro meio que o Conselho possa escolher.
c. O Conselho pode, se assim escolher, solicitar os pareceres de conselheiros externos em sua reunião final. Os pareceres desses conselheiros, caso consultados pelo Conselho, devem ser (i) incorporadas ao relatório da Diretoria, (ii) identificados especificamente como oriundos de um conselheiro externo e (iii) acompanhados por uma declaração detalhada de (a) qualificações e experiência relevante dos conselheiros e (b) possíveis conflitos de interesse.
11. Recomendação do Conselho
Ao considerar se faz uma recomendação sobre o assunto (uma "Recomendação do Conselho"), o Conselho buscará agir em consenso. Se uma minoria se opuser a uma posição de consenso, essa minoria preparará e distribuirá para o Conselho uma declaração explicando suas razões para oposição. Se a discussão do Conselho da declaração não resultar em consenso, então uma recomendação apoiada por 14 ou mais dos membros do Conselho será considerada para refletir a opinião do Conselho e será transmitida aos Membros como Recomendação do Conselho. Não obstante o precedente, conforme declarado abaixo, todos os pontos de vista expressos pelos membros do Conselho durante o PDP devem ser incluídos no Relatório dos Membros.
12. Relatório do Conselho para os Membros
Caso uma Recomendação do Conselho seja adotada de acordo com o Item 11, o Gerente de Assunto incorporará, dentro do prazo de sete dias após a reunião do Conselho, a Recomendação do Conselho junto com quaisquer outros pontos de vista de membros do Conselho em um Relatório de Membros a ser aprovado pelo Conselho e depois submetido aos Membros (o "Relatório de Membros"). O Relatório de Membros deve conter pelo menos os seguintes tópicos:
a. Uma declaração clara da recomendação do Conselho;
b. O Relatório Final submetido ao Conselho; e
c. Uma cópia das minutas da deliberação do Conselho sobre o assunto da política (ver Item 10), incluindo todas as opiniões expressas durante essa deliberação, acompanhada por uma descrição de quem expressou essas opiniões.
13. Voto dos membros
Em seguida ao envio do Relatório dos Membros e dentro do tempo designado pelo Cronograma do PDP, os membros da ccNSO terão a oportunidade de votar na Recomendação do Conselho. O voto dos membros serão eletrônicos e ficarão registrados por um período de tempo conforme designado no Cronograma do PDP (pelo menos 21 dias).
Caso pelo menos 50% dos membros da ccNSO registrem votos no período de votação, a votação resultante será aplicada sem processo adicional. Caso menos de 50% dos membros da ccNSO registrem votos na primeira rodada de votação, a primeira rodada não será aplicada, e os resultados de uma segunda rodada final de votação, conduzida depois de pelo menos trinta dias do aviso aos membros da ccNSO, serão aplicados se pelo menos 50% dos membros da ccNSO registrarem votos. Caso mais de 66% dos votos recebidos ao final do período de votação sejam a favor da Recomendação do Conselho, a recomendação será transmitida à Diretoria de acordo com o Item 14 abaixo, conforme a Recomendação da ccNSO.
14. Relatório da Diretoria
O Gerente de Assunto, dentro do prazo de sete dias depois de uma Recomendação da ccNSO realizada de acordo com o Item 13, incorporará a Recomendação da ccNSO em um relatório a ser aprovado pelo Conselho e depois a ser submetido à Diretoria (o "Relatório da Diretoria"). Cada Relatório da Diretoria deve conter pelo menos os seguintes tópicos:
a. Uma declaração clara da recomendação da ccNSO;
b. O Relatório Final submetido ao Conselho; e
c. O Relatório dos Membros.
15. Voto da Diretoria
a. A Diretoria se reunirá para discutir a Recomendação da ccNSO logo que viável após o recebimento do Relatório da Diretoria do Gerente de Assunto, levando em conta procedimentos para consideração da Diretoria.
b. A Diretoria adotará a Recomendação da ccNSO a menos que uma votação de mais de 66% da Diretoria determine que essa política não é o melhor para a comunidade da ICANN ou a ICANN.
1. Caso o Conselho determine não agir de acordo com a Recomendação da ccNSO, a Diretoria (i) articulará os motivos para suas determinações em um relatório ao Conselho (a "Declaração da Diretoria"); e (ii) submeterá a Declaração da Diretoria ao Conselho.
2. O Conselho discutirá a Declaração da Diretoria com a Diretoria dentro do prazo de trinta dias depois que a Declaração da Diretoria for submetida ao Conselho. A Diretoria determinará o método (por exemplo, por teleconferência, e-mail ou outro modo) pelo qual o Conselho e a Diretoria discutirão a Declaração da Diretoria. As discussões serão mantidas em boa-fé e de uma maneira eficiente e oportuna para localizar uma solução mutuamente aceitável.
3. Na conclusão das discussões do Conselho e da Diretoria, o Conselho se reunirá para afirmar ou modificar a Recomendação do Conselho. Uma recomendação apoiada por 14 ou mais dos membros do Conselho será considerada para refletir a opinião do Conselho ("a Recomendação Suplementar" do Conselho). Essa Recomendação Suplementar será transmitida aos Membros em um Relatório Suplementar dos Membros, incluindo uma explicação para a Recomendação Suplementar. Os membros devem ter uma oportunidade para votar na Recomendação Suplementar nas mesmas condições descritas no Item 13. Caso mais de 66% dos votos depositados pelos Membros da ccNSO durante o período de votação sejam a favor da Recomendação Suplementar, essa recomendação deverá ser transmitida à Diretoria como a Recomendação Suplementar da ccNSO, e a Diretoria adotará a recomendação a menos que uma votação de mais de 66% da Diretoria determine que a aceitação dessa política constituiria uma violação dos deveres fiduciários da Diretoria para a Empresa.
4. Caso a Diretoria não aceite a Recomendação Suplementar da ccNSO, ela afirmará seus motivos para fazer isso em sua decisão final ("Declaração Suplementar da Diretoria").
5. Caso a Diretoria determine que não aceita uma Recomendação Suplementar da ccNSO, a Diretoria não terá direito a definir a política no assunto abordado pela recomendação e o status quo será preservado até o momento em que a ccNSO, de acordo com a ccPDP, faça uma recomendação sobre o assunto que seja considerada aceitável pela Diretoria.
16. Implementação da política
Após a adoção pela Diretoria de uma Recomendação da ccNSO ou Recomendação Suplementar da ccNSO, a Diretoria orientará ou autorizará, conforme adequado, a equipe da ICANN a implementar a política.
17. Manutenção de registros
Com relação a cada ccPDP para qual um Relatório de Assunto foi solicitado (consulte o Item 1), a ICANN manterá no site uma página de status detalhando o progresso de cada ccPDP, que fornecerá uma lista de datas relevantes para a ccPDP e também vinculará aos documentos seguintes, até a extensão que tenham sido preparados de acordo com a ccPDP:
a. Relatório de Assunto;
b. Cronograma de PDP;
c. Relatório de Comentário;
d. Declaração(ões) Regional(is);
e. Relatório Preliminar da Força-tarefa;
f. Relatório da Força-tarefa;
g. Relatório Inicial;
h. Relatório Final;
i. Relatório dos Membros;
j. Relatório da Diretoria;
k. Declaração da Diretoria;
l. Relatório Suplementar de Membros; e
m. Declaração Suplementar da Diretoria.
Além disso, a ICANN publicará no site comentários recebidos em formato escrito eletrônico, sugerindo especificamente que uma ccPDP seja iniciada.
Este anexo descreve o escopo e os princípios e métodos de análise a serem usados em qualquer desenvolvimento adicional do escopo da função de desenvolvimento de política da ccNSO. Conforme determinações no Artigo IX, Seção 6(2) do Estatuto, esse escopo será definido de acordo com os procedimentos da ccPDP.
O escopo da autoridade e das responsabilidades da ccNSO devem reconhecer a relação complexa entre a ICANN e os gerentes/registros da ccTLD referentes a assuntos da política. Este anexo auxiliará a ccNSO, o Conselho da ccNSO e a Diretoria e a equipe da ICANN a delinear os assuntos de política global relevantes.
Áreas da política
A função da política da ccNSO deve ser baseada em uma análise do seguinte modelo funcional da DNS:
1. Os Dados são registrados/mantidos para gerar um arquivo de zona,
2. Um arquivo de zona é em seguida usado nos servidores de nome do TLD.
Dentro de um TLD duas funções precisam ser desempenhadas (elas são abordadas em mais detalhes abaixo):
1. Inserção de dados em um banco de dados (Função de Entrada de Dados) e
2. Manutenção e garantia de manutenção de servidores de nome para o TLD (Função de Servidor de Nome).
Essas duas funções centrais devem ser realizadas no nível do registro da ccTLD bem como no nível superior (função e servidores raiz da IANA) e em níveis inferiores da hierarquia do DNS. Esse mecanismo, como a RFC 1591 propõe, é recursivo:
Não existem requisitos em subdomínios de domínios de nível superior além dos requisitos nos próprios domínios de nível superior. Isto é, os requisitos neste memorando são aplicáveis recursivamente. Em particular, todos os subdomínios serão permitidos para operar seus próprios servidores de nome de domínio, fornecendo neles quaisquer informações que o gerente de subdomínio considere adequadas (desde que verdadeiras e corretas).
As funções centrais
1. Função de Entrada de Dados (DEF):
Examinando em um nível mais detalhado, a primeira função (entrada e manutenção de dados em um banco de dados) deve ser totalmente definida por uma política de nomeação. Essa política de nomeação deve especificar as regras e condições:
(a) sob quais dados serão coletados e inseridos em um banco de dados ou dados alterados (no nível de TLD entre outros, dados que reflitam uma transferência de registrante para registrante ou a mudança do registrador) no banco de dados.
(b) para tornar determinados dados geral e publicamente disponíveis (seja, por exemplo, através de Whois ou servidores de nome).
2. A Função de Servidor de Nome (NSF)
A função de servidor de nome envolve assuntos de interoperabilidade e estabilidade essenciais no núcleo do sistema de nome de domínio. A importância dessa função se estende aos servidores de nome no nível da ccTLD, mas também aos servidores raiz (e sistema de servidor raiz) e servidores de nome em níveis inferiores.
Em seu próprio mérito e devido a considerações de interoperabilidade e estabilidade, servidores de nome em funcionamento adequado são da máxima importância para o indivíduo, bem como para as comunidades locais e globais da Internet.
Com relação à função de servidor de nome; portanto, as políticas precisam ser definidas e estabelecidas. A maior parte das partes envolvidas, incluindo a maioria dos registros da ccTLD, aceitaram a necessidade de políticas comuns nessa área aderindo aos RFCs relevantes, entre outros a RFC 1591.
Funções respectivas com relação à política, responsabilidades e prestações de contas
É do interesse da ICANN e dos gerentes da ccTLD garantir o funcionamento estável e adequado do sistema de nome de domínio. A ICANN e os registradores da ccTLD têm uma função distintiva cada a ser desempenhada com relação a isso que pode ser definida pelas políticas relevantes. O escopo da ccNSO não pode ser estabelecido sem chegar a um entendimento comum da alocação de autoridade entre ICANN e os registradores da ccTLD.
Três funções podem ser reconhecidas para as quais a responsabilidade deve ser atribuída em qualquer assunto:
- Função da política: isto é, a habilidade e poder para definir a política;
- Função executiva: isto é, a habilidade e poder de agir e implementar a política; e
- Função de responsabilidade: isto é, a habilidade e poder de manter a entidade responsável por exercer seu poder.
Primeiramente, a responsabilidade pressupõe uma política e isso delineia a função da política. Dependendo do assunto que precisa ser abordado, os envolvidos na definição da política necessária precisam ser determinados e definidos. Em segundo lugar, ela pressupõe uma função executiva que define o poder para implementar e agir dentro dos limites de uma política. Finalmente, para se contrapor à função executiva, a função de responsabilidade precisa ser definida e determinada.
As informações abaixo oferecem um auxílio para:
1. delinear e identificar áreas de política específicas;
2. definir e determinar funções com relação a essas áreas de política específicas.
Este anexo define o escopo da ccNSO referente às políticas de desenvolvimento. O escopo é limitado à função de política do processo de desenvolvimento de política da ccNSO para funções e níveis explicitamente declarados abaixo. Prevê-se que a precisão das atribuições das funções executiva, de política e responsabilidade mostradas abaixo será considerada durante o processo da ccPDP de definição de escopo.
Função de Servidor de Nome (com relação às ccTLDs)
Nível 1: Servidores de Nome Raiz
Função da política: IETF, RSSAC (ICANN)
Função executiva: Operadores do sistema de servidor raiz
Função de responsabilidade: RSSAC (ICANN), (US DoC-ICANN MoU)Nível 2: Servidores de Nome de Registrador da ccTLD referentes à interoperabilidade
Função da política: Processo de Desenvolvimento de Política da ccNSO (ICANN), como prática recomendada um processo da ccNSO pode ser organizado
Função executiva: Gerente da ccTLD
Função de responsabilidade: parte ICANN (IANA), parte Comunidade da Internet Local, incluindo governo localNível 3: Servidores de Nome do Usuário
Função da política: Gerente da ccTLD, IETF (RFC)
Função executiva: Registrante
Função de responsabilidade: Gerente da ccTLD
Função de Entrada de Dados (com relação às ccTLDs)
Nível 1: Registrador de Nível Raiz
Função da política: Processo de Desenvolvimento de Política da ccNSO (ICANN)
Função executiva: ICANN (IANA)
Função de responsabilidade: Comunidade da ICANN, Gerentes da ccTLD, US DoC, (autoridades nacionais em alguns casos)Nível 2: Registrador da ccTLD
Função da política: Comunidade da Internet Local, incluindo governo local, e/ou Gerente da ccTLD de acordo com a estrutura local
Função executiva: Gerente da ccTLD
Função de responsabilidade: Comunidade da Internet Local, incluindo autoridades nacionais em alguns casosNível 3: Segundo nível e níveis inferiores
Função da política: Registrante
Função executiva: Registrante
Função de responsabilidade: Registrante, usuários de nomes de domínio de nível inferior