Skip to main content

Mise à jour de la requête de propositions (RFP) pour consultant du cadre de gestion des risques du DNS – Réponses reçues

Cette page est disponible en:

Le 16 juillet, l'ICANN a publié une requête de propositions pour trouver un consultant expert capable d'aider l'ICANN au développement du cadre de gestion des risques du DNS. L'annonce indiquait que les questions liées à la requête de propositions (RFP) pouvaient être présentées entre le 1er et le 16 août 2012 à 23h59 UTC. La période de présentation de questions sur la RFP est maintenant clôturée. L'ICANN présente les questions reçues ainsi que les réponses dans sa mise à jour, de sorte que toutes les parties intéressées à répondre à la requête de propositions puissent avoir la même information.

La date limite de réception des réponses est le 31 août 2012 à 23h59 UTC. Les réponses peuvent être envoyées à drmf-rfi@icann.org à l'attention de Patrick Jones, du comité de sécurité de l'ICANN.

Questions

Soumission de la proposition

  1. Nous aimerions savoir si vous accepterez pour cette mission des propositions d'un consortium (deux sociétés consultantes) ou si vous cherchez un seul consultant.

    Réponse – Les propositions d'un consortium seront bienvenues. La proposition devrait inclure une description sur la manière dont les parties du consortium travailleraient ensemble et quelle serait leur interaction avec l'ICANN.

Calendrier

  1. Quelle est la période prévue pour le projet, sur la base des réunions passées de l'ICANN, étant donné les temps requis pour les commentaires internes et les commentaires publics ?

    Réponse – Idéalement, l'ICANN devrait pouvoir engager un consultant capable de commencer à travailler dans le projet vers la fin septembre, et pouvant participer d'un panel ouvert à la communauté lors de la réunion de l'ICANN à Toronto, Ontario. Des objectifs spécifiques seront établis dès que le consultant sera engagé, mais le groupe de travail du Conseil souhaite que la version préliminaire du cadre de gestion des risques du DNS soit disponible pour discussion en début décembre 2012, et après les périodes de commentaires publics pour le Conseil de l'ICANN lors de la réunion de l'ICANN à Beijing, Chine, en avril 2013.

  2. Quelle est la durée prévue pour le plan de transition pour compléter le lancement en termes de la disponibilité du personnel de l'ICANN ?

    Réponse – Le personnel de l'ICANN sera disponible et fera le suivi du travail du consultant à travers le projet. Ceci devrait réduire les délais entre le démarrage du projet et l'étape de mise en place de la gestion opérationnelle des risques au sein de l'ICANN.

  3. Quelle est la date de début prévue pour exécuter les activités de RFP ?

    Réponse – Le consultant devrait être disponible pour commencer dès que possible après avoir complété le processus d'embauche. Idéalement, ce travail devrait commencer vers la fin septembre de sorte à avoir le temps suffisant pour démarrer avant la réunion de l'ICANN à Toronto. Le groupe de travail du Conseil aura une session ouverte à la communauté lors de la réunion de l'ICANN, le jeudi 18 octobre ; il est prévu que la participation du consultant à cette session permette d'utiliser ce temps pour interagir avec la communauté.

  4. Quand est-ce que l'ICANN décidera sur l'enchérisseur gagnant ?

    Réponse – L'ICANN pense prendre une décision rapidement, sur la base de la qualité des réponses reçues et du processus interne de sélection. L'ICANN prévoit que la décision sera prise début septembre.

Soutien au personnel

  1. Quelle est la taille prévue de l'équipe interne de l'ICANN chargé de la mise en place de la méthodologie, de l'emplacement géographique et de la diversité du personnel désigné ?

    Réponse – La mise en place du cadre de gestion des risques du DNS sera faite sous la responsabilité de l'équipe de sécurité de l'ICANN ; cependant, elle dépendra de l'expertise du personnel appartenant à d'autres départements, à savoir, le département juridique, les opérations du DNS, IT, les finances, IANA, entre autres. Le personnel de l'ICANN est distribué dans le monde entier, bien que l'équipe de sécurité soit actuellement répartie entre la côte est et la côte ouest des États-Unis.

  2. Quelle est la composition du personnel de l'ICANN dédié à l'exécution des activités de gestion des risques (nombre, hiérarchie, etc.) ?

    Réponse –L'équipe de sécurité de l'ICANN fournit du personnel de soutien au comité des risques du Conseil et au groupe de travail du cadre de la gestion des risques du DNS du Conseil. Il y a du personnel de l'ICANN appartenant à l'équipe juridique qui fournit le soutien au Conseil et qui participe de l'équipe exécutive à travers le consultant juridique de l'ICANN.   L'équipe exécutive fait le suivi des activités de gestion, et des membres individuels du personnel font le suivi des risques du département.

  3. Quel est l'engagement des FTE (employés à temps plein) vis-à-vis de la disponibilité de l'ICANN pour contribuer aux travaux du projet ?

    Réponse – L'équipe de sécurité de l'ICANN fournira du personnel de soutien pour travailler avec le consultant dans ce projet.

