Respostas do ERC aos comentários recebidos sobre suas recomendações à ccNSO

29 de maio de 2003

Comitê para Desenvolvimento e Reforma da ICANN
Resposta aos comentários recebidos sobre as recomendações do ERC
para a ccNSO
29 de maio de 2003

Introdução e comentários gerais

O ERC gostaria de agradecer aos membros da comunidade da ICANN que enviaram comentários a respeito do Quinto Relatório Suplementar do ERC sobre Implementação (Recomendações para a ccNSO). O ERC destaca especialmente as contribuições do Comitê Consultivo para Assuntos Governamentais, da CENTR, APTLD, TWNIC e do Comitê Consultivo para Membresia Geral, que enviaram comentários sobre as recomendações do ERC para a ccNSO. O ERC os analisou cuidadosamente e oferece ao Fórum para Comentários Públicos esta resposta ao material recebido.

Em alguns casos, o ERC recebeu comentários incompatíveis com as recomendações atuais e passadas já recebidas por ICANN. Ao analisar todas as sugestões, o ERC acredita que suas recomendações, tal como foram elaboradas nesta resposta, estabelecem um denominador comum entre os diferentes mantenedores e os diferentes pontos de vista. O ERC acredita que este denominador comum, que se reflete em suas recomendações para a ccNSO, é importante para assegurar que a ccNSO faça parte e apóie a missão da ICANN em garantir a operação estável e segura do DNS com base em consenso e na participação de todos os mantenedores.

Em breve o ERC publicará os estatutos e uma nota explicativa completa sobre os comentários recebidos, acompanhando as propostas de emendas aos estatutos.

Quanto à criação de uma ccNSO, o ERC gostaria de deixar claro que a membresia dos ccTLDs na ccNSO não depende de qualquer relacionamento individual de um determinado ccTLD com ICANN nem do seu recebimento de serviços IANA.

Em relação aos ccTLDs, o papel da ICANN limita-se aos assuntos que exigem coordenação em nível global para assegurar a operação estável e segura do DNS. O ERC teve o prazer de constatar que nos comentários e nas discussões correspondentes sobre as recomendações do ERC houve um grande apoio ao papel da ICANN na estabilidade e segurança do DNS, e neste sentido o papel da ccNSO no desenvolvimento consensual de políticas globais está alinhado com a responsabilidade da ICANN. O ERC acredita que a estrutura para o escopo da Organização possibilita um tipo de abordagem tão dinâmico quanto a Internet, e que será capaz de se ajustar ao futuro da Internet. Ela oferece um método para garantir que a ccNSO, através de seus processos baseados em consenso, defina o seu escopo e, conseqüentemente, os assuntos que exigem uma normatização global.

Conselho da ccNSO e indicações do NomCom

As indicações do NomCom para o Conselho de uma Organização de Apoio são uma parte fundamental da reforma da ICANN. De maneira alguma o propósito dessas indicações é simplesmente levar representantes de grupos diferentes ao Conselho. Conforme declara o próprio NomCom,

O objetivo do novo processo de indicações da ICANN é equilibrar a escolha de Diretores e indivíduos para outros cargos, realizada pelas Organizações de Apoio e grupos constituintes, a fim de garantir que ICANN se beneficie da presença de participantes da maior integridade e capacidade, que coloquem o interesse público acima de qualquer interesse particular, mas que ainda assim estejam familiarizados com o ambiente no qual ICANN opera.

O ERC considera isso necessário para assegurar que a organização reformada seja vista como aberta e transparente em todos os níveis, e de fato o seja.

O ERC observa que alguns comentários refletem o ponto de vista de que o NomCom deve aumentar o seu número de delegados de ccTLDs, ou seja, que um delegado dos ccTLDs junto ao NomCom era insuficiente, já que o Comitê estava selecionando três membros para o Conselho da ccNSO. O ERC acredita que este é um assunto que não lhe compete neste estágio, no qual o NomCom está formado e concluindo um processo de seleção para diretores e para os membros do NomCom junto à GNSO e ao ALAC. O ERC compreende essa preocupação. No entanto, o ERC também acredita que a dúvida se deve haver mais delegados da comunidade de ccTLDs junto ao NomCom deve ser abordada durante a revisão periódica programada do NomCom.

Os comentários sobre o Conselho enviados pelo Comitê Consultivo para Membresia Geral manifestam o desejo de uma possível troca de observadores entre a ccNSO e o ALAC. O GAC também expressou seu interesse em garantir uma boa comunicação entre o GAC e a ccNSO. O ERC apóia veementemente a boa comunicação entre as entidades da estrutura da ICANN.

