Grupo de Assistência para a ccNSO: Síntese das recomendações

26 de fevereiro de 2003

Grupo de Assistência da ccNSO
Síntese das recomendações
(para discussão durante a reunião no Rio de Janeiro)
26 de fevereiro de 2003

Índice

Introdução

I. Recomendações sobre o escopo

II. Recomendações sobre o Processo Normativo (Policy Development Process  - ccPDP)

III. Recomendações sobre membresia

IV. Recomendações sobre o Conselho

V. Recomendações sobre a estrutura

Introdução

O Grupo de Assistência para a ccNSO (GA da ccNSO) foi formado em setembro de 2002 para auxiliar o Comitê de Desenvolvimento e Reforma de ICANN por meio da apresentação de recomendações sobre uma estrutura e um conjunto de procedimentos operacionais para a Organização de Apoio a Nomes de Códigos de Países (ccNSO), prevista no Programa Geral. O Grupo de Assistência foi formado por gerentes de ccTLDs, participantes do GAC e outros membros conhecidos da comunidade. Todos os participantes contribuíram com o Grupo de Assistência em suas habilidades individuais, e contribuíram com base em seus pontos de vista e experiências pessoais.

O Grupo de Assistência realizou o seu trabalho por meio de teleconferências, discussões on-line, e alguns membros tiveram reuniões pessoais. O GA da ccNSO elaborou recomendações para 5 áreas identificadas no Programa Geral. Essas áreas eram: o escopo da ccNSO como entidade normativa global; o processo normativo na ccNSO; a membresia, a estrutura e o Conselho da ccNSO.

Ao desenvolver o seu plano de trabalho, o GA da ccNSO procurou aproveitar o trabalho prévio da comunidade de registros de ccTLDs e de outros Grupos de Assistência do ERC. A existência de trabalhos anteriores foi de grande ajuda nos esforços do GA da ccNSO para elaborar recomendações.

Em seu trabalho, o Grupo de Assistência procurou moldar uma estrutura de alto nível e recomendações que auxiliem na formação de uma Organização de Apoio que tenha os componentes e as ferramentas para dedicar-se oficialmente às necessidades da coordenação global efetiva da ICANN. O Grupo de Assistência reconheceu a história complexa do gerenciamento do DNS e suas estruturas experimentais para oferecer uma metodologia sólida no futuro, a fim de construir a confiança na ccNSO como um dos principais componentes do Sistema Universal de Nomes de Domínio e o desenvolver o papel coletivo dos ccTLDs no gerenciamento global da Internet na ICANN.

O plano de trabalho do GA da ccNSO já foi publicado, e é o seguinte:

• Recomendações preliminares sobre o escopo
• Publicadas em 22 de outubro de 2002
• Resposta 28 de outubro de 2002 (reunião de Xangai)
• Comunicado do GA da cNSO após consulta ao Grupo Constituinte para ccTLDs
• Recomendações preliminares sobre o Processo Normativo
• Publicadas em 11 de novembro de 2002
• Esclarecimento: 29 de novembro de 2002
• Resposta: 10 de dezembro de 2002
• Recomendação preliminar sobre membresia
• Publicada em 10 de dezembro de 2002
• Resposta: 24 de dezembro de 2002
• Recomendações preliminares sobre o Conselho
• Publicadas em 24 de dezembro de 2002
• Resposta: 14 de janeiro de 2003
• Recomendações preliminares sobre a estrutura
• Publicadas em 28 de janeiro de 2003
• Resposta: 7 de fevereiro de 2003

Neste documento, o GA da ccNSO define suas recomendações sobre as cinco categorias do seu plano de trabalho, a saber: o escopo da ccNSO, o Processo Normativo (PDP) da ccNSO, a membresia, o Conselho e a estrutura da ccNSO. As recomendações aqui reunidas foram publicadas e comentadas individualmente, de acordo com o cronograma acima.

I. Recomendações sobre o escopo

O propósito da ccNSO é engajar-se e dirigir atividades relevantes para domínios de alto nível de códigos de países, especificamente através 

1. Da elaboração de recomendações políticas ao Conselho Administrativo da ICANN;
2. Da promoção do consenso entre a comunidade da ccNSO, incluindo as atividades dos ccTLDs relativas a nomes; e
3. Da colaboração com outras Organizações de Apoio, comitês ou eleitorados da ICANN.

O escopo da autoridade e das responsabilidades da ccNSO deve levar em conta o relacionamento complexo entre ICANN e os gerentes/registros de ccTLDs no que se refere a questões políticas.

Áreas políticas

Para identificar o papel político da ccNSO, o Grupo de Assistência baseou suas análises no seguinte modelo funcional do DNS:

1. Os dados são registrados/mantidos para gerar um arquivo de zona,
2. Por sua vez, um arquivo de zona é usado em servidores de nomes de TLDs.

