Procès-verbal | Réunion ordinaire du Conseil d’administration de l’ICANN 28 septembre 2015

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

Une réunion ordinaire du Conseil d'administration de l'ICANN a eu lieu à Marina Del Rey, en Californie, le 28 septembre 2015 à 16h45 heure locale.

Steve Crocker, président, 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 : Rinalia Abdul Rahim, Cherine Chalaby, Fadi Chehadé (Président-directeur général), Chris Disspain, Asha Hemrajani, Wolfgang Kleinwächter, Markus Kummer, Bruno Lanvin, Gonzalo Navarro, Ray Plzak, George Sadowsky, Mike Silber, Bruce Tonkin (vice-président), et Kuo-Wei Wu.

Les administrateurs suivants ont envoyé leurs excuses : Erika Mann.

Les agents de liaison suivants du Conseil ont participé à toute ou à une partie de la réunion : Ram Mohan (agent de liaison du SSAC), Thomas Schneider (agent de liaison du GAC), Jonne Soininen (agent de liaison de l'IETF), et Suzanne Woolf (agent de liaison du RSSAC).

Secrétaire : John Jeffrey (conseiller juridique et secrétaire).

Les cadres et les membres du personnel suivants ont participé à tout ou partie de la réunion : Akram Atallah (président de la division des domaines mondiaux); Susana Bennett (directrice d'exploitation); Megan Bishop (coordinatrice du soutien au Conseil d'administration); Michelle Bright (gestionnaire de contenus, soutien au Conseil d'administration); Xavier Calvez (directeur financier); David Conrad (directeur de la technologie); Samantha Eisner (conseillère générale associée); Allen Grogan (directeur de la conformité contractuelle); Dan Halloran (conseiller général adjoint); Jamie Hedlund (vice-président des programmes stratégiques - Division des domaines mondiaux); Tarek Kamel (conseiller principal du président – engagement gouvernemental); Vinciane Koenigsfeld (responsable du contenu, soutien au Conseil d'administration); Elizabeth Le (conseillère principale); Margie Milam (directrice des Initiatives stratégiques de l'ICANN); David Olive (vice-président en charge de l'élaboration de politiques); Erika Randall (conseillère principale); Amy Stathos (conseillère générale adjointe); Theresa Swinehart (conseillère principale du président en matière de stratégie); Shawn White (conseiller général associé); et Christine Willett (vice-présidente en charge des opérations gTLD).

Ordre du jour approuvé :

Le président a présenté les questions à traiter de l'ordre du jour et a demandé de passer au vote. Le Conseil a ensuite pris les décisions suivantes :

Il est résolu que les résolutions ci-dessous correspondant au présent ordre du jour sont approuvées :
1. Approbation des procès-verbaux du Conseil d'administration
  
  Il est résolu (2015.09.28.01) que le Conseil d'administration approuve les procès-verbaux des réunions du Conseil d'administration de l'ICANN du 16 et 28 juillet 2015.
2. Recommandations du conseil de la GNSO sur la traduction et la translittération de l'information de contact
  
  Attendu que le 13 juin 2013 le conseil de la GNSO a lancé un processus d'élaboration de politiques (PDP) sur la traduction et la translittération, abordant deux questions inscrites dans la charte consultable à l'adresse http://gnso.icann.org/en/issues/gtlds/transliteration-contact-charter-20nov13-en.pdf.
  
  Attendu que le PDP a suivi les étapes prévues dans les statuts constitutifs, qui ont donné lieu au rapport final délivré le 12 juin 2015.
  
  Attendu que le groupe de travail consacré au PDP sur la traduction et la translittération des informations de contact a atteint le consensus sur sa première recommandation et le consensus absolu sur ses six recommandations restantes.¹
  
  Attendu que le Conseil de la GNSO a révisé et discuté les recommandations du groupe de travail consacré au PDP sur la traduction et la translittération des informations de contact et qu'il a adopté les recommandations du 24 juin 2015 à l'unanimité (voir : http://gnso.icann.org/en/council/resolutions#20150624-3).
  
  Attendu que le vote du conseil de la GNSO a atteint et dépassé le nombre de voix nécessaires (c.-à-d. la majorité qualifiée) pour imposer de nouvelles obligations aux parties contractantes de l'ICANN, et
  
  Attendu qu'après le vote du conseil de la GNSO, une période de consultation publique a été lancée au sujet des recommandations approuvées, et que les commentaires reçus ont été résumés et étudiés (https://www.icann.org/public-comments/transliteration-contact-recommendations-2015-06-29-en).
  
  Il est résolu (2015.09.28.02) que le Conseil adopte les recommandations de politique du conseil de la GNSO concernant la traduction et la translittération des informations de contact telles que présentées dans le rapport final.
  
  Il est résolu (2015.09.28.03) de donner des instructions au PDG, ou à ses représentants autorisés, d'élaborer et de compléter un plan de mise en œuvre de ces recommandations et de poursuivre la communication et la coopération avec l'équipe de révision de la mise en œuvre de la GNSO pour les travaux de mise en œuvre.
  
  Fondements des résolutions 2015.09.28.02 et 2015.09.28.03
  
  Pourquoi le Conseil aborde cette question maintenant ?
  
  L'internationalisation continue du système des noms de domaine implique qu'une proportion croissante des utilisateurs de l'Internet n'utilise pas (ou ne connait même pas) l'ASCII US, nom technique de l'alphabet latin utilisé en anglais et dans de nombreuses autres langues d'Europe occidentale.
  
  L'exactitude et la cohérence des données des informations de contact sont essentielles pour qu'elles deviennent une source utile pour ceux qui cherchent des informations concernant les titulaires de noms de domaine. Ce groupe de travail du PDP a examiné la question importante de savoir si les données traduites et/ou translittérées ou les données présentées dans le script mieux connu par le titulaire sont plus susceptibles de remplir ces exigences, compte tenu de la quantité de demandes de ces données et des coûts associés à la traduction ou la translittération non déclarée.
  
  Le rapport final du PDP sur la traduction et la translittération a reçu le soutien consensuel de sa première recommandation et le consensus absolu sur les six autres. Il a également reçu le soutien unanime du conseil de la GNSO.
  
  Suite à la clôture de la période de commentaires publics, lors de la prochaine étape, tel que prévu dans l'annexe A des statuts de l'ICANN, le Conseil d'administration de l'ICANN prendra en considération les recommandations.
  
  Quelle est la proposition à l'étude ?
  
  Les recommandations suivantes ont été adoptées :
  
  Recommandation 1 Le Groupe de travail recommande de ne pas rendre obligatoire la transformation des coordonnées. Toute partie réclamant la transformation est libre d'y procéder ponctuellement en dehors du WHOIS ou de tout système de remplacement, tel que prévu dans le protocole d'accès aux données d'enregistrement des noms de domaine (RDAP). Si le bureau d'enregistrement/l'opérateur de registre ne procède pas volontairement à la transformation (voir la recommandation 5), il revient alors à la partie requérante d'y procéder.
  
  Recommandation 2 Tout en faisant remarquer qu'un système de remplacement du WHOIS devrait être en mesure de recevoir des informations sous la forme de coordonnées dans un alphabet autre que l'ASCII, le Groupe de travail recommande que ses champs de données soient stockés et affichés de façon à identifier plus facilement ce que les différentes entrées représentent et quel(le) alphabet/langue a été utilisé(e) par le titulaire de nom de domaine enregistré.
  
  Recommandation 3 Le Groupe de travail recommande que les alphabets et langues sélectionnés par les titulaires de noms de domaine pour soumettre leurs coordonnées soient choisis conformément aux modèles commerciaux des fournisseurs de gTLD.
  
  Recommandation 4 Le Groupe de travail recommande qu'indépendamment des alphabets et des langues utilisés, il soit garanti que les champs de données soient conformes aux normes définies dans le Contrat d'accréditation de bureau d'enregistrement (RAA), la politique de consensus applicable, la politique relative aux informations WHOIS supplémentaires et toutes autres politiques en vigueur. Les coordonnées saisies sont validées conformément aux politiques et contrats susmentionnés et les alphabets/langues utilisés doivent être facilement identifiables.
  
  Recommandation 5 Le Groupe de travail recommande, s'il est procédé à la transformation des coordonnées et si le système de remplacement du WHOIS est en mesure d'afficher plus d'un ensemble de données par entrée de titulaire de nom de domaine enregistré, que ces données soient présentées dans des champs supplémentaires (en sus des champs d'alphabet local faisant autorité fournis par le titulaire de nom de domaine) et que ces champs soient marqués comme transformés et que leurs sources soient précisées.
  
  Recommandation 6 Le Groupe de travail recommande que tout système de remplacement du WHOIS, par exemple le RDAP, reste suffisamment flexible pour pouvoir ajouter les coordonnées dans les nouveaux alphabets/langues et développe ses capacités en alphabets/langues afin de recevoir, stocker et afficher les coordonnées.
  
  Recommandation 7 Le Groupe de travail recommande que ces recommandations soient mises en relation avec les autres modifications du WHOIS le cas échéant et soient mises en œuvre et/ou appliquées dès qu'un système de remplacement du WHOIS en mesure de recevoir, stocker et afficher des caractères non-ASCII, sera opérationnel.
  
  Conclusion en ce qui concerne la deuxième question de la Charte À partir des recommandations 1 à 7, il n'est pas clair qui doit décider qui doit supporter la charge de la traduction ou de la translittération des informations de contact en un seul script commun.
  
  La recommandation 1 était accompagnée d'une Déclaration de la minorité qui disait ce qui suit : le membre du groupe de travail Petter Rindforth, conformément à la position adoptée par son unité constitutive, l'Unité constitutive des représentants de la propriété intellectuelle (ICP),² recommande la traduction et/ou la translittération (transformation) obligatoire des informations de contact dans tous les domaines de premier niveau génériques (gTLD).
  
  Bien que conscient qu'il existe des situations dans lesquelles les coordonnées dans la langue locale du titulaire de nom de domaine constituent la version première, de sorte à identifier le titulaire de nom de domaine dans le cadre de la préparation d'une action en justice au niveau local, il existe également des cas où une recherche WHOIS globale, donnant accès aux informations le plus uniformément possible, s'avère nécessaire afin que le service d'enregistrement des informations atteigne ses objectifs de transparence et de responsabilité du DNS. Voir aussi l'alinéa 5.1.1 [du rapport Final], qui explique les fondements du groupe de travail qui soutiennent la transformation obligatoire des informations de contact dans tous les domaines génériques de premier niveau.
  
  Quelles parties intéressées ou autres entités ont été consultées ?
  
  Des consultations régulières avec les parties prenantes ont eu lieu pendant la durée de ce PDP, particulièrement au cours de trois réunions de l'ICANN (ICANN, 49, 50 et 51), ainsi que des périodes de consultation publique pour le Rapport thématique préliminaire , le Rapport initial et avant l'examen par le Conseil.
  
  Quelles sont les préoccupations ou les questions soulevées par la communauté ?
  
  La principale préoccupation soulevée par la communauté a été qu'une base de données en plusieurs scripts / plurilingue impliquera moins de transparence parce que les scripts autres que le latin pourraient être moins compréhensibles pour la majorité des utilisateurs de l'Internet. Cela réduirait aussi la capacité de faire des recherches dans ces données. On craint également que les titulaires de nom de domaine frauduleux pourraient cacher leur identité derrière des scripts/langues différents.
  
  Quels sont les documents importants examinés par le Conseil ?
  
  Le Conseil a révisé le rapport final, les recommandations du conseil de la GNSO au Conseil d'administration, ainsi que la synthèse des commentaires publics et la réponse du personnel à ces commentaires.
  
  Quels sont les facteurs que le Conseil a trouvés significatifs ?
  
  Les recommandations ont été élaborées selon le PDP de la GNSO, tel que décrit dans l'annexe A aux statuts constitutifs de l'ICANN, et ont reçu l'appui unanime du conseil de la GNSO. Comme indiqué dans les statuts, le vote de cette motion à la majorité qualifiée du conseil de la GNSO oblige le Conseil d'administration à adopter la recommandation, à moins qu'il ne détermine, par un vote de plus des deux tiers de ses membres, que la politique concernée n'est pas dans l'intérêt de la communauté de l'ICANN ou de l'ICANN comme société. En outre, la poursuite de l'internationalisation du système des noms de domaine est un domaine de travail important de l'ICANN. Les recommandations ont le potentiel d'améliorer la convivialité et l'exactitude des données de contact pour un DNS véritablement mondialisé.
  
  Y a-t-il des effets positifs ou négatifs pour la communauté ?
  
  Certains des impacts positifs identifiés dans le rapport final comprennent (sans s'y limiter) :
  - les titulaires de noms qui ne comprennent pas l'ASCII US seront en mesure d'enregistrer des noms de domaine en utilisant le script qu'ils connaissent le mieux ;
  - les bureaux d'enregistrement ne sont pas obligés de traduire ou de translittérer les données mais ils doivent valider les données indépendamment du script qu'ils soutiennent – la décision sur lesquels ils soutiennent sera régulée par l'offre et la demande.
  - les coûts d'enregistrement n'augmenteront pas, car l'exigence que les bureaux d'enregistrement traduisent ou translittèrent toutes les données de contact à un script³ impliquera inévitablement des coûts qui pourraient être reportés aux titulaires de nom de domaine ;
  - l'impact de la permission aux titulaires de noms d'utiliser le script / la langue qu'ils connaissent le mieux pour enregistrer leurs noms de domaine sera positif pour l'exactitude des données.
  Certains des impacts négatifs identifiés dans le rapport final sont :
  - que ceux visant à effectuer des recherches des données de contact qui opèrent en ASCII US pourraient avoir à traduire ou translittérer les données afin de pouvoir contacter les titulaires de noms de domaine (bien que cela soit vrai aujourd'hui pour ceux qui cherchent des informations mais ne connaissent pas l'ASCII US, même si la traduction ou la translittération étaient obligatoires).
  Y a-t-il des impacts financiers ou des répercussions à prévoir sur l'ICANN (plan stratégique, plan opérationnel, budget), la communauté ou le public ?
  
  Il n'y a pas d'impact financier pour l'ICANN. Les membres de la communauté et le public en général pourraient devoir payer des services de traduction ou de translittération professionnelle des informations de contact. Toutefois, ces coûts sont négligeables par rapport aux coûts éventuels qui pourraient se produire si en vertu d'une exigence non déclarée tous les contacts fournis dans un script autre que l'ASCII US devaient être traduits ou translittérés.
  
  Y a-t-il des implications sur la sécurité, la stabilité ou la résilience du DNS ?
  
  Le protocole WHOIS actuel n'est pas conçu pour les scripts autres que l'ASCII US. Toutefois, le protocole d'accès aux données d'enregistrement des noms de domaine (RDAP) est actuellement mis en place comme le replacement du WHOIS et il [le RDAP] est entièrement compatible avec les différents scripts. Une fois que le RDAP sera mis en œuvre – ou tout autre remplacement capable de supporter des scripts autres que l'ASCII US – il n'y aura aucune sécurité, stabilité ou questions de résilience liées au DNS si le Conseil approuve les recommandations proposées.
3. Renouvellement du contrat de registre .CAT
  
  Attendu que l'ICANN a lancé une période de consultation publique du 28 mai 2015 au 7 juillet 2015 <https://www.icann.org/public-comments/cat-renewal-2015-05-28-en > concernant un contrat de renouvellement de registre proposé pour le TLD .CAT <https://www.icann.org/resources/unthemed-pages/cat-2012-02-25-en>.
  
  Attendu que le contrat proposé pour le renouvellement du registre .CAT inclut des dispositions modifiées pour adapter le contrat de registre de .CAT à la forme du contrat de registre de nouveaux gTLD.
  
  Attendu que le forum de consultation publique sur le contrat de renouvellement proposé s'est achevé le 7 juillet 2015, l'ICANN ayant reçu quinze (15) commentaires, tant de personnes individuelles que de groupes et organisations. Un résumé et une analyse des commentaires ont été fournis au Conseil.
  
  Attendu que le contrat de renouvellement du registre a été mis à jour afin d'inclure les dispositions existantes concernant le Whois.
  
  Il est résolu (2015.09.28.04) que le renouvellement proposé du contrat de registre de .CAT soit approuvé, et le Président-directeur général, ou ses représentants autorisés, est autorisé à appliquer ces décisions comme cela lui semblera approprié pour conclure et mettre en œuvre ledit accord.
  
  Fondements de la résolution 2015.09.28.04
  
  Pourquoi le Conseil aborde cette question maintenant ?
  
  L'ICANN et la Fundació puntCAT (l'« opérateur de registre ») ont conclu un contrat de registre le 23 septembre 2005 pour l'exploitation du domaine de premier niveau .CAT. Le contrat de registre du .CAT en vigueur expire le 31 août 2013. Le contrat de renouvellement de registre proposé (le « contrat de renouvellement de registre » ou le « contrat ») a été publié pour consultation publique entre le 28 mai 2015 et le 7 juillet 2015. En ce moment, le Conseil approuve le contrat de renouvellement de registre pour la poursuite de l'exploitation du TLD .CAT par l'opérateur de registre.
  
  Quelle est la proposition à l'étude ?
  
  Le contrat de renouvellement de registre approuvé par le Conseil d'administration comprend des dispositions modifiées pour adapter le contrat à la forme du contrat de registre des nouveaux gTLD. Les modifications comprennent : mise à jour des spécifications techniques ; exigence d'inclure certaines des sauvegardes du GAC telles que les engagements d'intérêt public (qui dépendent de l'application de la procédure de règlement de litiges relatifs aux engagements d'intérêt public) ; l'exigence d'utiliser des bureaux d'enregistrement en vertu du contrat d'accréditation de bureau d'enregistrement de 2013 une fois qu'un certain seuil est atteint ; et la mise à jour des frais d'enregistrement.
  
  Pour refléter la spécificité du TLD .CAT, un TLD sponsorisé, les dispositions pertinentes du contrat de registre de TLD sponsorisés du 23 septembre 2005 ont été incluses dans le contrat de renouvellement de registre. Plus précisément, les dispositions de la charte décrivant la communauté linguistique et culturelle catalane sur Internet qui correspondent au sens de communauté et qui la rendent admissible pour l'enregistrement sont identifiées dans la spécification 12. Le contrat de renouvellement de registre reflète également les approbations précédentes concernant les noms réservés.
  
  Quelles parties intéressées ou autres entités ont été consultées ?
  
  L'ICANN a lancé une période de consultation publique sur le contrat de renouvellement de registre proposé pour .CAT du 28 mai 2015 au 7 juillet 2015, suite à laquelle les commentaires ont été résumés et analysés. En outre, l'ICANN a lancé des négociations bilatérales avec l'opérateur de registre pour convenir l'ensemble des termes à inclure dans le contrat de renouvellement de registre publié pour commentaires publics.
  
  Quelles sont les préoccupations ou les questions soulevées par la communauté ?
  
  Quinze (15) membres de la communauté ont participé à la période de consultation publique. Les membres de la communauté ont soulevé trois préoccupations clés dans leurs commentaires :
  - la transition des TLD existants à la forme du contrat de registre de nouveaux gTLD. Certains commentaires publics exprimaient l'inquiétude par rapport au processus de l'ICANN d'utiliser le contrat de registre de nouveaux gTLD comme point de départ pour le renouvellement des contrats de registre de gTLD existants. Ces commentateurs suggèrent que prendre une telle position a pour effet de transformer les procédures de règlement de litiges après-délégation de nouveaux gTLD (par exemple, la procédure de règlement de litiges après-délégation de marques déposées et la procédure de règlement de litiges relatifs aux engagements d'intérêt public) et la suspension rapide uniforme (URS) en des politiques consensuelles de fait sans suivre les procédures énoncées dans les statuts constitutifs de l'ICANN pour leur création. En revanche, d'autres commentaires soutenaient la recherche de cohérence de l'ICANN entre les contrats de registre et notaient que la transition vers la nouvelle forme de contrat fait partie des négociations bilatérales admissibles.
  - l'inclusion du système uniforme de suspension rapide (URS) et de la procédure de règlement de litiges relatifs aux marques déposées (PDDRP) dans les renouvellements de TLD existants sans passer par un processus d'élaboration de politiques (PDP): la plupart des commentaires reçus exprimaient leur opposition à l'inclusion de l'URS dans le renouvellement proposé du contrat de registre .CAT, affirmant que l'URS peut devenir une politique consensuelle seulement après un processus d'élaboration de politiques (PDP) auquel toute la communauté de parties prenantes de l'ICANN ait participé. Ces commentateurs suggéraient également que l'imposition de l'URS sur un gTLD existant à travers le processus contractuel est une intervention de personnel inacceptable dans le processus d'élaboration de politiques. En revanche, certains commentaires exprimaient leur appui à l'inclusion de l'URS dans le contrat de renouvellement de registre, déclarant que les registres sont libres d'aller au-delà de la protection de droits minimaux et ne requièrent pas de PDP.
  Quels sont les documents importants examinés par le Conseil ?
  
  Dans le cadre de ses délibérations, le Conseil d'administration a examiné plusieurs documents, y compris mais sans s'y limiter, les suivants :
  - Le contrat de renouvellement de registre proposé pour le .CAT et ses annexes <https://www.icann.org/public-comments/cat-renewal-2015-05-28-en>
  - Commentaires publics
  - Résumé et analyse de la consultation publique <https://www.icann.org/en/system/files/files/reissued-report-comments-cat-renewal-18aug15-en.pdf>
  - Rapport de l'IRT : https://archive.icann.org/en/topics/new-gtlds/irt-final-report-trademark-protection-29may09-en.pdf
  - Rapport des STI : https://www.icann.org/news/announcement-2-2009-12-17-en
  - Contrat de registre actuel de .PRO < https://www.icann.org/resources/unthemed-pages/cat-2012-02-25-en>
  - Contrat de registre de base – mis à jour le 9 janvier 2014 <http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.pdf>
  - Séance de travail de la GNSO du 21 juin 2015 lors de la 53e réunion de l'ICANN à Buenos Aires (mise à jour de la GDD à la GNSO : < https://buenosaires53.icann.org/en/schedule/sun-gnso-working/audio-gnso-working-1-21jun15-en>
  Quels sont les facteurs que le Conseil a trouvés significatifs ?
  
  Le Conseil a soigneusement examiné les commentaires publics reçus pour le contrat de renouvellement de registre, ainsi que le résumé et l'analyse de ces commentaires. Le Conseil a également examiné les termes convenus par l'opérateur de registre dans le cadre des négociations bilatérales avec l'ICANN. Alors que le Conseil reconnaît les préoccupations exprimées par certains membres de la communauté concernant l'inscription de l'URS dans le contrat de renouvellement de registre, le Conseil note que cela dépend des négociations bilatérales entre l'ICANN et l'opérateur de registre, où l'opérateur de registre a manifesté son intérêt de renouveler son contrat de registre pour se conformer aux dispositions du contrat de registre des nouveaux gTLD.
  
  Le Conseil d'administration note que l'URS a été recommandé par l'équipe de mise en œuvre des recommandations (IRT) comme un mécanisme de protection des droits (RPM) obligatoire pour tous les nouveaux gTLD. Il a été demandé à la GNSO de fournir son point de vue au sujet de si les mécanismes de protection des droits recommandés (qui comprenaient l'URS) étaient cohérents avec la politique d'introduction des nouveaux gTLD proposée par la GNSO et s'ils constituaient une option appropriée et effective pour atteindre les principes et les objectifs fixés para la GNSO. La STI a examiné cette question et a conclu que « l'utilisation de l'URS devrait être un RPM requis pour tous les nouveaux gTLD ». Autrement dit, la GNSO a déclaré que l'URS n'était incompatible avec aucune de ses recommandations de politique existantes.
  
  Bien que l'URS ait été développé et peaufiné par le processus décrit ici, y compris la révision publique et la discussion dans la GNSO, il n'a pas été adopté comme une politique consensuelle et l'ICANN n'a aucune possibilité de le rendre obligatoire pour des TLD autres que les nouveaux candidats aux gTLD ayant déposé leur candidature au cours de la série de nouveaux gTLD de 2012.
  
  Par conséquent, l'approbation du contrat de renouvellement de registre par le Conseil d'administration n'est pas une motion de faire l'URS obligatoire pour les TLD existants, et il serait inapproprié de le faire. Dans le cas de .CAT, l'inclusion de l'URS a été développée dans le cadre de la proposition au cours des négociations bilatérales entre l'opérateur de registre et l'ICANN.
  
  En outre, le Conseil a examiné les commentaires concernant les gTLD existants qui se conforment à la nouvelle forme du contrat de registre. Le Conseil d'administration note que le contrat de registre existant demande un renouvellement crédible du contrat au moment de son échéance pourvu que certaines conditions soient remplies. Le contrat de renouvellement fait l'objet de la négociation des termes de renouvellement raisonnablement acceptables pour l'ICANN et pour l'opérateur de registre. Les termes du renouvellement approuvés par le Conseil résultent des négociations bilatérales demandées dans l'actuel contrat de registre, et la transition vers la nouvelle forme du contrat de registre ne violerait pas la politique établie de la GNSO. Tel que décrit ci-dessous, la nouvelle forme du contrat de registre fournit certains avantages opérationnels, outre les avantages pour les titulaire de noms de domaine et la communauté Internet, y compris les engagements d'intérêt public, l'exigence d'utiliser des bureaux d'enregistrement ayant signé le RAA 2013 et la capacité de l'ICANN de désigner un opérateur de registre provisoire d'urgence dans l'éventualité où les seuils d'urgence pour les services de registre critiques soient atteints.
  
  Y a-t-il des effets positifs ou négatifs pour la communauté ?
  
  Dans le cadre du processus de renouvellement, l'ICANN a mené une révision des performances récentes de l'opérateur de registre en vertu du contrat de registre actuel du .CAT. L'opérateur de registre s'est avéré avoir rempli substantiellement ses exigences contractuelles.
  
  L'approbation du Conseil d'administration du contrat de renouvellement de registre offre également des avantages techniques et opérationnels positifs. En conformité avec le contrat de renouvellement de registre, au cas où un des seuils d'urgence pour les fonctions de registre serait atteint, l'opérateur de registre accepte que l'ICANN puisse désigner un opérateur de registre provisoire d'urgence pour le registre du TLD, ce qui atténuerait les risques pour la stabilité et la sécurité du système de noms de domaine. Aussi, l'intégration technique de l'opérateur de registre pour se conformer aux dispositions du contrat des nouveaux gTLD permettra au registre d'utiliser des processus automatisés et uniformes, ce qui facilitera l'utilisation du TLD. Le contrat de renouvellement de registre inclut également des sauvegardes sous forme d'engagements d'intérêt public dans la spécification 11.
  
  Cela aura aussi un impact positif sur les bureaux d'enregistrement et les titulaires de noms de domaine. La transition vers le contrat de registre des nouveaux gTLD apportera une cohérence à l'ensemble des registres, ce qui conduira à un environnement plus prévisible pour les utilisateurs finaux et le fait que le renouvellement proposé du contrat de registre exige que l'opérateur de registre utilise des bureaux d'enregistrement accrédités par l'ICANN qui aient signé le contrat d'accréditation des bureaux d'enregistrement (RAA) de 2013 fournira plus d'avantages pour les bureaux d'enregistrement et les titulaires de noms.
  
  Protection des titulaires de droits : le contrat des nouveaux gTLD permettra à l'opérateur de registre d'adopter des mécanismes de protection des droits supplémentaires pour protéger les titulaires de droits.
  
  Y a-t-il des impacts financiers ou des répercussions à prévoir sur l'ICANN (plan stratégique, plan opérationnel, budget), la communauté ou le public ?
  
  Aucun impact financier significatif n'est à prévoir suite à l'approbation par l'ICANN du renouvellement proposé de l'accord de registre du .CAT. Il convient toutefois de noter que suite à l'approbation du renouvellement du contrat de registre, les frais de registre annuels prévus diminuent de 112 000 USD à 56 000 USD. L'impact financier nominal est compensé par les avantages supplémentaires pour les titulaires de noms de domaine et la communauté Internet, y compris les engagements d'intérêt public, l'exigence d'utiliser des bureaux d'enregistrement ayant signé le RAA 2013 et la capacité de l'ICANN de désigner un opérateur de registre provisoire d'urgence dans l'éventualité où les seuils d'urgence pour les services de registre critiques soient atteints.
  
  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 du DNS n'est à prévoir suite à l'approbation par l'ICANN du renouvellement proposé de l'accord de registre du .CAT. En fait, le renouvellement du contrat de registre proposé comprend des dispositions destinées à permettre la mise en place d'actions plus rapides au cas où il y aurait des menaces à la sécurité ou à la stabilité du DNS. Dans le cadre de la fonction administrative organisationnelle de l'ICANN, l'ICANN a publié la version préliminaire du contrat de renouvellement de registre pour consultation publique le 28 mai 2015.