Em resposta ao comentário feito pelo GAC - de que em caso de uma delegação contestada, um gerente da ccNSO não pode ser indicado ao Conselho da ccNSO - o ERC chama a atenção para a seção 3(d) das suas recomendações sobre Indicações e Qualificações: Qualquer membro da ccNSO pode indicar um indivíduo para servir como membro do Conselho da ccNSO, representando a sua Região. As indicações precisam do apoio de outro membro da ccNSO da mesma Região. Os membros do Conselho da ccNSO deverão apoiar as políticas aceitas pelos membros da ccNSO.

O afastamento de um membro do Conselho exigirá a aprovação de 12 votos dos membros do Conselho. Se o membro do Conselho afetado contestar esse tipo de decisão, não se elegerá nenhum substituto até que a disputa seja resolvida. O ERC recomenda que em princípio essas disputas sejam encaminhadas ao Ombudsman.

O ERC não especificou um quorum do Conselho porque este optou por deliberar por meio da maioria absoluta dos votos (14) a favor.

Escopo

O ERC recebeu várias séries de comentários sobre o escopo da ccNSO.

Neste aspecto, o ERC gostaria de esclarecer um ponto. O Quinto Relatório Suplementar do ERC sobre a Implementação abordou as recomendações do Grupo de Assistência para a ccNSO referentes ao seu escopo, com um link para a matriz apresentada ali. Para solidificar este esclarecimento, o ERC transformou a matriz apresentada nas Recomendações sobre o Escopo do Grupo de Assistência para a ccNSO em Estrutura para o Escopo da ccNSO, que formará a base de  um Anexo aos estatutos. Comentários sobre esse Anexo são bem-vindos.

O ERC está consciente da preocupação manifestada por muitos, de que o escopo da ccNSO deve permanecer limitado a assuntos de caráter realmente global, pertinentes à operação estável e segura do DNS e da Internet. O ERC partilha das mesmas opiniões, e portanto – segundo as recomendações do Grupo de Assistência da ccNSO – dá grande ênfase à capacidade da ccNSO definir o seu escopo, com auxílio da Matriz (agora Estrutura) do Escopo. Assim, os próprios gerentes de ccTLDs servirão como um controle sobre o que será a "política global".

A outra série de comentários que o ERC recebeu sobre o escopo argumentava que havia necessidade de definir esse âmbito, ou que o escopo deveria limitar-se somente a assuntos relativos a IANA. O ERC acredita que deve haver uma estrutura para o escopo tal como a que foi desenvolvida pelo Grupo de Assistência para a ccNSO. Essa opinião baseia-se no ponto de vista de que a própria ccNSO deve decidir quais assuntos fazem parte do âmbito de políticas globais. Para essa finalidade, convém ter uma estrutura para identificar o que pertence e o que não pertence a uma política global.

O ERC acredita que políticas globais definidas dessa maneira, elaboradas pela ccNSO com aplicação do seu processo normativo, e adotadas pela Diretoria da ICANN, terão um caráter vinculativo para a operação estável da Internet. Como no momento não existem relacionamentos contratuais entre ICANN e a maioria dos gerentes de ccTLDs, o ERC considera recomendável que os membros da ccNSO se comprometam a seguir essas políticas como parte do contrato de membresia. Os membros da ccNSO participarão da elaboração dessas políticas.

Membresia

A composição da ccNSO difere bastante da das outras Organizações de Apoio. Ela possui apenas um grupo constituinte: os Gerentes de ccTLDs. Naturalmente, o ideal é que todos os gerentes de ccTLDs sejam membros da ccNSO.

O ERC espera que esse objetivo seja atingido no momento certo. O papel primário da ccNSO - conforme define o Quinto Relatório Suplementar de Implementação - é ser uma "entidade normativa . . .  que será responsável por elaborar e recomendar à Diretoria da ICANN políticas relevantes para domínios de alto nível com códigos de país". Como papel secundário, o ERC sugere a análise voluntária e cooperativa das melhores práticas para gerentes de ccTLDs. Na opinião do ERC, o primeiro aspecto da ccNSO implica no compromisso dos membros da ccNSO em cumprir as políticas globais desenvolvidas através do seu PDP (processo normativo).

O que deve ficar claro é que a membresia na ccNSO não é e não pode ser uma condição para o acesso ou o registro na base de dados de IANA. Como observamos acima, a membresia de um ccTLD na ccNSO não depende de qualquer relacionamento individual que o ccTLD tenha com ICANN ou do fato de receber serviços de IANA.

