|
|
Criação de novos sTLDs: (Esboço para comentário público) |
||
Criação de novos sTLDs: Solicitação de propostas Histórico e panorama geral ICANN está publicando esta Solicitação de Propostas (RFP) com o objetivo de solicitar requerimentos para um número limitado de novos Domínios de Alto Nível Patrocinados (sTLDs). Esta publicação atende uma diretiva do Conselho de Diretores da ICANN para a equipe da ICANN, definida durante a reunião em Amsterdã em 15 de dezembro de 2002, depois de o Presidente em exercício na época, Stuart Lynn, ter apresentado um Plano de Ação para novos TLDs em geral. O Plano de Ação em si atendia a uma solicitação da Diretoria da ICANN definida em sua reunião de 23 de agosto de 2002. Esse Plano de Ação propunha que ICANN poderia continuar com a implementação de um número limitado de novos TLDs patrocinados (o Plano sugeria três, mas os comentários da comunidade propunham que não se estabelecesse um número fixo) antes de concluir uma avaliação completa do Teste de Conceito iniciado no segundo semestre de 2000. Este Teste de Conceito, iniciado após uma solicitação aberta de propostas para criação de novos TLDs, finalmente conduziu à criação de quatro novos TLDs não-patrocinados (.info, .biz, .name e .pro) e três TLDs patrocinados (.museum, .aero e .coop). O Plano de Ação declarava - e a Diretoria aceitou os pontos de vista expressados - que os problemas não-resolvidos, inerentes ao lançamento de novos TLDs não-patrocinados (uTLDs), antes da avaliação e uma análise completa de como proceder no futuro, eram grandes demais para se coadunarem neste momento com a solicitação de requerimentos para novos uTLs. Por outro lado, o Plano de Ação defendia o ponto de vista de que seria muito menos arriscado continuar com a implementação de um número limitado de novos sTLDs como uma extensão do Teste de Conceito original do segundo semestre de 2002. Esta RFP segue a decisão preliminar da Diretoria (sujeita à aprovação da própria RFP) para que se prossiga com uma solicitação de requerimentos para um número limitado de novos sTLDs como extensão do Teste de Conceito. No entanto, num aperfeiçoamento da redação do Plano de Ação, a Diretoria propõe que os requerimentos sejam limitados àqueles candidatos (ou afiliados, ou sucessores, conforme define esta RFP a seguir) que enviaram requerimentos para TLDs patrocinados durante a rodada original de requerimentos no segundo semestre de 2000, mas que não foram aprovados naquela época. Esta RFP reflete o ponto de vista da Diretoria sobre este aspecto, e portanto limita o escopo dos candidatos possíveis. Em consulta ao Presidente da ICANN, Paul Twomey, a Diretoria também está avaliando a possibilidade da ICANN iniciar um amplo estudo sobre se e como deve continuar com a criação de TLDs adicionais, ao mesmo tempo em que analisa a criação de novos sTLDs por este processo da RFP, e conclui a avaliação do Teste de Conceito original. O resultado deste estudo pode ou não justificar o crescimento contínuo de TLDs adicionais e pode ou não manter o conceito de sTLDs e uTLDs. Até que esta análise mais profunda esteja pronta, a Diretoria considera que não convém comprometer-se com uma expansão significativa dos sTLDs. Entretanto, a Diretoria acredita que deve haver uma oportunidade para permitir que aqueles que enviaram requerimentos para sTLDs no segundo semestre de 2000, e cujos requerimentos não foram atendidos, tenham uma oportunidade de enviar requerimentos atualizados e revisados neste momento, como uma extensão do Teste de Conceito original. Pelos motivos apresentados no Plano de Ação, essa oportunidade não se estende aos candidatos a uTLDs. Esta RFP e os documentos relacionados no Apêndice D seguem basicamente o mesmo processo que acompanhou a rodada original de candidaturas em 2000. Contudo, ela foi atualizada com base na experiência obtida na rodada original. Mais especificamente:
Particularmente em vista dos aperfeiçoamentos desta RFP, os requerimentos originais enviados no segundo semestre de 2000 não atenderiam os requisitos e critérios de seleção para a criação de um novo sTLD de acordo com os padrões exigidos para requerimentos enviados de acordo com esta RFP. Somente requerimentos novos com informações revistas e atualizadas, em conformidade com as exigências desta RFP serão analisados seriamente. Entretanto, espera-se que grande parte do material enviado com os requerimentos anteriores seja útil como ponto de partida para o novo requerimento. Os novos requerimentos, porém, concedem aos candidatos a oportunidade de melhorar seus requerimentos originais. Esta RFP oferece uma visão geral do que é necessário para se candidatar para um novo sTLD. Os documentos relacionados no Apêndice D, porém, apresentam os detalhes do que é necessário para cada candidatura. Os candidatos qualificados estão convidados a ler e analisar todos estes materiais cuidadosamente para ajudá-os a decidir se desejam enviar novos requerimentos. O cronograma provisório relacionado no Programa Planejado para Avaliação e Decisão prevê que a Diretoria tomará sua decisão quanto à seleção de candidatos para novos sTLDs bem-sucedidos conforme determina aquele cronograma. Este cronograma, porém, pode mudar dependendo das circunstâncias. Os candidatos em potencial e efetivos devem acompanhar atentamente o site de ICANN para verificar se há mudanças no cronograma ou no processo. Elegibilidade e restrições Esta RFP está aberta somente para aquelas entidades relacionadas no Apêndice B, ou para os afiliados ou sucessores dessas entidades (conforme definição a seguir), que enviaram seus requerimentos a ICANN como patrocinadores de um novo sTLD no segundo semestre de 2000. Os afiliados ou sucessores das entidades relacionadas no Apêndice B são organizações autorizadas no Formulário de Requerimento de Novos sTLDs para agir em nome do candidato original no envio do requerimento, desde que seja no(s) mesmo(s) nome(s) e para essencialmente o mesmo fim definido no requerimento original. Os afiliados e sucessores deverão fornecer detalhes sobre seu relacionamento com o candidato original no Formulário de Requerimento de TLDs Patrocinados e comprovar sua autorização pelo candidato original. Outras questões importantes para a decisão quanto à candidatura As exigências para patrocinar ou operar um novo sTLD são muito rigorosas. Apenas candidaturas com qualificações extremamente elevadas serão aceitas nesta rodada de requerimentos, ou seja, apenas aquelas que atendem ou superam os requisitos e atingirem uma pontuação elevada nos critérios de seleção especificados no documento Metodologia de avaliação e critérios de seleção. ICANN reserva-se o direito de não selecionar qualquer candidato para futuras negociações se este de fato não cumprir os requisitos especificados. Todos os requerimentos aprovados continuarão dependendo da assinatura de um contrato final pelo candidato, conforme o Contrato Modelo anexado como Apêndice A, juntamente com todos os apêndices aplicáveis àquele Contrato. Este Contrato Modelo basicamente se assemelha aos acordos assinados em 2001 entre ICANN e as Organizações Patrocinadoras para os requerimentos de sTLDs aprovados em novembro de 2002. As organizações que acreditam que não podem ou que não irão aceitar os termos do Contrato Modelo não devem enviar requerimentos, pois o contrato não será re-negociado. A taxa não-reembolsável a ser paga a ICANN por todo requerimento de sTLD que será submetido à avaliação é de US$25.000. Este valor é um acréscimo à taxa de US$50.000 que acompanhava as propostas iniciais em 2000. Em razão das condições alteradas e dos aperfeiçoamentos nos materiais para candidaturas, os requerimentos enviados na primeira rodada em 2000 não satisfarão as exigências desta RFP. Portanto, os candidatos também devem contar com o fato de investir recursos extras na preparação de seus novos requerimentos. Esta RFP está aberta a todas as entidades (ou aos seus afiliados ou sucessores indicados e autorizados) que enviaram um requerimento para um TLD patrocinado em 2000, mas que não foram selecionados naquela rodada de requerimentos. Contudo, o envio do requerimento naquela época não garante que a estrutura de Organização Patrocinadora proposta pelo candidato naquela época o qualifica como tendo cumprido as exigências para uma Organização Patrocinadora definidas nesta RFP. Na verdade, vários requerimentos não foram aceitos naquela época justamente por não atenderem os requisitos para uma Organização Patrocinadora. Insistimos para que os candidatos em potencial que responderem a esta RFP revejam cuidadosamente as exigências para um TLD patrocinado e para uma Organização Patrocinadora (ver a Definição de Termos-Chave abaixo) para garantir que sua candidatura atende a esses requisitos. Um requerimento que não cumprir as exigências para uma Organização Patrocinadora será rejeitado e não será mais analisado. ICANN recomenda que, antes de decidir se irá se candidatar, cada interessado siga as seguintes etapas:
Os candidatos também devem estar cientes de que a aceitação de sua proposta por ICANN e a assinatura de um contrato com a Corporação não garantem que o novo TLD entrará imediatamente em funcionamento pela Internet. A experiência passada indicou que os ISPs e webhosters não concedem automaticamente a passagem ou o acesso a novas seqüências de TLDs, mesmo quando essas seqüências são autorizadas por ICANN, já que podem ser necessárias modificações de software que não são efetuadas até que haja um motivo comercial para fazê-lo. Do mesmo modo, muitas vezes os aplicativos da rede validam seqüências de nomes na entrada de dados e podem filtrar seqüências novas ou desconhecidas. ICANN não tem a autoridade nem a capacidade de exigir a aceitação de novas seqüências de nomes de TLDs, embora publique seqüências de TLDs autorizadas por ICANN em seu site. Portanto, os candidatos aprovados poderão ser obrigados a despender esforços consideráveis após a implementação para persuadir os provedores da necessidade de aceitar sua nova seqüência de nomes de TLDs. Recentemente, o Grupo Constituinte de Registros de gTLDs da ICANN publicou uma declaração sobre este assunto (ver Apêndice E). Definição de termos-chave Como esta RFP se destina unicamente a propostas de criação de sTLDs, o entendimento da definição e do propósito de um sTLD é essencial para a elaboração de requerimentos bem-sucedidos. Particularmente, os termos Organização Patrocinadora (a organização que patrocina o sTLD), também denominada "Patrocinador" e Operador de Registro (a organização que opera o registro de sTLD) também exigem uma definição e entendimento claros. TLD Patrocinado (sTLD) e Organização Patrocinadora Um uTLD, ao contrário de um sTLD, em geral opera de acordo com normas estabelecidas pela comunidade global da Internet diretamente por meio do processo da ICANN. Um sTLD, porém, é um TLD especializado que possui uma Organização Patrocinadora representando uma comunidade mais restrita, mas bem definida, que é a mais afetada pelas políticas que regem a operação do sTLD. Assim, ICANN atribui ao Patrocinador a responsabilidade de formular diretrizes sobre diversos assuntos referentes ao TLD. Uma Organização Patrocinadora é uma organização à qual ICANN delega algum nível definido de responsabilidade para formular políticas e autoridade sobre a forma de operação de um determinado TLD. Um TLD patrocinado tem uma Pauta a ser observada pela Organização Patrocinadora, e esta Pauta define a finalidade para a qual o TLD foi criado e para a qual ele será operado. A Organização Patrocinadora é responsável por desenvolver diretrizes sobre os tópicos que lhe foram delegados, de modo que o TLD funcione em benefício de um grupo definido, conhecido como a Comunidade do TLD Patrocinado, que são as pessoas ou entidades mais diretamente interessadas na operação do TLD. O Patrocinador também é responsável por selecionar o Operador de Registro (ver abaixo) e por definir as funções desempenhadas pelos registradores e seu relacionamento com o Operador de Registro. Em suas atividades de elaboração e manutenção de políticas, ICANN é responsável perante a comunidade mais ampla da Internet e os interesses públicos. Como um Patrocinador de um sTLD exerce a autoridade que lhe foi delegada por ICANN, ao exercer suas atividades normativas e de manutenção, a Organização Patrocinadora, por sua vez, deve ser estruturada de tal forma que ela preste contas primariamente à Comunidade do TLD Patrocinado e aos interesses do público de modo geral. O Patrocinador deverá exercer sua autoridade delegada de acordo com padrões de eqüidade, representando a Comunidade do TLD Patrocinado. Ao exercer esta função, a Organização Patrocinadora não será responsável nem prestará contas primariamente a um grupo de indivíduos, como por exemplo os acionistas de uma corporação, ou a qualquer outro grupo com interesses particulares. Repetindo: os beneficiários primários das atividades de elaboração, implementação e manutenção de políticas da Organização Patrocinadora serão a Comunidade do TLD Patrocinado e o interesse público como um todo; atender a esses interesses objetivamente é primordial. Além disso, a Organização Patrocinadora manterá este modo de operação representativa de modo contínuo, não apenas durante o período inicial. Os requerimentos serão verificados cuidadosamente para garantir que todas essas condições sejam cumpridas. Até que ponto as responsabilidades pela formulação de políticas são delegadas adequadamente a um Patrocinador depende das características da organização. Essas características podem incluir: os mecanismos que o Patrocinador usa para formular políticas; sua missão ou propósito; suas garantias de independência do Operador de Registro e dos registradores; a proporção em que o Operador de Registro e os registradores participarão dos esforços normativos do Patrocinador; e o nível e tipo de responsabilidade do Patrocinador em relação à Comunidade do TLD Patrocinado. Um sTLD deve apresentar as seguintes características, entre outras: (a) as registrações se limitarão a registrantes de uma comunidade bem definida e limitada, incluindo membros de uma Organização Patrocinadora (se de fato a Organização Patrocinadora for uma organização de membros); (b) o escopo da atividade e os limites de registrações devem ser circunscritos por uma pauta bem definida; (c) em um ambiente normativo hierárquico, a pauta deve definir claramente quais são as responsabilidades normativas delegadas ao Patrocinador por ICANN; (d) deve haver estruturas abertas e transparentes que proporcionem uma elaboração ordenada de diretrizes, que permitam que os membros e registrantes interfiram no processo de elaboração e implementação de normas, e que possibilitem que a Organização Patrocinadora seja receptiva a essa influência; e (e) o Patrocinador deve comprometer-se a cumprir as políticas da ICANN, mesmo que eventualmente estas se modifiquem ao longo de processos de consenso. Operador de Registro: O Operador de Registro é uma entidade responsável pela operação efetiva do registro para um TLD, o que inclui receber pedidos de registração (seja de registradores ou diretamente dos registrantes), manter uma base de dados com os dados de registro necessários, gerar arquivos de zona e providenciar servidores de nomes para publicar os dados de arquivos de zona na Internet. Embora esses serviços possam ser terceirizados, o Operador de Registro é o responsável geral por garantir que os serviços sejam oferecidos de maneira confiável. A Organização Patrocinadora é responsável por selecionar o Operador de Registro para um sTLD. Uma mesma organização pode ser uma Organização Patrocinadora e um Operador de Registro de um sTLD, contanto que ela possua as características descritas acima que a qualifiquem para as duas funções. Se um Operador de Registro não tiver os requisitos necessários para uma Organização Patrocinadora, esta deverá ter uma estrutura independente do Operador de Registro. Processo de requerimento para um novo sTLD Esta seção descreve o que é necessário para que um requerimento para um novo STLD seja submetido à avaliação da ICANN. Todos os requerimentos apresentados deverão cumprir os requisito de qualificação descritos acima. Material confidencial em requerimentos Todos os requerimentos e a documentação de apoio serão publicados no site da ICANN e portanto não deverão conter nenhum material confidencial. A taxa de requerimento não-restituível Todos os requerimentos deverão ser acompanhados do pagamento de US$25.000 no momento da apresentação inicial. Requerimentos enviados sem o pagamento integral da taxa de requerimento não serão considerados. Essa taxa não será restituída em hipótese alguma. É possível fazer o pagamento (a) por cheque certificado, emitido por um banco dos Estados Unidos e pagável à Internet Corporation for Assigned Names and Numbers ou (b) por transferência eletrônica, de acordo com as instruções incluídas no Formulário para Requerimento de TLDs Patrocinados. Não existe absolutamente nenhuma garantia de que um requerimento será aprovado ou, caso seja aprovado, que ICANN firmará um contrato, ou que a criação de um sTLD se concretizará. Na verdade, é possível que ICANN decida não aprovar nenhum dos requerimentos enviados nem criar algum novo sTLD. Proposta de sTLDs múltiplos Um único requerimento poderá propor até três seqüências de sTLD, organizados em ordem de preferência, desde que essas seqüências tenham sido apresentadas no requerimento original no segundo semestre de 2000. Caso um requerimento proponha duas ou três seqüências de sTLDs, (a) todas as partes do requerimento devem se aplicar a cada seqüência, sem grandes variações e (b) se ICANN determinar, exclusivamente a seu critério, que uma ou mais partes se aplicam a diferentes seqüências de sTLD de maneira muito diferente, ela poderá solicitar que o candidato escolha quais seqüências estão sendo solicitadas naquele requerimento. Conteúdo dos requerimentos Cada requerimento deve conter um Formulário de requerimento para novo sTLD; uma Proposta de Organização Patrocinadora para um novo sTLD (ver Requisitos para propostas de Organizações Patrocinadoras para novos sTLDs); uma Proposta de Operador de Registro (caso se selecione a Opção B: veja Requisitos para propostas de Operadores de Registro de novos sTLDs); o Formulário de Divulgação das Qualificações da Organização Patrocinadora; o Formulário de Divulgação das Qualificações do Operador de Registro, e a Taxa de Requerimento. Esses itens serão indicados a seguir, mas o candidato deverá analisar a descrição detalhada dos documentos exigidos (relacionados no Apêndice D) para compreender corretamente o que é necessário. Recomendamos que os candidatos sejam tão meticulosos quanto possível, já que os documentos apresentados formarão a base para avaliação da proposta como um todo. Os documentos necessários são os seguintes (veja o Apêndice D para ver os links aos documentos que descrevem com mais detalhes o que é necessário): Formulário de Requerimento para TLDs Patrocinados: Cada candidato deverá preencher e enviar o Formulário de Requerimento para sTLDs. Proposta de Organização Patrocinadora de novos sTLDs: Cada candidato deverá enviar uma proposta completa de acordo com a descrição no documento Requisitos para propostas de Organizações Patrocinadoras de novos sTLDs. A proposta contém descrições: · do sTLD proposto; · da Organização Patrocinadora proposta, incluindo a extensão de sua autoridade normativa, seu processo normativo proposto, e uma indicação do grau de apoio da comunidade do TLD Patrocinado proposto; · de como o novo sTLD agregaria valor ao DNS; · de como o sTLD proposto atingiria e beneficiaria comunidades globais mais amplas; · de como a Organização Patrocinadora implementaria políticas e processos para proteger os direitos de terceiros; e · de como a Organização Patrocinadora e seu Operador de Registro selecionado iriam assegurar a operação estável do registro, incluindo providências para assegurar a continuidade do serviço em caso de falência comercial. Cada Proposta de Organização Patrocinadora para um novo sTLD deverá incluir como anexo uma Carta de Compromisso ou um contrato de serviços de registro do Operador de Registro Proposto. As exigências para a Carta de Compromisso serão indicadas a seguir na descrição da Proposta do Operador de Registro. Recomendamos que os candidatos examinem cuidadosamente a seção abaixo, que descreve como as propostas serão avaliadas, e o documento "Metodologia de avaliação e critérios de seleção". Existe uma estreita correlação entre os critérios de avaliação e as informações contidas na Proposta de Organização Patrocinadora para um novo sTLD. Proposta de Operador de Registro: Existem duas opções: Opção A: O candidato (Organização Patrocinadora) poderá usar essa opção quando ele propuser firmar um contrato para serviços de operação de registro com um Operador de Registro que já possui um contrato com ICANN para a operação de um ou mais gTLDs não-patrocinados (e portanto já satisfez anteriormente todas as exigências referentes ao material fornecido em uma Proposta de Operador de Registro), contanto que: (a) o Operador de Registro proposto satisfaça todos os termos de seu contrato com ICANN existente para o fornecimento de serviços de registro e (b) o próprio Operador de Registro proposto já esteja fornecendo os serviços de registro estabelecidos em seu contrato com ICANN, sem ter terceirizado essas operações a outra parte. Os Operadores de Registro qualificados estão relacionados no Apêndice C. Opção B: Um candidato usará esta opção se seu propósito é firmar um contrato com um Operador de Registro que não está relacionado no Apêndice C. O Formulário de Requerimento de Novo sTLD indica a opção escolhida pelo candidato. Somente os candidatos que escolheram a opção B deverão completar uma Proposta de Operador de Registro. O candidato que escolher a opção A não precisa completar uma Proposta de Operador de Registro. As instruções para completar uma Proposta de Operador de Registro estão detalhadas no documento Exigências para a Proposta de Operador de Registro para novos sTLDs. Todos os candidatos (tanto os que escolheram a opção A quanto os que escolheram a opção B) deverão enviar uma Carta de Compromisso assinada (ou um contrato assinado de serviços de registro) do Operador de Registro proposto, anexada à Proposta da Organização Patrocinadora para novos sTLDs. A Carta de Compromisso deverá indicar, no mínimo, (a) a disposição do Operador de Registro proposto para firmar um contrato de serviços adequado com a Organização Patrocinadora, se esta tiver sucesso em seu requerimento e na negociação de um contrato com ICANN; (b) os termos e condições gerais desse contrato, incluindo sua duração, isto é, uma tabela de condições; (c) um entendimento de que em caso de falência comercial da Organização Patrocinadora, os direitos do patrocinador deverão ser transferíveis a ICANN ou à entidade por ela designada, a pedido da ICANN, por um período de no mínimo um ano; (d) as obrigações de desempenho do Operador de Registro; e (e) disposições sobre procedimentos em caso de mudanças do Operador de Registro, não-desempenho e rescisão. Formulário de divulgação da qualificação da Organização Patrocinadora: Cada requerimento deverá incluir um Formulário de divulgação da qualificação da Organização Patrocinadora. Formulário de divulgação da qualificação do Operador de Registro: Cada requerimento deverá incluir um Formulário de divulgação da qualificação do Operador de Registro, preenchido pelo Operador de Registro proposto. Formato dos materiais apresentados Todos os documentos relacionados no Apêndice D deverão ser enviados em formato eletrônico e em formato impresso, de acordo com os formatos especificados em cada documento e reiterados no Formulário de Requerimento. Todo material será em inglês (receberemos cópias em outros idiomas para fins de publicação, mas só avaliaremos a versão em inglês). Todo documento enviado em formato eletrônico deverá estar em arquivo
Adobe pdf (Portable Document Format). Cada documento relacionado no
Apêndice
D deverá ser enviado como arquivo pdf separado. O nome do arquivo
deverá indicar o nome do candidato e um nome abreviado do documento
(ver Apêndice D), como por exemplo: abc_sTLD_Transmittal.pdf. Favor seguir cuidadosamente essas instruções e todas as outras instruções específicas contidas nos documentos citados no Apêndice D. Para onde e quando enviar o requerimento completo ICANN aceitará requerimentos completos para novos registros de sTLDs no máximo até [data a ser anunciada posteriormente no site da ICANN]. Esta data é o prazo final para o recebimento de requerimentos, tanto em formato eletrônico quanto impresso, e ICANN não considerará requerimentos recebidos após essa data. A versão impressa do requerimento não será recebida após essa data final absoluta no endereço: ICANN A versão eletrônica do requerimento (contendo arquivos pdf; veja o item Formato do material enviado, acima) será enviada até essa data final absoluta para: e enviada em um CD-ROM acompanhando a versão impressa. Logo depois de receber o seu requerimento completo, ICANN enviará um e-mail para o endereço relacionado no item C18 do seu Formulário de requerimento de novos sTLDs. Os requerimentos deverão fornecer todas as informações solicitadas nesta RFP e nos documentos correspondentes relacionados no Apêndice D, obedecendo também os formatos determinados. Os candidatos deverão assegurar que seus requerimentos cumprem essas exigências; o não-cumprimento poderá pôr em risco a análise do requerimento por ICANN para avaliação e futuro processamento, resultando na rejeição sumária do requerimento. Como serão avaliados os requerimentos Os requerimentos serão avaliados de acordo com a metodologia e os critérios definidos em "Metodologia de avaliação e critérios de seleção". Recomendamos que os candidatos leiam esse documento com muita atenção, pois o entendimento desse documento é essencial para preencher um requerimento bem-sucedido. É intenção da ICANN contratar os serviços de um ou mais consultores externos para realizar uma avaliação objetiva e independente dos requerimentos quanto às exigências especificadas na RFP e segundo os critérios de seleção e a metodologia de avaliação descritos neste documento. A equipe da ICANN poderá preparar relatórios para publicação ou para a Diretoria, resumindo as conclusões do consultor ou consultores, especialmente se mais de um consultor for funcionário ou se houver outras questões pertinentes ou jurídicas que precisarão ser levadas em conta pela Diretoria. Ainda que não seja a equipe da ICANN que fará a parte principal da avaliação, a sua equipe poderá ajudar a compilar, sintetizar ou tabular informações para análise pela Diretoria. O papel da Diretoria da ICANN será aceitar ou rejeitar as avaliações resultantes. A Diretoria em si não fará avaliações. Se a Diretoria determinar que o processo de avaliação realizado é insuficiente, ela poderá decidir se contratará o(s) mesmo(s) ou outro(s) consultor(es) para uma outra análise. Os candidatos deverão compreender e levar em conta o risco de que todos os requerimentos podem ser considerados deficientes e rejeitados. Cronograma planejado para avaliação e decisão ICANN pretende empregar todos os seus esforços para cumprir o seguinte cronograma. A experiência passada, contudo, indica que por motivos imprevisíveis nem sempre é possível cumprir o cronograma original. Portanto, os candidatos ou candidatos em potencial devem acompanhar atentamente o site da ICANN para verificar se existem alterações neste cronograma proposto.
A divulgação desta RFP marcará o início do período de requerimento citado em outros trechos desta RFP, e este período se encerrará com o prazo final para o recebimento de requerimentos. Obtenção de informações adicionais Durante o período de requerimento, as perguntas sobre o processo de requerimento de novos TLDs poderão ser enviadas para <stld-applications@icann.org>. Para ajudar todos os candidatos a terem acesso eqüitativo às informações sobre o processo enquanto preparam seus requerimentos, até o Prazo Final para os Requerimentos todos os pedidos de informações sobre o processo ou problemas que surgirem durante a preparação de um requerimento deverão ser enviados a ICANN por e-mail para <stld-applications@icann.org>. Pedidos para consultas pessoais ou por telefone não serão atendidos. De modo geral, ICANN publicará em seu site todas as respostas a perguntas importantes enviadas durante o período de requerimento. Aqueles que enviarem perguntas deverão levar em conta esse fato ao formularem suas dúvidas. Após o final do período de requerimento, todos os requerimentos completos recebidos serão avaliados. Este processo envolverá não apenas a análise do que foi enviado, mas também consultas a especialistas externos e a obtenção de informações adicionais que poderão ser pertinentes ao requerimento. Se necessário, após o final do período de requerimento, a equipe da ICANN poderá obter outras informações ao enviar e-mails aos candidatos solicitando a informação necessária, realizando entrevistas por telefone ou ao vivo com os candidatos, recebendo os representantes dos candidatos ou seus especialistas (possivelmente com especialistas contratados por ICANN), ou de outras maneiras. A equipe da ICANN tomará a iniciativa para essas consultas; se o candidato julgar necessária uma apresentação para ICANN para descrever adequadamente sua proposta, deverá incluir essa sugestão em seu requerimento por escrito. Todo material apresentado em relação aos requerimentos estará sujeito a publicação no site da ICANN; portanto, tendo em vista os aspectos de privacidade, observe a redação de qualquer dado com identificação pessoal nos documentos apresentados (p. ex., informações de contatos nos currículos). ICANN antecipa que solicitará comentários de vários grupos e do público em geral sobre as propostas recebidas. Quaisquer outras dúvidas sobre esta RFP após o período de requerimento deverão ser endereçadas para general-counsel@icann.org (perguntas orais não serão aceitas). Enviar perguntas ou tentar conversar com membros da equipe ou do Conselho de Diretores da ICANN (exceto consultas jurídicas ou com os consultores no período entre a publicação dessa RFP e a decisão final da Diretoria) pode constituir motivo para a rejeição sumária do requerimento (ver o item "Comunicações abertas e transparentes" abaixo). Comunicações abertas e transparentes Coerentemente com sua Missão e Valores Fundamentais, ICANN opera de maneira aberta e transparente. Isso tem implicações sobre a aceitação de requerimentos segundo esta RFP, sobre o tratamento desses requerimentos e sobre todas as comunicações entre a equipe e os que apóiam o candidato, por um lado e, por outro lado, os membros do Conselho de Diretores e da equipe da ICANN, seus contratos ou sua assessoria jurídica externa. Todos os documentos recebidos por um diretor, funcionário ou contratado da ICANN após a data final para requerimento, que não se limitem ao requerimento em si, serão publicados no site da ICANN. Assim, os candidatos não deverão enviar nenhum material confidencial como parte do requerimento. Comunicações orais diretas com qualquer diretor, funcionário ou contratado da ICANN serão consideradas inadequadas e poderão constituir motivo para desqualificar o requerimento, a menos que tenham sido previamente aprovadas por ICANN como parte do processo de requerimento. Apêndices B. Lista de candidatos de TLDs patrocinados em 2000 C. Lista de operadores de registro elegíveis para a Opção A, segundo a descrição das exigências para a proposta do operador de registro D. Documentos exigidos para preencher um requerimento Para formar uma proposta completa, exigem-se os seguintes documentos, exceto em caso de indicação em contrário: a. Formulário de Requerimento de TLDs Patrocinados (ver Requisitos para o formulário de requerimento de novos sTLDs). Nome do arquivo eletrônico (pdf): abc_stld_transmit.pdf, onde abc é o nome do candidato. b. Proposta da Organização Patrocinadora de um novo sTLD (ver Requisitos para a proposta de uma Organização Patrocinadora de um novo sTLD). O candidato deverá anexar uma Carta de Compromisso assinada ou um contrato de serviços de registro do Operador de Registro Proposto. Nome do arquivo eletrônico (pdf): abc_sTLD_spons_prop.pdf. c. Somente opção B: Proposta do Operador de Registro (ver Requisitos para a proposta do Operador de Registro). Nome do arquivo eletrônico (pdf): abc_reg_prop.pdf. d. Formulário de divulgação das qualificações da Organização Patrocinadora (ver "Requisitos para o formulário de divulgação das qualificações da Organização Patrocinadora"). Nome do arquivo eletrônico (pdf): abc_spons_fitness.pdf. e. Formulário de divulgação das qualificações do Operador de Registro (ver "Requisitos para o formulário de divulgação das qualificações do Operador de Registro"). Nome do arquivo eletrônico (pdf): abc_reg_fitness .pdf. Além disso, recomendamos veementemente que todos os candidatos analisem e compreendam o documento Metodologia de avaliação e critérios de seleção, visto que ele determinará como os documentos acima serão avaliados; e também que examinem o Contrato Modelo, pois mais tarde os candidatos aprovados deverão assinar este tipo de Contrato. E. Declaração do Grupo Constituinte de Registros de gTLDs O Grupo Constituinte de Registros de gTLDs publicou a seguinte declaração: FILTRAGEM DE NOVOS DOMÍNIOS DE ALTO NÍVEL PELOS ISPs Desde que se introduziram novos domínios de alto nível (DNS) pela primeira vez, os domínios de alto nível (tanto os gTLDs quanto os ccTLDs) apresentam predominantemente dois ou três caracteres. Embora inicialmente tenha-se criado um TLD de quatro letras (.arpa), esse domínio não esteve disponível para o público geral. Antes de novembro de 2000, a lista de TLDs válidos mudou muito pouco, e apenas alguns poucos ccTLDs foram acrescentados à lista, incluindo a Palestina (.ps) e Afeganistão (.af). FILTRAGEM DE NOVOS DOMÍNIOS DE ALTO NÍVEL Em novembro de 2000, contudo, ICANN aprovou sete novos TLDs e em seguida os acrescentou à raiz. Entre eles havia vários TLDs com 4 ou mais caracteres (.aero, .coop, .info, .name e .museum). Embora a implementação desses novos TLDs tenha começado em 2001, houve barreiras consideráveis à sua aceitação pela maioria dos ISPs em todo mundo. Mesmo alguns dos novos TLDs de três letras, como .biz, enfrentaram algumas dificuldades de aceitação por muitos dos principais ISPs do mundo. Alguns ISPs estão usando listas de nomes de domínio incompletas para filtrar endereços de e-mail e URL[1] <outbind://39/#_ftn1> e é óbvio que seus sistemas que filtram nomes de domínio de alto nível não verificam nem atualizam a atual lista de validação de TLDs ("genéricos" e relativos a códigos de países) publicada por IANA em http://www.iana.org/domain-names.htm. Isso é grave, porque quando se usa uma lista incompleta, os novos TLDs não serão reconhecidos como domínios válidos, e o sistema poderá tentar chegar a eles por meio de domínios diferentes. Por exemplo, "entity.xxxx" é um nome válido porque pertence à lista de IANA, porém se o ISP não reconhecer "xxxx." como um TLD válido, irá transformá-lo em "entity.xxxx.com" e http://www.entity.xxxx.com" (e então falhará ou encontrará o host errado). PLANOS da ICANN De acordo com vários relatórios recentes, ICANN pretende expandir a lista de novos gTLDs. Essa expansão pode ocorrer em intervalos regulares. Portanto, é essencial que ICANN e seus componentes, particularmente os ISPs, estejam cientes de que este problema existe e que conseqüentemente os novos gTLDs não podem funcionar adequadamente. Os novos operadores de registro em potencial devem estar conscientes de que essa barreira existe e ICANN deve avaliar a coordenação dessas questões mais de perto. A aceitação global de todos os nomes de domínio válidos é parte integral da estabilidade da Internet. CONCLUSÃO É importante observar: . Novos TLDs, acrescentados à lista de TLDs em novembro de 2000, ainda não foram globalmente aceitos por ISPs, web hosts e sites de comércio eletrônico. . Técnicas de segurança, que foram criadas para proteger o sistema do DNS, estão criando barreiras ao acesso (funcionando como filtros). . Quando os ISPs rejeitam formatos válidos de nomes de domínio, endereços de e-mail ou URLs, estão na verdade negando serviço ao usuário dessas entidades ou comunidades cibernéticas. . ICANN procura incluir os novos TLDs na lista atual de TLDs, apesar do problema descrito acima. . Os novos TLDs em potencial devem estar conscientes desse problema antes de enviar requerimentos na próxima abertura. RECOMENDAÇÕES Como este problema está causando prejuízos econômicos aos patrocinadores, operadores de registro e consumidores, recomendamos que o Grupo Constituinte de ISP, juntamente com a comunidade da ICANN, colabore mais ativamente para minimizar essas dificuldades. Comentários sobre o layout,
estrutura e funcionalidade deste site Página atualizada em 24 de junho
de 2003 |
|||