Portanto, um TLD deverá desempenhar duas funções (que serão abordadas mais detalhadamente a seguir):

1. Registrar dados em uma base de dados (DEF) e
2. Manter e garantir a atualização de servidores de nomes para o TLD (NSF).

Essas duas funções fundamentais precisam ser efetuadas no nível de registros de TLD, bem como em um nível mais elevado (função IANA e Servidores-Raiz) e em níveis mais baixos (como, p. ex., .eu.com) da hierarquia do DNS. Esse mecanismo, como indica a RFC 1591, é recursivo.

"Não existem exigências sobre sub-domínios de domínios de alto nível além das exigências para os próprios domínios de níveis mais elevados. Isto é, as exigências neste memorando aplicam-se de modo recursivo. Particularmente, todos os sub-domínios terão permissão para operar seus próprios servidores de nomes de domínio, oferecendo neles todas as informações que o gerente de sub-domínio julgar apropriadas (desde que sejam verdadeiras e corretas)."

Ao longo dos últimos cinco ou seis anos, o número de nomes de domínio registrados cresceu exponencialmente. Em conseqüência, o impacto do DNS sobre a sociedade e as expectativas da sociedade em relação ao DNS também cresceram de maneira significativa. Como resultado, a primeira função (DEF) tornou-se mais importante em seu próprio direito (em retrospectiva: de uma função auxiliar para servidores de nomes, ela evoluiu para a segunda função fundamental).

Pelos mesmos motivos algumas funções latentes ou secundárias também passaram a ser importantes por mérito próprio (como, por exemplo, WHOIS). No entanto, essas funções adicionadas são derivadas, e apenas secundárias em relação às duas funções centrais mencionadas acima e não são necessárias (do ponto de vista técnico) para operar um TLD.

As funções fundamentais

1. Função de registro de dados (DEF):

Se olharmos mais detalhadamente para a primeira função, registrar e manter dados em uma base de dados, ela deve ser definida totalmente por uma política de atribuição de nomes. Essa política de atribuição de nomes deve especificar as normas e condições:

(a) segundo as quais os dados serão reunidos e registrados em uma base de dados ou alterados nessa base de dados (no nível de TLDs, entre outros, os dados para indicar uma transferência de um registrante para outro, ou a mudança de um registrador);

(b) para tornar determinados dados disponíveis de maneira pública e geral (por exemplo dados WHOIS ou de servidores de nomes).

2. A função de servidor de nomes (NSF)

A função de servidor de nomes envolve questões essenciais para a interoperabilidade e estabilidade no núcleo do sistema de nomes de domínio. O propósito essencial de usar nomes de domínio reflete-se nesta função do sistema de nomes de domínio. A importância dessa função estende-se aos servidores de nomes no nível de TLDs, mas também aos servidores-raiz (sistema) e servidores de nomes em níveis mais baixos. O registro e manutenção de dados PARA A FINALIDADE DE USAR NOMES DE DOMÍNIO NO DNS são inúteis, a menos que essa função seja desempenhada adequadamente.

Por seus próprios méritos e por causa dos aspectos de interoperabilidade e estabilidade, o funcionamento correto dos servidores de nomes é de extrema importância para a comunidade de  indivíduos, bem como para a comunidade local e global da Internet.

Portanto, no que se refere à função de servidor de nomes, é necessário definir e criar políticas. Por sua natureza, essas políticas são mais técnicas. Grande parte dos envolvidos, incluindo a maioria dos registros de ccTLDs, aceitou a necessidade de políticas nesta área, aderindo às RFC relevantes, entre outras, a RFC1591.

À medida que o uso de nomes de domínio aumentou, as abordagens necessárias ou úteis para assegurar o funcionamento apropriado do DNS também mudaram ao longo do tempo. Está claro que as questões importantes não são mais cobertas totalmente pela RFC 1591, ou mesmo pelo ICP-1. Por exemplo, como resultado das mudanças na tecnologia, a RFC não abrange mais todos os aspectos relevantes para garantir o bom andamento da função de servidores de nomes.

Papel dos gerentes de ccTLDs e da ICANN em relação à política e as respectivas responsabilidades.

É do interesse da ICANN e dos gerentes de ccTLDs garantir o funcionamento estável e apropriado do sistema de nomes de domínio. Tanto ICANN quanto os registros de ccTLDs têm um papel distinto a desempenhar neste aspecto, definido pelas políticas relevantes.

O escopo apropriado da ccNSO não pode ser definido sem que se obtenha um entendimento comum da divisão de autoridade entre ICANN e os registros de ccTLDs. Portanto, o GA da ccNSO discutiu exaustivamente as maneiras de diferenciar assuntos de natureza local, e que por isso devem ser resolvidos em nível local (isto é, pelo registro de ccTLD), e aqueles que devem ser resolvidos em nível global (ou seja, pela comunidade da ICANN).

