Annonces de l'ICANN

Lisez les annonces de l'ICANN pour vous tenir au courant des dernières activités d’élaboration de politiques, des événements régionaux et bien plus encore.

Référence de mise en œuvre « open source » d'un serveur Whois de nom de domaine RESTful – Réponse aux questions de la requête de propositions (Request for proposal – RFP)

8 juin 2012

Nous prions aux participants de répondre à cet Request For Proposals (RFP) à : rws-opensource@icann.org. La période de présentation de questions sur le RFP est maintenant clôturée. La réponse finale au RFP est prévue pour le 15 juin 2012.

Les 26 questions ci-dessous ont été présentées à rws-opensource@icann.org entre le 16 mai et le 5 juin 2012. La totalité des questions / réponses sera publiée sur le site Web de l'ICANN pour que tous les participants puissent y accéder.

Les questions reçues ont été groupées en vertu de leur similarité ou si la même réponse serait applicable à plusieurs questions.

Exigences

Question : Dans sa section « Exigences », la RFP contient un lien vers http://tools.ietf.org/id/weirds. Sous cet URL, certaines versions préliminaires n'étant pas strictement liées au modèle classique du modèle Whois pour les noms de domaine TLD sont répertoriées (normalement elles permettent des requêtes aux bureaux d'enregistrement, domaines, hôtes et contacts dans le référentiel local des registres). En particulier, draft-fiorelli-weirds-rws renvoie à la base de données du RIPE tandis que draft-newton-et-al-weirds-rir-json-response et draft-newton-et-al-weirds-rir-query renvoient aux registres Internet régionaux (Regional Internet Registries – RIR), draft-newton-weirds-arin-whoisrws renvoie au Whois ARIN, et draft-lacnic-weirds-restwhois-redirects a trait au redirectionnement d'un serveur Whois mondial. Comme dans le cas des exigences du RFP, devons-nous supposer que seulement les documents restants (draft-designteam-weirds-using-http, draft-kucherawy-weirds-requirements et draft-sheng-weirds-icann-rws-dnrd) – deux desquels sont aussi explicitement référencés dans la section « Références » de la RFP – sont importants en tant qu'exigences pour la référence de mise en œuvre ? Si non, veuillez spécifier quels sont les autres versions préliminaires sous http://tools.ietf.org/id/weirds qui exigent du support et pourquoi.

Réponse : Oui, votre hypothèse est correcte. La portée prévue ne couvre que les registres de noms de domaine.

Question : Le groupe WEIRDS est en train de créer deux standards IETF pour la requête de données RIR. ET les standards pour les requêtes de données d'enregistrement de noms de domaine. La mise en œuvre de référence doit-elle implémenter tous ces standards ou seulement ceux liés aux données d'enregistrement de noms de domaine ?

Réponse : Vu qu'il n'y a que 5 RIR dont la plupart emploie WEIRDS et travaille avec ses propres mises en œuvre, nous sommes seulement focalisés sur le côté des noms de domaine. Avec 1k+ bureaux d'enregistrement accrédités par l'ICANN, les centaines potentielles de nouveaux gTLD plus les ccTLD existants, et étant donné le financement limité, nous avons décidé de nous centrer sur la population du serveur général.