Neste caso, o termo "Organização de Apoio" é usado no sentido de um registrante na base de dados de IANA, e deve ser compreendido como tal. O Grupo de Assistência para a ccNSO e o ERC passaram muito tempo à procura de um termo que garantisse que a entidade apropriada representaria os ccTLDs na ccNSO, e concluíram que o melhor seria referir-se à entidade identificada sob a designação "organização patrocinadora" na base de dados de IANA. O ERC entende que existe uma história por trás disso, e espera que um dia ela seja abordada e solucionada de fato - talvez pela ccNSO.

Alguns comentários observavam que não deveria haver a exigência de uma "carta reconhecendo o papel da ccNSO", ou outra forma de compromisso para tornar-se membro da ccNSO. O ERC destaca, como já observamos acima, que a ccNSO é diferente das outras Organizações de Apoio, pois constitui-se de uma parcela da comunidade da ICANN, e uma parcela que em grande parte não possui obrigações contratuais que a levem a cumprir políticas globais.

O GAC observou que nos casos de delegações contestadas as duas partes devem ter condições de comparecer. O ERC não acredita que isso seja um problema, pois em princípio as reuniões da ccNSO serão abertas. Contudo, o ERC destaca que os gerentes de ccTLDs registrados na base de dados de IANA estarão qualificados para se tornarem membros da ccNSO.

O ERC concorda com os comentários a respeito de que se deve conceder uma isenção baseada em políticas nacionais, etc., a menos que dois terços do Conselho da ccNSO rejeitem essa isenção.

Processo normativo

Um dos tópicos citados por membros fora da comunidade dos ccTLDs é a necessidade de consulta e comunicação entre os diferentes componentes da ICANN. Isso não se aplica somente ao processo normativo (PDP) da ccNSO, mas também de modo geral. Mais especificamente, o GAC manifestou seu desejo por boas relações de trabalho entre o GAC e a ccNSO. O ERC já incorporou essa sugestão em suas recomendações e acredita que a boa comunicação entre o GAC e a comunidade de ccTLDs deve ser um objetivo constante.

Outro ponto citado em vários comentários foi a opinião de que o papel da Diretoria é ratificar as recomendações provenientes de fora da ccNSO, ou encaminhá-las para a ccNSO para análise e revisão. O ERC acredita que foi bastante claro ao endossar as recomendações do Grupo de Assistência para a ccNSO, segundo as quais se a Diretoria não adotar as recomendações produzidas pelo PDP da ccNSO, a situação será mantida.

O ERC compreende o ponto de vista de que é necessário reunir 40 gerentes de ccTLDs antes que se empreenda um Processo Normativo. No entanto, o ERC sugere que se mantenha um número de 20 gerentes de ccTLDs, a fim de garantir o início do trabalho da ccNSO sem atrasos significativos. Se for possível reunir 40 ou mais membros, tanto melhor, e isso aumentará a amplitude das contribuições que a ccNSO e o Processo Normativo terão imediatamente.

Tomada de decisões

Houve um longo debate sobre as diversas opções para tomada de decisões, tanto no Grupo de Assistência para a ccNSO quanto no ERC. O ERC acredita que a proposta atual oferece o equilíbrio correto de autoridade e responsabilidade. O ERC tem consciência do fato de qualquer sistema está sujeito ao controle ou ao bloqueio por uma minoria. Não obstante, o ERC espera que o voto do Conselho da ccNSO represente o peso e a autoridade na comunidade de ccTLDs. Ao invés de definir um quorum para as decisões do Conselho, o número de votos necessários será especificado em números absolutos. No caso do voto dos membros, o ERC decidiu antecipar uma disposição sobre quorum especificamente para evitar outro mecanismo que poderia resultar num bloqueio por não-participação.

Recursos humanos e financeiros

O ERC destaca que alguns comentários argumentavam que os recursos humanos não deveriam vir da ICANN. Como já se observou em outras ocasiões, ICANN oferecerá apoio de sua equipe, se uma Organização de Apoio optar por usá-lo. A GNSO, por exemplo, solicitou apoio da equipe para auxiliar nas operações e na administração da GNSO, e para ajudar a preparar seu Processo Normativo. Fica a cargo da ccNSO determinar se também deseja esse tipo de apoio ou não. A obtenção dos recursos financeiros da ccNSO é responsabilidade da ccNSO. Esses recursos são separados e diferentes das contribuições dos ccTLDs para ICANN, das quais ICANN não depende, conforme declara o orçamento proposto para este ano.

