Skip to main content
Resources

Résolutions du Conseil d'administration approuvées | Réunion ordinaire du Conseil d'administration de l'ICANN

Cette page est disponible en:

Ce document a été traduit dans plusieurs langues dans un but purement informatif. Le texte original faisant foi (en anglais) peut être consulté sur : https://www.icann.org/resources/board-material/resolutions-2017-10-29-en

  1. Ordre du jour approuvé :
    1. Examen de la demande de réexamen 17-4
  2. Ordre du jour principal :
    1. Demande de nouvelles informations ou d'informations supplémentaires au Comité consultatif gouvernemental concernant l'avis sur les candidatures d'Amazon
    2. Demande de report de 180 jours de la mise en conformité à la politique de consensus relative au WHOIS détaillé
    3. Perfectionnement du processus de révision de similarité de chaînes dans le cadre de la procédure accélérée ccTLD IDN

 

  1. Ordre du jour approuvé :

    1. Examen de la demande de réexamen 17-4

      Attendu que, dotgay LLC et DotMusic Limited (les requérants) ont déposé la demande de réexamen 17-4 (la demande 17-4) contestant la réponse de l'organisation ICANN à la demande de documents des requérants conformément à la politique de divulgation d'informations documentaires eu égard à la révision du processus d'évaluation de la priorité communautaire (CPE).

      Attendu que, le Comité du Conseil d'administration chargé des mécanismes de responsabilité (BAMC) a précédemment déterminé que la demande 17-4 était suffisamment fondée et a envoyé la demande au médiateur à des fins d'examen et de prise en compte conformément au chapitre 4 articles 4.2(j) et (k) des statuts constitutifs de l'ICANN.

      Attendu que, le médiateur s'est abstenu de prendre part aux discussions relatives à cette question conformément au chapitre 4 article 4.2(l)(iii) des statuts constitutifs.

      Attendu que, le BAMC a évalué le bien-fondé de la demande 17-4 et de l'ensemble des supports y afférents, et a recommandé de rejeter la demande 17-4 en raison du fait qu'elle ne constitue pas un fondement valable de réexamen, et le Conseil d'administration accepte cette recommandation.

      Attendu que, le Conseil d'administration a également pris en compte la réfutation des requérants à la recommandation du BAMC relative à la demande 17-4 et estime que la réfutation ne constitue pas elle non plus un argument ou un motif justifiant le réexamen.

      Il est résolu (2017.10.29.01) que le Conseil d'administration adopte la recommandation du BAMC relative à la demande 17-4 [PDF, 273 KB].

      Fondements de la résolution 2017.10.29.01

      1. Bref récapitulatif

        Les requérants dotgay LLC (dotgay) et DotMusic Limited (DotMusic) ont respectivement soumis des candidatures communautaires pour .GAY et .MUSIC ; ces deux candidatures ont été soumises à la CPE et n'ont pas été retenues. En octobre 2015, dotgay a demandé le réexamen de la CPE (la demande 15-21),1 demande rejetée par le Comité de gouvernance du Conseil d'administration (BGC)2.3 En février 2016, dotgay a demandé le réexamen du rejet par le BGC de la demande 15-21 (voir demande 16-3).4 En février 2016, DotMusic a demandé le réexamen de la décision de la CPE et a demandé d'approuver la candidature de DotMusic (la demande 16-5).5

        Par la suite, le Conseil d'administration de l'ICANN a enjoint au président-directeur général, ou à son ou ses représentants, de mener une révision du processus en vertu duquel l'organisation ICANN a interagi avec le fournisseur CPE (la révision du processus CPE). Le BGC a ensuite décidé que la révision du processus CPE devrait également inclure les supports de référence sur lesquels le fournisseur CPE s'est fondé pour les évaluations, qui font l'objet des demandes de réexamen en cours relatives à la CPE. Le BGC a suspendu les huit demandes de réexamen en cours relatives à la CPE, dont les demandes 16-3 et 16-5, jusqu'à l'achèvement de la révision du processus CPE.

        Le 10 juin 2017, les requérants ont soumis une demande DIDP conjointe afin d'obtenir des documents et des informations liés à la révision du processus CPE, les requérants ayant déjà cherché à obtenir certains de ces documents et informations lors de précédentes demandes DIDP. (Voir la demande DIDP conjointe jointe en tant qu'annexe E aux supports de référence.) L'organisation ICANN a répondu (la réponse à la demande DIDP conjointe jointe en tant qu'annexe F aux supports de référence) que, sauf pour certains documents qui étaient soumis à des conditions précises de non-divulgation prévues dans la DIDP (les conditions de non-divulgation), tous les autres documents requis avaient été publiés et identifiés suite aux demandes DIDP précédentes des requérants.6 (Voir id.) La réponse à la demande DIDP conjointe comprenait des liens vers les réponses aux demandes DIDP précédentes, qui à leur tour identifiaient et fournissaient des liens vers des documents requis accessibles au public. (Voir id. à la page 2.) La réponse à la demande DIDP conjointe indiquait également que deux points (les points 2 et 4) ne cherchaient pas à obtenir des informations documentaires existant au sein de l'ICANN. (Voir id.) De plus, la réponse à la demande DIDP conjointe précisait que l'organisation ICANN avait évalué des documents requis soumis à des conditions de non-divulgation afin de déterminer si l'intérêt public lié à leur divulgation l'emportait sur le préjudice découlant de cette divulgation, et qu'elle avait déterminé qu'en aucun cas l'intérêt public lié à la divulgation des informations l'emportait sur le préjudice potentiel découlant de la divulgation des documents. (Voir id. à la page 3.)

        Les requérants ont ensuite déposé une demande de réexamen 17-4 (la demande 17-4) contestant la réponse à la demande DIDP conjointe. (Voir demande 17-4 jointe en tant qu'annexe A aux supports de référence.) Pour les requérants, le réexamen de la réponse à la demande DIDP conjointe est justifié car l'organisation ICANN n'a pas respecté les valeurs fondamentales de l'ICANN, les politiques de divulgation d'informations documentaires définies et les statuts constitutifs eu égard au traitement non-discriminatoire, à la transparence et à la responsabilité. (Voir id. au point §8 de la page 21.)

        Le BAMC a examiné la demande 17-4 ainsi que l'ensemble des supports de référence et a recommandé au Conseil d'administration de rejeter ladite demande en raison du fait qu'elle ne constitue pas un fondement valable de réexamen pour les motifs indiqués dans la recommandation du BAMC relative à la demande de réexamen 17-4 (la recommandation du BAMC), recommandation qui a été prise en compte et est jointe aux présentes. (Voir la recommandation du BAMC [PDF, 273 KB] jointe en tant qu'annexe D aux supports de référence.)

        Le 26 octobre 2017, les requérants ont soumis une réfutation à la recommandation du BAMC (la réfutation) conformément au chapitre 4 article 4.2(q) des statuts constitutifs de l'ICANN. (Voir la réfutation jointe en tant qu'annexe G aux supports de référence.) Selon les requérants : (1) la demande 17-4 relève du processus de réexamen car « le processus de réexamen permet de réexaminer une action ou une inaction, pas seulement le processus utilisé afin de mener l'action » ; (2) « la DIDP est liée aux engagements et aux valeurs fondamentales de l'organisation ICANN qui exigent une certaine transparence » ; et (3) l'organisation ICANN n'a pas respecté ses engagements en matière de transparence, de responsabilité et d'équité dans sa réponse à la demande DIDP conjointe. (Voir id.)

      2. Faits et recommandation

        L'ensemble des faits sont exposés dans la recommandation du BAMC [PDF, 273 KB] que le Conseil d'administration a examinée et prise en compte et qui est jointe aux présentes.

        Le 11 octobre 2017, le BAMC a recommandé de rejeter la demande 17-4 en raison du fait qu'elle ne constitue pas un fondement valable de réexamen pour les motifs indiqués dans la recommandation du BAMC [PDF, 273 KB] que le Conseil d'administration a examinée et qui est jointe aux présentes.

        Le 26 octobre 2017, les requérants ont soumis une réfutation à la recommandation du BAMC conformément au chapitre 4 article 4.2(q) des statuts constitutifs de l'organisation ICANN, réfutation que le Conseil d'administration a également examinée.

      3. Problématiques

        Les problématiques se posant sont les suivantes 7:

        • Déterminer si la réponse de l'organisation ICANN à la demande DIDP conjointe a respecté les politiques de l'ICANN.
        • Déterminer si la réponse de l'organisation ICANN à la demande DIDP conjointe a respecté ses valeurs fondamentales, sa mission et ses engagements.
      4. Normes applicables pour évaluer les demandes de réexamen

        Les dispositions du chapitre 4 articles 4.2(a) et (c) des statuts constitutifs de l'ICANN permettent à toute entité de soumettre une demande de réexamen ou de révision d'une action ou d'une inaction de l'ICANN si elle a été lésée par :

        1. au moins une action ou inaction du Conseil d'administration ou du personnel qui serait contraire à la mission, aux engagements, aux valeurs fondamentales et/ou aux politiques établies de l'ICANN ;
        2. au moins une action ou inaction du Conseil d'administration ou du personnel adoptée ou dont l'adoption a été refusée sans tenir compte d'informations importantes, sauf si le requérant n'a pas soumis ces informations, alors qu'il aurait pu le faire, au Conseil d'administration ou au personnel à des fins d'examen au moment où l'action ou l'inaction a été décidée ; ou
        3. au moins une action ou inaction du Conseil d'administration ou du personnel décidée sur la base d'informations fausses ou inexactes.

        (Chapitre 4 §§ articles 4.2(a) et (c) des statuts constitutifs de l'ICANN, 22 juillet 2017.) Conformément au chapitre 4 article 4.2(k) des statuts constitutifs, si le BAMC estime que la demande est suffisamment fondée, la demande est envoyée au médiateur à des fins d'examen et de prise en compte. (Voir id. au point § 4.2(l).) Si le médiateur s'abstient de prendre part aux discussions relatives à cette question, le BAMC examine la demande sans intervention du médiateur et transmet une recommandation au Conseil d'administration. (Voir id. au point § 4.2(l)(iii).) Le requérant peut envoyer une réfutation à la recommandation du BAMC à condition que la réfutation : (i) « se limite à remettre en question ou contredire les questions soulevées dans la recommandation du BAMC ; et (ii) ne comporte pas de nouvelles données venant étayer un argument présenté dans la demande de réexamen originale du requérant et que le requérant aurait pu fournir lorsqu'il a soumis sa demande de réexamen originale ». (Voir id. au point§ 4.2(q).) Il convient de refuser une demande de réexamen d'une action ou inaction de l'ICANN si le BAMC estime et le Conseil d'administration détermine que la partie requérante n'a pas satisfait aux critères de réexamen définis dans les statuts constitutifs. (Voir id. aux points § 4.2(e)(vi), (q), (r).)

      5. Analyse et fondements

        Le Conseil d'administration a dûment examiné et pris en compte la demande 17-4 ainsi que l'ensemble des supports pertinents, dont la recommandation du BAMC. Le Conseil d'administration estime que l'analyse contenue dans la recommandation du BAMC [PDF, 273 KB], jointe aux présentes, a été menée avec sérieux. Le Conseil d'administration a également tenu compte de la réfutation des requérants à la recommandation du BAMC. Le Conseil d'administration estime que la réfutation ne présente aucun argument ou fait justifiant le réexamen.

        1. La réponse de l'organisation ICANN à la demande DIDP conjointe a respecté les politiques et procédures établies.

          Le BAMC est arrivé à la conclusion et le Conseil d'administration est d'accord avec le fait que la réponse à la demande DIDP conjointe a respecté les politiques et procédures applicables. (Recommandation du BAMC [PDF, 273 KB], pages 16-27.) En répondant à une demande de documents soumise conformément à la DIDP, l'organisation ICANN respecte le « processus de réponse aux demandes relevant de la politique de divulgation d'informations documentaires (DIDP) de l'ICANN » (le processus de réponse DIDP). (Voir le processus de réponse DIDP [PDF, 59 KB].) Le processus de réponse DIDP prévoit qu'« en cas de dépôt d'une demande DIDP, le personnel de l'ICANN procède à un examen de la demande et identifie les informations documentaires faisant l'objet de la demande . . ., interroge . . . le ou les membres du personnel concernés et recherche activement les documents requis dans la demande DIDP. » (Id.) Après vérification de la pertinence des documents recueillis, un examen est mené afin de déterminer si les documents jugés pertinents dans le cadre de la demande sont soumis aux conditions de non-divulgation prévues sur la page web consacrée à la DIDP (https://www.icann.org/resources/pages/didp-2012-02-25-en). Si c'est le cas, un nouvel examen est mené afin de déterminer si, en l'espèce, l'intérêt public lié à la divulgation des informations documentaires l'emporte sur le préjudice potentiel découlant de ladite divulgation. (Voir le processus de réponse DIDP [PDF, 59 KB].)

          Tel que requis par le processus de réponse DIDP, la réponse à la demande DIDP conjointe a précisé que, sauf pour certains documents qui étaient soumis à des conditions de non-divulgation, tous les autres documents requis avaient été publiés et identifiés suite aux demandes DIDP précédentes des requérants. (Voir la réponse à la demande DIDP conjointe [PDF, 214 KB], page 2). Pour les points 1 et 3, l'organisation ICANN a déterminé que l'ensemble des informations documentaires requises avaient déjà été publiées sur le site web de l'ICANN et fournies aux requérants suite à de précédentes demandes DIDP. (Voir id. au point 2.) Les réponses DIDP à ces demandes ont identifié et fourni les liens vers 21 documents accessibles au public et vers des sites web regroupant des documents qui contiennent des informations requises par les points 1 et 3. (Voir id.) La réponse à la demande DIDP conjointe indiquait également que deux points (les points 2 et 4) ne cherchaient pas à obtenir des informations documentaires existant au sein de l'ICANN. (Voir id.) En dépit de cette exigence, l'organisation ICANN a fourni d'importantes informations correspondant aux points 2 et 4 dans le rapport d'étape et dans un précédent rapport d'étape sur la révision du processus CPE, et a fourni des liens vers ces rapports. (Voir id. aux points 2-3.) De plus, la réponse à la demande DIDP conjointe indiquait que des documents requis aux points 2 et 4 étaient soumis à certaines conditions de non-divulgation identifiées. (Voir id.) La réponse à la demande DIDP conjointe indiquait aussi que l'organisation ICANN avait évalué des documents requis soumis à des conditions de non-divulgation, tel que requis, et avait déterminé qu'en aucun cas l'intérêt public lié à la divulgation des informations l'emportait sur le préjudice potentiel découlant de la divulgation des documents. (Voir id. au point 3.)

          Pour les requérants, un réexamen est justifié car la réponse de l'organisation ICANN aux points 1 à 4 n'a pas respecté les valeurs fondamentales de l'ICANN, les politiques de divulgation d'informations documentaires définies et les statuts constitutifs eu égard au traitement non-discriminatoire, à la transparence et à la responsabilité. (Voir la demande 17-4, § au point 8, page 21.) De plus, les requérants estiment que la décision de l'organisation ICANN quant à l'applicabilité des conditions de non-divulgation spécifiques en réponse aux points 2 et 4 justifie un réexamen car il « est dans l'intérêt public de divulguer » ces documents. (Id. au point § 8, page 22.)

          Le BAMC a déterminé et le Conseil d'administration est d'accord avec le fait que la position des requérants est infondée car la réponse de l'organisation ICANN à la demande DIDP a bel et bien respecté les politiques et procédures établies. (Voir la recommandation du BAMC [PDF, 273 KB], pages 16-27.) Les requérants ne prétendent pas que la réponse à la demande DIDP conjointe est contraire au processus de réponse DIDP et ne fournissent pas non plus d'informations précisant la mesure dans laquelle la réponse de l'organisation ICANN à la demande DIDP conjointe ne respecte pas la mission, les engagements ou les valeurs fondamentales de l'ICANN. (Voir id.) Le BAMC conclut également et le Conseil d'administration accepte le fait que l'organisation ICANN a respecté le processus DIDP en évaluant les documents requis soumis à des conditions de non-divulgation, tel que requis, et a déterminé qu'en aucun cas l'intérêt public lié à la divulgation des informations l'emportait sur le préjudice potentiel découlant de la divulgation des documents. (Voir id. aux points 21-26.) Même si les requérants peuvent estimer que l'organisation ICANN aurait dû exercer son pouvoir discrétionnaire différemment, cela ne justifie pas un réexamen.

        2. Les références non vérifiées des requérants aux engagements et valeurs fondamentales de l'ICANN ne justifient pas un réexamen de la réponse à la demande DIDP conjointe.

          Pour les requérants, la réponse de l'organisation ICANN à la demande DIDP conjointe n'a pas respecté les engagements et valeurs fondamentales suivants : chapitre 1 articles 1.2(a), 1.2(a)(v), 1.2(a)(vi) et chapitre 3 article 3.1 des statuts constitutifs de l'ICANN. (Voir la demande 17-4, § au point 6, pages 5-7.) Toutefois, comme le soulignent le BAMC et le Conseil d'administration, les requérants ne précisent ni le lien entre ces engagements et valeurs fondamentales et la réponse à la demande DIDP conjointe en cause dans la demande 17-4, ni la mesure dans laquelle l'organisation ICANN n'aurait pas respecté ces engagements et valeurs fondamentales. (Voir la recommandation du BAMC [PDF, 273 KB], pages 26-27.) Ainsi, les requérants n'ont pu établir de fondements au réexamen via leur liste d'engagements et de valeurs fondamentales.

        3. La réfutation ne présente aucun argument ou fait justifiant le réexamen.

          Le Conseil d'administration a examiné la réfutation des requérants et estime qu'ils n'ont pas fourni de nouveaux arguments ou faits justifiant le réexamen.

          La réfutation fait valoir ce qui suit : (1) la demande 17-4 relève du processus de réexamen car « le processus de réexamen permet de réexaminer une action ou une inaction, pas seulement le processus utilisé afin de mener l'action » ; (2) « la DIDP est liée aux engagements et aux valeurs fondamentales de l'organisation ICANN qui exigent une certaine transparence » ; et (3) l'organisation ICANN n'a pas respecté ses engagements en matière de transparence, de responsabilité et d'équité dans sa réponse à la demande DIDP conjointe. (Voir la réfutation.)

          Concernant la première revendication, le Conseil d'administration a examiné la demande 17-4, l'ensemble des supports pertinents, la recommandation du BAMC ainsi que la réfutation et estime que le réexamen n'est pas justifié. Le processus de demande de réexamen permet aux requérants de demander le réexamen « d'une action ou inaction de l'organisation ICANN s'ils ont été lésés par… au moins une action ou inaction du Conseil d'administration ou du personnel contraire à la mission, aux engagements, aux valeurs fondamentales et/ou aux politiques établies de l'ICANN. » (Chapitre 4 article 4.2(c)(i) des statuts constitutifs de l'ICANN.) Il convient de procéder au réexamen si le requérant prouve que l'action ou l'inaction est contraire « à la mission, aux engagements, aux valeurs fondamentales et/ou aux politiques établies de l'ICANN. » (Id. ; voir aussi, par exemple, la décision du Conseil d'administration sur la demande 17-3, https://www.icann.org/resources/board-material/resolutions-2017-09-23-en#2.b ; la décision du Conseil d'administration sur la demande 17-1, https://www.icann.org/resources/board-material/resolutions-2017-06-24-en#2.d.)8 Une demande de réexamen qui conteste les conséquences d'une action ou inaction de l'organisation ICANN sans autres pièces justificatives que le mécontentement du requérant ne peut faire l'objet d'un réexamen. De même, une demande de réexamen qui ne précise pas en quoi l'action ou l'inaction contestée est contraire à la mission, aux engagements, aux valeurs fondamentales et/ou aux politiques établies de l'ICANN ne peut aboutir.

          Pour les requérants, « les demandes de réexamen donnent l'occasion de réexaminer une action ou inaction ». (Réfutation, page 3.) C'est exactement ce qui s'est produit en l'espèce. En effet, malgré l'incapacité des requérants à prouver que l'action ou l'inaction de l'organisation ICANN est contraire à sa mission, à ses engagements, à ses valeurs fondamentales et/ou à ses politiques établies, le BAMC a évalué la réponse à la demande DIDP conjointe afin de déterminer si une telle violation s'était effectivement produite. Le BAMC conclut et le Conseil d'administration accepte le fait que l'action prévue par l'organisation ICANN dans la réponse était conforme à sa mission, à ses engagements, à ses valeurs fondamentales et à ses politiques établies. (Recommandation du BAMC, pages 16-27.)

          Deuxièmement, les requérants font valoir que « l'ICANN doit respecter ses engagements et valeurs fondamentales lors du processus DIDP » car « la DIDP est clairement liée à ces engagements et valeurs fondamentales ». (Réfutation, pages 4-5.) Toutefois, la réponse à la demande DIDP conjointe respectait bien les engagements et valeurs fondamentales de l'organisation ICANN. La DIDP met en œuvre les engagements et les valeurs fondamentales de l'ICANN promouvant la transparence et la responsabilité en définissant une procédure via laquelle les documents relatifs aux opérations de l'organisation ICANN et en possession, sous la garde ou sous le contrôle de l'organisation ICANN sont mis à la disposition du public à moins qu'une raison impérieuse en exige la confidentialité. (Voir la DIDP, https://www.icann.org/resources/pages/didp-2012-02-25-en). Mais ni la DIDP ni les engagements et les valeurs fondamentales de l'organisation ICANN promouvant la transparence et la responsabilité n'obligent l'organisation ICANN à rendre public tout document en sa possession. Tel que l'a indiqué en début d'année le panel du processus de révision indépendante pour l'affaire Amazon EU S.A.R.L. v. ICANN :

          En dépit de l'obligation de transparence de l'ICANN, les statuts constitutifs de l'ICANN et ses pratiques en matière de publication reconnaissent qu'il existe des cas dans lesquels des informations non publiques, par exemple des communications internes du personnel intéressant les processus délibératifs de l'ICANN,. . . peuvent contenir des informations faisant l'objet d'une protection adéquate contre toute divulgation.

          (Amazon EU S.A.R.L. v. ICANN, cas de l'ICDR n° 01-16-000-7056, ordonnance de procédure (7 juin 2017), page 3.) Les statuts constitutifs de l'organisation ICANN tâchent de concilier des intérêts contradictoires tels que la transparence et le respect de la vie privée en précisant que « dans le cas où une valeur fondamentale doit être conciliée avec une autre valeur fondamentale potentiellement concurrentielle, cette conciliation doit donner la priorité à une politique élaborée via le processus ascendant multipartite ou autrement servir au mieux la mission de l'ICANN. » (Chapitre I article 1.2(c) des statuts constitutifs de l'ICANN.) La DIDP prévoit un test de conciliation des impératifs liés au respect de la vie privée, tels que le privilège et la protection du processus délibératif, qui soutiennent les valeurs fondamentales de l'organisation ICANN consistant à mener des activités dans un souci d'efficacité et d'excellence et à « s'efforcer à parvenir à un équilibre raisonnable entre les intérêts des différentes parties prenantes tout en évitant la capture », et de la valeur fondamentale de transparence. (Id. aux articles 1.2(b)(v) et 1.2(b)(vii).) Ainsi, l'organisation ICANN peut exercer de façon adéquate son pouvoir discrétionnaire, conformément à la DIDP, afin de décider que certains documents ne peuvent être divulgués sans porter atteinte à son obligation de transparence.

          Troisièmement, les requérants font valoir que la réponse à la demande DIDP conjointe est contraire aux engagements et aux valeurs fondamentales de l'ICANN promouvant la transparence, l'équité et la responsabilité. (Réfutation, pages 9-10.) Le Conseil d'administration estime que ces arguments ne sont pas fondés.

          Quant à l'obligation de transparence de l'ICANN, les requérants considèrent que l'organisation ICANN aurait dû divulguer tous les documents requis, ou au moins « identifier les documents soumis à des conditions de non-divulgation et préciser comment les conditions de non-divulgation s'appliquent. » (Id. à la page 6.) Tel que vu précédemment, l'organisation ICANN a respecté les politiques et procédures établies, dont l'obligation de transparence de l'ICANN, en indiquant que certains des documents requis étaient soumis à des conditions de non-divulgation DIDP. De plus, le Conseil d'administration estime que la réponse au processus de demande DIDP conjointe n'impose pas à l'organisation ICANN d'identifier la condition de non-divulgation applicable à chaque document individuel non communiqué ; en effet, une telle exigence ferait peser une charge excessive sur l'ICANN. En l'espèce, le BAMC a suffisamment expliqué la mesure dans laquelle les conditions de non-divulgation s'appliquaient aux documents qui, selon l'organisation ICANN, ne devaient pas être divulgués. Plus précisément, conformément à la réponse au processus de demande DIDP conjointe, le BAMC a expliqué que les supports requis comprenaient des propositions internes, des documents susceptibles de compromettre l'intégrité du processus délibératif et de prise de décision par rapport à la révision du processus CPE, et des documents soumis au secret professionnel ou autres privilèges. (Recommandation du BAMC, pages 23-24.) Enfin, les requérants n'ont pas démontré que l'organisation ICANN n'avait pas respecté la DIDP ou que la réponse à la demande DIDP conjointe était contraire aux engagements et aux valeurs fondamentales de l'ICANN promouvant la transparence, l'équité et la responsabilité.

          Les requérants estiment également que les engagements et les valeurs fondamentales de l'ICANN promouvant la transparence et l'équité imposaient à l'organisation ICANN de divulguer les supports requis même si certaines conditions de non-divulgation s'appliquaient car la révision du processus CPE est « importante pour les requérants » et d'autres, car « le public est clairement intéressé » par les documents requis, et car les requérants ont le sentiment que « le risque lié à la divulgation des documents est faible ». (Réfutation, pages 6-8.) L'« intérêt public » n'est pas déterminé par le fait qu'une entité soit « intéressée » ou non par un sujet donné mais plutôt par le fait qu'une action ait été oui ou non prise dans l'« intérêt public » global. En outre, la DIDP permet à l'organisation ICANN d'exercer son pouvoir discrétionnaire afin de déterminer si, « en l'espèce, . . . l'intérêt public lié à la divulgation des informations l'emporte sur le préjudice potentiel découlant de ladite divulgation ». (Page web de la DIDP, https://www.icann.org/resources/pages/didp-2012-02-25-en.)

          Tel qu'indiqué dans la réponse à la demande DIDP conjointe, l'organisation ICANN a évalué les documents soumis à des conditions de non-divulgation afin de déterminer si l'intérêt public (y compris les impératifs de transparence et d'équité) lié à la divulgation desdits documents l'emportait sur le préjudice potentiel découlant de ladite divulgation, et est arrivée à la conclusion qu'en l'espèce l'intérêt public ne justifiait pas le préjudice qu'entraînerait la divulgation. (Voir la réponse à la demande DIDP conjointe, pages 2-3.) Tel qu'indiqué précédemment, les requérants estiment que l'organisation ICANN aurait dû exercer différemment son pouvoir discrétionnaire, mais cet argument ne constitue pas un fondement valable de réexamen car les requérants n'ont pas prouvé que l'organisation ICANN avait violé, de quelque façon que ce soit, la DIDP.

          Les requérants estiment également que l'ICANN a bloqué la possibilité d'obtenir des informations supplémentaires relatives à la révision du processus CPE, ce qui va manifestement à l'encontre de son propre engagement et de la valeur fondamentale de transparence. (Réfutation, page 7.) De même, les requérants prétendent que l'organisation ICANN « a limité . . . l'accès aux informations relatives à la révision du processus CPE via une décision tout à fait injuste qui fait que les parties concernées sont mal informées et qui soulève des interrogations quant à l'intégrité même de la révision indépendante », et que « l'ICANN a interdit la participation éclairée de la communauté Internet à la révision du processus CPE ». (Id. aux pages 9-10.) Le Conseil d'administration souligne que le BGC et l'organisation ICANN ont fourni plusieurs rapports d'étape sur la révision du processus CPE, dont un le 1er septembre 2017. (https://www.icann.org/news/announcement-2017-09-01-en.) De plus, comme indiqué dans ce rapport d'étape du 1er septembre 2017, la révision du processus CPE est toujours en cours. Lorsqu'elle sera achevée, d'autres informations seront mises à la disposition de la communauté de l'ICANN, requérants compris.

          Cette action relève de la mission de l'ICANN et sert l'intérêt public dans la mesure où il est important de veiller à ce que, dans le cadre de sa mission et à l'égard de la communauté, l'ICANN mène ses activités dans le respect de l'acte constitutif, des statuts constitutifs et autres procédures établies, via un processus permettant à une personne ou une entité substantiellement affectée par une action du Conseil d'administration ou du personnel de l'ICANN de demander le réexamen, par le Conseil d'administration, de cette action ou inaction.

          L'adoption de la recommandation du BGC n'a pas de répercussions financières sur l'ICANN et n'aura aucune incidence sur la sécurité, la stabilité et la résilience du système des noms de domaine.

          Cette décision relève d'une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

  2. Ordre du jour principal :

    1. Demande de nouvelles informations ou d'informations supplémentaires au Comité consultatif gouvernemental concernant l'avis sur les candidatures d'Amazon

      Attendu que, la déclaration finale du processus de révision indépendante (IRP) pour l'affaire Amazon EU S.A.R.L. v. ICANN a été adoptée le 11 juillet 2017.

      Attendu que, dans la déclaration finale, le panel a recommandé au Conseil d'administration de « réévaluer dans de brefs délais les candidatures d'Amazon » et de « rendre un jugement objectif et indépendant statuant sur l'existence ou non de motifs d'intérêt public fondés qui justifieraient le rejet des candidatures d'Amazon ». (Voir la déclaration finale au ¶ 125.)

      Attendu que, conformément au chapitre IV article 3.21 de la version actuellement en vigueur des statuts constitutifs, le Conseil d'administration a examiné la déclaration finale lors de sa réunion du 23 septembre 2017 et a déterminé que devait être mené un nouvel examen de la recommandation non contraignante du panel selon laquelle le Conseil d'administration doit « réévaluer dans de brefs délais les candidatures d'Amazon » et « rendre un jugement objectif et indépendant statuant sur l'existence ou non de motifs d'intérêt public fondés qui justifieraient le rejet des candidatures d'Amazon ».

      Attendu que, le Conseil d'administration a demandé au Comité du Conseil d'administration chargé des mécanismes de responsabilité (BAMC) de réviser et prendre en compte la recommandation du panel selon laquelle le Conseil d'administration doit « réévaluer dans de brefs délais les candidatures d'Amazon » et « rendre un jugement objectif et indépendant statuant sur l'existence ou non de motifs d'intérêt public fondés qui justifieraient le rejet des candidatures d'Amazon », et de proposer des solutions au Conseil d'administration qui permettraient de mettre en œuvre la recommandation du panel.

      Attendu que, le BAMC a recommandé au Conseil d'administration de demander au Comité consultatif gouvernemental (GAC) s'il disposait : (i) d'informations à fournir au Conseil d'administration eu égard aux « motifs d'intérêt public fondés » concernant l'avis du GAC selon lequel les candidatures d'Amazon ne devraient pas être retenues ; ou (ii) de nouvelles informations ou d'informations supplémentaires à fournir au Conseil d'administration concernant l'avis du GAC selon lequel les candidatures d'Amazon ne devraient pas être retenues.

      Il est résolu (2017.10.29.02) que le Conseil d'administration demande au GAC s'il dispose : (i) d'informations à fournir au Conseil d'administration eu égard aux « motifs d'intérêt public fondés » concernant l'avis du GAC selon lequel les candidatures d'Amazon ne devraient pas être retenues ; ou (ii) de nouvelles informations ou d'informations supplémentaires à fournir au Conseil d'administration concernant l'avis du GAC selon lequel les candidatures d'Amazon ne devraient pas être retenues.

      Il est résolu (2017.10.29.03) que le Conseil d'administration demande au GAC, s'il dispose de nouvelles informations ou d'informations supplémentaires (tel que requis ci-dessus) à fournir au Conseil d'administration, de les lui faire parvenir, à l'issue de la 61e réunion de l'ICANN qui se tiendra du 10 au 15 mars 2018, afin de l'aider à procéder à un examen adéquat dans les plus brefs délais.

      Fondements des résolutions 2017.10.29.02 et 2017.10.29.03

      Amazon EU S.A.R.L. (Amazon) a engagé un processus de révision indépendante (IRP) afin de contester la décision du Comité du programme des nouveaux gTLD (NGPC) en date du 14 mai 2014 acceptant l'avis consensuel du Comité consultatif gouvernemental (GAC) selon lequel les trois candidatures d'Amazon ne devraient pas être retenues. (La résolution 2014.05.14.NG03 est disponible sur https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-05-14-en#2.b.)

      Amazon a déposé sa candidature pour .AMAZON et ses trois équivalents en caractère chinois et japonais (les candidatures d'Amazon), candidatures qui ont passé avec succès l'évaluation initiale (voir https://newgtlds.icann.org/sites/default/files/ier/bqe3so7p3lu2ia8ouwp7eph9/ie-1-1315-58086-en.pdf [PDF, 46 KB]). En réponse aux candidatures d'Amazon, les gouvernements du Brésil et du Pérou, avec l'approbation de la Bolivie, de l'équateur et de la Guyane, ont envoyé une alerte précoce, via le GAC et conformément au guide de candidature, dans laquelle les gouvernements concernés indiquaient que : « l'octroi de droits exclusifs sur ce gTLD spécifique à une société privée empêcherait l'utilisation de ce domaine aux fins d'intérêt public liés à la protection, la promotion et la sensibilisation au biome amazonien. De même, cela découragerait l'utilisation de ce domaine afin de rassembler les pages web liées à la population vivant dans cette région géographique. » (L'alerte précoce est disponible sur https://gacweb.icann.org/display/gacweb/GAC+Early+Warnings?preview=/27131927/27197938/Amazon-BR-PE-58086.pdf [PDF, 79 KB].)

      Après avoir indiqué dans le communiqué de Beijing (avril 2013) qu'il devait procéder à un nouvel examen des candidatures d'Amazon, le GAC a fourni un avis consensuel (l'avis du GAC) au Conseil d'administration de l'ICANN dans le communiqué de Durban (18 juillet 2013) selon lequel les candidatures d'Amazon ne devraient pas être retenues (https://gacweb.icann.org/display/GACADV/2013-07-18-Obj-Amazon).

      Le 14 mai 2014, le Conseil d'administration (agissant via le NGPC) a accepté l'avis du GAC et a enjoint à l'ICANN de ne pas retenir les candidatures d'Amazon. (La résolution 2014.05.14.NG03 est disponible sur https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-05-14-en#2.b.) La décision du NGPC permet cependant à Amazon et aux membres du GAC de poursuivre leurs efforts et leur dialogue sur les questions importantes.

      En mars 2016, Amazon a lancé une révision indépendante de la résolution 2014.05.14.NG03 du Conseil d'administration de l'ICANN enjoignant de ne pas retenir les candidatures d'Amazon.

      Le 11 juillet 2017, le panel de l'IRP (le panel) a adopté sa déclaration finale dans l'IRP Amazon (https://www.icann.org/en/system/files/files/irp-amazon-final-declaration-11jul17-en.pdf [PDF, 294 KB]). Les conclusions et la recommandation du panel sont résumées ci-dessous et disponibles sur https://www.icann.org/resources/pages/irp-amazon-v-icann-2016-03-04-en.

      Dans une décision 2-1, le panel a donné gain de cause à Amazon et déclaré que « le Conseil d'administration avait agi, via le NGPC, de manière incompatible avec son acte constitutif, ses statuts constitutifs et son guide de candidature car, […] en s'en remettant pleinement à l'avis consensuel du [GAC] afin de déterminer s'il existait un motif d'intérêt public fondé pour son avis, le NGPC a manqué à son obligation de procéder à une évaluation indépendante et de déterminer s'il existait des motifs d'intérêt public valables et fondés justifiant l'avis consensuel du GAC ». (Voir la déclaration finale au ¶ 2.) Le panel a également déclaré ce qui suit : « l'ICANN doit prendre en charge les frais liés à cet IRP ainsi que les frais liés au fournisseur IRP » et « doit rembourser à Amazon la somme de 163 045,51 $ ». (Voir la déclaration finale au ¶ 126.)

      De plus, le panel a recommandé au Conseil d'administration de « réévaluer dans de brefs délais les candidatures d'Amazon » et de « rendre un jugement objectif et indépendant statuant sur l'existence ou non de motifs d'intérêt public fondés qui justifieraient le rejet des candidatures d'Amazon ». Si le Conseil d'administration détermine que les candidatures d'Amazon ne doivent pas être retenues, le panel a indiqué que « le Conseil d'administration devra expliquer les raisons de cette décision » ; l'« avis consensuel du GAC ne peut, seul, se substituer à la décision indépendante et objective du Conseil d'administration accompagnée d'une analyse raisonnée ». (Voir la déclaration finale au ¶ 125.) Sinon, si le Conseil d'administration détermine que les candidatures d'Amazon devraient être retenues, le panel a recommandé que l'ICANN « se réunisse et discute avec le GAC » « dans un délai de soixante (60) jours à compter de l'adoption de la déclaration finale ». (Voir la déclaration finale au ¶ 125.) Afin de dégager ses conclusions, le panel a indiqué qu'« au vu des faits de cet IRP, l'obligation d'équité procédurale applicable au GAC imposait à ce dernier de permettre au moins à une partie potentiellement lésée de transmettre une déclaration ou un commentaire écrit avant de décider d'émettre ou non un avis consensuel de rejet d'une candidature ; et le Conseil d'administration était tenu de s'assurer que le GAC, en tant qu'organe constitutif de l'ICANN, disposait d'une telle procédure et l'avait respectée ». (Voir la déclaration finale au ¶ 94.)

      Le panel a également indiqué que « l'avis consensuel du GAC, bien qu'aucune raison ou aucun fondement ne doive être donné, doit toutefois se baser sur un motif d'intérêt public fondé et ce fondement d'intérêt public doit être constaté ou constatable à partir de l'ensemble des pièces présentées au NGPC ». (Voir la déclaration finale au ¶ 103.) Selon le panel, « le NGPC s'en est remis à l'avis consensuel du GAC concernant l'existence d'un motif d'intérêt public valable et, ce faisant, il ne s'est pas acquitté de son obligation, prévue par les documents de gouvernance de l'ICANN, de prendre une décision indépendante, fondée et objective quant à la sélection des candidatures ». Le panel a également souligné qu'« en omettant de procéder à une évaluation indépendante et qu'en déterminant l'existence d'un motif d'intérêt public fondé pour l'avis du GAC, le NGPC a en effet créé une présomption irréfragable eu égard à l'avis consensuel du GAC ». (Voir la déclaration finale au ¶ 116.)

      Conformément au chapitre IV article 3.21 de la version actuellement en vigueur des statuts constitutifs, le Conseil d'administration a examiné la déclaration finale lors de sa réunion du 23 septembre 2017 et a déterminé, entre autres, que devait être mené un nouvel examen de la recommandation contraignante du panel invitant le Conseil d'administration à « réévaluer dans de brefs délais les candidatures d'Amazon » et à « rendre un jugement objectif et indépendant statuant sur l'existence ou non de motifs d'intérêt public fondés qui justifieraient le rejet des candidatures d'Amazon ». Le Conseil d'administration a demandé au BAMC d'examiner et de prendre en compte la recommandation du panel et de proposer au Conseil d'administration des solutions qui permettraient de mettre en œuvre la recommandation du panel.

      Après examen et prise en compte de la déclaration finale, de la recommandation du panel et de tous les supports y afférents, le Comité du Conseil d'administration chargé des mécanismes de responsabilité (BAMC) est arrivé à la conclusion qu'il serait utile de recevoir de nouvelles informations ou des informations supplémentaires de la part du GAC concernant son avis selon lequel les candidatures d'Amazon ne devraient pas être retenues. Le Conseil d'administration estime que ces nouvelles informations ou informations supplémentaires aideraient le Conseil d'administration à mener une réévaluation complète des candidatures d'Amazon conformément à la recommandation du panel. Par conséquent, le BAMC a recommandé au Conseil d'administration de demander au GAC s'il pouvait lui fournir de nouvelles informations ou des informations supplémentaires relatives à son avis selon lequel les candidatures d'Amazon ne devraient pas être retenues.

      Le Conseil d'administration reconnaît l'importance de cette décision et souhaite préciser qu'il prend très au sérieux les résultats de l'ensemble des mécanismes de responsabilité de l'ICANN, ce qui se vérifie par la création du nouveau BAMC et ce qui explique pourquoi la recommandation du panel a été transmise au BAMC.

      Prendre cette décision relève de la mission de l'ICANN et sert l'intérêt public dans la mesure où le résultat final de l'examen par l'ICANN de cette question constitue un aspect clé de la coordination de l'affectation et l'attribution des noms dans la zone racine du système des noms de domaine (DNS). De plus, la décision du Conseil d'administration sert l'intérêt public étant donné qu'elle prend en compte et concilie les objectifs de règlement des différends en cours liés aux gTLD, de respect des mécanismes de responsabilité et des comités consultatifs de l'ICANN, et de conformité aux politiques et procédures définies dans le guide de candidature qui ont été élaborées via un processus multipartite ascendant fondé sur le consensus après plusieurs années d'efforts et de contributions de la part de la communauté.

      Cette décision ne devrait pas avoir de répercussions financières directes sur l'organisation ICANN. Cette décision n'aura aucune incidence sur la sécurité, la stabilité ou la résilience du système des noms de domaine.

      Il s'agit d'une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    2. Demande de report de 180 jours de la mise en conformité à la politique de consensus relative au WHOIS détaillé

      Attendu que, la politique de consensus relative au WHOIS détaillé impose de soumettre au registre toutes les données d'enregistrement de nouveaux noms de domaine sous forme « détaillé » à compter du 1er mai 2018 au plus tard, et de procéder à la migration de l'ensemble des données d'enregistrement pertinentes relatives aux noms de domaine existants du WHOIS « résumé » au WHOIS « détaillé » d'ici au 1er février 2019.

      Attendu que, la migration du modèle d'enregistrement résumé au modèle d'enregistrement détaillé imposera aux bureaux d'enregistrement de modifier les systèmes via lesquels ils soumettent des données d'enregistrement aux bureaux d'enregistrement.

      Attendu que, le Groupe des représentants des bureaux d'enregistrement a exprimé des inquiétudes quant au fait de procéder à ces modifications sans que les questions liées au Règlement général sur la protection des données (RGPD) de l'Union européenne ne soient réglées, car d'autres modifications du système pourraient s'avérer nécessaires par la suite.

      Attendu que, afin de pouvoir parachever le déploiement visant à accepter des données du WHOIS détaillé, Verisign, Inc. a proposé des amendements des contrats entre registres et bureaux d'enregistrement pour .COM et .NET de façon à établir un cadre juridique qui permettrait à Verisign de commencer à accepter la transmission de données détaillées des bureaux d'enregistrement vers le registre.

      Attendu que, l'organisation ICANN a facilité des discussions entre Verisign et le Groupe des représentants des bureaux d'enregistrement afin de parvenir à un accord sur les propositions d'amendements des contrats entre registres et bureaux d'enregistrement visant à mettre en œuvre la politique de consensus relative au WHOIS détaillé.

      Attendu que, Verisign et le Groupe des représentants des bureaux d'enregistrement ont besoin de davantage de temps afin de parvenir à un accord sur les propositions d'amendements des contrats entre registres et bureaux d'enregistrement concernés visant à mettre en œuvre la politique de consensus relative au WHOIS détaillé.

      Attendu que, davantage de temps est nécessaire afin de régler les questions liées à l'application du RGPD aux données WHOIS.

      Il est résolu (2017.10.29.04) que le président-directeur général, ou son ou ses représentants, sont autorisés à reporter de 180 jours la mise en conformité à la politique de consensus relative au WHOIS détaillé de sorte à donner davantage de temps aux bureaux d'enregistrement et à Verisign afin de parvenir à un accord sur les amendements requis pour les contrats entre registres et bureaux d'enregistrement concernés visant à mettre en œuvre la politique et aux bureaux d'enregistrement afin de procéder aux modifications du système requises pour assurer la migration du WHOIS résumé au WHOIS détaillé et éventuellement d'autres modifications liées au respect du RGPD.

      Fondements de la résolution 2017.10.29.04

      La politique de consensus relative au WHOIS détaillé impose aux bureaux d'enregistrement de soumettre des données d'enregistrement détaillées aux registres .COM, .NET et .JOBS pour tous les nouveaux enregistrements de noms de domaine à compter du 1er mai 2018 au plus tard. Cette politique impose également la migration de l'ensemble des données d'enregistrement de noms de domaine existants du WHOIS résumé au WHOIS détaillé d'ici au 1er février 2019. Afin de pouvoir parachever le déploiement visant à accepter des données du WHOIS détaillé, Verisign, opérateur de registre pour .COM et .NET et fournisseur des services de registre back-end pour .JOBS, a proposé des amendements des contrats entre registres et bureaux d'enregistrement pour .COM et .NET de façon à établir un cadre juridique qui permettrait à Verisign de commencer à accepter la transmission de données détaillées des bureaux d'enregistrement vers le registre.

      L'organisation ICANN a suivi sa procédure d'amendement des contrats entre opérateurs de registre et bureaux d'enregistrement et a transmis les propositions d'amendements au Groupe des représentants des bureaux d'enregistrement à des fins d'examen. Le Groupe des représentants des bureaux d'enregistrement a exprimé des préoccupations quant à l'adoption des propositions d'amendements en raison de certaines questions relatives au Règlement général sur la protection des données (RGPD) de l'Union européenne qui entrera en vigueur le 25 mai 2018. De ce fait, l'étape suivante prévue dans la procédure consiste pour l'organisation ICANN à mener des consultations avec l'opérateur de registre et le Groupe des représentants des bureaux d'enregistrement de façon à dissiper ces préoccupations.

      Au cours des derniers mois, l'organisation ICANN a facilité des discussions entre Verisign et le Groupe des représentants des bureaux d'enregistrement afin de parvenir à un accord sur les propositions d'amendements des contrats entre opérateurs de registre et bureaux d'enregistrement, mais les parties ne sont pas encore parvenues à un accord. De plus, l'organisation ICANN tâche de détecter d'éventuels problèmes de conformité de ces contrats entre opérateurs de registre et bureaux d'enregistrement au Règlement général sur la protection des données. L'organisation ICANN collabore avec des registres, des bureaux d'enregistrement et différentes parties prenantes afin de comprendre ces éventuels problèmes de conformité. à partir de premiers examens et de communications, notamment avec certaines agences de protection des données, l'organisation ICANN sait désormais que la conformité au RGPD aura un impact sur le système WHOIS.

      Le 29 juin 2017, l'organisation ICANN a approuvé la demande de Verisign de report de la date limite facultative prévue par la politique à partir de laquelle les bureaux d'enregistrement peuvent commencer à soumettre volontairement des données résumées au registre. Ce report a été accordé pour donner davantage de temps à Verisign, à l'ICANN et au Groupe des représentants des bureaux d'enregistrement afin qu'ils puissent poursuivre le dialogue visant à trouver un terrain d'entente tout en prenant des mesures raisonnables pour respecter la politique. Cette date limite facultative, à savoir le 1er août 2017, a été reportée au 29 novembre 2017.

      Afin de donner davantage de temps aux bureaux d'enregistrement et à Verisign pour parvenir à un accord sur les amendements requis pour les contrats entre registres et bureaux d'enregistrement visant à mettre en œuvre la politique, le Conseil d'administration prend actuellement des mesures afin d'autoriser le président-directeur général de l'ICANN à reporter de 180 jours la mise en conformité à la politique relative au WHOIS détaillé. Le report du délai de mise en conformité permettra également à l'organisation ICANN de poursuivre le dialogue avec la communauté européenne (y compris le groupe de travail Article 29 de l'Union européenne), les agences de protection des données, les parties contractantes ainsi que d'autres parties prenantes concernées afin de mieux comprendre les aspects pertinents du RGPD liés aux activités, aux politiques et aux contrats de l'ICANN avec les registres et bureaux d'enregistrement, notamment la politique relative au WHOIS détaillé.

      Suite aux mesures prises par le Conseil d'administration, l'organisation ICANN commencera à mettre en œuvre les critères prévus par la politique afin que les bureaux d'enregistrement soumettent au registre toutes les données d'enregistrement des nouveaux noms de domaine sous forme détaillée à compter du 28 octobre 2018 au plus tard, toutes les données d'enregistrement des noms de domaine existants devant elles être migrées du WHOIS résume au WHOIS détaillé d'ici au 31 juillet 2019. La date limite facultative à partir de laquelle les bureaux d'enregistrement peuvent commencer à soumettre volontairement au registre des données résumées est le 28 mai 2018.

      Lors de cette période de report de la mise en conformité, l'organisation ICANN continuera à collaborer avec Verisign et le Groupe des représentants des bureaux d'enregistrement afin de faciliter les discussions sur les propositions d'amendements. L'organisation ICANN tiendra également la communauté informée de l'avancée de la conformité à la politique relative au WHOIS détaillé. Lors de cette période de report, le Groupe des représentants des bureaux d'enregistrement a indiqué [PDF, 43 KB] qu'il « poursuivra le dialogue avec l'ICANN et Verisign eu égard aux modifications des RRA, au rôle de l'ICANN en vertu du RGPD et aux mesures requises afin de mettre en œuvre la transition vers le WHOIS détaillé ».

      Les délibérations du Conseil d'administration sur cette question ont tenu compte, entre autres, des documents suivants :

      Cette décision sert l'intérêt public dans la mesure où elle aide à garantir la mise en œuvre uniforme et coordonnée des politiques dans les gTLD et où elle relève de la mission de l'ICANN consistant à coordonner l'élaboration et la mise en œuvre des politiques.

      La décision du Conseil d'administration ne devrait pas avoir de répercussions financières sur l'ICANN qui n'aient pas déjà été prévues dans le budget actuel et n'aura aucune incidence sur la sécurité, la stabilité ou la résilience du système des noms de domaine.

      Il s'agit d'une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.

    3. Perfectionnement du processus de révision de similarité de chaînes dans le cadre de la procédure accélérée ccTLD IDN

      Attendu que, le Conseil d'administration de l'ICANN a approuvé le plan de mise en œuvre final pour la procédure accélérée ccTLD IDN le 30 octobre 2009 (http://www.icann.org/en/minutes/resolutions-30oct09-en.htm#2).

      Attendu que, dans le cadre d'une révision et mise à jour du plan de mise en œuvre, le Conseil de la ccNSO, suite à la formulation des recommandations relatives à la sélection des chaînes ccTLD IDN, a demandé au Conseil d'administration de l'ICANN d'inclure un processus à deux panels pour l'évaluation de la similarité des chaînes (http://ccnso.icann.org/node/38787).

      Attendu que, le Conseil d'administration de l'ICANN a approuvé la mise à jour de la mise en œuvre de la procédure accélérée ccTLD IDN visant à mettre en place le processus à deux panels pour la révision de la similarité des chaînes. L'inclusion du Panel chargé de mettre en place le processus élargi de révision de similarité de chaînes (EPSRP) dans la procédure accélérée ccTLD IDN a été approuvée le 27 juin 2013, et l'organisation ICANN a été enjointe d'élaborer les lignes directrices y afférentes et de mettre à jour en conséquence le plan de mise en œuvre final (https://www.icann.org/resources/board-material/resolutions-2013-06-27-en#2.a).

      Attendu que, suite à la mise à jour de 2013, et à la demande de tout candidat concerné, les candidatures en cours pour les chaînes ccTLD IDN faisant l'objet de la procédure accélérée ont été évaluées par l'EPSRP, et celui-ci a rédigé des rapports pour les trois candidatures qui ont été publiés avec les résultats de l'évaluation sur le site Internet de l'ICANN le 14 octobre 2014 (https://www.icann.org/resources/pages/epsrp-reports-2014-10-14-en). Une candidature a reçu des résultats divergents sur le fondement d'évaluations de l'éventuel risque de confusion des représentations en minuscules et majuscules de la chaîne objet de la candidature.

      Attendu que, les retours du public ont été reçus pendant la troisième révision annuelle de la procédure accélérée ccTLD IDN sur les questions liées à la méthodologie expérimentale et les résultats rapportés par l'EPSRP, dont l'interprétation des recommandations divergentes de l'EPSRP sur la similarité prêtant à confusion eu égard aux représentations en minuscules et majuscules de la chaîne objet de la candidature (https://www.icann.org/public-comments/idn-cctld-fast-track-2015-01-15-en).

      Attendu que, suite aux commentaires publics de la troisième révision annuelle, le Conseil d'administration de l'ICANN a décidé le 25 juin 2015 de demander à la ccNSO, en consultation avec d'autres parties prenantes, dont le GAC et le SSAC, de fournir des directives supplémentaires et d'apporter des améliorations à la méthodologie du deuxième processus de révision de similarité de chaînes (https://www.icann.org/resources/board-material/resolutions-2015-06-25-en#2.a).

      Attendu que, suite à la lettre du Conseil d'administration visant à avoir des précisions, le ccNSO et le SSAC ont adressé une réponse conjointe le 19 septembre 2017 proposant des modifications du plan de mise en œuvre final pour la procédure accélérée ccTLD IDN.

      Il est résolu (2017.10.29.05) que le Conseil d'administration remercie le ccNSO, le GAC et le SSAC d'avoir collaboré afin de résoudre le problème lié à la révision de similarité de chaînes et d'avoir rédigé la « réponse conjointe ccNSO-SSAC au Conseil d'administration sur l'EPSRP ».

      Il est résolu (2017.10.29.06) que le Conseil d'administration approuve la modification du plan de mise en œuvre final pour la procédure accélérée ccTLD IDN tel que suggéré dans la réponse conjointe ccNSO-SSAC. Le PDG, ou son ou ses représentants, sont priés d'incorporer la modification dans le plan de mise en œuvre préalablement adopté par le Conseil d'administration le 30 octobre 2009 (et modifié le 5 novembre 2013) et de mettre en œuvre ladite modification dès que possible.

      Fondements des résolutions 2017.10.29.05 et 2017.10.29.06

      Pourquoi le Conseil aborde-t-il cette question maintenant ?

      Le 5 novembre 2013, l'organisation ICANN a publié le plan de mise en œuvre final pour la procédure accélérée ccTLD IDN mis à jour [PDF, 851 KB] comprenant les lignes directrices [PDF, 86 KB] pour le Panel chargé de mettre en place le processus élargi de révision de similarité de chaînes (EPSRP), mettant en œuvre la révision de similarité de chaînes à deux panels, conformément à la résolution adoptée par le Conseil d'administration le 27 juin 2013. Suite à cette mise à jour, trois candidats à la procédure accélérée ccTLD IDN éligibles pour la Bulgarie (en cyrillique), l'Union européenne (en grec) et la Grèce (en grec) ont exercé leur option consistant à se soumettre à une deuxième révision de similarité. L'EPSRP a procédé à la révision et l'organisation ICANN a publié ces rapports le 14 octobre 2014.

      Pour chaque candidature, l'EPSRP a étayé ses conclusions eu égard à la chaîne objet de la candidature. Chaque rapport comprenait une description détaillée de la méthodologie ainsi que les résultats des tests de similarité de chaîne. L'EPSRP n'a pas fait une synthèse des conclusions pour une chaîne sur la base de tests effectués sur les représentations en minuscules et majuscules de la chaîne. L'EPSRP est arrivé à la conclusion que du point de vue de la similarité visuelle, les caractères en majuscules et minuscules constituent des entités distinctes. Et étant donné qu'il n'existe aucune base scientifique ou politique pour la combinaison des résultats de similarité des représentations en minuscules ou majuscules pour des ccTLD IDN, l'EPSRP ne pouvait que formuler des recommandations distinctes pour chacune de ces représentations. Par conséquent, lorsque les conclusions de l'EPSRP divergent du fait qu'il est arrivé à des résultats différents quant à la similarité prêtant à confusion des représentations en minuscules et majuscules d'une chaîne, il n'existe aucun mécanisme permettant de dégager une seule recommandation combinée de la deuxième révision de similarité de chaînes effectuée par l'EPSRP.

      Sur la base des enseignements tirés de l'analyse de l'EPSRP, lors de la troisième révision de la procédure accélérée ccTLD IDN, la communauté a fourni des commentaires publics soulevant des problèmes liés à la méthodologie de l'EPSRP, dont l'évaluation des recommandations divergentes (par exemple une similarité prêtant à confusion pour des représentations en majuscules mais pas pour des représentations en minuscules).

      Afin de prendre en compte ces commentaires, le Conseil d'administration (via la résolution 2015.06.25.16) a demandé à la ccNSO, en lien avec d'autres parties prenantes, dont le GAC et le SSAC, de fournir des directives supplémentaires et d'apporter des améliorations à la méthodologie du deuxième processus de révision de similarité de chaînes, y compris l'interprétation de recommandations divergentes, afin de pouvoir appliquer cette méthodologie améliorée aux candidatures actuelles et futures à la procédure accélérée ccTLD IDN et d'éclairer la proposition de politique relative à la sélection des chaînes ccTLD IDN.

      Le groupe de travail de la ccNSO concerné, en lien avec des membres du GAC, a publié son rapport [PDF, 274 KB] à des fins de consultation publique avant sa finalisation. Le SSAC a soumis un point de vue différent dans le SAC 084 [PDF, 218 KB] puis dans le SAC 088 [PDF, 72 KB] et le SAC 089 [PDF, 128 KB]. à la demande du Conseil d'administration, la ccNSO et le SSAC ont travaillé ensemble afin de dégager une solution que les présidents de la ccNSO et du SSAC ont présentée au Conseil d'administration le 19 septembre 2017 sous la forme d'une réponse conjointe [PDF, 215 KB].

      Avec cette résolution, le Conseil d'administration a désormais achevé la révision du programme de procédure accélérée de 2015 et s'attaque à la mise à jour du plan de mise en œuvre final pour la procédure accélérée ccTLD IDN tel que suggéré dans la réponse conjointe ccNSO-SSAC. Traiter de cette question relève de la mission de l'ICANN telle qu'énoncée à l'article 1.1(a)(i) des statuts constitutifs de l'ICANN : « Coordonne l'affectation et l'attribution des noms dans la zone racine du système des noms de domaine ». Cette question maintenant réglée, le cycle de révision du plan de mise en œuvre peut commencer.

      Quelles sont les inquiétudes ou questions soulevées par la communauté ?

      Le SSAC fournit des premiers éléments dans le SAC 084 [PDF, 218 KB] et précisent par la suite dans le SAC 088 [PDF, 72 KB] et le SAC 089 [PDF, 128 KB] qu'en cas de recommandation divergente, « la mesure à prendre par défaut devrait consister à rejeter l'étiquette si le risque de confusion existe sous l'une ou l'autre des deux représentations », tout en continuant à appliquer aux processus tels que l'EPSRP les principes de conservatisme, d'inclusion et de stabilité. Toutefois, le Conseil de la ccNSO a mis en exergue le rapport technique Unicode n° 36 : Impératifs de sécurité Unicode, selon lequel « l'utilisation de caractères pouvant être visuellement confondus à des fins d'usurpation est souvent surestimée,… cette utilisation ne représentant qu'une faible partie des problèmes d'hameçonnage » qui peuvent être atténués par les mesures proposés dans le rapport Unicode. Dans leur réponse conjointe, la ccNSO et le SSAC ont convenu d'un processus qui répondrait aux inquiétudes soulevées par le SSAC en permettant au demandeur de proposer des mesures qui seraient examinées par des experts chargés de déterminer si le risque de confusion est effectivement atténué.

      Quels sont les principaux documents examinés par le Conseil ?

      Le Conseil d'administration a examiné divers documents et facteurs lors de ses délibérations et en a tenu compte dans sa prise de décision. Les documents pertinents et importants sont, mais ne se limitent pas à, ce qui suit :

      Quels sont les facteurs que le Conseil a trouvés significatifs ?

      Le Conseil d'administration a indiqué que les membres de la ccNSO et du SSAC ont collaboré afin de convenir d'un mécanisme efficace répondant aux différentes préoccupations soulevées lors du processus. Le demandeur de ccTLD IDN devrait proposer des mesures efficaces d'atténuation des risques afin de répondre aux craintes en matière de sécurité dont a fait préalablement part le SSAC.

      Y a-t-il des effets positifs ou négatifs pour la communauté ?

      Cette décision a un impact positif car elle lève l'ambiguïté des lignes directrices pour la deuxième révision de similarité en cas de recommandations divergentes en permettant de mener des évaluations de chaînes ccTLD IDN à condition que des mesures efficaces d'atténuation des risques puissent être définies et mises en œuvre. Cette décision sert également l'intérêt public en étendant l'éventuelle disponibilité des ccTLD IDN à d'autres pays et territoires, véritable avancée pour les internautes locaux.

      Y a-t-il des répercussions financières sur l'ICANN (plan stratégique, plan opérationnel, budget), la communauté et/ou le public ?

      La mise en œuvre aura des répercussions financières car l'organisation ICANN doit embaucher des experts chargés d'évaluer les stratégies d'atténuation des risques proposées par le demandeur.

      Y a-t-il des implications en termes de sécurité/stabilité/résilience du DNS ? Quelles sont les inquiétudes ou questions soulevées par la communauté ?

      La réponse conjointe ccNSO-SSAC expose quatre cas de figure eu égard à l'évaluation de la similarité prêtant à confusion des représentations en minuscules et majuscules de la chaîne objet de la candidature. Dans le premier cas, aucune représentation ne présente de similarité prêtant à confusion ; la chaîne passe alors avec succès l'évaluation. Dans les deuxième et troisième cas, la représentation en minuscules présente une similarité prêtant à confusion et la représentation en majuscules présente ou non une similarité prêtant à confusion ; les risques associés sont alors trop élevés et difficiles à atténuer et la chaîne ne passe donc pas l'évaluation. Dans le quatrième cas, la représentation en minuscules ne présente pas de similarité prêtant à confusion mais la représentation en majuscules présente elle une similarité prêtant à confusion ; le SSAC conseille alors d'adopter une approche prudente. La réponse conjointe indique que le SSAC estime que le risque est un continuum, et dans ce quatrième cas de figure, l'approche prudente pourrait consister pour le demandeur de ccTLD IDN à proposer des mesures d'atténuation jugées suffisantes afin de réduire les risques à un niveau qualifiée d'acceptable par les experts concernés. Ce n'est qu'à ce moment-là que la chaîne peut passer avec succès l'évaluation de la similarité de chaîne.

      S'agit-il d'un processus d'élaboration de politiques défini au sein des organisations de soutien de l'ICANN ou d'une fonction organisationnelle administrative de l'ICANN nécessitant ou non une consultation publique ?

      La mise à jour suggérée par la ccNSO a déjà été soumise, tel que requis, à la consultation publique après la rédaction du rapport initial. Les commentaires comprenaient une réponse du GAC appuyant les conclusions et une réponse du SSAC via le SSAC 084 ainsi que d'autres réponses dans le SAC 088 et le SAC 089 suggérant une approche alternative. Afin de concilier les avis divergents des commentaires publics, la ccNSO et le SSAC ont collaboré afin de clarifier leurs positions et de trouver un terrain d'entente qui est présenté dans leur réponse conjointe au Conseil d'administration. Il n'est pas nécessaire de solliciter de nouveau l'avis du public afin d'incorporer dans le plan de mise en œuvre final pour la procédure accélérée ccTLD IDN l'ajustement suggéré dans la réponse conjointe ccNSO-SSAC. Il s'agit d'une fonction administrative organisationnelle qui ne nécessite pas de consultation publique.


1 Décision du BGC eu égard à la demande 15-21, page 1, https://www.icann.org/en/system/files/files/reconsideration-15-21-dotgay-bgc-determination-01feb16-en.pdf [PDF, 272 KB].

2 Avant le 22 juillet 2017, le BGC était chargé d'examiner les demandes de réexamen. Voir les statuts constitutifs de l'ICANN, 1er octobre 2016, chapitre 4, § 4.2(e), https://www.icann.org/resources/pages/bylaws-2016-09-30-en#article4. à compter du 22 juillet 2017, le Comité du Conseil d'administration chargé des mécanismes de responsabilité (BAMC) a été chargé d'examiner et de formuler des recommandations au Conseil d'administration relatives aux demandes de réexamen. Voir les statuts constitutifs de l'ICANN, 22 juillet 2017, chapitre 4, § 4.2(e), https://www.icann.org/resources/pages/governance/bylaws-en/#article4.

3 Décision du BGC eu égard à la demande 15-21, page 1.

4 Demande 16-3, https://www.icann.org/en/system/files/files/reconsideration-16-3-dotgay-request-17feb16-en.pdf [PDF, 728 KB].

5 Demande 16-5, https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-request-redacted-24feb16-en.pdf [PDF, 1.06 MB].

6 Réponses de l'ICANN aux demandes DIDP n° 20170505-1 (DotMusic Ltd.) et 20170518-1 (dotgay LLC) intégrées par renvoi à la réponse de l'ICANN à la demande DIDP n° 20170610-1 à la page 2.

7 Comme l'a souligné le BAMC, les requérants ont indiqué (en cochant la case correspondante sur le formulaire de demande de réexamen) que la demande 17-4 réclame le réexamen de l'action ou l'inaction du personnel et du Conseil d'administration. Toutefois, à part une brève mention du chapitre 4 article 4.2(o) des statuts constitutifs de l'ICANN selon lequel le BAMC « doit . . . fournir au demandeur » toute information « recueillie par l'ICANN via des tiers présentant un intérêt pour la demande de réexamen », les requérants n'ajoutent aucun argument eu égard aux actions ou inactions du BAMC. Les requérants ne demandent pas non plus à l'organisation ICANN de prendre une mesure à cet égard. Au lieu de cela, ils se concentrent sur la réponse à la demande DIDP conjointe de l'organisation ICANN. Par conséquent, le BAMC a interprété la demande 17-4 comme réclamant le réexamen de la réponse à la demande DIDP conjointe de l'organisation ICANN et non le réexamen de l'action ou l'inaction du BAMC, et le Conseil d'administration est d'accord avec cette interprétation. (Voir la recommandation du BAMC [PDF, 273 KB], pages 12-13.)

8 Il convient de procéder à un réexamen si le requérant prouve avoir été lésé par une action ou inaction du Conseil d'administration ou du personnel décidée sans tenir compte d'informations importantes, ou décidée en se fondant sur des informations fausses ou inexactes. (Statuts constitutifs de l'ICANN, chapitre 4 article 4.2(c)(ii), (iii).)

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."