Skip to main content
Resources

Résolutions 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 : http://www.icann.org/en/groups/board/documents/resolutions-28sep13-en.htm

 

  1. Ordre du jour convenu
    1. Approbation du procès-verbal du Conseil d'administration
    2. Délégation d'un ccTLD pour l'Iran en caractères arabes
    3. Les recommandations de PDP de la GNSO en matière de verrouillage d'un nom de domaine faisant l'objet de procédures UDRP
    4. Mise en oeuvre des améliorations de l'organisation de soutien relative aux noms de codes de pays (ccNSO)
    5. Révision de la GNSO
  2. Ordre du jour principal
    1. Nomination du président et du président-élu du comité de nomination 2014
    2. Traitement des coûts de développement historique des nouveaux gTLD
    3. Processus proposé pour les amendements de charte du regroupement et du groupe de parties prenantes de la GNSO
    4. Clarification concernant les critères de mesure de concurrence, confiance du consommateur et choix du consommateur pour le programme des nouveaux gTLD selon la révision de l'affirmation d'engagements (AoC)

 

  1. Ordre du jour convenu :

    1. Approbation du procès-verbal du Conseil d'administration

      Résolu (2013.09.28.01), le Conseil approuve les procès-verbaux des réunions du Conseil d'administration de l'ICANN du 17 juillet, 18 juillet et 22 août 2013.

    2. Délégation d'un ccTLD pour l'Iran en caractères arabes

      Résolu (2013.09.28.02), dans le cadre de l'exercice de ses responsabilités en vertu du contrat des fonctions IANA, l'ICANN a révisé et évalué la demande de délégation du domaine de premier niveau de code pays ایران (« Iran ») à l'Institut de recherche en sciences fondamentales. La documentation montre que les procédures appropriées ont été suivies pour l'évaluation de la demande.

      Résolu (2013.09.28.03), le Conseil ordonne, qu'en vertu de l'article III, section 5.2 des statuts de l'ICANN, certaines parties des fondements ne se prêtant pas pour l'instant à une distribution publique dans le cadre des résolutions, du rapport préliminaire ou du procès-verbal compte tenu des obligations contractuelles, soient retenues jusqu'à ce que leur publication soit autorisée conformément aux obligations contractuelles pertinentes.

      Fondements des résolutions 2013.09.28.02 – 2013.09.28.03

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

      Conformément au contrat des fonctions IANA, le personnel de l'ICANN a évalué la demande de délégation de ccTLD et présente son rapport au Conseil d'administration pour révision. Cette révision du Conseil d'administration vise à assurer que le personnel de l'ICANN ait suivi les procédures appropriées.

      Quelle est la proposition à l'étude ?

      La proposition est d'approuver une demande faite au département IANA de l'ICANN de créer un domaine de premier niveau de code pays et d'attribuer le rôle d'organisation commanditaire (également appelée gestionnaire ou administrateur) à l'Institut de recherche en sciences fondamentales.

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

      Au cours de l'évaluation d'une demande de délégation, le personnel de l'ICANN consulte le candidat, et d'autres parties concernées. Dans le cadre du processus de candidature, le candidat doit décrire les consultations effectuées dans le pays concernant le ccTLD et la possibilité d'application dans leur communauté Internet locale.

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

      Le personnel n'est au courant d'aucune question ou préoccupation soulevées par la communauté concernant cette demande.

      [Fondements supprimés]

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

      Le Conseil d'administration n'a identifié aucun facteur d'inquiétude spécifique concernant cette demande.

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

      L'approbation en temps opportun des administrateurs de noms de domaine de code pays répondant aux divers critères d'intérêt public est positive vis-à-vis de la mission globale de l'ICANN et les communautés locales, dont les domaines de premier niveau de code pays sont désignés pour desservir, et répondent aux obligations de l'ICANN établies en vertu du contrat des fonctions IANA.

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

      La gestion des délégations des codes pays dans la zone racine du DNS fait partie des fonctions IANA, et le processus de délégation ne devrait pas produire une variation significative des dépenses prévues. Ce n'est pas le rôle de l'ICANN d'évaluer l'impact financier des opérations internes des domaines de premier niveau de code pays à l'intérieur d'un pays.

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

      L'ICANN ne croit pas que cette demande pose des risques significatifs par rapport à la sécurité, la stabilité ou la résilience.

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

    3. Les recommandations de PDP de la GNSO en matière de verrouillage d'un nom de domaine faisant l'objet de procédures UDRP

      Attendu que le 15 décembre 2011, le conseil de la GNSO a lancé un processus de développement de politique (PDP) portant sur le verrouillage d'un nom de domaine faisant l'objet de procédures de règlement uniforme des litiges relatifs aux noms de domaine (UDRP) traitant de cinq questions de charte, présenté sur https://community.icann.org/x/ma-bAQ.

      Attendu que le PDP a suivi les étapes prévues dans les statuts, qui ont donné lieu au rapport final délivré le 5 juillet 2013.

      Attendu que le groupe de travail sur le verrouillage d'un nom de domaine faisant l'objet de procédures UDRP (GT) est parvenu à un consensus quant aux recommandations liées aux questions exposées dans la charte.

      Attendu que le conseil de la GNSO a examiné discuté les recommandations du groupe de travail sur le verrouillage d'un nom de domaine faisant l'objet de procédures UDRP et a adopté les recommandations le 1er août 2013 par majorité qualifiée et vote unanime (voir http://gnso.icann.org/en/council/resolutions#201308).

      Attendu que le vote du conseil de la GNSO a atteint et dépassé le nombre de voix nécessaires pour imposer de nouvelles obligations aux parties contractantes de l'ICANN.

      Attendu qu'après le vote du conseil de la GNSO, une période de consultation publique relative aux recommandations approuvées a été tenue et que les commentaires reçus ont été résumés et pris en considération (http://www.icann.org/en/news/public-comment/locking-domain-name-recommendations-02aug13-en.htm).

      Résolu (2013.09.28.04), le Conseil adopte les recommandations de politique du conseil de la GNSO sur le verrouillage d'un nom de domaine faisant l'objet de procédures UDRP tel que présenté dans le rapport final (voir http://gnso.icann.org/fr/issues/locking/domain-name-final-05jul13-fr.pdf [PDF, 1.25 MB]).

      Résolu (2011.0.28.06), le président et directeur général développera et complètera un plan de mise en œuvre pour ces recommandations et poursuivra la communication avec la communauté concernant ces travaux.

      Fondements des résolutions 2013.09.28.04 – 2013.09.28.05

      Pourquoi le Conseil d'administration aborde-t-il cette question maintenant?

      Actuellement, il n'y a aucune exigence concernant le verrouillage des noms de domaine pendant la période comprise entre la déposition d'une plainte et le début des procédures, ni aucune définition de 'status quo', ce qui a amené à différentes interprétations de la politique et à la confusion. Pour aborder cette question, le conseil de la GNSO a décidé d'amorcer un processus de développement de politique (PDP) le 15 décembre 2011. Dans le cadre de ses délibérations, le groupe de travail devait examiner les questions suivantes :

      1. s'il serait souhaitable de créer une ébauche de procédure devant être suivie par le demandeur afin que le bureau d'enregistrement place le nom de domaine sous verrouillage.

      2. s'il serait souhaitable de créer un plan des étapes du processus qu'un bureau d'enregistrement s'attendrait, raisonnablement, à être suivi pendant un litige UDRP.

      3. si le délai pendant lequel le bureau d'enregistrement doit verrouiller un nom de domaine après le dépôt d'un UDRP devrait être normalisé.

      4. a. s'il fallait définir ce qui constitue un nom de domaine « verrouillé ».

        b. si, après verrouillage d'un nom de domaine en vertu d'une procédure UDRP, les informations relatives au titulaire de ce nom de domaine pouvaient être changées ou modifiées.

      5. si des sauvegardes supplémentaires devraient être créées pour protéger les titulaires de noms de domaine au cas où le nom de domaine serait verrouillé en vertu d'une procédure UDRP.

      Le groupe de travail a publié son premier rapport pour consultation publique le 15 mars 2013, suivi par son rapport final le 5 juillet 2013. Ce dernier a fait l'objet d'un consensus unanime de la part du groupe de travail sur le PDP ainsi que de la part du conseil de la GNSO. Suite à la clôture de la période de consultation publique, l'étape suivante, tel que prévu dans l'Annexe A des statuts de l'ICANN, consiste en l'examen des recommandations par le Conseil d'administration de l'ICANN.

      Quelle est la proposition à l'étude ?

      Les recommandations suivantes sont envisagées :

      Recommandation nº 1 : Dans ce contexte, le terme « verrouillage » signifie empêcher tous changements de bureau d'enregistrement et de titulaire de nom de domaine. Ce « verrouillage » ne devrait pas affecter la résolution du nom de domaine uniquement sur la base du fait qu'une plainte ait été déposée sous l'UDRP ou uniquement sur la base du fait que la procédure UDRP soit en cours.1

      Recommandation nº 2 : Modifier la disposition des règles UDRP qui stipule qu'après soumission de la plainte au fournisseur UDRP, le demandeur devrait aussi 'déclarer qu'une copie de la plainte […] a été envoyée ou transmise au défendeur' (section 3, b – xii) et recommander que, comme meilleure pratique, les demandeurs n'aient pas besoin d'informer les défendeurs qu'une plainte a été déposée afin d'éviter le 'cyberflight' (le transfert d'un nom de domaine par le titulaire afin d'éviter une action dans le cadre d'une procédure UDRP). Le fournisseur UDRP sera responsable d'informer le défendeur dès que les procédures officielles auront commencé.

      Recommandation nº 3 : Suite à la réception de la plainte, le fournisseur UDRP, après avoir effectué un contrôle préliminaire de déficience2, enverra une demande de vérification au bureau d'enregistrement, y compris la demande d'empêcher tous changements de bureau d'enregistrement et de titulaire du nom de domaine (« verrouillage »). Le bureau d'enregistrement n'est pas autorisé à notifier le titulaire du nom de domaine de la procédure en cours jusqu'à ce que tous changements de bureau d'enregistrement et de registrant aient été empêchés, mais pourra le faire lorsque tous changements de bureau d'enregistrement et de titulaire de nom de domaine auront été empêchés. Dans le cas de fournisseurs de services d'anonymisation / d'intermédiation accrédités3 ou de fournisseurs de services d'anonymisation / d'intermédiation affiliés au bureau d'enregistrement, le bureau d'enregistrement peut contacter ledit fournisseur de services accrédité / affilié afin d'autoriser le dévoilement des données de son client. Toutefois, ce contact ne peut être établi qu'après un verrouillage initial destiné à prévenir tout changement de bureau d'enregistrement ou de titulaire de nom de domaine.

      Recommandation nº 4 : Dans les deux jours ouvrables4 au plus tard après réception de la demande de vérification de la part du fournisseur UDRP, le bureau d'enregistrement modifiera le statut de l'enregistrement dans le but d'empêcher tout changement de bureau d'enregistrement ou de titulaire de nom de domaine (« verrouillage »). Le bureau d'enregistrement continuera à empêcher les changements durant tout le déroulement de la procédure UDRP, sauf en cas de suspension d'une procédure UDRP (voir recommandation nº 10). Le déroulement est défini commencer au moment où une plainte UDRP, ou un document pertinent ayant déclenché une procédure ou un arbitrage par devant les tribunaux, concernant un nom de domaine, ont été déposés par le demandeur au fournisseur UDRP, selon le cas. Toutes mises à jour5 résultant d'une demande du fournisseur de services d'anonymisation / d'intermédiation accrédité / affilié de dévoiler les données du client doit être faite avant la fin de la période de deux jours ouvrables ou avant que le bureau d'enregistrement vérifie l'information demandée et confirme le verrouillage au fournisseur UDRP, selon ce qui intervient en premier.

      Un bureau d'enregistrement ne peut autoriser le transfert à un autre titulaire de nom de domaine6 ou bureau d'enregistrement après réception par le bureau d'enregistrement d'une demande de vérification de la part du fournisseur UDRP, à l'exception de cas limités impliquant un arbitrage n'étant pas réalisé au titre de la politique ou impliquant un litige tel qu'établi dans les paragraphes 8(a) et 8(b) de la politique UDRP. Pour les besoins de l'UDRP, le titulaire de nom de domaine inscrit dans les listes du registre Whois au moment du verrouillage sera considéré comme défendeur. Tout changement des données du Whois pendant le déroulement de la procédure administrative au titre de la politique peut être permis ou interdit en vertu des politiques et des contrats applicables au bureau d'enregistrement. Toutefois, le titulaire du nom de domaine est responsable (règle 2(e) de l'UDRP et règle 5(b)(ii)) d'informer le fournisseur de toute mise à jour importante pouvant affecter les avis et les obligations du fournisseur vis-à-vis du défendeur en vertu de l'UDRP.

      Selon les modalités de service du fournisseur de service d'anonymisation / d'intermédiation, un bureau d'enregistrement peut choisir de dévoiler les données sous-jacentes comme résultat des services d'anonymisation/d'intermédiation au fournisseur ou dans le Whois, ou les deux, s'il le peut. Cela ne sera pas considéré comme un « transfert » en violation de ce qui précède, si cela se produisait conformément à la recommandation préliminaire nº 2. Si un service d'anonymisation / d'intermédiation est dévoilé ou des informations d'un client d'un tel service sont publiées après la mise en place du verrouillage et que le fournisseur est notifié, le fournisseur n'est pas obligé de demander au demandeur d'amender sa plainte en conséquence, mais il peut le faire à sa discrétion. Il est de la responsabilité du titulaire du nom de domaine (règle UDRP 2(e) et règle UDRP 5 (b)(ii)) d'informer le fournisseur de toute mise à jour pertinente pouvant affecter les avis et les obligations du fournisseur envers le défendeur au titre de l'UDRP. Le fournisseur devra aussi, conformément à l'UDRP, fournir au défendeur des informations relatives à l'affaire à l'adresse du choix du défendeur dès que le fournisseur sera au courant de la mise à jour (selon la règle UDRP 5(b)(iii)), le fournisseur devra utiliser l'adresse e-mail préférée du défendeur pour ces communications, par exemple).

      Recommandation nº 5 : En tant que meilleure pratique, les bureaux d'enregistrement et les fournisseurs de services UDRP sont encouragés à offrir un moyen qui permette à des parties tierces d'identifier leurs heures et jours d'ouverture respectifs, pendant lesquels il est prévu d'accomplir les tâches liées aux UDRP.

      Recommandation nº 6 : Le bureau d'enregistrement doit confirmer au fournisseur de services UDRP dans les deux jours ouvrables à compter de la réception de la demande7 de vérification de la part du fournisseur de services UDRP que tous changements de bureau d'enregistrement et de titulaire de nom de domaine ont été empêchés et seront empêchés pendant le déroulement de la procédure, et que le bureau d'enregistrement doit vérifier8 les informations requises par le fournisseur de services UDRP.

      Recommandation nº 7 : Si cela est jugé conforme, le fournisseur de services UDRP devra transmettre la plainte au bureau d'enregistrement et et au défendeur. Il leur notifiera le début de la procédure administrative au plus tard 3 jours ouvrables9 suite à la réception des frais payés par le demandeur.

      Recommandation nº 8 :10: qu'il soit accordé aux défendeurs participant à l'UDRP une option formelle de demander une prolongation de quatre jours s'ils le souhaiteraient, ces quatres jours étant automatiquement accordés et la date limite correspondante prolongée par le fournisseur de services UDRP, sans frais pour le défendeur. La disponibilité d'une telle option de prolongation automatique de quatre jours suite à la demande devrait également être signalée par le fournisseur de services UDRP au défendeur au commencement de la procédure et n'exclut pas d'autres prolongations supplémentaires pouvant être accordées par le fournisseur de services UDRP conformément à l'article 5d des règles de l'UDRP.

      Recommandation nº 9 : Si la plainte était non-conforme ou si les frais restaient impayés après la fin de la période administrative de contrôle des déficiences selon le paragraphe 4 de l'UDRP, ou si la plainte était retirée volontairement pendant cette période, le fournisseur de services UDRP informera le bureau d'enregistrement que la procédure a été retirée. Dans un délai d'un jour ouvrable à compter de la transmission de l'avis de retrait, le bureau d'enregistrement relâchera le « verrouillage ».

      Recommandation nº 10 : Dans le cadre de sa notification au titulaire de nom de domaine (notification de plainte – voir section 4 des règles de l'UDRP), le fournisseur de services UDRP informe le titulaire du nom de domaine que toute correction des informations de contact de ce dernier pendant le déroulement de la procédure devra être également communiquée au fournisseur de services UDRP en vertu de la règle UDRP 5(ii) et (iii).

      Recommandation nº 11 : Cette notification inclurait aussi l'information que tous les changements découlant de la levée des services d'anonymisation / d'intermédiation, suite au « verrouillage », devraient être abordés/discutés directement par le panel UDRP. Le groupe de travail recommande que cette question soit révisée plus tard dans le cadre du travail de développement du programme d'accréditation d'anonymisation / intermédiation.

      Recommandation nº 12 : Après réception et communication de la décision du fournisseur de services UDRP, le bureau d'enregistrement doit, dans les trois jours ouvrables, communiquer à chaque partie, au fournisseur de services UDRP et à l'ICANN, la date de mise en œuvre de la décision, conformément à la politique (règle 16 de l'UDRP et paragraphes 4(k) et 8(a) de l'UDRP). Si le demandeur a prévalu, le bureau d'enregistrement devra mettre en œuvre l'ordre du panel immédiatement après les 10 jours ouvrables (UDRP, paragraphe 4(k)). Le demandeur ou son représentant autorisé devra fournir au bureau d'enregistrement l'information requise pour soutenir la mise en œuvre de la décision du panel ; ceci pourrait inclure l'information qui devrait être contenue dans le Whois. Si le défendeur a prévalu, le bureau d'enregistrement devra interdire le transfert du nom de domaine à un autre bureau d'enregistrement ou registrant pendant 15 jours ouvrables à partir de la date où le fournisseur aura transmis la décision (UDRP paragraphe 8)

      Recommandation nº 13 : Si la procédure était suspendue (lorsque les parties essaient d'arriver à un accord), le fournisseur de services UDRP informera le bureau d'enregistrement de la suspension, y compris la durée prévue de la suspension. Si les parties parviennent à un règlement, impliquant un transfert, une annulation ou un accord selon lequel l'enregistrement continuera d'appartenir au défendeur, le bureau d'enregistrement doit lever tout verrouillage empêchant un transfert ou une annulation dans les 2 jours ouvrables à compter de la confirmation du règlement par le fournisseur de services UDRP, sauf si l'enregistrement du nom de domaine faisant l'objet du litige fait par ailleurs l'objet d'une poursuite judiciaire déjà entamée et portant sur ce nom de domaine.

      Recommandation nº 14 : Le processus de règlement doit suivre les étapes ci-dessous : (1) les parties demandent la suspension au fournisseur de services UDRP, (2) les parties s'entendent, (3) les parties soumettent un « formulaire de règlement » normalisé au fournisseur de services UDRP, (4) le fournisseur de services UDRP confirme au bureau d'enregistrement avec copie au demandeur et au défendeur, si les modalités du règlement indiquent l'accord du défendeur pour un transfert ou une annulation du nom de domaine en question en faveur du demandeur, ou l'accord du demandeur pour que le nom de domaine soit econservé par le défendeur, (5) l'accord de règlement est mis en oeuvre par le bureau d'enregistrement , (6) le demandeur confirme la mise en oeuvre au fournisseur de services UDRP et (7) le fournisseur de services UDRP classe l'affaire.

      Recommandation nº 15 : L'ICANN, en collaboration avec les fournisseurs de services UDRP, les bureaux d'enregistrement et toute autre partie intéressée, développera des documents de formation et d'information qui aideront à informer les parties touchées sur ces nouvelles exigences et recommandera les meilleures pratiques suite à l'adoption de ces recommandations par le Conseil d'administration de l'ICANN.

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

      Tel que requis par sa charte, il était demandé au groupe de travail PDP 'en tant que première étape, de solliciter les commentaires de la communauté sur cette question, afin d'avoir une compréhension claire de la nature exacte et de la portée des questions liées au verrouillage de noms de domaine faisant l'objet de procédures UDRP'. Comme résultat, le groupe de travail a mené une enquête auprès des bureaux d'enregistrement ainsi que des fournisseurs de services UDRP tel que décrit dans la section 5.1. du rapport final. En plus des questions spécifiques relatives aux pratiques et expériences des bureaux d'enregistrement et des fournisseurs de services UDRP, il a été demandé aux participants à l'enquête de donner leur avis sur les questions de la charte. En outre, le groupe de travail a établi un forum de consultation publique pour recueillir les commentaires de la communauté le 25 juillet 2012.

      En parallèle à l'information régulière du conseil de la GNSO, des ateliers ont été organisés pour informer et solliciter les avis de la communauté de l'ICANN aux rencontres de l'ICANN (voir par exemple http://beijing46.icann.org/node/37193, http://toronto45.icann.org/node/34245 et http://prague44.icann.org/node/31807).

      Des déclarations des regroupements et groupes de parties prenantes ont été demandées ainsi que des contributions des autres organisations de soutien et comités consultatifs de l'ICANN à un stade précoce du processus. Il n'y a pas eu de réponse à ces demandes. Le président du groupe de travail sur le PDP a rencontré la ccNSO à la rencontre de l'ICANN de Prague pour un échange de points de vue sur ce sujet (voir http://ccnso.icann.org/meetings/toronto/summary.htm#neylon-greenberg pour plus d'informations).

      Le groupe de travail a aussi mis en place un forum de consultation publique concernant le rapport initial le 15 mars 2013.

      Tous les commentaires reçus ont été examinés et pris en considération par le groupe de travail sur le PDP portant sur le verrouillage d'un nom de domaine faisant l'objet d'une procédure UDRP (voir section 6 du rapport final).

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

      Aucune inquiétude n'a été manifestée par la communauté concernant le rapport final et ses recommandations. Tous les autres commentaires reçus ont été examinés et abordés par le groupe de travail sur le PDP tel qu'indiqué dans la section 6 du rapport final.

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

      Le Conseil a révisé le rapport de recommandations du conseil de la GNSO au Conseil d'administration, ainsi que la synthèse des commentaires publics.

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

      Les recommandations ont été élaborées selon le processus d'élaboration des politiques de la GNSO, telle que décrit dans l'annexe A des statuts de l'ICANN et ont reçu l'appui unanime du conseil de la GNSO. Comme indiqué dans les statuts de l'ICANN, le soutien unanime de cette motion par le conseil (majorité qualifiée) oblige le Conseil d'administration à adopter la recommandation, sauf si, par un vote de plus de 66 %, le Conseil d'administration détermine que la politique concernée n'est pas dans le meilleur intérêt de la communauté de l'ICANN ou de l'ICANN.

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

      L'adoption des recommandations devrait clarifier et normaliser le processus de verrouillage d'un nom de domaine faisant l'objet d'une procédure UDRP et ceci pour toutes les parties impliquées y compris les demandeurs, les défendeurs, les bureaux d'enregistrement et les fournisseurs de services UDRP. La mise en oeuvre des recommandations exigera certains changements de certains processus de bureaux d'enregistrement puisqu'il n'existe par pour l'instant un processus normalisé qui traite du verrouillage de noms de domaine faisant l'objet de procédures UDRP, ainsi que certaines modifications des pratiques des fournisseurs de services UDRP. Pour les demandeurs, le changement principal est qu'au moment de déposer sa plainte, le demandeur n'est plus obligé de notifier le défendeur ce qui devrait réduire les cas de cyberflight (la notification du défendeur est faite par le fournisseur de services UDRP au moment du démarrage officile de la procédure). Comme résultat du changement, à savoir de ne plus avoir de notification du défendeur par le demandeur au moment de la déposition, le défendeur pourrait voir une réduction du temps de réponse informel. Toutefois, afin de compenser cette perte potentielle de temps de réponse informel, les recommandations prévoient qu'il soit accordé aux défendeurs participant à l'UDRP une option formelle de demander une prolongation de quatre jours s'ils le souhaiteraient, ces quatres jours étant automatiquement accordés et la date limite correspondante prolongée par le fournisseur de services UDRP, sans frais pour le défendeur.

      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 ?

      Outre les changements requis dans les processus en ce qui concerne les bureaux d'enregistrement et les fournisseurs de services UDRP, évoqués ci-dessus, il peut y avoir un impact fiscal lié à la mise en œuvre de la politique dont les coûts sont cependant anticipés dans les prévisions du budget actuel.

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

      Aucun problème de sécurité, de stabilité ou de résilience lié au DNS n'est à prévoir si le Conseil approuve les recommandations proposées.

    4. Mise en œuvre des améliorations de l'organisation de soutien relative aux noms de codes de pays (ccNSO)

      Attendu que, le 21 avril 2011, le Conseil a résolu d'enjoindre au personnel de l'ICANN, en coordination avec le Comité pour les améliorations structurelles (SIC), de développer une proposition de plan de mise en œuvre et de délai pour les recommandations du rapport final du groupe de travail du Conseil sur les améliorations de la ccNSO [PDF, 1.13 MB] ainsi que de soumettre cela au comité pour les améliorations structurelles pour révision et approbation du Conseil d'administration (résolution 2011.04.21.06).

      Attendu que, lors de sa réunion du 18 juin 2011, le SIC a accusé réception d'un plan de mise en œuvre de la part du personnel, à savoir du « plan de projet de mise en œuvre d'améliorations de la ccNSO » en date du 9 juin 2011 et a résolu de le recommander à l'examen du Conseil d'Administration de l'ICANN.

      Attendu que, lors de sa réunion du 24 juin 2011, le Conseil a résolu de demander au président directeur général de l'ICANN d'enjoindre au personnel de procéder à la mise en oeuvre conformément au document de mise en œuvre plan de projet de mise en œuvre d'améliorations de la ccNSO en date du 9 juin 2011[PDF, 508 KB] (résolution 2011.06.24.03).

      Attendu que, le 27 septembre 2013, le SIC a accusé réception d'une lettre du président de la ccNSO annonçant l'achèvement de la mise en oeuvre des améliorations de la ccNSO en plus d'une mise à jour du plan de projet de mise en oeuvre d'améliorations de la ccNSO, datée de septembre 2013.

      Attendu que, le 27 septembre 2013, le SIC a convenu de recommander que le Conseil de l'ICANN reçoive la mise à jour du plan de projet final de mise en œuvre de la ccNSO [PDF, 170 KB], datée de septembre 2013, note l'achèvement de la phase de mise en oeuvre des améliorations de la ccNSO, et entame la phase d'évaluation inhérente au cycle de révision.

      Résolu (2013.09.28.06), le Conseil reçoit la mise à jour du plan de projet final de mise en oeuvre de la ccNSO, datée de septembre 2013, et note l'achèvement de la mise en oeuvre des recommandations d'amélioration de la ccNSO.

      Résolu (2013.09.28.07), le Conseil enjoint au président et directeur général de l'ICANN d'évaluer les améliorations ressortant de la révision de la ccNSO conformément à la phase d'évaluation du cycle organisationnel de révision.

      Résolu (2013.09.28.08), le Conseil remercie la ccNSO pour son travail de mise en œuvre.

      Fondements des résolutions 2013.09.28.06 – 2013.09.28.08

      Conformément aux statuts de l'ICANN, une révision périodique des organisations de soutien / comités consultatifs de l'ICANN est requise afin d'évaluer la performance et l'efficacité opérationnelle de l'entité examinée. Le but de cette révision est de déterminer : (i) si cette organisation a un rôle continu au sein de la structure de l'ICANN, et (ii) dans l'affirmative, si un changement dans la structure ou les opérations serait souhaitable pour améliorer son efficacité.

      Cette action est une réponse directe à une demande du Conseil concernant la mise en oeuvre des recommandations ressortant de l'effort de révision de la ccNSO et sert à faciliter l'évaluation des améliorations de révision de la ccNSO de manière opportune.

      Cette action n'implique pas des changements structurels complexes ou des conséquences budgétaires. Nul impact sur la sécurité, la stabilité et la résilience du système des noms de domaine n'est prévu en tant que résultat de cette action.

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

    5. Révision de la GNSO

      Attendu que, conformément aux statuts de l'ICANN, la révision prochaine de la GNSO devait commencer en 2013.

      Attendu que, le SIC a sollicité et examiné les commentaires publics sur la mesure dans laquelle la révision devait être reportée et un nouveau calendrier établi pour la révision dans les prochains six mois.

      Attendu qu'il est important que la révision de la GNSO prenne en compte les résultats des efforts de planification stratégique de l'ICANN et le travail de la deuxième équipe de révision de la responsabilité et transparence, ce qui peut uniquement être accompli par le démarrage d'une révision de la GNSO en 2014.

      Résolu (2013.09.28.09), que le Conseil enjoigne au SIC de programmer la révision de l'organisation de soutien aux politiques des noms génériques (GNSO), autorisée par les statuts de l'ICANN, article IV, section 4, en 2014, et que les préparatifs pour cette révision démarrent dès que possible.

      Fondements des résolutions 2013.09.28.09

      Les statuts de l'ICANN exigent que les structures existantes au sein de l'ICANN soient révisées de manière régulière dans le cadre de la responsabilité continue de l'ICANN. Dans ce but, la première révision organisationnelle de la GNSO a été entreprise en 2006. Dans le cadre de cette révision, un rapport rédigé par les réviseurs indépendants LSE Public Policy Group and Enterprise LSE, engagés pour ce faire, a été publié en septembre 2006 et le rapport relatif aux améliorations de la GNSO rédigé par le groupe de travail sur la révision de la GNSO du comité de gouvernance du Conseil a été publié le 3 février 2008. Conformément aux statuts de l'ICANN, article IV, section 4, la révision suivante commencerait cinq ans après la publication du rapport final, ce qui nécessiterait donc que cette révision commence dans le courant des premiers mois de 2013. Le comité pour les améliorations structurelles (SIC) a recommandé au Conseil de reporter le démarrage de cette nouvelle révision de la GNSO, avec l'avantage pour l'ICANN de prendre en compte des apports précieux provenant du processus de planification stratégique de l'ICANN et du travail en cours de la deuxième équipe de révision de la responsabilité et de la transparence organisée en vertu de l'affirmation d'engagements (ATRT 2). La période de consultation publique a été lancée le 15 juillet 2013 afin de solliciter des contributions qui guideraient les actions du SIC concernant le report éventuel de la révision de la GNSO. Les réactions de la part de communauté ont donné lieu à huit réponses et sept des personnes ayant répondu ont indiqué que la révision de la GNSO ne devrait pas être reportée. Les raisons invoquées comprenaient ce qui suit :

      • L'expansion de l'espace TLD a augmenté le nombre et la varitété des parties prenantes participant à l'élaboration des politiques de la GNSO. ne révision doit avoir lieu comme prévu afin d'examiner la mesure dans laquelle le modèle actuel répond aux besoins d'une nouvelle génération de parties prenantes.
      • Il est peu probable que la structure de la GNSO puisse s'adapter à la nouvelle vague de parties prenantes résultant de l'expansion de l'espace TLD. La révision de la GNSO sera un véhicule important pour examiner et aborder cette question. Le déséquilibre apparaissant déjà a besoin d'être abordé par la révision de la GNSO.
      • Il a fallu plusieurs années pour mettre en oeuvre la révision précédente. Les personnes ayant répondu ont souligné le besoin de réduire au maximum la durée du processus de révision de la GNSO, de manière générale, afin d'assurer une révision plus efficace, dynamique et effective de la GNSO et ce pour l'ensemble de la communauté de l'ICANN.
      • Le travail entrepris par l'ATRT 2, à savoir l'évaluation du processus de développement des politiques ou le processus de planification stratégique n'abordera pas les questions indiquées de manière extensive.

      Les participants au processus de consultation publique comprenaient le groupe registres de marque (BRG), le regroupement de fournisseurs de services Internet et de services de connexion, le regroupement d'entreprises opérationnelles à but non lucratif (NPOC), le groupe de parties prenantes non commerciales, le regroupement sur la propriété intellectuelle, le regroupement d'utilisateurs commerciaux et les services de registre ARI.

      L'approche proposée vise à répondre au retour d'informations de la part de la communauté insistant pour qu'il n'y ait pas plus de retard, tout en établissant un délai pour le démarrage d'une révision qui conviendrait à la complexité du travail et à l'importance d'une planification minutieuse, en tenant compte de la méthodologie de la révision et de la participation de la communauté au processus. Reconnaissant l'importance d'une révision approfondie et bien organisée qui tienne compte des contributions pertinentes du travail actuellement en cours, ainsi que des opinions variées de la communauté, le SIC a pris ces éléments en parallèle avec le retour d'informations de la part de la communauté.

      Afin de remplir l'obligation du Conseil selon les règlements, à savoir de « mettre en place une révision périodique de la performance et du fonctionnement de chaque organisation de soutien, chaque conseil d'organisation de soutien », le SIC recommande que la planification de la prochaine révision de la GNSO commence vraiment en préparation de la révision laquelle commencera aussitôt que possible en 2014.

      Le but de la révision structurelle est de « déterminer (i) si cet organisme a un rôle permanent au sein de la structure de l'ICANN, et (ii) si oui ou non, tout changement dans la structure ou le fonctionnement serait souhaitable pour améliorer son efficacité ». Étant donné l'environnement en évolution, le nombre grandissant de parties prenantes participantes, leur diversité et les leçons apprises durant la dernière révision de la GNSO, le SIC considère la planification de la révision comme étant d'importance capitale pour s'assurer que les recommandations d'amélioration soient utiles et exécutables. Le SIC élaborera et mettra en oeuvre un calendrier de révision qui prendra en considération la connotation d'urgence exprimée dans les commentaires publics tout en s'assurant qu'une période de temps suffisante soit accordée à l'effort de planification. La période de temps supplémentaire impartie aux consultations publiques garantira le fait que la communauté ait largement le temps d'examiner et de s'exprimer quant aux modalités de réalisation de la deuxième révision de la GNSO, confortant ainsi la responsabilité et la transparence de l'ICANN.

      Il n'est prévu aucun impact sur la sécurité ou la stabilité du DNS. Il y aura un impact fiscal et un impact sur les ressources, liés à la révision de la GNSO lorsque celle-ci sera entamée. Ces ressources et ces coûts seront anticipés et imputés dans le budget de l'ICANN des exercices budgétaires au cours desquels la révision sera entamée et achevée.

      Il s'agit d'une fonction administrative organisationnelle pour laquelle des commentaires publics ont été sollicités.

  2. Ordre du jour principal :

    1. Nomination du président et du président-élu du comité de nomination 2014

      Attendu que le comité de gouvernance du Conseil (BGC) a examiné les manifestations d'intérêt des candidats aux postes de président et de président-élu du comité de nomination (« NomCom ») pour 2014, a mené des entretiens avec ces candidats et a examiné les résultats de l'évaluation à 360 degrés par les dirigeants du NomCom en 2013.

      Attendu que le BGC a recommandé la nomination de Cheryl Langdon-Orr pour le poste de présidente du NomCom 2014, et de Stéphane Van Gelder pour le poste de président-élu du NomCom 2014.

      Résolu (2013.09.28.10), le Conseil nomme par la présente Cheryl Langdon-Orr au poste de présidente du comité de nomination pour 2014 et Stéphane Van Gelder au poste de président-élu du comité de nomination pour 2014.

      Fondements des résolutions 2013.09.28.10

      Les statuts de l'ICANN exigent que le Conseil nomme le président du comité de nomination (NomCom) et le président élu du NomCom. Voir article VII, sections 2.1 et 2.2 sur http://www.icann.org/fr/general/bylaws.htm#VII. Le Conseil a délégué au comité de gouvernance du Conseil la responsabilité de recommander des candidats au poste de président et de président-élu du NomCom pour leur approbation par le Conseil. Voir charte du BGC sur http://www.icann.org/en/committees/board-governance/charter.htm. Le BGC a publié un appel à candidatures (EOI), a révisé les manifestations d'intérêt reçues, a mené des entretiens avec les candidats et a passé en revue une évaluation à 360 degrés faite par les dirigeants du NomCom en 2013 avant de formuler ses recommandations. Le Conseil a examiné et approuve les recommandations du BGC. Le Conseil souhaiterait également remercier toutes les personnes ayant manifesté leur intérêt pour une participation à la direction du NomCom.

      La nomination du président et du président-élu du NomCom identifiés par le biais d'un processus public d'appel à candidatures a des effets positifs sur la transparence et la responsabilité de l'ICANN. L'adoption de la recommandation du BGC n'a pas d'impact financier non anticipé autrement sur l'ICANN et n'aura pas d'impact négatif sur la sécurité, la stabilité et la résilience du système de noms de domaine.

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

    2. Traitement des coûts de développement historique des nouveaux gTLD

      Attendu que, l'ICANN a encouru des frais pendant plusieurs années pour concevoir et préparer le lancement du programme des nouveaux gTLD.

      Attendu que les frais encourus à partir d'octobre 2007 (date de la recommandation de la GNSO sur le programme des nouveaux gTLD) jusqu'au lancement du programme (« coûts de développement historique ») sont à rembourser à l'ICANN à partir d'une portion des frais de candidature du programme des nouveaux gTLD.

      Attendu que les coûts de développement historique sont progressivement imputés sur le programme à mesure que le travail d'évaluation progresse et que les frais de candidature ne sont plus remboursables, ce qui a débuté en juillet 2012.

      Attendu que le comité des finances du Conseil d'administration a recommandé que le montant des coûts de développement historique remboursé au fonds d'exploitation de l'ICANN à partir du programme des nouveaux gTLD soit transféré au fonds de réserve.

      Résolu (2013.09.28.11), le Conseil autorise le président et directeur général, ou la personne désignée par ce dernier, à procéder à toutes les actions nécessaires afin de transférer, selon que de besoin, du fonds d'exploitation de l'ICANN au fonds de réserve de l'ICANN, tous les montants, déjà versés ou devant être remboursés à l'avenir, qui constituent les coûts de développement historique.

      Fondements des résolutions 2013.09.28.11

      L'ICANN a encouru des frais pour définir, concevoir et préparer le lancement du programme des nouveaux gTLD tout au long des années ayant précédé le lancement du programme en janvier 2012 (« coûts de développement historique »). (Voir annexe 1.)

      Dans le cadre de la conception du programme, les coûts de développement historique ont été avancés et pris sur le fonds d'exploitation de l'ICANN et devaient être compensés à partir d'une portion des frais de candidature versés par les candidats au programme des nouveaux gTLD. Afin de s'assurer que les fonds nécessaires seraient reçus, les frais de candidature comportaient 25 000 USD par candidature pour permettre le remboursement des coûts de développement historique à l'ICANN. Le montant de 25 000 USD résultait d'une estimation historique du total des coûts de développement du programme réparti sur 500 candidatures. Il a été aussi établi que les frais encourus par l'ICANN qui seraient remboursés à partir d'une portion des frais de candidature seraient ceux encourus entre octobre 2007, date approximative des recommandations stratégiques de la GNSO relatives aux nouveaux gTLD, et le lancement du programme en janvier 2012.

      Le personnel de l'ICANN a estimé que les coûts de développement historique correspondaient à environ 32,5 millions USD. Ce montant a été communiqué dans le cadre de la présentation du budget pour l'exercice budgétaire 2013 en juin 2012. Sa justification détaillée est en cours de finalisation pour l'audit et la communication à la communauté.

      Le montant des coûts de développement historique couvert à partir des 25 000 USD perçus des montants réellement reçus des candidatures s'élève à environ 48 millions USD (25k * 1930 candidatures), avant remboursements. La différence entre les 48 millions USD (moins les remboursements) et la somme d'environ 32,5 millions USD contribue au solde net restant du programme.

      Le montant de remboursement des coûts de développement historique est imputé sur le programme des nouveaux gTLD, commençant en juillet 2012, à mesure que le travail d'évaluation progresse et que les frais de candidature deviennent non remboursables.

      Environ 17 millions USD de frais imputés sur le programme des nouveaux gTLD, de juillet 2012 à juin 2013, avec des recettes correspondantes de l'ICANN, ont été transférés sur le compte d'exploitation de l'ICANN en août 2013.

      Bien que l'intention ait toujours été de transférer les montants résultants du remboursement des coûts de développement historique au fonds de réserve de l'ICANN, cette intention n'avait jamais été officialisée dans une résolution du Conseil d'administration. (Voir annexe 1.)

      Après le transfert initial imminent des coûts de développement historiques déjà recouvrés du fonds d'exploitation de l'ICANN au fonds de réserve, l'ICANN a l'intention de procéder à des transferts trimestriels au fonds de réserve à mesure que les montants seront imputés sur le compte du programme des nouveaux gTLD.

      Cette résolution aura un impact positif du fait qu'elle apporte plus de clarté sur la gestion des ressources de l'ICANN. Il y aura un impact fiscal sur l'ICANN et sur la communauté, comme voulu. Cette action ne devrait pas avoir d'impact sur la sécurité, la stabilité et la résilience du système de noms de domaine (DNS).

      Il s'agit d'une fonction administrative organisationnelle qui ne nécessite pas de consultation publique à ce stade. Mais la nature et la méthode de traitement des coûts de développement historique et le fait qu'ils soient transférés au fonds de réserve ont été précédemment publiés et ont fait l'objet d'une consultation publique.

    3. Processus proposé pour les amendements de charte du regroupement et du groupe de parties prenantes de la GNSO

      Attendu que, les statuts de l'ICANN (article X, section 5.3) établissent que « chaque groupe multipartite [de la GNSO] … et chacun de ses regroupements associés sera reconnu par le Conseil d'administration de l'ICANN ».

      Attendu qu'il est important que les regroupements et groupes de parties prenantes de la GNSO disposent de la flexibilité de mettre à jour, modifier et faire évoluer leurs chartes organisationnelles afin que ces dernières reflètent les changements de la communauté sans négliger le besoin de validation de la part du Conseil.

      Attendu qu'il n'existe pas actuellement de procédure à suivre par un regroupement ou un groupe de parties prenantes de la GNSO pour obtenir l'approbation du Conseil d'administration de l'ICANN concernant un amendement de sa charte.

      Attendu que le comité pour les améliorations structurelles du Conseil d'administration de l'ICANN a formulé et recommandé un processus par le biais duquel les regroupements et les groupes de parties prenantes de la GNSO peuvent amender leurs chartes, alors que les responsabilités de validation adéquate du Conseil sont maintenues pour la reconnaissance de ces groupes de la GNSO.

      Attendu que la communauté a eu la possibilité de réviser et de commenter le processus proposé et que des changements ont été apportés à la proposition afin de prendre en compte les suggestions de la communauté.

      Résolu (2013.09.28.12), le Conseil approuve le processus formulé et recommandé par le comité pour les améliorations structurelles et enjoint au personnel de l'ICANN de notifier le processus aux dirigeants des divers regroupements et groupes de parties prenantes de la GNSO et de publier une copie du processus approuvé sur le site Web de la GNSO dans les sept jours civils.

      Fondements des résolutions 2013.09.28.12

      En juillet 2009, dans le cadre du programme détaillé des améliorations de la GNSO, le conseil d'administration de l'ICANN a approuvé les chartes formelles de quatre nouveaux groupes de parties prenantes de la GNSO (voir résolution du Conseil d'administration de l'ICANN 2009.30.07.09).

      Les statuts de l'ICANN (article X, section 5.3) établissent que « chaque groupe multipartite … et chacun de ses regroupements associés sera reconnu par le Conseil d'administration de l'ICANN ». Vu que les premières chartes organisationnelles de la GNSO approuvées en 2009 ontfait l'objet de négociations et de discussions exhaustives et rigoureuses entre la communauté et les membres du Conseil, il est de mise que le Conseil ait la possibilité de réviser et d'approuver les amendements de charte à venir. De plus, le Conseil estime que la révision d'amendements de charte de la GNSO maintenue par des groupes de parties prenantes de la GNSO et des regroupements qui constituent ces groupes, représente une obligation importante en termes de maintien de la reconnaissance de structures de la GNSO officiellement approuvées, en ligne avec les principes des statuts de l'ICANN.

      Le comité pour les améliorations structurelles du Conseil (SIC) a élaboré ce processus et la proposition a été soumise à la révision et aux commentaires de la communauté. La version finale approuvée par le Conseil reflète les ajustements apportés à la proposition initiale du SIC après la prise en compte des commentaires utiles de la communauté concernant le moment choisi pour les notifications du personnel et le délai et processus pour la révision des amendements de charte de la communauté par le Conseil.

      Cette action n'aura pas d'impacts immédiats ou substantiels sur les ressources de l'ICANN. Certaines fois, ceci nécessitera un travail supplémentaire de la part de la communauté, le soutien du personnel et du temps consacré à la révision de la part du Conseil, mais tous ces efforts devraient être limités dans le temps et amélioreront la transparence et l'efficacité ultime des processus structurels et de gestion de l'ICANN.

      Cette action n'est pas censée avoir d'incidence sur la sécurité, la stabilité ou la résilience du DNS.

      LIENS AU DOCUMENT/CONTEXTE :
      Lien au forum de consultation publique de la communauté.

      Il s'agit d'une fonction administrative organisationnelle pour laquelle des commentaires publics ont été reçus.

    4. Clarification concernant les critères de mesure de concurrence, confiance du consommateur et choix du consommateur pour le programme des nouveaux gTLD selon la révision de l'affirmation d'engagements (AoC)

      Attendu que, le 18 juillet 2013, le Conseil d'administration de l'ICANN a enjoint au président directeur général de démarrer le processus d'établissement de l'équipe de révision de la concurrence, de la confiance du consommateur et du choix du consommateur (CCT) afin de faciliter le travail préliminaire sur la faisabilité, l'utilité et la rentabilité de l'adoption des recommandations du conseil de la GNSO et de l'ALAC, ainsi que de l'analyse des autres critères de mesure éventuels devant être disponibles pour la révision CCT.

      Attendu que le Conseil souhaite clarifier ses résolutions 2013.07.18.06 et 2013.07.18.07 pour souligner le fait que la révision réelle CCT n'a pas commencé à ce stade mais plutôt, qu'il est approuvé de constituer un groupe consultatif sur la mise en oeuvre pour la concurrence, la confiance du consommateur et le choix du consommateur. Le travail de ce groupe consultatif vise à contribuer à la révision CCT au moment où la révision CCT sera démarrée conformément au calendrier indiqué dans l'affirmation d'engagements (AoC).

      Résolu (2013.09.28.13), le Conseil enjoint au président directeur général de réunir un groupe de volontaires (le groupe consultatif sur la mise en oeuvre pour la concurrence, la confiance du consommateur et le choix du consommateur) en amont de l'équipe à venir de révision de la concurrence, de la confiance du consommateur et du choix du consommateur de l'AoC, aux fins suivantes : (i) évaluer et présenter un rapport au Conseil d'administration sur la faisabilité, l'utilité et la rentabilité de l'adoption des recommandations du conseil de la GNSO et de l'ALAC ; (ii) évaluer d'autres alternatives, y compris les données historiques en matière de critères de mesure utilisés pour évaluer des séries précédentes des nouveaux gTLD (2000, 2004) ; (iii) engager la GNSO, l'ALAC et le personnel dans un effort pour arriver à un accord sur les critères de mesure ; et (iv) proposer une série de critères de mesure devant être compilés par l'ICANN pour être mis à disposition d'une équipe à venir de révision AoC qui examinera le programme des nouveaux gTLD.

      Résolu (2013.09.28.14), les parties des résolutions 2013.07.18.06 et 2013.07.18.07 suggérant que la révision CCT aurait démarré avant le temps défini dans l'AoC sont retirées.

      Fondements des résolutions 2013.09.28.13 – 2013.09.28.14

      La résolution du Conseil clarifie ses résolutions précédentes concernant l'évaluation des critères de mesure proposés par la communauté pour une utilisation dans le cadre d'une révision à venir de l'impact des nouveaux gTLD dans les domaines de la concurrence, de la confiance du consommateur et du choix du consommateur, au titre de l'affirmation d'engagements (AoC).   

      La résolution du Conseil demande au président directeur général de réunir un groupe de volontaires qui fourniraient des conseils sur la mise en oeuvre en amont de l'établissement d'une équipe de révision à venir de la concurrence, de la confiance du consommateur et du choix du consommateur pour : évaluer et rédiger un rapport sur la faisabilité, l'utilité et la rentabilité de divers critères de mesure recommandés par la communauté ; évaluer d'autres alternatives, y compris les données historiques en matière de critères de mesure utilisés pour évaluer des séries précédentes des nouveaux gTLD (2000, 2004) ; engager la GNSO et l'ALAC pour identifier un accord sur les critères de mesure ; et finalement, proposer une série de critères de mesure à soumettre à l'approbation du Conseil d'administration, qui seront rassemblés et disponibles pour être utilisés, à discrétion, dans la future révision qui sera réalisée en vertu de l'AoC. Si, après en avoir discuté avec la GNSO et l'ALAC, le groupe consultatif sur la mise en oeuvre pour la concurrence, la confiance du consommateur et le choix du consommateur, recommandait en fin de compte de ne pas utiliser un critère de mesure quelconque proposé par le conseil de la GNSO et/ou l'ALAC, le groupe consultatif devrait fournir une explication pertinente.

      Ce travail doit démarrer dans l'immédiat et implique la participation de la communauté et de l'ICANN, l'évaluation et la rédaction d'un rapport sur les critères de mesure proposés par le conseil de la GNSO et l'ALAC, et la recommandation de critères de mesure devant être rassemblés par l'ICANN dans le cadre de la préparation d'une révision à venir du programme des nouveaux gTLD.

      La révision requise au titre de l'AoC aura lieu seulement et quand les nouveaux gTLD auront fonctionné pendant un an. Elle implique l'examen de la mesure dans laquelle l'introduction ou l'expansion des gTLD aura promu la concurrence, la confiance du consommateur et le choix du consommateur. Le moment de démarrer cette révision n'est pas encore venu. Aujourd'hui, le Conseil demande le démarrage du travail de mise en oeuvre visant à faciliter le travail de la révision AoC le moment venu.

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


1 Il faut souligner qu'un tel verrouillage ne devrait pas empêcher le renouvellement d'un nom de domaine faisant l'objet d'une procédure UDRP, conformément à la politique de suppression des noms de domaines expirés (EDDP).

2 Il s'agit d'un contrôle initial effectué par le fournisseur UDRP afin de s'assurer qu'il ne s'agit pas d'une fausse plainte. Il ne faut pas confondre ce contrôle avec le contrôle de conformité administrative décrit dans l'UDRP et effectué selon l'étape 4 de cette proposition.

3 S'appliquera aux fournisseurs de services d'anonymisation / d'intermédiation accrédités, suite à la finalisation du programme d'accréditation d'anonymisation / d'intermédiation par l'ICANN.

4 Les jours ouvrables sont définis comme jours ouvrables dans la juridiction de l'entité qui doit entreprendre cette action, dans ce cas, le bureau d'enregistrement.

5 Les données dévoilées peuvent uniquement inclure celles détenues par le fournisseur de services d'anonymisation / d'intermédiation accrédité / affilié.

6 Pour plus de clarté, ceci inclut tout transfert à un fournisseur de services d'anonymisation ou d'intermédiation à part le dévoilement des données du client tel que prévu dans le paragraphe suivant.

7 Le fournisseur de services UDRP enverra une demande au bureau d'enregistrement pour vérifier, entre autres, que le défendeur nommé est le titulaire actuel du nom de domaine en question, les modalités de l'accord d'enregistrement ainsi que la vérification des coordonnées de contact du défendeur.

8 Cette demande de vérification est liée à l'exigence de la part du bureau d'enregistrement de fournir au fournisseur de services UDRP la vérification des points demandés.

9 Cette modification des règles UDRP (normalement on parle de jours « civils ») est recommandée afin de s'assurer que cela est en ligne avec l'exigence de 2 jours ouvrables pour le verrouillage. Sinon, il pourrait y avoir des cas où 2 jours ouvrables représenteraient un délai plus long que les 3 jours civils, ce qui ne permettrait pas au fournisseur de services UDRP d'effectuer les contrôles administratifs dans le délai alloué.

10 Cette recommandation est fondée sur le fait qu'elle permettrait d'aborder les préoccupations exprimées dans le cadre du forum de consultation publique concernant la perte de temps de réponse pouvant résulter du changement proposé à savoir de ne plus exiger du demandeur qu'il notifie le défendeur au moment de la déposition de la plainte. Elle donnerait aux défendeurs qui ont réellement besoin des quatre jours de plus le comfort d'une certitude sans incidence sur le coût lorsque nécessaire et sans incidence sur les délais de l'UDRP dans l'ensemble.

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