Grupo de Lançamento (como Transição)

Em suas recomendações, o ERC denominou de "transição" a seção sobre o Grupo de Lançamento. Os comentários recebidos indicaram que isso causou certa confusão. A fase de lançamento não é uma transição - não haverá um Conselho de transição. Na opinião do ERC, após a adoção das mudanças dos estatutos haverá o lançamento da ccNSO, começará o recebimento das candidaturas dos membros, e a organização das eleições do Conselho, seguida da posse dos três membros do Conselho selecionados pelo NomCom. Assim que o Conselho da ccNSO estiver empossado, a própria ccNSO poderá começar o seu trabalho, e não antes. O Grupo de Lançamento é responsável por implementar a estrutura assim que se adotarem os estatutos.

O ERC observa que alguns comentários sugeriram que o Grupo de Lançamento deve consistir de todos os gerentes de ccTLDs. O ERC acredita que as recomendações do Grupo de Assistência para a ccNSO devem ser aceitas pelas seguintes razões. O Grupo de Lançamento é o responsável exclusivo por "lançar" a ccNSO, e apenas isto. Há muito trabalho por fazer, e o ERC espera que a ccNSO seja lançada em pouco tempo, para que se possa começar o trabalho propriamente dito. Por motivos de ordem prática, o ERC acredita que um Grupo de Lançamento baseado no convite a todos os gerentes de ccTLDs será impraticável, e que o acúmulo de trabalho acabará acarretando um atraso na formação da ccNSO. Além disso, como o Grupo de Lançamento se destina unicamente ao lançamento da ccNSO, incluindo a organização das eleições do primeiro Conselho da ccNSO, na opinião do ERC não se deve proibir os membros do Grupo de Lançamento de se candidatarem à eleição do primeiro Conselho.

O ERC concorda que futuramente a comunidade de ccTLDs deverá eleger ou indicar os seus representantes em nível regional, como descrevem as recomendações sobre o Conselho da ccNSO, 
com a assistência adequada das organizações regionais, quando houver.

Anexo
Estrutura para o escopo da ccNSO

O propósito da ccNSO é participar e fornecer liderança em atividades relevantes para os domínios de alto nível com códigos de país, mais especificamente:

1. Ao elaborar recomendações políticas para a Diretoria da ICANN;

2. Ao promover o consenso entre a comunidade da ccNSO, incluindo as atividades dos ccTLDs relativas a nomes; e

3. Ao trabalhar em coordenação com outras Organizações, Comitês e grupos constituintes da ICANN.

O escopo da autoridade e das responsabilidades da ccNSO precisa reconhecer a relação complexa entre ICANN e gerentes/registros de ccTLDs no que se refere a questões políticas. O objetivo da estrutura a seguir é auxiliar a ccNSO, o Conselho da ccNSO e a Diretoria e a equipe da ICANN a delinear as políticas globais relevantes.

Áreas políticas

O papel político da ccNSO pode basear-se numa análise do seguinte modelo funcional do DNS:

1. Os dados são registrados/mantidos para gerar um arquivo de zona,

2. Por sua vez, o arquivo de zona é usado em servidores de nomes.

Em um TLD, é necessário que se desempenhem duas funções (que serão abordadas mais detalhadamente a seguir):

1. Registrar dados em uma base de dados (função Registro de Dados) e

2. Manter e assegurar a manutenção de servidores de nomes para o TLD (função Servidor de Nomes).

Essas duas funções essenciais precisam ser desempenhadas em nível de registro de ccTLDs, e também em um nível mais alto (função IANA e servidores-raiz) e em níveis mais baixos (como em níveis secundários) da hierarquia do DNS. Esse mecanismo, conforme destaca a RFC 1591, é recorrente:

 Não existem exigências para sub-domínios de domínios de alto nível além das exigências para os próprios domínios de alto nível. Isto é, as exigências deste memorando se aplicam de forma recorrente. Em particular, todos os sub-domínios terão permissão para operar seus próprios servidores de nomes de domínio, fornecendo nestes sub-domínios todas as informações que o gerente julgar adequadas (contanto que sejam verdadeiras e corretas).

As funções essenciais

1. Função Registro de Dados (DEF):

Registrar e manter dados em uma base de dados que será definida mais especificamente por uma política de atribuição de nomes. Essa política deverá especificar as normas e condições:

