Les participants sont priés de répondre à cette requête de propositions (RFP) à pre-delegation-testing-bid@icann.org. La période prévue pour la présentation de questions sur la requête de propositions est maintenant close. La réponse finale à la requête de propositions est prévue pour le 20 novembre 2012.
Les questions ci-dessous ont été présentées entre le 30 octobre et le 7 novembre 2012. L'ensemble des questions / réponses sera publié sur le site Web de l'ICANN pour que tous les participants puissent y avoir accès.
Les questions reçues ont été regroupées en fonction de leur similarité ou lorsque la même réponse concerne plusieurs questions.
Le texte ci-dessous est basé sur les questions reçues de la part de participants potentiels à la requête de propositions et ont été reformulées afin de les rendre neutres.
Question 1 : Q.16 : À quoi correspondent spécifiquement les « trois étapes majeures » définies par l'ICANN?
Il s'agit de trois étapes différentes définies dans la section 2.2. (« Champ d'application »).
Question 2 : Prévoit-on aussi l'évaluation des interfaces Web de chaque système de registre?
L'interface Whois devra être testée, tel que décrit dans le point 2.3.4.1. Le guide de candidature établit :
L'ICANN vérifiera l'accessibilité des données Whois à travers IPv4 et IPv6, via le port TCP 43 et l'interface Web, ainsi que la documentation d'auto-certification relative à la prise en charge des transactions Whois. Le format de réponse conformément à la Spécification 4 du contrat de registre et l'accès à Whois (via le port 43 et l'interface Web) seront testés à distance par l'ICANN depuis différents points sur Internet, via IPv4 et IPv6.
Question 3 : Y aura-t-il une ressource de l'ICANN spécialement dédiée à la quelle le fournisseur de test pourra avoir recours s'il a des questions pendant les étapes de conception et de mise en œuvre ?
Oui.
Question 4 : La requête de propositions indique que le processus aboutira à la conclusion d'un contrat avec « un ou plusieurs » fournisseurs, ce qui pourrait affecter les tarifs. Pourrait-on avoir plus de précisions de la part de l'ICANN par rapport à cette question?
Tel qu'il figure dans les Q.24, Q.25 et Q.26, les fournisseurs devront communiquer des tarifs différents pour chacun des points figurant sur la liste.
Question 5 : Les tests devront-ils se faire par fournisseur de services de registre back-end ou par candidat ?
Le fournisseur de test de pré-délégation devra vérifier que chaque candidat a tenu son engagement d'établir des opérations de registre conformément au guide de candidature aux gTLD (AGB).
Question 6 : Étant donné qu'il y a environ 1400 chaînes uniques faisant l'objet de candidatures, prévoit-on encore 2000 tests environ, à un rythme de 20 tests par semaine?
Nous prévoyons 1400 candidats qui devront être évalués à un rythme initial de 20 tests par semaine. Il convient de signaler qu'il est demandé au fournisseur d'être en mesure de monter jusqu'à 100 tests par semaine, à la demande de l'ICANN.
Question 7 : L'ICANN peut-elle fournir un chiffre définitif du nombre minimum anticipé de tests de pré-délégation ?
Le nombre total de chaînes faisant l'objet de candidatures qui seront approuvées n'est pas connu à ce stade. C'est pourquoi nous ne pouvons pas confirmer le nombre minimum de registres devant être évalués mais uniquement leur nombre maximum : 1400. Nous prévoyons que le nombre réel de registres évalués se rapprochera du maximum.
Question 8 : L'ICANN demande à ce que le logiciel de test de pré-délégation soit mis à disposition de l'ICANN en format de code source, et qu'il puisse être publié par l'ICANN comme un logiciel libre. Merci de bien préciser ce point.
Toute limitation applicable à la fourniture du logiciel ou de la licence devra être clairement établie dans l'appel d'offres. Au minimum, l'ICANN demande à avoir une licence non-exclusive et à tout moment exempte de droits du logiciel qui sera utilisé aux fins du test de pré-délégation.
Question 9 : Lorsqu'on parle du « logiciel du test de pré-délégation » fait-on référence à tous les logiciels utilisés dans le système de test de pré-délégation ou bien uniquement au logiciel utilisé pour mettre en place les tests techniques?
Tous les logiciels nécessaires pour fournir le service de test de pré-délégation.
Question 10 : La requête de propositions exige au fournisseur de test de pré-délégation d'examiner les documents d' « auto-certification » fournis par l'opérateur de registre évalué. Est-ce que l'ICANN pourrait confirmer que cette évaluation est destinée à vérifier que les documents sont complets et qu'elle ne comporte pas d'autres tests pour vérifier les auto-certifications?
Le fournisseur de test de pré-délégation devrait examiner les documents d'auto-certification afin de vérifier qu'ils sont complets, qu'ils sont plausibles et qu'ils sont conformes aux déclarations faites dans la candidature gTLD.
Question 11 : En ce qui concerne les rapports élaborés à travers les systèmes de test pré-délégation, le fournisseur de test de pré-délégation devra-t-il fournir un rapport pour chaque candidat ou bien un ensemble de rapports uniformes pour chaque plateforme technique des fournisseurs de services de registre back-end?
Oui. Pour chaque gTLD évalué, le fournisseur devra fournir un rapport où soit établi le degré de conformité de l'opérateur de registre vis-à-vis des critères du test de pré-délégation.
Question 12 : Est-ce que les propositions des candidats gTLD ou des fournisseurs de services de registre back-end et/ou des fournisseurs de service DNS ayant été engagés par les candidats aux nouveaux gTLD seront disqualifiées ou autrement pénalisées dans ce processus de requête de propositions?
L'ICANN acceptera des propositions des candidats aux nouveaux gTLD et/ou des fournisseurs de services de registre back-end pour les nouveaux gTLD. Tel qu'établi dans les Q.3 et Q.6, tout conflit d'intérêt devra être clairement déclaré par le participant. Un conflit d'intérêt ne disqualifie et ne pénalise pas automatiquement un participant.
Question 13 : Est-ce que l'ICANN considérera des EBERO comme des fournisseurs de test de pré-délégation ?
Oui.
Question 14 : Si le candidat à fournisseur de test de pré-délégation est le fournisseur de services de registre back-end d'un candidat, a-t-il le droit de vérifier ou de tester ses propres spécifications techniques conformément aux orientations du RFP ou bien y a-t-il d'autres méthodes pour gérer ce type de situations ? Si c'est le cas, merci de les préciser en détail.
Un fournisseur de services de pré-délégation n'a pas le droit de tester ses propres spécifications ou les services de registres fournis par lui-même à un candidat, dans la mesure où cela constitue une situation de conflit d'intérêt.
Question 15 : Est-ce que l'ICANN accepterait une approche comportant la participation de deux fournisseurs (c'est à dire, un fournisseur qui développe le logiciel du test de pré-délégation et héberge le système de test de pré-délégation, et un autre fournisseur qui prête les services de test de pré-délégation) ?
Oui.
Question 16 : Est-ce que l'ICANN envisagerait la conclusion d'un contrat avec un seul fournisseur pour a) permettre des économies d'échelle et b) avoir un modèle cohérent pour tout ?
L'option d'un seul fournisseur est celle préférée par l'ICANN. Cependant, l'ICANN est prête à considérer plus d'un fournisseur si cela s'avère être une meilleure alternative.
Question 17 : Est-il possible d'exécuter un seul test par fournisseur de services de registre back-end (car cela limiterait l'exigence à environ 80 tests de ce type)?
Le guide de candidature spécifie un test de pré-délégation par opérateur de registre (partie contractante de l'ICANN).
Question 18 : Est-ce que l'ICANN considérera des propositions portant sur un sous-ensemble du test de pré-délégation? Plus spécifiquement : Vu leur nature technique et leur importance, l'ICANN considérerait-elle des propositions qui ne concernent que les composantes DNS et DNSSEC de la requête de propositions?
Non.
Question 19 : L'ICANN a-t-elle des inquiétudes par rapport à des conflits d'intérêt avec d'autres services d'évaluation de candidatures fournis à l'ICANN dans le cadre du programme des nouveaux gTLD ?
Non.
Question 20 : Q.26 : En ce qui concerne l'audit sur place, combien de personnes faut-il prévoir pour effectuer un audit sur place?
Le fournisseur de test de pré-délégation devrait constituer une équipe ayant les compétences requises pour un audit sur place. Il est prévu qu'un faible nombre de tests de ce type sera nécessaire.
Question 21 : Est-ce que l'ICANN pourrait préciser les éléments à examiner dans le cadre d'un audit sur place ?
Le fournisseur de test de pré-délégation devra vérifier la conformité vis-à-vis des critères établis dans la section 5.2 du guide de candidature et les affirmations faites dans la candidature gTLD.
Question 22 : Q.26 : L'ICANN prévoit-elle une augmentation significative du nombre de tests pendant la période du contrat ?
Il est prévu que les tests de pré-délégation soient exécutés à un rythme initial de 20 tests par semaine, avec la possibilité d'augmenter ce rythme jusqu'à 100 par semaine. Tel que décrit dans la Q.26(a), le tarif devra être fourni par test.
Question 23 : R.6 : Est-il acceptable de ne pas mettre en place des authentifications réciproques d'agents mettant en place les tests de pré-délégation si le fournisseur de test de pré-délégation opère dans un environnement de réseau interne/privé?
Non, le système de test de pré-délégation devrait être conçu pour fonctionner dans un environnement ouvert (par exemple, l'Internet public) – l'authentification réciproque et le cryptage sont des exigences.
Question 24 : Est-ce que l'IPv6 est une condition pour les « tests à réaliser sur IPV4 et IPv6 »?
Les tests doivent être réalisés sur IPv6 quand cela est applicable. Il convient de signaler que certains services (par exemple, DNS et Whois) doivent être fournis sur IPv6 (comme établi par la spécification 6 de l'accord sur les nouveaux gTLD).
Question 25 : R.18 : Qu'est-ce que c'est qu'un « contrat gTLD »?
Le contrat gTLD est l' « accord sur les nouveaux gTLD » signé.
Question 26 : R.19 : Quel est le contenu de la note en bas de page nº1 qui manque?
http://www.iana.org/procedures/idn-repository.html
Question 27 : Q.26(b) n'est pas correctement formulée.
« Un test du processus de communication de données d'un dépositaire légal. Il est prévu que l'ICANN exige environ 20 tests au long de la période du contrat »
Question 28 : R.25 : Est-ce que l'ICANN fournira un serveur racine pour le test d'ancre de confiance DNSSEC ?
Non.
Question 29 : R.26 : Est-ce que l'ICANN peut fournir davantage de détails sur les critères d'une déclaration de politique DNSSEC (DPS)?
En vertu de la section 1.3 de la spécification 6 de l'accord de base, la DPS devra être conforme à la prochaine RFC décrivant un cadre DPS (actuellement en version préliminaire https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-dps-framework/), c'est-à-dire qu'elle devra décrire des procédures et des contrôles de sécurité critiques, par exemple, du stockage de matériel de chiffrement, de l'accès et l'utilisation de ses propres clés et de l'acceptation sécurisée du matériel de clé publique des registrants.
Question 30 : Questions concernant des limites.
- Y a-t-il un délai maximum pour qu'une candidature réussisse le test ? Quel est le délai dans lequel une candidature doit compléter ses tests techniques avant la délégation du gTLD à la zone ?
- Si la candidature ne réussit pas le test technique la première fois, combien d'opportunités a-t-elle de le faire avant l'annulation de la procédure de test de pré-délégation ?
- Ou bien, si d'autres tests supplémentaires sont concernés, est-ce que le fournisseur de service de pré-délégation peut faire payer des frais supplémentaires à l'ICANN?
Les candidats devraient se voir accorder un délai raisonnable (à convenir entre le fournisseur sélectionné et l'ICANN) pour corriger des problèmes techniques ou compléter l'information présentée. Si le candidat est incapable de fournir les preuves demandées dans ce délai, le test sera considéré comme non réussi.
Question 31 : Q.5 : Y a-t-il des informations spécifiques exigées concernant les sous-traitants répertoriés ?
Tel que décrit dans la Q.15(a), les participants à l'appel à contributions devront fournir une évaluation de conflit d'intérêts basée sur la liste actuelle des candidats aux nouveaux gTLD.
Question 32 : Si un opérateur TLD échouait à une composante du test de pré-délégation, l'ICANN pourrait-elle préciser le niveau de soutien que le fournisseur du test de pré-délégation est censé lui apporter, outre la répétition du test ?
Le fournisseur du test de pré-délégation est censé fournir au candidat une réponse descriptive pour chaque test échoué, et permettre au candidat d'y apporter des corrections dans un délai raisonnable (à convenir entre le fournisseur choisi et l'ICANN) avant de considérer que le test n'a définitivement pas été réussi.
Question 33 : En ce qui concerne l'exigence d'établir la liste des noms et des adresses unicast IPv4/IPv6 des nœuds anycast, quelles mesures l'ICANN souhaiterait-elle mettre en place si, dans leur fonctionnement normal, l'opérateur TLD ne permet pas que des serveurs individuels dans leurs ensembles anycast puissent être interrogés par des adresses IP publiques autres que l'adresse anycast ?
Si l'opérateur TLD ne permet pas des requêtes du fournisseur du test de pré-délégation vers les adresses unicast de tous les nœuds anycast, le candidat sera tenu de présenter une déclaration d'accessibilité pour tous les nœuds sur lesquels le test ne pourra pas être fait.
Question 34 : Est-ce que l'ICANN pourrait préciser quel sont les éléments d'audit à considérer lors de la révision des tests de chargement d' « auto-certification » ?
Le fournisseur du test de pré-délégation devrait examiner les documents d'auto-certification afin de vérifier qu'ils sont complets, qu'ils sont plausibles et qu'ils sont conformes aux déclarations faites dans la candidature gTLD.
Question 35 : Est-ce que le test du processus de communication de données issues du dépôt de données est focalisé sur la communication des données existantes du dépôt de données du dépositaire légal à l'ICANN ou au fournisseur du test de pré-délégation ?
Le test de communication est focalisé sur la communication de dépôts de données du dépositaire légal de données gTLD au fournisseur du test de pré-délégation.
Question 36 : En ce qui concerne le dépôt de données dans le point 2.3.4.4 ; faut-il que la vérification de la conformité du dépôt de données par rapport aux exigences soit faite avec un logiciel spécifique ?
Non, le fournisseur du test de pré-délégation devrait valider le profil et le format d'un dépôt de données complet et d'un dépôt de donnés progressif. C'est pourquoi ce test ne dépend pas d'un logiciel spécifique.
Question 37 : R.24 : Est-ce que la « vérification que les données peuvent être communiquées dans les 24 heures » fait référence à une révision du manuel des contrats de niveau de service (SLA) entre le fournisseurs de service de dépôt de données et le candidat (tel que fourni par le candidat) ou bien à un test réel qui doit être mis en œuvre par le fournisseur du test de pré-délégation pour assurer que les données sont communiquées et renvoyées conformément aux exigences établies pour le dépôt de données ?
Pour la plupart des cas, l'ICANN espère uniquement la vérification du SLA, mais dans certains cas, l'ICANN peut demander à ce que la capacité réelle de communication de chaque fournisseur de dépôt de données soit vérifiée. Tel qu'indiqué dans la Q.26, l'ICANN envisage environ une vingtaine de tests de ce type pendant la durée du contrat.
Question 38 : Serait-il acceptable de tester uniquement les dépôts de données complets ?
Non, le guide de candidature prévoit aussi bien les dépôts complets que les dépôts progressifs, ce qui implique que tous les deux devront être testés.
Question 39 : R.19 et R.20 : Merci de préciser les critères pour la vérification des tables IDN.
L'objectif principal est de vérifier que les capacités IDN des candidats sont conformes à celles décrites dans les tables IDN fournies. La mise en œuvre de ces tests est largement simplifiée si les tables IDN sont fournies dans un format pouvant être lu par les machines à l'aide d'un programme, mais l'ICANN reconnaît qu'il peut y avoir des tables IDN dans d'autres formats, par exemple, avec des algorithmes de création de variantes plus complexes.
Question 40 : R.13 : L'interface EPP doit être uniquement testée pour les commandes EPP figurant sur la liste ?
Non, l'interface EPP doit être testée pour vérifier que les critères sont conformes aux conditions décrites dans la section 5.2 du guide de candidature gTLD, à savoir « vérifier la conformité aux RFC pertinents (y compris les extensions EPP pour DNSSEC) ».
Question 41 : R.18 : Y a-t-il des tests techniques demandés pour vérifier les extensions EPP des candidats ?
Non.
Question 42 : 2.3.4.1 : Y a-t-il une exigence concernant la vérification de l'interface Web du Whois sur HTTPS ?
Si l'interface web du Whois est fournie sur HTTPS, elle devra être testée.
Question 43 : Q.26 : Est-ce que l' « audit du test de chargement » fait référence à une révision manuelle de la documentation d'auto-certification du candidat ou bien aux tests réels que le fournisseur du test de pré-délégation doit mettre en place indépendamment, afin de valider les déclarations du candidat ?
Q.26 (c,d,e) fait référence aux tests techniques réels de chargement mis en place par le fournisseur du test de pré-délégation. Il est prévu qu'un faible nombre de tests de ce type sera nécessaire.