Préparation de documents

  1. La requête de propositions indique que le consultant expert présentera un rapport au groupe de travail du cadre de gestion des risques du DNS du Conseil d'administration et à la communauté de l'ICANN. Les résultats atteints par le consultant expert seront-ils partagés textuellement avec la communauté comme commentaires publics, ou l'ICANN ou le consultant expert vont-ils préparer des résumés pour les partager publiquement ?

    Réponse – Le consultant devrait assumer que les résultats atteints pour ce projet seront partagés textuellement avec la communauté comme des documents publics. Le consultant devrait également fournir les résumés exécutifs, le cas échéant, pour que la communauté comprenne le cadre de risques une fois qu'il sera développé.

Listes de tâches pour le cadre de gestion des risques du DNS

  1. Tâche 2 – Cadre de risques – L'ICANN a-t-elle adopté auparavant un cadre de gestion des risques ? De quel cadre s'agit-il ?

    Réponse – Oui, l'ICANN a une cadre de gestion des risques interne à l'entreprise.

  2. Tâche 2 – Cadre des risques – L'ICANN a-t-elle des cadres susceptibles d'être adoptés dans son organisation ?

    Réponse – L'ICANN serait ouverte à des approches pratiques et applicables sur la gestion des risques du DNS.

  3. Tâche 2 – Cadre des risques – L'ICANN a-t-elle un cadre de gestion des risques d'entreprise (Enterprise Risk Management - ERM) avec lequel serait aligné le cadre de gestion des risques de sécurité ?

    Réponse – L'ICANN a un cadre interne de gestion des risques d'entreprise. L'ICANN serait ouverte à des approches pratiques et applicables sur la gestion des risques du DNS.

  4. Tâche 2 – Cadre des risques – L'ICANN prendrait-elle en considération de baser son cadre de gestion des risques sur des pratiques et des cadres acceptés mondialement comme par exemple le Risque IT et COBIT5 pour la sécurité ?

    Réponse – COBIT est essentiellement un cadre de processus de la technologie de l'information. Le consultant devrait considérer que le centre du cadre de gestion des risques n'a pas seulement trait à la technologie de l'information mais, en général, aux risques du DNS pour l'ICANN en tant qu'organisation. COBIT5 et Risque IT peuvent servir comme exemple mais ne devraient pas être considérés la seule base du cadre proposé par le consultant.

  5. Tâche 2 – Cadre des risques – La liste des résultats n'articule pas clairement l'exigence de la gouvernance des risques (par ex., l'appétit et la tolérance aux risques, les responsabilités de la gestion des risques IT, la prise de conscience et communication, la culture des risques). S'agit-il aussi d'un résultat souhaité ?

    Réponse – Les recommandations du consultant sur les mécanismes permettant d'articuler clairement l'exigence de la gouvernance des risques seraient bienvenues dans le contexte des risques du DNS.

  6. Tâche 3 – Construire le consensus – Quelle est la durée prévue du cycle de commentaires publics ?

    Le processus du cycle de commentaires publics de l'ICANN est décrit à http://www.icann.org/en/news/public-comment. La durée totale du cycle des commentaires publics dépendra si les commentaires sont reçus pendant la période initiale de commentaires, ou s'il sera nécessaire de prévoir une période de réponse aux commentaires. Le groupe de travail estime que les commentaires publics auront lieu au début 2013, bien que cela puisse faire l'objet de changements qui dépendront d'une série de facteurs.

  7. Tâche 3 – Construire le consensus – Le groupe de travail présentera-t-il la révision et les commentaires avant le cycle des commentaires publics ? Y aura-t-il l'occasion de faire des révisions au cadre avant sa publication pour commentaires publics, sur la base du feedback du groupe de travail ?

    Réponse - Oui

  8. Tâche 3 – Construire le consensus – Comment le groupe de travail fera-t-il pour mesurer si le consensus a été atteint ?

    Réponse – Le groupe de travail cherche un cadre de gestion des risques du DNS applicable et cela est accepté par la communauté car les objectifs sont normalement atteints dans cette requête de propositions.

  9. Tâche 3 – Construire le consensus – La requête de propositions indique que le consultant expert « aidera le personnel et le groupe de travail à construire le consensus pour soutenir le cadre de gestion des risques au sein de l'ICANN (l'organisation et la communauté) ». Est-ce que le consultant expert mènera une interaction directe avec la communauté ou son interaction avec la communauté aura lieu seulement à travers le personnel de l'ICANN ?

    Réponse – Le groupe de travail du Conseil souhaite que le consultant participe de la session ouverte du groupe de travail lors de la réunion de l'ICANN à Toronto le 18 octobre 2012. Cette réunion permettra d'une part aux participants intéressés de la communauté de poser des questions et d'autre part au consultant de s'engager avec les participants de la réunion. Il est aussi prévu que le consultant mène une interaction directe avec les experts de la communauté en matière de développement du cadre des risques.

  10. Tâche 4 – Cycle du risque – La requête de propositions indique que la tâche 4 fait partie de « la phase potentielle II ». Quels sont les facteurs déterminants pour que la « phase II » ait lieu ?

    Le Conseil et les cadres supérieurs de l'ICANN détermineront les prochaines démarches du processus avant de délivrer la phase 1 du cadre de gestion des risques du DNS, y compris le calendrier et la faisabilité de la Phase II tel que décrit dans la requête de propositions. La réponse à la requête de propositions peut inclure une description de la manière dont le consultant pourrait considérer les objectifs dans la Phase II.

  11. Tâche 4 – Cycle des risques – La requête de propositions devrait-elle inclure les estimations des activités potentielles de la Phase II ?

    Réponse – Oui. Bien qu'ils puissent être présentés à haut niveau, les détails précis des étapes de la Phase II ne sont pas requis pour la Phase I ; ils peuvent cependant être utiles pour que l'ICANN comprenne la méthodologie proposée par le consultant.

  12. Tâche 4 – Cycle du risque – Quels sont les outils utilisés actuellement par l'ICANN pour identifier, documenter, gérer et surveiller les risques ?

    Réponse – L'ICANN fait le suivi des risques au sein de ses départements et fournit aussi des mises à jour régulières sur les domaines clés de risques à travers le comité du Conseil pertinent, à savoir, le comité des risques, le comité des finances et le comité IANA du Conseil d'administration, entre autres. Le programme des nouveaux gTLD présente un mécanisme de rapport des risques séparés à travers le comité des nouveaux gTLD du Conseil d'administration.

  13. Tâche 4 – L'ICANN peut-elle se servir de solutions technologiques en matière de gouvernance, gestion des risques et conformité (GRC) ?

    Réponse – L'équipe de conformité de l'ICANN est en train de développer des outils pour aider à la gestion des risques en matière de conformité. L'ICANN recevrait avec plaisir les suggestions concernant les solutions techniques pour que le cadre de gestion des risques du DNS soit pratique et applicable une fois livré par le consultant.

  14. Tâche 4 – Cycle des risques – L'ICANN doit-elle identifier les risques préalablement identifiés et documentés dans son organisation ? Y a-t-il d'autres activités de risque au sein de l'organisation ? Quelles sont ces activités ?

    Réponse – L'ICANN organise des réunions régulières de son comité des risques et utilise les risques de gestion préalablement identifiés et documentés pour gérer les risques au sein de l'organisation.

  15. Tâche 4 – Cycle des risques – L'ICANN aimerait-elle inclure dans ses objectifs une bibliothèque du processus de base, des risques et du contrôle pour les risques clés de sécurité ?

    Réponse – Les tâches principales de ce contrat sont décrites dans la requête de propositions. Des informations supplémentaires devraient soutenir la délivrance du cadre de gestion des risques du DNS pour l'organisation.

  16. Tâche 4 – Cycle des risques – En abordant le plan des risques (stratégie de réponse aux risques) l'ICANN veut-elle inclure des exemples de procédures de test pour valider l'efficacité du plan des risques en plus de surveiller les procédures des indicateurs clés ?

    Réponse – Oui. Cela peut être inclus si le cadre est supporté.

  17. Tâche 4 – Cycle des risques – L'ICANN voudrait-elle de l'aide pour concevoir et développer la surveillance et les rapports de tableau de bord ?

    Réponse – La conception et la surveillance des rapports de tableau de bord contribueraient à la mise en place et à l'exécution d'un cycle initial du cadre comme une partie de la Phase II. Ces suggestions pourraient être incluses dans la requête de propositions mais elles ne sont pas requises à ce stade.

Généralités

  1. Quel sont les critères clés de sélection utilisés par l'ICANN pour attribuer cette requête de propositions ?

    Réponse – L'ICANN fera une évaluation des réponses reçues afin d'identifier un consultant expert pouvant appliquer des méthodologies de risques aux seuls aspects du système de noms de domaine, y compris sa nature internationale et sa participation multipartite. L'ICANN a besoin d'un consultant capable de livrer un produit de qualité qui sera soumis à l'examen et à l'analyse de la communauté dans une période de temps relativement limitée.


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."