|
|
Relatório final e recomendações
da Força-Tarefa para Transferências do Conselho da GNSO 30 de novembro de 2002 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Relatório final e recomendações
da Força-Tarefa para Transferências do Conselho da GNSO Recomendações políticas da Força-Tarefa Recomendações políticas de consenso Análise de impacto.custos e riscos Impacto para registros de gTLDs Análise geral de riscos e custos Análises do impacto sobre os grupos constituintes (CI) Análise detalhada da implementação e comentários da Força-Tarefa Outras observações e considerações I. Teleconferências e reuniões abertas para indivíduos que participam da Força-Tarefa II. Comentários do público e dos grupos constituintes recebidos pela Força-Tarefa Exposição A: Requerimento de referência Exposição B: Modelo proposto para resolução de disputas Exposição C: Definições padronizadas Exposição D: Relatório da Força-Tarefa para Implementação de Transferências
Quando se introduziu a concorrência do setor privado nas funções de registração dos Domínios genéricos de Alto Nível, a comunidade saudou esse conceito com grande entusiasmo e expectativa. Agora que a concorrência foi implementada, a comunidade usufrui as vantagens de ter acesso a uma comunidade saudável e diversificada de Registradores competitivos que oferecem serviços diferenciados a preços diferenciados. Eles se encontram em diferentes países. Alguns trabalham mediante ISPs, alguns realizam vendas diretas. Alguns são fornecedores de "nichos" de mercado, que basicamente oferecem serviços de ISP ou hospedagem na rede, ou oferecem o serviço de registro como uma cortesia, porém uma cortesia importante, aos seus atuais clientes. Para muitos, os serviços de registro constituem sua atividade mais importante. Ainda que essa descrição não faça justiça ao grau de inovação dos Registradores competitivos para nomes de gTLDs, ela tenta transmitir a mensagem essencial: os registrantes devem ser capazes de escolher um registrador que possa atender suas necessidades, e devem ter a possibilidade de "mudar" de um registrador para outro se, por alguma razão, não estiverem satisfeitos. Bem, mas eles podem fazer isso? Quando a Força-Tarefa passou a examinar esses tópicos, tornou-se evidente que é difícil, se não impossível, que as partes com interesses próprios concordem voluntariamente com mudanças na política. Na verdade, isso foi tentado em mais de uma ocasião, e as experiências de registradores, registros, registrantes e da equipe da ICANN demonstram que a abordagem voluntária para resolver esses problemas complexos não é um método válido para solucionar as dificuldades identificadas pela comunidade. As práticas de um único grande registrador podem afetar dezenas de pequenos registradores, ao passo que decisões de 2 ou 3 dos maiores registradores significam que a opção simplesmente está "em espera". Apesar de várias tentativas para obter um acordo voluntário quanto às mudanças necessárias, os fatos indicam que ainda há problemas com a "portabilidade" de registrações de domínios - a escolha do consumidor continua limitada. A pesquisa conduzida pela Força-Tarefa apóia este ponto de vista. A equipe da ICANN também concordou com isso. Com esse entendimento, a Força-Tarefa partiu de um pressuposto: independentemente dos motivos pelos quais uma transferência é aprovada, negada, bloqueada, retardada ou conduzida ao objetivo errado, os registrantes estão autorizados a transferir sua registração de um registrador para outro, e o processo para fazê-lo deve ser fácil, fluido, transparente e sem custos. Quando ocorrerem enganos, erros ou transferências fraudulentas, deve haver um processo de "recuperação" rápido e simples, e um processo de apelação para tratar das situações complicadas. Tudo isso deve ser bem claro, compreensível e rápido, e restringir o investimento de tempo e recursos de registradores, registros e registrantes. A Força-Tarefa resume essas exigências em quatro simples palavras: segurança, transparência, estabilidade e portabilidade. Qualquer recomendação aprovada para implementação como política deve satisfazer esses quatro parâmetros e manter o equilíbrio entre eles. A Força-Tarefa acredita que suas recomendações atendem essa obrigação sob todos os aspectos. Em termos mais genéricos, as características que beneficiam registrantes também devem beneficiar registradores e registros. A Força-Tarefa para Transferências procurou abordar os problemas e preocupações com esse objetivo em mente - uma abordagem proveitosa para todos, que garanta a satisfação de registrantes, registradores e registros. Esse sistema deve viabilizar um ambiente justo, equilibrado e competitivo, oferecer opções aos registrantes e a possibilidade de exercer essas opções, e fornecer aos registros e registradores as salvaguardas necessárias para limitar sua exposição, custos e responsabilidades. A Força-Tarefa empreendeu uma ampla pesquisa entre a comunidade afetada ao longo de vários meses. Alguns aceitaram o convite para fornecer sugestões e comentários, outros não. Os registradores tiveram preocupações legítimas quanto ao abuso de um sistema que poderia enganar registrantes, levando-os concordar com uma transferência que eles talvez não compreenderam. Alguns levantaram questões sobre "fraude de consumidores". A Força-Tarefa levou todas essas considerações muito a sério. Os processos recomendados oferecem uma opção para que o registrador perdedor entre em contato com o registrante para validação, caso haja suspeita de fraude. Se existe um tema único para o trabalho da Força-Tarefa, esse tema é que o sistema de transferências entre registradores concorrentes existe para servir os registrantes. Tenha esse tema em mente ao ler esse relatório: a transferência de nomes de domínio é uma opção do consumidor. A Força-Tarefa teve a contribuição contínua de todos os seus membros, que dedicaram muitas horas tentando compreender, documentar e elaborar um procedimento que pode trazer mais certezas para um processo essencial, que atende as necessidades e interesses do fornecedor do processo de registração, e do usuário desse processo, de uma maneira justa, aberta e econômica, e que ofereça um mecanismo de apelação ou resolução de problemas com as mesmas características. Muitos indivíduos e empresas compartilharam seus pontos de vista e experiências conosco. A equipe da ICANN ofereceu um esclarecimento essencial e análises dos acordos existentes; membros de grupos constituintes e da Assembléia Geral (e outros) participaram de reuniões abertas. Recebemos muitos comentários divergentes e muitos comentários de apoio. A Força-Tarefa agradece a todos que gastaram seu tempo em explicar, concordar e discordar com suas recomendações. Fizemos todos os esforços para refletir as contribuições que recebemos. Reconhecemos que talvez tenhamos omitido algumas particularidades, mas acreditamos que captamos os assuntos e preocupações gerais. Agora que iniciamos o período final para comentários durante oito dias, solicitamos que os grupos constituintes apresentem suas Declarações de Impacto. Outros poderão enviar suas opiniões divergentes e expressões de apoio. Incluiremos todos os materiais sobre o impacto das decisões ou opiniões minoritárias recebidos no documento final, juntamente com os comentários da Força-Tarefa. Esse Relatório Final da Força-Tarefa baseia-se em relatórios anteriores que procuraram descrever a natureza do problema. Este relatório baseia-se na necessidade de uma mudança no processo, e descreve princípios de alto nível para nortear a política, amplas recomendações políticas e documenta onde há e onde não consenso. Finalmente, ele descreve algumas áreas em que ainda há itens de trabalho não-resolvidos. Este relatório será submetido ao Conselho de Nomes e encaminhado à Diretoria. Antecipamos desde já que podem surgir perguntas, e estamos à disposição para oferecer toda assistência possível nos processos de aprovação e implementação. Enviado pela Força-Tarefa para Transferências, 30 de novembro de 2002 Recomendações políticas da Força-Tarefa A Força-Tarefa respeitosamente apresenta ao Conselho de Nomes as seguintes recomendações políticas, a serem consideradas como Políticas de Consenso em conformidade com os parâmetros estabelecidos nas Normas de Procedimento do Conselho de Nomes. A menos que haja observações em contrário, a Força-Tarefa acredita que essas recomendações são compatíveis com o consenso da comunidade referente às implicações políticas levantadas pela Força-Tarefa. Ao longo desse relatório encontram-se outros esclarecimentos dessas recomendações e a documentação do nível de apoio a essas políticas.. Recomendações políticas de consenso [Observação da versão de 12 de fevereiro de 2003: Com base na análise
e nas recomendações do Comitê de Implementação, efetuamos algumas alterações
na redação do texto a fim de aumentar a clareza e assim facilitar a
implementação das recomendações. "A análise detalhada da implementação
e os comentários da Força-Tarefa" também foram incorporados integralmente
a este Relatório. Para facilitar a identificação, essas mudanças foram
assinaladas no documento. O texto excluído aparece em fonte 1. Os registrantes devem ter a possibilidade de transferir suas registrações de nomes de domínio entre registradores, contanto que o processo de transferência do Registrador Vencedor siga parâmetros mínimos e que ICANN ou as políticas do registro não proíbam esse tipo de transferência. 2. Sempre que possível, a implementação dessas conclusões e recomendações deve usar os protocolos e padrões já existentes. 3. Os registradores a. Este e-mail é exclusivo para assuntos relativos a transferências. b. O endereço deve ser administrado a fim de garantir que as mensagens sejam recebidas somente por alguém que possa responder ao assunto de transferências. c. Deve-se exigir um prazo para respostas, como por exemplo: "comercialmente razoável", contanto que este prazo não seja superior a XX. d. Definir-se-á um período de tempo de XX durante o processo de implementação, antes da implementação dessas recomendações. 4. Processos de transferências de nomes de domínio entre registradores devem ser claros e concisos a fim de evitar confusão entre os registrantes ou outros interessados. 5. 6. Em registros de gTLDs baseados em EPP, os registradores devem fornecer ao registrante seu "código AuthInfo" exclusivo dentro de um período de tempo razoável a partir do pedido inicial do registrante. A Força-Tarefa observa que esse período de tempo razoável poderia ser de 72 horas ou um período limitado semelhante. 7. Em registros de gTLDs baseados em EPP, os registradores não podem empregar qualquer mecanismo para que um registrante obtenha seu código AuthInfo que seja mais restritivo do que aquele que se exige de um registrante ao mudar qualquer aspecto das suas informações de contato ou de servidor de nomes. 8. 9. O Registrador Vencedor é a. Entretanto, isso não impede o Registrador Perdedor de exercer sua opção de confirmar de maneira independente a intenção do registrante em transferir seu nome de domínio para o Registrador Vencedor. 10. 11. Se o Registrador Perdedor preferir confirmar de maneira independente a intenção do registrante quando o Registrador Perdedor receber do Registro a notificação de uma transferência pendente, o Registrador Perdedor deverá fazê-lo, de maneira compatível com os parâmetros estabelecidos nestas recomendações deste relatório referentes a Registradores Vencedores. Mais especificamente, o formulário de solicitação usado pelo Registrador Perdedor deverá fornecer ao detentor do Nome Registrado instruções claras para aprovar ou negar o pedido de autorização, e uma declaração concisa descrevendo o impacto da decisão do registrante, incluindo as conseqüências se o registrante não responder. a. O propósito dessa exigência não é impedir o Registrador Perdedor de comercializar seus produtos ou serviços aos seus clientes existentes mediante comunicações separadas. O objetivo dessa exigência é garantir que a solicitação empregada pelo Registrador Perdedor tenha um caráter essencialmente administrativo e informativo, e seja expressamente fornecido ao registrante com o propósito de verificar sua intenção. b. Nenhum registrador acrescentará qualquer informação adicional ao Formulário de Autorização Padronizado ou a qualquer formulário ou requerimento usado para obter o consentimento do registrante ou seu contato administrativo. c. O Formulário de Autorização Padronizado deve ser enviado assim que possível do ponto de vista operacional, mas no máximo 24 horas depois de receber o pedido de transferência. 12. Em todos os casos, o pressuposto será que o Registrador Vencedor recebeu e autenticou o pedido de requisitos do registrante ou seu contato administrativo. 13. Nos casos em que o Registrador Perdedor julgar que o Registrador Vencedor não obteve as autorizações descritas nestas recomendações, o Registrador Perdedor poderá dar início a uma disputa, conforme descrição na Implementação de Referência. Qualquer registrador deverá poder iniciar uma disputa. 14. No caso de disputas por pagamento, o Registrador Perderá não poderá empregar processos de transferência como um mecanismo para obrigar um registrante a pagar por serviços (o Registrador Perdedor tem outros mecanismos disponíveis para obter o pagamento do registrante, que não dependem do processo de transferência.) Exceto para o não-pagamento por um período de registração anterior, caso a transferência seja solicitada após a data de expiração, ou não-pagamento do atual período de registração, caso a transferência seja solicitada antes da data de expiração. 15. Em TLDs baseados em EPP, um Registrador Perdedor não pode se recusar a liberar um "Código AuthInfo" para o registrante apenas porque existe uma disputa entre o registrante e o registrador quanto a pagamento. 16. 17. 18. ICANN deve apoiar a elaboração deste Formulário de Autorização Padronizado, orientando sua equipe a consultar os interessados afetados com apoio desta Força-Tarefa, a fim de definir o propósito e o escopo da consulta. Esse formulário deve estar disponível tanto em sistemas físicos (formulário em papel, versão por fax, etc.) quanto automáticos (Internet, e-mail, etc.). 19. Se o Registrador Vencedor precisar basear-se em um processo físico para obter essa autorização, uma cópia em papel do Formulário de Autorização Padronizado será suficiente, desde que tenha sido assinada pelo registrante ou seu contato administrativo, e seja acompanhado de uma cópia em papel do resultado Whois do Registrador Perdedor para o nome de domínio em questão. a. Se os registradores vencedores se basearem em um processo físico, eles assumirão a responsabilidade de obter uma Evidência Confiável da Identidade do Registrante ou Contato Administrativo e comprovar que a entidade solicitante está de fato autorizada a fazê-lo. b. A Força-Tarefa observa que há apoio à idéia de que formas recomendadas que constituem Evidencia Confiável de Autoridade incluem: · Declaração reconhecida em cartório · Carteira de habilitação válida · Passaporte · Contrato social · Certificado de reservista · Identidade emitida pelo estado/governo · Certidão de nascimento c. A Força-Tarefa observa que há apoio à idéia de que no caso de um processo de autorização eletrônico, as formas recomendadas de identificação incluiriam: · assinatura eletrônica em conformidade com a legislação nacional, por exemplo, a Lei para Assinaturas Eletrônicas dos Estados Unidos · endereços de e-mail correspondentes aos endereços do registrante ou do contato administrativo encontrados na base de dados Whois oficial. 20. 21. 22. Juntamente com o Formulário Padronizado de Autorização, devem-se guardar cópias da Evidência Confiável de Identidade. O Registrador Vencedor deve reter uma cópia por escrito ou eletrônica do Formulário Padronizado de Autorização e, se o Registrador Perdedor o solicitar, deve fornecer-lhe uma cópia também. O Registrador Perdedor mantém o direito de inspecionar essa documentação a qualquer momento, de acordo com as exigências existentes para retenção de documentos. 23. Nos casos em que o Registrador Perdedor solicitou cópias do Formulário de Autorização Padronizado, o Registrador Vencedor deverá atender o pedido do Registrador Perdedor (inclusive fornecendo a documentação comprobatória solicitada) dentro de um período de tempo razoável depois de receber o pedido. A Força-Tarefa recomenda três (3) dias úteis. O não-fornecimento dessa documentação dentro do período especificado constitui motivo para revogação pelo operador de registro ou pelo painel para resolução de disputas, caso se protocole uma queixa sobre transferência de acordo com as recomendações neste relatório. 24. Um Registrador Perdedor poderá negar pedidos de transferências somente em circunstâncias específicas, e deve haver uma
lista limitada dos motivos admissíveis para negar um pedido de transferência.
Se os registradores forem a favor de modificações nessa lista e a equipe da ICANN ou outra entidade igualmente aprovada aprovar essas mudanças,
devem-se elaborar procedimentos para realizar essas mudanças. Caso as
mudanças solicitadas constituam novas políticas, ou não sejam autorizadas
pela equipe da ICANN ou pela entidade apropriada, o assunto deve ser
encaminhado para consideração pelo Conselho de Nomes da GNSO. Além disso,
depois de negar um pedido de transferência por alguma razão, os registradores
deverão apresentar ao registrante e ao outro registrador os motivos
da negação. Portanto, um d. Controvérsia razoável quanto à identidade do registrante ou do contato administrativo e. Ausência de pagamento referente ao período de registração anterior (incluindo recusa de cartões de crédito), caso a data de expiração do nome de domínio tenha vencido ou, caso o nome de domínio ainda não tenha expirado, referente a períodos de registração anteriores ou atuais. Em todos os casos, contudo, o nome de domínio deverá ser mantido em "espera do Registrador" pelo Registrador Perdedor antes de negar a transferência. f. Objeção expressa por escrito do registrante ou do contato administrativo (p. ex., e-mail, fax, documento em papel ou outros processos através dos quais o registrante tenha manifestado sua objeção de maneira expressa e voluntária) Um nome de domínio estará bloqueado, contanto que o registrador forneça um meio simples e de acesso imediato para que o registrante remova o bloqueio. Um nome de domínio está nos primeiros 60 dias de um período de registração inicial. Um nome de domínio está no prazo de 60 dias (ou num período menor a ser determinado) depois de ter sido transferido (exceto transferências ao registrador original). 25. Situações nas quais o Registrador Perdedor não pode negar uma transferência incluem, mas não se limitam a: a. Não-pagamento por um período de registração pendente ou futuro b. Ausência de resposta do registrante ou do contato administrativo, a menos que o Registrador Perdedor apresente evidências de objeção expressa por escrito do registrante ou do contato administrativo (p. ex., e-mail, fax, documento em papel ou outros processos através dos quais o Registrante tenha manifestado sua objeção de maneira expressa e voluntária) c. Nome de domínio em status de Bloqueio do Registrador, a menos que o Registrante tenha tido uma oportunidade razoável de desbloquear o nome de domínio antes do Pedido de Transferência. 26. Que os registradores tenham acesso a um processo apropriado através do qual possam contestar transferências específicas depois do fato (isto é, um processo de resolução de disputas conforme a descrição da Implementação de Referência, indicada em outro trecho deste relatório). E que esse processo inclua disposições que cumpram as seguintes exigências: a. A resolução das disputas deve ser administrada por um terceiro, pelo operador de registro correspondente, ou por ambos. b. O escopo do processo deve limitar-se a problemas decorrentes de transferências entre registradores. c. Somente um registrador pode dar início a um processo. d. A apelação a decisões judiciais é permitida, mas em número limitado. e. A política inclui obrigações específicas para que todas as partes da disputa forneçam documentação ao provedor de resolução de disputas. f. O registrador que protocolar a disputa pagará os custos correspondentes e a parte que "perder" a disputa pagará os custos administrativos da resolução da disputa e restituirá as taxas para o início do processo ao registrador que protocolou a disputa, se for o caso. g. A terceira parte que presta o serviço de resolução de disputas ou o registro terá autoridade para determinar que o registro ou registrador em questão devolva o nome de domínio ao estado que o provedor da resolução de disputas considerar apropriado com base nos fatos apresentados durante o procedimento. 27. Que os registros implementem um 28. Que a implementação e execução dessas recomendações sejam monitoradas pela DNSO. Mais especificamente, que: i. Até que ponto as políticas foram implementadas por registradores, registros e registrantes, ii. Se a DNSO deve avaliar eventuais modificações nessas políticas, como resultado das experiências adquiridas durante os estágios de implementação e monitoramento; iii. A eficiência dos processos de resolução de disputas e um resumo dos casos resolvidos pelo processo. b. De acordo com o resultado, o Conselho de Nomes poderá instruir a equipe a: i. Prosseguir com análises bi-anuais, de forma compatível com os requisitos mencionados acima; ou ii. Reportar-se novamente ao Conselho de Nomes num prazo adicional de doze meses. c. O propósito dessas exigências de monitoramento e apresentação de relatórios é permitir que o Conselho de Nomes determine quando, eventualmente, essas recomendações e as políticas decorrentes exigem esclarecimentos ou atenção adicionais com base nos resultados dos relatórios preparados pela equipe da ICANN. 29. Orientação. A Força-Tarefa concluiu três documentos complementares ("Exposição A, Implementação de referência", "Exposição B, Modelo proposto para resolução de disputas" e "Exposição C, Definições padronizadas") para apoiar essas recomendações. Apresentamos essas exposições como orientação para aqueles que deverão elaborar e/ou implementar as políticas adotadas como conseqüência dessas recomendações. Existem muitos problemas complexos derivados da atual política para transferências de nomes de domínio entre registradores. A Força-Tarefa não acredita que os assuntos possam ser tratados em profundidade por um mero pronunciamento político que, como por magia, resolva os problemas enfrentados por registradores, registros e registrantes; Assim, a Força-Tarefa adotou um método para formular suas recomendações, baseadas em princípios condicionais e que têm a concordância de todos os grupos de interessados. Esses princípios dividem-se em quatro categorias básicas:
A condição associada a esses princípios é igualmente simples: equilíbrio. As recomendações desenvolvidas a partir desses princípios devem oferecer um equilíbrio suficiente entre os princípios muitas vezes conflitantes, de modo que as exigências de uma grande variedade de interessados sejam analisadas e tratadas adequadamente. Por exemplo, segurança em detrimento da transparência provavelmente deixaria os registrantes sem um entendimento claro das providências que deveriam tomar se desejassem mudar seu nome de um registrador para outro. Por outro lado, recomendações que enfatizam demais a portabilidade em detrimento da estabilidade deixariam a maior parte dos envolvidos no processo sem um procedimento previsível através do qual pudessem reparar erros ou precaver-se contra eles. As recomendações contidas neste relatório são o produto de um processo aberto e transparente desenvolvido ao longo de um ano. Dedicamos centenas de horas de discussão ao assunto, analisamos muitas propostas, sugerimos dezenas de revisões e em milhares de ocasiões debatemos os méritos de recomendações específicas e abordagens alternativas. Em outras palavras, foi um processo em que as melhores recomendações foram discutidas em profundidade, esclarecidas, ajustadas e finalmente apresentadas como as recomendações de consenso neste relatório. A Força-Tarefa acredita que é esta abordagem, o processo, que representa o argumento mais convincente a favor da adoção dessas recomendações. A verdade é que elas representam as melhores idéias da comunidade, aquelas com as quais a maioria concorda e, o que talvez seja o mais importante, aquelas com o impacto mais compreendido e mais refinado. Isso não significa que os conceitos e idéias que não foram integrados ao relatório não fossem bons ou bem estruturados, ao contrário, havia muitas idéias boas e bem fundamentadas. Entretanto, essas idéias brilhantes não tiveram o apoio necessário da comunidade para incluí-las como recomendações de consenso neste relatório. Além disso, houve também muitas críticas razoáveis a essas recomendações que foram passadas adiante. Porém a menos que elas fossem partilhadas por uma parcela significativa da comunidade, seria impossível apresentá-las como o consenso da comunidade. Essa é uma das características do processo de desenvolvimento de consenso - é necessário lidar tanto com o apoio geral quanto com a discordância geral. Mais uma vez, a Força-Tarefa acredita que cumpriu essa exigência. No entanto, não temos a ilusão de que na DNSO não surgirão novas idéias de consenso e novas discordâncias. Assim, tentamos suavizar essas recomendações com mecanismos de revisão muito restritos e previsíveis, que permitirão que a DNSO ajuste ou corrija a política em curto, médio e longo prazo. Acreditamos que uma abordagem moderada como essa garantirá que a política continuará refletindo a vontade da comunidade no futuro próximo. O processo de desenvolvimento de consenso não é fácil nem trivial. E também não deveria ser. Processos apropriados conduzem a resultados apropriados. Processos equilibrados conduzem a resultados equilibrados. A Força-Tarefa acredita que os processos empregados no desenvolvimento dessas recomendações são equilibrados e apropriados, mas se os resultados precisarem ser ajustados, deve-se usar um método igualmente equilibrado e apropriado para garantir a integridade dos resultados. Análise de impacto, custos e riscos A Força-Tarefa tem a obrigação de garantir que o Conselho de Nomes seja informado de todas as dúvidas relevantes quanto à implementação ou operação decorrentes das recomendações que fazem parte deste relatório. A Força-Tarefa dedicou grande atenção à pergunta: O que significa "dúvidas relevantes quanto à implementação ou operação"? Concluímos que a definição mais efetiva e prática seria analisar as recomendações políticas do ponto de vista daquelas partes que poderiam ser mais afetadas. Assim, solicitou-se que representantes da Força-Tarefa conduzissem uma análise descrevendo quais são os possíveis obstáculos à implementação dessas recomendações e todos os fardos indevidos ou conseqüências não-intencionais que podem ocorrer como resultado da implementação. Essas questões foram esmiuçadas nas especificações gerais de custos e riscos, e provavelmente serão aumentadas pelas análises de impacto dos grupos constituintes enviadas para a Força-Tarefa durante o período para comentários públicos. A Força-Tarefa acredita que esse relatório oferece ao Conselho de Nomes a orientação necessária para aceitar essas recomendações. A Força-Tarefa deixou claro que reconhece que o processo de transferência tem um impacto significativo sobre os registrantes, ao oferecer-lhes a opção de um mudar de um registrador concorrente para outro, independentemente das razões do registrante. Recebemos comentários da equipe da ICANN e dos próprios registrantes, bem como de registradores e registros, observando que os registrantes podem ser prejudicados de várias maneiras quando ocorre uma transferência errada ou com propósitos fraudulentos de algum terceiro, ou quando a transferência não foi legitimamente autorizada ou solicitada pelo registrante. Alguns registrantes receberam o pedido para que renovem seus contratos com um registrador do qual gostariam de se desligar porque acreditam, ou ouviram dizer que sua registração pode expirar. A renovação então os mantém presos, até uma outra data quando poderão tentar a transferência novamente. O resultado pode ser uma falta de opção para o registrante, ou taxas de registração adicionais quando fizerem a renovação e então seguirem adiante com a transferência. Os registrantes se beneficiarão de uma abordagem clara, transparente e documentada para transferências, que limite fraudes ou abusos e que ofereça clareza sobre como podem efetuar uma transferência autorizada. Ambas são questões de "paz de espírito", porém, mais importante ainda, representam impactos econômicos e sociais reais para um registrante que está operando um site para comunicar-se com o público e que teme riscos, perder seu nome de domínio ou que seu site "saia do ar" durante um período de recuperação. Os registrantes precisam ser claramente informados, por comunicações tanto da ICANN, via seus processos de distribuição normais, quanto de seus registradores, sobre as mudanças nas práticas baseadas em mudanças políticas. Este relatório contempla muitas obrigações novas e/ou modificadas que podem ou não ser compreendidas inteiramente por todos os registradores. É importante garantir que ICANN e a DNSO estejam preparadas para promoverem a divulgação e a informação dessas medidas para assegurar que todos os registradores credenciados por ICANN tenham conhecimento e cumpram essas obrigações novas e modificadas. Algumas das obrigações contidas neste relatório são mais limitantes do que as políticas anteriores. Isso exigirá que os registradores garantam que seus sistemas e processos internos estejam em conformidade com quaisquer políticas adotadas em conseqüência dessas recomendações. Algumas das recomendações contidas nesse relatório exigirão que os registradores modifiquem seus sistemas técnicos internos para viabilizar as políticas adotadas em conseqüência desse relatório. Entretanto, muitos registradores já empregam sistemas que já estão de acordo com as recomendações apresentadas nesta proposta, ou exigem aperfeiçoamentos mínimos para estarem de acordo. Mesmo que o grau de modificações varie de um registrador para outro, a Força-Tarefa não acredita que os custos decorrentes dessas modificações serão muito significativos. Além disso, as evidências sugerem que os benefícios de longo prazo obtidos pela implementação de processos padronizados em algumas áreas da operação de transferência produzirão uma maior confiança dos consumidores, e assim compensem os eventuais custos de curto prazo envolvidos. Finalmente, essas recomendações não pretendem fornecer especificações referentes ao tipo de tecnologia e nível de automação exigidos para implementar essas recomendações. Isso está além da responsabilidade desta Força-Tarefa. A Força-Tarefa concorda, porém, que essas mudanças podem resultar em custos maiores para os registradores. Ao longo da discussão para implementação, será possível identificar áreas de custo com ajuda de um grupo de trabalho composto pela equipe da ICANN, registradores, registros e, se necessário, especialistas técnicos externos. A Força-Tarefa dispõe-se a fazer os contatos necessários para esse empreendimento e representar os interesses mais amplos dos usuários quando for conveniente. Portanto, a Força-Tarefa acredita que como: a) os registradores mantêm a capacidade de exercer um alto grau de controle sobre os eventuais custos decorrentes dessas obrigações e b) os registradores mantêm o seu direito de buscar o ressarcimento de custos de acordo com seus contratos de operação, o impacto total dessas obrigações será bastante limitado. Impacto para registros de gTLDs (Observação: Esta seção foi acrescentada em 12-12-02) Este relatório contempla várias obrigações novas e/ou modificadas que terão impacto sobre os registros de gTLDs e, assim como no caso dos registradores de gTLDs, será importante garantir que ICANN e a DNSO estejam preparadas para promover a divulgação e informação dessas medidas a fim de que todos os registros e registradores tenham conhecimento e cumpram essas obrigações novas e modificadas. Talvez a recomendação com o maior impacto sobre os registros de gTLDs seja a possibilidade de poderem atuar como provedores de resolução de disputas, nos casos em que registradores disputam uma transferência ou um Registrador Perdedor contesta uma transferência. Isso pode exigir que registros de gTLDs forneçam novos recursos, incluindo apoio aos consumidores e à equipe, que não oferecem no momento. Além disso, isso pode exigir que os registros de gTLDs participem de investigações limitadas, numa tentativa de obrigar o cumprimento das recomendações neste relatório. Sem dúvida, isso pode acabar acrescentando custos extras para os registros de gTLDs, mas estes custos poderão ser recuperados de acordo com as disposições dos atuais Contratos de Registros de gTLDs com ICANN. A Força-Tarefa não acredita que os custos decorrentes dessas modificações serão muito significativos, tendo em vista os esforços para padronizar o processo de transferência e conseqüentemente aumentar a certeza para usuários finais e, em última análise, a portabilidade dos nomes de domínio. Ao longo da discussão para implementação, será possível identificar áreas de custo com ajuda de um grupo de trabalho composto pela equipe da ICANN, registradores, registros e, se necessário, especialistas técnicos externos. Análise geral de riscos e custos Os riscos e custos associados a esta proposta ainda precisam ser totalmente definidos, e a Força-Tarefa reconhece isto. Tendo em vista que o período de implementação irá revelar muitos aspectos sobre "como" fazer a implementação, e como haverá áreas de flexibilidade para os registradores individuais, a Força-Tarefa acredita que será mais conveniente efetuar essa etapa durante o Processo de Implementação. Assim, a Força-Tarefa não realizou uma análise em profundidade dos riscos e custos associados a esta recomendação além daquilo que foi incluído no item "Análise de impacto" deste relatório. Embora consideremos que a Análise de Impacto e os Relatórios de Impacto dos Grupos Constituintes oferecerão um alto nível de identificação dos riscos e custos do momento, a Força-Tarefa acredita que outros riscos ou custos que ainda não foram identificados ou completamente documentados só irão se manifestar ao longo das etapas de implementação e monitoramento, contempladas pelas Recomendações de Conselho da Força-Tarefa. Durante o período de implementação, esses custos e riscos devem ser documentados e deverão ser levados em conta ao longo do próprio período de implementação. Mais uma vez, a Força-Tarefa pressupõe que os custos podem incluir custos da equipe e custos dos sistemas. É provável que a equipe da ICANN seja mais exigida e que se torne mais fácil documentar os custos, de modo que talvez seja necessário solicitar que a gerência da ICANN conceda mais tempo à equipe da ICANN para abordar problemas de transferências. Assim que se implementar um novo processo, "testado" durante o uso prático e real, pode ser que a exigência de tempo da equipe diminua. A Força-Tarefa, porém, não tem certeza de que isso ocorrerá em curto prazo, já que sem dúvida haverá mudanças constantes no competitivo "mercado" de registradores, com as mudanças habituais que ocorrem em um setor de mercado - consolidação, expansão, fusões, crescimento de novos registradores, etc. Portanto, a gerência da ICANN deve prever tempo e recursos adicionais para a equipe da ICANN. Além disso, nossa opinião é que, assim que se identificarem os custos iniciais durante o período de implementação, essas áreas passem a fazer parte dos relatórios periódicos de implementação recomendados pela Força-Tarefa. Contudo, esses relatórios também devem incluir o número de incidentes e o impacto sobre registrantes. Análises de impacto dos grupos constituintes (CI) A Força-Tarefa não recebeu nenhuma análise de CI antes da documentação deste documento. Assim, eles serão publicados assim que os recebermos, e incorporados por referência na seguinte URL: http://www.byte.org/nc-transfers/ci/ (Observação: Até 12-12-02, a Força-Tarefa não havia recebido nenhuma Análise de Impacto dos Grupos Constituintes.) (Observação: Em 14-12-02, o Conselho de Nomes da DNSO aprovou a seguinte resolução por unanimidade: O Conselho de Nomes aceita as recomendações políticas pertencentes ao Relatório da Força-Tarefa para Transferências de 30 de novembro. O Conselho de Nomes formará um comitê de análise de implementação, composto pelos contatos da Força-Tarefa para Transferências com registros e registradores, com a equipe da ICANN e com os usuários. Esse comitê concluirá sua análise até 30 de janeiro de 2003. Em seguida, o Conselho de Nomes se encontrará para discutir o relatório final para a Diretoria da ICANN em sua reunião em fevereiro, encaminhando o relatório final para a Diretoria para que este chegue aos destinatários 30 dias antes da reunião da ICANN no Rio de Janeiro. O relatório do comitê de análise da implementação apresentará as conclusões sobre a viabilidade de se implementar a política e já poderá ser incluído no relatório, que passará a ser o Relatório sobre Transferências para a Diretoria.) [Observação: Os comentários sobre implementação da Força-Tarefa serão analisados imediatamente a seguir]. Análise detalhada da implementação e comentários da Força-Tarefa Em 31-01-2003, o Comitê para Implementação de Transferências apresentou seu relatório final ao Conselho da GNSO de acordo com esta resolução. Esse relatório pode ser encontrado na íntegra na Exposição D deste relatório. As recomendações significativas deste Comitê de Implementação (Imp-Comm), acompanhadas de uma análise por esta Força-Tarefa, são as seguintes:
Outras observações e considerações Ao longo do seu trabalho, a Força-Tarefa verificou que havia muitas observações e considerações genéricas que, mesmo não sendo parte integrante das recomendações políticas específicas, eram muito valorizadas pela comunidade e eram totalmente pertinentes ao objeto de análise da Força-Tarefa. Assim, gostaríamos de chamar a atenção do Conselho de Nomes para os seguintes princípios gerais. Estes princípios não são recomendações políticas formais da Força-Tarefa, e são apresentados apenas com a intenção de esclarecer a análise realizada pela Força-Tarefa e a comunidade. Estes princípios têm caráter apenas de recomendação e não incluímos nenhum comentário expresso ou implícito sobre se eles representam ou não o consenso formal de qualquer segmento da comunidade. Além disso, é importante observar que eles não estão sendo apresentados nem devem ser interpretados como recomendações alternativas ou concorrentes para as Recomendações Políticas de Consenso da Força-Tarefa. 1. Os registradores não devem usar processos de transferência que apresentem qualquer conflito de contratos com ICANN ou com o Registro. Se houver algum conflito, os contratos com ICANN ou com o Registro prevalecerão. Os registradores (e seus agentes) não poderão acrescentar outras restrições para um registrante na forma de um contrato de serviço contrário à política e/ou ao contrato da ICANN ou do Registro em relação a transações de transferências de nomes de domínio entre registradores. 2. As transferências de nomes de domínio entre registradores devem ser conduzidas de maneira a promover a confiança dos registrantes. 3. Registrantes, registradores e registros destacaram a importância de um processo de transferência entre registradores que aumente a segurança, estabilidade, transparência e portabilidade presentes nas atuais políticas. 4. Os registradores devem levar em conta as diferenças jurídicas, lingüísticas e culturais do mercado de registração de nomes de domínio, dos registradores e dos registrantes quando implementarem processos de transferência de nomes de domínio entre registradores. 5. Registradores e registros não devem elaborar processos de transferência entre registradores que resultem em ônus indevidos para o registrante, registrador ou registro. 6. Sempre que possível, estimulamos registradores e registros a automatizar processos de transferência de nomes de domínio entre registradores. 7. As políticas e os processos de transferência de nomes de domínio entre registradores adotados por registros e registradores devem oferecer a estes o máximo de flexibilidade possível ao determinar a escala, o escopo e as tecnologias usadas em suas próprias implementações específicas, de acordo com seus próprios modelos de negócios. 8. Quando possível, os registradores só devem iniciar transferências de nomes de domínio entre registradores a pedido do registrante ou seu contato administrativo. 9. Recomenda-se que o Registrador Perdedor use o conjunto de comandos EPP ou RRP equivalente a "Espera do registrador" antes de receber uma notificação de transferência do registro como mecanismo para garantir o pagamento de um registrante em caso de não-pagamento. O Registrador Perdedor não deve usar o conjunto de comandos EPP ou RRP equivalente a "Bloqueio do registrador" para o mesmo fim. 10. Transferências entre registradores devem ser conduzidas de maneira segura e viável, e não permitir a influência ou manipulação indevida pelo registrador perdedor ou qualquer outro terceiro. O propósito da Força-Tarefa para Transferências é:
No início de 2001, começaram a surgir queixas de vários registradores sobre pedidos de transferência negados, incluindo atrasos significativos e respostas confusas. Em 25 de maio de 2001, o registrador Verisign entrou em contato com os outros registradores, informando que estava tomando providências específicas para reparar essa situação e anunciou uma política que parece estar em conflito com a política padrão descrita no Apêndice B do Contrato de Credenciamento de Registrador com a Verisign. Em 16 de julho de 2001, a Verisign Corporate comunicou a Stuart Lynn, Presidente da ICANN, que havia adotado uma política padrão de não-reconhecimento para proteger seus clientes contra transferências não-autorizadas. Em 27 de agosto de 2001, Stuart Lynn respondeu ao Grupo Constituinte de Registradores, recomendando a criação de uma nova política para tratar do problema. Louis Touton, Conselheiro Geral e Secretário da ICANN, respondeu ao pedido da Verisign, indicando que registradores não podem negar pedidos de transferência que o registrador vencedor havia verificado simplesmente porque o registrador perdedor não havia feito a verificação. Durante julho, agosto e setembro, o Grupo Constituinte de Registradores elaborou e aprovou, dentro do grupo, um protocolo referente a transferências, com a intenção de que esse protocolo fosse seguido por todos os registradores credenciados, dando assim certeza ao registrante sobre o que acontece quando ele troca de registrador, ou quando seu agente encarregado troca de registrador em seu nome. Após uma exaustiva análise e discussão, o grupo produziu um documento final com ampla orientação e submeteu-o à votação dos registradores. O resultado da votação:
Entretanto, apesar da votação, não houve uma aceitação completa entre o Grupo Constituinte de Registradores, e pelo menos um registrador - talvez mais - ainda não se adaptou ao procedimento recomendado, segundo a definição no protocolo dos registradores para transferências. Quando os outros grupos constituintes tomaram conhecimento dessa situação antes da reunião da ICANN em Montevidéu, no segundo semestre de 2001, tornou-se evidente que os outros grupos não estavam totalmente cientes da situação ou da solução que os registradores estavam elaborando. Três grupos (IPC, ISPCP, BC) tiveram uma reunião com o representante do Grupo Constituinte de Registradores. Verificou-se que os outros grupos acreditam que seus membros (usuários/registrantes) estão sendo afetados por essa situação, e alguns questionaram se haveria problemas quanto à política e quanto aos contratos. Também ficou claro que, embora o protocolo seja o primeiro passo, são necessárias outras áreas de trabalho, e o Grupo Constituinte de Registradores reconheceu este fato. O assunto foi submetido à consideração do Conselho de Nomes na teleconferência seguintes (11 de outubro de 2001), resultando na criação de uma Força-Tarefa de "acompanhamento rápido". I. Teleconferências e reuniões abertas a não-participantes da força-tarefa
II. Comentários do público e dos grupos constituintes enviados para a Força-Tarefa Comentários do público sobre o Relatório Preliminar da Força-Tarefa, 16-30 de outubro de 2002 (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/)
Os comentários relevantes incluem: 1. Reunião do Conselheiro Geral referente à implementação de políticas por registradores e operadores de registros (http://www.icann.org/legal/briefing-on-implementation-20oct02.htm) · Orientação específica para que a Força-Tarefa desenvolva políticas que possam ser implementadas de acordo com os contratos da ICANN, de modo que se atinjam os mesmos objetivos das políticas. 2. De Tim Ruiz (et al) (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/doc00000.doc) · transferências fraudulentas são um problema maior do que se imagina · a proposta não protege contra o marketing enganoso · auto-reconhecimento sugere uma autoridade aparente obtida de modo fraudulento · necessidade de outra votação do grupo constituinte de Registradores · contratos exigem mudanças significativas · sistemas entre registradores/registros exigem mudanças significativas 3. De Danny Younger (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/msg00006.html) · Um resumo de várias queixas dos consumidores referentes a transferências, incluindo: o registradores que aplicam uma política de "não-reconhecimento automático" o e-mails confusos tentando confirmar desejos de registrantes o recusa indevida de pedidos de transferências por parte de registradores perdedores o processos complicados impostos por registradores perdedores o pouco apoio para consumidores o regras pouco claras e incoerentes para determinar quando um nome de domínio pode ser transferido o práticas de marketing enganosas ou confusas destinadas a segurar clientes o problemas com idiomas estrangeiros o dados Whois incorretos, complicando o processo de transferência o impossibilidade de atualizar dados Whois o definição indevida de "autoridade aparente" o a condição de não-pagamento não deve afetar a possibilidade de transferir o os procedimentos devem ser uniformes para todos os registradores o revendedores devem anunciar melhor suas políticas o falha de registradores em liberar códigos de autenticação o uso indevido do recurso "Bloqueio do Registrador" o transferências não-autorizadas/ "seqüestro de domínio" o cobrança por transferências pelos registradores perdedores o não-atendimento de queixas / descumprimento de contratos 4. De Hollenbeck (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/msg00009.html) · comentários re: modelos operacionais EPP 5. De Danny Younger (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/msg00011.html) · um resumo dos deveres impostos pela política 6. De Danny Younger (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/msg00013.html) · Descrição das Normas de Procedimento do Conselho de Nomes, e em que medida o Relatório Preliminar não segue essas normas. (Observação: A seção seguinte foi acrescentada em 12-12-02 para
que o Relatório Final incluísse todos os comentários recebidos pela
Força-Tarefa durante seu período final para comentários públicos.)
Os comentários relevantes incluem: 1. De Elana Broitman (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/msg00001.html) · questões sobre o que significa uma "Especificação do impacto sobre o grupo constituinte" e a incapacidade do grupo constituinte de Registradores criar e oferecer uma resposta nos oito dias concedidos. 2. De Danny Younger (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/msg00002.html) · comentários sobre as deficiências identificadas no processo seguido pela Força-Tarefa e os dados e análises apresentados no Relatório Final da Força-Tarefa. 3. De Danny Younger (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/msg00003.html) · preocupação com o prazo limitado durante o qual o Relatório Final esteve disponível para comentários. 4. De Jeff Williams (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/msg00004.html) · concorda com a avaliação de Broitman (acima) · concorda com as críticas de Younger (acima) · preocupação com a falta de informações para contato no Relatório Final · preocupação com a falta de opções e de diversidade que o regime de credenciamento da ICANN está criando. 5. Do Grupo Constituinte de Registros (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/msg00005.html) · solicita formalmente que não se tome nenhuma decisão sobre o Relatório Final durante a reunião do Conselho de Nomes em 14 de dezembro de 2002; o muito pouco tempo para que a comunidade analise e responda ao Relatório Final o o Relatório Final provocou uma discussão na comunidade que precisa ser levada em conta o o Grupo Constituinte de Registros apóia muitas das recomendações do Relatório Final, mas aguarda para adotar uma posição final até que o assunto tenha sido analisado em outros grupos, incluindo o grupo constituinte de Registradores · propõe adiar a decisão sobre o assunto até a reunião do Conselho de Nomes em janeiro de 2003. 6. De Chuck Gomes (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/msg00007.html) · apresenta uma lista de dezesseis princípios formalmente endossados por dez registradores credenciados por ICANN · destaca a importância do apoio dos registradores para as políticas propostas e convida outros registradores que também apóiam o documento para também darem uma indicação formal de apoio. Relatório de opiniões divergentes As Normas de Procedimento do Conselho de Nomes especificam que todas as Recomendações Políticas de Consenso de uma força-tarefa precisam incluir "uma especificação justa das posições contrárias e uma análise significativa dos seus méritos e da intensidade da oposição". Apesar de até o momento a Força-Tarefa não ter recebido nenhum material importante que corresponda ao que, classicamente, se denomina um "Relatório de opiniões divergentes", a Força-Tarefa recebeu muitas consultas e comentários que deveriam ser incluídos nesta seção do relatório, conforme os parâmetros para um "Relatório de opiniões divergentes" definidos nas Normas de Procedimento do Conselho de Nomes. Essa porção do Relatório Final é apresentada no formato de "Perguntas e respostas", concentrando-se nas perguntas e comentários que a Força-Tarefa recebeu de maneira informal e formal, ao longo de sua existência. Acreditamos que as Recomendações Políticas da Força-Tarefa e este relatório abordam em profundidade cada uma dessas implicações. Cada resposta a essas perguntas é acompanhada por uma análise do mérito e intensidade da objeção apresentada. 1. "Aparentemente, a Força-Tarefa só abordou as considerações levantadas por uma proposta que foi encaminhada pela comunidade, e não outras que também foram apresentadas. Será que uma das exigências da Força-Tarefa não é tratar todas as propostas importante apresentadas pela comunidade?" R. Ao longo da evolução deste assunto e do trabalho da Força-Tarefa, surgiram e continuam surgindo várias propostas, com a intenção de abordar as preocupações levantadas pela comunidade. Após um cuidadoso exame dos tópicos e suas abordagens, a Força-Tarefa concluiu que nenhuma dessas propostas alternativas trata os assuntos de fato em toda sua profundidade e amplitude, e portanto não representa soluções completas ou que tenham apoio consensual. Enquanto desenvolvia as recomendações incluídas neste Relatório Final, a Força-Tarefa analisou tantas propostas quanto foi possível, levando em conta que houve vários períodos durante os quais seria possível enviar comentários e propostas significativas e que não obstante, algumas propostas foram recebidas muito depois do encerramento dos períodos para comentários públicos (elas continuam aparecendo, como mais recentemente em 11/27/02). Quando tinham o apoio do consenso da comunidade, os princípios e políticas contidos nessas propostas alternativas foram incluídos neste relatório. Reconhecendo que o desenvolvimento dessas políticas levou um período de tempo extraordinariamente longo em razão da complexidade dos problemas, e que a DNSO deseja resolver esses problemas dentro de um prazo razoável, a Força-Tarefa recomendou expressamente uma estrutura para que o Conselho de Nomes e as entidades que o sucederem analisem a implementação de qualquer política adotada como resultado desse documento, em intervalos de tempo periódicos. O propósito dessas exigências de análise é garantir que ICANN possa continuar aperfeiçoando as novas políticas de consenso e ao mesmo tempo aprenda com sua implementação.
2. "As recomendações políticas que vocês apresentaram não parecem suficientemente claras para oferecer a registrantes, registradores e registros o nível de confiança adequado. Será que a Força-Tarefa não deveria procurar definir claramente todos os aspectos do processo de transferência?" R. Existe uma diferença fundamental entre criar recomendações políticas que definem claramente um processo previsível, conduzindo à confiança de registrantes, registradores e registros, e uma tentativa de definir todos os aspectos da transferência. Ao tentar responder a essa preocupação em particular, a Força-Tarefa se concentrou basicamente em cumprir as exigências impostas pela primeira alternativa. Reconhecendo a importância de usar termos facilmente compreensíveis pelo universo mais amplo das partes afetadas, a Força-Tarefa criou uma lista de definições padronizadas que deve responder a essa preocupação. Além disso, a Força-Tarefa também forneceu informações em várias exposições relacionadas ao Processo de Implementação. Esses dados são apenas "informativos", embora representem um exaustivo trabalho da Força-Tarefa e sejam produto de muitas horas de consulta.
3. "Embora isso tenha sido levantado várias vezes, a Força-Tarefa não faz nenhuma recomendação específica quanto ao assunto de 'Autoridade aparente', tal como existe atualmente na política corrente. Como este relatório trata desses assuntos?" R. Ao elaborar essas recomendações, a Força-Tarefa dedicou uma grande parte do seu tempo e atenção para compreender não apenas a noção de Autoridade Aparente, tal como prevêem as políticas existentes para transferências, mas também para tentar entender o propósito dessas políticas. A Força-Tarefa levou em conta os comentários (provenientes de um número limitado de remetentes) que tratavam de "autoridade aparente", procurou a orientação da equipe jurídica da ICANN e empreendeu análises exaustivas da sua utilidade. Como resultado desta deliberação, a Força-Tarefa chegou à conclusão que a idéia de "Autoridade aparente" não era suficientemente precisa para oferecer aos registrantes, registradores e registros a transparência, segurança, confiabilidade e previsibilidade no processo de transferência necessárias para satisfazer as necessidades da maior variedade possível de partes afetadas. Assim, o conceito de "Autoridade aparente" foi substituído por um grupo muito limitado de entidades que estão autorizadas a aprovar uma transferência.
4. "Algumas partes gostam de 'criar suas próprias políticas' e assim parece que sempre acabamos tendo um sistema que pode facilmente ser manipulado. Como este relatório lida com essa questão?" R. A Força-Tarefa ouviu uma grande variedade de preocupações manifestadas em todos os grupos envolvidos, indicando que enquanto houvesse uma "manipulação" contrariando as políticas estabelecidas ou que onde não havia nenhuma política, a Força-Tarefa deveria tentar abordar as implicações decorrentes desse comportamento de forma pró-ativa. Assim, as recomendações da Força-Tarefa procuram cobrir ao máximo os "buracos" na política, sem prejudicar indevidamente nenhum grupo específico. Em termos gerais, a Força-Tarefa conseguiu fazer isso de duas maneiras: a) esclarecendo que é o Registrador Vencedor que é obrigado a verificar a intenção do registrante; e b) limitando a quantidade de motivos pelos quais uma transferência deveria ser negada. Tendo em vista que a Força-Tarefa concluiu a partir das comunidades de usuários que essas duas áreas eram as que mais afetavam sua capacidade de transferir efetivamente seus nomes de domínio dentro da política atual[3], temos todos os motivos para crer que as recomendações para essas duas áreas abordarão a maior variedade possível de problemas, prevendo ao mesmo tempo o máximo de flexibilidade de implementação para registros e registradores.
5. "Como 'terceiros' poderão autenticar transferências segundo essas recomendações?" R. A política proposta limita o número e o tipo de entidades que podem verificar a intenção do contato administrativo ou do registrante em realizar a transferência. Portanto, se o registrante quiser conferir a um terceiro a capacidade de aceitar ou negar pedidos de transferência de Registradores Vencedores, o registrante deverá designar esse terceiro como o seu contato administrativo. A Força-Tarefa ouviu um número limitado de entidades quanto às suas preocupações, mas também recebeu o seu apoio quanto à necessidade de um processo efetivo. Esses comentários fazem parte dos registros de consultas.
6. "Às vezes revendedores e ISPs representam o registrante. Sem a noção de 'Autoridade aparente", será impossível para essas partes autenticar uma transferência. Como essas recomendações tratam esse problema?" Basicamente, esta é a mesma pergunta da questão 5. Os registrantes precisam entender o que eles estão delegando a um terceiro. Acreditamos que esta dúvida é pertinente, e que a solução proposta é satisfatória. Além disso, quando o registro usa códigos auth-info, o registrante teria a liberdade de compartilhar esse código com a entidade autorizada a agir em seu nome. 7. "Não-provedores precisam participar do processo de desenvolvimento de políticas. Como a força-tarefa tratou as exigências de 'usuários' (ou seja, registrantes) durante a formulação dessas recomendações?" R. Consultamos vários tipos de registrantes ao longo de toda elaboração deste relatório, na pesquisa descrita em outros trechos deste documento. Além disso, a maioria, se não todos os tipos de usuários estiveram diretamente representados pelos seus representantes na composição da Força-Tarefa. Os grupos de registrante que não estavam diretamente representados foram consultados pela Força-Tarefa a fim de garantir que as recomendações fossem adequadas às suas necessidades. Por causa das nossas preocupações quanto a registrantes, a Força-Tarefa realizou várias sessões de informação. Num certo momento, a Força-Tarefa determinou que havia obtido contribuições suficientes sobre o impacto para os registrantes para poder fazer recomendações políticas.
8. "Mesmo quando as melhores políticas são cumpridas da maneira mais rigorosa por todos os participantes, algumas coisas dão errado. Com nomes de domínio, isso pode significar que um registrante fique sem o uso de seu nome de domínio durante um período. Segundo a atual política, isso geralmente significa que os registrantes precisam esperar pelo melhor e colocar seu destino nas mãos de um registro, que pode ou não cooperar quando se trata de 'fazer as coisas direito'. Esse relatório trata dessa dinâmica de maneira objetiva?" R. Especificamente, sim. Essa dinâmica é abordada de duas maneiras. Primeiro, o relatório recomenda um processo de resolução de disputas entre registrantes e seu registrador para que seus problemas sejam resolvidos formalmente, de acordo com um processo pré-definido. A Força-Tarefa prevê que esse processo será bastante semelhante à atual Política Uniforme para Resolução de Disputas. Em segundo lugar, a Força-Tarefa também recomenda que provedores de registros de gTLDs aumentem seus recursos comerciais com uma "função desfazer", a qual devolveria a registração de domínio a um estado anterior, que do ponto de vista funcional seria idêntico em todos os aspectos ao estado em que o nome de domínio estava antes que ocorresse qualquer erro ou interferência.
9. "Alguns registradores usam livremente a função 'Bloqueio do registrador' relacionada aos nomes de domínio que eles registram para os registrantes. Muitas vezes isso significa que os registrantes *não podem* transferir seu nome de domínio de maneira previsível. As recomendações da Força-Tarefa levam isso em conta?" R. Durante exaustivas discussões na Força-Tarefa e outras consultas à comunidade após o Relatório Preliminar, a Força-Tarefa elaborou uma pequena série de recomendações com emendas que apenas exigem que os registradores forneçam aos registrantes mecanismos simples e transparentes através dos quais os registrantes possam simplesmente desbloquear ou bloquear seu nome de domínio, usando procedimentos acessíveis definidos pelo registrador.
10. "Será que a documentação obtida pelo Registrador Vencedor não deveria obedecer um padrão mais elevado, em razão da sua influência sobre o sistema? Se os documentos que eles obtiveram forem autenticados em cartório ou de alguma outra forma, o processo seria muito mais seguro para os registrantes." R. Ainda que processos mais rigorosos como os descritos nesta pergunta possam criar um ambiente mais seguro para registrantes, processos excessivamente rigorosos não oferecem os níveis de portabilidade pelos quais os registrantes manifestaram claramente sua preferência. O segredo de qualquer política de transferências bem-sucedida está no equilíbrio entre as exigências de segurança e estabilidade de registradores, registros e registrantes e as exigências de transparência e portabilidade desses mesmos grupos. A Força-Tarefa ouviu comentários contrários aos custos e inconveniências de autenticações em cartório, bem como manifestações de alguns registradores que queriam exigir esses documentos. Surgiram também algumas dúvidas quanto a exigir que indivíduos, mesmo quando representarem uma empresa ou organização, enviem fax de cópias de licenças de habilitação, o que pode incluir números de inscrição na seguridade social, etc.
11. "Até que ponto a Força-Tarefa acompanhou a discussão ocorrida em vários fóruns na DNSO e no restante da comunidade?" R. A Força-Tarefa acredita que os seus membros têm um conhecimento detalhado da grande variedade de problemas levantados pela comunidade em vários fóruns. Isso foi possível graças às diversas reuniões abertas, participação em listas de correio, consultas ao público, teleconferências e sessões de divulgação empreendidas pela Força-Tarefa em toda DNSO. Vários membros da Força-Tarefa são membros da Assembléia Geral, por exemplo. Além disso, a própria Assembléia Geral está representada na Força-Tarefa. À medida que outras discussões vieram a público, a Força-Tarefa tentou aproveitar essas informações.
12. "Será que a opção 'auto-reconhecimento' simplesmente não estimula a ocorrência de atividades fraudulentas?" R. As opções específicas de "reconhecer" ou "não reconhecer" em si não incentivam nem desencorajam atividades fraudulentas, e a Força-Tarefa continua questionando a base dessas conclusões. Contudo, a Força-Tarefa acredita que os processos empregados com processos de "reconhecimento" ou "não-reconhecimento" pelas diversas partes envolvidas numa transação de transferência podem conduzir a uma maior ou menor incidência de fraude. O fato desses processos conduzirem a incidências maiores ou menores de fraude depende apenas do incentivo ou desencorajamento ao comportamento apropriado. Tendo em vista a necessidade esmagadora de portabilidade aliada à segurança, a Força-Tarefa determinou que há apoio geral a uma política padrão de "reconhecimento", acompanhada de medidas severas de autenticação e controle. Quase universalmente, preferiu-se o "reconhecimento" padrão às alternativas, em razão da maior portabilidade e estabilidade que ele oferece aos registrantes, da semelhança do processo com a política existente e a relativa simplicidade e baixo impacto que esses processos apresentam em comparação às alternativas.
13. "Por que essas recomendações não indicam também como proteger registrantes contra práticas de marketing inescrupulosas?" R. A Força-Tarefa foi encarregada de analisar os aspectos mais estritos das transferências. Sempre que possível, tentamos elaborar recomendações que atendessem as queixas que recebemos sobre como algumas comunicações conduziam a uma transferência indesejada pelo registrante. Nossas recomendações referem-se a processos de transferência, não a práticas de marketing. Baseando-se em contribuições importantes de registradores, registros e registrantes, a Força-Tarefa recomendou especificamente que se usem processos e documentos padronizados e transparentes quando for apropriado. Acreditamos que isso produz um equilíbrio razoável entre as preocupações apresentadas e o âmbito do processo normativo da DNSO e desta Força-Tarefa. Observamos que, como de hábito, a equipe da ICANN, ou o registrante, ou mesmo outro registrador ou registro preocupado, pode encaminhar queixas sobre comércio enganoso para a autoridade legal competente, que nos Estados Unidos é o Procurador Geral ou a Comissão Federal de Comércio. Em outros países existem autoridades semelhantes. A Força-Tarefa não abordou nem julgou que a área de práticas de comércio fizesse parte do seu escopo de trabalho.
14. "Transferências fraudulentas representam um problema muito maior do que a 'manipulação' das atuais políticas pelos registradores. Por que não se abordaram as transferências fraudulentas de maneira mais explícita?" R. A Força-Tarefa levou essa reclamação a sério e tentou exigir que as entidades afetadas e a equipe da ICANN quantificassem ou documentassem suas queixas. No final, a Força-Tarefa não tinha nenhum dado que corroborasse a conclusão descrita. Apesar de repetidas solicitações, essa queixa nunca foi quantificada de maneira significativa e na verdade foi contrariada pelos dados fornecidos pela equipe da ICANN. Esses dados indicaram que o volume de queixas referentes à impossibilidade de registrantes transferirem seus nomes de domínio rapidamente superava todas as queixas de atividade fraudulenta. Observando as implicações de transferências fraudulentas de nomes de domínio (apropriação e seqüestro de nomes), a Força-Tarefa concluiu que seriam desejáveis processos rigorosos para controle de cumprimento e remediação. Uma consulta à comunidade confirmou amplo apoio consensual a esta abordagem.
15. "Os principais registradores estão praticando o não-reconhecimento automático, e declaram que isso reduziu significativamente as transferências fraudulentas. Será que permitir que o registrador perdedor realize o 'não-reconhecimento automático' não produziria os resultados esperados? O que há de errado com a política atual?" R. Conforme observamos em outra parte desta análise, o "não-reconhecimento" automático trata apenas de um aspecto relativamente simples do problema político mais amplo, e não atende as necessidades mais amplas da comunidade geral. Além disso, como se tentou demonstrar constantemente ao longo desse esforço normativo, a atual política não oferece padrões suficientemente rigorosos ou a função de controle do cumprimento das exigências para tornar a política realmente útil. É necessário reconhecer que há um grande número de queixas sobre as atuais práticas de "não-reconhecimento automático", não apenas dos registradores, mas dos registrantes. Essas queixas conduziram à criação da Força-Tarefa e ao esforço de entender como revisar a política em primeiro lugar.
16. "A proposta corrente cria um incentivo para que registradores vencedores obtenham a 'autoridade aparente' do cliente através de outros meios, possivelmente incluindo práticas de comércio enganosas, já que ela permitirá transferências sem que se verifique a declaração objetiva do registrante sobre sua intenção ao transferir. Como a proposta trata situações em que a 'autoridade aparente' é conseguida por fraude em práticas comerciais enganosas?" R. Primeiramente, a "autoridade aparente" é substituída por um processo mais definido para determinar quem pode autorizar uma transferência legítima. Em segundo lugar, quando o registro usa códigos "authinfo", estes oferecem salvaguardas adicionais. Finalmente, e o que é muito importante, as recomendações descrevem especificamente uma série de medidas que permitirão que um registrante ou registrador "conserte" os eventuais erros causados em decorrência da violação intencional ou não-intencional das políticas implementadas como resultado dessas obrigações.
17. "Essa proposta se baseia em antigos conceitos do grupo constituinte de Registradores, que não têm mais o apoio da comunidade. Será que a Força-Tarefa não deveria conceder mais tempo para explorar alternativas?" R. Como explicamos na seção Resumo e Comentários, o grupo constituinte de Registradores é apenas um dos envolvidos neste processo. Além disso, a Força-Tarefa dedicou mais de um ano para consultar a comunidade e explorar todas as alternativas possíveis. Como não podemos avaliar propostas que não recebemos, acreditamos que o momento para implementar mudanças que têm o apoio geral da comunidade é agora, e julgamos que essas recomendações são um reflexo do apoio e do consenso da comunidade.
18. "Será que a implementação dessas mudanças não exige uma alteração significativa dos contratos existentes? Devem as partes afetadas ter uma oportunidade para alterar ou negociar essas disposições antes de serem incluídas num contrato?" R. Em geral, políticas novas ou reformuladas exigem a alteração dos contratos correspondentes. A Força-Tarefa não tem a experiência legal, ou a autoridade para determinar se a implementação ou não dessas recomendações políticas exigiria "alterações significativas" nos contratos existentes, nem mesmo quais contratos deveriam ser alteradas para que se atinjam esses objetivos. Tivemos a orientação do Conselheiro Geral e da equipe da ICANN para algumas das áreas em que a política de consenso poderia exigir alterações contratuais ou no Contrato de Credenciamento de Registradores. Contudo, mais uma vez, a Força-Tarefa acredita que não deveria se envolver em análises legais na medida sugerida por essa pergunta. Quanto à dúvida se as partes afetadas (contratadas) devem ou não ter a oportunidade de alterar ou modificar essas disposições antes de incluí-las nos contratos, a Força-Tarefa observa que essas recomendações são a posição de consenso da comunidade, e portanto devem ser implementadas da forma em que foram escritas, com exceção de detalhes de implementação específicos, os quais devem ser deixados para que a equipe da ICANN e as partes dos contratos os considerem, documentem e implementem. A Força-Tarefa também acredita que se ocorrerem mudanças significativas nas recomendações políticas de consenso durante a implementação, essas mudanças deve ser revistas com o Conselho de Nomes/seu sucessor. Caso contrário, as partes afetadas que são usuários não serão levadas em conta nessas mudanças importantes, nem terão uma oportunidade para comentá-las. Da maneira como foi apresentada, a pergunta parece considerar que apenas registradores ou registros podem ser "partes afetadas". O processo de consenso da DNSO e seu sucessor exige que se levem em conta as sugestões e preocupações de uma grande variedade de envolvidos.
19. "Será que a implementação dessas mudanças não exigiria que registros e registradores realizem mudanças significativas em seus sistemas e portanto incorram em custos pesados, que no final das contas os registrantes teriam de cobrir?" R. A resposta para essa pergunta depende da definição de "significativo". Como custo e impacto são considerações relativas, não existe uma resposta única para essa questão. As respostas dependem do tamanho e da capacidade de cada registrador ou registro específico e do processo que ele utiliza no momento. A Força-Tarefa acredita que: · Os custos técnicos e econômicos que podem resultar das implicações dessas recomendações não serão insignificantes. · Qualquer implementação dessas recomendações não criará nenhum ônus excessivo ou indevido para nenhuma das partes afetadas. Além disso, a Força-Tarefa reconhece que registrantes, registradores e registros, todos serão afetados por essas recomendações, mas que a longo prazo elas terão um caráter essencialmente social e serão compensadas pelos efeitos econômicos resultantes de políticas, estáveis, estáveis, transparentes e seguras, que incentivarão a confiança de registrantes, registradores e registros.
Broitman, Elana. "Transferências [de registradores] para registradores." Publicação on-line. 29 de junho de 2001. Lista de correio do grupo constituinte de Registradores. 27 de novembro de 2002 <http://gnso.icann.org/clubpublic/Registrars/Arc01/msg00776.html> Cochetti, Roger. "Carta de Roger Cochetti para Stuart Lynn." ICANN. 16 de julho de 2001. Verisign, Inc. 27 de novembro de 2002. <http://www.icann.org/correspondence/cochetti-to-lynn-16jul01.htm> Rader, Ross. "Descrição e panorama geral do processo de transferência de nomes de domínio entre registradores." Proposta para transferências padronizadas de domínios entre registradores. 26 de agosto de 2001. Tucows Inc. 27 de novembro de 2002. <http://www.byte.org/rc-transfers/> Broitman, Elana e Ross Wm. Rader. "Transferências de nomes de domínio entre registradores; Princípios e processos para registradores vencedores e perdedores." ICANN-Registradores. 1 de outubro de 2001. Grupo Constituinte de Registradores da DNSO, ICANN. 27 de novembro de 2002. <http://www.icann-Registrars.org/pdfs/rc-irdx-091801-v1r0d8.PDF> Gomes, Chuck e Elliot Noss. "Autorização mediada". Arquivos da lista de correio do Grupo Constituinte de Registradores da DNSO. 6 de novembro de 2002. Verisign, Inc. & Tucows Inc. 27 de novembro de 2002 <http://gnso.icann.org/clubpublic/Registrars/Arc01/doc00128.doc > Gomes, Chuck et al. "[Registradores] Fw: Princípios." Publicação on-line. 27 de novembro de 2002. Lista de correio do Grupo Constituinte de Registradores. 27 de novembro de 2002 <http://gnso.icann.org/clubpublic/Registrars/Arc01/msg03652.html> Exposições Exposição A: Requerimento de referência Exposição B: Modelo proposto para resolução de disputas Exposição C: Definições padronizadas Exposição D: Relatório da Força-Tarefa para Implementação de Transferências Exposição E: Observações finais Comentários sobre o layout,
estrutura e funcionalidade deste site Página atualizada em 1 de março
de 2003 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