O GA da ccNSO também distingue três elementos ou papéis, cuja responsabilidade deve ser definida em todas as questões:

Papel político: significa a capacidade e o poder de definir uma política;

Papel executivo: significa a capacidade e o poder de adotar e implementar a política;

Papel de atribuição de responsabilidade: significa a capacidade e o poder de responsabilizar a entidade em questão pelo exercício de seu poder.

Primeiramente, a responsabilidade pressupõe uma política, e isso implica em uma função política. Dependendo do assunto a ser tratado, será necessário definir aqueles que estarão envolvidos em definir e estabelecer a política. Em segundo lugar, a definição do poder de implementar e agir dentro dos limites de uma política pressupõe um papel executivo. E finalmente, como contraponto ao papel executivo, é necessário definir o papel de atribuição de responsabilidade.

Estrutura para análise:

Se combinarmos as duas perspectivas - ou seja, as funções e responsabilidades, teremos a seguinte estrutura:

Tal como é apresentada acima, a estrutura oferece a possibilidade de:

1. Delinear e identificar áreas políticas específicas;
2. Definir e determinar papéis em relação a essas áreas políticas específicas.

Quanto a esse delineamento, naturalmente sempre existe uma interação entre precisão/granularidade e viabilidade.

A estrutura apresenta as recomendações do Grupo de Assistência da ccNSO em relação a uma divisão apropriada e viável da responsabilidade entre os ccTLDs e outros participantes. O Grupo de Assistência reconhece que esta estrutura eventualmente precisará de ajustes para refletir as mudanças na tecnologia ou em outras áreas que possam afetar as idéias da comunidade sobre a definição e atribuição de papéis no DNS. Embora a tarefa e o escopo do GA da ccNSO não incluam explicitamente a apresentação de recomendações sobre o papel de atribuição de responsabilidade, está claro que será necessário um arcabouço de responsabilidade entre os registros de ccTLDs e ICANN e que provavelmente isso terá impacto sobre a estrutura apresentada.

II. Recomendações sobre o processo normativo (ccPDP)

O GA da ccNSO usou o Processo Normativo (PDP) da GNSO como ponto de partida para suas recomendações sobre o PDP da ccNSO. Quando a situação o exigia, fizeram-se os ajustes necessários para a ccNSO.

O processo seguinte regerá o processo normativo ("PDP") da ccNSO até que a ccNSO recomende modificações ao Conselho de Diretores da ICANN ("Diretoria") e este as aprove. A ccNSO elaborará essas recomendações mediante o PDP.

1. Dando início a um Relatório de Assunto

Qualquer um dos grupos seguintes poderá solicitar um Relatório de Assunto, que dá início a um ccPDP:

(a) Conselho. O Conselho da cNSO ("Conselho") poderá requerer a criação de um Relatório de Assunto mediante a aprovação de pelo menos 7 membros do Conselho presentes a qualquer reunião na qual se propõe uma moção para iniciar o processo normativo.

(b) Diretoria. A Diretoria da ICANN poderá requerer a criação de um Relatório de Assunto solicitando que o Conselho da ccNSO inicie o processo normativo.

(c) Organização Regional. Uma ou mais Organizações Regionais que  representam as regiões reconhecidas por ICANN podem dar início a um Relatório de Assunto solicitando que o Conselho comece o processo normativo.

(d) Organização de Apoio ou Comitê Consultivo da ICANN. Uma Organização de Apoio ou um Comitê Consultivo da ICANN pode iniciar um Relatório de Assunto, solicitando que o Conselho comece o processo normativo.

Todos os pedidos de Relatórios de Assunto devem ser feitos por escrito e deverão especificar o assunto ao qual se refere o Relatório com detalhes suficientes para permitir que o Relatório de Assunto seja elaborado. Ficará a critério do Conselho solicitar outras informações ou empreender outras pesquisas ou investigações para determinar se o Relatório de Assunto deve ou não ser criado.

2. Criação do Relatório de Assunto

No prazo de 7 dias após a aprovação conforme o item 1 a) acima ou após o recebimento de um pedido conforme os itens 1 b), c) e d) acima, o Conselho indicará um Gerente de Assunto. O Gerente de Assunto pode ser um membro da equipe da ICANN (e nesse caso os custos do Gerente de Assunto ficarão a cargo da ICANN) ou outra pessoa ou pessoas selecionada(s) pelo Conselho (e neste caso, a ccNSO será responsável pelos custos do Gerente de Assunto).