4. Renouvellement du contrat de registre .TRAVEL
  
  Attendu que l'ICANN a lancé une période de consultation publique du 12 mai 2015 au 5 juillet 2015 <https://www.icann.org/public-comments/travel-renewal-2015-05-12-en > concernant un contrat de renouvellement de registre proposé pour le TLD .TRAVEL <https://www.icann.org/resources/unthemed-pages/travel-2012-02-25-en>.
  
  Attendu que le contrat proposé pour le renouvellement du registre .TRAVEL inclut des dispositions modifiées pour adapter le contrat de registre de .TRAVEL aux formes du contrat de registre de nouveaux gTLD.
  
  Attendu que le forum de consultation publique sur le contrat de renouvellement proposé s'est achevé le 5 juillet 2015, l'ICANN ayant reçu quinze (15) commentaires, tant de personnes individuelles que de groupes et organisations. Un résumé et une analyse des commentaires ont été fournis au Conseil.
  
  Attendu que le Conseil a déterminé qu'aucune révision au contrat de registre pour le renouvellement du registre .TRAVEL ne sera nécessaire après avoir pris en considération les commentaires.
  
  Il est résolu (2015.09.28.05) que le renouvellement proposé du contrat de registre de .CAT soit approuvé, et le Président-directeur général, ou ses représentants autorisés, est autorisé à appliquer ces décisions comme cela lui semblera approprié pour conclure et mettre en œuvre ledit accord.
  
  Fondements de la résolution 2015.09.28.05
  
  Pourquoi le Conseil aborde cette question maintenant ?
  
  L'ICANN et Tralliance Registry Management Company, LLC (l'« opérateur de registre ») ont conclu un contrat de registre le 5 mai 2005 pour l'exploitation du domaine de premier niveau .TRAVEL. Le contrat de registre de .TRAVEL en vigueur expire le 19 octobre 2015. Le contrat de renouvellement de registre proposé (le « contrat de renouvellement de registre » ou le « contrat ») a été publié pour consultation publique entre le 12 mai 2015 et le 5 juillet 2015. En ce moment, le Conseil approuve le contrat de renouvellement de registre pour la poursuite de l'exploitation du TLD .TRAVEL par l'opérateur de registre.
  
  Quelle est la proposition à l'étude ?
  
  Le contrat de renouvellement de registre approuvé par le Conseil d'administration comprend des dispositions modifiées pour adapter le contrat à la forme du contrat de registre des nouveaux gTLD. Les modifications comprennent : mise à jour des spécifications techniques ; exigence d'inclure certaines des sauvegardes du GAC telles que les engagements d'intérêt public (qui dépendent de l'application de la procédure de règlement de litiges relatifs aux engagements d'intérêt public) ; l'exigence d'utiliser des bureaux d'enregistrement en vertu du contrat d'accréditation de bureau d'enregistrement de 2013 une fois qu'un certain seuil est atteint ; et la mise à jour des frais d'enregistrement.
  
  Pour refléter la spécificité du TLD .TRAVEL, un TLD sponsorisé, les dispositions pertinentes du contrat de registre de TLD sponsorisés du 5 mai 2005 ont été incluses dans le contrat de renouvellement de registre. Plus précisément, les dispositions de la charte décrivant les secteurs de l'industrie des voyages qui correspondent au sens de communauté et qui la rendent admissible pour l'enregistrement sont identifiées dans la spécification 12. Le contrat de renouvellement de registre reflète également les approbations précédentes concernant les noms réservés.
  
  Quelles parties intéressées ou autres entités ont été consultées ?
  
  L'ICANN a lancé une période de consultation publique sur le contrat de renouvellement de registre proposé pour .TRAVEL du 12 mai 2015 au 5 juillet 2015, suite à laquelle les commentaires ont été résumés et analysés. En outre, l'ICANN a lancé des négociations bilatérales avec l'opérateur de registre pour convenir l'ensemble des termes à inclure dans le contrat de renouvellement de registre publié pour commentaires publics.
  
  Quelles sont les préoccupations ou les questions soulevées par la communauté ?
  
  Quinze (15) membres de la communauté ont participé à la période de consultation publique. Les membres de la communauté ont soulevé deux préoccupations clés dans leurs commentaires :
  - transition des TLD existants à la forme du contrat de registre de nouveaux gTLD. Certains commentaires publics exprimaient l'inquiétude par rapport au processus de l'ICANN d'utiliser le contrat de registre de nouveaux gTLD comme point de départ pour le renouvellement des contrats de registre de gTLD existants. Ces commentateurs suggèrent que prendre une telle position a pour effet de transformer les procédures de règlement de litiges après-délégation de nouveaux gTLD (par exemple, la procédure de règlement de litiges après-délégation de marques déposées et la procédure de règlement de litiges relatifs aux engagements d'intérêt public) et la suspension rapide uniforme (URS) en des politiques consensuelles de fait sans suivre les procédures énoncées dans les statuts constitutifs de l'ICANN pour leur création. En revanche, d'autres commentaires soutenaient la recherche de cohérence de l'ICANN entre les contrats de registre et notaient que la transition vers la nouvelle forme de contrat fait partie des négociations bilatérales admissibles.
  - inclusion du système uniforme de suspension rapide (URS) et de la procédure de règlement de litiges relatifs aux marques déposées (PDDRP) dans les renouvellements de TLD existants sans passer par un processus d'élaboration de politiques (PDP): la plupart des commentaires reçus exprimaient leur opposition à l'inclusion de l'URS dans le renouvellement proposé du contrat de registre .TRAVEL, affirmant que l'URS peut devenir une politique consensuelle seulement après un processus d'élaboration de politiques (PDP) auquel toute la communauté de parties prenantes de l'ICANN ait participé. Ces commentateurs suggéraient également que l'imposition de l'URS sur un gTLD existant à travers le processus contractuel est une intervention de personnel inacceptable dans le processus d'élaboration des politiques. En revanche, certains commentaires exprimaient leur appui à l'inclusion de l'URS dans le contrat de renouvellement de registre, déclarant que les registres sont libres d'aller au-delà de la protection de droits minimaux et ne requièrent pas de PDP.
  Quels sont les documents importants examinés par le Conseil ?
  
  Dans le cadre de ses délibérations, le Conseil d'administration a examiné plusieurs documents, y compris mais sans s'y limiter, les suivants :
  - le contrat de renouvellement de registre proposé pour le .TRAVEL et ses annexes <https://www.icann.org/public-comments/travel-renewal-2015-05-12-en>
  - commentaires publics
  - résumé et analyse de la consultation publique <https://www.icann.org/en/system/files/files/reissued-report-comments-travel-renewal-18aug15-en.pdf>
  - rapport de l'IRT : https://archive.icann.org/en/topics/new-gtlds/irt-final-report-trademark-protection-29may09-en.pdf
  - rapport des STI : https://www.icann.org/news/announcement-2-2009-12-17-en
  - contrat de registre actuel de .TRAVEL <https://www.icann.org/resources/unthemed-pages/travel-2012-02-25-en>
  - contrat de registre de base – mis à jour le 9 janvier 2014 <http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.pdf>
  - séance de travail de la GNSO du 21 juin 2015 lors de la 53e réunion de l'ICANN à Buenos Aires (mise à jour de la GDD à la GNSO : <https://buenosaires53.icann.org/en/schedule/sun-gnso-working/audio-gnso-working-1-21jun15-en>
  Quels sont les facteurs que le Conseil a trouvés significatifs ?
  
  Le Conseil a soigneusement examiné les commentaires publics reçus pour le contrat de renouvellement de registre, ainsi que le résumé et l'analyse de ces commentaires. Le Conseil a également examiné les termes convenus par l'opérateur de registre dans le cadre des négociations bilatérales avec l'ICANN. Alors que le Conseil reconnaît les préoccupations exprimées par certains membres de la communauté concernant l'inscription de l'URS dans le contrat de renouvellement de registre, le Conseil note que cela dépend des négociations bilatérales entre l'ICANN et l'opérateur de registre, où l'opérateur de registre a manifesté son intérêt de renouveler son contrat de registre pour se conformer aux dispositions du contrat de registre des nouveaux gTLD.
  
  Le Conseil d'administration note que l'URS a été recommandé par l'équipe de mise en œuvre des recommandations (IRT) comme un mécanisme de protection des droits (RPM) obligatoire pour tous les nouveaux gTLD. Il a été demandé à la GNSO de fournir son point de vue au sujet de si les mécanismes de protection des droits recommandés (qui comprenaient l'URS) étaient cohérents avec la politique d'introduction des nouveaux gTLD proposée par la GNSO et s'ils constituaient une option appropriée et effective pour atteindre les principes et les objectifs fixés para la GNSO. La STI a examiné cette question et a conclu que « l'utilisation de l'URS devrait être un RPM requis pour tous les nouveaux gTLD ». Autrement dit, la GNSO a déclaré que l'URS n'était incompatible avec aucune de ses recommandations de politique existantes.
  
  Bien que l'URS ait été développé et peaufiné par le processus décrit ici, y compris la révision publique et la discussion dans la GNSO, il n'a pas été adopté comme une politique consensuelle et l'ICANN n'a aucune possibilité de le rendre obligatoire pour des TLD autres que les nouveaux candidats aux gTLD ayant déposé leur candidature au cours de la série de nouveaux gTLD de 2012.
  
  Par conséquent, l'approbation du contrat de renouvellement de registre par le Conseil d'administration n'est pas une motion de faire l'URS obligatoire pour les TLD existants, et il serait inapproprié de le faire. Dans le cas de .TRAVEL, l'inclusion de l'URS a été développée dans le cadre de la proposition au cours des négociations bilatérales entre l'opérateur de registre et l'ICANN.
  
  En outre, le Conseil a examiné les commentaires concernant les gTLD existants qui se conforment à la nouvelle forme du contrat de registre. Le Conseil d'administration note que le contrat de registre existant demande un renouvellement crédible du contrat au moment de son échéance pourvu que certaines conditions soient remplies. Le contrat de renouvellement fait l'objet de la négociation des termes de renouvellement raisonnablement acceptables pour l'ICANN et pour l'opérateur de registre. Les termes du renouvellement approuvés par le Conseil résultent des négociations bilatérales demandées dans l'actuel contrat de registre, et la transition vers la nouvelle forme du contrat de registre ne violerait pas la politique établie de la GNSO. Tel que décrit ci-dessous, la nouvelle forme du contrat de registre fournit certains avantages opérationnels, outre les avantages pour les titulaire de noms de domaine et la communauté Internet, y compris les engagements d'intérêt public, l'exigence d'utiliser des bureaux d'enregistrement ayant signé le RAA 2013 et la capacité de l'ICANN de désigner un opérateur de registre provisoire d'urgence dans l'éventualité où les seuils d'urgence pour les services de registre critiques soient atteints.
  
  Y a-t-il des effets positifs ou négatifs pour la communauté ?
  
  Dans le cadre du processus de renouvellement, l'ICANN a mené une révision des performances récentes de l'opérateur de registre en vertu du contrat de registre actuel de .TRAVEL. L'opérateur de registre s'est avéré avoir rempli substantiellement ses exigences contractuelles.
  
  L'approbation du Conseil d'administration du contrat de renouvellement de registre offre également des avantages techniques et opérationnels positifs. En conformité avec le contrat de renouvellement de registre, au cas où un des seuils d'urgence pour les fonctions de registre serait atteint, l'opérateur de registre accepte que l'ICANN puisse désigner un opérateur de registre provisoire d'urgence pour le registre du TLD, ce qui atténuerait les risques pour la stabilité et la sécurité du système de noms de domaine. Aussi, l'intégration technique de l'opérateur de registre pour se conformer aux dispositions du contrat des nouveaux gTLD permettra au registre d'utiliser des processus automatisés et uniformes, ce qui facilitera l'utilisation du TLD. Le contrat de renouvellement de registre inclut également des sauvegardes sous forme d'engagements d'intérêt public dans la spécification 11.
  
  Cela aura aussi un impact positif sur les bureaux d'enregistrement et les titulaires de noms de domaine. La transition vers le contrat de registre des nouveaux gTLD apportera une cohérence à l'ensemble des registres, ce qui conduira à un environnement plus prévisible pour les utilisateurs finaux et le fait que le renouvellement proposé du contrat de registre exige que l'opérateur de registre utilise des bureaux d'enregistrement accrédités par l'ICANN qui aient signé le contrat d'accréditation des bureaux d'enregistrement (RAA) de 2013 fournira plus d'avantages pour les bureaux d'enregistrement et les titulaires de noms.
  
  Protection des titulaires de droits : le contrat des nouveaux gTLD permettra à l'opérateur de registre d'adopter des mécanismes de protection des droits supplémentaires pour protéger les titulaires de droits.
  
  Y a-t-il des impacts financiers ou des répercussions à prévoir sur l'ICANN (plan stratégique, plan opérationnel, budget), la communauté ou le public ?
  
  Aucun impact fiscal significatif n'est à prévoir suite à l'approbation par l'ICANN du renouvellement proposé de l'accord de registre du .TRAVEL. Il convient toutefois de noter que suite à l'approbation du renouvellement du contrat de registre, les frais de registre annuels prévus diminuent de 46 000 USD à 25 000 USD. L'impact financier nominal est compensé par les avantages supplémentaires pour les titulaires de noms de domaine et la communauté Internet, y compris les engagements d'intérêt public, l'exigence d'utiliser des bureaux d'enregistrement ayant signé le RAA 2013 et la capacité de l'ICANN de désigner un opérateur de registre provisoire d'urgence dans l'éventualité où les seuils d'urgence pour les services de registre critiques soient atteints.
  
  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 du DNS n'est à prévoir suite à l'approbation par l'ICANN du renouvellement proposé de l'accord de registre de .TRAVEL. En fait, le renouvellement du contrat de registre proposé comprend des dispositions destinées à permettre la mise en place d'actions plus rapides au cas où il y aurait des menaces à la sécurité ou à la stabilité du DNS. Dans le cadre de la fonction administrative organisationnelle de l'ICANN, l'ICANN a publié la version préliminaire du contrat de renouvellement de registre pour consultation publique le 12 mai 2015.