Question : La section 2.4.4 établit que la mise en œuvre devrait inclure un port 43 « proxy » utilisant le RESTful Whois afin de répondre aux requêtes et de traduire les requêtes du port 43 et les réponses en conséquence. Bien qu'il s'agisse d'une approche possible, notre mise en œuvre actuelle du serveur Whois inclut la mise en œuvre du port 43 qui permet d'accéder « directement » à la base de données du serveur Whois (c'est-à-dire, il ne renvoie pas de requêtes / réponses / de / à un frontend différent), ce qui permet une meilleure performance du port 43. Est-ce possible que la mise en œuvre de référence utilise cette approche directe au lieu de l'approche par « proxy » décrite dans la requête de propositions, pourvu que la mise en œuvre prévoie au port 43 un Whois capable de répondre aux requêtes de la même manière qu'il le ferait en mode « proxy »?

Réponse : Non. Pour préciser, ce que nous voulons c'est que tous les principaux services soient basés RESTful, et vu que certains clients risquent encore d'interroger le port 43, nous voulons que celui-ci soit capable de traduire les requêtes de ces clients en requêtes RESTful et de retourner le résultat par le port 43.

Question : La mise en œuvre de référence concerne autant les gTLD que les ccTLD ?

Réponse : C'est correct. Cette mise en œuvre de référence est censée pouvoir être utilisée autant pour les gTLD que pour les ccTLD.

Question : Un serveur WHOIS est fondamentalement un système d'interrogation de bases de données. Une base de données est un recueil d'informations sur les domaines que possède un registre ou un bureau d'enregistrement ; le langage d'interrogation est celui que le serveur WHOIS accepte; et le résultat est issu de la base de données sous-jacente. Quel est le contenu de la base de données et quel type de requêtes accepte le langage d'interrogation?

S'il est possible de déduire les réponses à ces questions à partir des annexes WHOIS des accords de registre existants en matière de WHOIS complet, toutes les annexes ne disent pourtant pas la même chose. Par exemple, l'accord .INFO évoque des interrogations de correspondance partielle, alors que l'accord .BIZ ne le fait pas. Le registre .AERO a un champ ENS_Authid et possède des étiquettes de confidentialité, alors que .ASIA a des champs ENS_Authid mais ne possède pas d'étiquettes de confidentialité. L'accord .XXX fait référence à l'information DNSSEC, alors que des accords précédents ne le font pas. L'accord .POST prévoit un champ « Maintainer » au lieu d'un champ « Email » comme c'est le cas dans d'autres accords. L'accord .NAME décrit des niveaux d'accès multiples ainsi que des objets d'enregistrement défensif.

Nous savons que les différents registres continueront à être confrontés à des besoins différents, mais on constate que les plus grandes différences entre les accords tiennent à une évolution dans la compréhension des besoins, plutôt qu'à des décisions délibérées de différentiation; par exemple, les interrogations partielles versus les interrogations exactes, les DNSSEC, et « mainteiner » versus « email ». L'ICANN peut-elle fournir des orientations sur le contenu des bases de données et les types d'interrogation qui devraient être acceptées ?

Réponse : Comme vous l'avez bien souligné dans votre description ci-dessus, c'est à l'organisme d'élaboration de politiques des registres /bureaux d'enregistrement de décider quel sera le contenu des bases de données et quels types d'interrogation seront acceptés.

Autrement dit, nous nous attendons à ce que cette mise en œuvre de logiciel libre RWS puisse gérer (configurer) les champs qui peuvent être interrogés.

Question : L'appel d'offres ne précise pas la structure des résultats. Y a-t-il des attentes par rapport au séquencement des données? Si c'est le cas, quelles sont ces attentes?

Réponse : La structure des résultats sera définie par le protocole IETF. Actuellement, les projets internet cités dans la RFP ont une structure pour les noms de domaine.

Question : Y a-t-il des exigences spécifiques en matière de performance du système? Par exemple, existe-t-il une exigence concernant un minimum de requêtes par seconde pour un matériel ayant des spécifications données?

Réponse : A ce stade, nous n'avons que l'ensemble d'exigences décrites dans la RFP. Nous sommes ouverts à toute proposition à cet égard que des fournisseurs potentiels seraient prêts à soumettre.

Question : Y a-t-il une liste spécifique d'encodages de données WHOIS devant être supportés ? Par exemple, suffirait-il de contraindre les requêtes et les réponses à utiliser l'encodage UTF-8 ou bien faut-il qu'un grand nombre d'encodages puissent être supportés ? Est-il possible que les données de registre/bureau d'enregistrement soient converties entre les différents types d'encodage ?

Réponse : Cela dépend du protocole qui n'a pas encore été défini. Nous prévoyons que l'UTF-8 sera nécessaire, mais il se peut que d'autres encodages puissent être acceptés.

Question : Y a-t-il une exigence minimale concernant les types de formats de messages supportés ? Par exemple, la mise en œuvre de référence pourrait-elle mettre en œuvre uniquement JSON et par la suite permettre l'incorporation d'autres formats ou bien doit-elle accepter un ensemble minimum de représentations ?

Réponse : Comme pour la question de l'encodage, cela dépend des spécifications du protocole.

Question : Y a-t-il des exigences minimales pour les options en matière de politiques ? L'appel d'offres précise que: « La mise en œuvre devrait permettre la configuration de paramètres pour les options en matière de politiques », mais c'est assez large. Y a-t-il des exemples des types de politiques pouvant être exigées ? Par exemple, des politiques telles que la limitation de requêtes, le filtrage de réponses (c'est-à-dire, des détails supplémentaires pour les requêtes Whois de certains clients), etc. seront-elles prises en compte ?