Quinze (15) dias corridos após a indicação (ou em outra data que o Conselho, em consulta ao Gerente de Assunto, considerar apropriada), o Gerente de Assunto criará um Relatório de Assunto. Cada Relatório de Assunto incluirá pelo menos os seguintes elementos:

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 iniciar o PDP para esse tópico (a "Recomendação do Gerente"). Cada Recomendação do Gerente incluirá o parecer do Conselheiro Geral da ICANN sobre se o assunto pertence ao escopo do processo político da ICANN, ou se pertence aos ccTLDs. 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) Pertence ao escopo da ccNSO de acordo com a Matriz do Escopo da ccNSO;

Se o Conselheiro Geral concluir que a resposta aos pontos 1 e 2 acima é afirmativa, ele também deverá analisar se o assunto

3) Interfere com ou afeta uma política já existente da ICANN;

4) Terá valor ou aplicação duradouros, não obstante a necessidade de atualizações ocasionais, e se ele estabelecerá um guia ou estrutura para a futura tomada de decisões; ou

f. Na eventualidade de a Recomendação do Gerente ser a favor do início de um PDP, uma proposta de cronograma para conduzir cada um dos estágios do PDP aqui delineado;

Após a conclusão do Relatório de Assunto, o Gerente de Assunto o distribuirá para todo o Conselho, que decidirá o início ou não do PDP.

3. Início do PDP

O Conselho decidirá se iniciará o PDP da seguinte maneira:

a. 21 dias após o recebimento de um Relatório de Assunto do Gerente de Assunto, o Conselho irá reunir-se para votar se iniciará o PDP ou não. Essa reunião pode ser marcada da maneira considerada apropriada pelo Conselho, inclusive pessoalmente, através de teleconferência ou correio eletrônico.

b. O voto de 10 ou mais membros do Conselho a favor do início do PDP será suficiente para iniciar o PDP, CONTANTO QUE a recomendação do Gerente de Assunto especifique que o assunto pertence ao escopo da missão da ICANN ou da Matriz do Escopo da ccNSO. Se o Gerente de Assunto afirmar que o assunto não pertence ao escopo, será necessário o voto favorável de 12 ou mais membros do Conselho para iniciar o PDP.

4. Início do PDP

Durante a reunião do Conselho em que se iniciar o PDP conforme a Seção 3 acima, 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 a Seção 7 abaixo.

b. Contra a criação de uma força-tarefa, ele reunirá informações sobre o assunto, de acordo com a Seção 8 abaixo.

Além disso, se tiver o voto da maioria dos membros presentes à reunião, o Conselho também deverá aprovar ou emendar e aprovar o cronograma para a realização do PDP estabelecido no Relatório de Assunto (o "Cronograma do PDP", item 2-e-5 ou 2-f).

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 para indicar dois indivíduos a participar da força-tarefa (os "Representantes"). Além disso, o Conselho poderá indicar até três consultores externos (os "Consultores") a tomarem parte da força-tarefa. Se o Conselho considerar necessário ou conveniente, ele 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 devem ser indivíduos com interesse e, de preferência, conhecimento e experiência no assunto em questão, além de serem capazes 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, em conformidade com o Cronograma do PDP.

6. Notificação pública do início do PDP e período para comentários

Depois de dar início ao PDP, ICANN publicará uma notificação desse fato no site da ICANN e informará as outras Organizações de Apoio e Comitês Consultivos da ICANN. Haverá um período para comentários (de acordo com o Cronograma do PDP) para o envio de comentários de gerentes de ccTLDs, outras Organizações de Apoio, Comitês Consultivos e do público. O Gerente de Assunto ou outro representante do Conselho designado para tal irá analisar os comentários e integrá-los em um relatório (o "Relatório do Início") que, por sua vez, será incluído no Relatório Preliminar da Força-Tarefa ou no Relatório Inicial, conforme o caso.

7. Forças-Tarefa

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 das Regiões e de outros grupos e partes; 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 possibilitar que o Conselho tome decisões significativas e bem fundamentadas.

A força-tarefa não terá nenhuma outra 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 determinado pelo Cronograma 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 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 serão atendidos pela força-tarefa com a aprovação da maioria dos membros do Conselho presentes à reunião.

c. Indicação do presidente da força-tarefa. O Gerente de Assunto agendará a primeira reunião da força-tarefa dentro do prazo previsto no Cronograma do PDP. 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.

d. Coleta de informações.

1. Especificações das Organizações Regionais. Cada Representante será responsável por solicitar o ponto de vista de sua Organização Regional, no mínimo, e poderá solicitar outros comentários que julgar apropriados, dependendo do assunto em consideração. O ponto de vista da Organização Regional e os outros comentários reunidos pelos Representantes serão enviados sob forma de uma declaração formal ao presidente da força-tarefa (a "Declaração Regional") no prazo indicado pelo Cronograma do PDP. Cada Declaração Regional incluirá no mínimo o seguinte:

(i) Caso se tenha obtido o voto da supermaioria (conforme definição da Organização Regional), uma descrição clara do ponto de vista da Organização Regional sobre o assunto;

(ii) Caso não se tenha atingido o voto da supermaioria, uma descrição de todos os pontos de vista defendidos pelos membros da Organização Regional;

(iii) Uma descrição clara de como a Organização Regional chegou à sua conclusão. Mais especificamente, a declaração deverá detalhar as reuniões, teleconferências ou outros meios usados para deliberar sobre o assunto, e uma lista de todos os membros que participaram ou enviaram seus pontos de vista;

(iv) Uma análise de como o assunto afetaria a Região, abordando também o impacto financeiro sobre a Região; e

(v) Uma análise do período de tempo provável para implementar a política.

2. Consultores externos. A seu critério, a força-tarefa poderá solicitar a opinião de consultores e especialistas externos, ou de outros membros do público. As opiniões destes deverão ser especificadas em um relatório elaborado por esses consultores externos e (i) identificadas claramente como provenientes de consultores externos; (ii)  acompanhadas de uma descrição detalhada (a) das qualificações e experiência do consultor no assunto; e (b) dos conflitos de interesse em potencial. Esses relatórios serão encaminhados ao presidente da força-tarefa em uma declaração formal, no prazo determinado pelo Cronograma do PDP.

e. Relatório da força-tarefa. Trabalhando em conjunto com o Gerente de Assunto, o presidente da força-tarefa irá compilar as Declarações Regionais e as outras informações e relatórios, se houver, em um único documento (o "Relatório Preliminar da Força-Tarefa") e distribui-las para toda a força-tarefa dentro do prazo determinado pelo Cronograma do PDP. A força-tarefa fará  uma reunião final para deliberar sobre os assuntos e tentar obter o voto da supermaioria. Após a reunião final da força-tarefa, o presidente da força-tarefa e o Gerente de Assunto elaborarão o relatório final da força-tarefa (o "Relatório da Força-Tarefa") e o publicarão no site da ICANN, além de encaminhá-lo às outras Organizações de Apoio e Comitês Consultivos. Cada Relatório de uma Força-Tarefa deverá incluir:

1. Uma indicação clara quando houver o voto da supermaioria (equivalente a 66% da força-tarefa) da força-tarefa sobre o assunto;

2. Quando não se atingir o voto da supermaioria, uma indicação clara de todas as posições defendidas pelos membros da força-tarefa e apresentadas durante o prazo de encaminhamento de relatórios. Cada declaração deverá indicar claramente (i) as razões que fundamentam a posição e (ii) as Organizações Regionais que defenderam aquela posição;

3. Uma análise de como o assunto afetaria cada Região, incluindo o eventual impacto financeiro sobre a Região;

4. Uma análise do período de tempo que provavelmente seria necessário para implementar a política; e

5. As recomendações de todos os consultores externos indicados para a força-tarefa pelo Conselho, acompanhadas de uma descrição detalhada das qualificações e da experiência dos consultores e dos conflitos de interesse em potencial.

8. Procedimento caso não se forme uma força-tarefa

a. Se o Conselho decidir não criar uma força-tarefa, cada Organização Regional deverá, dentro do prazo determinado pelo Cronograma do PDP, indicar um representante que solicitará as perspectivas da Região sobre o assunto. Cada um desses representantes deverá submeter uma Declaração Regional ao Gerente de Assunto dentro do prazo indicado no Cronograma do PDP.

b. A seu critério, o Conselho poderá tomar outras medidas para assistir o PDP, por exemplo, indicando um determinado indivíduo ou organização para  obter 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 determinado pelo Cronograma do PDP.

c. O Gerente de Assunto reunirá todas as Declarações Regionais e outras informações e as compilará em um Relatório Inicial dentro do prazo determinado pelo Cronograma do PDP, publicando esse Relatório no site para comentários. Em seguida, de acordo com a Seção 9 abaixo, o PDP criará um Relatório Final.

9. Comentários sobre o Relatório da Força-Tarefa ou Relatório Inicial

a. Haverá um período para comentários (de acordo com o Cronograma do PDP) para comentários sobre o Relatório da Força-Tarefa ou sobre o Relatório Inicial. Poderão enviar comentários os gerentes de ccTLDs, outras Organizações de Apoio, Comitês Consultivos ou o público em geral. Todos os comentários deverão incluir o nome do autor, sua experiência e seu interesse no assunto.

b. No final do período para comentário, o Gerente de Assunto analisará os comentários recebidos e poderá, a seu critério, acrescentar comentários apropriados ao Relatório da Força-Tarefa ou ao Relatório Inicial (denominados coletivamente de "Relatório Final"). O Gerente de Assunto não será obrigado a incluir todos os comentários apresentados durante o período para comentários, nem será obrigado a incluir todos os comentários enviados por um indivíduo ou organização.