(a) para a coleta e o registro de dados em uma base de dados ou para a troca de dados na base de dados (no nível de TLDs, entre outros, dados que reflitam uma transferência de um registrante para outro ou mudança de registrador);

(b) para que determinados dados estejam disponíveis ao público (por exemplo, através de Whois ou servidores de nomes).

2. A função de Servidor de Nomes (NSF)

A função de servidor de nomes envolve questões essenciais de interoperabilidade e estabilidade no núcleo do sistema de nomes de domínio. A importância desta função se estende aos servidores de nomes no nível de ccTLDs, mas também aos servidores-raiz (e ao sistema de servidores-raiz) e servidores de nomes em níveis mais baixos.

Por seu próprio mérito e por causa dos aspectos de interoperabilidade e estabilidade, o funcionamento apropriado dos servidores de nomes é extremamente importante para a comunidade de indivíduos, bem como para as comunidades locais e globais da Internet.

Portanto, em relação à função de servidores de nomes, é necessário definir e estabelecer diretrizes. A maioria das partes envolvidas, incluindo a maioria dos registros de ccTLDs, concordou com a necessidade de normas nesta área aderindo às RFC relevantes, entre outras, à RFC 1591.

Respectivos papéis relativos a políticas, responsabilidades e atribuição de responsabilidade

É 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 nesta área, que pode ser definido pelas diretrizes relevantes. Não é possível estabelecer o escopo da ccNSO sem que haja um entendimento comum da divisão de autoridade entre ICANN e os registros de ccTLDs.

É possível distinguir três funções na responsabilidade sobre um determinado assunto:

• Função normativa: isto é, a capacidade e o poder de definir uma diretriz;
• Função executiva: isto é, a capacidade e o poder de votar e implementar uma diretriz; e
• Função de atribuição de responsabilidade: isto é, a capacidade e o poder de exigir que a entidade responsável preste contas por exercer o seu poder.

Primeiramente, a responsabilidade pressupõe uma política, e isso delineia a função normativa. Dependendo do assunto a ser tratado, será necessário determinar e definir aqueles que estão envolvidos na definição e estabelecimento da política. Em segundo lugar, ela pressupõe um papel executivo que defina o poder de implementar e agir dentro dos limites de uma política. Finalmente, como contrapeso ao papel executivo, é necessário definir e determinar o papel de atribuição de responsabilidades.

A estrutura abaixo oferece uma ajuda para:

1. delinear e identificar áreas políticas específicas;

2. definir e determinar funções relativas a essas áreas políticas específicas.

A estrutura apresenta um método para identificar a divisão de autoridade entre os gerentes de ccTLDs e outros grupos.

Função de servidor-raiz

Nível 1: A raiz
Função normativa: IETF , RSSAC (ICANN)
Função executiva: Operadores do sistema de servidores-raiz
Função de atribuição de responsabilidades: RSSAC (ICANN), (Protocolo de Intenção entre o Departamento de Comércio da ICANN)

Nível 2: Servidor de nomes de registros de ccTLD
Função normativa: Processo normativo da ccNSO (ICANN), pode-se organizar um processo da ccNSO para as melhores práticas
Função executiva: Gerente de ccTLD
Função de atribuição de responsabilidades: Em parte ICANN (IANA), em parte da comunidade local da Internet, incluindo o governo local

Nível 3: Servidor de nomes de usuários
Função normativa: Gerente de ccTLD, IETF (RFC)
Função executiva: Registrante
Função de atribuição de responsabilidades: Gerente de ccTLD

Função de registro de dados

Nível 1: ICANN (IANA): (mudanças, transferências de servidores de nomes, detalhes sobre contatos e alterações)
Função normativa: Processo normativo da ccNSO (ICANN)
Função executiva: ICANN (IANA)
Função de atribuição de responsabilidade: Comunidade da ICANN, gerentes de ccTLDs, DoC, (autoridades nacionais em alguns casos)

Nível 2: Registro de ccTLD (registrações, transferências, exclusões, Whois, resolução de disputas)
Função normativa: Comunidade local da Internet, incluindo o governo local e /ou gerente de ccTLD, de acordo com a estrutura local
Função executiva: Gerente de ccTLD
Função de atribuição de responsabilidades: Comunidade local da Internet, incluindo autoridades nacionais em alguns casos

Nível 3: Servidores de nomes de segundo nível e níveis mais baixos
Função normativa: Registrante
Função executiva: Registrante
Função de atribuição de responsabilidades: Registrante, usuários de nomes de domínios em níveis mais baixos

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