5. Renouvellement du contrat de registre .PRO
  
  Attendu que l'ICANN a lancé une période de consultation publique du 28 mai 2015 au 7 juillet 2015 <https://www.icann.org/public-comments/pro-renewal-2015-05-28-en > concernant un contrat de renouvellement de registre proposé pour le TLD .PRO. <https://www.icann.org/resources/unthemed-pages/pro-2012-02-25-en>.
  
  Attendu que le contrat proposé pour le renouvellement du registre .PRO inclut des dispositions modifiées pour adapter le contrat de registre de .PRO à la forme du contrat de registre de nouveaux gTLD.
  
  Attendu que le forum de consultation publique sur le contrat de renouvellement proposé s'est achevé le 7 juillet 2015, l'ICANN ayant reçu quatorze (14) commentaires, tant de personnes individuelles que de groupes et organisations. Un résumé et une analyse des commentaires ont été fournis au Conseil.
  
  Attendu que le contrat de renouvellement du registre a été mis à jour afin d'inclure les dispositions existantes concernant les enregistrements des domaines de troisième niveau.
  
  Il est résolu (2015.09.28.06) que le renouvellement proposé du contrat de registre de .PRO soit approuvé, et le Président-directeur général, ou ses représentants autorisés, est autorisé à appliquer ces décisions comme cela lui semblera approprié pour conclure et mettre en œuvre ledit accord.
  
  Fondements de la résolution 2015.09.28.06
  
  Pourquoi le Conseil aborde cette question maintenant ?
  
  L'ICANN et Registry Services Corporation (l'« opérateur de registre ») ont conclu un contrat de registre le 22 avril 2010 pour l'exploitation du domaine de premier niveau .PRO. Le contrat de registre de .PRO en vigueur expire le 20 octobre 2015. Le contrat de renouvellement de registre proposé (le « contrat de renouvellement de registre » ou le « contrat ») a été publié pour consultation publique entre le 28 mai 2015 et le 7 juillet 2015. En ce moment, le Conseil approuve le contrat de renouvellement de registre pour la poursuite de l'exploitation du TLD .PRO par l'opérateur de registre.
  
  Quelle est la proposition à l'étude ?
  
  Le contrat de renouvellement de registre approuvé par le Conseil d'administration comprend des dispositions modifiées pour adapter le contrat à la forme du contrat de registre des nouveaux gTLD. Les modifications comprennent : mise à jour des spécifications techniques ; exigence d'inclure certaines des sauvegardes du GAC telles que les engagements d'intérêt public (qui dépendent de l'application de la procédure de règlement de litiges relatifs aux engagements d'intérêt public) ; l'exigence d'utiliser des bureaux d'enregistrement en vertu du contrat d'accréditation de bureau d'enregistrement de 2013 une fois qu'un certain seuil est atteint ; et l'élimination des frais maximaux que le registre peut appliquer aux bureaux d'enregistrement.
  
  Plus précisément, il est proposé de remplacer les restrictions d'enregistrement actuelles de l'annexe 11 du contrat du .PRO par l'ensemble d'engagements d'intérêt public normaux applicables à tous les nouveaux gTLD. Toutefois, le contrat de renouvellement de registre proposé a été actualisé afin d'inclure des dispositions relatives à l'enregistrement des noms de domaine de troisième niveau. En outre, les sauvegardes 1 à 3 de catégorie 1 du GAC sont ajoutées à la spécification 11. Le contrat de renouvellement de registre élimine également la limite des frais maximaux que le registre peut appliquer aux bureaux d'enregistrement pour les noms de domaine et reflète les approbations précédentes concernant les noms réservés.
  
  Quelles parties intéressées ou autres entités ont été consultées ?
  
  L'ICANN a lancé une période de consultation publique sur le contrat de renouvellement de registre proposé pour .PRO du 28 mai 2015 au 7 juillet 2015, suite à laquelle les commentaires ont été résumés et analysés. En outre, l'ICANN a lancé des négociations bilatérales avec l'opérateur de registre pour convenir l'ensemble des termes à inclure dans le contrat de renouvellement de registre publié pour commentaires publics.
  
  Quelles sont les préoccupations ou les questions soulevées par la communauté ?
  
  Quatorze (14) membres de la communauté ont participé à la période de consultation publique. Les membres de la communauté ont soulevé deux préoccupations clés dans leurs commentaires :
  - transition des TLD existants à la forme du contrat de registre de nouveaux gTLD. Certains commentaires publics exprimaient l'inquiétude par rapport au processus de l'ICANN d'utiliser le contrat de registre de nouveaux gTLD comme point de départ pour le renouvellement des contrats de registre de gTLD existants. Ces commentateurs suggèrent que prendre une telle position a pour effet de transformer les procédures de règlement de litiges après-délégation de nouveaux gTLD (par exemple, la procédure de règlement de litiges après-délégation de marques déposées et la procédure de règlement de litiges relatifs aux engagements d'intérêt public) et la suspension rapide uniforme (URS) en des politiques consensuelles de fait sans suivre les procédures énoncées dans les statuts constitutifs de l'ICANN pour leur création. En revanche, d'autres commentaires soutenaient la recherche de cohérence de l'ICANN entre les contrats de registre et notaient que la transition vers la nouvelle forme de contrat fait partie des négociations bilatérales admissibles.
  - inclusion du système uniforme de suspension rapide (URS) et de la procédure de règlement de litiges relatifs aux marques déposées (PDDRP) dans les renouvellements de TLD existants sans passer par un processus d'élaboration de politiques (PDP): la plupart des commentaires reçus exprimaient leur opposition à l'inclusion de l'URS dans le renouvellement proposé du contrat de registre .PRO, affirmant que l'URS peut devenir une politique consensuelle seulement après un processus d'élaboration de politiques (PDP) auquel toute la communauté de parties prenantes de l'ICANN ait participé. Ces commentateurs suggéraient également que l'imposition de l'URS sur un gTLD existant à travers le processus contractuel est une intervention de personnel inacceptable dans le processus d'élaboration des politiques. En revanche, certains commentaires exprimaient leur appui à l'inclusion de l'URS dans le contrat de renouvellement de registre, déclarant que les registres sont libres d'aller au-delà de la protection de droits minimaux et ne requièrent pas un PDP.
  Quels sont les documents importants examinés par le Conseil ?
  
  Dans le cadre de ses délibérations, le Conseil d'administration a examiné plusieurs documents, y compris mais sans s'y limiter, les suivants :
  - le contrat de renouvellement de registre proposé pour .PRO et ses annexes https://www.icann.org/public-comments/pro-renewal-2015-05-28-en >
  - le contrat de renouvellement de registre proposé actualisé et modifié, avec le suivi des modifications, afin de refléter les dispositions incluses relatives à l'enregistrement des noms de domaine de troisième niveau.
  - commentaires publics
  - résumé et analyse de la consultation publique <https://www.icann.org/en/system/files/files/reissued-report-comments-pro-renewal-18aug15-en.pdf>
  - rapport de l'IRT : https://archive.icann.org/en/topics/new-gtlds/irt-final-report-trademark-protection-29may09-en.pdf
  - rapport des STI : https://www.icann.org/news/announcement-2-2009-12-17-en
  - contrat de registre actuel de .PRO < https://www.icann.org/resources/unthemed-pages/pro-2012-02-25-en>
  - contrat de registre de base – mis à jour le 9 janvier 2014 <http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.pdf>
  - Séance de travail de la GNSO du 21 juin 2015 lors de la 53e réunion de l'ICANN à Buenos Aires (mise à jour de la GDD à la GNSO : < https://buenosaires53.icann.org/en/schedule/sun-gnso-working/audio-gnso-working-1-21jun15-en>
  Quels sont les facteurs que le Conseil a trouvés significatifs ?
  
  Le Conseil a soigneusement examiné les commentaires publics reçus pour le contrat de renouvellement de registre, ainsi que le résumé et l'analyse de ces commentaires. Le Conseil a également examiné les termes convenus par l'opérateur de registre dans le cadre des négociations bilatérales avec l'ICANN. Alors que le Conseil reconnaît les préoccupations exprimées par certains membres de la communauté concernant l'inscription de l'URS dans le contrat de renouvellement de registre, le Conseil note que cela dépend des négociations bilatérales entre l'ICANN et l'opérateur de registre, où l'opérateur de registre a manifesté son intérêt de renouveler son contrat de registre pour se conformer aux dispositions du contrat de registre des nouveaux gTLD.
  
  Le Conseil d'administration note que l'URS a été recommandé par l'équipe de mise en œuvre des recommandations (IRT) comme un mécanisme de protection des droits (RPM) obligatoire pour tous les nouveaux gTLD. Il a été demandé à la GNSO de fournir son point de vue au sujet de si les mécanismes de protection des droits recommandés (qui comprenaient l'URS) étaient cohérents avec la politique d'introduction des nouveaux gTLD proposée par la GNSO et s'ils constituaient une option appropriée et effective pour atteindre les principes et les objectifs fixés para la GNSO. La STI a examiné cette question et a conclu que « l'utilisation de l'URS devrait être un RPM requis pour tous les nouveaux gTLD ». Autrement dit, la GNSO a déclaré que l'URS n'était incompatible avec aucune de ses recommandations de politique existantes.
  
  Bien que l'URS ait été développé et peaufiné par le processus décrit ici, y compris la révision publique et la discussion dans la GNSO, il n'a pas été adopté comme une politique consensuelle et l'ICANN n'a aucune possibilité de le rendre obligatoire pour des TLD autres que les nouveaux candidats aux gTLD ayant déposé leur candidature au cours de la série de nouveaux gTLD de 2012.
  
  Par conséquent, l'approbation du contrat de renouvellement de registre par le Conseil d'administration n'est pas une motion de faire l'URS obligatoire pour les TLD existants, et il serait inapproprié de le faire. Dans le cas de .PRO, l'inclusion de l'URS a été développée dans le cadre de la proposition au cours des négociations bilatérales entre l'opérateur de registre et l'ICANN.
  
  En outre, le Conseil a examiné les commentaires concernant les gTLD existants qui se conforment à la nouvelle forme du contrat de registre. Le Conseil d'administration note que le contrat de registre existant demande un renouvellement crédible du contrat au moment de son échéance pourvu que certaines conditions soient remplies. Le contrat de renouvellement fait l'objet de la négociation des termes de renouvellement raisonnablement acceptables pour l'ICANN et pour l'opérateur de registre. Les termes du renouvellement approuvés par le Conseil résultent des négociations bilatérales demandées dans l'actuel contrat de registre, et la transition vers la nouvelle forme du contrat de registre ne violerait pas la politique établie de la GNSO. Tel que décrit ci-dessous, la nouvelle forme du contrat de registre fournit certains avantages opérationnels, outre les avantages pour les titulaire de noms de domaine et la communauté Internet, y compris les engagements d'intérêt public, l'exigence d'utiliser des bureaux d'enregistrement ayant signé le RAA 2013 et la capacité de l'ICANN de désigner un opérateur de registre provisoire d'urgence dans l'éventualité où les seuils d'urgence pour les services de registre critiques soient atteints.
  
  Y a-t-il des effets positifs ou négatifs pour la communauté ?
  
  Dans le cadre du processus de renouvellement, l'ICANN a mené une révision des performances récentes de l'opérateur de registre en vertu du contrat de registre actuel de .PRO. L'opérateur de registre s'est avéré avoir rempli substantiellement ses exigences contractuelles.
  
  L'approbation du Conseil d'administration du contrat de renouvellement de registre offre également des avantages techniques et opérationnels positifs. En conformité avec le contrat de renouvellement de registre, au cas où un des seuils d'urgence pour les fonctions de registre serait atteint, l'opérateur de registre accepte que l'ICANN puisse désigner un opérateur de registre provisoire d'urgence pour le registre du TLD, ce qui atténuerait les risques pour la stabilité et la sécurité du système de noms de domaine. Aussi, l'intégration technique de l'opérateur de registre pour se conformer aux dispositions du contrat des nouveaux gTLD permettra au registre d'utiliser des processus automatisés et uniformes, ce qui facilitera l'utilisation du TLD. Le contrat de renouvellement de registre inclut également des sauvegardes sous forme d'engagements d'intérêt public dans la spécification 11, y compris des sauvegardes 1 à 3 de catégorie 1 du GAC.
  
  Cela aura aussi un impact positif sur les bureaux d'enregistrement et les titulaires de noms de domaine. La transition vers le contrat de registre des nouveaux gTLD apportera une cohérence à l'ensemble des registres, ce qui conduira à un environnement plus prévisible pour les utilisateurs finaux et le fait que le renouvellement proposé du contrat de registre exige que l'opérateur de registre utilise des bureaux d'enregistrement accrédités par l'ICANN qui aient signé le contrat d'accréditation des bureaux d'enregistrement (RAA) de 2013 fournira plus d'avantages pour les bureaux d'enregistrement et les titulaires de noms.
  
  Protection des titulaires de droits : le contrat des nouveaux gTLD permettra à l'opérateur de registre d'adopter des mécanismes de protection des droits supplémentaires pour protéger les titulaires de droits.
  
  Y a-t-il des impacts financiers ou des répercussions à prévoir sur l'ICANN (plan stratégique, plan opérationnel, budget), la communauté ou le public ?
  
  Aucun impact fiscal significatif n'est à prévoir suite à l'approbation par l'ICANN du renouvellement proposé de l'accord de registre du .PRO.
  
  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 du DNS n'est à prévoir suite à l'approbation par l'ICANN du renouvellement proposé de l'accord de registre du .PRO. En fait, le renouvellement du contrat de registre proposé comprend des dispositions destinées à permettre la mise en place d'actions plus rapides au cas où il y aurait des menaces à la sécurité ou à la stabilité du DNS. Dans le cadre de la fonction administrative organisationnelle de l'ICANN, l'ICANN a publié la version préliminaire du contrat de renouvellement de registre pour consultation publique le 28 mai 2015.
