Skip to main content
Resources

Procès verbaux | Réunion du comité du programme des nouveaux gTLD

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 : http://www.icann.org/en/groups/board/documents/minutes-new-gtld-10sep13-en.htm

 

Remarque : le 10 avril 2012, le Conseil d'administration a créé le comité du programme des nouveaux gTLD, intégré par tous les membres du Conseil ayant droit de vote et n'ayant pas de conflit d'intérêt par rapport au programme des nouveaux gTLD. Le comité s'est vu accorder tous les pouvoirs du Conseil d'administration (soumis aux limitations établies par la loi, les statuts ou les politiques de l'ICANN en matière de conflits d'intérêt) pour exercer son autorité sur toute question relative au programme des nouveaux gTLD. Le champ d'application de l'autorité du comité est établi dans sa charte http://www.icann.org/en/groups/board/new-gTLD.

Une réunion extraordinaire du comité du programme sur les nouveaux gTLD du Conseil d'administration de l'ICANN a eu lieu par voie téléphonique le 10 septembre 2013 à 13h00 UTC.

Le président du comité Cherine Chalaby a rapidement rappelé la séance à l'ordre.

Outre le président, les administrateurs suivants ont participé à toute ou à une partie de la réunion : Fadi Chehadé (Président-directeur général, ICANN), Chris Disspain, Bill Graham, Olga Madruga-Forti, Erika Mann, Ray Plzak, George Sadowsky, Mike Silber et Kuo-Wei Wu.

Gonzalo Navarro a envoyé des excuses.

Jonne Soininen, agent de liaison IETF et Francisco da Silva, agent de liaison TLG, ont également assisté à la réunion comme liaisons au comité sans droit de vote. Heather Dryden a participé en sa qualité d'observatrice du comité. Bruce Tonkin a assisté à la réunion en tant qu'observateur invité (sans droit de vote) pour le point 1 de l'ordre du jour principal.

Membres du personnel de l'ICANN ayant assisté à toute ou à une partie de la réunion : Akram Atallah, président, division des domaines génériques ; John Jeffrey, conseiller juridique et secrétaire ; Megan Bishop, Michelle Bright, Samantha Eisner, Allen Grogan, Dan Halloran, Jamie Hedlund, Elizabeth Le, Karen Lentz, Cyrus Namazi, Olof Nordling, David Olive, Karine Perset, Erika Randall, Amy Stathos, Christine Willett et Mary Wong.