c. O Gerente de Assunto preparará o Relatório Final e o encaminhará ao presidente do Conselho dentro do prazo determinado no Cronograma do PDP.

10. Deliberação do Conselho

a. Depois de receber um Relatório Final, seja como resultado do trabalho de uma força-tarefa ou de outra forma, o presidente do Conselho distribuirá o Relatório Final a todos os membros do Conselho e convocará uma reunião do Conselho dentro do prazo determinado pelo Cronograma do PDP, na qual o Conselho tentará elaborar uma recomendação que será apresentada à ccNSO (os "Membros"), a fim de que estes a aprovem e em seguida a recomendem à Diretoria. Essa reunião poderá ser agendada da maneira que o Conselho considerar adequada, podendo ser pessoalmente, por teleconferência ou correio eletrônico. O Gerente de Assunto deverá estar presente à reunião.

b. O Conselho poderá iniciar sua deliberação sobre o assunto antes da reunião formal, inclusive através de reuniões pessoais, teleconferências, discussões por e-mail ou outros meios que o Conselho escolher.

c. Se assim o desejar, o Conselho poderá solicitar a opinião de consultores externos em sua reunião final. Se o Conselho se basear nas opiniões desses consultores, elas deverão ser (i) integradas ao relatório do Conselho à Diretoria, (ii) identificadas especificamente como provenientes de um consultor externo, e (iii) acompanhadas de uma descrição detalhada das qualificações e experiência do consultor no assunto e dos conflitos de interesse em potencial.

11. Recomendação do Conselho

Uma recomendação que tiver o apoio de 12 ou mais membros do Conselho será considerada reflexo do ponto de vista do Conselho e os Membros poderão apresentá-la como Recomendação do Conselho. Não obstante o texto precedente, conforme indicamos abaixo, todos os pontos de vista expressados pelos membros do Conselho durante o PDP deverão ser incluídos no Relatório dos Membros.

12. Relatório do Conselho aos Membros

Caso se adote uma Recomendação do Conselho de acordo com a Seção 11, no prazo de 7 dias após a reunião do Conselho o Gerente de Assunto deverá integrar a Recomendação do Conselho juntamente com todos os outros pontos de vista dos membros do Conselho em um Relatório dos Membros, a ser aprovado pelo Conselho e depois submetido aos Membros (o "Relatório dos Membros"). O Relatório dos Membros deverá conter no mínimo o seguinte:

a. Uma descrição clara da recomendação do Conselho;

b. O Relatório Final submetido ao Conselho; e

c. Uma cópia das atas da deliberação do Conselho sobre a política, incluindo todas as opiniões expressadas durante a deliberação, acompanhadas por uma descrição de quem manifestou as opiniões.

13. Votação dos Membros

Após a apresentação do Relatório dos Membros e no prazo indicado no Cronograma do PDP, os membros terão a oportunidade de votar sobre a Recomendação do Conselho. A votação dos membros será eletrônica e os votos serão recolhidos durante o período designado no Cronograma do PDP.

Se mais de 66 por cento dos votos recebidos no final do período de votação forem a favor da Recomendação do Conselho, a recomendação será transmitida à Diretoria como a Recomendação da ccNSO, de acordo com a Seção 14 abaixo.

14. Relatório para a Diretoria

Sete (7) dias depois do encaminhamento de uma Recomendação da ccNSO de acordo com a Seção 13, o Gerente de Assunto incorporará a Recomendação da ccNSO em um relatório a ser aprovado pelo Conselho e depois encaminhado à Diretoria (o "Relatório para a Diretoria"). O Relatório para a Diretoria deverá conter pelo menos o seguinte:

i. Uma especificação clara da recomendação da ccNSO;

ii. O Relatório Final e o Relatório dos Membros submetido ao Conselho; e

iii. Uma cópia das atas da deliberação do Conselho sobre o assunto, incluindo todas as opiniões expressadas durante essa deliberação, acompanhadas de uma descrição de quem manifestou essas opiniões.

15. Votação da Diretoria

a. A Diretoria irá encontrar-se para discutir a Recomendação da ccNSO tão logo seja possível depois de receber o Relatório para a Diretoria do Gerente de Assunto.

b. A Diretoria adotará a Recomendação da ccNSO, a menos que mais de sessenta e seis por cento (66%) dos votos da Diretoria determinem que essa política não é do interesse da comunidade da ICANN ou da ICANN.

1. Na eventualidade de a Diretoria decidir não seguir a Recomendação da ccNSO, a Diretoria deverá (i) descrever os motivos da sua decisão de não seguir a Recomendação da ccNSO em um relatório para o Conselho (a "Declaração da Diretoria") e (ii) encaminhar a Declaração da Diretoria ao Conselho.