Tous les membres du Conseil d'administration présents ont voté en faveur des résolutions 2015.09.28.01, 2015.09.28.02, 2015.09.28.03, 2015.09.28.04, 2015.09.28.05, et 2015.09.28.06. Wolfgang Kleinwächter, Erika Mann et Bruce Tonkin n'étaient pas disponibles pour voter sur ces résolutions. Les résolutions ont été adoptées.

Ordre du jour principal :
1. Conclusion du contrat pour le lieu de la réunion de l'ICANN de juin 2016
  
  Cherine Chalaby, le président du Comité de finances, a présenté le point de l'ordre du jour. Le site proposé pour la réunion de l'ICANN de juin 2016 est Panama, au Panama. Cherine a noté que le coût général du site est compétitif et se compare favorablement avec les sites des autres réunions, à savoir, Singapour, Buenos Aires et Dublin. Le Conseil a discuté que la réunion de juin 2016 sera la première réunion publique de type « B », qui comprend moins de jours et moins d'événements par rapport aux deux autres réunions publiques normales de l'ICANN dans l'année.
  
  Cherine a proposé et George Sadowsky l'a appuyé et le Conseil a pris la mesure suivante :
  
  Attendu que l'ICANN a l'intention d'organiser sa deuxième réunion publique de 2016 dans la région Amérique latine et Caraïbes.
  
  Attendu que le personnel a effectué une révision approfondie des sièges proposés pour tenir sa réunion en Amérique latine et les Caraïbes, et que le site le plus approprié a été identifié à Panama, au Panama.
  
  Il est résolu (2015.09.28.07) que le Conseil autorise le Président-directeur général, ou ses représentants désignés, à conclure et faciliter tous les contrats et les déboursements nécessaires pour l'hôtel / centre de convention hôte pour la réunion publique de l'ICANN de juin 2016 à Panama, au Panama, pour un montant ne devant ne pas dépasser 1,1 millions de dollars américains.
  
  Il est résolu (2015.09.28.08) que les éléments spécifiques de cette résolution restent confidentiels à des fins de négociation conformément au chapitre III, article 5.2 des statuts constitutifs de l'ICANN jusqu'à ce que le Président-directeur général détermine que les informations confidentielles peuvent être divulguées.
  
  Tous les membres du Conseil d'administration présents ont voté en faveur des résolutions 2015.09.28.07 et 2015.09.28.08. Wolfgang Kleinwächter, Erika Mann et Bruce Tonkin n'étaient pas disponibles pour voter sur ces résolutions. Les résolutions ont été adoptées.
  
  Fondements des résolutions 2015.09.28.07 et 2015.09.28.08
  
  Dans le cadre de son calendrier de réunions publiques, l'ICANN organise actuellement trois réunions par an dans des régions géographiques différentes (tel que décrit dans ses statuts constitutifs). La 56e réunion, prévue du 27 au 30 juin 2016, doit avoir lieu dans la région géographique de l'Amérique latine et les Caraïbes. Un appel à recommandations pour établir l'emplacement de la réunion en Amérique latine a été publié le 23 mars 2015. L'ICANN a reçu de nombreuses propositions
  
  Que le personnel a examinées avec attention, de même que d'autres endroits. Il a ensuite rédigé un document afin de déterminer quels sites remplissaient les Critères de sélection du lieu de réunion (http://meetings.icann.org/location-selection-criteria). À partir de l'analyse et des propositions, l'ICANN a identifié Panama, au Panama, comme le siège pour la 56e réunion de l'ICANN.
  
  Le Conseil a examiné l'exposé du personnel sur l'emplacement de la réunion à Panama, au Panama, et a déterminé que la proposition respectait des facteurs de sélection importants répondant à des critères de sélection des réunions, ainsi que les coûts liés des installations sélectionnées, pour la réunion publique de l'ICANN de juin 2016.
  
  Les frais d'organisation de la réunion auront un impact financier sur l'ICANN, ainsi que sur la communauté, car cela implique des frais de voyage pour se déplacer jusqu'à l'emplacement de la réunion. Cet impact est à prévoir indépendamment de l'emplacement de la réunion. Cette décision n'aura aucune incidence sur la sécurité ou la stabilité du DNS.
  
  Le Conseil d'administration remercie tous ceux qui ont adressé des propositions de lieux pour la 56^e réunion de l'ICANN.
  
  Il s'agit d'une fonction administrative et organisationnelle de l'ICANN qui ne nécessite pas de consultation publique.
