Implementação de referência open-source de um servidor RESTful para o serviço WHOIS – Respostas a dúvidas sobre RFP
8 de junho de 2012
Solicitamos que os interessados respondam à Solicitação de Propostas enviando um e-mail para: rws-opensource@icann.org. O período para enviar perguntas sobre a RFP já se encerrou. A resposta final à RFP está agendada para 15 de junho de 2012.
As 26 perguntas seguintes foram enviadas a rws-opensource@icann.org entre 16 de maio e 5 de junho de 2012. Estamos divulgando todas as perguntas e respostas no site da ICANN para que todos os interessados que responderam à proposta as aproveitem.
As perguntas foram agrupadas com perguntas semelhantes recebidas, ou por resposta igual a várias questões.
Exigências
Pergunta: Na seção “Exigências” a RFP contém um link para http://tools.ietf.org/id/weirds. Essa URL relaciona alguns drafts que não estão necessariamente relacionados ao modelo clássico de objetos de DPNs no serviço Whois (que em geral permite buscas por registradores, domínios, hosts e contatos no repositório local de objetos do registro). Em particular, draft-fiorelli-weirds-rws se refere à base de dados do RIPE, draft-newton-et-al-weirds-rir-json-answer e draft-newton-et-al-weirds-rir-query se referem aos Registros Regionais da Internet (RIRs), draft-newton-weirds-arin-whoisrws se refere aos dados Whois do ARIN, e draft-lacnic-weirds-restwhois-redirects trata do redirecionamento a partir um servidor Whois global. Tal como acontece com as exigências da RFP, podemos portanto concluir que apenas os documentos restantes (draft-designteam-weirds-using-http, draft-kucherawy-weirds-requirements e draft-sheng-weirds-icann-rws-dnrd) – dois dos quais também são expressamente citados na seção de “Referências” da RFP – são importantes como exigências para implementação das referências? Se não for o caso, por favor especifiquem quais outros drafts em http://tools.ietf.org/id/weirds também precisam ter apoio e por quê.
Resposta: Sim, esse é uma conclusão correta. O escopo esperado abrange apenas registros de nomes de domínio.
Pergunta: O grupo WEIRDS está criando dois padrões da IETF para procurar dados dos RIRs e padrões para buscar dados cadastrais de nomes de domínio. É necessário que a implementação de referências aplique todos esses padrões, ou apenas os padrões referentes aos dados cadastrais de nomes de domínio?
Resposta: Considerando que existem somente 5 RIRs e a maioria deles já está envolvida em WEIRDS e trabalhando em sua própria implementação, estamos nos dedicando somente ao lado do nome de domínio. Com 1k+ registradores credenciados pela ICANN e potencialmente centenas de novos gTLDs mais os ccTLDs existentes, e levando em conta os limites dos recursos, decidimos concentrar-nos na população do servidor mainstream.
Pergunta: A seção 2.4.4 diz que a implementação deve incluir um proxyporta 43 que utiliza o Whois RESTful para responder pedidos e traduzir buscas e respostas na porta 43. Embora essa seja uma abordagem possível, nossa atual implementação de servidores para o serviço Whois inclui o uso de uma porta 43 que acessa “diretamente” a base de dados do servidor Whois (isto é, ela não encaminha pedidos/respostas de/para uma interface diferente), o que possibilita um desempenho muito melhor da porta 43. A implementação de referência pode usar essa abordagem direta ao invés da abordagem por “proxy” descrita na RFP, contanto que a implementação ofereça um serviço Whois de porta 43 que responda dúvidas do mesmo modo como faria com “proxy”?
Resposta: Não. Para esclarecer, o que queremos é que todos os serviços essenciais se baseiem em RESTful, e ao perceber que alguns clientes ainda querem a porta 43, queremos que o proxy da porta 43 consiga traduzir os pedidos desses cliente para buscas RESTful e fornecer o resultado via porta 43.
Pergunta: A implementação de referência deve atender tanto gTLDs quanto ccTLDs?
Resposta: Sim, esperamos que a implementação de referência possa ser usada por gTLDs e ccTLDs.
Pergunta: Basicamente, um servidor WHOIS é um sistema de busca em bases de dados. A base de dados é o conjunto de informações de um registro ou registrador sobre os domínios; a linguagem da busca é aquela que o servidor WHOIS aceita, e o resultado é escolhido na base de dados subjacente. O que a base de dados contém, e quais buscas a linguagem de busca possibilita?
Embora seja possível intuir respostas a essas perguntas a partir dos apêndices sobre WHOIS nos contratos de registro com para dados WHOIS completos, os apêndices não são todos iguais. Por exemplo, o contrato de .INFO especifica buscas de correspondência parcial, ao passo que o contrato para .BIZ não o faz. O registro .AERO tem um campo ENS_Authid e rótulos de privacidade, enquanto .ASIA tem ENS_Authid, mas não tem rótulos de privacidade. O contrato de .XXX contém informações sobre as DNSSEC, o que contratos mais antigos não têm. O contrato de .POST inclui um campo Maintainer (Mantenedor) no lugar do campo de e-mail dos outros contratos. O contrato de .NAME descreve vários níveis de acesso e objetos de cadastro defensivo.
Entendemos que registros diferentes continuarão tendo exigências um pouco diferentes, mas parece que muitas diferenças entre os contratos se devem mais a um entendimento em evolução das necessidades do que a decisões deliberadas de ser diferente, p. ex., buscas parciais vs. buscas exatas, DNSSEC, ou Mantenedor vs. e-mail. Será que a ICANN pode dar alguma orientação sobre o que se espera que esteja na base de dados subjacente e quais tipos de buscas precisam ser atendidos?
Resposta: O que está na base de dados subjacente e quais buscas serão atendidas depende da entidade normativa do registro/registrador, conforme destaca a descrição acima.
Em outras palavras, esperamos que essa implementação RWS open-source possa ser configurada de acordo com os campos em que oferece buscas.
Pergunta: A RFP não esclarece a estrutura do resultado. Existe alguma expectativa da sequência dos elementos de dados? Se houver, qual é essa expectativa?
Resposta: Espera-se que a estrutura do resultado seja definida no protocolo da IETF. No momento, os Drafts da Internet citados na RFP têm uma estrutura para nomes de domínio.
Pergunta: Existem exigências específicas quanto ao desempenho do sistema? Por exemplo, existe alguma exigência mínima de pedidos-por-segundo conforme as especificações de acordo com o hardware?
Resposta: Neste ponto, temos apenas o conjunto de exigências descrito na RFP. Estamos interessados em conhecer as propostas dos possíveis fornecedores a esse respeito.
Pergunta: Existe alguma lista específica de códigos para dados Whois que precisam ser viabilizados? Por exemplo, é suficiente limitar pedidos e respostas para UTF-8 ou é preciso viabilizar um grande número de codificações? É possível que dados de registros/registradores tenham de ser convertidos entre codificações?
Resposta: Isso depende do protocolo, que ainda não está definido. Nós cremos que ele exigirá o UTF-8, mas também pode permitir outras codificações.
Pergunta: Existe alguma exigência mínima para os tipos de formato para transmissão via rede que precisam ser viabilizados? Por exemplo, será que a implementação de referência poderia implementar somente JSON e depois permitir que se incluam outros formatos, ou ela precisa possibilitar uma série mínima de representações?
Resposta: Assim como na pergunta sobre as codificações, isso depende do que o protocolo exigirá.
Pergunta: Existe alguma exigência mínima para opções de políticas? A RFP especifica o seguinte: “A implementação deve permitir a configuração de parâmetros das opções de políticas”, mas isso é muito amplo. Existem exemplos dos tipos de políticas que poderão ser exigidas? Por exemplo, isso inclui normas como otimização de pedidos, filtragem de respostas (i. é., detalhes ampliados para pedidos Whois de determinados clientes), etc.?
Resposta: Nós aguardamos as opções de configuração para a funcionalidade definida nas especificações do protocolo. Não esperamos que as coisas que não estão definidas no protocolo sejam implementadas. No entanto, esperamos que a implementação aconteça de forma modular, permitindo que os registros/registradores interessados a modifiquem com um esforço mínimo para incluir a funcionalidade adicional.
Pergunta: Testes de segurança fazem parte das exigências? Em caso afirmativo, o contratante está elaborando a implementação de referência exigida para executar esses testes de segurança?
Resposta: Esperamos que a implementação final tenha um código de qualidade de produção. Por isso esperamos pelo menos testes básicos de segurança, e esperamos que o contratante os proponha.
Pergunta: Existe alguma exigência sobre o gerenciamento geral do projeto ou isso ficará a cargo do contratante? Por exemplo, onde o código será hospedado? Como ficará o acompanhamento de um assunto e o fluxo de trabalho para desenvolvimento?
Resposta: Não, não existem exigências a esse respeito além do que está descrito na RFP.
Pergunta: Para reduzir o trabalho de integração, o documento com a RFP especifica como exemplo que as diversas camadas podem ser separadas (veja a seção 2.4.2 da RFP). Vocês estão procurando uma implementação modular de modo que existam produtos separados para as camadas de apresentação, lógica de negócios e aceso de dados que possam ser usadas em combinação ou isoladamente?
Resposta: Nós não os chamamos de produtos separados, mas mantê-los em módulos separados faz sentido, ou no mínimo conseguir configurá-los separadamente seria bom.
Pergunta: Em termos da configuração de parâmetros segundo a seção 2.5 da RFP, a implementação deve oferecer somente a possibilidade de ser configurada, ou a ICANN está aberta a sugestões de, por exemplo, uma interface para configurar diversas opções que já poderiam ser incluídas na implementação? Devemos oferecer essa possibilidade como um módulo adicional e opcional?
Resposta: Estamos abertos a sugestões.
Pergunta: O produto, a documentação e o suporte devem estar apenas em inglês ou também em outros idiomas? Nesse caso, por favor especifiquem.
Resposta: Pelo menos em inglês, e seria ótimo se houver a possibilidade de outros idiomas.
Pergunta: A inclusão do código de terceiros (2.6) pode levar a custos imprevisíveis em termos de controle de qualidade e documentação. A ICANN estaria aberta a um modelo de custos que inclua esse trabalho adicional por tempo e material? O mesmo se aplica à necessidade não especificada de publicações, segundo 2.2, ou suporte.
Resposta: Sim, estamos abertos a sugestões. Mas para esclarecer, a inclusão do código de terceiros só deve acontecer quando fizer sentido (do ponto de vista dos custos) para o fornecedor usá-lo em vez de ele mesmo fazer o trabalho desde o início.
Cronograma do projeto
Pergunta: Qual é o cronograma do projeto? A RFP especifica um período de suporte de um ano, mas não descreve nenhuma expectativa quanto a prazos para que o grupo de trabalho crie a especificação final, nem define expectativas de tempo para entregar a implementação inicial.
Resposta: O cronograma atual da IETF diz que as especificações estarão prontas até agosto de 2013; mas isso pode mudar.
Pergunta: Qual é tempo esperado entre a publicação das especificações e as mudanças no sistema?
Resposta: Nós não esperamos que o fornecedor escolhido implemente todos os Drafts. Pretendemos nos reunir com o fornecedor toda vez que acharmos que faz sentido divulgar uma nova publicação e então entraremos em acordo com o fornecedor quanto ao momento e escopo da entrega.
Avaliação da RFP e contratação
Pergunta: Quem é o público que está examinando a RFP? E o comitê de seleção?
Resposta: Um comitê de seleção composto de especialistas técnicos examinará a proposta.
Pergunta: Existe um valor orçado para o projeto?
Resposta: Nós temos um orçamento para o restante desse exercício fiscal e solicitamos mais para o próximo exercício. Gostaríamos de analisar as propostas dos fornecedores interessados.
Pergunta: Qual é o orçamento total para o projeto? A ICANN está interessada em ofertas a preço fixo ou também estaria aberta a uma abordagem escalonada, na qual primeiro as exigências são reunidas e especificadas e depois se estimam os custos, ou em que se faz uma oferta com base nas conclusões dessa interação com a ICANN?
Resposta: Nós gostaríamos de examinar as propostas dos fornecedores interessados, e estamos abertos a ouvir as opções.
Pergunta: Existe alguma preferência quanto ao tipo de contrato (Tempo e Material, Preço Fixo, etc.)?
Resposta: Estamos abertos a ambos, mas talvez seja mais fácil definir um contrato de preço fixo em um comunicado ao invés do projeto todo, reconhecendo o cronograma variável.
Pergunta: Na seção "Assessment and Award" (Avaliação e concessão), a RFP observa que o momento exato da concessão pode depender do processo de padronização da IETF. De que maneira a ICANN espera que o momento da concessão dependa do processo da IETF? Mais especificamente, será que a concessão pode acontecer em, digamos, um mês mais ou menos a partir do prazo final para resposta à RFP, ou ela pode ser adiada até depois de novembro de 2012 ou agosto de 2014 (datas sugeridas nos marcos do GT WEIRDS)?
Resposta: Nós pretendemos conceder o contrato o mais depressa possível. Esperamos que o fornecedor apresente os comunicados antes das RFCs se encerrarem, assim que houver especificações mais ou menos estáveis e com orientação prévia da ICANN.
Outras perguntas
Pergunta: A RFP exige que “o produto final esteja em conformidade com as RFCs relevantes que serão padronizadas no GT WEIRDS da IETF”. A ICANN espera ou exige que o contratante participe e/ou contribua com o GT WEIRDS para garantir que o projeto open source se mantenha alinhado com o GT?
Resposta: Não existe nenhuma exigência de contribuir, mas provavelmente seria recomendável que o contratante no mínimo acompanhe a lista de correio do GT WEIRDS.
Pergunta: A ICANN acaba de publicar um roteiro para implementar o SAC 051 (http://www.icann.org/en/news/announcements/announcement-6-04jun12-en.htm), que inclui o trabalho da IETF para um novo protocolo, mas também prevê contribuições da comunidade da ICANN, particularmente de registros e registradores de ccTLDs e gTLDs e da GNSO: “este roteiro recomenda uma abordagem de várias vertentes para a adoção de um substituto ao protocolo WHOIS”. O escopo do projeto de implementação de referência se limita às especificações do protocolo que a IETF produzirá?
Resposta: Sim, ele precisa estar de acordo com as RFCs produzidas na IETF, mas também se espera que tenha qualidade de produção.
Pergunta: Podemos esperara que os registro se envolvam durante o desenvolvimento e teste de processos?
Resposta: Pode haver alguns registros/registradores envolvidos, mas o fornecedor escolhido não deve contar com isso.