2. O Conselho irá analisar a Declaração da Diretoria, para discuti-la com a Diretoria no prazo indicado no Cronograma do PDP. A Diretoria determinará o método (p. ex., através de teleconferência, e-mail ou de outra forma) através do qual o Conselho e a Diretoria discutirão a Declaração da Diretoria. As discussões serão feitas em boa-fé, de maneira rápida e eficiente, a fim de encontrar uma solução aceita pelas duas partes.

3. No final das discussões do Conselho e da Diretoria, o Conselho deverá reunir-se para confirmar ou modificar sua Recomendação do Conselho e comunicar essa conclusão (a "Recomendação Suplementar") aos Membros, em um Relatório Suplementar aos Membros, incluindo uma explicação sobre sua recomendação atual. Os membros terão oportunidade de votar sobre a Recomendação Suplementar nas mesmas condições descritas na Seção 13. Se mais de 66% dos votos obtidos durante o período de votação forem a favor da Recomendação Suplementar, esta será encaminhada à Diretoria como Recomendação Suplementar da ccNSO, e a Diretoria a adotará, a menos que sessenta e seis por cento (66%) da Diretoria determine que essa política não é do interesse da ICANN ou da comunidade da ICANN.

4. Na eventualidade de a Diretoria não aceitar a Recomendação Suplementar da ccNSO, ela especificará seus motivos em sua decisão final ("Declaração Suplementar da Diretoria").

5. Quando a Diretoria decidir não aceitar uma Recomendação Suplementar da ccNSO, a Diretoria não terá autoridade para estabelecer normas para o assunto ao qual se refere a recomendação e a situação deverá ser mantida até o momento em que a ccNSO fizer uma recomendação sobre o assunto que seja considerada aceitável segundo esse Processo Normativo.

16. Implementação da Política

Depois que a Diretoria adotar uma Recomendação da ccNSO ou uma Recomendação Suplementar da ccNSO, a Diretoria orientará ou autorizará a equipe da ICANN a implementar a norma.

17. Manutenção de registros

Ao longo do PDP, da sugestão de uma política até a decisão final da Diretoria, ICANN manterá em seu site uma página sobre o status do processo, detalhando o progresso de cada assunto do PDP, e que descreverá:

a. A sugestão inicial de 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 por cada política;

d. Todas s discussões entre o Conselho referentes à política;

e. Todos os relatórios de forças-tarefa, do Gerente de Assunto, do Conselho e da Diretoria;

f. Todos comentários enviados pelo público; e

g. A disposição final de todos os PDPs empreendidos.

III. Recomendações sobre membresia

1. Qualificação para membresia: os registros de ccTLDs estarão qualificados como membros da ccNSO.

2. Representação de membros: os registros de ccTLDs serão representados por seus gerentes de registro de ccTLD ou pelas pessoas que o registro de ccTLD designar por escrito.

3. Taxa de membresia da ccNSO: a ccNSO estabelecerá uma estrutura de cobrança de uma taxa de membresia para ajudá-la a cobrir os custos operacionais da ccNSO.

4. Política: Políticas que

a. tiverem sido elaboradas através do processo normativo da ccNSO; e

b. foram recomendadas como tal pela ccNSO à Diretoria da ICANN; e

c. forem adotadas pela Diretoria da ICANN como normas

serão obrigatórias para registros de ccTLDs que são membros da ccNSO, desde que essas políticas não estejam em conflito com a legislação aplicável ao Registro de ccTLD, a qual sempre prevalecerá.

Definições

"Registro de ccTLD" significa um registro de Domínio de Alto Nível com Código de País que funciona como registro de nomes de domínios com dois caracteres, conforme define a RFC 1591.

"Gerente de registro de ccTLD" significa a entidade ou organização à qual a IANA delegou o gerenciamento de um Domínio de Alto Nível de código de país segundo a ISO 3166 e que está registrada na base de dados da IANA.

IV. Recomendações sobre o Conselho

1. Composição do Conselho: O Conselho compreenderá 18 membros votantes, incluindo 3 membros indicados pelo Comitê de Indicação. Com o objetivo de assegurar a diversidade geográfica, os membros da ccNSO em cada uma das cinco regiões reconhecidas da ICANN (a Região ou Regiões) estarão qualificados para eleger 3 membros do Conselho.

Se em algum momento posterior ICANN reconhecer outras regiões geográficas, o número de membros do Conselho será ajustado, de modo que cada região reconhecida continue tendo o direito de eleger o mesmo número de membros do Conselho que as outras regiões.

2. Responsabilidades do Conselho: O papel do Conselho é administrar e coordenar as atividades da ccNSO (inclusive a coordenação da reunião anual dos seus membros) e administrar a elaboração de recomendações políticas de acordo com o PDP da ccNSO. O Conselho também assumirá as outras funções que os membros da ccNSO eventualmente decidirem.