Voici le procès verbal de la réunion du comité du programme des nouveaux gTLD, ayant eu lieu le 10 septembre 2013.

  1. Ordre du jour convenu
    1. Approbation des procès-verbaux des réunions du NGPC
  2. Ordre du jour principal
    1. Mise à jour concernant la similarité de chaînes
    2. Recommandation du Comité de Gouvernance du Conseil concernant la demande de reconsidération
    3. Communiqué du GAC de Durban – examen approfondi de la fiche de suivi
    4. Communiqué du GAC de Beijing – fiche de suivi
    5. Communiqué du GAC de Beijing – catégorie 1
    6. Déclaration de l'ALAC sur le traitement préférentiel pour les candidatures de la communauté en cas de conflit de chaînes
    7. Déclaration de l'ALAC sur l'expertise de la communauté dans l'évaluation avec priorité à la communauté
    8. Autres points à l'ordre du jour

 

  1. Ordre du jour convenu

    1. Approbation des procès-verbaux des réunions du NGPC

      Le président a présenté le point de l'ordre du jour convenu. George Sadowsky a proposé et Chris Disspain a appuyé la résolution à l'ordre du jour convenu et le comité a pris la décision suivante :

      Résolu (2013.09.10.NG01), le NGPC approuve les procès-verbaux des réunions du 13 juillet 2013 et du 17 juillet 2013 du comité du programme des nouveaux gTLD.

      Tous les membres du Conseil ont voté en faveur de la résolution 2013.09.10.NG01. Gonzalo Navarro n'était pas disponible pour voter cette résolution. La résolution a été adoptée.

  2. Ordre du jour principal

    1. Mise à jour concernant la similarité de chaînes

      Le président a fourni un aperçu général des points de l'ordre du jour principal devant être examinés par le comité et a signalé que le membre du Conseil d'administration de l'ICANN, Bruce Tonkin, participerait à la discussion relative au premier point de l'ordre du jour afin de fournir des détails relatifs au processus de révision de la similarité de chaînes.

      Bruce Tonkin a présenté au comité un aperçu général de la manière selon laquelle les normes portant sur la similarité de chaînes étaient élaborées, expliquant que la similarité de chaînes se basait sur la recommandation de politique numéro 2 de la GNSO, laquelle indique que les chaînes ne devaient pas être si similaires à des chaînes de premier niveau existantes ou proposées qu'elles seraient susceptibles d'entraîner une confusion.

      Bruce a signalé que dans le cadre de l'élaboration des normes portant sur la similarité de chaînes, la GNSO a pris en considération la norme « similaire susceptible d'entraîner une confusion » utilisée dans la loi régissant les marques de commerce relevant de plusieurs juridications ainsi que la convention de Paris pour la protection de la propriété intellectuelle.

      Bruce a présenté au comité une synthèse du processus de révision de similarité de chaînes dans les évaluations initiales, qui se concentre sur la similarité visuelle, et le processus d'objection pour confusion de chaîne. Bruce a signalé qu'une décision fondamentale avait été prise assez tôt lors des itérations du guide de candidature. Selon cette décision, l'ICANN, durant la phase d'évaluation initiale, examinerait les chaînes uniquement en termes de confusion visuelle.

      Bruce a également expliqué le rôle des objections pour confusion de chaîne dans le processus et a signalé que la politique suivie était de permettre un examen plus large de la confusion – pas seulement la confusion visuelle. Bruce a ajouté que l'objection pour similarité de chaîne constituait un litige entre deux parties et que l'ICANN n'était pas impliquée.

      Bruce a ajouté que certains candidats qui avaient fait l'objet d'une décision défavorable suite au processus de révision de similarité de chaîne ou au processus d'objection pour similarité de chaîne avaient invoqué le processus de demande de réexamen prévu dans les statuts de l'ICANN.

      Mike Silber a signalé trois questions clés que le comité devait examiner par rapport aux décisions de similarité de chaînes. Mike a demandé au comité de réfléchir, le cas échéant, à ce qui devrait être fait pour aborder l'incohérence perçue entre les conclusions des divers panels d'objection pour confusion de chaîne. Mike a déclaré que le comité devrait aussi examiner les décisions du panel de révision de similarité de chaînes et examiner si des changements étaient nécessaires pour les tours à venir compte tenu des préoccupations exprimées lors du tour actuel. Mike a signalé que le personnel préparerait un document d'information fournissant plus de détails sur ces préoccupations pour un débat au sein du comité lors de sa prochaine réunion.

      Le président a demandé à Mike s'il suggérait que toute action n'aurait d'impact que sur les tours à venir. Erika Mann a demandé si Mike recommandait que le comité s'adresse aux experts et leur demande de fournir des opinions cohérentes. Mike a précisé que le comité devrait d'abord comprendre s'il y avait un vrai problème avant d'agir. En outre, Mike a recommandé que le comité s'efforce à mieux comprendre les conséquences de toute action sur le tour actuel.

      Akram Atallah a recommandé que le comité sépare la question de révision de la similarité de chaînes, laquelle examine uniquement la similarité visuelle, de la question d'objection pour confusion de chaîne. Akram a indiqué que le personnel préparerait un document sur ces questions pour une conversation future.

      Après la conclusion de la discussion, Bruce s'est excusé de ne pas participer à la suite de la réunion.

    2. Recommandation du Comité de Gouvernance du Conseil concernant la demande de reconsidération

      Le président a présenté le point au comité et Amy Stathos a fourni un aperçu général de la demande de reconsidération 13-5, y compris la recommandation du comité de gouvernance du Conseil (BGC) au comité. Amy a indiqué que le demandeur soutenait que la décision du panel de révision de la similarité de chaîne devait être annulée pour que « hotels » et « hoteis » ne fassent pas partie d'un ensemble conflictuel. Amy a aussi rappelé au comité les principes des demandes de reconsidération tels qu'indiqués dans les statuts. Le BGC a décidé que le demandeur n'avait pas avancé de motifs appropriés pour une reconsidération.

      George Sadowsky a indiqué qu'il comprenait que le BGC avait pris la bonne décision mais considérait que le résultat final était contraire aux meilleurs intérêts de l'ICANN et de l'utilisateur. George a indiqué que, par conséquent, il comptait s'abstenir de voter.

      Olga Madruga-Forti a indiqué qu'elle comptait s'abstenir de voter parce qu'il n'y avait pas de fondements suffisants justifiant la décision du panel de révision de la similarité de chaînes.

      Le président a noté que la partie ayant soumis la demande de reconsidération n'est essentiellement simplement pas d'accord avec la décision. Vu que la procédure avait été suivie, le président a indiqué que le comité ne devrait pas accepter la demande de reconsidération.

      Ray Plzak a convenu que la procédure avait été suivie, mais a indiqué que la procédure devrait être révisée pour ajouter un mécanisme qui permette aux personnes qui ne sont pas d'accord avec le résultat de faire une objection, au lieu d'utiliser la demande de reconsidération. Ray a recommandé que le comité indique clairement au BGC, ou adopte une résolution recommandant que le BGC envisage l'élaboration d'un mécanisme différent qui fournisse une possibilité pour la communauté de faire appel du résultat d'une décision basée sur les qualités. Olga a recommandé qu'à l'avenir, un mécanisme de renvoi ou d'appel pourrait aider à soulager les inquiétudes exprimées.

      Bill Graham était d'accord avec la suggestion de Ray et a indiqué qu'en général, il y avait un sentiment considérable de gêne et d'insatisfaction à l'égard du processus tel qu'exprimé par les membres du comité. Le président a indiqué être d'accord avec le sentiment de Bill.

      Le conseiller juridique et secrétaire a noté que l'ICANN avait essayé d'encourager un recours plus fréquent au médiateur ou à d'autres mécanismes de responsabilité pour ces types de préoccupations.

      Le président directeur général a proposé et Ray Plzak a soutenu la résolution.

      Le Conseil a ensuite pris la décision suivante :

      Attendu que, la demande 13-5 de reconsidération de Booking.com B.V. ( « Booking.com »), demandait la reconsidération de l'acte du personnel de l'ICANN en date du 26 février 2013, lorsque les résultats du panel de similarité de chaînes ont été publiés pour le programme des nouveaux gTLD, plaçant les candidatures pour .hotels et .hoteis dans un ensemble conflictuel de similarité de chaînes.

      Attendu que le BGC a examiné les questions soulevées dans la demande de reconsidération 13-5.

      Attendu que le BGC a recommandé le refus de la demande de reconsidération 13-5 au motif que Booking.com n'avait pas présenté des arguments pertinents pour la reconsidération.

      Résolu (2013.09.10.NG02), le Comité du programme des nouveaux gTLD adopte la recommandation du BGC concernant la demande de reconsidération 13-5, qui peut être consultée à l'adresse http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-booking-01aug13-en.pdf [PDF, 117 KB].

      Le président a demandé un vote par acclamation concernant la résolution 2013.09.10.NG02. Cherine Chalaby, Fadi Chehadé, Chris Disspain, Bill Graham et Mike Silber ont voté en faveur de la résolution 2013.09.10.NG02. Olga Madruga-Forti, Ray Plzak, George Sadowsky et Kuo-Wei Wu se sont abstenus de voter sur la résolution 2013.09.10.NG02. Erika Mann et Gonzalo Navarro n'étaient pas disponibles pour voter sur la résolution 2013.09.10.NG02. La résolution a été adoptée.

      Fondements de la résolution 2013.09.10.NG02

      En vertu des statuts de l'ICANN, le Comité de gouvernance du Conseil doit évaluer les demandes de reconsidération et faire des recommandations au Conseil d'administration. Voir article IV, section 3 des statuts. Le Comité du programme des nouveaux gTLD (« NGPC »), à qui ont été délégués les pouvoirs du Conseil d'administration en la matière, a examiné et considéré en profondeur la recommandation du BGC concernant la demande de reconsidération 13-5 et a trouvé l'analyse correcte.

      Le fait d'avoir un processus de reconsidération à travers lequel le BGC effectue une révision et, s'il le désire, recommande l'approbation du Conseil/NGPC a des effets positifs sur la transparence et la responsabilité de l'ICANN. Cette approche permet à la communauté de s'assurer que le personnel et le Conseil agissent dans le respect des politiques, des règlementations et des statuts constitutifs de l'ICANN.

      La demande cherchait à obtenir une annulation de la décision du panel de révision de la similarité de chaînes (le « panel »), datée du 26 février 2013, de placer la candidature de Booking.com pour .hotels dans le même ensemble conflictuel que .hoteis. En particulier, Booking.com soutenait que la chaîne objet de candidature pour .hotels pouvait coexister dans la zone racine avec la chaîne .hoteis sans inquiétude en termes de confusion et que, par conséquent, .hotels ne devrait pas être placée dans le même ensemble conflictuel que .hoteis.

      La demande nécessite les réflexions suivantes : (1) si le panel a enfreint une politique ou un processus dans le cadre de la réalisation de sa révision de similarité visuelle de la candidature de Booking.com et (2) si le NGPC a la capacité de faire annuler la décision du panel concernant .hotels/.hoteis en partant du principe que la décision avait été fournie en tant que « conseil à l'ICANN » et que l'ICANN avait pris la décision ultime d'accepter ce conseil.

      Le BGC a noté qu'une demande de reconsidération similaire avait été auparavant soumise par Booking.com le 28 mars 2013 et placée en suspens dans l'attente de l'achèvement d'une demande au titre de la politique de divulgation de documents annexes de l'ICANN. Par conséquent, la demande se rapporte à la date de la déposition initiale et devrait être évaluée conformément aux statuts qui étaient en vigueur du 20 décembre 2012 au 10 avril 2013.

      Par rapport à la première question, le BGC a révisé les arguments indiqués dans la demande, y compris les pièces jointes, et a conclu que Booking.com n'avait pas énoncé une demande de reconsidération d'une action du personnel de manière appropriée parce que Booking.com n'avait pas réussi à identifier une politique ou un processus enfreints par le personnel. Le BGC a indiqué que Booking.com ne suggérait pas que le processus pour la révision de la similarité de chaînes exposé dans le guide de candidature, n'avait pas été respecté ou que le personnel de l'ICANN avait enfreint une politique établie par l'ICANN en acceptant la décision du panel de placer .hotels et .hoteis dans le même ensemble conflictuel. Booking.com cherche plutôt à supplanter ce qu'elle estime que la méthodologie d'appréciation de la similarité visuelle aurait dû être par opposition à la méthodologie formulée dans la section 2.2.1.1.2 du guide de candidature et demande que le BGC, (et le Conseil par le biais du comité du programme des nouveaux gTLD) juge à nouveau la décision du 26 février 2013 selon la méthodologie qu'elle propose. Le BGC a conclu que ceci ne constituait pas un motif de reconsidération suffisant parce que le processus de reconsidération n'avait pas pour finalité d'être un mécanisme permettant de juger à nouveau des décisions des panels d'évaluation.

      Par rapport à l'assertion de Booking.com selon laquelle la décision du 26 février 2013 avait été prise sans informations matérielles, telles que l'opinion de l'expert linguistique de Booking.com ou d'autres « informations qui réfuteraient l'assertion erronée selon laquelle il y aurait confusion du consommateur entre '.hotels' et '.hoteis', le BGC a conclu qu'il n'existe pas de processus dans la révision de similarité de chaînes pour que les candidats soumettent des informations supplémentaires. Comme l'ICANN l'a expliqué à Booking.com en réponse à ses demandes au titre de la DIDP concernant la révision de la similarité de chaînes, la révision était basée sur la méthodologie décrite dans le guide de candidature, complétée par les documents pertinents au processus. le processus ne permet pas de contributions supplémentaires. Le BGC avait indiqué que le désaccord de Booking.com sur la mesure dans laquelle la méthodologie aurait dû résulter en une conclusion de similarité visuelle, ne signifie pas que l'ICANN (y compris les fournisseurs tiers réalisant des révisions de similarité de chaînes) ait enfreint une politique quelconque en parvenant à la décision (ni qu'il y aurait lieu de soutenir que la décision ait été en fait erronée).

      Quant à la deuxième question, le BGC a conclu que la suggestion de Booking.com selon laquelle le Conseil (par le biais du NGPC) avait la capacité de faire annuler la décision du panel sur .hotels/.hoteis parce que le panel a simplement fourni un « conseil à l'ICANN » et que l'ICANN avait pris la décision ultime d'accepter ce conseil, se base sur des conclusions inexactes du processus de révision de similarité de chaînes. Ainsi, le BGC a conclu que Booking.com n'avait pas avancé d'arguments suffisants pour une reconsidération. Le BGC a indiqué que toutes les chaînes faisant l'objet de candidatures étaient révisées par le panel conformément aux normes et à la méthodologie de révision de similarité de chaînes visuelle décrite dans le guide de candidature. Le guide de candidature précise qu'une fois les ensembles conflictuels établis par le panel, l'ICANN notifiera les candidats et publiera les résultats sur son site Internet. (AGB, section 2.2.1.1.1.) Que les résultats soient transmis en tant que « conseils » ou « conclusions » ou « rapports », l'ICANN a toujours précisé qu'elle se fierait aux conseils de ses évaluateurs durant la phase d'évaluation initiale du programme des nouveaux gTLD, sous réserve des mesures d'assurance qualité. La réception et l'examen subséquents de l'avis du GAC sur les versions au singulier et au pluriel de la même chaîne ne changent pas le processus établi pour l'élaboration des ensembles conflictuels sur la base de la similarité visuelle, le Conseil d'administration de l'ICANN étant tenu, selon les statuts, d'examiner l'avis du GAC sur des questions de politique publique, telles que celle des versions des chaînes au singulier et au pluriel. Le BGC a conclu que Booking.com était en fait en train de proposer un nouveau processus différent lorsqu'elle suggérait que l'ICANN devrait réaliser une révision approfondie (au lieu d'analyses du processus) des résultats du panel de révision de similarité de chaînes avant la finalisation des ensembles conflictuels.

      En plus de ce qui précède, la totalité de la recommandation du BGC qui peut être consultée sur http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-booking-01aug13-en.pdf [PDF, 117 KB] et qui est jointe à la documentation de référence soumise au Conseil pour appuyer cette résolution, sera aussi considérée comme faisant partie de ces fondements.

      L'adoption de la recommandation du BGC n'a aucun impact financier sur l'ICANN et n'aura pas d'impact négatif sur la sécurité systémique, la stabilité et la résilience du système de noms de domaine.

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

      Les membres du comité qui se sont abstenus de voter ont fait les déclarations suivantes. Ray Plzak a indiqué qu'il s'abstenait de voter parce qu'il était déçu par ce qui est fait pour remédier à la situation. Ray souhaiterait voir plus de détermination à régler le processus.

      Olga Madruga-Forti a déclaré que le BGC avait fait un travail adéquat en appliquant une norme de révision limitée à la candidature reconsidérée, mais que, malheureusement, dans ce cas, appliquer cette révision limitée tout en manquant d'informations concernant les fondements de la décision du panel de révision de similarité de chaînes ne pouvait se faire de manière logique et équitable. L'intérêt public ne serait pas desservi par l'application de la norme de révision limitée sans informations adéquates concernant les fondements et le raisonnement sous-tendant la décision du panel. A mon avis, l'intérêt public serait moeux desservi si l'on s'abstenait et continuait à explorer des moyens pour établir un meilleur compte-rendu des fondements de la décision du panel de révision de similarité de chaînes dans des circonstances telles que celles-ci.

      Kuo-Wei Wu était d'accord avec les déclarations de Ray et d'Olga.

      George Sadowsky a fait la déclaration suivante sur ce vote : Je ressens une grande inquiétude quant à la ratification de la recommandation du BGC de refuser la demande de reconsidération relative au conflit de chaînes entre .hoteis et .hotels. Je me suis donc abstenu de voter sur cette question.

      Le processus de reconsidération est un instrument très étroitement concentré, s'appuyant uniquement sur l'examen des écarts par rapport au processus établi et convenu. En tant que tel, il peut être utile mais son champ d'application est limité. En particulier, il n'aborde pas des situations où le processus a été en fait respecté mais où les résultats d'un tel processus ont été considérés, quelquefois largement, contraires à ce qui serait le mieux pour d'importants secteurs ou pour tous les secteurs de la communauté de l'ICANN et/ou des utilisateurs d'Internet en général.

      Les fondements sous-tendant le refus de la demande de reconsidération consistent essentiellement en le fait que le processus de similarité de chaînes a trouvé qu'il était probable d'avoir une confusion considérable entre les deux et, donc, qu'elles appartenaient à un ensemble conflictuel. De plus, aucun processus n'a été identifié comme ayant été enfreint et donc, il n'y a rien à reconsidérer.

      En tant que membre du Conseil au courant des statuts de l'ICANN, je ne peux pas voter contre la motion de refuser la reconsidération. La motion apparaît correcte compte tenu des critères décrits dans les statuts et qui définissent le processus de reconsidération, et compte tenu des faits dans ce cas particulier.

      Toutefois, je suis de plus en plu gêné par la séquence grandissante de décisions qui sont basées sur un critère relatif à la confusion de l'utilisateur qui, à mon avis, n'est pas uniquement incomplet et défectueux mais semble fonctionner directement contre le concept selon lequel les utilisateurs ne devraient pas être déroutés. Je suis convaincu par l'argument présenté par les partisans de la reconsidération dans ce cas, à savoir qu'en fait, les utilisateurs ne confondront pas .hoteis avec .hotels, puisque s'ils saisissent le mauvais nom, ils seront très probablement immédiatement confrontés à des informations dans une langue à laquelle ils ne s'attendaient pas.

      La confusion est une question de perception. La similarité de chaînes ne représente qu'une considération de la réflexion sur la confusion de perception. En fait, ce n'est pas toujours le problème. A mon avis, il y aura beaucoup plus de confusion de perception entre .hotel et .hotels qu'entre .hotels et .hoteis. Pourtant, si l'on suit le guide de candidature à la lettre et quelles que soient les instructions données ou pas par les experts de similarité de chaînes, j'estime que nous travaillons contre la mise en oeuvre de décisions qui aident à éviter la confusion des utilisateurs et que nous travaillons en faveur de décisions basées sur une analyse ex ante incorrecte, incomplète et défectueuse des questions réelles en matière de confusion de l'utilisateur.

      Le but du processus de similarité de chaînes est de réduire au maximum la confusion de l'utilisation et de garantir la confiance de l'utilisateur dans l'utilisation du DNS. L'exercice de similarité de chaînes est l'un des moyens inclus dans le processus des nouveaux gTLD pour réduire au maximum une telle confusion et renforcer la confiance de l'utilisateur. En mettant l'accent et en fait, en concentrant nos décisions uniquement sur la similarité de chaînes, nous sommes involontairement en train de substituer le moyen au but et de prendre des décisions se rapportant au but sur la base d'un essai de moyen. Il s'agit d'un mauvais service rendu à la communauté des internautes.

      Je ne peux pas voter et je ne voterai pas en faveur d'une motion qui reflète, directement ou indirectement, une réticence à abandonner ce que j'estime être une position si défectueuse qui ne reflète pas, à mon avis, la compréhension de la réalité actuelle de la situation.

      Le comité a convenu de discuter encore du processus lors de sa réunion à Los Angeles.

    3. Communiqué du GAC de Durban – examen approfondi de la fiche de suivi

      Chris Disspain a entraîné le comité dans une discussion de chacun des points de la fiche de suivi proposée pour aborder l'avis du GAC transmis dans le communiqué de Durban. Chris a indiqué que le créneau permettant aux candidats de répondre à l'avis du GAC était clos et que les commentaires pouvaient être examinés par le comité.

      Le comité a dit qu'il était nécessaire de disposer d'une période de temps supplémentaire pour examiner sa position par rapport à l'avis d'objection consensuel du GAC concernant .AMAZON compte tenu des informations présentées dans la réponse du candidat.

      Chris a indiqué que, récemment, une série de communications concernant la candidature .THAI avaient été fournies au comité, ce qui soutient le fait que l'avis du GAC n'était pas fondé. Chris a précisé que la position du GAC par rapport à son avis consensuel sur la candidature pour .THAI est appuyée par le gouvernement de Thailande.

      Chris a discuté la position proposée dans la fiche de suivi pour .SPA, .YUN, .GUANGZHOU et .SHENZHEN. Kuo-Wei Wu a demandé si la réponse proposée dans la fiche de suivi s'appliquait à toutes les chaînes avec indicateurs géographiques. Chris a précisé que la fiche de suivi concernant uniquement les chaînes pour lesquelles le GAC avait émis un avis.

      Le comité a également discuté la nouvelle correspondance du GAC au sujet de .WINE et .VIN. Heather Dryden a reconnu la complexité de la question et a indiqué que bien que le GAC ne soit pas parvenu à un consensus, il y avait tout intérêt à ce que le comité comprenne bien les raisons justifiant les points de vue différents parmi les membres du GAC par rapport aux candidatures pour .VIN et .WINE. Le comité a décidé d'examiner l'avis lors de sa prochaine réunion à Los Angeles.

      Le comité a examiné les autres points de la fiche de suivi.

      Chris Disspain a proposé et George Sadowsky a appuyé la résolution.

      Le Conseil a ensuite pris la décision suivante :

      Attendu que le GAC s'est réuni lors de la 47e réunion de l'ICANN à Durban et a émis un communiqué le 18 juillet 2013 (« Communiqué de Durban »).

      Attendu que, le 1 août 2013, l'ICANN a publié le communiqué de Durban et en a officiellement informé les candidats, <http://newgtlds.icann.org/en/announcements-and-media/announcement-01aug13-en> démarrant la période de réponse des candidats de 21 jours conformément au module 3.1 du Guide de candidature.

      Attendu que le NGPC s'est réuni le 12 août 2013 pour examiner un plan de réponse à l'avis du GAC relatif au programme des nouveaux gTLD, transmis au Conseil dans le Communiqué de Durban.

      Attendu que le NGPC a évalué les réponses des candidats envoyées pendant la période de 21 jours de réponse des candidats, et que le NGPC a identifié des points de l'avis dans la fiche de suivi ci-jointe où sa position est cohérente avec l'avis du GAC du Communiqué de Durban.

      Attendu que le NGPC a élaboré une fiche de suivi pour répondre à l'avis du GAC du Communiqué de Durban semblable à celle qui avait été utilisée pour aborder l'avis de Beijing et lors des réunions du GAC et du Conseil à Bruxelles le 28 février et le 1er mars 2011, et qu'il a identifié la cohérence entre le NGPC et l'avis du GAC, en les signalant comme points « 1A ».

      Attendu que le NGPC entreprend cette action conformément à l'autorisation qui lui a été accordée par le Conseil le 10 avril 2012 pour exercer l'autorité du Conseil de l'ICANN sur toutes les questions pouvant apparaître quant au Programme des nouveaux gTLD.

      Résolu (2013.09.10.NG03), le NGPC adopte la « fiche de suivi du comité du programme des nouveaux gTLD du Conseil de l'ICANN en réponse au communiqué du GAC de Durban » (10 septembre 2013), jointe en tant que annexe 1 [PDF, 119 KB] à cette résolution, en réponse aux points de l'avis du GAC transmis dans le communiqué de Durban, tel que présenté dans la fiche de suivi.

      Tous les membres du Conseil présents ont voté en faveur de la résolution 2013.09.10.NG03. Erika Mann et Gonzalo Navarro n'étaient pas disponibles pour voter sur la résolution 2013.09.10.NG03. La résolution a été adoptée.

      Fondements de la résolution 2013.09.10.NG03

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

      L'article XI, section 2.1 des Statuts de l'ICANN <http://www.icann.org/fr/about/governance/bylaws#XI> permet au GAC de « soumettre directement des questions au Conseil, soit par la voie d'un commentaire, soit par un avis préalable, ou encore en recommandant une action spécifique ou le développement d'une nouvelle politique ou la révision des politiques actuelles ». Le GAC a soumis son avis au Conseil sur le programme des nouveaux gTLD dans son communiqué de Durban daté du 18 juillet 2013. Les statuts de l'ICANN demandent au Conseil de tenir compte de l'avis du GAC en matière de politique publique pour la formulation et l'adoption des politiques. Au cas où le Conseil d'administration de l'ICANN déciderait d'agir contrairement à l'avis du GAC, il est tenu d'en avertir ce dernier, en précisant les raisons pour lesquelles l'avis n'a pas été suivi. Le Conseil d'administration et le GAC tenteront ensuite, en toute bonne foi, de trouver une solution réciproquement acceptable. S'ils ne trouvent pas de solution, le Conseil déclarera dans sa décision finale les raisons pour lesquelles l'avis du GAC n'a pas été suivi.

      Quelle est la proposition à l'étude ?

      Il est demandé au NGPC d'envisager d'accepter l'avis du GAC de Durban tel que décrit dans la fiche de suivi du comité du programme des nouveaux gTLD du Conseil d'administration de l'ICANN en réponse au communiqué du GAC de Durban (10 septembre 2013). Comme il est indiqué dans la fiche de suivi, la plupart des points de l'avis sont caractérisés « 1A », ce qui indique que la position du NGPC est en accord avec l'avis du GAC tel que décrit dans la fiche de suivi.

      Quelles parties intéressées ou autres ont été consultées?

      Le 1 août 2013, l'ICANN a publié l'avis du GAC et en a officiellement informé les candidats, <http://newgtlds.icann.org/en/announcements-and-media/announcement-01aug13-en> démarrant la période de réponse des candidats de 21 jours conformément au module 3.1 du Guide de candidature. Toutes les réponses des candidats sont fournies sur : http://newgtlds.icann.org/en/applicants/gac-advice/durban47. Le NGPC a tenu compte des réponses des candidats dans la formulation de sa réponse à l'avis du GAC, le cas échéant.

      Quelles sont les préoccupations ou les questions soulevées par la communauté ?

      Dans le cadre de la période de réponse des candidats de 21 jours, plusieurs des candidats ont indiqué avoir entamé un dialogue avec les parties impliquées et prévoyaient parvenir à un accord concernant les sujets d'inquiétude. Certains des candidats notaient qu'ils avaient proposé des sauvegardes supplémentaires pour aborder les préoccupations des gouvernements pertinents mais n'étaient pas sûrs de pouvoir parvenir à un accord. Ces candidats demandaient que le Conseil de l'ICANN permettent l'avancement de leurs candidatures même si un accord n'était pas établi avec les parties pertinentes. De plus, des demandes ont été faites pour savoir si les candidats et les gouvernements pertinents auraient la possibilité de commenter les conversations tenant lieu entre le GAC, le Conseil d'administration de l'ICANN et le personnel de l'ICANN. Des demandes ont été exprimées quant au fait que le GAC, le NGPC et le personnel de l'ICANN consultent les candidats avant la prise de décisions concernant des sauvegardes supplémentaires.

      D'autres candidats notaient le rôle important des gouvernements dans le modèle multi-parties prenantes, mais conseillaient que le NGPC ne permette pas aux gouvernements d'exercer des pouvoirs de veto aux politiques de l'ICANN adoptées par le biais du processus multi-parties prenantes.

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

      Dans le cadre de ses délibérations, le NGPC a examiné les documents suivants :

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

      En adoptant sa réponse à l'avis du GAC transmis dans le communiqué de Durban, le NGPC a tenu compte des commentaires soumis par les candidats, de l'avis du GAC transmis dans le communiqué de Durban et des procédures établies dans le guide de candidature (AGB).

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

      L'adoption de l'avis du GAC telle que fournie dans la fiche de suivi ci-jointe aidera à résoudre l'avis du GAC de sorte que le plus grand nombre de candidatures à de nouveaux gTLD puissent progresser le plus tôt possible.

      Y a-t-il un impact fiscal ou des répercussions à prévoir sur l'ICANN (plan stratégique, plan opérationnel, budget), sur la communauté et/ou sur le public ?

      Aucun impact fiscal associé à l'adoption de cette résolution n'est prévu.

      Y a-t-il des implications sur la sécurité, la stabilité ou la résilience du DNS ?

      L'approbation de la résolution proposée n'aura pas d'impact sur les questions de sécurité, de stabilité ou de résilience liées au DNS.

      S'agit-il d'un processus de développement de politiques défini au sein des organisations de soutien de l'ICANN ou bien d'une fonction organisationnelle administrative de l'ICANN nécessitant une consultation publique ou ne nécessitant pas de commentaires du public ?

      L'ICANN a publié l'avis du GAC et en a officiellement notifié les candidats le 1er août 2013. Cela a donné lieu au démarrage de la période de réponse des candidats de 21 jours conformément au module 3.1 du Guide de candidature.

    4. Communiqué du GAC de Beijing – fiche de suivi

      Le comité a débattu sur les points en suspens de l'avis du GAC transmis dans le communiqué de Beijing, y compris les catégories 1 et 2 de l'avis de sauvegarde et les protections pour les OIG.

      Chris Disspain a fourni au comité une mise à jour de la proposition actuelle concernant les protections pour les OIG ce qui influencerait la fonction actuelle de réclamations du Bureau central de marques et le processus du système uniforme de suspension rapide. Chris a indiqué qu'il pourrait y avoir une réunion entre le NGPC et les OIG vers la fin de septembre pour discuter d'une proposition d'approche pour la fourniture de protections.

      Par rapport à l'avis de sauvegarde de catégorie 2, Christine Willet a fourni au comité une mise à jour des réponses reçues de la part de candidats à des chaînes identifiées dans l'avis du GAC comme concernant un accès exclusif pour une chaîne générique. Akram Atallah a noté que les réponses des candidats reçues à ce jour indiquaient que seule une poignée de candidats avait l'intention de fournir un accès de registre exclusif.

      Le comité a convenu de discuter de la voie à suivre pour l'avis de sauvegarde de catégorie 2 lors de sa prochaine réunion.

    5. Communiqué du GAC de Beijing – catégorie 1

      Chris Disspain a fourni au comité une mise à jour sur la proposition d'approche pour répondre à l'avis du GAC transmis dans le communiqué de Beijing concernant les sauvegardes de catégorie 1, et le comité a discuté de la voie à suivre. La discussion a aussi porté sur les modalités de mise en oeuvre des sauvegardes en tant que dispositions contractuelles et de la distinction à faire dans la liste des chaînes de catégorie 1 entre les chaînes associées à des secteurs réglementés et toutes les autres chaînes énumérées.

      Chris a recommandé une stratégie pour un progrès continu par rapport à l'avis de sauvegarde de catégorie 1. La recommandation comprenait la préparation d'un document décrivant le cadre proposé pour aborder l'avis et la diffusion de ce document à un petit nombre de membres du GAC avant sa communication à l'ensemble du GAC.

      Jonne Soininen a recommandé que les membres du GAC de pays non-anglophones soient inclus dans les discussions. Olga Madruga-Forti était d'accord avec la recommandation.

      Heather Dryden a ajouté que tous les membres du GAC devraient pouvoir participer au processus, selon le cas, avant que le comité ne finalise la proposition.

      Jonne a demandé s'il y avait des différences nationales qui pourraient causer des inquiétudes de la part du GAC quant à ce qui est considéré comme secteur réglementé et ce qui ne l'est pas. Olga a noté qu'il était important de commencer à réfléchir sur les conséquences en cas de non conformité avec les obligations contractuelles associées aux sauvegardes de catégorie 1.

      Le comité a reconnu la difficulté de programmation d'une réunion intersessions avec le GAC sur ce sujet, compte tenu du timing de la réunion de Buenos Aires, et a réfléchi sur le chemin à suivre avant la réunion de Buenos Aires.

    6. Déclaration de l'ALAC sur le traitement préférentiel pour les candidatures de la communauté en cas de conflit de chaînes

      George Sadowsky a présenté au comité un aperçu général des préoccupations exprimées par l'ALAC dans sa déclaration sur le traitement préférentiel pour les candidatures de la communauté en cas de conflit de chaînes, ajoutant que l'ALAC avait demandé au comité de prévoir un traitement préférentiel pour les candidatures satisfaisant les caractéristiques de candidatures de la communauté même si elles n'avaient pas été soumises en tant que telles.

      George a indiqué avoir eu des discussions avec l'auteur de la déclaration de l'ALAC pour mieux comprendre les inquiétudes sous-tendant la lettre de l'ALAC.

      Le comité a discuté sur les préoccupations liées à la mise en application de la recommandation de l'ALAC. Chris Disspain a souligné le besoin de cohérence avec la position que le comité a communiqué au GAC concernant cette question.

      George a indiqué qu'il pourrait être difficile d'accepter la recommandation de la déclaration de l'ALAC et Ray Plzak était d'accord avec lui.

      George a convenu de travailler avec le personnel pour préparer une réponse à l'ALAC et a noté que la réponse devrait inclure un examen des questions supplémentaires envoyées par l'ALAC après avoir soumis sa déclaration.

    7. Déclaration de l'ALAC sur l'expertise de la communauté dans l'évaluation avec priorité à la communauté

      George Sadowsky a présenté les préoccupations exprimées dans la déclaration de l'ALAC sur l'expertise de la communauté dans l'évaluation avec priorité à la communauté, indiquant que l'ALAC doute de la capacité de l'évaluateur choisi à évaluer la priorité à la communauté, par rapport à une façon de penser orientée communauté par opposition à une façon de penser orientée métier.

      Le comité a examiné s'il était adéquat d'accepter l'avis de l'ALAC et sa proposition de fournir des évaluateurs de la communauté pour le panel. George a recommandé de ne pas adopter cette approche. Ray Plzak était d'accord et a ajouté que le comité ne devrait pas établir un précédent en termes d'invitation d'autres personnes à assister le travail des panels, en dehors du processus existant établi pour la composition des panels.

      George a proposé que le comité enjoigne au personnel d'avertir le panel des préoccupations exprimées dans la déclaration de l'ALAC. George a aussi ébauché une proposition de réponse à l'ALAC et a convenu de travailler avec le personnel pour rédiger une réponse officielle.

      George a ajouté qu'à l'achèvement du processus d'évaluation avec priorité à la communauté, il pourrait être utile de réaliser un audit informel afin d'examiner toutes enfreintes flagrantes de perception de l'évaluation avec priorité à la communauté

    8. Autres points à l'ordre du jour

      Le comité n'a pas discuté d'autres points et le président a ensuite levé la séance.

minutes-new-gtld-10sep13-fr.pdf  [273 KB]

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