Requerimento relativo à RFP (Solicitação de Propostas) para .NET
Respostas a perguntas
5 de janeiro de 2005
Essas perguntas foram enviadas por candidatos em potencial, de acordo com os procedimentos descritos na RFP para .NET. Algumas perguntas foram editadas, para facilitar seu entendimento, e/ou combinadas, para evitar repetições. Estamos publicando as perguntas e respostas on-line para que todos os candidatos em potencial tenham as mesmas informações. O período para perguntas sobre a RFP para .NET encerrou-se em 6 de janeiro de 2005. A ICANN continuará oferecendo apoio técnico por intermédio deste fórum de perguntas e respostas ao longo de todo período de requerimento. (Envie suas perguntas sobre apoio técnico para <net-rfp@icann.org>.)
OBSERVAÇÃO: Poderemos publicar novas perguntas e/ou respostas. Verifique com freqüência.
Respostas a perguntas
O formulário de requerimento on-line referente à RFP para .NET estará disponível em breve, assim que os testes estiverem concluídos. Os candidatos em potencial de boa-fé poderão solicitar uma senha e a URL para o formulário de requerimento enviando um pedido por e-mail para net-rfp@icann.org. Os pedidos devem incluir o nome da organização, o nome da pessoa de contato e seu endereço de e-mail e telefone.
2. As perguntas sobre a RFP para .net serão respondidas à medida que chegarem, ou serão respondidas de uma vez no final do período para perguntas?
As perguntas serão respondidas à medida que chegarem.
3 . A RFP contém várias indicações para que os candidatos em potencial não tenham contato com a equipe de ICANN, com a Diretoria ou com os avaliadores independentes. Entretanto, gostaria que confirmassem que, caso uma entidade entre em contato com a equipe de ICANN no decurso normal de uma transação (isto é, para cumprir eventuais obrigações contratuais já existentes) e esses contatos não tiverem nenhuma relação com a RFP de .net, isso não resultará na desqualificação dessa entidade.
Confirmado.
ICANN identificará a empresa que realizará a avaliação independente e, de acordo com o grau e tipo de contribuição com o processo, o nome de alguns indivíduos que participarão.
5. Os candidatos serão obrigados a enviar todo seu requerimento com o formulário on-line? Como eles enviarão tabelas e gráficos conforme descrição no requerimento? Quais são as limitações de tamanho e formato dos desenhos e gráficos? (O requerimento diz: “É possível enviar diagramas, tabelas e outros materiais semelhantes em resposta a disposições específicas, quando a RFP assim o indicar. Em algumas seções do formulário on-line os candidatos poderão incluir material não-textual como parte de seu requerimento (p. ex., gráficos, fluxogramas, modelos e diagramas”.)
O requerimento inicial, na íntegra, será enviado pelo formulário on-line. Como indica o requerimento, mais tarde ICANN poderá solicitar material suplementar em papel. O candidato poderá acrescentar gráficos para algumas questões do formulário on-line. Essas questões são:
· Parte Dois, pergunta quatro: Modelo de receitas e preços; Capacidade e estabilidade financeira.
Haverá uma oportunidade de incluir gráficos separadamente para todas as partes da pergunta, ou seja, subseção (a), subseção (b), subseção (b)ii, subseção (b)iii, subseção (b)iv, subseção (b)v.
· Parte Dois, pergunta cinco: Competência técnica
Haverá uma oportunidade de incluir gráficos separadamente para todas as partes da pergunta, ou seja, subseção (a), e uma para cada subseção de (b) até (b)xix.
Os gráficos poderão estar nos seguintes formatos: GIF, PNG e JPEG, e serão exibidos numa largura de 640 pixels. Não é possível fazer o upload de formatos de documentos como .pdf ou .doc (*exceto no caso da indicação na resposta 11 abaixo – atualizada em 3 de Janeiro de 2005).
6. De que maneiras o requerimento on-line garante que as respostas não serão limitadas? Haverá outras opções para enviar requerimentos além do formulário on-line?
O requerimento foi desenvolvido para solicitar as informações necessárias e suficientes para que avaliadores competentes e com conhecimento de causa selecionem o sucessor para .net. Esse método já foi testado durante o processo semelhante (mas reconhecidamente diferente) para os sTLDs. Se forem necessárias informações adicionais, elas serão solicitadas por um intermediário, de modo simplificar a interação entre candidatos e avaliadores. Todos os requerimentos deverão ser enviados por esse formulário.
7. Na Parte 2, Seção 4:” Modelos de receitas e preços”, a RFP para .NET especifica: “Todos os candidatos deverão observar que taxas de registração pagas à VeriSign antes da transferência da responsabilidade pela operação não serão transferidas ao próximo operador do registro”. Favor esclarecer o que significa essa afirmação quanto à transferência de taxas de registração.
O atual Contrato de Registro para .NET entre ICANN e a VeriSign não prevê que a VeriSign, caso não seja selecionada como sucessor, faça qualquer pagamento ao próximo operador do registro .NET referente a receitas que a VeriSign já tenha recebido na data de por períodos de registração no futuro. Do mesmo modo, ele também não prevê que o próximo operador do registro faça algum pagamento à VeriSign correspondente ao valor da atual base de clientes.
8. O formulário on-line estabelece um limite de 20.000 caracteres, com espaços, para o texto. Isso significa aproximadamente sete páginas de texto por caixa de resposta. Ainda que isso seja espaço suficiente para discutir adequadamente e detalhar a solução de um candidato para alguns componentes, outros componentes exigirão mais espaço para poderem ser avaliados apropriadamente, como por exemplo a Seção 8: Transição. Era intenção da ICANN limitar o texto e, nesse caso, a ICANN vai reconsiderar a exigência e conceder espaço ilimitado para que os candidatos respondam à RFP?
Sim, o limite de 20.000 caracteres foi intencional, ver resposta 6 acima. No entanto, para permitir que os candidatos respondam na íntegra cada uma das oito subperguntas da Parte 2, Seção 8 (Transição), o limite de caracteres para aquela caixa de texto somente será aumentado para 160.000 caracteres.
9. O texto do formulário on-line indica que a Parte 2, Seção 5, “Competência técnica”, permite gráficos, mas o mecanismo para incluir gráficos se encontra apenas na Subseção 5.b.xiii, “Segurança do sistema e segurança física”. A ICANN pretende mudar o formulário para possibilitar a inclusão de gráficos no restante da Parte 2, Seção 5?
Sim.
10. No momento, o formulário on-line não oferece nenhum mecanismo para incluir gráficos na Parte 2, Seção 8, “Planos de transição e migração”. Acreditamos que os desenhos e gráficos serão essenciais para articular e avaliar adequadamente essa seção. A ICANN pretende mudar o formulário para possibilitar a inclusão de gráficos na Parte 2, Seção 8?
Sim.
11. Na Parte II, Seção 4 (a) o formulário de requerimento solicita cópias de declarações financeiras auditadas. Como essas informações serão incluídas no formulário on-line?
O formulário está sendo modificado a fim de possibilitar a inclusão de documentos PDF na Parte II, Seção 4 (a) somente.
12. O ponto 4 da “Lista de verificação da RFP” indica que o candidato deverá imprimir, assinar e enviar para ICANN uma cópia do requerimento. Até quando e como a cópia deverá ser enviada?
Favor enviar a cópia impressa e assinada do requerimento preenchido para ICANN via correio ou serviço de entregas (p. ex., DHL ou FedEx) até no máximo o final do expediente de 21 de janeiro de 2005.
13. Não tenho certeza se os dados para login podem ser usados por várias pessoas. Devemos solicitar dados adicionais de login para cada pessoa?
Não solicite logins adicionais – um login separado iria especificar um requerimento diferente. Um único login pode ser usado por várias pessoas ao mesmo tempo. Entretanto, é importante estar ciente de que há um risco de inconsistência se várias pessoas editarem os formulários simultaneamente, ou mesmo se uma única pessoa editar a mesma página em várias janelas.
Mais especificamente: se você clicar no botão “Update” (atualizar) na parte de baixo de uma página, TODOS os elementos daquela página serão atualizados. Se você tiver uma versão antiga da página numa janela (talvez clicando várias vezes no botão “back” (voltar) e clicar no botão “Update”, as informações antigas irão substituir todas as informações novas.
Desde que se observem essas ressalvas, várias pessoas poderão trabalhar em páginas diferentes ao mesmo tempo.
As caixas de texto usam uma fonte de largura fixa e preservam o espaço em branco, portanto é possível usar tabelas puramente baseadas em texto.
Consulte a página com informações técnicas (o link encontra-se no formulário de requerimento).
16. O espaço no formulário destinado a muitos capítulos não é suficiente para uma resposta de qualidade. Além disso, parece que só se permite um gráfico por caixa. Para algumas seções, seria melhor usar vários gráficos a fim de articular e avaliar adequadamente as soluções do candidato. A ICANN pretende modificar o formulário on-line para possibilitar mais de um gráfico por caixa?
Favor consultar as perguntas 6 e 8 acima referentes ao limite de caracteres em caixas de texto. Observe que a largura está definida em 640 pixels, mas a altura não está especificada, de modo que você pode colar várias imagens em um gráfico longo. Uma interface que permita vários gráficos por caixa de texto tornaria o formulário bem mais complexo para o usuário. Além disso, muitas imagens complicariam o formato do documento na produção do resultado final.
17. A Parte 2, Seção 5, da RFP para .net diz: “… o candidato deve incluir suas próprias propostas de versão dos apêndices C, D, E, O, P, Q e R, com base no atual contrato de registro para .NET <http://www.icann.org.br/tlds/agreements/verisign/net-index.htm> que o candidato gostaria de ver incluídas no próximo contrato de registro para .NET”. Algumas mudanças nos apêndices existentes no contrato para .net também seriam adequadas, mas o formulário de requerimento on-line não oferece nenhum mecanismo para enviar essas sugestões. Vocês pretendem acrescentar algum mecanismo ao formulário para que isso seja possível?
As eventuais mudanças em outros apêndices serão abordadas durante a fase de negociação do contrato.
18. Vocês pretendem oferecer aos candidatos um canal de comunicação sobre o formulário on-line depois de 6 de janeiro?
Sim, a ICANN continuará oferecendo suporte técnico por intermédio desse fórum de perguntas e respostas durante todo o período de requerimento. (Enviar para net-rfp@icann.org.)
“Capacidade de reiniciar” significa a capacidade de restaurar as operações on-line do registro depois de uma interrupção inesperada.
O prazo final para envio de requerimentos é 18 de janeiro de 2005, às 23:59 hs UTC.
Os “usuários” são funcionários do registro autorizados a efetuar alterações no arquivo de zona.
22. A Solicitação de Propostas final para .NET (ver http://www.icann.org.br/tlds/dotnet-reassignment/net-rfp-final-10dec04.pdf) indicava que a data planejada para o anúncio do sucessor do operador do registro .NET seria março de 2005. O contrato de registro entre a ICANN e a VeriSign irá expirar em 30 de junho de 2005. Isso deixa cerca de três meses para que o operador vencedor forme, teste, desenvolva e faça a transferência do registro .NET, o que inclui coisas como um ambiente OT e E pelo menos um mês antes da data para “ir ao ar” e do credenciamento técnico de todos os registradores. Isso também significa que qualquer plano de “recuo” para a transição não poderá depender do incumbente para continuar os serviços de registro. Vocês poderiam confirmar se isso está correto?
Confirmado. A data-alvo para o anúncio do próximo operador do registro .NET é março de 2005. O atual Contrato de Registro para .NET (ver http://www.icann.org.br/tlds/agreements/verisign/registry-agmt-net-25may01.htm) expira em 30 de junho de 2005. A Seção 5.2.3 do atual Contrato de Registro para .NET determina que se o incumbente não for designado como o próximo Operador do Registro, o incumbente “deverá cooperar com a ICANN e com o próximo Operador do Registro para facilitar a transição suave da operação do registro ao seu sucessor”, mas não exige especificamente que o incumbente coloque suas instalações de registração ou resolução à disposição do sucessor após 30 de junho de 2005.
23. Não consigo encontrar o link para a página com informações técnicas no formulário. Vocês poderiam me dar mais detalhes a respeito?
O link para a página com informações técnicas aparece na parte inferior da página índice do requerimento; a URL também se encontra no final do e-mail que lhe forneceu seu nome de usuário e sua senha para entrar no formulário de requerimento on-line.
24. Eu entendi que os diversos gráficos podem ser colados um abaixo do outro em uma longa imagem. Nossos navegadores não permitem imprimir com clareza imagens mais longas do que uma página. No caso da versão final impressa do requerimento, vocês aceitarão imagens que foram impressas individualmente e incluídas no documento impresso do formulário de requerimento preenchido?
Sim. No entanto, o propósito do requerimento impresso é apenas fornecer uma cópia assinada em papel do requerimento. Os avaliadores não irão ver a cópia composta em papel que você fornecer, e sim irão basear-se nos arquivos enviados. Imagens truncadas na cópia impressa do seu requerimento não afetarão a avaliação do seu requerimento. Se você quiser, poderá ajustar a aparência impressa, ajustando o tamanho de cada arquivo.
25. A Seção 2 #5b, xvii determina que os candidatos descrevam sua “… capacidade de manter a atual funcionalidade de .NET, incluindo IDNs, a viabilidade do Ipv6, do DNSSEC” e a Seção 8 também inclui “manter as capacidades funcionais existentes”. A ICANN vai exigir que o incumbente também detalhe essas funcionalidades para que seja possível fazer uma comparação?
Segundo o atual contrato de registro, o incumbente não é obrigado a fornecer detalhes adicionais sobre a funcionalidade. Como indica a Seção 2 #5b, xvii, as respostas dos candidatos devem se basear em informações “públicas ou disponíveis ao candidato por outros meios.” Do mesmo modo, as respostas do candidato à seção 8 devem basear-se em informações públicas ou disponíveis por outros meios.
26. A Parte 1 da RFP solicita que os candidatos forneçam as seguintes informações: “Identifique também quaisquer pessoas ou entidades que possuem ou irão possuir, ou de alguma maneira controlem, direta ou indiretamente, 5% ou mais do poder de voto pendente detido por todas as pessoas ou entidades qualificadas a participar da eleição (ou outro tipo de seleção) do conselho de diretores ou grupo gestor do candidato”.
Como esclarecimento, e numa tentativa de compreender melhor o que se pretende dizer com a expressão propriedade ou controle “indireto”, o texto citado acima exige que o candidate revele o nome dos seguintes:
a. O acionista majoritário (ou outro indicador de posse) de uma entidade que possui mais de 5% do poder de voto do candidato? No caso de companhias públicas, em oposição a companhias privadas, há algum indicador ou limiar de posse que possa obrigar a essa revelação?
b. O CEO (ou outro diretor-executivo) de uma entidade que detém mais de 5% do poder de voto do candidato?
O objetivo final é compreender quais pessoas físicas exercem controle sobre o candidato, de modo que se a revelação em resposta a essas instruções indicar uma série de entidades sem uma pessoa física no final da série, poderemos solicitar informações adicionais sobre a propriedade das entidades até encontrarmos uma pessoa física.
Caso o candidato seja uma empresa pública, com registro semelhante ao que exige a Comissão da Bolsa de Valores dos Estados Unidos, será suficiente fornecer as informações sobre o candidato referentes à posse de títulos de determinados beneficiários que a companhia inclui nos relatórios periódicos que protocola junta ao registro governamental.
Se o candidato não for uma empresa pública dessa espécie, solicitamos que ele identifique cada pessoa física e cada entidade cujas cotas de participação sejam superiores ao limite de 5%. Solicitamos que o candidato também forneça o nome do CEO (ou diretor administrativo ou outra pessoa que desempenhe as funções de um CEO) e os nomes dos detentores de capital cujas cotas de capital sejam superiores a 30%.
27. A Parte 2, Seção 5, da RFP especifica: “O candidato deve incluir suas próprias propostas de versões dos apêndices C, D, E, O, P, Q e R, com base no atual contrato de registro para .NET que o candidato gostaria de ver incluídas no próximo contrato de registro para .NET”. O candidato pode enviar esboços de apêndices com base em .biz, .info, .name ou .pro, os registros “gordos” credenciados pela ICANN?
O requerimento determina que o candidato apresente o texto dos apêndices que se tornarão parte do novo contrato para .NET. “Com base no atual contrato de .NET” significa o assunto analisado (que deve ser abordado de modo adequado) em cada um desses apêndices indicados. Não é necessário que o texto dos apêndices propostos corresponda exatamente do texto existente para .NET.
A ICANN fez outros testes para garantir que seja possível fazer o upload de arquivos PNG no formato do requerimento. Resolveu-se também um problema que havia antes com alguns navegadores e arquivos PNG. Favor consultar a página técnica para saber mais detalhes sobre o upload de imagens.
29. A caixa para resposta da Seção 7, Outros critérios relativos, permite até 20.000 caracteres para as três subseções com numerais romanos (no total). A ICANN vai permitir 20.000 caracteres para cada numeral romano, ou um total de 60.000 caracteres para a caixa toda?
Não. A caixa continuará limitada a 20.000 caracteres.
30. A Parte 2, Seção 5 da RFP determina: “Juntamente com as informações solicitadas abaixo, o candidato deve incluir suas próprias propostas de versões dos apêndices C, D, E, O, P, Q e R com base no atual contrato de registro para .NET...” O formulário de requerimento on-line só oferece caixas de texto para C.4 e C.5. Estou certo ao supor que só devo enviar propostas para C.4 e C.5?
Envie propostas de texto apenas para C.4 (Especificações funcionais do servidor de nomes) e C.5 (Política para consertos, atualizações e upgrade).
31. Algumas das nossas propostas de resposta à Parte 2.5 da RFP para .NET, Competência técnica, excederam o limite de caracteres dos campos correspondentes. Como devemos enviar o apêndice proposto?
As respostas a essa seção, ou seja, os apêndices propostos, devem limitar-se a 20.000 caracteres cada.
32. A resposta na pergunta 8 do texto Respostas a perguntas sobre o requerimento para .NET de 5 de janeiro de 2005 indica que “o limite de 20.000 caracteres foi intencional”, mas o formulário on-line não determina um limite de 20.000 caracteres, e sim de 20.000 bytes. O formulário on-line conta retornos como dois caracteres, o que pode causar uma diferença de 15% ou mais no comprimento da resposta. Quando o formulário será ajustado para um limite de caracteres ao invés de bytes?
No momento, não se pretende efetuar nenhuma modificação no formulário on-line. As metodologias para contagem de caracteres de cada sistema variam. Ao longo do processo de requerimento, o formulário on-line sempre considerou as contagens de bytes e caracteres equivalentes.
33. O formulário on-line não tem o recurso “word-wrapping” (ajuste de texto) ou outros limites para ajustar o texto à largura da caixa – ao imprimir uma página da Internet que avança para a direita, o texto ficará truncado. Como ter certeza de que esse texto não foi perdido?
As caixas de texto contêm elementos html “textarea” (área de texto) definidos para ajustar o texto em 80 colunas. Navegadores diferentes podem apresentar esses elementos de maneiras diferentes. Os candidatos poderão ver o formato impresso clicando no link de pré-visualização na parte inferior de cada seção, ou no botão “Preview Entire Application” (Pré-visualização de todo o requerimento” na parte de baixo da página-índice.
34. O suporte técnico ficará disponível no final de semana e na segunda-feira, 17 de janeiro, se um candidato tiver problemas ao enviar texto ou imagens?
Sim. O suporte técnico estará disponível em net-rfp@icann.org.
35. Tivemos um problema quando tentamos incluir imagens na seção Parte 2, No 8. Tentamos usar imagens diferentes com tamanhos, formatos, nomes, etc., de arquivos, mas não conseguimos enviar nada. Vocês poderiam verificar se há um problema técnico da sua parte?
Isso foi solucionado.
36. Encontramos erros do tipo “Conteúdo grande demais” ao tentarmos incluir uma imagem. Nosso arquivo estava dentro do limite de 640 pixels. Há algum problema?
Acreditamos que isso foi resolvido. Melhoramos a mensagem de erro para dar mais informações. Se você continuar tendo problemas, por favor, informe-nos imediatamente. (Observe que o limite de 640 pixels não é um limite de tamanho para incluir imagens. O limite de tamanho é de cerca de 4.000.000 bytes.)
37. Parece que o XML incluído em respostas não é exibido corretamente. Está havendo algum problema com isso?
Isso já foi solucionado.
38. Nós preenchemos algumas caixas de texto da lista de verificação “Etapas finais”, e depois voltamos e editamos algumas das nossas respostas anteriores. As caixas que já havíamos assinalado não estavam mais marcadas. Isso é proposital?
Sim. As caixas devem refletir a versão final do formulário, e devem ser preenchidas por último.
39. Uma das nossas respostas tem uma URL extremamente longa que excede o limite de 80 colunas para a largura do texto. Isso causa problemas na formatação final. O que nós podemos fazer?
Divida manualmente a seqüência longa em várias linhas, nenhuma delas com mais de 80 caracteres. Por exemplo, uma URL como esta:
http://www.minha-empresa-com-um-nome-muito-longo.com/nome-de-primeiro-nível-muito-longo/nome-de-segundo-nível-muito-longo/arquivo.html
pode ser apresentada como:
http://www.minha-empresa-com-um-nome-muito-longo.com/
nome-de-primeiro-nível-muito-longo/
nome-de-segundo-nível-muito-longo/arquivo.html
Esse problema pode ocorrer com qualquer seqüência não-dividida de caracteres que exceda o limite de palavras; a formatação resultante é uma função do algoritmo de formatação do navegador que nós não podemos controlar. Em todos esses casos, você precisa dividir a seqüência manualmente.
Última modificação deste arquivo em 18 de janeiro de 2005 |