A ICANN publica hoje o seu plano para casos de falhas de registros de gTLDs para que o público o comente. Os comentários sobre o plano podem ser enviados para registry-failover-plan@icann.org até às 23:59 h UTC de 19 de novembro de 2007, e poderão ser vistos em http://forum.icann.org/lists/registry-failover-plan/.

Resumo executivo

O Projeto para Casos de Falhas de Registros é um dos projetos fundamentais da ICANN no seu Plano Operacional 2007-2008, e é coerente com a missão da ICANN de preservar a estabilidade operacional da Internet.

A introdução de novos gTLDs segundo a política de consenso da GNSO eventualmente pode causar falhas de registros. A equipe do programa (constituída de representantes de registros de gTLDs, de ccTLDs e da equipe da ICANN) responsável por estudar esses assuntos já publicou documentos descrevendo o trabalho que contribuirá para a implementação de um programa para casos de falhas de registros. A ICANN concluiu um plano preliminar para casos de falhas de registros e está revisando esse plano com especialistas em registros e na área técnica e com outros participantes da comunidade para garantir que ele seja completo.

Este anúncio contém links para o plano para casos de falhas (descrito em formato de texto e fluxograma [PDF, 84K]) e para o documento de Melhores Práticas [PDF, 56K]. O plano para casos de falhas identifica os processos e procedimentos a serem seguidos quando se identificar um conjunto específico de acontecimentos que indicam uma possível falha de algum registro de gTLDs. O objetivo do plano preliminar é proteger os interesses dos registrantes e oferecer a melhor oportunidade para que as operações de registro prossigam.

O documento de melhores práticas pretende ser a fonte das condições contratuais que serão parte de todos os novos contratos de registro. O propósito dessas condições é fornecer aos registros uma ferramenta para garantir a continuidade das operações e também um processo de backstop em caso de falha.

O projeto para falhas de registros estará concluído quando:

• o contrato de registro básico, publicado como parte do processo de novos gTLDs, incorporar elementos do documento de melhores práticas; e
• o grupo constituinte dos registros e a equipe da ICANN adotarem o plano para falhas.

É importante reconhecer que vários registros bem desenvolvidos implementaram planos de contingência competentes. A ICANN se baseou nesse trabalho (ao invés de tentar repeti-lo) e elaborou um documento preliminar de "melhores práticas". O documento pode ser adotado pela ICANN quando ela criar novos contratos de registro de DPNs.

Uma questão importante é definir o papel da ICANN em caso de falha de um registro. Esse programa para falhas de registros determina que cada registro deve ter um plano de contingência para manter as suas funções essenciais durante um certo período, de modo que:

• se possa encontrar um operador ou patrocinador substituto e efetuar uma transferência, ou
• na falta de indicação de um substituto, os registrantes sejam informados por um certo período de que o registro está fechando.

Histórico