3. Observadores: O status de observador será mantido por um contato indicado pelo GAC e pelo ALAC, e cada uma das organizações regionais dos ccTLDs também poderá indicar um contato.

4. Qualificações: Para tornar-se um membro do Conselho, um indivíduo precisa ser indicado por um membro da ccNSO como candidato à eleição na Região daqueles membros; e embora não tenha necessariamente que ser membro da ccNSO, ele deverá apoiar as políticas defendidas pelos membros da ccNSO. Essa indicação deverá ser secundada por outro membro da ccNSO da mesma região.

5. Eleição de Membros do Conselho: Se no final das indicações houver mais candidatos indicados em uma determinada Região do que assentos disponíveis para aquela região, realizar-se-á uma eleição. Todos os membros da ccNSO da Região em questão estarão qualificados para votar na eleição.

Se não estiver claro à qual região um determinado membro da ccNSO pertence, o membro poderá escolher a região que desejar para fins de indicação do Conselho.

6. Mandatos, exceto para membros do Conselho Inaugural: Os membros do Conselho permanecerão no cargo por mandatos de 3 anos, a menos que sejam removidos por não comparecerem a três reuniões consecutivas, ou por comportamento inapropriado, conforme determinar a supermaioria do Conselho.

No caso do Conselho Inaugural, cada Região indicará 1 membro para um mandato de 1 ano, elegerá 1 membro para um mandato de 2 anos e um membro para um mandato de 3 anos.

7. Organização do Conselho: O Conselho elegerá um presidente e um vice-presidente, se considerar necessário.

8. Vacâncias: Vacâncias interinas serão preenchidas por uma eleição na Região do membro do Conselho ausente ou por meio de medidas apropriadas aprovadas pelo Conselho após consulta à Região em questão. Os candidatos eleitos por meio desse processo servirão apenas durante o mandato restante do membro do Conselho ausente.

9. Reuniões: O Conselho irá encontrar-se regularmente de acordo com um cronograma determinado por seus membros, mas não menos do que quatro vezes por ano. As reuniões podem ser com o comparecimento pessoal dos membros ou através da tecnologia apropriada, a critério do Conselho. Na medida do possível, as reuniões do Conselho deverão coincidir com as reuniões da Diretoria da ICANN e das outras Organizações de Apoio.

V. Recomendações sobre a estrutura

Os assuntos abordados sob o tópico "Estrutura" indicam como fazer a transição para a nova estrutura e os itens que talvez não tenham sido tratados, mas que o Grupo de Assistência da ccNSO considera importante incluir em suas recomendações.

Quanto à transição, o Grupo de Assistência da ccNSO recomenda que se crie um Grupo de Lançamento, com a responsabilidade de formalizar as providências para a ccNSO, fazer o contato com a comunidade de ccTLDs e ICANN em relação a isso, e organizar a eleição do primeiro Conselho da ccNSO. O Grupo de Lançamento também receberia as candidaturas à membresia da ccNSO, cujos membros estariam qualificados a votar para o Conselho.

Durante esse período, para tornar-se membro, um registro de ccTLD precisaria enviar uma carta na qual reconhece o papel da ccNSO na estrutura da ICANN, seu processo normativo e concordando em aderir às normas e taxas de membresia.

O Grupo de Lançamento será formado por integrantes do GA da ccNSO e da Comunidade de ccTLDs, e incluirá quinze (15) gerentes de registros de ccTLDs. A logística geral das eleições para o Conselho será deixada a cargo do Grupo de Lançamento. No entanto, o Grupo de Assistência da ccNSO recomenda que todo o Conselho seja eleito de uma vez após um período de lançamento, sendo que cada região elegerá três membros para mandatos de um, dois e três anos, respectivamente. As eleições serão organizadas no prazo de 120 dias após a adoção dos estatutos.

Os membros do Grupo de Lançamento também estão qualificados para serem eleitos ao Conselho.

O Grupo de Lançamento não teria outro poder além de formalizar a fase inicial da cNSO de acordo com os estatutos da ICANN, organizar e realizar a eleição do Conselho. Assim que o primeiro Conselho estiver eleito, o trabalho do Grupo de Lançamento estará terminado.

Uma vez eleito, o Conselho da ccNSO terá de abordar assuntos como: procedimentos de trabalho para o Conselho, opções de uma secretaria, procedimentos de trabalho para abordar assuntos que não passam pelo Processo Normativo, e a possibilidade de troca de observadores entre os Conselho da GNSO e da ccNSO.

Página atualizada em 26 de fevereiro de 2003
©2003 The Internet Corporation for Assigned Names and Numbers. Todos os direitos reservados.