2. Contrats et déboursements pour la nouvelle Initiative ERP
  
  Cherine Chalaby, le président du Comité de finances, a présenté le point de l'ordre du jour. Le Comité de finances recommande que le Conseil approuve la passation de marchés et la mise en œuvre d'une nouvelle solution de planification des ressources d'entreprise intégrée (ERP) pour remplacer l'infrastructure actuelle du système administratif de finances, de ressources humaines et d'approvisionnement, qui soutient toute l'organisation. La sécurisation et mise en œuvre d'une solution ERP intégrée dans un système unique d'enregistrement améliorera la capacité des systèmes, les fonctions de rapport générales et les capacités d'analyse, la productivité et l'efficacité interdisciplinaire et améliorer les contrôles internes. Cherine a également noté que la mise en œuvre d'une nouvelle solution ERP est plus rentable que d'essayer de moderniser le système existant.
  
  Cherine a proposé, Ray Plzak l'a appuyé et le Conseil a pris la mesure suivante :
  
  Attendu que l'ICANN a établi le besoin d'obtenir une solution de planification de ressources d'entreprise intégrée (ERP).
  
  Attendu que, au cours de sa réunion du 11 septembre 2015, le Comité de finances du Conseil a examiné les incidences financières d'une nouvelle initiative ERP et a examiné les alternatives.
  
  Attendu que certains membres du Comité des risques du Conseil d'administration ont examiné la solution ERP proposée et ont orienté le personnel au sujet des risques et des mesures d'atténuation utiles.
  
  Attendu que tant le personnel que le Comité de finances du Conseil d'administration ont recommandé que le Conseil autorise le Président-directeur général ou ses représentants désignés à prendre toutes les mesures nécessaires pour conclure les contrats pour une nouvelle initiative ERP, tel que reflété dans les documents de référence de cet article, et à faire tous les déboursements nécessaires en vertu de ces contrats.
  
  Il est résolu (2015.09.28.09) que le Conseil autorise le Président-directeur général ou ses représentants désignés à prendre toutes les mesures nécessaires pour conclure les contrats pour une nouvelle solution ERP, tel que reflété dans les documents de référence de cet article, et à faire tous les déboursements nécessaires en vertu de ces contrats.
  
  Il est résolu (2015.09.28.10) que les éléments spécifiques de cette résolution restent confidentiels à des fins de négociation conformément au chapitre III, article 5.2 des statuts constitutifs de l'ICANN jusqu'à ce que le Président-directeur général détermine que les informations confidentielles peuvent être divulguées.
  
  Tous les membres du Conseil d'administration présents ont voté en faveur des résolutions 2015.09.28.09 et 2015.09.28.10. Erika Mann n'était pas disponible pour voter sur ces résolutions. Les résolutions ont été adoptées.
  Fondements des résolutions 2015.09.28.09 et 2015.09.28.10
  
  L'ICANN a grandi en taille et en complexité au cours des cinq dernières années dans de nombreuses façons y compris, sans s'y limiter : (i) le personnel est trois fois plus nombreux ; (ii) sa présence mondiale s'est élargie à trois bureaux régionaux et plusieurs centres d'engagement ; et (iii) ses processus sont devenus plus globaux et complexes. D'autre part, l'infrastructure des systèmes administratifs indépendants de finances, ressources humaines et approvisionnement qui soutiennent l'organisation actuelle ont été conçus et mis en œuvre il y a au moins cinq ans. La sécurisation et mise en œuvre d'une solution ERP de planification des ressources d'entreprise intégrée dans un système unique d'enregistrement améliorera la capacité des systèmes, les fonctions de rapport générales et les capacités d'analyse, et la productivité et l'efficacité interdisciplinaire et améliorer les contrôles internes, ce qui accélèrerait les progrès de l'ICANN vers l'excellence opérationnelle.
  
  Le personnel a effectué une analyse approfondie des deux options disponibles : (i) mise à niveau des systèmes existant afin d'améliorer légèrement leurs capacités et de développer des interfaces dans la mesure du possible ; et (ii) mettre en œuvre une solution ERP intégrée. Bien que le coût de l'option de mise à niveau soit plus faible dans la première année, les coûts totaux du projet quinquennal dépasseraient substantiellement l'option ERP intégrée, car la mise à niveau nécessiterait encore une amélioration significative au cours des cinq années. En outre, la mise à niveau ne serait qu'une légère amélioration des capacités et de l'efficacité administratives et exigerait le développement d'interfaces coûteuses, complexes et de haute maintenance avec un ensemble de capacités très inférieures à celles de la solution intégrée.
  
  Par conséquent, la solution ERP intégrée est considéré comme une solution viable et plus rentable.
  
  Le projet de la solution ERP intégrée a été conçu comme suit :
  
  Ressources internes : le projet a été examiné rapidement mais a été remis jusqu'à ce que des ressources du personnel possédant une vaste expérience soient disponibles et jusqu'à ce que chaque département impliqué ait atteint le niveau suffisant de maturité (TI, finances, RH, approvisionnement). Avec l'embauche d'un directeur principal de TI en 2014 et un vice-président de finances en mars 2015, les deux ayant une vaste expérience dans le domaine des projets de mise en œuvre de grands systèmes, les conditions ont été respectées. Les ressources internes comprennent :
  1. trois équipes d'experts techniques : chacune comprenant deux niveaux d'experts (un directeur et des experts pour chaque fonction)
  2. quatre ressources de remblayage couvrant la période entre la conception et la mise en œuvre pour assurer que les opérations quotidiennes soient effectuées sans pour autant consacrer moins d'attention des experts au projet ERP.
  3. Un gestionnaire de projet dédié (contracté) possédant une vaste expérience dans la mise en œuvre d'ERP.
  4. trois ressources informatiques : un directeur principal de TI (gestion et contrôle), un analyste métier de TI et un gérant de TI (un pour RH, un pour les finances/approvisionnement)
  5. un comité de pilotage qui comprend : le directeur informatique, le directeur des opérations, le directeur financier et le directeur principal de TI
  6. une ressource de RH consacrée à la gestion du changement (à embaucher)
  7. Des révisions inhérentes ERM depuis le début du projet.
  Ressources externes :
  1. les plus grands fournisseurs d'ERP ont un vaste réseau de partenaires commerciaux certifiés ainsi que des ressources de conseil internes que l'ICANN consultera.
  2. L'ICANN sélectionnera les conseillers techniques les plus qualifiés à travers un processus d'entretiens individuels.
  Solution technique: modèle de logiciel en tant que service (SaaS) :
  1. Une plate-forme Web prête à configurer utilisée par tous les clients du fournisseur de solution
  2. Chaque client configure un large éventail de capacités, aux besoins de son département (aucun développement de logiciel, pas de personnalisation)
  3. Pour chaque fonction, l'éventail des processus standards et optionnels est conçu sur la base des processus et des contrôles des meilleures pratiques, prêts pour leur configuration.
  4. La plate-forme sera régulièrement mise à jour et aura une feuille de route complète des nouvelles capacités à disposition de tous les clients de la plate-forme sans frais supplémentaires
  5. La performance du système est contrôlée et gérée par le fournisseur de SaaS suivant les conventions de service (SLA).
  Sécurité du système :
  1. Transfert de données : conception d'une stratégie de conversion de données en plusieurs étapes comprenant les processus d'essais, de réconciliation et de validation.
    1. L'ICANN convertira les données transactionnelles historiques et toutes les données du fichier maître.
    2. Tous les programmes de conversion seront testés pour vérifier leur exactitude et exhaustivité.
    3. L'ICANN effectuera des tests unitaires, deux pilotes de salles de conférences (CRP), qui vérifieront le fonctionnement de nos processus commerciaux quant à la configuration du système et la conversion des fichiers de données.
    4. L'ICANN effectuera un pilote commercial, qui va simuler les processus commerciaux réels du début à la fin (par exemple, les ordres de trésorerie) et tester la conversion complète des données historiques et de fichiers maître.
  2. Sécurité des données : le processus de RFP comprend des démos du processus de reprise des opérations suite à des catastrophes, de la gestion des opérations des centres de données, de l'encodage de données, des registres de données et de l'environnement ERP exclusif à l'ICANN :
    1. l'ICANN suivra les normes mondiales pour la sécurité des données, qui comprend l'encodage des données, la gestion des contrôles d'accès, l'accès et l'examen des fichiers journaux du système et la configuration de la sécurité d'accès basée sur les contrôles internes.
  En outre, le Conseil a examiné les recommandations du personnel et du Comité de finances du Conseil d'administration au sujet de l'autorité dans le domaine de la passation de marchés et des déboursements pour une nouvelle solution ERP.
  
  La mise en œuvre d'une nouvelle solution ERP aura une incidence financière pour l'ICANN. Cet impact est actuellement inclus dans Plan opérationnel et budget approuvé par le Conseil le 25 juin 2015 pour l'exercice fiscal 2016. Cette action n'aura pas d'incidence directe sur la sécurité, la stabilité et la résilience du système des noms de domaine.
  
  Il s'agit d'une fonction administrative et organisationnelle de l'ICANN qui ne nécessite pas de consultation publique.