Réponse : Les options de configuration s'appliqueront à la fonctionnalité définie dans les spécifications du protocole. Tout ce qui ne sera pas défini dans le protocole n'est pas censé être mis en œuvre. Cependant, nous envisageons une mise en œuvre de type modulaire, qui permettra aux registres / bureaux d'enregistrement intéressés d'y apporter des modifications avec un minimum d'effort pour inclure des fonctionnalités supplémentaires.

Question : Les tests de sécurité font-ils partie des exigences ? Si c'est le cas, le prestataire chargé de développer la mise en œuvre de référence, doit-il mettre en place ces tests de sécurité ?

Réponse : Nous espérons que la mise en œuvre finale soit un code de qualité. C'est pourquoi nous nous attendons à au moins un test de sécurité de base, et nous attendons du prestataire une proposition dans ce sens.

Question : Y a-t-il des exigences par rapport à la gestion globale du projet ou bien cela relèvera du contractant ? Par exemple, où est-ce que le code sera hébergé ? Qu'en est-il du suivi des problèmes et du développement de flux de travail ?

Réponse : Non, il n'y a pas d'exigences à cet égard, en dehors de ce qui est décrit dans la requête de propositions.

Question : Pour minimiser le travail d'intégration, le document de la requête de propositions précise en tant qu'exemple que les différentes couches pourraient être séparées. Voir 2.4.2 de la RFP. Cherchez-vous une mise en œuvre modulaire afin qu'il y ait des produits différenciés pour la couche de présentation, de logique commerciale et d'accès aux données, qui puissent être utilisés de façon combinée ou isolée ?

Réponse : Nous ne les appellerions pas des produits isolés, mais le fait de les avoir en modules isolés pourrait être intéressant, ou au moins le fait d'être capables de les configurer de façon isolée serait positif.

Question : En ce qui concerne la configuration de paramètres conformément à la section 2.5 de l'appel d'offres, la mise en œuvre prévoira-t-elle uniquement la possibilité de les configurer ou bien l'ICANN sera ouverte à des suggestions, par exemple, une interphase pour configurer plusieurs options qui pourrait d'ores et déjà être incluse dans la mise en œuvre ? Pourrait-on proposer une telle approche en tant que module supplémentaire et optionnel ?

Réponse : Nous sommes ouverts aux suggestions.

Question : Le produit, la documentation et les supports seront-ils uniquement en anglais ou d'autres langues seront-elles prévues ? Si c'est le cas, merci de le préciser.

Réponse : Au moins en anglais, mais ce serait génial si on pouvait avoir d'autres langues.

Question : L'inclusion d'un code tiers (2.6) pourrait entraîner des coûts imprévisibles en matière de contrôle de qualité et de documentation. L'ICANN serait-elle ouverte à un modèle de coût qui tienne compte d'un tel travail supplémentaire autant du point de vue du temps que des matériaux ? La même chose s'appliquerait au besoin non spécifié de publications conformément au point 2.2. ou de soutien.