A ICANN realizou pesquisas exaustivas e divulgou o assunto das falhas de registros. Em 1 de junho de 2007, a ICANN publicou o primeiro relatório abrangente de falhas de registros (http://www.icann.org/announcements/announcement-4-01jun07.htm e http://www.icann.org/registries/reports/registry-failover-01jun07.htm).

Enquanto elaborava esse relatório, a ICANN reviu as funções essenciais de registros, examinou a transição de registros de um operador para outro, e estudou possíveis situações de falhas. Este relatório concluiu que a identificação das funções essenciais, juntamente com a definição das melhores práticas pelos registros, servirá para a proteção dos registrantes em caso de uma falha do registro. O relatório apresenta os elementos do plano para casos de falha de registros e recomendações iniciais baseadas nas atuais práticas dos registros.

O relatório foi discutido em San Juan durante apresentações para o grupo de registros de gTLDs, para a ccNSO, no fórum aberto do SSAC e no workshop sobre proteções para registrantes. Após o encontro em San Juan, a ICANN fez consultas a um grupo de representantes de registros de gTLDs e ccTLDs, concluiu o Plano para Casos de Falhas de Registros de gTLDs e sintetizou um documento de melhores práticas que descreve mecanismos para casos de falhas de registros. Esses mecanismos servirão como orientação ou serão incorporados ao processo da ICANN para novos gTLDs e possivelmente como exigência contratual.

Discussão dos tópicos

De acordo com a perspectiva atual, o propósito da implementação de procedimentos para casos de falhas de registros é definir uma exigência contratual para que os registros ofereçam salvaguardas como pré-requisito para a delegação como registros. Em caso de falhas de um registro, os mecanismos para essas situações garantirão um período de operações contínuas até que se contrate uma entidade substituta ou, se isso não for possível, concederão um período de notificação aos registrantes sobre o fechamento iminente, de modo que os registrantes possam tomar suas próprias providências.

Essas metas foram definidas como respostas para as seguintes perguntas:

• Quais são as obrigações da ICANN em relação aos registrantes em caso de falha de registros de gTLD?
• Até que ponto é preciso haver garantias de que um registro não irá falhar?
• Como a ICANN pode ajudar a garantir os serviços para operação de um registro?
• Os registros devem ser obrigados a indicar um operador de registro de emergência que assumiria o registro em caso de uma falha prolongada?
• Quais são as situações nas quais um registro poderia ter falhas sem precisar de um mecanismo temporário ou permanente para casos de falhas?

Se um registro tiver uma falha e uma RFP não resultar na indicação de um sucessor, a ICANN sugere aqui um processo para encerrar o registro e retirar o DPN da raiz. Esse processo está descrito no Plano para Casos de Falhas de Registros. A ICANN não tem condições de financiar ou assumir as operações de um DPN falido, nem é uma entidade que possa procurar um modelo viável para o registro falido. Nesse caso, o melhor para a comunidade é ser informada de que registros podem falhar, e que um registro falido ou com falhas técnicas insolúveis pode ser removido da zona de raiz. Muitos contratos de registro de gTLDs existentes exigem um teste de falhas a cada dois anos. Essa disposição consta nos contratos de registro para.ASIA, .JOBS, .MOBI e .TRAVEL. A ICANN está trabalhando com esses registros para coordenar os critérios para testes de falhas. Os parâmetros para teste de falhas serão acrescentados como uma das exigências contratuais das Melhores Práticas para novos gTLDs e também passarão a fazer parte dos contratos de gTLDs existentes quando esses contratos forem renovados.

Resumo das recomendações

O relatório da ICANN sobre falhas de registro, publicado em http://www.icann.org/announcements/announcement-4-01jun07.htm no dia 1 de junho de 2007, identificou sete funções essenciais de um registro:

1. a manutenção dos servidores de nomes e do DNS
2. o sistema de cadastro compartilhado
3. WHOIS
4. as informações comerciais e contábeis dos registradores
5. segurança e custódia de dados
6. tabelas de IDNs (para os registros que oferecem IDNs) e
7. chaves DNSSEC (para os registros que empregaram o DNSSEC).

Além disso, a versão preliminar do Plano da ICANN para Casos de Falhas de Registros de gTLDs inclui uma série de pressupostos, exigências e processos, que são resultado da interação da ICANN com o grupo de ccTLDs e gTLDs descrito acima e de consultas com outros. A seguir, descreveremos em mais detalhes os elementos básicos do plano:

1. A ICANN terá um papel em casos de falhas de registros de gTLDs. Esse poderá ser um papel primário de comunicação com o registro, os registradores e a comunidade dos usuários finais.
2. Os registros devem elaborar e implementar seus próprios planos de contingência, incluindo a designação de um operador de emergência substituto.
3. A ICANN não assumirá a operação de nenhum registro, mas pode operar servidores de nomes ou designar um operador de servidores temporário na eventualidade de uma emergência.
4. Eventuais alterações nos contratos de registro deverão implementar adequadamente o Plano da ICANN para Casos de Falhas de Registros de gTLDs. Os novos contratos de gTLDs já terão disposições sobre esses casos de falhas, e o mesmo pode acontecer em renovações de contratos e propostas de políticas de consenso.
5. Os registros devem designar uma pessoa de contato autorizada a agir em nome do registro e que possa servir como ponto de contato com a ICANN e o público nas funções essenciais do registro.
6. Os registros devem reservar recursos financeiros necessários como garantias para financiar temporariamente as suas funções até que seja possível indicar um sucessor.
7. Os registros devem atentar para a diversidade geográfica dos serviços do DNS.
8. Se for necessário, a ICANN consultará especialistas em planejamento de contingência e falhas de registro.
9. Na eventualidade de falha de um registro, a ICANN irá consultá-lo para verificar se a falha é técnica, comercial ou outra e definir se a falha é temporária ou de longo prazo. Uma falha temporária acionaria um conjunto pré-definido de respostas da ICANN, enquanto uma falha de longo prazo acionaria um conjunto de respostas diferentes.
10. A ICANN deve definir parâmetros para falhas (o que caracteriza um evento que acionaria procedimentos de emergência) nos contratos de registros de gTLDs. Nos contratos, ela também deve esclarecer as práticas em casos de falhas e as obrigações de testes prévios.
11. A ICANN criou um Grupo de Assistência para Continuidade de Registros, constituído de 5 representantes de registros de ccTLDs e 5 representantes de registros de gTLDs, para auxiliar na manutenção e teste do Plano para Casos de Falhas de Registros de gTLDs.
12. O Plano para Casos de Falhas de Registros inclui um procedimento para indicar um operador de registro substituto. Se não for possível encontrar esse substituto, o plano determina que a comunidade seja informada e que a ICANN siga um processo para encerrar as operações do registro. A ICANN deve examinar atentamente as disposições sobre transição e rescisão existentes nos atuais contratos de registro para decidir se essas disposições devem ser esclarecidas ou mudadas nos novos contratos.
13. A ICANN deve criar um procedimento para a divulgação de dados sob custódia para a ICANN. O procedimento deve preservar rigorosamente a segurança dos dados. Segundo os termos do contrato de custódia padrão, os depósitos em custódia dos registros podem ser divulgados para a ICANN sob determinadas condições, a saber:
1. Expiração do contrato de registro ou de patrocínio sem renovação
2. Rescisão de um registro ou patrocínio
3. Pedido conjunto do registro e da ICANN
4. Ausência de relatórios de verificação de Depósitos Completos no período de um mês
5. Não-pagamento de taxas pelo registro
6. Divulgação obrigatória determinada por um tribunal, árbitro, órgão judicial ou governamental da jurisdição competente.

Conclusão

O propósito do Plano da ICANN para Casos de Falhas de Registros de gTLDs é oferecer proteção aos registrantes e reforçar a segurança e a estabilidade da Internet pela colaboração com registros, registradores e membros da comunidade da Internet. O próximo passo no projeto é concluir a aprovação do procedimento, o contrato-base para novos gTLDs.