3. Libération des fonds de réserve - Frais de transition de la supervision de l'IANA des mains du Gouvernement des États-Unis
  
  Cherine Chalaby, président du comité des finances, a présenté le point de l'ordre du jour. Le Conseil a déjà autorisé le déboursement d'un montant ne devant pas dépasser les 7 millions de dollars américains provenant du Fonds de réserve pour couvrir les coûts de l'exercice fiscal 2015 associés à l'initiative de transition de la supervision américaine de l'IANA. Le montant total des coûts du projet de transition dépasse actuellement le montant prévu dans le budget de l'exercice fiscal 2015 (les coûts dépensés sont maintenant de 8,7 millions de dollars américains) en raison des coûts supplémentaires d'un conseil juridique indépendant externe qui a été mis en place à la demande du CCWG et du CWG. Par conséquent, le Comité de finances recommande que le Conseil autorise la libération de fonds provenant du Fonds de réserve pour couvrir les coûts supplémentaires de 1,7 millions de dollars américains.
  
  Le Conseil d'administration a discuté du grand montant de coûts qui ont été dépensés pour l'initiative de transition de la supervision américaine de l'IANA. Plusieurs membres du Conseil ont exprimé leurs inquiétudes concernant les déboursements responsables et efficaces et des mesures de contrôle des coûts des travaux futurs afin d'éviter des coûts exponentiels. Le Conseil d'administration a par la suite discuté de la définition de paramètres et d'attentes pour des dépenses futures similaires. Le Conseil a étudié la possibilité d'établir des mesures de réduction de coûts internes pour compenser le montant qui a été retiré du Fonds de réserve. Le Conseil a également discuté de la nécessité de réviser les coûts et l'historique des dépenses, les attentes pour le Fonds de réserve, les projections des exercices fiscaux 2016 et 2017 et le plan opérationnel quinquennal afin d'élaborer des recommandations sur la façon de maintenir le Fonds de réserve et de réduire les dépenses.
  
  Cherine a proposé, Gonzalo Navarro l'a appuyé et le Conseil a pris les mesures suivantes :
  
  Attendu que le 26 avril 2015 le Conseil a autorisé le déboursement d'un montant ne devant pas dépasser les 7 millions de dollars américains provenant du Fonds de réserve pour couvrir les coûts de l'exercice fiscal 2015 associés à l'initiative de transition de la supervision américaine de l'IANA.
  
  Attendu que l'ICANN a encouru des coûts réels de 8,7 millions de dollars américains au cours de son exercice fiscal 2015, y compris les coûts imprévus du conseil juridique indépendant d'environ 3,1 millions de dollars américains.
  
  Attendu que le Conseil réitère sa déclaration du 25 juin 2015 que le Conseil d'administration est « engagé à soutenir la communauté dans l'obtention du conseil dont elle a besoin pour élaborer des recommandations qui soutiennent le processus de transition et note également l'importance d'assurer que les fonds confiés à l'ICANN par la communauté soient utilisés de manière responsable et efficace. Il est encouragé d'assurer la continuité des mesures de contrôle des coûts pour les travaux futurs du conseil indépendant ». (Voir https://www.icann.org/resources/board-material/resolutions-2015-06-25-en#2.c).
  
  Attendu que le Comité de finances du Conseil a recommandé que le Conseil autorise la libération de 8,7 millions USD provenant du Fonds de réserve pour couvrir les coûts réels encourus au cours de l'exercice fiscal 2015 associés à l'initiative de transition de la supervision américaine de l'IANA et que le Conseil d'administration est d'accord.
  
  Il est résolu (2014.09.28.11) que le Conseil autorise le Président-directeur général, ou ses représentants autorisés, à retirer 8,7 millions USD provenant du Fonds de réserve pour couvrir les coûts encourus au cours de l'exercice fiscal 2015 pour l'initiative de transition de la supervision américaine de l'IANA.
  
  Douze des membres présents du Conseil ont voté en faveur de la résolution 2015.09.28.11. Ray Plzak et Kuo-Wei Wu ont voté contre la résolution 2015.09.28.11. Wolfgang Kleinwächter s'est abstenu de voter. Erika Mann n'était pas disponible pour voter sur cette résolution. La résolution a été adoptée.
  
  Fondements de la résolution 2015.09.28.11
  
  L'initiative de transition de la supervision de l'IANA du gouvernement des États-Unis est une initiative majeure pour laquelle la communauté de l'ICANN entière consacre du temps et des ressources. Il est essentiel pour l'ICANN de soutenir le travail de sa communauté en vue de la réussite totale de ce projet (qui comprend l'élaboration de la proposition de transition de la supervision américaine de l'IANA et le travail de reddition de comptes).
  
  Considérant sa nature exceptionnelle et le montant significatifs des frais qui seront engendrés, ce projet ne peut pas être financé par les recettes annuelles de l'ICANN. Par conséquent, lorsque le Conseil d'administration a approuvé le plan opérationnel et le budget de l'exercice fiscal 2015, il y a inclus le coût prévu du projet (sept millions de dollars) en déduisant la somme correspondante du fonds de réserve.
  
  Étant donné que les coûts de ce projet ont été encourus au cours de l'exercice fiscal 2015, le Conseil a approuvé le retrait de 7 millions USD provenant du Fonds de réserve pour couvrir les coûts réels associés à l'initiative de transition de la supervision américaine de l'IANA. Ce montant a été inclus dans le plan opérationnel et budget approuvé par le Conseil pour l'exercice fiscal 2015.
  
  Étant donné que les coûts réels totaux encourus au cours de l'exercice fiscal 2015 pour ce projet ont atteint les 8,7 millions USD, ce qui dépasse le montant total de 7 millions de retrait du Fonds de réserve que le Conseil avait autorisé dans sa décision 2015.04.26.17, l'ICANN essaye d'obtenir l'approbation du Conseil d'administration pour retirer 8,7 millions USD du Fonds de réserve pour couvrir le montant total des coûts effectivement encourus. Cette action n'aura pas d'incidence directe sur la sécurité, la stabilité et la résilience du système des noms de domaine.
  
  Il s'agit d'une fonction administrative et organisationnelle de l'ICANN qui ne nécessite pas de consultation publique.
4. Programme des nouveaux gTLD : parcours vers les prochaines séries
  
  Akram Atallah, président de la division des domaines mondiaux, a présenté l'ordre du jour. Le Conseil d'administration a été invité à envisager un processus et un calendrier pour une série supplémentaire du programme des nouveaux gTLD. Les révisions de la série de 2012 sont actuellement en cours. Le Conseil a examiné l'importance d'avoir toutes les révisions et l'évaluation des révisions terminées avant le lancement de la prochaine série, car les révisions et leurs évaluations informeront quand et comment la prochaine série aura lieu. Une fois achevées les révisions de la communauté et les évaluations, le Conseil sera en mesure de proposer un calendrier pour le lancement de la prochaine série du programme des nouveaux gTLD.
  
  Chris Disspain a proposé et Cherine Chalaby a appuyé la résolution proposée, et le Conseil d'administration a pris la décision suivante :
  
  Attendu que, la résolution 2012.02.07.05 du Conseil d'administration a réaffirmé l'engagement de l'ICANN de lancer une série supplémentaire du programme des nouveaux gTLD aussi rapidement que possible.
  
  Attendu que les révisions de la série de 2012 du programme des nouveaux gTLD sont actuellement en cours.
  
  Attendu que le Conseil encourage la participation des parties prenantes au processus ascendant pour examiner et élaborer de futures séries du programme des nouveaux gTLD.
  
  Il est résolu (2015.09.28.12) que le Conseil ordonne au personnel de l'ICANN de continuer avec les révisions du programme des nouveaux gTLD comme prévu et encourage la communauté de parties prenantes à participer et à soutenir un processus de révision fiable et important.
  
  Il est résolu (2015.09.28.13) que le Conseil suive avec intérêt le travail de la communauté et tienne compte des indications sur les prochaines séries une fois que le processus de révision et le processus potentiel d'élaboration des politiques de la GNSO auront atteint un stade plus avancé.
  
  Tous les membres du Conseil d'administration présents ont voté en faveur des résolutions 2015.09.28.12 et 2015.09.28.13. Erika Mann n'était pas disponible pour voter sur ces résolutions. Les résolutions ont été adoptées.
  Fondements des résolutions 2015.09.28.12 et 2015.09.28.13
  
  Pourquoi le Conseil d'administration aborde-t-il cette question maintenant?
  
  De nombreuses activités de révision et communautaires sont actuellement en cours et informeront quand la prochaine série aura lieu et comment elle s'effectuera. Le Conseil d'administration a été invité à envisager un processus et un calendrier pour une série supplémentaire du programme des nouveaux gTLD afin d'aider l'ICANN avec la planification, l'analyse et la budgétisation à long terme nécessaires pour la réalisation d'une prochaine série efficace.
  
  Quelles sont les propositions à l'étude ?
  
  Le Conseil considère la mesure dans laquelle les nombreux processus de révision et les activités communautaires en cours informeront quand et comment la prochaine série du programme des nouveaux gTLD sera entreprise. Trois options ont été envisagées. La première établit une date butoir pour les contributions de la communauté dans les prochaines séries et prévoit un délai approximatif pour l'achèvement du processus de révision et du possible PDP. Il n'engage aucune partie à un délai strict d'achèvement d'une révision ou activité d'élaboration de politiques, mais au contraire fournit un délai approximatif pour toutes les parties afin de les aider avec leur planification. La deuxième option prévoit un processus précoce par lequel le Conseil d'administration examinerait d'abord les résultats de la révisions avant d'indiquer au personnel d'élaborer des plans de mise en œuvre et des calendriers. La troisième diffère la mise en place d'un calendrier ou un ensemble de conditions préalables pour la prochaine série jusqu'à ce que le processus de révision et/ou le PDP atteignent un stade plus avancé.
  
  En ce moment, le Conseil prend des mesures pour encourager la poursuite de l'exécution et la participation aux processus de révision actuels et pour reporter la considération de la planification de futures séries jusqu'à ce que les révisions soient à un stade plus avancé.
  
  Quelles parties prenantes ou autres ont été consultées ?
  
  À partir de septembre 2014, le personnel de l'ICANN a publié et recueilli des commentaires sur le plan de travail préliminaire des révisions du programme des nouveaux gTLD.⁴ Le groupe de discussion de la GNSO sur les procédures suivantes des nouveaux gTLD a joué un rôle très important dans la discussion des incidences sur les politiques et le développement du programme des nouveaux gTLD. Tandis que la GNSO n'a pas été formellement consultée, un thème récurrent dans les discussions du groupe est centré sur les processus futurs qui devraient être considérés pour déterminer le développement de la prochaine série. En outre, les parties prenantes de la communauté telles que les parties contractantes, les nouveaux opérateurs de registre, les FSI et les opérateurs IP, ainsi que les membres de la communauté d'utilisateurs finaux ont contribué leurs points de vue sur le calendrier de la prochaine série.
  
  Quels sont les documents importants examinés par le Conseil ?
  
  Le Conseil a examiné la version préliminaire du plan de travail, l'Affirmation d'engagements (AoC), l'échéancier estimatif pour l'achèvement de la révision en fonction des estimations initiales des activités décrites dans le plan de travail, le rapport thématique préliminaire de la GNSO du 31 août 2015 ainsi que les discussions de la GNSO sur lesquelles celui-ci se fondait, les résolutions 2012.02.07.05 et 2014.11.17.10 à 2014.11.17.12 au sujet des engagements d'ouvrir une deuxième série dans les meilleurs délais possibles et en consultation avec les parties prenantes pertinentes et la révision des mécanismes de protection des droits concernant les sauvegardes mises en place pour atténuer les problèmes potentiels du programme des nouveaux gTLD.
  - Plan de travail : https://www.icann.org/news/announcement-3-2014-09-22-en
  - AoC : https://www.icann.org/resources/pages/affirmation-of-commitments-2009-09-30-en
  - Révision du calendrier d'achèvement : http://newgtlds.icann.org/en/reviews
  - Rapport thématique préliminaire de la GNSO du 31 août 2015 :http://gnso.icann.org/en/node/48007
  - Résolution 2012.02.07.05 : https://www.icann.org/resources/board-material/resolutions-2012-02-07-en
  - Résolutions 2014.11.17.10 à 2014.11.17.12:https://www.icann.org/resources/board-material/resolutions-2014-11-17-en#2.b
  - Révision des mécanismes de protection des droits : https://www.icann.org/public-comments/rpm-review-2015-02-02-en
  Quels sont les facteurs que le Conseil a trouvés significatifs ?
  
  Étant donné que les résultats du processus de révision sont inconnus et qu'un PDP pourrait être initié, il est irréaliste à ce stade d'établir un calendrier pour le lancement d'une série supplémentaire du programme des nouveaux gTLD. Le Conseil d'administration croit comprendre qu'une grande partie de la communauté des parties prenantes souhaite davantage de certitude, mais considère qu'il est prioritaire à ce stade de procéder à des révisions approfondies de la série actuelle. Le Conseil reprendra les discussions des calendriers et des processus pour les prochaines séries à un stade ultérieur.
  
  Y a-t-il des effets positifs ou négatifs pour la communauté ?
  
  Certains dans la communauté seront probablement frustrés par le manque d'engagement avec une procédure ou un calendrier définitif. Cependant, à travers ses mesures, le Conseil d'administration tente de faire en sorte qu'une importance suffisante soit accordée au processus de révision afin d'évaluer pleinement les résultats de la première série du programme des nouveaux gTLD. Cela peut être considéré par certaines unités constitutives comme un manque de réponse aux questions concernant comment les divers examens et processus actuellement en cours devraient mener au lancement d'une deuxième série. Toutefois, cette approche permet de maintenir le dialogue avec la communauté au sujet des zones critiques à traiter dans la création de cet ensemble de mesures. Le lancement trop précoce d'une deuxième série sans avoir le temps suffisant pour la révision pourrait empêcher la communauté d'examiner adéquatement les leçons tirées de la première série pour en tenir compte au moment de développer la prochaine série. En outre, s'engager avec un calendrier ou un processus prévu pourrait créer des attentes irréalistes de la part des communautés de parties prenantes quant à quand une deuxième série pourrait avoir lieu.
  
  Y a-t-il des répercussions financières sur l'ICANN (plan stratégique, plan opérationnel, budget), sur la communauté et/ou sur le grand public ?
  
  Certaines révisions du programme nécessitent l'expertise de spécialistes. Des fonds ont été alloués à ces activités dans le budget de l'exercice fiscal 2016. Cependant, aucune incidence supplémentaire sur le budget qui ne soit pas déjà prévue et/ou affectée n'est à prévoir comme résultat de cette résolution.
  
  Existe-t-il des problèmes de sécurité, stabilité et résilience liés au DNS ?
  
  Il n'y a pas de répercussions immédiates pour la sécurité, la stabilité et la résilience du DNS qui résultent de cette résolution, mais il est à noter que la sécurité, la stabilité et la résilience du DNS est parmi les domaines d'étude proposés.
  
  S'agit-il d'un processus d'élaboration 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 ?
  
  Ce n'est pas un processus politique défini, puisque les résultats de la première série du programme des nouveaux gTLD doivent encore être évalués et un processus politique déterminé doit être établi. Il est probable, cependant, que les révisions et le PDP soient soumis à consultation publique une fois terminés.
5. Exigences en matière d'assurance pour le contrat d'accréditation de bureaux d'enregistrement
  
  Mike Silber, co-président du Comité des risques, a présenté le point de l'ordre du jour. La politique d'accréditation de bureaux d'enregistrement exige que les bureaux d'enregistrement maintiennent des polices d'assurance de responsabilité civile professionnelle d'au moins 500 000 USD, ou un montant inférieur si le bureau d'enregistrement peut démontrer qu'une limite inférieure fournirait une compensation raisonnable en cas de perte. Les contrats d'accréditation de bureaux d'enregistrement (RAA) exigent que les bureaux d'enregistrement maintiennent une couverture de 500 000 USD. L'ICANN a reçu des commentaires disant que les exigences de polices d'assurance de responsabilité civile professionnelle des RAA ne respectent pas le but de la déclaration de la politique d'accréditation des bureaux d'enregistrement d'exiger une police d'assurance de responsabilité civile professionnelle, qui visait à fournir une réparation aux titulaires de noms en cas d'actions malveillantes d'un bureau d'enregistrement. En outre, cette couverture d'assurance n'a pas été utilisée à ce jour. Le Conseil a également discuté du fait que cette exigence d'assurance constitue un obstacle pour le développement du marché de bureaux d'enregistrement dans les pays en développement. D'après cette information, le Conseil a discuté de l'application d'une dérogation de l'obligation d'assurance de responsabilité civile professionnelle.
  
  Mike a proposé, Gonzalo Navarro l'a appuyé et le Conseil a pris la mesure suivante :
  
  Attendu que la déclaration de la politique d'accréditation des bureaux d'enregistrement (« politique d'accréditation »), adoptée en 1999, exige que les bureaux d'enregistrement aient et maintiennent des polices d'assurance de responsabilité civile professionnelle d'au moins 500 000 USD, ou un montant inférieur si le bureau d'enregistrement peut démontrer qu'une limite inférieure fournirait une compensation raisonnable en cas de perte.
  
  Attendu que les contrats d'accréditation de bureau d'enregistrement 2013 et 2009 (« RAA ») exigent aux bureaux d'enregistrement de maintenir une couverture de 500 000 USD (sans faire référence aux limites potentiellement plus réduites de la politique d'accréditation).
  
  Attendu que l'ICANN a reçu des commentaires disant que les exigences de polices d'assurance de responsabilité civile professionnelle des RAA ne respectent pas le but de la déclaration de la politique d'accréditation des bureaux d'enregistrement d'exiger une police d'assurance de responsabilité civile professionnelle, qui visait à fournir une réparation aux titulaires de noms en cas d'actions malveillantes d'un bureau d'enregistrement et qu'elles constituent un obstacle pour le développement du marché des bureaux d'enregistrement dans les pays en développement.
  
  Attendu que l'ICANN a demandé des commentaires publics à ce sujet en mai 2014 et en janvier 2015.
  
  Il est résolu (2015.09.28.14) que l'exigence d'assurance de responsabilité civile professionnelle des RAA 2009 et 2013 soit dérogée et il est indiqué au Président-directeur général ou à ses représentants autorisés de prendre les mesures nécessaires pour mettre en œuvre cette résolution.
  
  Il est résolu (2015.09.28.15) que la GNSO soit priée d'examiner si des travaux de politique pour remplacer les exigences d'assurance devraient être entrepris à la lumière de la déclaration de la politique d'accréditation de bureaux d'enregistrement.
  
  Tous les membres du Conseil d'administration présents ont voté en faveur des résolutions 2015.09.28.14 et 2015.09.28.15. Erika Mann n'était pas disponible pour voter sur ces résolutions. Les résolutions ont été adoptées.
  
  Fondements des résolutions 2015.09.28.14 et 2015.09.28.15
  
  Pourquoi le Conseil aborde cette question maintenant ?
  
  Les contrats d'accréditation de bureaux d'enregistrement de 2009 et 2013 exigent aux bureaux d'accréditation d'engager des polices d'assurance de responsabilité civile professionnelle avec une limite d'au moins 500 000 USD. Cette exigence est fondée sur le texte de la déclaration de la politique d'accréditation de bureaux d'enregistrement, qui exige que les bureaux d'enregistrement aient et maintiennent des polices d'assurance de responsabilité civile professionnelle d'au moins 500 000 USD, ou un montant inférieur si le bureau d'enregistrement peut démontrer qu'une limite inférieure fournirait une compensation raisonnable en cas de perte. L'exigence du RAA n'inclut pas la souplesse de la déclaration de la politique d'accréditation de permettre des limites de police inférieures.
  
  Les polices d'assurance de responsabilité civile professionnelle protègent normalement les entreprises contre les réclamations ayant trait à la responsabilité pour blessures corporelles et aux dommages matériels qui se produisent dans leurs locaux, ainsi qu'à la responsabilité pour la publicité ou en cas de blessure personnelle. Toutefois, la plupart des polices de responsabilité civile professionnelle excluent l'assurance pour les erreurs et omissions du bureau d'enregistrement. Autrement dit, les détenteurs de noms de domaine en général ne seraient pas en mesure de recevoir une compensation auprès d'une compagnie d'assurance (en vertu d'une police de responsabilité civile professionnelle) pour les actes de négligence réalisés par le bureau d'enregistrement, tels que la suppression accidentelle ou le non renouvellement d'un enregistrement, ou bien le détournement d'un nom de domaine.
  
  Cette exigence d'assurance pose des défis financiers et pratiques pour certaines entités qui visent à devenir un bureau d'enregistrement accrédité par l'ICANN. Les commentaires de la communauté suggèrent que cette exigence nuit de manière disproportionnée les bureaux d'enregistrement et les bureaux d'enregistrement potentiels des régions où ce type d'assurance est indûment coûteux ou inexistant.
  
  Ainsi, en ce moment le Conseil d'administration prend des mesures pour approuver la dérogation de l'exigence d'une assurance de responsabilité civile professionnelle des RAA 2009 et 2013, parce que l'exigence d'assurance de responsabilité civile professionnelle ne semble pas atteindre son objectif de politique prévu et constitue une charge indue aux bureaux d'enregistrement potentiels. Malgré la consultation publique considérable, il n'y a aucune preuve que l'exigence de l'assurance de responsabilité civile professionnelle ait été avantageuse pour les titulaires de noms de domaine.
  
  Quelles parties intéressées ou autres entités ont été consultées ?
  
  L'ICANN a reçu des commentaires de bureaux d'enregistrement potentiels que l'assurance requise dans leur région est difficile, voire impossible d'obtenir. L'ICANN a organisé un atelier pour discuter de cela et d'autres sujets liés aux régions mal desservies lors de la réunion de l'ICANN à Singapour en 2014. L'ICANN a consulté un conseiller d'assurance externe, ainsi que de nombreux bureaux d'enregistrement actuels et potentiels. L'ICANN a demandé des commentaires publics à ce sujet en mai 2014 et en janvier 2015. Dans le cadre des mesures du Conseil d'administration, le Conseil encourage la GNSO à examiner cette question.
  
  Quelles sont les préoccupations ou les questions soulevées par la communauté ?
  
  Les membres de la communauté ont manifesté à l'ICANN que l'exigence d'assurance existante peut être difficile ou impossible de satisfaire dans de nombreuses juridictions, notamment celles qui n'appartiennent ni à l'Amérique du Nord ni à l'Europe. Certaines personnes ont mentionné que l'assurance CGL n'existe pas du tout dans certains pays et, bien que disponible dans d'autres, la limite de 500 000 USD pourrait être excessive (et en conséquence commercialement irréalisable), par rapport aux conditions du marché, le coût de la vie et les risques de faire des affaires dans la région. En outre, certains commentateurs ont demandé si l'exigence est toujours nécessaire compte tenu des améliorations institutionnelles de l'ICANN dans d'autres domaines, tels que l'application de la conformité et le dépôt de données. Certains membres de la communauté ont suggéré que l'ICANN pourrait fournir aux nouveaux bureaux d'enregistrement et à ceux existants une liste d'assureurs qui soient connus pour servir les bureaux d'enregistrements existants afin que tous les bureaux d'enregistrement puissent accéder à l'assurance nécessaire afin d'obtenir l'accréditation de l'ICANN.
  
  Cependant, d'autres membres de la communauté ont averti que les titulaires de noms pourraient être laissés sans protection si l'exigence d'assurance de responsabilité civile professionnelle était dérogée.
  
  Quels documents le Conseil a-t-il étudié pour prendre cette décision ?
  
  Pour prendre cette décision, le Conseil a examiné deux rapports de commentaires publics sur cette question, publiés le 2 septembre 2014 et le 3 avril 2015 ainsi que des documents de référence du Conseil. Le Conseil a également examiné la Déclaration de la politique d'accréditation des bureaux d'enregistrement , ainsi que les contrats d'accréditation de bureaux d'enregistrement de 2009 et 2013.
  
  Quels sont les facteurs que le Conseil a trouvés significatifs pour prendre cette décision ?
  
  L'exigence d'assurance existante ne sert pas son but original de protéger les titulaires de noms des actes fautifs des bureaux d'enregistrement. En outre, l'exigence empêche la concurrence dans les régions du monde mal desservies. Étant donné que l'exigence d'assurance originale était une question de politique de l'ICANN, la GNSO est l'organe compétent pour décider s'il serait approprié de créer une exigence de remplacement.
  
  Quelles sont les incidences financières de cette décision ?
  
  Cette décision n'a aucune incidence financière sur l'ICANN. L'élimination de l'exigence pourrait réduire les coûts pour les bureaux d'enregistrement et les bureaux d'enregistrement potentiels qui choisissent de ne pas maintenir une police d'assurance de responsabilité civile professionnelle.
  
  Quels sont les impacts de cette décision sur la communauté ?
  
  D'après les informations reçues à ce jour, il semblerait qu'il n'y aura aucun impact négatif sur les titulaires de noms, les autres parties prenantes ou l'intérêt public mondial si le Conseil approuvait la dérogation de l'exigence d'assurance.
  
  Cette décision aura un impact positif sur les bureaux d'enregistrement actuels et potentiels, en particulier dans les régions où l'assurance de responsabilité civile professionnelle est indûment onéreuse ou impossible d'obtenir. L'impact est susceptible d'être essentiellement financier, mais peut aussi encourager la présentation de nouvelles candidatures pour l'accréditation de bureaux d'enregistrement de pays développés et en développement.
  
  L'approbation par le Conseil d'une dérogation de l'exigence d'assurance approfondira les efforts de l'ICANN visant à promouvoir la concurrence des bureaux d'enregistrement dans un environnement mondialisé et donnera à la GNSO l'occasion d'examiner s'il serait approprié de créer une exigence d'assurance de remplacement.
  
  Quels sont les impacts sur la sécurité et la stabilité de l'Internet ?
  
  L'approbation de la résolution n'aura pas d'impact sur la sécurité, la stabilité ou la résilience du DNS.
6. Recommandations de politique et de mise en œuvre de la GNSO
  
  Bruce Tonkin a présenté le point de l'ordre du jour. Le Conseil a reçu une série de recommandations dans le rapport final de recommandations du groupe de travail de la GNSO sur les politiques non-PDP et la mise en œuvre qui proposaient des modifications aux statuts constitutifs pour aborder de nouveaux seuils de vote de la GNSO résultant du processus d'orientation de la GNSO (GGP) et du processus accéléré d'élaboration de politiques de la GNSO (EPDP). Les amendements proposés aux statuts constitutifs ont été publiés pour consultation publique, et deux commentaires ont été reçus pendant la période de consultation publique. Le Conseil demande maintenant d'adopter les recommandations de la GNSO concernant la politique et la mise en œuvre en approuvant les amendements des statuts constitutifs qui ont été publiés pour commentaires publics. Le Conseil approuve également les principes proposés de politique et de mise en œuvre de la GNSO et les lignes directrices pour orienter le personnel ainsi que le travail de la communauté lié aux politiques et à la mise en œuvre de la GNSO. Le Conseil a également accepté le conseil fourni par l'ALAC et s'est engagé à surveiller attentivement les activités d'élaboration de politiques de la GNSO pour s'assurer que les intérêts de l'utilisateur et les intérêts publics sont dûment considérés.
  
  Bruce a proposé, le président l'a appuyé et le Conseil a pris la mesure suivante :
  Attendu que le 17 juillet 2013 le conseil de la GNSO a approuvé la charte pour un groupe de travail de la GNSO sur les politiques non-PDP et la mise en œuvre (http://gnso.icann.org/en/council/resolutions#201307) chargé de fournir au conseil de la GNSO une série de recommandations sur :
  - Un ensemble de principes visant à étayer les discussions relatives aux politiques de la GNSO et leur mise en œuvre et tenant compte des procédures opérationnelles existantes de la GNSO.
  - Un processus pour l'élaboration de politiques de la GNSO, peut se produire sous forme d'« orientations politiques », y compris entre autres les critères permettant d'établir quand il serait approprié d'utiliser un tel processus (pour élaborer des politiques autres que les « politiques de consensus ») au lieu du processus d'élaboration de politiques de la GNSO.
  - Un cadre pour les discussions liées à la mise en œuvre des recommandations de la GNSO en matière de politique.
  - Les critères servant à déterminer à quel moment une action doit être abordée par le biais d'un processus de politique et à quel moment elle doit être considérée comme une mise en œuvre.
  - Des instructions sur la manière dont les équipes de révision de la mise en œuvre de la GNSO, telles que définies dans le manuel du PDP, devraient fonctionner et opérer.
  Attendu que le groupe de travail de la GNSO sur la politique et la mise en œuvre a publié son rapport initial de recommandations pour consultation publique le 19 janvier 2015 (voirhttps://www.icann.org/public-comments/policy-implementation-2015-01-19-en).
  
  Attendu que le groupe de travail de la GNSO sur la politique et la mise en œuvre a examiné les commentaires reçus (voir l'outil de révision des consultations publiques) et mis à jour le rapport en conséquence pour créer un rapport de recommandations finales, qui a été soumis au conseil de la GNSO le 2 juin 2015.
  
  Attendu que le rapport final de recommandations (voir http://gnso.icann.org/en/drafts/policy-implementation-recommendations-01jun15-en.pdf) a été adopté à l'unanimité par le conseil de la GNSO le 24 juin 2015.
  
  Attendu que le 28 juillet 2015 le Conseil de l'ICANN a indiqué au personnel de l'ICANN de valider les modifications proposées aux statuts de l'ICANN à la suite des recommandations proposées dans le rapport final des recommandations pour consultation publique (voir https://www.icann.org/public-comments/bylaws-amendments-2015-07-31-en).
  
  Attendu que deux commentaires ont été reçus à l'appui des recommandations proposées, y compris une déclaration de l'avis de l'ALAC.
  
  Attendu que l'ATRT2 a recommandé que « le Conseil devrait continuer de soutenir l'engagement intercommunautaire visant à développer une compréhension de la distinction entre l'élaboration de politiques et la mise en œuvre de la politique. Élaborer des mécanismes complémentaires qui permettent aux organisations de soutien et aux comités consultatifs (SO / AC) de consulter le Conseil sur différentes questions, y compris sans s'y limiter la politique, la mise en œuvre et des questions administratives, sur lesquelles le Conseil d'administration prend des décisions » (recommandation 4).
  
  Il est résolu (2015.09.28.16) que le Conseil approuve les amendements apportés aux articles 3-9, chapitre X des statuts constitutifs de l'ICANN, tels que publiés pour consultation publique sur le nouveau seuil de vote de la GNSO résultant du processus d'orientation de la GNSO (GGP) et du processus accéléré d'élaboration de politiques de la GNSO (EPDP).
  
  Il est résolu (2015.09.28.17) que le Conseil approuve les modifications apportées à l'annexe A de statuts constitutifs de l'ICANN publié pour consultation publique (voir https://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf), qui crée une nouvelle annexe A-1 qui énonce l'EPDP de la GNSO.
  
  Il est résolu (2015.09.28.18) que le Conseil approuve les modifications apportées à l'annexe A de statuts constitutifs de l'ICANN publié pour consultation publique (voir https://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf), qui crée une nouvelle annexe A-2 qui énonce le GGP de la GNSO.
  
  Il est résolu (2015.09.28.19) que le Conseil approuve l'ensemble de principes / exigences de la GNSO qui ont trait aux politiques et à la mise en œuvre énoncés dans la section 4 du rapport final des recommandations et indique au Président-directeur général, ou à ses représentants autorisés, ainsi qu'à la communauté de l'ICANN, de tenir compte de ces principes et exigences lorsqu'ils participent aux questions liées à la politique et à la mise en œuvre de la GNSO.
  
  Il est résolu (2015.09.28.20) que le Conseil approuve les orientations et principes de l'équipe de révision de la mise en œuvre tels qu'énoncés dans l'annexe L du rapport final des recommandations et indique au personnel de l'ICANN ainsi qu'à la communauté de l'ICANN de tenir compte de ces orientations et principes lorsqu'ils participent aux questions liées à la mise en œuvre.
  
  Il est résolu (2015.09.28.21) que le Conseil d'administration accepte les conseils de l'ALAC et s'engage à surveiller attentivement les activités d'élaboration de politiques de la GNSO pour s'assurer que les intérêts des utilisateurs et les intérêts publics sont dûment considérés et que la mise en œuvre d'une politique complexe peut être accomplie dans des délais raisonnables.
  
  Il est résolu (2015.09.28.22) que le Conseil indique au Président-directeur général, ou à son représentant autorisé, de valider les documents pertinents sur la politique et la mise en œuvre de la GNSO par rapport aux pages liées du site de la GNSO et de l'ICANN et de demander et incorporer des commentaires sur les améliorations et d'autres documents de soutien le cas échéant.
  
  Il est résolu (2015.09.28.23) que le Conseil considère que la recommandation 4 de l'ATRT2 est ainsi complétée par les présentes et invite l'ATRT3 à examiner ces recommandations adoptées à la lumière des constats et des recommandations de l'ATRT2.
  
  Il est résolu (2015.09.28.24) que le Conseil remercie la communauté de la GNSO et les autres personnes impliquées de leur travail acharné sur cet effort.
  Quatorze membres du Conseil d'administration ont voté en faveur des résolutions 2015.09.28.16, 2015.09.28.17, 2015.09.28.18, 2015.09.28.19, 2015.09.28.20, 2015.09.28.21, 2015.09.28.22, 2015.09.28.23, et 2015.09.28.24. Ray Plzak s'est abstenu de voter. Erika Mann n'était pas disponible pour voter sur ces résolutions. Les résolutions ont été adoptées.
  Fondements des résolutions 2015.09.28.16 à 2015.09.28.24
  
  Pourquoi le Conseil aborde-t-il cette question maintenant ?
  
  Suite notamment aux discussions qui ont vu le jour à partir d'un certain nombre de problèmes liés à la mise en œuvre du programme des nouveaux noms de domaine génériques de premier niveau (gTLD), l'accent a été de plus en plus mis sur la question de savoir quels sont les dossiers relevant de la politique et quels sont ceux relevant de la mise en œuvre. Le débat a également porté sur les procédures à appliquer ainsi que sur le moment et la manière dont les questions faisant l'objet d'opinions différentes au cours du processus de mise en œuvre doivent être traitées. À la suite de plusieurs discussions, dont celles faisant l'objet de la publication par le personnel de l'ICANN d'un document de discussion et d'une séance avec la communauté lors de la 46e réunion publique de l'ICANN, le Conseil de l'Organisation de soutien aux extensions génériques (GNSO) a décidé en juillet 2013 de créer un groupe de travail chargé d'élaborer une série de recommandations sur :
  - un ensemble de principes pour étayer les discussions futures liées à la politique et à la mise en œuvre de la GNSO, compte tenu des procédures opérationnelles existantes de la GNSO.
  - un processus pour l'élaboration de politiques de la GNSO, peut se produire sous forme d'« orientations politiques », y compris entre autres les critères permettant d'établir quand il serait approprié d'utiliser un tel processus (pour élaborer des politiques autres que les « politiques de consensus ») au lieu du processus d'élaboration de politiques de la GNSO ;
  - un cadre pour les discussions liées à la mise en œuvre des recommandations de la GNSO en matière de politique ;
  - Les critères servant à déterminer à quel moment une action doit être abordée par le biais d'un processus de politique et à quel moment elle doit être considérée comme une mise en œuvre, et ;
  - des instructions sur la manière dont les équipes de révision de la mise en œuvre de la GNSO, telles que définies dans le manuel du PDP, devraient fonctionner et opérer.
  Les recommandations du groupe de travail ont été adoptées à l'unanimité par le conseil de la GNSO le 24 juin 2015 et par la suite soumises au Conseil de l'ICANN pour leur examen.
  
  En outre, ce problème a été également identifié comme étant prioritaire par la deuxième Équipe de révision de la responsabilité et de la transparence (ATRT2) : « le Conseil devrait continuer de soutenir l'engagement intercommunautaire visant à développer une compréhension de la distinction entre l'élaboration de politiques et la mise en œuvre de la politique. Élaborer des mécanismes complémentaires qui permettent aux organisations de soutien et aux comités consultatifs (SO / AC) de consulter le Conseil sur différentes questions, y compris sans s'y limiter la politique, la mise en œuvre et des questions administratives, sur lesquelles le Conseil d'administration prend des décisions » (recommandation 4).
  
  Quelle est la proposition à l'étude ?
  
  La mesure prise par le Conseil d'administration aujourd'hui est d'adopter les recommandations de la GNSO concernant la politique et la mise en œuvre. Les recommandations adoptées incluent, entre autres, trois nouveaux processus pour la GNSO, dont deux - le processus d'orientation de la GNSO (GGP) et le processus accéléré d'élaboration de politiques de la GNSO (EPDP) - nécessitent l'introduction de modifications dans les statuts de l'ICANN. La mesure du Conseil d'administration est d'approuver les modifications nécessaires aux statuts constitutifs afin de mettre en œuvre le processus d'orientation de la GNSO et le processus accéléré d'élaboration de politiques de la GNSO. Ces nouveaux processus visent à fournir au conseil de la GNSO plus de flexibilité pour traiter les questions de politique à travers des processus formels qui seraient utilisés si certains critères spécifiques sont remplis. Le Conseil prend également des mesures pour approuver les principes proposés de politique et de mise en œuvre de la GNSO et les lignes directrices pour orienter davantage le travail du personnel ainsi que de la communauté lié aux politiques et à la mise en œuvre de la GNSO.
  
  Quelles parties intéressées ou autres entités ont été consultées ?
  
  Suite à plusieurs discussions, y compris la publication d'un document de travail du personnel (voirhttps://gnso.icann.org/en/correspondence/policy-implementation-framework-08jan13-en.pdf et http://forum.icann.org/lists/comments-policy-implementation-31jan13/) et une séance de la communauté lors de la 46e réunion publique de l'ICANN (voirhttp://beijing46.icann.org/node/37133) le conseil de l'Organisation de soutien aux noms génériques (GNSO) a décidé en juillet 2013, en consultation avec les autre SO / AC (voirhttp://gnso.icann.org/en/correspondence/robinson-to-so-ac-leadership-23apr13-en.pdf), de former un groupe de travail de la GNSO pour aborder un certain nombre de questions précises qui se rapportent à la politique et à la mise en œuvre de la GNSO. Le groupe de travail de la GNSO a demandé les contributions initiales de tous les SO / AC de l'ICANN et des groupes de parties prenantes et unités constitutives de la GNSO à un stade précoce (voir https://community.icann.org/x/iSmfAg). La publication du rapport initial était accompagnée d'un forum de commentaires publics (voir https://www.icann.org/public-comments/policy-implementation-2015-01-19-en) ainsi que d'une séance communautaire au cours de la 52e réunion publique de l'ICANN (voir https://singapore52.icann.org/en/schedule/wed-policy-implementation). Le groupe de travail a examiné et adressé tous les commentaires reçus, tel que démontré dans l'outil de révision des consultations publiques (voir https://community.icann.org/x/iSmfAg). Suite à l'adoption unanime par le conseil de la GNSO du rapport final des recommandations, le Conseil de l'ICANN a indiqué au personnel de l'ICANN de publier les changements proposés aux statuts de l'ICANN pour consultation publique (voir https://www.icann.org/public-comments/bylaws-amendments-2015-07-31-en). Deux commentaires, y compris une déclaration de l'avis de l'ALAC, ont été reçus à l'appui des recommandations (voir http://forum.icann.org/lists/comments-bylaws-amendments-31jul15/).
  
  Quelles sont les préoccupations ou les questions soulevées par la communauté ?
  
  Le groupe de travail a examiné et adressée tous les commentaires reçus, tel que démontré dans l'outil de révision des consultations publiques (voir https://community.icann.org/x/iSmfAg). L'ALAC, dans sa déclaration d'avis en réponse au forum de commentaires publics lancé par le Conseil de l'ICANN, a appuyé les recommandations mais a également recommandé que le Conseil de l'ICANN surveille attentivement les activités d'élaboration de politiques de la GNSO pour garantir que les intérêts des utilisateurs et les intérêts publics soient dûment examinés et que la mise en œuvre de politiques complexes puisse être accomplie dans des délais raisonnables.
  
  Quels sont les documents importants examinés par le Conseil ?
  
  Le Conseil d'administration a examiné le rapport final de recommandations de politique et de mise en œuvre de la GNSO (voir http://gnso.icann.org/en/drafts/policy-implementation-recommendations-01jun15-en.pdf) et des documents connexes.
  
  Quels sont les facteurs que le Conseil a trouvés significatifs ? Y a-t-il des effets positifs ou négatifs pour la communauté ?
  
  Le Conseil d'administration considère d'une importance considérable le fait que ces recommandations aient été élaborées par la communauté, en consultation avec le personnel de l'ICANN et que ces recommandations aient reçu l'appui unanime du conseil de la GNSO. En outre, le Conseil reconnaît l'importance d'aborder cette question, tel que souligné par l'ATRT2 et est d'avis que ces recommandations fourniront au conseil de la GNSO plus de flexibilité pour traiter les questions de politique par le biais de processus formels. De même, ces recommandations apporteront la clarté et la prévisibilité nécessaires en ce qui concerne les questions liées à la politique et à la mise en œuvre de la GNSO.
  
  Y a-t-il des impacts financiers ou des répercussions à prévoir sur l'ICANN (plan stratégique, plan opérationnel, budget), la communauté ou le public ?
  
  Aucune incidence fiscale ni ramification n'est à prévoir suite à la mise en œuvre de ces recommandations.
  
  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 relatif au DNS n'a été identifié pour ces recommandations.
7. Désignation du président et du président élu du Comité de nomination 2016 – RÉUNION EXÉCUTIVE
  
  Le Conseil est entré en séance à huis clos. Le Conseil a entrepris les actions suivantes lors de sa séance à huis clos :
  
  Attendu que le BGC a examiné les Manifestations d'intérêt des candidats pour les postes de président et de président élu du Comité de nomination 2016 (« NomCom »), a examiné les résultats de l'évaluation 360 degrés des dirigeants du NomCom 2015 et a mené des entretiens avec les candidats.
  
  Attendu que le BGC a recommandé que Stéphane Van Gelder soit désigné pour le poste de président du NomCom 2016, et Hans Petter Holen soit nommé pour le poste de président-élu du NomCom 2016.
  
  Il est résolu (2015.09.28.25) que le Conseil d'administration nomme par les présentes Stéphane Van Gelder président du Comité de nomination 2016 et Hans Petter Holen le président élu du Comité de nomination 2016.
  
  Fondements de la résolution 2015.09.28.25
  
  Les statuts constitutifs de l'ICANN exigent que le Conseil nomme le président du Comité de nomination (NomCom) et le président élu du NomCom. Voir chapitre VII, articles 2.1 et 2.2 à http://www.icann.org/en/general/bylaws.htm - VII. Le Conseil a délégué la responsabilité de recommander des candidats au poste de président et de président élu du NomCom pour leur approbation par le Conseil au comité de gouvernance du Conseil. Voir la charte du BGC à http://www.icann.org/en/committees/board-governance/charter.htm. Le BGC a publié un appel à Manifestations d'intérêt (EOI) le 4 juin 2015 demandant les EOI avant le 30 juin 2015 (voir https://www.icann.org/news/announcement-2-2015-06-04-en). L'appel à Manifestations d'intérêt a ensuite été prolongé jusqu'au 20 juillet 2015 (voir https://www.icann.org/news/announcement-2015-07-01-en). Le BGC a reçu et examiné plusieurs EOI, a supervisé une évaluation de 360 degrés des dirigeants du NomCom 2015 et a mené des entretiens avec les candidats avant de formuler ses recommandations. Le Conseil a examiné et est d'accord avec la recommandation du BGC pour les postes de président et de président élu du NomCom 2016. Le Conseil tient à remercier tous ceux qui ont manifesté leur intérêt à faire partie de l'équipe de dirigeants du NomCom 2016.
  
  La désignation du président et du président élu du NomCom, déterminée au travers d'un processus public d'EOI, a un effet positif sur la transparence et la reddition de comptes de l'ICANN, et soutient l'intérêt public. L'adoption de la recommandation du BGC n'a aucun impact financier sur l'ICANN qui n'ait pas été prévu et n'aura pas d'impact négatif sur la sécurité systémique, la stabilité et la résilience du système des noms de domaine.

¹ La définition des niveaux de consensus est disponible sur http://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-07apr11-en.pdf (p.8).

² Voir aussi la section 5.1.1 et l'outil de révision des consultations publiques (dans l'annexe B [du rapport Final])

³ Beaucoup de personnes supposent que ce sera l'ASCII américain, mais les arguments pour les autres scripts pourraient être convaincants.

⁴ Voir https://www.icann.org/news/announcement-3-2014-09-22-en

ICANN

Get Started

News and Media

Policy

Public Comment

Resources

Community

Quicklinks

Procès-verbal | Réunion ordinaire du Conseil d’administration de l’ICANN 28 septembre 2015

Ordre du jour approuvé :

Approbation des procès-verbaux du Conseil d'administration

Recommandations du conseil de la GNSO sur la traduction et la translittération de l'information de contact

Fondements des résolutions 2015.09.28.02 et 2015.09.28.03

Renouvellement du contrat de registre .CAT

Fondements de la résolution 2015.09.28.04

Renouvellement du contrat de registre .TRAVEL

Fondements de la résolution 2015.09.28.05

Renouvellement du contrat de registre .PRO

Fondements de la résolution 2015.09.28.06

Ordre du jour principal :

Conclusion du contrat pour le lieu de la réunion de l'ICANN de juin 2016

Fondements des résolutions 2015.09.28.07 et 2015.09.28.08

Contrats et déboursements pour la nouvelle Initiative ERP

Fondements des résolutions 2015.09.28.09 et 2015.09.28.10

Libération des fonds de réserve - Frais de transition de la supervision de l'IANA des mains du Gouvernement des États-Unis

Fondements de la résolution 2015.09.28.11

Programme des nouveaux gTLD : parcours vers les prochaines séries

Fondements des résolutions 2015.09.28.12 et 2015.09.28.13

Exigences en matière d'assurance pour le contrat d'accréditation de bureaux d'enregistrement

Fondements des résolutions 2015.09.28.14 et 2015.09.28.15

Recommandations de politique et de mise en œuvre de la GNSO

Fondements des résolutions 2015.09.28.16 à 2015.09.28.24

Désignation du président et du président élu du Comité de nomination 2016 – RÉUNION EXÉCUTIVE

Fondements de la résolution 2015.09.28.25