Réponse : Oui, nous sommes ouverts aux suggestions. Mais pour préciser, l'idée de l'inclusion d'un code tiers n'est envisageable que si elle a un sens (du point de vue d'une perspective de coûts) pour le fournisseur, qui peut alors s'en servir au lieu de commencer le travail à partir de zéro.


Calendrier du projet

Question : Qu'est-ce que le calendrier du projet ? La RFP spécifie une période de soutien d'un an bien que le délai établi pour que le groupe de travail finisse la spécification ou que les attentes concernant le délai de livraison de la mise en œuvre initiale ne soient pas spécifiées.

Réponse : Le calendrier actuel de l'IETF établit que les spécifications doivent être prêtes en août 2013 ; cependant, il pourrait subir des modifications.

Question : Quel est le temps prévu entre la publication itérative des spécifications et la livraison de changements au système ?

Réponse : Il n'est pas prévu que le fournisseur choisi soit chargé de la mise en œuvre de tous et chacun des avant-projets Internet. Par contre, il est prévu d'accompagner le fournisseur pour chaque nouvelle publication, si elle s'avérait censée, et par la suite accorder avec le fournisseur la date de la livraison ainsi que la portée.


Évaluation du RFP et contrat

Question : Qui sont les responsables de la révision du RFP ? Qui sont les membres du comité de sélection ?

Réponse : Un comité de sélection intégré par des experts techniques fera la révision de la requête de propositions.

Question : Le projet a-t-il un montant budgété ?

Réponse : Il existe des fonds budgétés pour ce qui reste de cet exercice fiscal et nous en avons demandé davantage pour le prochain exercice fiscal. Nous aimerions faire la révision des propositions des fournisseurs intéressés.

Question : Quel est le budget total pour le projet ? L'ICANN est-elle intéressée à des offres à prix fixe ou bien l'ICANN serait ouverte à une approche par étapes selon laquelle les exigences seraient tout d'abord rassemblées et les coûts seraient estimés ou proposés sur la base des résultats de l'interaction avec l'ICANN ?

Réponse : Nous aimerions faire la révision des propositions des fournisseurs intéressés. Et nous sommes ouverts à écouter d'autres options.

Question : Y a-t-il un type de contrat préféré (délai et matériel, prix fixe, etc.) ?

Réponse : Nous sommes ouverts aux deux ; mais peut être le prix fixe serait-il mieux pour une publication au lieu du projet complet en fonction du calendrier variable.

Question : Dans la section « évaluation et décision », la RFP établit que le temps exact de la décision peut dépendre du processus de standardisation de l'IETF. De quelle manière l'ICANN s'attend à ce que le temps de la décision dépende du processus de l'IETF ? Spécifiquement, la décision devrait-elle avoir lieu dans un mois ou près d'un mois de la date butoir de réponse de la RTF ou pourrait-elle être reportée jusqu'après novembre 2012 ou août 2013 (dates ayant été fournies dans les jalons du groupe de travail WIERDS ?

Réponse : Nous espérons attribuer le contrat dans le plus bref délai. Nous espérons que le fournisseur produise les publications avant la sortie des RFC, étant donné les spécifications plutôt stables et la direction préalable de l'ICANN.


Autres questions

Question : La RFP exige que « le produit final soit conforme aux RFC qui seront normalisés par le groupe de travail WEIRDS IETF ». L'ICANN espère ou exige que le contractant participe et/ou contribue avec le groupe de travail WIERDS dans le but d'assurer que le projet open source soit en ligne avec le groupe de travail ?

Réponse : Il n'y a pas d'exigences là-dessus ; mais peut-être serait-il censé que le contractant fasse au moins le suivi de la liste de diffusion du WEIRDS.

Question : L'ICANN vient de publier une feuille de route pour la mise en œuvre du SAC 051 (http://www.icann.org/fr/news/announcements/announcement-6-04jun12-fr.htm), qui adopte le travail de l'IETF sur un nouveau protocole anticipant aussi les contributions de la communauté de l'ICANN, notamment les registres et les bureaux d'enregistrement des ccTLD et des gTLD et la GNSO : « cette feuille de route recommande une approche sur plusieurs fronts pour adopter le remplacement du protocole WHOIS ». La portée du projet de mise en œuvre de référence est-elle limitée aux spécifications du protocole que sera produit par l'IETF ?

Réponse : Oui, il doit se conformer aux RFC produits par l'IETF, mais l'on s'attend aussi à une production de qualité.

Question : Devons-nous nous attendre à ce que les registres soient impliqués pendant les processus de développement et de test ?

Réponse : Il se peut que quelques registres/bureaux d'enregistrement soient impliqués, mais le fournisseur sélectionné ne devrait pas s'attendre à cela.