Esta tradução em português é cortesia do NIC.br. Para mais informações sobre a ICANN em português, consulte http://www.icann.org.br/.
0.1 Em consulta à comunidade, a ICANN elaborou este procedimento preliminar para administrar a transferência de cadastros de nomes de domínio genéricos de um registrador descredenciado para um registrador credenciado. No momento, a equipe operacional da ICANN está usando este processo para facilitar a transferência de cadastros de gTLDs de registradores descredenciados. A descrição do processo ficará disponível para leitura on-line até 7 de julho de 2008, e público poderá comentá-la para que mais tarde seja aperfeiçoada. Juntamente com os programas de custódia de dados de registradores, cumprimento contratual e procedimentos para casos de falhas e falências de registradores, o objetivo deste procedimento é aumentar a proteção dos registrantes. Também publicamos uma representação gráfica deste procedimento em http://www.icann.org/registrars/drt-procedure-flowchart-06jun08.pdf [PDF, 21K].
0.2 Os comentários sobre este procedimento preliminar podem ser enviados por e-mail para dtr-procedure-2008@icann.org
até 7 de julho de 2008 e vistos em http://forum.icann.org/lists/dtr-procedure-2008/. Quando este período para comentários do público estiver encerrado, o procedimento que resultar da consulta será analisado e submetido à aprovação do Conselho de Diretores da ICANN e instituído após aprovação.
1. Introdução
1.1 No momento da rescisão ou expiração de um Contrato de Credenciamento de Registrador (RAA), é preciso que os cadastros patrocinados pelo registrador descredenciado sejam transferidos para um registrador competente registrado. No passado, em geral essas transferências eram feitas em “bloco”, conforme descreve a Parte B da Política para Transferências entre Registradores (<http://www.icann.org/transfers/policy-12jul04.htm>), e exigiam a cooperação do registrador “perdedor” (descredenciado) porque ele era a única fonte de dados cadastrais necessários para identificar os direitos de registro nos nomes de domínio em questão.
1.2 Com a introdução do Programa de Custódia de Dados de Registradores (RDE) <http://www.icann.org/announcements/announcement-2-09nov07.htm>, a ICANN terá mais condições de viabilizar uma transferência de nomes, mesmo que o registrador descredenciado não coopere com uma transferência
1.3 No momento a equipe operacional da ICANN está usando este processo preliminar para facilitar a transferência dos cadastros de dois registradores recentemente descredenciados. Ele foi criado a partir da experiência da equipe com descredenciamentos anteriores (que incluem rescisões voluntárias e involuntárias) e a partir das sugestões da comunidade durante o workshop sobre Rescisão de Registradores que ocorreu em Déli, Índia, no encontro da ICANN em fevereiro de 2008. (A transcrição, os slides da apresentação e o resumo dos comentários dos participantes estão disponíveis em http://delhi.icann.org/node/53.) Durante o workshop em Déli, os membros da comunidade apresentaram várias boas idéias para situações específicas que podem ocorrer após o descredenciamento de um registrador. Ainda que muitas sugestões tenham sido incorporadas a este procedimento preliminar, algumas delas não podem ser aplicadas no momento, seja em razão de limitações nas normas existentes, seja porque ainda precisamos definir soluções de longo prazo. A expectativa é que assim que este procedimento for definido e aprovado, ele será reavaliado e adaptado periodicamente, conforme indicar a experiência da ICANN com o seu uso.
2. Procedimento preliminar para transição de registradores com contratos rescindidos
2.1 De maneira geral, o procedimento para transição de registradores com contratos rescindidos não será aplicado antes que o RAA de um registrador seja de fato rescindido, porque o RAA garante certos direitos aos registradores, como por exemplo o de reparar uma violação assim que receber um aviso da ICANN, ou contestar uma rescisão por intermédio de arbitragem. Não obstante, antes de dar início ao processo, a ICANN tomará as providências para garantir a transição mais suave possível, e para isso avaliará a disponibilidade dos dados cadastrais (seja aplicando o programa de custódia de dados de registradores ou de outra forma) e trabalhará com os registros para garantir que os cadastros não sejam excluídos por ação ou omissão de um registrador descredenciado.
2.2 Segundo a Parte B da Política para Transferências entre Registradores (a “Política”), o patrocínio de todos os cadastros de gTLDs de um registrador pode ser transferido em bloco para outros registradores (uma “transferência em bloco”) se um registrador não estiver mais credenciado como registrador e a ICANN aprovar a transferência
3. Transferências em bloco voluntárias
3.1 Quando o RAA de um registrador é rescindido ou não é renovado, pode ser que os interesses dos registrantes e internautas em geral sejam que a ICANN autorize o registrador descredenciado a designar um “registrador vencedor”, que receberá a transferência em bloco dos seus nomes. Essa transição poderia ajudar a reduzir a confusão entre os consumidores, e ao mesmo tempo garantir que o registrador vencedor receba do registrador perdedor o maior número possível de dados cadastrais e de clientes. Mas acima de tudo, em geral uma transição voluntária envolve menos atritos.
3.2 Em alguns casos, porém, uma transição voluntária não é possível ou prática, ou porque o registrador “perdedor” não quer cooperar, ou porque a designação de um registrador “vencedor” não atende aos interesses da comunidade. Por exemplo, uma determinada transferência proposta pode não corresponder aos interesses da comunidade se o registrador “vencedor” não tiver cumprido suas obrigações para com a ICANN, ou se o registrador “perdedor” aparentemente estiver usando a rescisão do seu RAA como forma de evitar suas obrigações para com a ICANN ou para com seus clientes, ao transferir os cadastros para um outro registrador sem satisfazer as obrigações pendentes.
3.3 Embora reconheça as vantagens em potencial de uma transferência em bloco voluntária, o “Procedimento para transição de registradores com contrato rescindido” procura equilibrar os interesses na decisão de aprovar ou não uma proposta de transferência em bloco voluntária. Alguns fatores dessa decisão são: saber se o registrador “vencedor” cumpriu todas as suas obrigações para com a ICANN, se está em operação e se tem experiência no gerenciamento dos DPNs afetados, se existe um relacionamento entre o registrador “perdedor” e o registrador “vencedor” que poderia conduzir a abusos ou fraudes na transferência em bloco proposta, se o registrador “perdedor” continuará administrando os cadastros como revendedor do registrador “vencedor” ou continuará envolvido de alguma maneira no gerenciamento dos nomes e clientes e se com a transferência em bloco as obrigações para com a ICANN e com os clientes do registrador “perdedor” serão satisfeitas.
3.4 Ao ponderar todas as considerações, a ICANN poderá aprovar a transferência em bloco voluntária, anunciando a aprovação aos registradores e registros envolvidos, ou então negar o pedido de transferência, dando ao registrador “perdedor” mais uma oportunidade de indicar um registrador “vencedor” ou ainda designar um outro registrador “vencedor”, sem levar em conta a sugestão do registrador perdedor. Se a ICANN aprovar a transferência voluntária, essa aprovação poderá ser condicionada ao cumprimento de alguns requisitos (p. ex., pagamento de faturas ou taxas de registro pendentes para a ICANN). Caso o registrador não cumpra os requisitos, a ICANN poderá retirar sua aprovação à transferência e selecionar um outro registrador “vencedor”.
4. Transferências em bloco involuntárias
4.1 O RAA confere à ICANN o direito de usar ou transferir dados de registradores para oferecer serviços de registrador após a rescisão de um contrato de credenciamento de registradores. Quando um registrador descredenciado não cooperar com as iniciativas da ICANN para a transição, ou a ICANN não aprovar o registrador “vencedor” proposto numa transferência em bloco voluntária, a ICANN deverá selecionar um registrador “vencedor” para administrar os cadastros “órfãos”. Durante o workshop
5. Disponibilidade de dados cadastrais
5.1 Para efetuar uma transferência de cadastros de um registrador para outro, o registrador “vencedor” precisa receber pelo menos os dados cadastrais básicos a fim de conseguir identificar os registrantes e processar mudanças nos cadastros como renovações, alterações nos dados de contato e de servidores de nomes. Fora do programa de RDE há algumas ferramentas disponíveis para possibilitar a identificação de registrantes quando um registrador descredenciado não coopera com uma transferência em bloco
5.2 Quando uma transferência em bloco voluntária não for possível, a ICANN deverá avaliar até que ponto os dados cadastrais estão disponíveis para ela (ou, mais precisamente, para o possível registrador vencedor). Como esses dados provêm de várias fontes diferentes, a ICANN precisará analisar se estão completos e corretos para decidir se continuará com a escolha de um registrador “vencedor” ou se deve examinar outros cursos de ação.
5.3 Se os dados cadastrais não estiverem disponíveis ou se forem considerados não-confiáveis, a ICANN poderá:
5.3.1 iniciar um processo de litígio ou arbitragem para obter os dados cadastrais e assim facilitar uma transferência em bloco;
5.3.2 tentar obter os dados Whois/cadastrais de fontes não-oficiais;
5.3.3 permitir que o registrador descredenciado mantenha algumas operações para poder atender às necessidades de serviço dos clientes existentes (processando renovações e atualizações, mas não novos cadastros, por exemplo);
5.3.4 negociar um acordo com o registrador descredenciado para obter sua cooperação numa transferência em bloco;
5.3.5 permitir que os cadastros expirem na sua data de expiração;
5.3.6 instruir os registros a excluírem nomes (em situações específicas e únicas, como por exemplo quando parecer que todos os nomes são cadastros para teste, sem um proprietário definido); ou
5.3.7 aplicar uma combinação de mais de um desses procedimentos possíveis ou uma alternativa.
5.4 Se a ICANN ficar satisfeita com a disponibilidade e qualidade dos dados cadastrais, ela dará início ao processo de seleção do registrador “vencedor”.
6. Processo de seleção do registrador vencedor
6.2 Quando examinar as respostas ao RFI, a ICANN decidirá se há necessidade de uma Solicitação de Propostas (RFP) formal ou de um leilão para escolher um registrador “vencedor”. Essa decisão baseia-se sobretudo na possibilidade de negociar com os registradores que atenderam ao RFI. Ou seja, se a ICANN receber apenas algumas manifestações de interesse, ou se todos (exceto alguns poucos) aparentemente não estiverem qualificados para atuar como registrador “vencedor”, a ICANN poderá preferir contratar os candidatos qualificados em negociações diretas para selecionar o registrador vencedor. Contudo, se negociações diretas forem inviáveis, ou se não houver manifestações de interesse, a ICANN pode iniciar uma RFP ou leilão. Independentemente do processo aplicado (RFI, RFP ou leilão), os critérios para escolher o registrador vencedor são os mesmos. O registrador vencedor deve:
6.2.1 ser capaz de transferir cadastros e informações de clientes rapidamente para suas operações, e assim oferecer serviços com rapidez aos registrantes recém-adquiridos;
6.2.2 comprovar experiência anterior no gerenciamento de uma carteira de cadastros/clientes comparável à do registrador descredenciado;
6.2.3 ter funcionários suficientes no atendimento aos consumidores para responder rapidamente às solicitações de serviço durante e após a transferência em bloco;
6.2.4 estar credenciado e em condições de operação em todos os gTLDs aplicáveis e em boa situação em relação ao seu RAA;
6.2.5 ter experiência e conhecimento de processos de transferência em bloco;
6.2.6 aplicar procedimentos documentados para resolver possíveis disputas pelo controle de nomes de domínio ou direitos cadastrais;
6.2.7 ter experiência como empresa registradora de “varejo” (se for o caso);
6.2.8 ter experiência na administração de nomes de domínio internacionalizados de segundo nível (se for o caso);
6.2.9 ser capaz e estar disposto a apresentar relatórios periódicos à ICANN; e
6.2.10 oferecer um pagamento adequado pela carteira de clientes/cadastros.
6.3 Embora sejam esses os critérios que orientarão a ICANN na escolha de um registrador vencedor, eles não têm a intenção de ser normas inflexíveis. Isto é, um candidato que satisfizer a maioria dos critérios ainda assim pode ser levado em consideração como registrador vencedor e, do mesmo modo, circunstâncias excepcionais poderão exigir a análise de outros fatores que não estão relacionados aqui.
7. Alternativas para casos em que não se encontrar um registrador vencedor
7.1 Se não for possível encontrar um registrador vencedor com o “Processo de seleção de um registrador vencedor”, a ICANN poderá:
7.1.1 operar o registrador temporariamente por intermédio de sua conta de registro para “registradores com contrato rescindido” e definir um prazo final para que todos os registrantes transfiram seus nomes;
7.1.2 operar o registro rescindido por um tempo indefinido, oferecendo serviços de desbloqueio e codificação automática aos registrantes;
7.1.3 contratar um prestador de serviços de backend para registradores (ou serviços de backend e atendimento ao cliente) por um período definido ou indefinido;
7.1.4 pagar um registrador para receber a transferência em bloco;
7.1.5 oferecer um credenciamento temporário aos possíveis registradores vencedores; ou
7.1.6 permitir que os nomes sejam excluídos depois de expirarem.
7.2 Essas alternativas indicam, em diferentes graus, a reação ao pior cenário possível. Estimamos que com a proximidade de qualquer descredenciamento a carteira dos clientes do registrador descredenciado terá algum valor, de modo que o processo de seleção descrito acima permita identificar o registrador vencedor.
8. Processos em andamento