STATUTS DE L’ ICANN | Tel qu’amendé à la date effective du 15 février 2008
Note: this page is an archive of an old version of the bylaws. The current ICANN bylaws are always available at: https://www.icann.org/resources/pages/governance/bylaws-en
Société de droit californien à but non-lucratif
Tel qu’amendé à la date effective du 15 février 2008
| Remarque sur les documents traduits La version originale, en anglais, du présent document est disponible à l’adresse suivante : http://www.icann.org/en/general/bylaws.htm. En cas de différence d’interprétation entre une version non anglaise de ce document et le texte original, ce dernier prévaut. |
ARTICLE I : MISSION ET PRINCIPALES VALEURS
ARTICLE II : POUVOIRS
ARTICLE III : TRANSPARENCE
ARTICLE IV : RESPONSABILITE ET RÉVISION
ARTICLE V : MÉDIATEUR
ARTICLE VI : CONSEIL D'ADMINISTRATION
ARTICLE VII : COMITÉ DE NOMINATION
ARTICLE VIII : ORGANISME DE SOUTIEN DES ADRESSES
ARTICLE IX : ORGANISME DE SUPPORT DES NOMS GÉOGRAPHIQUES
ARTICLE X : ORGANISME DE SOUTIEN DES NOMS GENERIQUES
ARTICLE XI : COMITÉS CONSULTATIFS
ARTICLE XI-A : AUTRES MÉCANISMES CONSULTATIFS
ARTICLE XII : CONSEIL D’ADMINISTRATION ET COMITÉS PROVISOIRES
ARTICLE XIII : MEMBRES DU BUREAU
ARTICLE XIV : INDEMNISATION DES ADMINISTRATEURS, MEMBRES DU BUREAU, SALARIÉS ET AUTRES AGENTS
ARTICLE XV : CLAUSES GÉNÉRALES
ARTICLE XVI : FISCALITÉ
ARTICLE XVII : MEMBRES
ARTICLE XVIII : LOCAUX ET CACHET
ARTICLE XIX : AMENDEMENTS
ARTICLE XX : ARTICLE DE TRANSITION
ANNEXE A : PROCESSUS D’ÉLABORATION DES POLITIQUES DU GNSO
ANNEXE B : PROCESSUS D’ÉLABORATION DES POLITIQUES DE LA ccNSO (ccPDP)
ANNEXE C : DOMAINE DE COMPETENCE DE LA ccNSO
ARTICLE I : MISSION ET PRINCIPALES VALEURS
La mission de l’ICANN ( Société pour l’attribution des noms de domaines et des numéros sur Internet) est de coordonner, à un niveau général, les systèmes mondiaux d’identificateurs uniques d’Internet et d’en assurer en particulier la stabilité et la sécurité d’exploitation. En particulier, l’ICANN :
1. Coordonne l’allocation et l’attribution des trois ensembles d’identificateurs uniques pour Internet, à savoir :
a. Les noms de domaine (formant un système appelé « DNS ») ;
b. Les adresses de protocole Internet (« IP ») ainsi que les numéros de systèmes autonomes (« AS ») ; et
2. Coordonne l’exploitation et l’évolution du système des serveurs de noms racines du DNS.
3. Coordonne le développement des politiques associées de façon raisonnable et pertinente à ces fonctions techniques.
Section 2. PRINCIPALES VALEURS
En menant à bien cette mission, l’ICANN doit être guidé dans ses décisions et actions par les principales valeurs suivantes :
1. Préservation et amélioration de la stabilité opérationnelle, de la fiabilité, de la sécurité et de l’interopérabilité mondiale de l’Internet
2. Respect de la créativité, de l’innovation et de la diffusion des informations rendues possibles par l’Internet en limitant les activités de l’ICANN aux questions relevant de sa mission, exigeant ou bénéficiant de façon significative d’une coordination mondiale.
3. Dans la mesure du possible et au besoin, délégation des fonctions de coordination à ou reconnaissance du rôle en matière politique d’autres entités responsables reflétant les intérêts des parties intéressées.
4. Recherche et soutien d’une participation étendue et informée reflétant la diversité fonctionnelle, géographique et culturelle de l’Internet, à tous les niveaux du développement des politiques et de la prise de décision.
5. Dans la mesure du possible et selon les besoins, recours aux mécanismes des marchés afin de favoriser et consolider un environnement compétitif.
6. Introduction et soutien de la concurrence en termes d’enregistrement des noms de domaines dans la mesure du possible et dans l’intérêt du public.
7. Emploi de mécanismes de développement de politiques ouverts et transparents qui (i) favorisent des décisions bien informées fondées sur des conseils experts, et (ii) assurent que les entités les plus concernées sont en mesure d’aider le processus de développement des politiques.
8. Prise de décisions par l’application neutre et objective de politiques documentées, en toute intégrité et équité.
9. Rapidité d’action permettant de répondre aux besoins de l’Internet tout en obtenant des commentaires éclairés émanant des entités les plus concernées, et ce dans le cadre du processus de prise de décision.
10. Responsabilité continue vis à vis de la communauté Internet par le biais de mécanismes permettant d’améliorer l’efficacité de l’ICANN.
11. Tout en restant ancré dans le secteur privé, reconnaissance des gouvernements et autorités publiques en tant que responsables des politiques publiques et prise en compte légitime des recommandations émanant des gouvernements ou « des autorités publiques ».
Ces principales valeurs sont délibérément formulées en des termes très généraux, afin de fournir des informations utiles et pertinentes pour le plus grand nombre de cas possibles. Dans la mesure où ces dernières n’ont pas un caractère rigoureusement normatif, leur application spécifique, de manière individuelle et collective, dépendra nécessairement pour chaque nouvelle situation de différents facteurs qui ne peuvent en aucun cas être anticipés ou énumérés ; et dans la mesure où il s'agit là de principes plus que de pratiques, une parfaite fiabilité aux onze principales valeurs de manière simultanée ne pourra être forcément possible lors de l’apparition de certaines nouvelles situations. Tout membre de l’ICANN formulant une recommandation ou prenant une décision doit exercer son jugement pour déterminer les principales valeurs les plus pertinentes ainsi que leur application aux circonstances propres au cas à traiter, pour ensuite déterminer, si nécessaire, un équilibre approprié et défendable entre les différentes valeurs.
Sauf mention contraire dans les clauses ou ces statuts, les pouvoirs de l’ICANN doivent être exercés par le Conseil d’administration, et sa propriété contrôlée ainsi que ses activités professionnelles conduites par ou sous la direction du Conseil d’administration. Conformément à toute question relative aux clauses de l’Article III, Section 6, le Conseil d’administration ne peut agir qu’à condition d’obtenir la majorité des votes de tous les membres du Conseil d’administration. Pour les autres questions, sauf stipulation contraire de ces Statuts ou de la loi, le Conseil d’administration peut agir à condition d'obtenir la majorité du vote des membres présents lors de réunions annuelles, régulières ou extraordinaires du Conseil d’administration. Toute référence dans ces statuts à un vote du Conseil d’administration renvoie uniquement au vote de ceux présents à la réunion au cours de laquelle il existe un quorum, sauf stipulation contraire incluse dans ces statuts, l’élargissant à « tous les membres du Conseil d’administration ».
L’ICANN ne doit pas agir en tant que registre de nom de domaine, de bureau d’enregistrement ou encore de registre d’adresses IP en concurrence avec des entités affectées par les politiques de l’ICANN. Rien dans cette section n’est prévu pour empêcher l’ICANN de prendre les mesures nécessaires à la protection de la stabilité opérationnelle d’Internet en cas d’échec financier d'un registre, bureau d’enregistrement, ou tout autre cas d’urgence.
Section 3. TRAITEMENT NON-DISCRIMINATOIRE
L’ICANN ne doit pas appliquer ses normes, politiques, procédures ou pratiques de façon arbitraire, inéquitable ou injustifiée et ne pas traiter un Bureau d’enregistrement de façon particulière à moins que cela ne soit justifié par un motif sérieux et valable, telle que la promotion d’une concurrence efficace.
L’ICANN et ses organes constituants doivent opérer autant que possible de façon ouverte et transparente, et conformément aux procédures visant à assurer l’équité.
L’ICANN doit maintenir un site Internet accessible au public (désigné ci-après par « site Web), qui doit comprendre, entre autres, (i) un calendrier des différentes réunions au programme du Conseil d’administration, des organismes de support, et des Comités consultatifs ; (ii) un registre de toutes les questions en suspens relatives à l’élaboration de la politique, avec leur calendrier ainsi que leur statut actuel ; (iii) les notifications de réunions spécifiques ainsi que les ordres du jour, comme décrit ci-dessous, (iv) les informations relatives au budget de l’ICANN, un audit annuel, les intervenants financiers ainsi que le montant de leur contribution, et d’autres questions en rapport, (v), les informations concernant la disponibilité des mécanismes de responsabilité, en prenant en compte la reconsidération, l’audit indépendant et les activités du médiateur, ainsi que les informations relatives au résultat de demandes spécifiques et de plaintes faisant allusion à ces différents mécanismes ; (vi) les annonces concernant les activités dignes d’intérêt de l’ICANN pour différents segments de la communauté de l’ICANN, (vii) les commentaires provenant de la communauté au sujet des politiques en cours et d'autres questions ; (viii) les informations concernant les réunions en face à face ou forums publics de l'ICANN; et (ix) d'autres informations d’intérêt pour la communauté de l’ICANN.
Section 3. ADMINISTRATEUR POUR LA PARTICIPATION DU PUBLIC
Il doit y avoir une position intitulée Administrateur pour la Participation du Public ou tout autre titre tel que décidé par le Président. Il s’agit, sous la direction du Président, d'être en charge de la coordination des différents aspects de la participation du public au sein de l' ICANN, en prenant en compte le site web ou tout autre moyen de communication pour recueillir ainsi les remarques provenant de la communauté au sens large des utilisateurs Internet.
Section 4. ANNONCES DE REUNIONS ET ORDRES DU JOUR
L’annonce d'une réunion et, dans la mesure du possible, un ordre du jour de la réunion devront être publiés au minimum sept jours avant chaque réunion du conseil d’administration (ou le plus tôt possible),
Section 5. MINUTES ET RAPPORTS PRÉLIMINAIRES
1. Toutes les minutes des réunions du Conseil d’administration et des Organismes de soutien (et de tout autre conseil) devront être approuvées dans les plus brefs délais par les organes à l'origine de ces réunions et remises au Secrétaire de l’ICANN qui se chargera de les publier sur le site web.
2. Au plus tard dans les (5) jours ouvrables suivant chaque réunion (heure locale du bureau principal de l’ICANN), toute les mesures prises par le Conseil d’administration doivent être rendues publiques sur le site Web dans un rapport préliminaire. Il faut toutefois que toutes les mesures ayant trait aux questions du personnel ou de l’emploi, ou encore aux questions légales (dans la mesure où le Conseil d’Administration le juge nécessaire ou approprié pour protéger les intérêts de l’ICANN), mesures que l’ICANN est légalement ou contractuellement interdit de divulguer, et d’autres qui selon un vote à la majorité des trois-quarts(3/4) des Administrateurs au Conseil d’administration présents lors de la réunion et ayant droit de vote sont jugées inappropriées à une diffusion publique, ne soient pas incluses dans le rapport préliminaire rendu public. Pour toutes les questions que le Conseil d’administration choisit de ne pas divulguer, il devra expliquer dans le rapport préliminaire et ce en des termes généraux, les raisons de cette non-divulgation.
3. Dès le jour de leur approbation formelle par le Conseil d'administration (ou dans le cas où il ne s’agit pas d’un jour ouvrable selon le calendrier local du bureau principal de l’ICANN, le prochain jour ouvrable), les minutes doivent être rendues publiques sur le site Web. Il faut toutefois que toutes les mesures ayant trait aux questions du personnel ou de l’emploi, ou encore aux questions légales (dans la mesure où le Conseil d’administration le juge nécessaire ou approprié pour la protection des intérêts de l’ICANN), questions que l’ICANN est légalement ou contractuellement interdit de divulguer, et d’autres qui selon un vote à la majorité des trois-quarts(3/4) des Administrateurs au Conseil d’administration présents lors de la réunion et ayant droit de vote sont jugées inappropriées à une diffusion publique, ne soient pas incluses dans le rapport préliminaire rendu public. Pour toutes les questions que le Conseil d’administration choisit de ne pas divulguer, il doit expliquer en des termes généraux les raisons de cette non-divulgation dans les minutes concernées.
Section 6. NOTIFICATION ET COMMENTAIRE AU SUJET DES ACTIONS POLITIQUES
1. Conformément aux politiques prises en compte par le Conseil d’administration pour l’adoption ayant une nette incidence sur le fonctionnement d’Internet ou de tiers, dont l’imposition de frais divers, l’ICANN doit :
a. publier un commentaire public sur le site Web expliquant les politiques considérées pour l’adoption et les raisons, au minimum dans les vingt et un jours (plus tôt, si possible) précédant toute action du Conseil d’administration ;
b. donner aux parties la possibilité de commenter l’adoption des politiques proposées, de consulter les commentaires des autres et d’y répondre, avant toute action du conseil d’administration ; et
c. demander l’avis du comité consultatif gouvernemental, dans les cas où l’action politique influe sur les intérêts de la politique publique, et prendre dûment en compte tout conseil formulé dans les temps par le comité consultatif gouvernemental par sa propre initiative ou à la demande du conseil d’administration.
2. Dans la mesure du possible, et si cela convient au processus d’élaboration de la politique correspondante, un forum public doit être tenu afin de discuter des politiques proposées, comme décrit dans la Section 6 (1)(b) de cet article, avant toute action finale du conseil d’administration.
3. Après avoir pris des mesures concernant tout sujet ayant trait à la politique de cette section, le conseil d'administration doit publier dans les minutes de ses réunions, les raisons des mesures prises, le vote de chaque administrateur ayant voté pour cette mesure, ainsi que la décision séparée des administrateurs ayant choisi la publication d'une telle déclaration.
Section 7. TRADUCTION DE DOCUMENTS
Selon les besoins et les limites prévues dans le budget de l’ICANN, l’ICANN doit envisager la traduction des documents finaux publiés dans les différentes langues appropriées.
ARTICLE IV : RESPONSABILITÉ ET RÉVISION
Dans le cadre de sa mission telle qu’elle est définie dans ces statuts, l’ICANN doit faire en sorte que la communauté agisse en adéquation avec ces statuts, et en tenant parfaitement compte des principales valeurs soulignées au sein de ces derniers. Article I de ces statuts. Les clauses de cet article, engendrant un processus de reconsidération et de révision indépendante des actions de l’ICANN ainsi que la révision périodique de sa structure et de ses procédures, sont conçues pour renforcer les différents mécanismes de responsabilité suggérés dans ces statuts, y compris les clauses de transparence de l’article III et du conseil d’administration, ainsi que d’autres mécanismes de sélection mentionnés dans ces statuts.
1. L'ICANN doit avoir en place un processus par lequel toute personne ou entité matériellement affectée par une quelconque action de l’ICANN peut demander une révision ou une reconsidération de cette action par le conseil d’administration.
2. Toute personne ou entité peut soumettre une demande de reconsidération ou de révision d’une action ou inaction de l’ICANN (« Demande de Reconsidération ») dans la mesure où il ou elle a été affecté(e) par :
a. une ou plusieurs actions ou inactions du personnel en contradiction avec la ou les politiques établies par l’ICANN ; ou
h. une ou plusieurs actions ou inactions du conseil d'administration de l’ICANN prises ou refusées sans prendre en compte l'information matérielle, sauf si la partie soumettant la demande aurait pu la remettre, sans le faire, au conseil d’administration avant que celui-ci n'agisse ou pas.
3. Un comité du conseil d’administration constitué de trois administrateurs au minimum doit être mis en place, afin de réviser et considérer toute demande de ce type (« Comité de Reconsidération »). Il doit :
a. évaluer les demandes de révision ou de reconsidération ;
b. déterminer si oui ou non la résolution en suspens concernant l’action contestée de la demande est appropriée.
c. juger si, oui ou non, une enquête factuelle est appropriée ;
d. demander à la partie affectée ou à d’autres parties, des détails écrits supplémentaires ; et
e. formuler une recommandation au conseil d’administration au sujet de la valeur de la demande.
4. L’ICANN doit prendre en charge les coûts administratifs normaux du processus de reconsidération. L’ICANN se réserve le droit d’exiger de la partie faisant une demande de révision ou de reconsidération de prendre en charge tout coût jugé extraordinaire par nature. Lorsque ce type de coûts extraordinaires peut être prévu à l’avance, les raisons avançant pourquoi ils sont indispensables à l’évaluation de la demande de reconsidération doivent être communiquées à la partie demandant une reconsidération, qui a ensuite le choix de se retirer ou d'accepter de prendre en charge ces coûts.
5. Toute demande de reconsidération doit être envoyée à une adresse e-mail désignée par le Comité de reconsidération dans les trente jours suivants :
a. pour les demandes concernant les actions du Conseil d’Administration, la date à laquelle l’action contestée du Conseil d’administration est publiée pour la première fois dans un rapport préliminaire ou dans les minutes des réunions du Conseil d’Administration ; ou
b. pour les demandes concernant les actions du personnel, la date à laquelle la partie envoyant la demande a pris conscience ou, raisonnablement pris conscience de l’action contestée du personnel ; ou,
b. pour les demandes concernant soit l’inaction du Conseil d’Administration, soit celle du personnel, la date à laquelle la personne affectée a conclu, ou a dû conclure que, l’action ne serait pas prise suffisamment vite.
6. Toute demande de reconsidération doit comprendre les informations demandées par le Comité de reconsidération, parmi lesquelles :
a. le nom, l’adresse, et le contact de la partie formulant la demande, en incluant les adresses postale et e-mail.
b. l’action ou inaction spécifique de l’ICANN pour laquelle une révision ou reconsidération est envisagée ;
c. la date de l’action ou inaction ;
d. la manière dont la partie qui fait la demande sera affectée par l’action ou inaction ;
e. la mesure dans laquelle, selon la partie soumettant la demande de reconsidération, l’action ou inaction critiquée affecte d’autres personnes ;
f. si, oui ou non, une suspension provisoire de toute action contestée est nécessaire, et si oui, les torts qui en résulteront en cas de non-suspension ;
g. dans le cas d’une action ou inaction du personnel, une explication détaillée des faits tels qu'ils ont été présentés au personnel, ainsi que les raisons qui ont rendu l'action ou inaction du personnel incompatible avec la ou les politiques établie(s) par l’ICANN ;
h. dans le cas d’une action ou inaction du Conseil d' Administration, une explication détaillée de l'information matérielle ignorée par le Conseil d’Administration, et, si l’information n’a pas été présentée au Conseil d’Administration, les raisons pour lesquelles la partie soumettant la demande n’a pas mentionné son intention au conseil d’administration avant que celui-ci n'agisse ou pas.
i. les mesures spécifiques que la partie formulant la plainte demande auprès de l'ICANN, à savoir si, oui ou non, et comment l'action doit être inversée, annulée ou modifiée ou encore les actions spécifiques qui doivent être menées ;
j. les critères selon lesquels la mesure demandée doit être prise ; et
k. tous les documents que la partie faisant la demande souhaite soumettre pour soutenir sa demande.
7. Toutes les demandes de reconsidération doivent être publiées sur le site Web.
8. Le Comité de Reconsidération est chargé d’examiner les demandes de reconsidération de différentes parties en suivant la même procédure, à condition que (i) les demandes concernent la même action ou inaction générale et (ii) que les parties soumettant les demandes de reconsidération soient affectées de la même manière par une telle action ou inaction.
9. Le comité de reconsidération doit examiner les demandes de reconsidération dès leur réception et annoncer, dans un délai de trente jours, son intention de décliner ou de procéder à l’étude de la Demande de Reconsidération après sa réception. L’annonce doit être publiée sur le site Web.
10. L’annonce d’une décision du comité de reconsidération de ne pas donner suite à une demande de reconsidération doit comprendre une explication des raisons de ce choix.
11. Le comité de reconsidération peut demander des informations supplémentaires ou éclaircissements de la part de la partie formulant la demande de reconsidération.
12. Le comité de reconsidération peut demander au personnel de l’ICANN son avis sur la question, qui sera alors rendue public sur le site Web.
13. Si le comité de reconsidération a besoin d’informations supplémentaires, il peut choisir de s’entretenir avec la partie faisant la demande de reconsidération soit par téléphone, courrier electronique, soit si la partie le souhaite, en personne. Dans la mesure où toute information recueillie au cours d’un tel entretien est pertinente pour toute recommandation du comité de reconsidération, elle doit être mentionnée dans ladite recommandation.
14. Le comité de reconsidération peut également demander des informations pertinentes à la demande de tiers. Dans la mesure où toute information recueillie est pertinente pour une quelconque recommandation du comité de reconsidération, elle doit être mentionnée dans ladite recommandation.
15. Le comité de reconsidération doit ouvrir une demande de reconsidération sur la base d’un enregistrement public écrit du personnel de l’ICANN et de tout tiers, comprenant des informations soumises par la partie à l’origine de la reconsidération ou la révision.
16. Afin de lutter contre les abus de procédure de reconsidération, le comité de reconsidération peut rejeter une demande jugée répétitive, fantaisiste, légère, ou abusive ou si la partie affectée n’a pas participé, bien qu’ayant eu l’occasion, à la période de consultation publique concernant l’action contestée, le cas échéant. Le comité de reconsidération peut également rejeter une demande si la partie à l'origine de la demande de reconsidération n’arrive pas à prouver qu'elle sera affectée par l'action de l'ICANN.
17. Le comité de reconsidération peut formuler une recommandation finale au conseil d’administration au sujet d’une demande de Reconsidération, dans les quatre-vingt-dix jours suivant la réception de la demande. Dans le cas où cela serait impossible, le comité de reconsidération doit préciser au conseil d'administration les circonstances qui l’ont empêché de formuler sa recommandation finale, ainsi que le temps nécessaire estimé pour produire une telle recommandation. La recommandation finale doit être publiée sur le site Web.
18. Le conseil d'administration n’est pas tenu de suivre les recommandations du comité de reconsidération. La décision finale du conseil d’administration doit être rendue publique dans le cadre du rapport préliminaire et des minutes de la réunion du conseil d’administration au niveau duquel l’action est menée.
19. Chaque année, le comité de reconsidération doit soumettre un rapport au conseil d'administration contenant au minimum les informations suivantes pour l'année précédente :
a. le nombre et la nature générale des demandes de reconsidération reçues ;
b. le nombre de demandes de reconsidération pour lesquelles le comité a pris des mesures ;
c. le nombre de demandes de reconsidération restées en suspens à la fin de l’année, ainsi que la durée moyenne depuis laquelle de telles demandes de reconsidération sont en suspens ;
d. une description de toutes les demandes de reconsidération laissées en suspens à la fin de l’année pendant plus de quatre-vingt-dix (90) jours, ainsi que les raisons pour lesquelles le comité n’a pris aucune mesure les concernant ;
e. le nombre et la nature des demandes de reconsidération que le comité a refusé de prendre en compte dans la mesure où elles ne remplissaient pas les critères établis dans sa politique ;
f. pour les demandes de reconsidération rejetées, une explication de tous les autres mécanismes disponibles pour garantir que l’ICANN soit responsable des personnes matériellement affectées par ses décisions ; et
g. si oui ou non, selon le comité, les critères pour lesquels la reconsidération peut être demandée doivent être révisés, ou si un autre processus doit être adopté ou modifié, pour s’assurer que toute personne matériellement affectée par les décisions de l’ICANN ait bien accès à un processus de révision qui garantisse l’équité, tout en limitant les plaintes fantaisistes.
20. Chaque rapport annuel doit également regrouper les informations relatives aux sujets répertoriés dans le paragraphe 19(a)-(e) de cette section pour la période commençant le 1ier janvier 2003.
Section 3. RÉVISION INDÉPENDANTE DES ACTIONS DU CONSEIL D’ADMINISTRATION
1. Outre le processus de reconsidération décrit dans la section 2 de cet article,l’ICANN doit instaurer un processus distinct pour un examen indépendant tiers des actions du conseil d’administration jugées, selon une partie concernée, incompatibles avec les statuts de l’ICANN.
2. Toute personne matériellement affectée par une décision ou action du conseil d’administration qu’il ou elle juge incompatible avec les statuts de l’ICANN peut soumettre une demande pour obtenir l’examen indépendant de cette décision ou action.
3. Les demandes d’un tel examen indépendant doivent renvoyer à un Panel de révision indépendant (« IRP »), en charge de comparer les actions contestées du conseil d’administration aux statuts de l’ICANN, et de déclarer si le conseil d’administration a clairement agi en respectant les clauses de ces statuts.
4. Le Panel de révision indépendant doit être mis en place par un fournisseur d’arbitrage international nommé de temps en temps par l’ICANN (« le fournisseur du Panel de révision indépendant»)
5. En fonction de l’approbation du conseil d’administration, le fournisseur du Panel de révision indépendant doit établir des règles et procédures de fonctionnement qui doivent être mises en place, et en conformité avec la section 3.
6. Chacune des parties peut décider que la demande pour une révision indépendante soit considérée par une commission constituée de trois membres ; en l'absence d'une telle décision, par défaut, la question sera considérée par une commission constituée d’un seul membre.
7. Le fournisseur du Panel de révision indépendant doit déterminer une procédure pour nommer les membres des commissions individuelles, à condition que, si l’ICANN l’ordonne ainsi, le fournisseur de Panel de révision indépendant établisse un panel permanent pour recevoir de telles plaintes.
d. demander des propositions supplémentaires écrites de la partie affectée, du conseil d’administration, des organismes de soutien ou des autres parties ; et
b. déclarer si oui ou non une action ou inaction du Conseil d’administration a été incompatible avec les clauses ou Statuts ; et
c. recommander que le Conseil d’Administration suspende toute action ou décision, ou prenne toute décision provisoire jusqu’à ce qu’il révise et agisse en fonction de l’avis du Panel de révision indépendant.
9. Toute personne occupant un poste ou une fonction officiel(le) au sein des structures de l’ICANN n’est pas éligible pour intégrer le Panel de révision indépendant.
10. Dans le but de maintenir les coûts et charges de la révision indépendante le plus bas possible, le Panel de révision indépendant doit mener ses procédures, autant que possible, par e-mail ou Internet. Si nécessaire, le Panel de révision indépendant peut accorder des entretiens par téléphone.
11. Le Panel de révision indépendant doit se soumettre à la politique des conflits d'intérêt spécifiée dans les règles et procédures d’opération du fournisseur du Panel de révision indépendant approuvées par le conseil d’administration.
12. Les déclarations du Panel de révision indépendant doivent se faire par écrit. Le Panel de révision indépendant doit uniquement fonder sa déclaration sur la documentation, les pièces justificatives, ainsi que les différents arguments soumis par les parties, et doit, par ailleurs spécifiquement préciser dans sa déclaration la partie dominante. La partie dominée prend généralement en charge tous les coûts du fournisseur du Panel de révision indépendant, mais, dans un cas extraordinaire, ce dernier peut attribuer dans sa déclaration jusqu’à près de la moitié des coûts du fournisseur du Panel indépendant de révision à la partie dominante en se fondant sur les circonstances, et en prenant en considération la sagesse des positions des parties ainsi que leur contribution envers l’intérêt public. Chaque partie intervenant dans les procédures du Panel de révision indépendant doit prendre à sa charge ses propres frais.
13. Les procédures de fonctionnement du Panel de révision indépendant, ainsi que toutes les pétitions, revendications et déclarations doivent être publiées sur le site Web, dès lors qu'elles sont disponibles.
14. Le Panel de révision indépendant doit, à sa discrétion, garantir une certaine confidentialité de l’information suivant la demande d’une partie, comme par exemple lorsqu’il est question de secrets commerciaux.
15. Le cas échéant, le conseil d'administration examine la déclaration du Panel de révision indépendant au cours de la réunion suivante du conseil d'administration.
Section 4. RÉVISION PÉRIODIQUE DES STRUCTURES ET ACTIVITÉS DE L’ICANN
1. Le conseil d’administration doit mettre en place, si possible à raison d'une fois tous les trois ans minimum, un processus de révision indépendante des prestations et activités de chaque organisme de soutien, conseil des organismes de soutien, comité consultatif (différent du comité consultatif gouvernemental), ainsi que du comité de nomination, réalisé par une ou plusieurs entités indépendantes de l'organisme en cours d'examen. Le but de la révision, entreprise à l’issue de critères et standards tels qu’énoncés par le conseil d'administration, est de déterminer (i) si cet organisme a un rôle permanent au sein de la structure de l'ICANN, et (ii) si oui ou non, tout changement dans la structure ou les opérations serait souhaitable pour améliorer son efficacité. Les résultats des révisions devront être publiés sur le Site web pour être révisés publiquement ou commentés et devront par ailleurs être examinés par le Conseil d’administration pas plus tard que lors de sa deuxième réunion programmée, après que les résultats aient été rendus publics pendant 30 jours. Le Conseil d’administration examine également la possibilité de réviser la structure ou les activités des organes de l'ICANN par un vote à la majorité des deux-tiers de l’ensemble des membres du Conseil d'administration.
2. La première des révisions, commencée au plus tard le 15 décembre 2003 et complétée en temps voulu pour l’examen du conseil d’administration au cours de la réunion annuelle de l'ICANN en 2004, devra dépendre du conseil du GNSO ainsi que du comité consultatif du serveur racine de l'ICANN. La deuxième révision, qui devra être commencée au plus tard le 15 novembre 2004 et complétée en temps voulu pour l’examen du conseil d’administration au cours de la réunion annuelle de l'ICANN en 2005, devra dépendre du ccNSO, du conseil du ccNSO, ainsi que d’autres organismes désignés par le conseil d’administration.
3. Le comité consultatif gouvernemental doit fournir ses propres mécanismes de révision.
Section 1 : BUREAU DU MÉDIATEUR
1. Un bureau du médiateur doit être mis en place, dirigé par un médiateur et qui doit comprendre un soutien en personnel si le Conseil d' administration le juge approprié et envisageable. Le poste de médiateur sera une fonction à plein-temps, avec un salaire ainsi que des avantages en conséquence, comme convenu par le conseil d’administration.
2. Le médiateur sera nommé par le conseil d’administration pour un mandat initial de deux ans, qui pourra être reconduit par le conseil d’administration.
3. Le médiateur pourra être renvoyé par le conseil d’administration sur la seule base d'un vote aux trois-quarts (3/4) de l'ensemble du conseil d'administration.
4. Le budget annuel du bureau du Médiateur sera établi par le conseil d'administration dans le cadre de l'établissement du budget annuel de l'ICANN. Le Médiateur soumettra une proposition de budget au Président et le Président inclura cette proposition de budget dans son intégralité et sans modification dans le cadre du budget général de l'ICANN recommandé par le Président de l'ICANN au conseil d'administration. Rien dans cet article n'empêchera le président de présenter des vues séparées sur le contenu, la taille et d'autres caractéristiques de la proposition de budget du Médiateur présentée au conseil d'administration.
La charte du médiateur doit servir à agir de manière neutre lors de la résolution de litiges concernant les questions dont les clauses de la politique de reconsidération exposées dans la section 2 de l’article IV ou la politique de révision indépendante énoncée dans la section 3 de l’article IV n’ont pas été évoquées. La fonction principale du médiateur doit consister à fournir une évaluation interne indépendante des plaintes émanant des membres de la communauté de l'ICANN qui estiment avoir été injustement traités par le personnel de l'ICANN, le conseil d'administration ou un organe constituant de l’ICANN. Le médiateur doit militer objectivement pour l'équité, chercher à évaluer et, si possible, résoudre les plaintes relatives à un traitement injuste ou inapproprié du personnel de l’ICANN, du conseil d’administration ou d’organes constituants de l’ICANN, en éclaircissant les problèmes et en utilisant des outils de résolution de litiges comme la négociation, la facilitation ou des « démarches diplomatiques » pour arriver à ces fins.
Le bureau du médiateur doit :
1. faciliter la résolution équitable, impartiale et opportune des problèmes et plaintes que les membres affectés de la communauté de l’ICANN (à l’exception des employés, des vendeurs / fournisseurs de l’ICANN) peuvent avoir formulés concernant des actions ou inactions spécifiques du conseil d'administration ou du personnel de l'ICANN, n’ayant pas fait l'objet de politique de reconsidération ou de révision indépendante.
2. être libre d’accepter ou de refuser de traiter une plainte ou question, y compris en développant des procédures pour abandonner les plaintes jugées insuffisamment concrètes, substantielles, ou trop liées aux interactions de l’ICANN avec la communauté pour être traitées par le médiateur. En outre, et sans limitation des faits précédemment cités, le médiateur n’est pas autorisé à agir sur des questions administratives internes, personnelles, ou des problèmes ayant trait à l’appartenance au conseil ou à des relations vendeur / fournisseur ;
3. avoir le droit d’accéder (mais non pas de publier s’il y a confidentialité) à toutes les informations nécessaires et enregistrements du personnel de l’ICANN et des organes constituants pour permettre ainsi un examen documenté de la plainte, et de participer, si possible, à la résolution de litige (sous réserve des obligations de confidentialité telles qu'imposées par le plaignant ou de toute politique de confidentialité généralement applicable adoptée par l'ICANN) ;
4. Informer du programme du médiateur et de ses fonctions à travers des interactions de routine avec la communauté de l'ICANN et en publiant ces données sur le site Web.
5. faire régner la neutralité et l’indépendance, et ne pas avoir de parti pris ou d’enjeu personnel dans la conclusion ; et
6. se conformer à toutes les politiques des conflits d’intérêt et de confidentialité de l’ICANN.
Section 4. INTERACTION AVEC LES ENTITÉS DE L’ICANN OU EXTÉRIEURES À L’ICANN
1. Aucun employé de l’ICANN, membre du conseil d’administration, ou autre participant aux organismes de soutien ou comités consultatifs ne doit empêcher ou entraver les échanges entre le médiateur et la communauté de l'ICANN (y compris les employés de l'ICANN). Les employés de l’ICANN, ainsi que les membres du conseil d’administration doivent orienter les membres de la communauté de l’ICANN qui adresseront les problèmes, questions ou plaintes à propos de l’ICANN vers le médiateur, qui doit avertir et conseiller les plaignants sur les différentes options possibles pour examiner ces problèmes, question ou plaintes.
2. Le personnel de l’ICANN et les autres membres doivent observer et respecter les décisions du bureau du médiateur concernant la confidentialité des plaintes reçues par ce bureau.
3. Tout contact avec le médiateur n’aura pas valeur de notification à l’ICANN de toute action particulière ou justification d’une action.
4. Le médiateur doit être spécifiquement autorisé à rendre des rapports au conseil d’administration à propos d’une question particulière et de sa résolution ou de l’incapacité à la résoudre, si il ou elle l’estime nécessaire. En l’absence d'une décision par le médiateur, à sa seule discrétion, spécifiant que cela serait inapproprié, ces rapports doivent être publiés sur le site Web.
5. Le médiateur ne doit en aucun cas prendre une mesure non-prévue dans ces statuts, ni en particulier, instituer, joindre, ou soutenir de quelque manière que ce soit, toute mesure remettant en cause les structure, procédures, ou procédés de l’ICANN, ou encore toute conduite de son conseil d’administration, du personnel ou des organes constituants.
Chaque année, le bureau du médiateur doit publier une analyse complète des plaintes de l'année et de leurs résolutions, en respectant les obligations et soucis de confidentialité. Ce rapport annuel devra inclure une description de toutes les tendances ou points communs des plaintes reçues au cours de la période concernée, ainsi que les décisions qui pourraient être prises à l’avenir pour réduire le nombre de plaintes. Le rapport annuel doit être publié sur le site Web.
ARTICLE VI : CONSEIL D'ADMINISTRATION
Section 1. COMPOSITION DU CONSEIL D’ADMINISTRATION
Le conseil d’administration de l’ICANN doit être constitué de quinze membres ayant le droit de vote (appelés « administrateurs ») Par ailleurs, six agents de liaison sans droit de vote doivent être nommés pour les tâches exposées dans la section 9 de cet article. Seuls les administrateurs sont chargés de déterminer l’existence de quorums et établir la validité des votes du conseil d’administration de l’ICANN.
Section 2. LES ADMINISTRATEURS ET LEUR SÉLECTION ; ÉLECTION DU PRÉSIDENT ET DU VICE-PRÉSIDENT
a. Huit membres ayant le droit de vote, sélectionnés par le comité de nomination établi par l’article VII de ces statuts. Ces sièges au conseil d’administration sont appelés dans ces statuts sièges 1 à 8.
b. Deux membres ayant le droit de vote sélectionnés par l’organisme de soutien des adresses, conformément aux clauses de l’article VIII de ces statuts. Ces sièges au conseil d’administration sont désignés dans ces statuts comme étant les sièges 9 et 10.
c. Deux membres ayant le droit de vote sélectionnés par l’organisme de soutien des noms de codes de pays, conformément aux clauses de l’article IX de ces statuts. Ces sièges au conseil d’administration sont désignés dans ces statuts comme étant les sièges 11 et 12.
d. Deux membres ayant le droit de vote sélectionnés par l’organisme de soutien des noms génériques, conformément aux clauses de l’article X de ces statuts. Ces sièges au conseil d’administration sont désignés dans ces Statuts comme étant les sièges 13 et 14.
e. Le président ex officio, qui doit être un membre ayant le droit de vote.
2. En exécutant sa mission consistant à pourvoir les sièges 1 à 8, le comité de nomination doit s’assurer que le conseil d’administration de l’ICANN soit composé de membres qui, dans leur totalité, affichent une diversité géographique, culturelle, mais également en termes de compétences, expérience et perspective en appliquant les critères énoncés dans la section 3 de cet article. Le comité de nomination ne doit, à aucun moment, sélectionner un administrateur pour pourvoir une vacance ou un mandat expiré dont la sélection élèverait le nombre total d’administrateurs (à l'exception du président) citoyens d'une région géographique (comme spécifié dans la section 5 de cet article) à plus de cinq ; et le comité de nomination doit s’assurer qu’à travers ses sélections, le conseil d’administration comprenne, à tout moment, au moins un administrateur citoyen d’un pays dans chaque région géographique de l'ICANN.
3. En exécutant sa mission consistant à pourvoir les sièges 9 à 14, les organismes de soutien doivent s’assurer que le conseil d’administration de l’ICANN soit composé de membres qui, dans leur totalité, affichent une diversité géographique, culturelle, mais également en termes de compétences, expérience et perspective en appliquant les critères énoncés dans la section 3 de cet article. A aucun moment, deux administrateurs sélectionnés par l’organisme de support peuvent être citoyens du même pays, ou de pays situés dans la même région géographique.
4. Chaque année, le conseil d'administration doit élire un président et un vice-président parmi les administrateurs, président exclus.
Section 3. CRITÈRES POUR LA SÉLECTION DES ADMINISTRATEURS
Les administrateurs de l’ICANN doivent être :
1. Des personnes réputées pour leur intégrité, objectivité et intelligence, ainsi que pour leur bon jugement, ouverture d’esprit et leur capacité confirmée dans la prise de décision au sein d’un groupe ;
2. Des personnes ayant intégré la mission de l’ICANN, l’impact potentiel de ses décisions sur l’ensemble de la communauté Internet, et prêtes à s’engager en faveur de la réussite de l’ICANN ;
3. Des personnes qui formeront la plus large diversité culturelle et géographique au conseil d’administration, conformément aux autres critères soulignés dans cette section ;
4. Des personnes, qui, dans l'ensemble, sont familières avec les opérations des registres et bureaux d’enregistrement gTLD ; avec les registres ccTLD ; avec les registres des adresses IP ; avec les normes et protocoles techniques Internet ; avec les procédures d’élaboration de politique, les coutumes juridiques et l’intérêt public ; avec la grande variété d’utilisateurs commerciaux, individuels, académiques et non-commerciaux d’Internet.
5. Des personnes désireuses d’agir de manière volontaire, sans autre compensation que le remboursement de certains frais ; et
6. Des personnes capables de travailler et communiquer en anglais à l’écrit et à l’oral.
Section 4. QUALIFICATIONS SUPPLÉMENTAIRES
1. Sauf disposition contraire, aucune autorité d’un gouvernement national ou d’une entité multinationale établie par traité ou tout autre accord entre des gouvernements nationaux ne peut servir d’administrateur. Le terme d’« autorité » mentionné ci-dessus désigne une personne (i), qui a été élue à la tête d’un bureau gouvernemental ou (ii) qui est employée par ce gouvernement ou une entité multinationale, et dont la fonction première avec un tel gouvernement ou une telle entité consiste à développer ou influencer les politiques gouvernementales ou publiques.
2. Toute personne qui exerce une fonction (y compris celle d'agent de liaison) ou est membre du conseil des organismes de soutien ne peut agir à la fois en tant qu’administrateur et agent de liaison du conseil d’administration. Si cette personne accepte qu’une nomination soit prise en compte pour la sélection du conseil des organismes de soutien, cette personne ne pourra pas, après une telle nomination, participer aux discussions ou votes du conseil des organismes de soutien ayant trait à la sélection des administrateurs du conseil, avant que le conseil n’ait sélectionné la totalité des administrateurs qu’il doit sélectionner. Dans le cas où une personne qui exerce une fonction dans un conseil des organismes de soutien accepte une nomination pour la fonction d’administrateur, le groupe de constituants ou tout autre groupe ou entité à l’origine de la sélection de cette personne, doit choisir un remplaçant pour les besoins du processus de sélection du conseil.
3. Les personnes exerçant une fonction dans le comité de nomination doivent être éligibles pour la sélection aux postes du conseil d’administration, comme spécifié dans l’article VII, section 8.
Section 5. REPRÉSENTATION INTERNATIONALE
Afin d’assurer une vaste représentation du conseil d’administration à l’échelle internationale, la sélection des administrateurs par le comité de nomination ainsi que toute organisme de soutien doit être en conformité avec toutes les clauses de diversité en vigueur dans ces statuts ou tout protocole d’accord mentionné dans ces statuts ayant trait à l’organisme de soutien. Un des objectifs de ces clauses de diversité consiste à garantir que chaque région ait, à tout moment, au moins un administrateur, et qu'aucune région n'ait à un moment donné un conseil d’administration constitué de plus de cinq administrateurs (sans compter le président) Dans ces statuts, on désigne par « région géographique » : l'Europe, l’Asie / l’Australie / le Pacifique ; l’Amérique Latine / Les Caraïbes ; l’Afrique ; et l’Amérique du Nord. Les pays spécifiques inclus dans chaque région géographique doivent être déterminés par le conseil d'administration, qui devra réviser cette section de temps à autres (à raison d’une fois tous les trois ans au minimum) pour déterminer si, oui ou non, des changements sont nécessaires, du fait de l'évolution d'Internet.
Section 6. LES CONFLITS D'INTÉRÊT DES ADMINISTRATEURS
Le conseil d’administration, par le biais d’un comité désigné à cette fin, doit exiger, au minimum une fois par an, une déclaration de la part de chaque administrateur exposant toutes les activités commerciales et autres affiliations ayant trait d’une manière ou d’une autre aux activités commerciales et aux autres affiliations de l’ICANN. Chaque administrateur est responsable de la divulgation à l’ICANN de toute question qui pourrait être convenablement prise en compte pour faire de cet administrateur « un administrateur intéressé », selon l’explication donnée dans la section 5233 de la Loi CNPBCL. En outre, chaque administrateur doit faire part à l'ICANN de toute relation ou autre facteur susceptible d’être pris en considération pour faire de cet administrateur une « personne intéressée », selon l'explication donnée dans la section 5227 de la Loi CNPBCL. Le conseil d’administration doit adopter des politiques répondant aux conflits d’intérêt de l’administrateur, des membres et organismes de support. Aucun administrateur ne peut exprimer sa voix sur des affaires pour lesquelles il ou elle a un intérêt financier direct ou matériel qui pourrait avoir une incidence sur le résultat du vote.
Section 7. DEVOIRS DES ADMINISTRATEURS
Les administrateurs doivent agir en tant qu’individus qui ont le devoir d’intervenir dans ce qui, selon eux, constitue les meilleurs intérêts de l'ICANN, et non en tant que représentants d'une entité qui les a élus, leurs employés ou tout autre organisme ou collège.
Section 8. MANDATS DES ADMINISTRATEURS
1. Conformément aux clauses de l’article de transition de ces statuts, le mandat régulier du poste de direction des sièges 1 à 4 commence ainsi:
a. Les mandats réguliers des sièges 1 à 4 doivent commencer à la clôture de la réunion annuelle de l’ICANN en 2003 et à celle de chaque réunion de l'ICANN tenue tous les trois ans après 2003 ;
b. Les mandats réguliers des sièges 4 à 6 doivent commencer à la clôture de la réunion annuelle de l'ICANN en 2004, et à la clôture de chaque réunion de l'ICANN tenue tous les trois ans après 2004 ;
c . Les mandats réguliers des sièges 7 à 8 doivent commencer à la clôture de la réunion annuelle de l’ICANN en 2005 et à celle de chaque réunion annuelle de l'ICANN tenue tous les trois ans après 2005 ;
c . Les mandats réguliers des sièges 9 et 12 doivent commencer le premier jour du sixième mois suivant la clôture de la réunion annuelle de l’ICANN en 2002 et à la clôture de chaque réunion annuelle de l'ICANN tenue tous les trois ans après 2002 ;
c , Les mandats réguliers des sièges 10 et 13 doivent commencer le premier jour du sixième mois suivant la clôture de la réunion annuelle de l’ICANN en 2003 et à la clôture de chaque réunion annuelle de l'ICANN tenue tous les trois ans après 2003 ; et
c . Les mandats réguliers des sièges 11 et 14 doivent commencer le jour du sixième mois suivant la clôture de la réunion annuelle de l’ICANN en 2004 et à la clôture de chaque réunion annuelle de l'ICANN tenue tous les trois ans après 2004 ;
2. Chaque administrateur à la tête d’un des sièges 1 à 14, y compris l’administrateur sélectionné pour pourvoir une vacance, doit être en fonction pour un mandat durant jusqu’à la fin du mandat précédent et à la prise d’effet du siège, et jusqu'à ce qu'un successeur ait été choisi et qualifié ou jusqu'à ce que l’administrateur renouvelle son contrat ou soit relevé de ses fonctions conformément à ces statuts.
3. Au minimum un mois avant le début de chaque conférence annuelle, le comité de nomination doit remettre au secrétaire de l’ICANN une note écrite de sa sélection d’administrateurs pour les sièges dont les mandats commencent à la clôture de la réunion annuelle.
4. Au plus tard dans les cinq mois suivant la clôture de chaque conférence annuelle, tout organisme de soutien habilité à sélectionner un administrateur pour un siège dont le mandat commence le jour marquant les six mois suivant la conclusion de la réunion annuelle doit remettre une note écrite de son choix au secrétaire de l'ICANN.
5. Conformément aux clauses de ces statuts, aucun administrateur ne peut être en fonction plus de trois mandats consécutifs. Pour ce faire, une personne sélectionnée pour pourvoir la vacance d’un mandat ne doit pas être considérée comme ayant exercé ce mandat.
6. Le mandat en tant qu’administrateur de la personne exerçant la fonction de président doit durer aussi longtemps que, et seulement aussi longtemps que, la personne exerce la fonction de président.
Section 9. AGENTS DE LIAISON SANS DROIT DE VENTE
1. Les agents de liaison sans droit de vote doivent comprendre :
a. Un agent de liaison nommé par le comité consultatif gouvernemental;
b. Un agent de liaison nommé par le comité consultatif du serveur racine établi par l’article XI de ces statuts;
c. Un agent de liaison nommé par le comité consultatif sur la sécurité et la stabilité établi par l’article XI de ces statuts;
d. Un agent de liaison nommé par le groupe de liaison technique établi par l’article XI-A de ces statuts;
e. Un agent de liaison nommé par le comité consultatif des utilisateurs d'Internet établi par l’article XI de ces statuts; et
f. Un agent de liaison nommé par le groupe de travail de génie Internet.
2. Conformément aux clauses de l’article de transition de ces statuts, les agents de liaison sans droit de vote doivent exercer des mandats prenant effet à la clôture de chaque réunion annuelle. Chaque entité habilitée à nommer un agent de liaison sans droit de vote doit, au minimum un mois avant le début de chaque réunion annuelle, remettre au secrétaire de l'ICANN une note écrite de sa nomination.
3. Les agents de liaison sans droit de vote doivent faire office de volontaires, sans autre compensation que le remboursement de certains frais.
4. Chaque agent de liaison sans droit de vote peut être renommé et doit rester en poste jusqu’à ce qu’un successeur ait été nommé ou jusqu’à ce que l’agent de liaison renouvelle son contrat ou soit relevé de ses fonctions conformément à ces statuts.
5. Les agents de liaison sans droit de vote doivent être habilités à assister aux réunions du conseil, participer aux discussions et délibérations du conseil d’administration, et avoir accès (sous des conditions établies par le conseil d’administration) aux supports fournis aux administrateurs et utilisés dans les discussions, délibérations et réunions du conseil d’administration, mais ne doivent en revanche bénéficier d’aucun droit ni privilège d’administrateurs. Les agents de liaison sans droit de vote doivent être habilités (sous des conditions établies par le conseil d’administration) à utiliser tout support qui leur est fourni en accord avec cette section pour pouvoir consulter leur comité ou organisation respective.
Section 10. DÉMISSION D’UN ADMINISTRATEUR OU D’UN AGENT DE LIAISON SANS DROIT DE VOTE
Conformément à la section 5226 du CNPBCL, tout administrateur ou agent de liaison sans droit de vote peut démissionner à tout moment, soit par annonce orale lors d’une réunion du conseil d’administration (suivie d’une annonce écrite au secrétaire de l’ICANN) soit par voie écrite au président ou secrétaire de l’ICANN. Cette démission entrera en vigueur au moment spécifié, et, sauf toute spécification contraire, l’acceptation de cette démission ne sera pas nécessaire pour la rendre effective. Le successeur doit être choisi conformément à la section 12 de cet article.
Section 11. RÉVOCATION D’UN ADMINISTRATEUR OU D’UN AGENT DE LIAISON SANS DROIT DE VOTE
1. Tout administrateur peut être révoqué, suivant l’annonce qui lui a été transmise et, sur décision de l’organisme de soutien, à la majorité des trois-quarts (3/4) du vote de tous les administrateurs sous condition toutefois que l’administrateur faisant l’objet de la révocation ne soit pas habilité à voter sur cette décision ni considéré comme membre votant du conseil d'administration lors du vote aux trois-quarts(3/4) requis ; et à condition également que chaque vote visant à révoquer un administrateur soit un vote séparé sur la seule question de la révocation de ce administrateur en particulier.
2. A l’exception de l’agent de liaison sans droit de vote nommé par le comité consultatif gouvernemental, tout agent de liaison sans droit de vote peut être révoqué, après notification à ce dernier ainsi qu’à l’organisme via lequel l’agent de liaison a été choisi, à la majorité des trois-quarts (3 /4) du vote de l’ensemble des administrateurs si l’organisme de sélection échoue à révoquer promptement cet agent de liaison après cette notification. Le conseil d’administration peut exiger du comité consultatif gouvernemental le remplacement de l’agent de liaison sans droit de vote nommé par le comité si le conseil d’administration, par un vote aux trois-quarts(3/4) de la majorité de tous les administrateurs, décide que cette action est appropriée.
1. Une ou plusieurs vacances au conseil d’administration doivent être établies en cas de décès, démission ou révocation de tout administrateur, si le nombre autorisé d’administrateurs est supérieur à la normale ; si un administrateur a été jugé irresponsable par une décision finale de cour, responsable de félonie, incarcéré pendant plus de 90 jours à la suite d’une peine purgée ou encore qu’il a été déclaré, par un ordre final ou jugement d'une cour, responsable d’une fraude sous les sections 5230 et sous-sections du CNPBCL. Toute vacance survenant dans le conseil d’administration doit être pourvue par le comité de nomination, à moins (a) que ce administrateur ait été sélectionné par un organisme de soutien, auquel cas cette vacance doit être pourvue par cet organisme de soutien ; ou (b) que l administrateur ait occupé la fonction de président, et dans ce cas, la vacance doit être pourvue conformément aux clauses de l’article XIII de ces statuts. L’organe chargé de la sélection doit remettre une note écrite au sécretaire de l’ICANN faisant part de ses nominations pour pourvoir lesdites vacances. Un administrateur sélectionné pour pourvoir une vacance au conseil d’administration doit occuper la fonction pendant le mandat non-expiré de son prédécesseur et ce jusqu'à ce qu'un successeur ait été sélectionné et qualifié. Aucune réduction du nombre autorisé d’administrateurs ne doit avoir pour effet la révocation d’un administrateur avant que son mandat ne vienne à expiration.
2. Les organismes en charge de la sélection des agents de liaison n’ayant pas le droit de vote et identifiés dans la section 9 de cet article doivent déterminer l’existence de toute vacance pour ces fonctions et s’assurer de les pourvoir. Ils doivent remettre une note écrite au secrétaire de l’ICANN faisant part de leurs nominations pour pourvoir ces vacances.
Section 13. RÉUNIONS ANNUELLES
Des réunions annuelles de l’ICANN doivent être tenues dans le but d'élire les membres et de traiter toute autre affaire survenant avant la réunion. Toutes les réunions annuelles de l'ICANN se tiendront dans le bureau principal de l'ICANN ou à tout autre endroit approprié au moment et à la convenance du conseil d’administration, à condition que toute réunion annuelle soit organisée dans les 14 mois suivant la toute dernière réunion annuelle. Si le conseil d’administration l’estime pratique, la réunion annuelle pourrait être diffusée en temps réel sur Internet via des vidéos archivées et formats audio.
Section 14. RÉUNIONS RÉGULIÈRES
Les réunions régulières du conseil d’administration devront se tenir aux dates qu’il aura indiquées. En l’absence de toute autre spécification, les réunions régulières se tiendront dans le bureau principal de l’ICANN.
Section 15. RÉUNIONS EXTRAORDINAIRES
Les réunions extraordinaires du conseil d'administration doivent être sollicitées ou tenues à la demande d’un quart (1/4) des membres du conseil d’administration, du président du conseil d'administration ou du président. Toute demande concernant la mise en place d’une réunion extraordinaire doit être formulée par le secrétaire de l’ICANN. En l’absence de toute autre spécification, les réunions extraordinaires se tiendront dans le bureau principal de l’ICANN.
Section 16. NOTIFICATION DES RÉUNIONS
Une notification du jour et de l’endroit de toutes les réunions doit être remise personnellement, via téléphone ou courrier électronique, à chaque administrateur et agent de liaison sans droit de vote, ou envoyée en courrier prioritaire (par avion pour les adresses en dehors des Etats-Unis) ou télécopie, franco de port, à chaque administrateur et agent de liaison sans droit de vote à l’adresse de l’administrateur ou de l’agent de liaison sans droit de vote, comme cela est indiqué dans les registres de l’ICANN. Dans le cas où la notification est adressée par courrier, elle doit être postée aux États-Unis au minimum quatorze (14) jours avant la tenue de la réunion. Dans le cas où la notification est délivrée personnellement, par téléphone, télécopie, ou courrier electronique, elle devra être délivrée personnellement, par téléphone, télécopie ou courrier électronique au minimum quarante-huit jours (48) avant la tenue de la réunion. Sauf toute disposition contraire dans cette section, la notification d'une réunion ne doit être remise à aucun administrateur ayant renoncé ou consenti par écrit à la tenue de la réunion ou ayant signé une approbation des minutes, avant ou après la réunion ou encore ayant décidé d’assister à la réunion sans contester, avant celle-ci ou à l’ouverture, l’absence de notification de cet administrateur. De tels renonciations, consentements et approbations doivent être incorporés aux documents corporatifs ou aux minutes des réunions.
Lors de toutes les réunions annuelles, régulières ou extraordinaires du conseil d’administration, une majorité de l'ensemble des administrateurs alors en fonction doit constituer un quorum pour le traitement des activités et l'action d'une majorité des administrateurs présents aux réunions pour lesquelles il existe un quorum doit constituer l'action du conseil d'administration, sauf stipulation contraire mentionnée ci-joint ou par la loi. Si la constitution d’un quorum est impossible lors d’une réunion du conseil d’administration, les administrateurs présents doivent parfois procéder à l’ajournement de la réunion à un(e) autre endroit, heure ou date. Si la réunion est ajournée pendant plus de vingt-quatre (24) heures, une notification doit être remise aux administrateurs absents au moment de l’ajournement.
Section 18. ACTION PAR RÉUNION TELEPHONIQUE OU TOUT AUTRE MOYEN DE COMMUNICATION
Les membres du conseil d’administration ou de tout autre comité du conseil d’administration doivent participer à une réunion du conseil d’administration ou du comité du conseil d’administration via (i) une conférence téléphonique ou tout autre moyen de communication, à condition que tous les administrateurs prenant part à une telle réunion puissent parler et s’entendre les uns les autres, ou via (ii) des écrans de communication électronique ou tout autre moyen de communication, à condition que (a) tous les administrateurs prenant part à une telle réunion puissent parler et s’entendre les uns les autres, (b) qu’ils aient tous les moyens de participer activement à toutes les affaires auprès du conseil d’administration ou du comité de ce conseil d’administration, et (c) que l’ICANN adopte et mette en place des moyens de vérifier (x) qu'une personne participant à une telle réunion exerce la fonction d’administrateur ou soit effectivement habilitée à participer à la réunion et (y) que tou(te)s les mesures, ou votes du conseil d'administration ou du comité d'administration soient uniquement considérés ou exprimés par les membres du conseil d’administration ou du comité du conseil d'administration et non par des personnes non-membres. La participation à une réunion conformément à cette section revient à assister en personne à une telle réunion. L’ICANN doit mettre à disposition des membres du conseil d 'administration, sur le lieu de chaque réunion du conseil d'administration, les équipements de télécommunication nécessaires pour leur permettre de participer par téléphone.
Section 19. ACTION SANS RÉUNION
Toute action requise ou autorisée par le conseil d’administration ou un comité du conseil d’administration peut être prise sans réunion, à condition que tous les administrateurs habilités à voter formulent individuellement ou collectivement par écrit leur consentement vis-à-vis d’une telle action. Un tel document écrit dispose de la même vigueur et du même effet qu'un vote à l'unanimité des administrateurs Ces consentements écrits ou autres consentements doivent être incorporés aux minutes des procédures du conseil d’administration.
Section 20. COURRIER ÉLECTRONIQUE
Si la loi en vigueur le permet, la communication par courrier électronique doit être considérée équivalente à toute autre communication ne nécessitant pas d’être formulée par écrit. L’ICANN doit prendre des mesures jugées appropriées aux circonstances pour s'assurer de l'authenticité des communications établies par courrier électronique.
Section 21. DROITS D’INSPECTION
Tout administrateur doit avoir le droit, dans un délai raisonnable, d’inspecter et copier tous les livres, registres et documents en tout genre ainsi que les propriétés physiques de l'ICANN. L’ICANN doit établir des procédures adaptées pour se protéger contre la divulgation inappropriée d'informations confidentielles.
Les membres du comité ne doivent recevoir aucune compensation du fait de leurs services rendus en tant qu’administrateurs. Le conseil d’administration peut toutefois autoriser le remboursement de dépenses réelles et nécessaires engagées par les administrateurs et les agents de liaison sans droit de vote dans le cadre de leur fonction.
Section 23. PRÉSOMPTION D’ACCEPTATION
Il est supposé qu’un administrateur présent à une réunion du conseil d’administration au cours de laquelle une action est prise au sujet de toute affaire relative à la société accepte cette action, à moins que son opposition ou abstention soit mentionnée dans les minutes de la réunion, ou qu’il formule par écrit son opposition ou abstention à une telle action à la personne agissant en tant que secrétaire de la réunion avant le début de l’ajournement, ou fasse suivre son opposition ou abstention par courrier recommandé au secrétaire de l’ICANN immédiatement après l’ajournement de la réunion. Un tel droit d’opposition ou d'abstention ne doit pas être applicable f ayant voté en faveur de l’action.
ARTICLE VII : COMITÉ DE NOMINATION
Il doit exister un comité de nomination de l'ICANN, en charge de la sélection de tous les administrateurs de l'ICANN, à l'exception du président et des administrateurs sélectionnés par les organismes de soutien de l'ICANN, ainsi que de toutes les autres sélections spécifiées dans ces statuts.
Le comité de nomination doit comprendre :
1. Un président sans droit de vote, nommé par le conseil d'administration de l'ICANN .
2. Le dernier président en date du comité de nomination, agissant en tant que conseiller sans droit de vote ;
3. Un agent de liaison sans droit de vote nommé par le comité consultatif du serveur racine établi par l’article XI de ces statuts;
4. Un agent de liaison sans droit de vote nommé par le comité consultatif sur la sécurité et la stabilité établi par l’article XI de ces statuts;
5. Un agent de liaison sans droit de vote nommé par le comité consultatif gouvernemental;
6. Conformément aux clauses de ces statuts, cinq délégués ayant droit de vote, sélectionnés par le comité consultatif des utilisateurs d’Internet établi par l’article XI de ces statuts;
7. Deux délégués ayant droit de vote, avec l’un d’entre eux représentant un petit nombre d’utilisateurs commerciaux et le deuxième représentant un grand nombre d’utilisateurs commerciaux, sélectionnés par le collège des utilisateurs d’internet de l’organisme de soutien des noms génériques établi par l’article X de ces statuts;
8. Un délégué ayant le droit de vote sélectionné par les entités suivantes :
a. Le collège des registres de gTLD de l’organisme de soutien des noms génériques, établi par l’article X de ces statuts;
b. Le collège des registres gTLD de l’organisme de soutien des noms génériques, établi par l’article X de ces statuts;
c. Le conseil de l’organisme de soutien des noms géographiques établi par l’article IX de ces statuts;
d. Le collège regroupant les fournisseurs d’accès à Internet de l’organisme de soutien des noms génériques établi par l’article X de ces statuts;
e. Le collège représentant les intérêts de la propriété intellectuelle de l’organisme de soutien des noms génériques, établi selon l’article X de ces statuts;
Le conseil de l’organisme de soutien des adresses établi par l’article VIII de ces statuts;
g. Une entité désignée par le conseil d’administration pour représenter les organisations académiques et similaires ;
h. Des groupes de société civile et de consommateurs sélectionnés par le collège regroupant les utilisateurs non-commerciaux de l’organisme de soutien des noms génériques, établi par l’article X de ces statuts;
i. Le groupe de travail de génie Internet ; et
j. Le groupe de liaison technique de l’ICANN, établi par l’article XI-A de ces statuts; et
9. Un assistant du président sans droit de vote, qui peut être nommé par le président, à sa seule discrétion, pour exercer sa fonction pendant une partie ou tout le mandat du président. L’assistant du président ne peut pas être une personne également membre du même comité de nomination. L’assistant du président doit assister le président dans l’exercice de sa fonction, mais ne doit en aucun cas agir, temporairement ou autre, à sa place.
Conformément aux clauses de l’article de transition de ces statuts:
1. Tout délégué ayant droit de vote doit exercer sa fonction pendant un mandat d’une durée d’un an. Un délégué peut exercer au maximum deux mandats consécutifs d’une durée d’un an chacun, et attendre au minimum deux ans pour être à nouveau éligible.
2. Le mandat régulier de chaque délégué ayant droit de vote doit prendre effet à la clôture de la réunion annuelle de l’ICANN et se terminer à la clôture de la réunion annuelle suivante de l’ICANN.
3. Les agents de liaison sans droit de vote doivent exercer leur fonction au cours du mandat indiqué par l'entité à l'origine de leur nomination. Le président, son prédécesseur qui agit alors en tant que conseiller, ainsi que son assistant doivent exercer leurs fonctions jusqu'à la clôture de la réunion annuelle suivante de l'ICANN.
4. Les vacances aux postes de délégués, d’agents de liaison sans droit de vote, ou de président doivent être pourvues par l'entité habilitée à la sélection des délégués, agents de liaison sans droit de vote, ou président concernés. Une vacance au poste de conseiller sans droit de vote (prédécesseur direct du président) doit être pourvue via le conseil d’administration par toute personne ayant déjà exercé une fonction au conseil d'administration ou au comité de nomination. Une vacance au poste d’associé du président doit être pourvue par le président, conformément aux critères établis par la section 2(9) de cet Article.
5. L’existence de toute vacance ne doit pas empêcher le comité de nomination d'assumer les responsabilités mentionnées dans ces statuts.
Section 4. CRITÈRES POUR LA SÉLECTION DES DÉLÉGUÉS DU COMITÉ DE NOMINATION
Les délégués du Comité de nomination de l’ICANN doivent être :
1. Des personnes réputées pour leur intégrité, objectivité et intelligence, ainsi que pour leur bon jugement, leur ouverture d’esprit ainsi que leur expérience et leurs compétences en matière de prise de décision au sein de grands groupes collégiaux ;
2. Des personnes ayant des contacts variés, une vaste expérience dans la communauté Internet, et impliquées dans le succès de l'ICANN ;
3. Des personnes, bénéficiant de la confiance de l’organe de sélection en matière de consultation, et qui prendront acte des avis dans le cadre de leurs responsabilités ;
4. Des personnes neutres et objectives, sans aucun engagement personnel fixe envers des individus, organisations ou objectifs commerciaux particuliers dans l’exercice de leurs responsabilités au sein du comité de nomination ;
5. Des personnes ayant compris la mission de l’ICANN, l’impact potentiel de ses décisions sur l’ensemble de la communauté Internet au sens large, et qui soient prêtes à s’engager volontairement, sans autre compensation que le remboursement de certains frais ; et
6. Des personnes capables de travailler et de communiquer en anglais à l’écrit et à l’oral.
Dans le cadre de ses responsabilités pour sélectionner les membres du conseil d’administration de l’ICANN (ainsi que pour les sélections de tout autre organe de l’ICANN dont le comité de nomination est responsable, conformément à ces statuts), le comité de nomination doit prendre en considération l’adhésion continue des membres du conseil d’administration (et de tout autre organe), et chercher à garantir que les personnes sélectionnées pour pourvoir les vacances au conseil d’administration de l’ICANN (et de tout autre organe de la sorte) doivent, dans la mesure du possible et conformément aux autres critères exigés dans la section 4 de cet article, faire des sélections à partir de la valeur principale 4 de l'article I, section 2 .
Section 6. SUPPORT ADMINISTRATIF ET OPÉRATIONNEL
L'ICANN doit fournir au comité de nomination un support administratif et opérationnel nécessaire pour l'exercice de ses responsabilités.
S’il l’estime nécessaire, le comité de nomination doit adopter des procédures de fonctionnement qui doivent être publiées sur le site Web.
Section 8. INÉLIGIBILITÉ POUR LA SÉLECTION PAR LE COMITÉ DE NOMINATION
Toute personne exerçant une quelconque fonction au sein du comité de nomination ne peut en aucun cas être éligible à la sélection d’une quelconque position au conseil d’administration ou de tout autre organe de l’ICANN ayant une ou plusieurs fonctions que le comité de nomination est en charge de pourvoir, avant la clôture d’une réunion annuelle de l’ICANN qui coïncide avec, ou survient après la fin du service de cette personne au comité de nomination.
Section 9. INÉLIGIBILITÉ POUR L'EXERCICE AU COMITÉ DE NOMINATION
Toute personne travaillant en tant qu’employé ou consultant de l’ICANN (y compris le médiateur) ne peut simultanément exercer une fonction aux postes du comité de nomination décrites dans la section 2 de cet article.
ARTICLE VIII : ORGANISME DE SOUTIEN DES ADRESSES
1. L’organisme de soutien des adresses doit conseiller le conseil d'administration de l'ICANN sur les questions politiques relatives au fonctionnement, à l'allocation et la gestion des adresses Internet.
2. L’organisme de soutien des adresses doit être une entité établie par le protocole d’accord conclu le 21 octobre 2004 entre l’ICANN et le NRO (Number Resource Organization), organisation des registres Internet régionaux actuels.
Section 2. CONSEIL D’ADRESSAGE
1. L’ASO (organisme de soutien des adresses) doit avoir un conseil d’adressage, comprenant les membres du conseil du NRO .
2. Le conseil d’adressage doit sélectionner les administrateurs des sièges au conseil d’administration désignés pour les pourvoir par l'ASO.
ARTICLE IX : ORGANISME DE SOUTIEN DES NOMS GÉOGRAPHIQUES
Il doit exister un organe de développement de la politique appelé organisme de soutien des noms géographiques (ccNSO) chargé de :
1. développer et proposer au conseil d’administration de l’ICANN des politiques mondiales relatives aux domaines de codes de pays de premier niveau ;
2. Promouvoir un consensus au sein de la communauté du ccNSO, notamment concernant les activités des ccTLD relatives aux noms ; et
3. collaborer avec d’autres organismes de support, comités et collèges de l’ICANN.
Les politiques appliquées aux membres du ccNSO en vertu de leur composition sont uniquement celles établies conformément aux sections 4.10 et 4.11 de cet article. Toutefois, le ccNSO doit également s’engager dans d’autres activités autorisées par ses membres. L’observation des résultats de ces activités sera facultative et les activités doivent consister à : chercher à développer bénévolement de meilleures pratiques pour les responsables ccTLD, participer à la création de compétences au sein de la communauté mondiale des responsables ccTLD, et améliorer la coopération opérationnelle et technique parmi les responsables ccTLD.
Le ccNSO doit être constitué de (i) responsables ccTLD qui ont accepté par écrit d’être membres du ccNSO (voir la section 4(2) de cet article) et (ii) d’un conseil du ccNSO responsable de la gestion du processus d’élaboration de la politique du ccNSO.
1. Le conseil du ccNSO doit être constitué de (a) trois membres du conseil du ccNSO sélectionnés par les membres du ccNSO au sein de chaque région géographique de l’ICANN , comme décrit dans les alinéas (7) à (9) de la section 4 de cet article; (b) trois membres du conseil du ccNSO sélectionnés par le comité de nomination de l’ICANN ; (c) des agents de liaison, comme spécifié dans le paragraphe 2 de cette section; et (iv) des observateurs, comme mentionné dans le paragraphe 3 de cette section.
2. Il doit y avoir un agent de liaison du conseil du ccNSO provenant de chacun des organismes suivants, dans la mesure où ces derniers choisissent de nommer un tel agent de liaison : (a) le comité consultatif gouvernemental ; (b) l’ALAC ( Comité consultatif des utilisateurs d’Internet) ; et (c) chacune des organismes régionaux décrits dans la section 5 de cet article. Ces agents de liaison ne doivent pas être membres ou habilités à voter au conseil du ccNSO, mais doivent cependant être habilités à participer sur un pied d’égalité avec les membres du conseil du ccNSO. Les nominations des agents de liaison doivent être effectuées en soumettant une note écrite au secrétaire de l’ICANN, ainsi qu’une copie de la notification au président du conseil du ccNSO, et doivent par ailleurs concerner le mandat désigné par l’organisme de nomination comme spécifié dans la note écrite. L'organisme de nomination peut révoquer ou remplacer son agent de liaison à tout moment en remettant une note écrite au secrétaire de l’ICANN faisant part de la révocation ou du remplacement, et en adressant par ailleurs une copie de cette notification au président du conseil du ccNSO.
3. Le conseil du ccNSO doit s'entendre avec le conseil de tout autre organisme de soutien de l’ICANN pour changer les observateurs. Ces observateurs ne doivent pas être membres ou habilités à voter au conseil du ccNSO, mais doivent cependant être habilités à participer sur un pied d’égalité avec les membres du conseil du ccNSO. Le conseil de nomination peut, à tout moment, désigner son observateur (ou révoquer ou changer la désignation de celui-ci) au conseil du ccNCO, à condition de remettre une note écrite au secrétaire de l’ICANN ainsi qu’une copie de cette notification au président du conseil du ccNSO.
4. Conformément aux clauses de l’article de transition de ces statuts: (a) le mandat régulier de chaque membre du conseil du ccNSO doit généralement prendre effet à la clôture de chaque réunion annuelle de l'ICANN et prendre ensuite fin à la clôture de la troisième réunion annuelle de l’ICANN ; (b) les mandats réguliers des trois membres du conseil du ccNSO sélectionnés par les membres du ccNSO au sein de chaque région géographique de l’ICANN doivent généralement être échelonnés de manière à ce que le mandat d'un des membres prenne effet au cours d'une année divisible par trois, celui d'un deuxième membre dans la première année suivant une année divisible par trois, et qu'enfin, le mandat du troisième membre prenne effet au cours de la deuxième année suivant une année divisible par trois ; et (c) les mandats des trois membres du conseil du ccNSO sélectionnés par le comité de nomination doivent généralement être échelonnés de la même manière. Chaque membre du conseil du ccNSO peut être renommé et doit rester en poste jusqu’à ce qu’un successeur ait été nommé ou jusqu’à ce que le membre renouvelle son contrat ou soit relevé de ses fonctions conformément à ces statuts.
5. Un membre du conseil du ccNSO peut démissionner à tout moment en remettant une note écrite au secrétaire de l’ICANN, et en adressant par ailleurs une copie de cette notification au président du conseil du ccNSO.
6. Les membres du conseil du ccNSO peuvent être révoqués en cas de trois absences consécutives au conseil du ccNSO en l’absence d’une justification suffisante ou en cas de comportement tout à fait inapproprié, selon le vote d'au moins 66% de tous les membres du conseil du ccNSO.
7. Il peut y avoir une vacance au conseil du ccNSO en cas de décès, démission ou révocation de tout membre du conseil du ccNSO. Les vacances aux postes des trois membres sélectionnés par le comité de nomination doivent être pourvues pour le mandat non-expiré spécifié par le comité de nomination, en remettant au secrétaire de l'ICANN une note écrire de sa sélection, ainsi qu’une copie de cette notification adressée au président du conseil du ccNSO. Les vacances aux postes des membres du conseil du ccNSO sélectionnés par les membres du ccNSO doivent être pourvues pour le mandat non-expiré de la procédure décrite dans les alinéas (7) à (9) de la section 4 de cet article..
8. La fonction du conseil du ccNSO consiste à administrer et coordonner les activités du ccNSO (y compris coordonner les réunions, tout comme la réunion annuelle, des membres du ccNSO comme stipulé dans la section 4(6) de cet article) et gérer le développement de politique de recommandations, conformément à la section 6 de cet article. Le conseil du ccNSO doit également assumer d’autres rôles, d’après les décisions ponctuelles des membres du ccNSO.
9. Le conseil du ccNSO est chargé des sélections pour pourvoir les sièges 11 et 12 au conseil d'administration, par le biais d’un vote par écrit ou de toute autre action lors d’une réunion ; toute sélection doit obtenir les votes affirmatifs de la majorité de l'ensemble des membres du conseil du ccNSO alors en fonction. La notification des sélections du conseil du ccNSO doit être remise par écrit par le président du conseil du ccNSO au secrétaire de l’ICANN, conformément à l’article VI, sections 8(4) et 12(1).
10. Le Conseil du ccNSO doit, selon sa convenance, choisir parmi ses membres le président du conseil du ccNSO ainsi que le ou les vice(s) président(s). Les sélections du président et du / des vice(s) président(s) au conseil du ccNSO doivent être efféctuées par vote écrit ou action lors d’une réunion ; toute sélection doit obtenir les votes positifs de la majorité de l’ensemble des membres du conseil du ccNSO, alors en fonction. Le mandat du président et du / des vice(s) président(s) du conseil du ccNSO doit prendre effet au moment où, ou avant que la sélection ne soit effectuée, comme le spécifie le conseil du ccNSO. Le président ou le / les vice(s) président(s) du conseil du ccNSO peut être révoqué par la même procédure que celle utilisée pour la sélection.
11. S’il l’estime nécessaire, le conseil du ccNSO, dirigé par les membres du ccNSO, doit adopter ces règles et procédures pour le ccNSO, à condition toutefois qu’elles soient conformes à ces statuts. Les règles concernant l’adhésion au ccNSO et les procédures de fonctionnement adoptées par le conseil du ccNSO doivent être publiées sur le site Web.
12. A l’exception des spécifications particulières des paragraphes 9 et 10 de cette section, le conseil du ccNSO doit intervenir lors de réunions. Le conseil du ccNSO doit tenir des réunions régulières qu’il aura préalablement programmées, à raison de quatre par an au minimum. A la discrétion du conseil du ccNSO, les réunions doivent être tenues en personne ou par tout autre moyen, à condition que les membres du conseil du ccNSO soient autorisés à participer par le biais d’au moins l’un des moyens décrits dans le paragraphe 14 de cette section. Sauf si une majorité de votes des membres du conseil du ccNSO présents a établi qu'une session en huis clos était appropriée, les réunions physiques doivent être ouvertes à toute personne intéressée et désireuse d’y assister. Dans la mesure du possible, les réunions du conseil du ccNSO peuvent être tenues en conjonction avec des réunions du conseil d’administration, ou d’un ou plusieurs des autres organismes de soutien de l’ICANN.
13. Une notification de la date ainsi que du lieu (et des informations concernant les moyens de participation autre que la présence personnelle) de toutes les réunions du conseil du ccNSO doit être remise à chaque membre du conseil du ccNSO, agent de liaison et observateur, par courrier électronique, téléphone, télécopie, ou encore notification papier délivrée personnellement ou postée. Dans le cas où la notification est adressée par courrier, elle doit être envoyée au minimum dans les 21 jours précédant le jour de la réunion. Dans le cas où la notification est remise personnellement, par téléphone, télécopie, ou courrier electronique, elle doit être délivrée au minimum dans les sept jours précédant le jour de la réunion. Une notification de la réunion, et dans la mesure du possible, un ordre du jour pour la réunion devront être publiés au minimum dans les sept jours précédant chaque réunion du conseil du ccNSO (ou le plus tôt possible).
14. Les membres du conseil du ccNSO peuvent participer à une réunion du conseil du ccNSO en s'y rendant personnellement, ou par le biais d'une communication électronique (comme le téléphone ou la vidéo-conférence), à condition (a) qu’ils puissent tous parler et s'entendre les uns les autres, (b) qu’ils aient tous les mêmes moyens de participer activement à toutes les questions auprès du conseil du ccNSO, et (c) qu'il soit possible de vérifier, par des moyens raisonnables, l'identité des membres du conseil du ccNSO participant à la réunions et leurs votes. Una majorité des membres du conseil du ccNSO (c'est-à-dire ceux habilités à voter) alors en fonction doit constituer un quorum pour le traitement des activités, et les actes d’un vote majoritaire des membres du conseil du ccNSO présent à toute réunion au cours de laquelle il existe un quorum doivent constituer des actes du conseil du ccNSO, sauf toute spécification contraire dans ces statuts. Le conseil du ccNSO doit remettre les minutes de ses réunions au secrétaire de l’ICANN, qui doit faire en sorte qu'elles soient publiées sur le site Web, si possible directement après la réunion ou au maximum dans les 21 jours suivant la réunion.
1. Le ccNSO doit être constitué de responsables du ccTLD. Tout responsable ccTLD remplissant les critères d’adhésion précisés dans le paragraphe 2 de cette section doit être habilité à devenir membre du ccNSO. Dans le cadre de cet article, on entend par « responsable ccTLD », l’organisation ou entité responsable de la gestion d’un code ISO 3166 de noms de domaine de premier niveau géographique et désignée dans la base de données de l’IANA sous l’intitulé actuel d’« Organisme de soutien », ou sous toute autre variante future, pour ce domaine de premier niveau géographique.
2. Tout responsable ccTLD devient membre du ccNSO en exprimant sa candidature à une personne désignée par le conseil du ccNSO pour recevoir les différentes candidatures. Conformément aux clauses de l’article de transition de ces statuts, la candidature doit être formulée par écrit et selon le modèle indiqué par le conseil du ccNSO. La candidature doit inclure la reconnaissance du responsable ccTLD pour le rôle du ccNSO au sein de la structure de l'ICANN ainsi que l'accord du responsable ccTLD concernant la durée de son adhésion au ccNSO, (a) l’adhésion aux règles du ccNSO, y compris aux règles d’adhésion, (b) le respect des politiques développées et recommandées par le ccNSO et adoptées par le conseil d’administration, comme décrit dans les paragraphes 10 et 11 de cette section, et (c) le règlement des frais d’adhésion établis par le conseil du ccNSO dans la section 7(3) de cet article. Un membre du ccNSO peut, à tout moment, résilier son adhésion en remettant une note écrite à une personne désignée par le conseil du ccNSO pour recevoir les notifications de résiliation. Lors de sa résiliation, le responsable ccTLD cesse (a) d’adhérer aux règles du ccNSO, y compris à celles concernant l'adhésion, (b) de respecter les politiques développées et recommandées par le ccNSO et adoptées par le conseil d’administration, comme décrit dans les paragraphes 10 et 11 de cette section, et de (c) payer les frais d’adhésion au ccNSO établis par le ccNSO dans la section 7(3) de cet article. En l’absence de nomination par le Conseil du ccNSO d’une personne chargée de recevoir les candidatures et notifications de résiliation, ces dernières doivent être envoyées au secrétaire de l’ICANN, qui doit avertir le conseil du ccNSO de leur réception.
3. Aucune adhésion au ccNSO ou à tout organisme régional décrit dans la section 5 de cet article ne doit constituer une condition pour l’accès ou l’inscription à la base de données de l’IANA. Toute relation individuelle entre un responsable ccTLD et l'ICANN ou la réception de services de l'IANA par le responsable ccTLD n’influence en aucun cas l'adhésion au ccNSO.
4. Les régions géographiques ccTLD doivent être telles que stipulées dans l’article VI, section 5 de ces statuts. Dans le cadre de cet article, les responsable ccTLD dans une région géographique membres du ccNSO sont désignés comme étant des membres du ccNSO « appartenant à » la région géographique, quel que soit l'emplacement physique du responsable ccTLD. Dans le cas où la région géographique d’un membre du ccNSO n'est pas clairement définie, le membre ccTLD doit lui-même choisir, conformément aux procédures adoptées par le conseil du ccNSO.
5. Chaque responsable ccTLD doit désigner par écrit une personne, organisation ou entité chargée de le représenter. En l’absence d’une telle désignation, le responsable ccTLD doit être représenté par la personne, l’organisation ou entité répertoriée comme contact administratif dans la base de données de l’IANA.
6. Une réunion annuelle des membres du ccNSO doit être tenue et coordonnée par le conseil du ccNSO. Les réunions annuelles doivent être ouvertes à tous, et les responsables ccTLD qui ne sont pas membres du ccNSO ainsi que tous les autres non-membres du CCNSO doivent également avoir la possibilité de participer à la réunion. Les réunions annuelles des membres du ccNSO doivent être, si possible, tenues en personne et peuvent avoir lieu en conjonction avec des réunions du conseil d'administration, ou d'un ou plusieurs autres organismes de soutien de l'ICANN.
7. Les membres du conseil du ccNSO sélectionnés par les membres du ccNSO de chaque région géographique (voir la section 3(1)(a) de cet article) doivent être sélectionnés via nomination, et, si nécessaire, via un vote, par les membres du conseil du ccNSO au sein de cette région géographique. Au minimum dans les 90 jours précédant la fin du mandat régulier de tout membre sélectionné du ccNSO au conseil du ccNSO, ou dans le cas d'une vacance à un siège d'un membre du conseil du ccNSO, le conseil du ccNSO doit programmer une nomination ainsi qu'un vote, dont la notification sera à la fois envoyée à tous les membres du ccNSO à l'intérieur de la région géographique et publiée sur le site Web.
8. Tout membre du ccNSO doit nommer un individu pour agir en tant que membre du conseil du ccNSO représentant la région géographique du membre du ccNSO. Les nominations doivent être secondées par un autre membre du ccNSO provenant de la même région géographique. En acceptant leur nomination, les individus nommés au conseil du ccNSO acceptent de soutenir les politiques engagées par les membres du ccNSO.
9. Si à la fin des nominations, il y a autant de candidats nommés (with seconds and acceptances) dans une région géographique particulière que de sièges disponibles au conseil du ccNSO pour cette région géographique, alors les candidats nommés doivent être sélectionnés pour exercer leurs fonctions au conseil du ccNSO. Dans le cas contraire, un vote par écrit (qui peut être par courrier électronique) doit être organisé pour sélectionner les membres du conseil du ccNSO parmi ceux nommés, avec les membres du ccNSO de la région géographique habilités à voter à travers leurs représentants désignés. Lors d’un tel vote, la majorité des membres du ccNSO dans la région géographique habilités à voter doivent constituer un quorum, et le candidat sélectionné doit obtenir les votes de la majorité des membres du ccNSO au sein de la région géographique. Le président du conseil du ccNSO doit rapidement remettre au secrétaire de l’ICANN, une note écrite de la sélection des membres du conseil du ccNSO en accord avec ce paragraphe.
10. Conformément à la clause 4(11), les politiques de l’ICANN doivent être applicables aux membres du ccNSO, en vertu de leur adhésion, dans la mesure où, et uniquement dans la mesure où, les politiques (a) traitent des questions entrant bien dans le cadre de l’ICANN conformément à l’article IX, section 6 et annexe C, et (b) ont été développées via le ccPDP, comme décrit dans la section 6 de cet article, et (c) recommandées comme telles par le ccNSO au conseil d'administration, et (d) sont adoptées par le conseil d'administration comme des politiques, à condition qu'elles n'entrent pas en conflit avec la loi applicable au responsable ccTLD qui doit, à tout moment, prévaloir. En outre, de telles politiques doivent être applicables à l’ICANN dans les activités ayant trait aux ccTLD.
11. Un membre du ccNSO ne doit pas être révoqué s'il fournit une déclaration au conseil du ccNSO déclarant (a) qu'une mise en place de la politique le contraindrait à enfreindre la coutume, la religion ou la politique publique (non décrite dans la loi en vigueur spécifiée dans le paragraphe 10 de cette section), et (b) que l’échec dans la mise en place de la politique n'affecterait pas les opérations ou l’interopérabilité DNS, en donnant des raisons détaillées renforçant ses arguments. Après enquête, le conseil du ccNSO fournira une réponse à la déclaration du membre du ccNSO. En cas de consensus du conseil du ccNSO contestant la déclaration, qui doit être établi par le vote de 14 membres ou plus du conseil du ccNSO, la réponse doit exprimer le désaccord du conseil du ccNSO avec la déclaration ainsi que les motifs de ce désaccord. Dans le cas contraire, la réponse doit exprimer l’approbation du conseil du ccNSO avec cette déclaration. Si le conseil du ccNSO désapprouve cette déclaration, il doit réviser la situation après une période de six mois. A la fin de cette période, le conseil du ccNSO doit conclure (a) si oui ou non la mise en place de la politique des membres du conseil du ccNSO contraindrait le membre à enfreindre la coutume, la religion ou la politique publique (non décrite dans la loi en vigueur spécifiée dans le paragraphe 10 de cette section), et (b), si oui ou non l’échec dans la mise en place de la politique affecterait les opérations ou l’interopérabilité DNS. En choisissant de désapprouver la déclaration, le conseil du ccNSO doit procéder par consensus, qui doit être établi par le vote de 14 membres ou plus du conseil du ccNSO.
Section 5. ORGANISMES RÉGIONAUX
Le conseil du ccNSO doit désigner un organisme régional pour chaque région géographique de l’ICANN, à condition que l’organisme régional soit ouvert à toute adhésion de l'ensemble des membres du ccNSO au sein de la région géographique. Les décisions visant la désignation ou re-désignation d’un organisme régional doivent obtenir 66% des votes de l’ensemble des membres du conseil du ccNSO et faire l'objet d'une révision, conformément aux procédures établies par le conseil d'administration.
Section 6. PROCESSUS D’ÉLABORATION DE POLITIQUE DE L’ICANN ET CHAMP D’ACTION
1. L’étendue du rôle du ccNSO dans l’élaboration des politiques doit être telle que spécifiée dans l'annexe C de ces statuts; toute modification du champ d’action doit être recommandée au conseil d’administration par le ccNSO via des procédures du ccPDP, et soumise à l’approbation du conseil d’administration.
2. En développant des politiques globales au sein du champ d’action du ccNSO et en les recommandant au conseil d‘administration, le ccNSO doit suivre le processus d’élaboration des politiques du ccNSO (ccPDP) Le ccPDP doit être, tel que spécifié dans l'annexe B de ces statuts; toute modification doit être recommandée au conseil d’administration par le ccNSO via des procédures du ccPDP, et être soumise à l’approbation du conseil d’administration.
Section 7. SOUTIEN EN PERSONNEL ET FINANCEMENT
1. Sur demande du conseil du ccNSO, un membre du personnel de l'ICANN doit être assigné à soutenir le ccNSO et être désigné comme le responsable du personnel de l'ICANN. Le conseil du ccNSO peut également désigner, aux frais du ccNSO, une autre personne pour exercer la fonction de chef d’équipe du ccNSO. Le travail du chef d’équipe du ccNSO sur des questions essentielles doit être assigné par le président du conseil du ccNSO, et doit inclure les missions de l’administrateur de la publication du ccPDP.
2. L'ICANN doit fournir, à la demande du conseil du ccNSO, un soutien administratif et opérationnel nécessaire pour l’exercice des fonctions de ce dernier. Un tel soutien ne doit pas comprendre l’obligation de l’ICANN à financer les frais de déplacement engagés par les participants du ccNSO pour se rendre à toute réunion du ccNSO ou pour toute autre raison. Le conseil du ccNSO doit prévoir, aux frais du ccNSO, un soutien administratif et opérationnel en plus de ou comme alternative au soutien fourni par l'ICANN.
3. Le conseil du ccNSO doit établir les frais que les membres du ccNSO devront payer, afin de rembourser les dépenses du ccNSO, comme décrit dans les paragraphes 1 et 2 de cette section, et approuvé par les membres du ccNSO.
4. Les notifications écrites remises au secrétaire de l’ICANN, conformément à cet article, doivent être conservées de manière permanente, et mises à disposition, sur demande, pour être révisées par le conseil du ccNSO. Le secrétaire de l’ ICANN doit également mettre à jour la liste des membres du ccNSO, qui doit comprendre le nom de chaque représentant désigné par le responsable ccTLD et être publiée sur le site Web.
ARTICLE X : ORGANISME DE SOUTIEN DES NOMS GÉNÉRIQUES
Il doit y avoir un organe chargé de l’élaboration des politiques, appelé GNSO (organisme de soutien des noms génériques), chargé de développer et de proposer au conseil d’administration de l’ICANN des politiques substantielles ayant trait aux domaines génériques de premier niveau.
Le GNSO doit être formé de (i) divers collèges représentant des groupes particuliers de parties prenantes, comme décrit dans la section 5 de cet article ainsi que (ii) d’un conseil du GNSO, responsable de la gestion du processus d’élaboration de la politique du GNSO.
1. Conformément aux clauses de l’article de transition de ces statuts, le conseil du GNSO doit être constitué de trois représentants sélectionnés par chacun des collèges décrits dans la section 5 de cet article, et de trois personnes sélectionnées par le comité de nomination de l’ICANN. Deux représentants sélectionnés par un collège ne peuvent être citoyens du même pays, ni de pays situés dans la même région géographique. Le conseil du GNSO doit également comprendre deux agents de liaison, nommés chacun par chaque comité consultatif gouvernemental et parfois par le comité consultatif des utilisateurs d’Internet, qui ne doivent pas être membres ou être habilités à voter au conseil du GNSO, mais doivent toutefois être habilités à participer sur un pied d’égalité avec les membres du conseil du GNSO. Le comité consultatif nommé doit désigner son agent de liaison (ou révoquer ou modifier la désignation de son agent de liaison) au conseil du GNSO en remettant une note écrite au président du conseil du GNSO et au secrétaire de l’ICANN. Le conseil du GNSO doit également comprendre des observateurs, comme spécifié dans le paragraphe 9 de cette section.
2. Conformément aux clauses de l’article de transition de ces statuts: (a) le mandat régulier de chaque membre du conseil du GNSO doit prendre effet à la clôture d'une réunion annuelle de l'ICANN et terminer à la clôture de la deuxième réunion annuelle de l’ICANN ; (b) le mandat régulier d’un représentant sélectionné par chacun des collèges doit prendre effet au cours d’une année paire et celui des autres représentants sélectionnés par le collège au cours d’une année impaire ; et (c) le mandat régulier d’un des trois membres sélectionnés par le comité de nomination doit prendre effet au cours d’années paires et celui des deux autres membres sélectionnés par le comité de nomination au cours d’années impaires. Chaque membre du conseil du GNSO doit exercer ses fonctions durant son mandat régulier et ce jusqu’à ce qu'un successeur ait été sélectionné et pris ses fonctions ou encore jusqu'à ce que ce membre démissionne ou soit révoqué, conformément à ces statuts.
3. Un membre du conseil du GNSO peut démissionner à tout moment, en remettant une note écrite au secrétaire de l’ICANN. Un membre du conseil du GNSO sélectionné par un collège peut être révoqué par ce collège, conformément aux procédures qu'il a publiées. Un membre du conseil du GNSO sélectionné par le comité de nomination peut être révoqué pour une raison appuyée par un vote aux trois-quarts (3/4) (voir la section 5(2) de cet article) de l'ensemble des membres du conseil du GNSO (à l'exception du membre à révoquer), soumise à l'approbation du conseil d'administration de l'ICANN. Une vacance au Conseil du GNSO peut exister en cas de décès, démission ou révocation de tout membre ; Les vacances doivent être pourvues pour le mandat non-expiré mentionné par le comité de nomination, en remettant au secrétaire de l’ICANN une note écrite de la sélection, à moins que le membre exerçant cette fonction avant l’apparition de la vacance ait été sélectionné par un collège, auquel cas le collège doit pourvoir le mandat non-expiré, en remettant au secrétaire un note écrite de sa sélection.
4. Le conseil du GNSO est chargé de la gestion du processus d’élaborations des politiques du GNSO. Il doit adopter des procédures qui, selon lui, lui permettent d’exercer sa fonction, à condition que le conseil d'administration approuve ces procédures, et également que, jusqu’à ce qu’une quelconque modification soit recommandée par le conseil du GNSO et approuvée par le conseil d’administration, les procédures en vigueur soient introduites, comme spécifié dans la section 6 de cet article. En outre, le conseil du GNSO est chargé de gérer des forums ouverts, sous forme de listes envoyées par courrier electronique, ou d’autre façon que ce soit, pour que toute personne désireuse de contribuer au travail du GNSO puisse participer. Ces forums doivent être convenablement modérés pour garantir une attention maximale à l’activité du GNSO et minimiser les messages superficiels et abusifs.
5. À aucun moment, il ne peut y avoir au conseil du GNSO plus d’un agent, administrateur ou employé d’une société particulière ou autre organisme (y compris les filiales et membres).
6. Le conseil du ccNSO est chargé des sélections pour pourvoir les sièges 13 et 14 au conseil d'administration de l’ICANN, par le biais d’un vote par écrit ou de toute autre action lors d’une réunion ; toute sélection doit bénéficier des votes positifs de la majorité de l'ensemble des membres du conseil du GNSO. La notification des sélections du conseil du GNSO doit être remise par écrit par le président du GNSO au secrétaire de l’ICANN, conformément à l’article VI, sections 8(4) et 12(1).
7. Le conseil du GNSO doit sélectionner le président du GNSO, par le biais d’un vote écrit ou de toute autre action lors d’une réunion, pour un mandat déterminé par le conseil du GNSO, et impérativement inférieur à un an. Toute sélection doit obtenir les votes positifs d’une majorité des votes de l'ensemble des membres du conseil du GNSO.
8. A l’exception des spécifications particulières du paragraphe 6 de cette section, le conseil du GNSO doit intervenir lors de réunions. Les membres du conseil du GNSO peuvent participer à une réunion du conseil du GNSO via (i) une conférence téléphonique ou tout autre moyen de communication de la sorte, à condition que tous les membres participant à une telle réunion puissent parler et s’entendre les uns les autres ou via (ii) des écrans de communication par voie électronique ou tout autre moyen de communication, à condition que (a) tous les membres participant puissent parler et s’entendre les uns les autres, (b) qu’ils aient tous les moyens de participer activement à toutes les questions auprès du conseil du GNSO, et (c) que l’ICANN adopte et mette en place des moyens permettant de vérifier (x) qu'une personne participant à une telle réunion est effectivement membre du conseil du GNSO ou une autre personne habilitée à participer à la réunion et (y) que toutes les mesures, ou votes du conseil du GNSO soient uniquement considérés ou exprimés par les membres du conseil du GNSO et non par des personnes non-membres. Les membres habilités à s’exprimer à une majorité de l’ensemble des votes des membres du conseil du GNSO du conseil du GNSO alors en fonction doivent constituer un quorum pour le traitement des activités, et les actions d’un vote majoritaire des membres du conseil du GNSO présents à toute réunion au cours de laquelle il existe un quorum doivent constituer des actions du conseil du GNSO, sauf toute spécification contraire ci-dessous. (Voir la section 5(2) de cet article concernant le nombre de votes que les membres du conseil du GNSO peuvent exprimer.) Une notification préalable de telles réunions doit être publiée sur le site Web, si possible, dans les 7 jours précédant la réunion. Sauf lorsqu’un vote majoritaire (voir la section 5(2) de cet article) des membres du Conseil du GNSO présents juge qu'une session en huis-clos est appropriée, les réunions doivent être ouvertes à la présence physique ou électronique de toute personne intéressée. Le conseil du GNSO doit remettre les minutes de ses réunions au secrétaire de l’ICANN, qui doit faire en sorte qu'elles soient publiées sur le site Web, si possible directement après la réunion ou au maximum dans les 21 jours suivant la réunion.
9. Le conseil du GNSO peut s'entendre avec le conseil de tout autre organisme de soutien de l’ICANN pour échanger les observateurs. Ces observateurs ne doivent pas être membres ou habilités à voter au conseil du GNSO, mais doivent cependant être habilités à participer sur un pied d’égalité avec les membres du conseil du GNSO. Le conseil de nomination est chargé de désigner son observateur (ou révoquer ou changer la désignation de celui-ci) au conseil du GNSO en remettant une note écrite au président du conseil du GNSO et au secrétaire de l’ICANN.
Section 4. SOUTIEN EN PERSONNEL ET FINANCEMENT
1. Un membre du personnel de l’ICANN doit être assigné pour soutenir le GNSO, dont le travail ayant trait à des questions essentielles doit être nommé par le président du conseil du GNSO, et doit être désigné comme le chef du personnel du GNSO.
2. L’ICANN doit fournir le soutien administratif et opérationnel nécessaire au GNSO dans l’exercice de ses fonctions. Un tel soutien ne doit pas comprendre l’obligation de l’ICANN à financer les frais de déplacement engagés par les participants du GNSO pour se rendre à toute réunion du GNSO ou pour toute autre raison.
1. Les collèges auto-organisés suivants sont reconnus comme représentant un groupe spécifique et important de parties prenantes et, conformément aux clauses de l’article de transition de ces statuts,, chacun d’entre eux doit sélectionner deux représentants au conseil du GNSO :
a. Registres gTLD (représentant tous les registres gTLD sous contrat avec l’ICANN) ;
a. Bureaux d’enregistrement (représentant tous les bureaux d’enregistrement accrédités par, et sous contrat avec l’ICANN) ;
c. Fournisseurs d’accès et de services Internet (représentant toutes les entités fournissant un service Internet ainsi qu’une connectivité aux utilisateurs d’Internet) ;
d. Utilisateurs Internet à des fins commerciales (représentant à la fois une entité commerciale grande et petite d'utilisateurs Internet) ;
e. Utilisateurs non-commerciaux (représentant le panel complet des utilisateurs de l’entité non-commerciale Internet) ; et
f. Intérêts de propriété intellectuelle (représentant le panel complet des marques commerciales et autres intérêts de propriété intellectuelle ayant trait au DNS).
2. Le nombre de votes que les membres du conseil du GNSO peuvent exprimer doit être égalisé de sorte que le nombre total de votes des représentants sélectionnés par les collèges (actuellement les registres gTLD ainsi que les bureaux d'enregistrement) sous contrat avec l'ICANN les obligeant à mettre en place les politiques adoptées par l'ICANN soit égal au nombre de votes des représentants sélectionnés par les autres collèges. Initialement, chaque membre du conseil du GNSO sélectionné par les collèges regroupant les registres gTLD ou les collèges des bureaux d’enregistrement doit être habilité à exprimer deux votes, et tous les autres membres (y compris ceux sélectionnés par le comité de nomination) doivent être habilités à n’en exprimer qu’un. En cas de changement dans les collèges habilités à sélectionner les membres électeurs du conseil du GNSO, le conseil d’administration doit réviser le changement de circonstances et, par résolution, réviser la procédure pour l’égalisation des votes, conformément au paragraphe 2.
3. Chaque collège défini dans le paragraphe 1 de cette section conservera sa reconnaissance et, de fait, son habilité à sélectionner les représentants du conseil du GNSO, tant que cela représente les intérêts globaux des communautés de parties prenantes qu'il prétend représenter, et doit également, dans la mesure du possible, opérer, de manière ouverte, transparente, et en conformité avec les procédures désignées pour garantir l’équité. Aucun individu ou entité ne doit être exclu de participer à un collège uniquement du fait de sa participation à un autre collège.
4. Tout groupe d’individus ou entités peut adresser une pétition au conseil d’administration pour la reconnaissance d’un collège nouveau ou distinct. Toute pétition de la sorte doit contenir une explication détaillée de :
a. Pourquoi l’ajout d’un tel collège améliorera la capacité du GNSO dans l'exercice de ses fonctions pour l’élaboration des politiques du GNSO ; et
b. Pourquoi le nouveau collège proposé représenterait de manière adéquate, sur une base globale, les parties prenantes qu’il cherche à représenter.
Toute pétition pour la reconnaissance d’un nouveau collège doit être publiée pour être commentée publiquement.
5. Le conseil d’administration peut créer de nouveaux collèges en réponse à une telle pétition, ou sur sa propre motion, s'il estime qu'une telle action pourrait servir les fins de l'ICANN. Dans le cas où le conseil d’administration envisage d’agir sur sa propre motion, il doit publier une explication détaillée des raisons rendant cette action nécessaire ou souhaitable, définir une date raisonnable pour un commentaire public, et ne pas prendre de décision finale concernant la création ou non d’un tel collège avant d’avoir examiné tous les commentaires reçus. Dès lors que le conseil d’administration soumet une pétition ou recommandation concernant la création d’un nouveau collège aux commentaires publics, il doit en avertir le conseil du GNSO et considérer toute réponse à cette notification avant de prendre une quelconque mesure.
Section 6. PROCESSUS D’ÉLABORATION DES POLITIQUES
Initialement, les procédures d’élaboration des politiques à suivre par le GNSO doivent être telles que mentionnées dans l'annexe A de ces statuts. Ces procédurespeuvent être complétées ou révisées, conformément à la section 3(4) de cet article.
ARTICLE XI : COMITÉS CONSULTATIFS
Le conseil d’administration peut créer un ou plusieurs comités consultatifs en plus de ceux spécifiés dans cet article. Les membres du comité consultatif peuvent être des administrateurs uniquement, administrateurs et non-administrateurs, ou non-administrateurs seulement, ou encore des membres alternatifs ou sans droit de vote. Les comités consultatifs n’auront pas avoir d'autorité légale pour agir au nom de l'ICANN, mais doivent toutefois signaler leurs financements et recommandations au conseil d'administration.
Section 2. COMITÉS CONSULTATIFS SPÉCIFIQUES
Il doit y avoir les comités consultatifs suivants au minimum :
1. Comité consultatif gouvernemental
a. Le comité consultatif gouvernemental doit évaluer les activités de l'ICANN et prodiguer des conseils sur ces activités lorsque celles-ci ont trait à des préoccupations des gouvernements, notamment aux questions pour lesquelles il peut y avoir une interaction entre les politiques de l'ICANN et diverses lois et autres accords internationaux ou risquant d’affecter des enjeux de réglementation publique.
b. L’adhésion au comité consultatif gouvernemental doit être ouverte à tous les gouvernements nationaux. L’adhésion doit également être ouverte aux différentes économies, comme reconnu dans les forums internationaux, ainsi qu’aux organismes gouvernementaux multinationaux et de traité, sur invite du comité consultatif gouvernemental via son président.
c. Le comité Consultatif gouvernemental peut adopter sa propre charte ainsi que des principes de fonctionnement ou de procédures internes pour guider ses activités, qui devront être publiés sur le site Web.
d. Le président du comité consultatif gouvernemental est élu par les membres du comité consultatif gouvernemental, conformément aux procédures adoptées par les membres.
e. Chaque membre du comité consultatif gouvernemental doit nommer un représentant accrédité au comité. Le représentant accrédité d’un membre doit exercer une fonction officielle formelle avec l’administration publique de ce membre. Le terme « officiel » désigne une personne qui a été élue à la tête d’une fonction gouvernementale, ou qui est employée par un gouvernement, une administration locale, ou un organisme gouvernemental multinational ou de traité, et dont la fonction première avec un gouvernement, une administration locale ou organisme consiste à développer ou influer sur les politiques gouvernementales ou publiques.
f. Chaque année, le comité consultatif gouvernemental doit nommer un agent de liaison sans droit de vote au conseil d’administration de l’ICANN, sans limitation du nombre de mandats, ainsi qu’un agent de liaison sans droit de vote au comité de nomination de l’ICANN.
g. Le comité consultatif gouvernemental peut désigner un agent de liaison sans droit de vote pour chacun des conseils des organismes de soutien et comités consultatifs, dans la mesure où le comité consultatif gouvernemental le juge approprié et nécessaire.
h. Le conseil d’administration doit, dans les plus brefs délais, informer le président du comité consultatif gouvernemental de toute proposition soulevant des problèmes de politique publique pour laquelle il, ou tout autre organisme de soutien de l’ICANN ou comité de nomination, cherche à obtenir des commentaires du public. Le conseil d’administration doit, par ailleurs, prendre dûment en considération toute réponse à cette notification en temps opportun avant de prendre une quelconque mesure.
i. Le comité consultatif gouvernemental peut directement proposer au Conseil d‘administrationdes questions à traiter, soit en commentant ou conseillant au préalable, ou en recommandant de manière spécifique l’existence d’une nouvelle mesure ou politique de développement ou de révision.
j. Les conseils du comité consultatif gouvernemental au sujet des réglementations publiques doivent être dûment pris en considération, à la fois dans la formulation et l’adoption de politiques. Dans le cas où le conseil d’administration de l’ICANN souhaite prendre une mesure ne correspondant pas aux conseils du comité consultatif gouvernementalil doit l'en informer et spécifier les raisons qui ont orienté sa décision allant à l’encontre de ces conseils. Le comité consultatif gouvernemental et le conseil d'administration de l'ICANN essaieront ensuite alors, de bonne foi, dans les plus brefs délais et de manière efficace, de trouver un compromis acceptable.
k. Si un tel compromis s’avère impossible, le conseil d’administration de l’ICANN spécifiera dans sa décision finale les raisons pour lesquelles les conseils du comité consultatif gouvernemental n’ont pas été suivis, et une telle spécification ne portera pas préjudice aux droits et obligations des membres du comité consultatif gouvernemental, notamment concernant les problèmes de politique publique dont ils sont responsables.
2. Comité consultatif sur la sécurité et la stabilité
a. Le rôle du SAC (Comité consultatif sur la sécurité et la stabilité) consiste à conseiller la communauté de l'ICANN et le conseil d’administration sur les questions ayant trait à la sécurité et l’intégrité des systèmes de nommage et d’allocation d’adresses Internet. Il est chargé de :
1. Développer une structure de sécurité pour les systèmes de nommage et d'allocation d'adresses Internet définissant les principaux centres d’intérêt et identifiant les responsabilités pour chaque domaine. Le comité doit porter une attention toute particulière aux questions de fonctionnement liées aux infrastructures de nommage critiques.
2. Communiquer à propos de questions de sécurité avec la communauté technique d’Internet ainsi que les operateurs et responsables des services d'infrastructures DNS critiques, inclure la communauté des opérateurs de serveurs racines, les registres de premier niveau et bureaux d’enregistrement, les opérateurs des arbres de délégation inversés comme in-addr.arpa et ip6.arpa et d’autres, en fonction des événements et des progrès. Le comité doit rassembler et énoncer les conditions à proposer aux personnes impliquées dans la révision technique des protocoles ayant trait au DNS et à l’allocation d’adresses et celles impliquées dans la planification opérationnelle.
3. Conduire une analyse constante des menaces et risques des systèmes de nommage et d’allocation d'adresses Internet pour évaluer l’emplacement des principales menaces à la stabilité et à la sécurité, et conseiller la communauté de l'ICANN à ce propos. Le comité doit recommander toute activité d’audit nécessaire pour évaluer le statut actuel du DNS et traiter la sécurité de l’allocation d'adresses en relation avec les risques et menaces identifiés.
4. Communiquer avec ceux ayant des responsabilités directes dans les questions de sécurité du nommage et des allocations d’adresses Internet (IETF, RSSAC, RIR, registres de noms, etc.), s’assurer que ses conseils sur les risques de sécurité, problèmes et priorités sont correctement harmonisés avec les activités de normalisation, de déploiement, de fonctionnement et de coordination existantes. Le comité doit veiller à ces activités et informer, selon les besoins, la communauté de l'ICANN et le conseil d'administration de sa progression.
5. Signaler ses activités au conseil d’administration de manière périodique.
6. Formuler des recommandations réglementaires à la communauté de l’ICANN et au conseil d’administration.
b. Le président et les membres du SAC doivent être nommés par le conseil d‘administration.
Chaque année, le SAC doit nommer un agent de liaison sans droit de vote au conseil d'administration de l'ICANN, conformément à la section 9 de l’article VI.
3. Comité consultatif du système des serveurs racines
a. Le RSSAC (Comité consultatif du système des serveurs racines) est chargé de conseiller le conseil d‘administration au sujet des opérations des serveurs racines du système de noms de domaine. Le RSSAC doit envisager et apporter des conseils au sujet des conditions opérationnelles des serveurs racines, y compris des capacités du matériel informatique hôte, des versions de système d’exploitation et de logiciels de serveur de noms de domaine, ainsi qu’au sujet du réseau de connectivité et de l’environnement physique. Le RSSAC doit examiner et donner des conseils au sujet des aspects concernant la sécurité du serveur racine. D’autre part, le RSSAC doit réviser le nombre, le lieu et la répartition des serveurs racines en prenant en considération la performance, la force ainsi que la fiabilité de l'ensemble du système.
b. Le RSSAC doit être constitué de (i) tous les opérateurs d’un serveur racine de référence (comme répertorié sur <> ), et (ii) d’autres personnes nommées par le conseil d’administration de l’ICANN.>
c. Le président initial du comité consultatif du système de serveurs racines du DNS doit être élu par le conseil d'administration ; les présidents suivants doivent être élus par les membres du comité consultatif du système des serveurs racines du DNS, conformément aux procédures adoptées par les membres.
d. Chaque année, le comité consultatif du système des serveurs racines doit nommer un agent de liaison sans droit de vote au conseil d’administration de l’ICANN, sans limitation du nombre de mandats, ainsi qu’un agent de liaison sans droit de vote au comité de nomination de l’ICANN.
4. Comité consultatif de l’ALAC
Le rôle de l'ALAC (comité consultatif des utilisateurs d’Internet) consiste à étudier et proposer des conseils sur les activités de l'ICANN, dans la mesure où les intérêts des utilisateurs d’Internet sont concernés.
b. L'ALAC se compose de (a) deux membres sélectionnés par chacun des RALO (groupe régional d'organisations d'utilisateurs d'Internet), comme établi dans le paragraphe 4(g) de cette section, et de (ii) cinq membres sélectionnés par le comité de nomination. Les cinq membres sélectionnés par le comité de nomination doivent comprendre un citoyen d’un pays appartenant à chacune des cinq régions géographiques établies selon la section 5 de l’article VI.
c. Conformément aux clauses de l’article de transition de ces statuts, les mandats réguliers des membres de l’ALAC doivent être les suivants :
1. Le mandat d’un membre sélectionné par chacun des RALO doit prendre effet à la clôture d’une réunion annuelle de l’ICANN au cours d’une année paire.
2. Le mandat d’un autre membre sélectionné par chacun des RALO doit prendre effet à la clôture d’une réunion annuelle de l’ICANN au cours d’une année impaire.
3. Les mandats de trois des membres sélectionnés par le comité de nomination doivent prendre effet à la clôture d’une réunion annuelle au cours d’une année impaire, et ceux des deux autres membres sélectionnés par le comité de nomination à la clôture d’une réunion annuelle au cours d’une année paire.
4. Généralement, le mandat de chaque membre prend fin à la fin de la seconde conférence annuelle après le début dudit mandat.
d. Le président de l'ALAC (At-Large Advisory Committee, Comité consultatif des utilisateurs d'Internet) est élu par les membres de l'ALAC conformément aux procédures adoptées par le Comité.
e. L'ALAC doit nommer chaque année un agent de liaison sans droit de vote au directoire de l’ICANN, sans limitation du nombre de mandats, et doit, après consultation avec chaque GROUI (groupe régional d'organisations d'utilisateurs d'Internet), nommer chaque année cinq délégués votant (et devant tous venir de pays situés dans des régions géographiques différentes, comme défini dans la section 5 de l’Article VI) au Comité de nomination.
f. Objet des dispositions de l’article de transition de ces Statuts, l’ALAC peut nommer des agents de liaison sans droit de vote dans au sein du Conseil du ccNSO et du Conseil du GNSO.
g. Il doit y avoir un GROUI pour chaque région géographique définie dans la section 5 de l’Article VI. Chaque GROUI doit constituer le principal forum et point de coordination de la contribution du public à l'ICANN dans la région géographique correspondante et doit être une association à but non lucratif certifiée par l’ICANN conformément aux critères et aux normes établies par le Conseil d’administration sur les recommandations de l'ALAC. Une association devient le GROUI reconnu pour sa région géographique lorsqu’elle entre dans un protocole d’accord avec l’ICANN, qui définit les rôles et les responsabilités respectives de l’ICANN et du GROUI en ce qui concerne le processus de nomination des membres de l’ALAC et les besoins d'ouverture, les opportunités de participation, la transparence, la responsabilité et la diversité de la structure et des procédures du GROUI, ainsi que les critères et les normes pour les organisations d’organisateurs d’Internet (OUI) constituant le GROUI.
h. Chaque GROUI doit être composé d’OUI indépendantes situées dans sa région géographique et ayant été certifiées conformes aux exigences du protocole d'accord entre le GROUI et l'ICANN conformément au paragraphe 4(i) de cette Section. Si cela est stipulé dans le protocole d'accord avec l'ICANN, un GROUI peut également inclure des utilisateurs d'Internet étant citoyens ou résidents de pays au sein de la région géographique du GROUI.
- Les critères et normes de certifications des OUI au sein de chaque région géographique doivent être établis par le Conseil en fonction des recommandations de l’ALAC et doivent être stipulés dans le protocole d’accord entre l’ICANN et le GROUI pour chaque région géographique.
- Les critères et normes de certification des OUI doivent être établis de façon à ce que la participation d'utilisateurs d'Internet étant citoyens ou résidents de pays au sein de la région géographique (conformément à la section 5 de l’Article VI) du GROUI prédomine dans le fonctionnement de chaque OUI au sein du GROUI, sans que cela n’exclue toute participation supplémentaire, compatible avec les intérêts des utilisateurs d’Internet de la région, d’éléments extérieurs.
- Chaque protocole d’accord du GROUI doit également inclure des dispositions conçues pour permettre, dans la mesure du possible, à chaque utilisateur d’Internet étant citoyen d'un pays de la région géographique du GROUI de participer dans au moins une des OUI du GROUI.
- Dans la mesure du respect de ces objectifs, les critères et les normes doivent également fournir à chaque GROUI le type de structure qui correspond le mieux aux us et coutumes et au caractère de sa région géographique.
- Une fois les cirières et les normes établis comme stipulé dans cette clause i, l’ALAC, avec le conseil et la participation du GROUI de la région du candidat, est responsable de la certification des associations comme répondant aux critères et aux normes pour l’accréditation OUI.
- Les décisions portant sur la certification ou non d’une OUI doivent être prises de la façon déterminée par l’ALAC dans ses règles de procédure, à l’exception des modifications apportées à ces règles de procédure en matière d'applications OUI, qui doivent faire l'objet d’un examen par le GROUI et par le Conseil d’administration de l’ICANN.
- Les décisions portant sur l'accréditation, la non accréditation ou le retrait de l’accréditation d'une OUI doivent faire l'objet d'un examen respectant les procédures établies par le conseil d'administration.
- Sur une base permanente, l'ALAC peut également donner son avis sur le respect ou non par une OUI des critères et des normes appliqués.
j. L'ALAC est également responsable de la collaboration avec les GROUI, pour la coordination des activités suivantes :
1. communication à la communauté des utilisateurs individuels d'Internet des informations importantes de l'ICANN ;
2. diffusion (par courrier électronique ou autre) d'un agenda à jour, d'actualités sur l'ICANN et d'informations sur les éléments du processus d'élaboration de politiques de l'ICANN ;
3. promotion d'activités de formation au sein de la communauté des utilisateurs individuels d'Internet ;
4. développement et mise à jour de programmes continus d'information et de formation, concernant l'ICANN et ses réalisations ;
5 mise en place d'une stratégie de formation sur les enjeux traités par l'ICANN dans chaque région de GROUI ;
6. diffusion au public et analyse des projets de politiques et des décisions de l'ICANN, de leur impact régional (potentiel) et de leur effet (potentiel) sur les individus dans la région ;
7. mise à disposition de mécanismes basés sur Internet permettant les discussions entre les membres des organisations d'utilisateurs d'Internet ; et
8. élaboration de mécanismes et de processus permettant la communication bilatérale entre les membres des organisations d'utilisateurs d'Internet et les acteurs impliqués dans le processus de prise de décision de l'ICANN, de sorte que les individus puissent échanger leurs points de vue sur les enjeux en suspens traités par l'ICANN.
Chaque Comité consultatif doit déterminer ses propres règles de procédure et ses conditions de quorum.
Le président et chaque membre d'un comité doivent exercer jusqu'à la nomination de leur successeur, ou jusqu’à la résiliation du comité, ou jusqu’à ce qu'il ou elle soit relevé(e) de ses fonctions, renouvelle son contrat ou ne soit plus habilité à être un membre du comité.
Les vacances de postes dans les comités doivent être comblées de la même façon que dans le cas des nominations originales.
Les membres du Comité ne doivent pas recevoir de compensation en tant que membres d’un comité. Le Conseil d’administration peut toutefois autoriser le remboursement des dépenses réelles et nécessaires engagées par les membres d’un comité, administrateurs compris dans le cadre de leur travail en tant que membres d’un comité.
ARTICLE XI-A : AUTRES MÉCANISMES CONSULTATIFS
Section 1. CONSEIL D’EXPERT EXTERNE
1. Objectif. La recherche d’un conseil d’expert externe a pour objectif de permettre au processus d’élaboration des politiques au sein de l’ICANN de tirer parti de l’expertise existante présente dans les secteurs public ou privés, mais à l'extérieur de l'ICANN. Dans ces cas, où des organes publics disposant de l'expertise adaptée existent, ou dans lesquels l'accès à une expertise privée pourrait s'avérer utile, le Conseil d’administration et ses organes constituants doivent être encouragés à rechercher le conseil d'organes ou d’individus experts.
2. Types d’organisations consultatives d’experts.
a. De sa propre initiative, ou sur la suggestion de n’importe quel organe ICANN, le Conseil d’administration peut nommer ou autoriser le président à nommer les organisations consultatives d’experts constituées d’individus ou d’entités du secteur public ou du secteur privé. Si le conseil recherché auprès de ce type d'organisations concerne les problèmes de politiques publiques, les dispositions de la section 1(3)(b) de cet Article s’appliquent.
b. En outre, conformément à la section 1(3) de cet Article, le Conseil d’administration peut soumettre les problèmes de politique concernant les missions de l'ICANN à une organisation gouvernementale multinationale ou à une organisation de traité.
3. Processus de recherche de conseil - Problèmes de politique publique.
a. Le Comité consultatif gouvernemental peut à tout moment recommander que le Conseil d'administration demande conseil au sujet d’un ou plusieurs problème(s) de politique publique auprès d’une source externe, comme exposé plus haut.
b. Dans le cas où le Conseil d’administration détermine, sur une recommandation de ce genre ou autre, qu’un conseil externe doit être recherché au sujet d’un ou plusieurs problème(s), le Conseil d’administration doit, selon les besoins, consulter le Comité consultatif gouvernemental au sujet de la source adaptée dans laquelle rechercher le conseil et les dispositions, notamment la définition du contenu et du processus, afin de demander et d’obtenir ce conseil.
c. Le Conseil d’administration doit, selon les besoins, transmettre toute demande de conseil d'une organisation multinationale ou d'une organisation de traité, incluant le cahier des charges de référence, au Comité consultatif gouvernemental, avec la suggestion que la demande soit transmise par le Comité consultatif gouvernemental à l’organisation multinationale ou à l’organisation de traité.
4. Processus de recherche et de conseil – Autres problèmes. Tout signalement de problèmes ne concernant pas la politique publique à une organisation consultative d’experts par le Conseil d’administration ou par la président conformément à la section 1(2)(a) de cet Article doit être effectué conformément au cahier des charges décrivant les enjeux sur lesquels des commentaires et des conseils sont recherchés et les procédures et délais à respecter.
5. Réception des conseils d’experts et leurs effets. Les conseils externes associés à cette section doivent être fournis par écrit. Les conseils de ce type sont consultatifs et n’engagent à rien, et ont pour but d’augmenter les informations disponibles pour le Conseil d’administration ou tout autre organe de l’ICANN afin de remplir leur mission.
6. Commentaires possibles. Le Comité consultatif gouvernemental, en plus des organisations de soutien et des autres comités consultatifs, doit avoir l’opportunité de faire des commentaires sur tout conseil externe reçu avant la prise de toute décision par le Conseil d’administration.
Section 2. GROUPE DE LIAISON TECHNIQUE (TLG - Technical Liaison Group)
1. Objectif. La qualité du travail de l’ICANN dépend de son accès à des informations complètes et valides au sujet des normes techniques à la base des activités de l’ICANN. La relation de l'ICANN avec les organisations qui produisent ces normes est de ce fait particulièrement importante. Le Groupe de liaison technique (TLG pour Technical Liaison Group) doit connecter le Conseil d’administration aux sources adaptées de conseil technique au sujet des problèmes spécifiques concernant les activités d’ICANN.
2. Organisations TLG. Le Groupe de liaison technique (TLG pour Technical Liaison Group) doit comprendre quatre organisations : L’ETSI (European Telecommunications Standards Institute, institut européen des normes de télécommunication), l’ITU-T (International Telecommunications Union's Telecommunication Standardization Sector, secteur de normalisation de télécommunication de l'union des télécommunications internationales), le W3C (World Wide Web Consortium, consortium pour le World Wide Web) et l'IAB (Internet Architecture Board, comité d’architecture Internet).
3. Rôle. Le rôle des organisations TLG doit être la canalisation des informations et des conseils techniques vers le Conseil d’administration et les autres institutions de l’ICANN. Ce rôle a à la fois une composante de réactivité et de surveillance active, ce qui implique les responsabilités suivantes :
a. En réponse à la demande d’informations, connecter le Conseil d’administration ou tout autre organe de l’ICANN avec les sources d’expertise technique appropriées. Cette composante du rôle du groupe TLG couvre les circonstances dans lesquelles l’ICANN recherche une réponse ferme à une question technique spécifique. Lorsque des informations concernant une norme particulière dont une organisation du groupe TLG est responsable sont nécessaires, cette demande doit être envoyée à cette organisation du groupe TLG.
b. Dans le cadre de l’activité de surveillance permanente, informer le Conseil d’administration de la pertinence et de l’avancement des développements techniques dans les domaines entrant dans le cadre d'action de chaque organisation et susceptibles d'influencer les décision du Conseil d’administration ou d'autres actions de l'ICANN, et d’attirer l’attention sur les problèmes relatifs aux normes techniques globales influant sur le développement des politiques dans le cadre de la mission de l’ICANN. Cette composante du rôle du groupe TLG couvre les circonstances dans lesquelles l'ICANN n'est pas au courant d'un nouveau développement, et par conséquent ne réalise pas qu'une question doit être posée.
4. Procédures relatives aux TLG Le groupe TLG ne doit pas compter de membres du bureau ou tenir de réunions, ni fournir des conseils sur les politiques au Conseil d’administration en tant que comité (même si les organisations du groupe TLG peuvent se voir demander individuellement par le Conseil d’administration d'en faire ainsi lorsque le besoin s’en fait sentir dans des domaines en rapport avec leurs chartes individuelles). Le groupe TLG ne doit pas non plus débattre ou se charger de la coordination de problèmes techniques avec les organisations du groupe TLG ; établir ou tenter d’établir des postes unifiés ; ou créer ou tenter de créer des niveaux de structures supplémentaires au sein du groupe TLG pour le développement de normes techniques ou pour tout autre objectif.
5. Travail technique de l’IANA Le groupe TLG ne doit pas s’impliquer dans le travail de l’IANA pour l'IETF (Internet Engineering Task Force, groupe d’études d’ingénierie Internet), l’IRTF (Internet Research Task Force, groupe d’études de recherche Internet), ou l’IAB (Internet Architecture Board, comité d’architecture Internet),conformément au protocole d’accord concernant le travail technique de l’IANA (Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority) ratifié par le Conseil d’administration le 10 mars 2000.
6. Experts techniques individuels. Chaque organisation du groupe TLG doit désigner deux experts techniques individuels familiarisés avec les problèmes de normes techniques en vigueur pour les activités de l’ICANN. Ces 8 experts doivent être disponibles en cas de besoin afin de déterminer, par le biais d’un échange de messages électroniques, vers où diriger une question technique de l’ICANN lorsque l’ICANN ne la pose pas directement à une organisation spécifique du groupe TLG.
7. Liaison avec le Conseil d’administration et nomination du délégué du comité. Chaque année, en rotation, une organisation du groupe TLG doit nommer un agent de liaison sans droit de vote au Conseil d’administration, conformément à l’Article VI, section 9(1)(d). Chaque année, en rotation, une organisation du groupe TLG doit choisir un délégué ayant le droit de vote pour le Comité de nomination de l’ICANN, conformément à l’Article VII, section 2(8)(j). L'ordre de rotation pour la nomination de l'agent de liaison dans droit de vote doit être ETSI, ITU-T puis W3C. L’ordre de rotation pour la sélection du délégué du Comité de nomination doit être W3C, ETSI et ITU-T. (L’IAB ne prend pas part à ces rotations car sinon l’IETF nommerait un agent de liaison sans droite de vote pour le Conseil d’administration et sélectionnerait un délégué pour le Comité de nomination de l’ICANN.)
ARTICLE XII : CONSEIL D’ADMINISTRATION ET COMITÉS PROVISOIRES
Section 1. COMITÉS DU CONSEIL D'ADMINISTRATION
Le Conseil d'administration peut mettre en place un ou plusieurs comité(s) en son sein, dont l’existence perdure jusqu’à ce que le Conseil d’administration décide d’y mettre un terme. Seuls les administrateurs peuvent être nommés dans un comité du Conseil d’administration. Si une personne nommée dans un comité du Conseil d'administration perd son titre d’administrateur, elle perd également sa place dans tout comité du Conseil d’administration. Chaque Comité du Conseil d'administration doit être composé de deux administrateurs ou plus. Le Conseil d’administration peut désigner un ou plusieurs administrateur(s) en tant que membres alternatifs de tout comité de ce genre, qui sont susceptibles de remplacer n’importe quel membre absent lors des réunions du comité. Les membres d’un comité peuvent être révoqués à tout moment d’un comité par le vote d’une majorité de deux tiers (2/3) de l’ensemble des membres du Conseil d'administration ; à condition, toutefois, que tout administrateur sujet de l’action de révocation ne soit pas autorisé à voter sur ce type d’action ; et, en outre, à condition qu'en aucun cas un administrateur ne soit révoqué d'un comité sans que la révocation ne soit approuvée par une majorité de l'ensemble des membres du Conseil d'administration.
Section 2. POUVOIRS DES COMITÉS DU CONSEIL D’ADMINISTRATION
1. Le Conseil d’administration peut déléguer aux comités du Conseil d’administration toute autorité légale du Conseil d’administration concernant :
a. Les postes vacants à pourvoir au sein du Conseil d’administration ou de tout autre comité ;
b. La modification ou l’abrogation des Statuts ou des clauses ou l'adoption de nouveaux Statuts ou de nouvelles clauses ;
c. La modification ou l’abrogation de toute résolution du Conseil d’administration qui, selon ses termes express, ne peut être ni modifiée ni abrogée ;
d. La nomination de comités du Conseil d’administration ou de membres les composant ;
e. L’approbation de toute transaction indépendante, dont le type est défini dans la section 5233(a) du CNPBCL ;
f. L’approbation du budget annuel conformément à l’Article XVI ; ou
g. Le remplacement de tout membre du bureau décrit dans l’Article XIII.
2. Le Conseil d'administration doit avoir la capacité de dicter la manière dont les procédures de chaque Comité du Conseil d’administration doivent être conduites. Dans l’absence de toute prescription de ce type, ce type de comité doit avoir la capacité de dicter la manière dont les procédures doivent être conduites. À défaut de ces Statuts, que le Conseil d’administration ou tout autre comité de ce genre doivent autrement fournir, les réunions courantes et exceptionnelles doivent être menées conformément à l’Article VI portant sur les réunions et les actions du Conseil d’administration. Chaque comité doit conserver des minutes régulières de ses procédures et doit fournir des rapports occasionnels au Conseil d'administration lorsque celui-ci le demande.
Section 3. COMITÉS TEMPORAIRES
Le Conseil d’administration peut selon ses besoins établir des comités temporaires, dont la composition, les missions et les responsabilités sont définies dans les résolutions ou les chartes adoptées par le Conseil d'administration lors de leur mise en place.
ARTICLE XIII : MEMBRES DU BUREAU
Le bureau de l’ICANN doit être composé d’un président (ayant le poste de président directeur général), d’un secrétaire, et d’un directeur financier. L’ICANN peut également compter, à la discrétion du Conseil d'administration, tout membre supplémentaire nécessaire. Toute personne autre que le président peut avoir plusieurs rôles, excepté qu'aucun membre du Conseil d’administration (autre que le président) ne doit officier simultanément en tant que membre du bureau de l’ICANN.
Section 2. ÉLECTION DES MEMBRES DU BUREAU
Les membres du bureau de l'ICANN sont élus chaque année par le Conseil d’administration, conformément aux recommandations du président ou, dans le cas du président, du président du Conseil d’administration de l’ICANN. Chacun de ces membres du bureau conserve son poste jusqu’à sa démission, sa révocation ou l’élection de son successeur.
Section 3. RÉVOCATION DES MEMBRES DU BUREAU
Tout membre du bureau peut être révoqué, avec ou sans raison, par le vote d’une majorité de deux tiers (2/3) de l’ensemble des membres du Conseil d'administration. Dans le cas d’un poste vacant du fait d’un décès, d’une démission, d’une révocation, d’une disqualification ou de tout autre raison, le Conseil d’administration peut déléguer les pouvoirs et les missions inhérents au poste à n’importe quel membre du bureau ou à n’importe quel administrateur jusqu’à ce qu'un successeur soit élu pour le poste.
Le président est le président directeur général (PDG) de l’ICANN en charge de l’ensemble de ses activités et opérations. Tous les autres membres du bureau et de l’équipe rendent des comptes au président ou à son délégué, sauf mention contraire dans ces Statuts. Le président officie en tant que membre ex officio du Conseil d’administration, et dispose des mêmes droits et privilèges que tout autre membre du Conseil d’administration. Le président est habilité à solliciter des réunions extraordinaires du Conseil d’administration, conformément aux présents Statuts, et délègue toutes les autres missions en fonction des besoins, conformément aux présents Statuts et aux demandes occasionnelles du Conseil d’administration.
Le secrétaire consigne ou fait consigner les minutes du Conseil d'administration dans un ou plusieurs livre(s) fournis à cet effet, vérifie que toutes les notifications sont dûment effectuées, conformément aux dispositions de ces Statuts ou de la loi, et effectue généralement l'ensemble des missions que lui assigne le président du Conseil d'administration.
Section 6. DIRECTEUR FINANCIER
Le directeur financier est le directeur financier de l’ICANN. Sur demande du Conseil d'administration, le directeur délègue ses missions en respectant la forme et la/les caution(s) déterminées par le Conseil d’administration. Le directeur financier a la charge et la garde de l’ensemble des fonds de l’ICANN et doit consigner ou faire consigner, dans des livres de compte appartenant à l’ICANN, les montants totaux et précis de tous les encaissements et décaissements, et déposer l’ensemble de l’argent et de tout autre élément de valeur au nom de l'ICANN dans l’établissement de dépôt désigné à cet effet par le Conseil d'administration. Le directeur financier dépense les fonds de l’ICANN sur ordre du Conseil d’administration ou du président et, sur leur demande, rend au Conseil d’administration ou au président des comptes quant à ses transactions en tant que directeur financier et à la situation financière de l'ICANN. Le directeur financier est responsable de la planification et des prévisions financières de l’ICANN et assiste le président dans la préparation du budget annuel de l’ICANN. Le directeur financier coordonne et supervise le financement de l’ICANN, notamment les audits ou autres études de l’ICANN ou de ses organisations de soutien. Le directeur financier est responsable de tout autre problème relatif aux opérations financières de l’ICANN.
Section 7. MEMBRES DU BUREAU SUPPLÉMENTAIRES
En plus des membres du bureau décrits ci-dessus, les membres du bureau supplémentaires ou assistants élus ou nommés par le Conseil d'administration effectuent les missions qui leur sont assignées par le président ou le Conseil d'administration.
Section 8. COMPENSATION ET DÉPENSES
La compensation de tout membre du bureau de l’ICANN doit être approuvée par le Conseil d’administration. Les dépenses consenties dans la cadre de la réalisation leurs missions de membres du bureau peuvent être remboursées aux membres du bureau après acceptation du président (dans le cas de membres du bureau autres que le président), d’un autre membre du bureau désigné par le Conseil d’administration (dans le cas du président), ou du Conseil d’administration.
Le Conseil d’administration, par le biais d’un comité désigné à cette fin, doit instaurer une politique exigeant, au minimum une fois par an, une déclaration de la part de chaque membre du bureau exprimant toutes les affiliations commerciales ou aux autres ayant trait d’une manière ou d’une autre aux affiliations commerciales et aux autres affiliations de l’ICANN.
ARTICLE XIV : INDEMNISATION DES ADMINISTRATEURS, MEMBRES DU BUREAU, SALARIÉS ET AUTRES AGENTS
L’ICANN doit, autant que possible dans le cadre des indications du CNPBCL, indemniser chacun de ses agents pour les dépenses, jugements, amendes, transactions et autres montants réellement et raisonnablement engagés dans le cadre de toute procédure due au fait que la personne est ou était un agent de l’ICANN, à condition que la personne indemnisée ait agi en bonne foi et d’une façon qu’elle pensait être dans le meilleur intérêt de l’ICANN et dans le respect de la loi. Dans le cadre de cet article, un « agent » de l’ICANN désigne toute personne étant ou ayant été un administrateur, un membre du bureau, un employé ou tout autre agent de l’ICANN (y compris un membre de toute organisation de soutien, de tout comité consultatif, de tout comité de nomination, de tout autre comité de l’ICANN ou du Groupe de liaison technique (TLG) agissant dans le cadre de ses responsabilités ; ou agit ou agissait sur la demande de l’ICANN en tant qu’administrateur, membre du bureau, employé ou agent de toute autre corporation, de tout autre partenariat, de toute autre entreprise conjointe, de tout autre trust ou de toute autre entreprise. Le Conseil d’administration peut adopter une résolution autorisant l’achat et la maintenance d'une assurance au nom de tout agent de l'ICANN, contre toute responsabilité opposable ou engagée par l'agent dans le cadre de ses missions ou inhérente à son Statut, que l’ICANN ait ou non la possibilité d’indemniser l’agent pour cette responsabilité, conformément aux dispositions de cet article.
ARTICLE XV : CLAUSES GÉNÉRALES
Le Conseil d’administration peut autoriser un ou des membre(s) du bureau, un ou des agent(s) à souscrire un contrat ou à livrer un acte instrumentaire au nom et de la part de l’ICANN, et ce genre d’autorité peut être général ou limité à certaines circonstances spécifiques. En l’absence d'une autorisation contraire du Conseil d’administration, les contrats et les actes instrumentaires ne peuvent être exécutés que par les membres du bureau suivants : Le président, tout vice-président ou le directeur financier. À moins d’être autorisé ou ratifié par le Conseil d'administration, aucun autre membre du bureau, agent ou employé n'a le pouvoir ou l’autorité d’engager l’ICANN ou de la rendre responsable d'une dette ou d’une obligation quelconque.
L’ensemble des fonds de l’ICANN non employés doivent être déposés de temps en temps au crédit de l’ICANN dans les banques, les sociétés fiduciaires ou les autres dépôts lorsque le Conseil d'administration ou le président sous sa délégation le décide.
Toutes les vérifications, toutes les versions préliminaires ou tous les autres ordres pour le remboursement de dépenses, de notes et d’autres justificatifs d’endettement établis au nom de l’ICANN doivent être signés par un ou des membre(s) du bureau, un ou des agent(s) de l’ICANN et rédigés de la façon déterminée par des résolutions régulières du Conseil d'administration.
Aucun emprunt ne doit être contracté par ou pour l’ICANN et aucun justificatif d’endettement ne peut être établi en son nom sans autorisation par une résolution du Conseil d’administration. Ce genre d’autorité peut être général ou limité à certaines circonstances spécifiques ; à condition, toutefois, qu’aucun prêt ne soit accordé par l’ICANN à ses administrateurs ou aux membres de son bureau.
L’année fiscale de l'ICANN est déterminée par le Conseil d’administration.
A la fin de l’année fiscale, les livres de compte de l’ICANN doivent être clôturés et faire l’objet d’un audit par des comptables publics certifiés. La responsabilité de la nomination des personnes chargées de l’audit fiscal incombe au Conseil d’administration ;
Section 3. RAPPORT ANNUEL ET DÉCLARATION ANNUELLE
Le Conseil d’administration publie au moins une fois par an un rapport décrivant ses activités, notamment une déclaration financière ayant fait l'objet d'un audit et une description de tous les paiements faits par l'ICANN aux administrateurs (incluant les remboursements de frais). L’ICANN doit préparer et faire envoyer le rapport annuel et la déclaration annuelle de certaines transactions à chaque membre du Conseil d'administration et à toute autre personne désignée par le Conseil d'administration, conformément aux directives du CNPBCL, dans les cent-vingt (120) jours suivant la clôture de l'année fiscale de l'ICANN.
Au moins quarante-cinq (45) jours avant le début de chaque année fiscale, le président doit préparer et présenter au Conseil d'administration une proposition de budget de l’ICANN pour l’année fiscale à venir, qui doit être publiée sur le site Web. La proposition de budget doit identifier les sources et les niveaux de revenu prévus et, dans la mesure du possible, identifier les éléments de dépense matériels prévus par poste. Le Conseil d’administration adopte un budget annuel et publie le budget adopté sur le site Web.
Le Conseil d’administration peut définir des frais divers pour les services et les avantages fournis par l'ICANN, dans le but de couvrir entièrement les coûts raisonnables du fonctionnement de l'ICANN et d’établir des réserves raisonnables pour les dépenses courantes et extraordinaires à venir associées aux activités légitimes de l’ICANN. Ces frais divers doivent être justes et équitables, doivent être publiés et ouverts aux commentaires du public avant leur adoption, et doivent être publiés sur le site Web d'une façon suffisamment détaillée pour être facilement accessibles lorsqu'ils sont adoptés.
L'ICANN ne doit pas compter de membres, conformément à la loi CNPBCL (California Nonprofit Public Benefit Corporation Law), nonobstant l’utilisation du terme « Membre » dans ces Statuts, dans tout document de l'ICANN ou dans toute action du Conseil d'administration ou de l'équipe de l'ICANN.
ARTICLE XVIII : LOCAUX ET CACHET
Le local principal pour les transactions inhérentes aux activités de l'ICANN se situe dans le comté de Los Angeles, en Californie, aux États-Unis. L’ICANN peut également disposer d’un ou plusieurs local(aux) supplémentaire(s) aux États-Unis ou dans d’autres pays.
Le Conseil d’administration peut adopter un cachet pour l’entreprise et l’utiliser en le faisant copier, imprimer, apposer, ou autre.
Sauf mention contraire dans les Statuts, les clauses ou les Statuts de l’ICANN peuvent être modifiés, amendés ou abrogés, et de nouvelles clauses ou de nouveaux Statuts peuvent être adopté sur le vote de deux tiers (2/3) de l’ensemble des membres du Conseil d'administration.
ARTICLE XX : ARTICLE DE TRANSITION
Cet article de transition expose les dispositions pour la transition entre les processus et structures définis par les Statuts de l'ICANN, tels qu’amendés et définis le 29 octobre 1999, puis amendés le 21 février 2002 (les « Anciens Statuts »), et les processus et structures définis par les Statuts dont cet article fait partie (les « Nouveaux Statuts »).
Section 2. CONSEIL D’ADMINISTRATION
1. Pour la période débutant lors de l'adoption de cet article de transition et se terminant à la date d’entrée en vigueur du nouveau Conseil d’administration, conformément au paragraphe 5 de cette Section 2, le Conseil d’administration de la société (« Conseil d’administration de transition ») est constitué des membres du Conseil d’administration, qui auraient été administrateurs selon les Anciens Statuts immédiatement après la conclusion de la réunion annuelle de 2002, à l’exception des utilisateurs d’Internet du Conseil d’administration, qui, selon les Anciens Statuts, peuvent avoir été habilités à le devenir en notifiant au secrétaire du Conseil d’administration le 15 décembre 2002 ou par écrit soit par courrier électronique au plus tard le 23 décembre 2002 et officier également en tant que membres du Conseil d’administration de transition. Nonobstant les dispositions de l’Article VI, section 12 des nouveaux Statuts, les postes vacants au sein du Conseil d’administration de transition ne doivent pas être pourvus. Le Conseil d’administration de transition ne dispose pas d'agents de liaison, conformément à l’article VI, section 9 des nouveaux Statuts. Les comités du Conseil d’administration existant à la date d'adoption de cet article de transition continuent à exister et sont sujets à toutes les modifications au sein des comités du Conseil d'administration ou concernant les règles pour devenir membre que le Conseil d’administration de transition peut adopter.
2. Le Conseil d’administration de transition élit un président et un vice-président qui officient jusqu’à la date d’entrée en vigueur du nouveau Conseil d’administration.
3. Le « nouveau Conseil d’administration » est le Conseil d’administration décrit dans l’Article VI, section 2(1) des nouveaux Statuts.
4. Rapidement après l’adoption de cet article de transition, un comité de nomination doit être formé, et inclure les délégués et les agents de liaison décrits dans l’Article VII, section 2 des nouveaux Statuts, dont les mandats se terminent à la conclusion de la réunion annuelle de l’ICANN de 2003. Le comité de nomination doit sans délai sélectionner les administrateurs appelés à pourvoir les postes 1 à 8 du nouveau Conseil d'administration, dont les mandats se terminent au début des premiers mandats réguliers définis pour ces sièges dans l’Article VI, section 8(1)(a)-(c) des nouveaux Statuts, et doit en informer par écrit le secrétaire de l’ICANN.
5. La date et l’heure d’entrée en vigueur du nouveau Conseil d’administration doivent être à un moment, conformément aux indications du Conseil d’administration de transition définies lors de la réunion annuelle de l'ICANN de 2003, qui débute au moins sept jours civils après la réception par le secrétaire de l'ICANN de la notification écrite du choix des administrateurs voués à pourvoir au moins dix des postes 1 à 14 du nouveau Conseil d’administration. À compter de la date et de l’heure d’entrée en vigueur du nouveau Conseil d'administration, il est attendu que le Conseil d’administration de transition assume l’ensemble des droits, missions et obligations du Conseil d’administration de l’ICANN. Conformément à la section 4 de cet article, les administrateurs (Article VI, section 2(1)(a)-(d)) et les agents de liaison sans droit de vote (Article VI, section 9) pour lesquels le secrétaire de l’ICANN a reçu une notification de sélection doivent, en même temps que le président (Article VI, section 2(1)(e)), siéger dès la date et à l’heure d’entrée au vigueur du nouveau Conseil, et ensuite les administrateurs et les agents de liaison sans droite de vote peuvent siéger au moment où le secrétaire de l'ICANN’ reçoit la notification de leur sélection.
6. La première action du nouveau Conseil d’administration est d’élire un président et un vice-président. Les mandats de ces postes du Conseil d’administration expirent à la fin de la réunion annuelle de 2003.
7. Les comités du Conseil d’administration existant à la date et à l'heure d’entrée en vigueur du nouveau Conseil d’administration continuent à exister conformément à leurs chartes en vigueur, mais les mandats de tous les membres de ces comités se terminent à la date et à l'heure d'entrée en vigueur du nouveau Conseil d’administration. Les comités temporaires existant à la date et à l'heure d'entrée en vigueur continuent à exister conformément à leurs chartes en vigueur, sujettes à toutes les modifications que le nouveau Conseil d'administration adopte.
8. En application de la disposition de limitation des mandats de la section 8(5) de l’Article VI, le service d’un administrateur au sein du Conseil d’administration avant la date et l’heure d’entrée en vigueur du nouveau Conseil d’administration compte comme un mandat.
Section 3. ORGANISATION DE SUPPORT DES ADRESSES
L'organisation de support des adresses (ASO pour Address Supporting Organization) continue à fonctionner conformément aux dispositions du protocole d’accord souscrit à l’origine le 18 octobre 1999 entre l’ICANN et un groupe de registres Internet régionaux (RIR pour Regional Internet Registries), et amendé en octobre 2000, jusqu’à ce qu’un protocole d’accord de remplacement entre en vigueur. Rapidement après l’adoption de cet article de transition, l’organisation de support des adresses doit sélectionner, et en informer par écrit le secrétaire de l’ICANN :
1. Les administrateurs appelés à pourvoir les postes 9 et 10 dans le nouveau Conseil d’administration, dont les mandats se terminent au début des premier mandats réguliers spécifiés pour chacun de ces sièges dans l’Article VI, section 8(1)(d) et (e) des nouveaux Statuts; et
2. Le délégué du comité de nomination sélectionné par le Conseil d'administration de l'organisation de support des adresses, conformément à l’Article VII, section 2(8)(f) des nouveaux Statuts.
En prenant en compte le fait que les administrateurs de l'ICANN sont autorisés à choisir et le besoin d'une sélection rapide afin d’assurer le plus rapidement possible l'efficacité du nouveau Conseil d'administration, l'organisation de support des adresses peut choisir ces administrateurs parmi les personnes précédemment sélectionnées comme administrateurs de l'ICANN dans le cadre des anciens Statuts. Dans la mesure où l’organisation de support des adresses ne prévient pas par écrit le secrétaire de l’ICANN avant le 31 mars 2003 inclus de ses choix pour les sièges 9 et 10, l’organisation de support des adresses est estimée avoir choisi pour le siège 9 la personne qu’elle a choisie comme administrateur de l’ICANN dans le cadre des anciens Statuts pour un mandat débutant en 2001 et pour le siège 10 une personne qu’elle a choisie comme administrateur de l'ICANN dans le cadre des anciens Statuts pour un mandat débutant en 2002.
Section 4. ORGANISME DE SOUTIEN RELATIF AUX NOMS GÉOGRAPHIQUES (ccNSO)
1. Lors de l’engagement de trente responsables ccTLD (dont au moins quatre dans chaque région géographique) en tant que membres du ccNSO, une note écrite doit être publiée sur le site Web. Le plus rapidement possible après cette note, les membres du Conseil du ccNSO initial doivent être sélectionnés conformément aux procédures énoncées dans l’Article IX, section 4(8) et (9). Au cours du processus de sélection, une note écrite indiquant que le Conseil d’administration a été constitué doit être publiée sur le site Web. Trois membres du Conseil du ccNSO doivent être sélectionnés par les membres du ccNSO au sein de chaque région géographique, parmi lesquels un membre effectue un mandat se terminant à la fin de la première réunion annuelle de l’ICANN après la constitution du Conseil du ccNSO, un second effectue un mandat se terminant à la fin de la seconde réunion annuelle de l’ICANN après la constitution du Conseil d’administration et le troisième effectue un mandat se terminant à la fin de la troisième réunion annuelle après la constitution du Conseil du ccNSO. (La définition de « responsable ccTLD » énoncée dans l’Article IX, section 4(1) et les définitions énoncées dans l’Article IX, section 4(4) s’appliquent à cette section 4 de l’Article XX.)
2. Après l’adoption de l’Article IX de ces Statuts, le Comité de nomination sélectionne trois membres du Conseil du ccNSO décrit dans l’Article IX, section 3(1)(b). En sélectionnant trois individus pour œuvrer au sein du Conseil du ccNSO, le comité de nomination en désigne un appelé à effectuer un mandat se terminant à la fin de la seconde réunion annuelle de l’ICANN après la constitution du Conseil du ccNSO, un second appelé à effectuer un mandat se terminant à la fin de la seconde réunion annuelle de l’ICANN après la constitution du Conseil du ccNSO, et un troisième appelé à effectuer un mandat se terminant à la fin de la troisième réunion annuelle de l'ICANN après la constitution du Conseil du ccNSO. Les trois membres du Conseil du ccNSO sélectionnés par le comité de nomination ne doivent pas prendre leurs sièges avant que le Conseil du ccNSO ne soit constitué.
3. Lors de la constitution du Conseil du ccNSO, l’ALAC (At-Large Advisory Committee, Comité consultatif des utilisateurs d'Internet) et le Comité consultatif gouvernemental peuvent désigner un agent de liaison chacun dans le Conseil du ccNSO, conformément à l’Article IX, section 3(2)(a) et (b).
4. Lors de la constitution du Conseil du ccNSO, le Conseil d’administration peut désigner des organisations régionales, conformément à l’Article IX, section 5. Lors de sa désignation, une organisation régionale peut nommer un agent de liaison au Conseil du ccNSO.
5. Jusqu’à la constitution du Conseil du ccNSO, les sièges 11 et 12 du nouveau Conseil d'administration restent vacants. Rapidement après la constitution du Conseil du ccNSO, le ccNSO sélectionne, par l’intermédiaire du Conseil du ccNSO, les administrateurs voués à pourvoir les sièges 11 et 12 du nouveau Conseil d’administration, avec des mandats se terminant au début du mandat régulier suivant spécifié pour chacun de ces sièges dans l’Article VI, section 8(1)(d) et (f) des nouveaux Statuts, et doit informer par écrit le secrétaire de l’ICANN de ses choix.
6. Jusqu’à la constitution du Conseil du ccNSO, le délégué au Comité de nomination établi par les nouveaux Statuts est désigné par la Conseil d'administration de transition ou par le nouveau Conseil d'administration, en fonction de celui qui est en vigueur au moment où une nomination particulière est nécessaire, après consultation avec les membres de la communauté des ccTLD. Lors de la constitution du Conseil du ccNSO, le délégué au comité de nomination nommé par le Conseil d’administration de transition ou par le nouveau Conseil d'administration conformément à cette section 4(9) en service reste en place, mais le Conseil d’administration peut remplacer ce délégué par un autre de son choix dans les trois mois après la fin de la réunion annuelle de l’ICANN, ou en cas de vacance du poste. Les nominations ultérieures du délégué au comité de nomination décrites dans l’Article VII, section 2(8)(c) sont effectuées par le Conseil du ccNSO.
Section 5. ORGANISME DE SOUTIEN RELATIF AUX NOMS GÉNÉRIQUES
1. L’organisme de soutien relatif aux noms génériques cesse ses activités lors de l’adoption de cet article de transition, mais le Conseil des noms de l’organisme de soutien relatif aux noms de domaine peut agir dans le but limité d'autoriser le transfert de tous les fonds qu'il a collectés au profit de l'organisme de soutien relatif aux noms génériques.
2. L’organisme de soutien relatif aux noms génériques (« GNSO » pour Generic Names Supporting Organization) débute ses activités lors de l’adoption de cet article de transition, et les six collèges suivants du DNSO deviennent automatiquement des collèges de l’organisme de soutien des noms génériques, conformément à leur charte existant au début :
a. Le collège regroupant des entités utilisant Internet à des fins commerciales du DNSO devient le collège regroupant des utilisateurs d’Internet à des fins commerciales du GNSO.
b. Le collège regroupant les registres de gTLD devient le collège regroupant les registres de gTLD du GNSO.
c. Le collège regroupant les fournisseurs d’accès à Internet et de services Web du DNSO devient le collège regroupant les fournisseurs d’accès à Internet et de services Web du GNSO.
d. Le collège regroupant les utilisateurs non commerciaux du DNSO devient le collège regroupant les utilisateurs non commerciaux du GNSO.
e. Le collège regroupant les bureaux d’enregistrement du DNSO devient le collège regroupant les bureaux d’enregistrement du GNSO.
f. Le collège regroupant les marques déposées, les autres propriétés intellectuelles et les intérêts anti-contrefaçon du DNSO devient le collège représentant les intérêts de propriété intellectuelle du GNSO.
3. Nonobstant l’adoption ou l’efficacité des nouveaux Statuts, chaque collège du GNSO décrit dans le paragraphe 2 de cette Section 5 continue à fonctionner comme avant et les activités officielles de groupe d’études ou autres du collège doivent être modifiées avant toute action du collège, à condition que chaque collège du GNSO soumette au secrétaire de l’ICANN une nouvelle charte et une nouvelle déclaration des procédures de fonctionnement, adoptée conformément aux processus du collège et respectant les termes des nouveaux Statuts, au plus tard le 15 juillet 2003.
4. Jusqu’à la fin de la réunion annuelle de l’ICANN en 2003, le Conseil du GNSO est constitué de trois représentants de chaque collège du GNSO plus, sur sélection par le Comité de nomination, trois personnes sélectionnées par ce comité. Il peut également compter des agents de liaison nommés par le Comité consultatif gouvernemental et l'ALAC (intérim), conformément à l’Article X, section 3(1) des nouveaux Statuts. Après cela, la composition du Conseil du GNSO doit être conforme aux nouveaux Statuts, qui peuvent être parfois modifiés, sans tenir compte de cet article de transition. L'ensemble des comités, groupes d’études, groupes de travail, comités de proposition et groupes équivalents établis par le Conseil des noms du DNSO et existant avant l’adoption de cet article de transition continuent à exister en tant que groupes du Conseil du GNSO, avec les mêmes chartes, critères d'appartenance et activités, sujets à modifications sur action du Conseil du GNSO.
5. Lors de l'adoption de cet article de transition, les trois représentants du Conseil des noms de l'organisme relatif au soutien des noms de domaine (« DNSO » pour Domain Name Supporting Organization) de chacun des six collèges du DNSO doit siéger en tant que représentant du Conseil du GNSO, de la façon suivante :
a. Les trois représentants du collège regroupant des entités utilisant Internet à des fins commerciales du DNSO doivent siéger en tant que représentant du collège regroupant les utilisateurs d’Internet à des fins commerciales du GNSO.
b. Les trois représentants du collège regroupant les registres de gTLD du DNSO doivent siéger en tant que représentants du collège regroupant les registres de gTLD du GNSO.
c. Les trois représentants du collège regroupant les fournisseurs d'accès à Internet et de services Web du DNSO doivent siéger en tant que représentants du collège regroupant les fournisseurs d'accès à Internet et de services Web du GNSO.
d. Les trois représentants du collège regroupant les utilisateurs non commerciaux du DNSO doit siéger en tant que représentant du collège regroupant les utilisateurs non commerciaux du GNSO.
e. Les trois représentants du collège regroupant les bureaux d’enregistrement du DNSO doivent siéger en tant que représentants du collège regroupant bureaux d’enregistrement du GNSO.
f. Les trois représentants du collège regroupant les marques déposées, les autres propriétés intellectuelles et les intérêts anti-contrefaçon du DNSO doivent siéger en tant que représentants du collège regroupant les intérêts de propriété intellectuelle du GNSO.
6. Les mandats des membres du Conseil du GNSO décrits dans le paragraphe 5 de cette Section 5 vont jusqu’à leur terme selon les anciens Statuts, mais les mandats des membres du Conseil du GNSO se terminent à la fin de la réunion annuelle de l'ICANN en 2003. Tout poste vacant avant ce moment au Conseil du GNSO décrit dans le paragraphe 5 de cette Section 5 doit être pourvu par le collège représenté par le poste vacant pour le reste de la durée du mandat, jusqu'à la fin de la réunion annuelle de l'ICANN en 2003. En sélectionnant trois personnes devant travailler au sein du Conseil du GNSO, le Comité de nomination initial en désigne un pour effectuer un mandat jusqu’à la fin de la réunion annuelle de l’ICANN en 2004 et les deux autres pour effectuer des mandats jusqu’à la fin de la réunion annuelle de l’ICANN en 2005.
7. Rapidement après l’adoption de cet article de transition, l’organisation de soutien des noms génériques doit, par l’intermédiaire du Conseil du GNSO, sélectionner des administrateurs afin de pourvoir des sièges 13 et 14 du nouveau Conseil d’administration, dont les mandats se terminent au début des premier mandats réguliers spécifiés pour chacun de ces sièges dans l’Article VI, section 8(1)(d) et (e) des nouveaux Statuts, et doit informer par écrit le secrétaire de l’ICANN de ses choix.
8. En l’absence d’autres actions dans ce domaine par le nouveau Conseil d’administration, chaque collège du GNSO doit sélectionner deux représentants au Conseil du GNSO avant le 1er octobre 2003, et doit informer le secrétaire de l’ICANN de ses choix. Chaque collège doit désigner un de ces représentants pour effectuer un mandat d’un an, et un pour effectuer un mandat de deux ans. Chaque successeur de ces représentants devra effectuer un mandat de deux ans.
9. Lors de l’adoption de cet article de transition, et avant toute action du Conseil d'administration de l'ICANN, le Conseil du GNSO doit assumer la responsabilité des annonces et des listes de discussion par courrier électronique de l’Assemblée générale du DNSO.
10. Chaque collège défini dans le paragraphe 5 de cette Section 5 désigné pour sélectionner un délégué au Comité de nomination, conformément à l’Article VII, section 2 des nouveaux Statuts, doit rapidement, lors de l’adoption de cet article de transition, informer le secrétaire de l’ICANN de la ou des personne(s) sélectionnée(s) pour officier en tant que délégué(s).
Section 6. ORGANISME DE SOUTIEN RELATIF AUX PROTOCOLES
L’ Organisme de soutien relatif aux protocoles cité dans les anciens Statuts est supprimé.
Section 7. COMITÉS CONSULTATIFS ET GROUPE DE LIAISON TECHNIQUE
1. Lors de l’adoption des nouveaux Statuts, le Comité consultatif gouvernemental continue à fonctionner conformément à ses principes et pratiques de fonctionnement existants, jusqu’à ce que le comité prenne les mesures qui s’imposent. Le Comité consultatif gouvernemental peut désigner des agents de liaison appelés à travailler avec d’autres organes de l’ICANN conformément aux nouveaux Statuts, en informant le secrétaire de l’ICANN par écrit. Rapidement, lors de l’adoption de cet article de transition, le Comité consultatif gouvernemental doit informer le secrétaire de l'ICANN de la personne sélectionnée comme délégué au Comité de nomination, conformément à l’Article VII, section 2 des nouveaux Statuts,.
2. Les organisations désignées comme membres du Groupe de liaison technique conformément à l’Article XI-A, section 2(2) des nouveaux Statuts doivent chacune désigner les deux experts techniques individuels décrits dans l’Article XI-A, section 2(6) des nouveaux Statuts, en informant le secrétaire de l’ICANN par écrit. Le plus rapidement possible, le délégué du Groupe de liaison technique dans le Comité de nomination doit être sélectionné conformément à l'Article XI-A, section 2(7) des nouveaux Statuts.
3. Lors de l’adoption des nouveaux Statuts, le Comité consultatif sur la sécurité et la stabilité (SSAC pour Security and Stability Advisory Committee) continue à fonctionner conformément à ses principes et pratiques de fonctionnement existants, jusqu’à ce que le comité prenne les mesures qui s’imposent. Rapidement, lors de l’adoption de cet article de transition, le Comité consultatif sur la sécurité et la stabilité doit informer le secrétaire de l'ICANN de la personne sélectionnée comme délégué au Comité de nomination, conformément à l’Article VII, section 2(4) des nouveaux Statuts.
4. Lors de l’adoption des nouveaux Statuts, le Comité consultatif du serveur racine (RSSAC pour Root Server System Advisory Committee) continue à fonctionner conformément à ses principes et pratiques de fonctionnement existants, jusqu’à ce que le comité prenne les mesures qui s’imposent. Rapidement, lors de l’adoption de cet article de transition, le Comité consultatif du serveur racine doit informer le secrétaire de l'ICANN de la personne sélectionnée comme délégué au Comité de nomination, conformément à l’Article VII, section 2(3) des nouveaux Statuts.
5. Comité consultatif des utilisateurs d’Internet (ALAC pour At-Large Advisory Comittee)
a. Un Comité consultatif des utilisateurs d’Internet (ALAC) doit exister jusqu’au moment où l'ICANN reconnait, par la mise en place d'un protocole d'accord, l’ensemble des groupes régionaux d'organisations d'utilisateurs d'Internet (GROUI) identifiés dans l’article XI, section 2(4) des nouveaux Statuts.. Le Comité consultatif des utilisateurs d’Internet (ALAC) est constitué de (1) dix individus (deux pour chaque région de l’ICANN) sélectionnés par le Conseil d’administration de l’ICANN après nomination par le Comité consultatif des utilisateurs d’Internet (ALAC) et (2) cinq individus supplémentaires (un pour chaque région de l’ICANN) sélectionnés par le Comité de nomination initial le plus rapidement possible conformément aux principes établis dans l’Article VII, section 5 des nouveaux Statuts. Le Comité de nomination initial doit désigner deux de ces individus pour effectuer des mandats jusqu’à la fin de la réunion annuelle de l’ICANN de 2004 et trois d’entre eux pour effectuer des mandats jusqu’à la fin de la réunion annuelle de l’ICANN de 2005.
b. Lors de l’entrée de chaque GROUI dans un protocole d'accord de ce type, cette entité doit être habilitée à sélectionner deux personnes étant citoyens et résidents de cette région pour qu’ils soient membres du Comité consultatif des utilisateurs d’Internet (ALAC) établi par l’article XI, section 2(4) des nouveaux Statuts.. Lors de la notification par écrit de l’entité au secrétaire de l’ICANN de ce type de sélections, ces personnes pourvoient immédiatement les sièges pourvus jusqu’à cette notification par les membres du Comité consultatif des utilisateurs d’Internet (ALAC) intérimaire précédemment choisis par le Conseil d’administration de la région du GROUI.
c. Lorsque les personnes sélectionnées par les cinq GROUI prennent leurs sièges, le Comité consultatif des utilisateurs d’Internet (ALAC) intérimaire devient le Comité consultatif des utilisateurs d’Internet (ALAC), conformément à l’article XI, section 2(4) des nouveaux Statuts. Les cinq individus sélectionnés dans le Comité consultatif des utilisateurs d'Internet (ALAC) intérimaire par le Comité de nomination deviennent membres du Comité consultatif des utilisateurs d'Internet jusqu’à la fin du mandat pour lequel ils ont été choisis.
d. Rapidement, lors de sa création, le Comité consultatif des utilisateurs d’Internet (ALAC) doit informer le secrétaire de l'ICANN des personnes sélectionnées comme délégués au Comité de nomination, conformément à l’Article VII, section 2(6) des nouveaux Statuts.
Les membres du bureau de l’ICANN (définis dans l’Article VIII des nouveaux Statuts) doivent être élus par le Conseil d’administration de l’ICANN en place lors de la réunion annuelle de 2002 pour être en fonction jusqu'à la réunion annuelle de 2003.
Section 9. GROUPES NOMMÉS PAR LE PRÉSIDENT
Nonobstant l’adoption ou l'efficacité des nouveaux Statuts, les groupes d’études et les autres groupes nommés par le président de l’ICANN conservent la même constitution, la même portée d’action et le même fonctionnement jusqu’à ce que des modifications soient effectuées par le président.
Section 10. CONTRATS AVEC L’ICANN
Nonobstant l’adoption ou l’efficacité des nouveaux Statuts, tous les contrats, y compris les contrats de travail et de conseil, souscrits par l’ICANN restent effectifs conformément à leurs termes.
Annexe A : Processus d’élaboration des politiques du GNSO
Les processus suivants doivent gouverner le processus d’élaboration des politiques (« PDP pour Policy Development Process) du GNSO jusqu’au moment où des modifications sont recommandées au Conseil d’administration de l’ICANN (« Conseil d’administration ») et validées.
1. Proposition d'un enjeu à aborder
Un enjeu peut être abordé dans le cadre du processus d’élaboration des politiques des façons suivantes :
a. Lancement par le Conseil d’administration. Le Conseil d’administration peut lancer le processus d’élaboration des politiques en ordonnant au Conseil du GNSO (« Conseil ») de lancer le processus exposé dans cette annexe.
b. Lancement par le Conseil. Le Conseil du GNSO peut lancer le processus d’élaboration des politiques par le vote d’au moins vingt-cinq pourcents (25 %) des membres présents à toute réunion au cours de laquelle une motion qui lance le processus d’élaboration des politiques est adoptée.
c. Lancement par un comité consultatif. Un comité consultatif peut proposer un enjeu de développement des politiques à aborder en lançant le processus de développement des politiques et en transmettant cette requête au Conseil du GNSO.
Dans les quinze (15) jours civils après réception (1) d’une instruction du Conseil d’administration ; (2) d’une motion correctement soutenue d'un membre du Conseil ; ou (3) d’une motion correctement soutenue d’un Comité consultatif, le chef de l'équipe crée un rapport. Chaque rapport doit traiter au minimum des sujets suivants :
a. Enjeu proposé à la discussion ;
b. Identité de la partie soumettant l’enjeu de discussion ;
c. Mesure dans laquelle cette partie est concernée par cet enjeu ;
d. Soutien en faveur du lancement d’un PDP pour l’enjeu en question ;
e. Recommandation du chef de l’équipe pour que le Conseil lance le PDP pour cet enjeu (« recommandation de l’équipe »). Chaque recommandation de l’équipe doit inclure l’opinion du Conseil général de l’ICANN afin de voir si l’enjeu proposé pour lancer le PDP relève réellement du domaine de compétence du processus d’élaboration des politiques de l’ICANN et du GNSO. Afin de déterminer si l’enjeu concerné se situe dans le cadre du processus de politiques de l’ICANN, l’avocat-conseil doit vérifier s'il remplit les conditions suivantes :
1. relever du domaine de compétence défini par la déclaration de mission de l'ICANN ;
2. pouvoir être élargi à plusieurs situations ou organisations ;
3. être susceptible de rester longtemps applicable ou d’actualité (étant entendu que des mises à jour occasionnelles seront nécessaires) ;
4. pouvoir servir de base pour de futures prises de décision ; ou
5. impliquer ou affecter une politique existante de l’ICANN.
f. Dans la limite des quinze (15) jours, le chef de l’équipe devra distribuer le rapport à l’ensemble du Conseil en vue d’un vote sur la question du lancement du PDP, comme décrit ci-dessous.
Le Conseil doit lancer le PDP de la façon suivante :
a. Enjeu abordé par le Conseil d’administration. Si le Conseil d’administration pousse le Conseil à lancer le PDP, le Conseil doit se rassembler dans les quinze (15) jours civils suivant la réception du rapport, sans vote intermédiaire du Conseil.
b. Enjeu abordé par un organe différent du Conseil d’administration. Si un enjeu politique est proposé à la discussion au Conseil par le biais d'un rapport, le Conseil doit se réunir dans les quinze (15) jours civils suivant la réception de ce type de rapport, afin de voter le lancement ou non du PDP. Ce type de réunion peut être organisé de n’importe quelle façon jugée appropriée par le Conseil, notamment en personne, par conférence téléphonique ou par courrier électronique.
c. Vote du Conseil. Un vote de plus de 33 % des membres du Conseil présents en faveur du lancement du PDP suffit à lancer le PDP, à moins que la recommandation à l’équipe n’ait déclaré que l’enjeu ne dépendait pas du domaine de compétence du processus d'élaboration des politiques de l'ICANN ou du GNSO, auquel cas un vote à la majorité absolue des membres du Conseil présents en faveur du lancement du PDP est nécessaire pour lancer le PDP.
Lors de la réunion du Conseil lançant le PDP, le Conseil décide, par un vote à la majorité absolue des membres présents à la réunion, s’il faut nommer un groupe d’études pour traiter l’enjeu. Si le Conseil vote :
a. En faveur de l'instauration d'un groupe d'étude, il doit le faire en respectant les dispositions du paragraphe 7 ci-dessous.
b. Contre l’instauration d’un groupe d’étude, il doit collecter des informations au sujet de l’enjeu politique en respectant les dispositions du paragraphe 8 ci-dessous.
5. Section 1. Composition et sélection des groupes d’études
a. Lors du vote pour la nomination d’un groupe d’étude, le Conseil invite chaque collège du GNSO à nommer un individu pour prendre part au groupe d’étude. En outre, le Conseil peut nommer jusqu’à trois conseillers extérieurs pour siéger au groupe d’étude. (Chaque membre d’un groupe d’études est désigné dans cette annexe par le terme « Représentant », et collectivement, ils sont désignés par le terme « Représentants »). Le Conseil peut augmenter le nombre de représentants par collège siégeant dans un groupe d’études en son nom si les circonstances l’exigent et le permettent.
b. Tout collège souhaitant nommer un représentant dans le groupe d’études doit soumettre le nom de la personne désignée par le collège au chef de l’équipe dans les dix (10) jours civils après une demande de ce type pour être inclus dans le groupe de travail. Ce genre de personne désignée n’a pas besoin d’être un membre du Conseil, mais il doit être un individu ayant un intérêt, et dans l’idéal des connaissances et de l’expertise, dans le domaine à développer, en plus de la capacité à consacrer beaucoup de temps aux activités du groupe d’étude.
c. Le Conseil peut également suivre d'autres options qui lui semblent appropriées pour assister dans le PDP, notamment la nomination d’un individu particulier ou d’une organisation pour rassembler des informations sur l’enjeu ou planifier des réunions de délibération ou d'information. Toutes les informations de ce type doivent être soumises au chef de l'équipe dans les trente-cinq (35) jours après le lancement du PDP.
6. Notification publique du lancement du PDP
Après le lancement du PDP, l’ICANN doit publier une notification de ce type d'action sur le site Web. Une période de recueil des commentaires du public doit être lancée pour l’enjeu pour une période de vingt (20) jours civils après le lancement du PDP. Le chef de l’équipe ou un autre représentant désigné de l’ICANN doit passer en revue les commentaires du public et les incorporer dans un rapport (le « Rapport des commentaires du public ») devant être inclus soit dans le Rapport préliminaire du groupe d'étude, soit dans le Rapport initial, selon les besoins.
a. Rôle du groupe d'études. Si un groupe d’études est créé, son rôle est généralement de (1) rassembler des informations détaillant les points de vue des collèges officiels, s’il en existe au sein du GNSO ; et (2) obtenir des informations permettant au Rapport du groupe d'études d'être aussi complet et informatif que possible.
Le groupe d’études ne doit pas disposer d’une autorité officielle de prise de décisions. Le rôle du groupe d’études est davantage de rassembler des informations consignant les points de vue de différentes parties ou de différents groupes de la façon la plus spécifique et la plus compréhensive possible, permettant ainsi au Conseil d’avoir une délibération pertinente et informée sur l’enjeu.
b. Charte ou termes de référence du groupe d’étude. Le Conseil, avec l’assistance du chef de l’équipe, doit développer une charte ou des termes de référence pour le groupe d’études (la « Charte ») dans les dix (10) jours civils suivant le lancement du PDP. Une charte de ce type doit inclure :
1. l’enjeu devant être traité par le groupe d’études, tel qu’il a été défini pour le vote avant que le Conseil ne lance le PDP ;
2. le planning spécifique que le groupe d’études doit respecter, conformément aux indications ci-dessous, à moins que le Conseil d’administration ne décide qu’il existe une raison valable de l’étendre ; et
3. toutes les instructions spécifiques du Conseil pour le groupe d’études, y compris s'il doit ou non solliciter l’avis de conseillers extérieurs sur l’enjeu abordé.
Le groupe d'études doit préparer ses rapports et mener ses activité conformément à la charte. Toute demande de s’éloigner de la charte doit être officiellement présentée au Conseil et ne peut être mise en œuvre qu'après un vote de la majorité des membres du Conseil présents.
c. Nomination du président du groupe d’études. Le chef de l’équipe doit organiser la première réunion du groupe d'études dans les cinq (5) jours civils suivant l’entrée en vigueur de la Charte. Lors de la réunion initiale, les membres du groupe d’études doivent, entre autres choses, voter pour nommer le président du groupe d'études. Le président est responsable de l’organisation des activités du groupe d’études, notamment la compilation du Rapport du groupe d'études. Le président d'un groupe d'études doit être un membre du Conseil.
1. Déclarations des collèges. Les représentants ont chacun la responsabilité de solliciter le point de vue de leur collège, au minimum, et tous les commentaires qu'ils trouvent adaptés concernant l’enjeu abordé. Ce point de vue et les autres commentaires doivent, dans la mesure du possible, être soumis sous la forme d'une déclaration officielle au président du groupe d'études (une « Déclaration du collège » pour chacun) dans les trente-cinq 35) jours civils suivant le lancement du PDP. Chaque déclaration de collège doit inclure au moins les éléments suivants :
(1) Si un vote à la majorité absolue a été obtenu, une déclaration claire du point de vue du collège sur l’enjeu ;
(2) Si aucun vote à la majorité absolue n’a été obtenu, une déclaration claire des points de vue des membres du collège ;
(3) Une déclaration claire de la façon dont le collège est arrivé à ce(s) point(s) de vue. Précisément, la déclaration doit détailler les réunions du collège, les téléconférences ou les autres moyens de délibérer sur un enjeu, ainsi qu’une liste des membres ayant participé ou ayant soumis leur point de vue ;
(4) Une analyse de la façon dont l’enjeu affecte le collège, y compris tout impact financier sur le collège ; et
(5) Une analyse de la période de temps nécessaire estimée pour mettre en œuvre la politique.
2. Conseillers extérieurs. Le groupe d'études peut, s’il l’estime approprié ou judicieux, solliciter les opinions de conseillers extérieurs, d’experts ou d’autres membres du secteur public, en plus de celles des membres du collège. Les opinions de ce type doivent être exposées dans un rapport préparé par des conseillers extérieurs de ce genre et (1) clairement signalées comme venant de conseillers extérieurs ; (2) accompagnés par une déclaration détaillée des éléments suivants au sujet de conseillers : (A) qualifications et expérience dans le domaine ; et (B) conflits d’intérêt potentiels. Ces rapports doivent être soumis sous la forme d’une déclaration officielle au président du groupe d’études dans les trente-cinq (35) jours civils suivant le lancement du PDP.
e. Rapport de groupe d'études. Le président du groupe d’études, en travaillant avec le chef de l’équipe, doit compiler les Déclarations de collèges, le Rapport des commentaires du public et les autres informations et rapports, dans la mesure du possible, dans un seul document (« Rapport préliminaire du groupe d’études ») et distribuer le Rapport préliminaire du groupe d’études à l’ensemble du groupe d'études dans les quarante (40) jours civils suivant le lancement du PDP. Le groupe d’études doit organiser une réunion finale dans les cinq (5) jours après la date de distribution du Rapport préliminaire du groupe d'études afin de délibérer sur les enjeux abordés et d'essayer d'atteindre un vote à la majorité absolue. Dans les cinq (5) jours civils suivant la réunion finale du groupe d’études, le président du groupe d’études et le chef de l’équipe doivent créer le rapport final du groupe d'études (le « Rapport du groupe d’études ») et le publier sur le site de commentaires. Chaque rapport de groupe d’études doit comprendre les éléments suivants :
1. Une déclaration claire du point de vue atteint par le vote à la majorité absolue du groupe d’études sur l’enjeu abordé ;
2. Si aucun vote à la majorité absolue n’a été atteint, une déclaration claire de tous les points de vue des membres du groupe d'études soumise dans le délai de vingt jours pour la soumission de rapports de collèges. Chaque déclaration doit indiquer clairement (1) les raisons ayant mené au point de vue et (2) le(s) collège(s) ayant soutenu le point de vue ;
3. Une analyse de la façon dont l’enjeu affecte chaque collège du groupe d'études, y compris tout impact financier sur le collège ;
4. Une analyse de la période de temps nécessaire estimée pour mettre en œuvre la politique ; et
5. Les avis des conseillers extérieurs nommés dans le groupe de travail par le Conseil, accompagnés par une déclaration détaillée des éléments suivants au sujet de conseillers : (1) qualifications et expérience dans le domaine ; et (2) conflits d’intérêt potentiels.
8. Procédure si aucun groupe d’études n’est formé
a. Si le Conseil décide de ne pas instaurer de groupe d’études, le Conseil demande que, dans les dix (10) jours civils suivants, chaque collège nomme un représentant pour solliciter les points de vue du collège sur l’enjeu abordé. Chaque représentant de ce type doit se voir demander de soumettre un Rapport de collège au chef de l'équipe dans les trente-cinq (35) jours civils suivant le lancement du PDP.
b. Le Conseil peut également suivre d'autres options qui lui semblent appropriées pour assister dans le PDP, notamment la nomination d’un individu particulier ou d’une organisation pour rassembler des informations sur l’enjeu ou planifier des réunions de délibération ou d'information. Toutes les informations de ce type doivent être soumises au chef de l'équipe dans les trente-cinq (35) jours après le lancement du PDP.
c. Le chef de l’équipe récupère l’ensemble des Rapports de collèges, des Rapports de commentaires du public et autres informations et les compile en un Rapport initial (avant de le publier sur le site de commentaires) dans les cinquante (50) jours civils suivant le lancement du PDP. Après cela, le PDP doit suivre les dispositions du point 9 ci-dessous pour créer un Rapport final.
9. Commentaires du public au groupe d’études ou Rapport initial
a. La période de recueil des commentaires du public dure pendant les vingt (20) jours suivant la publication du Rapport du groupe d'études ou du Rapport initial. Tout individu ou toute organisation peut soumettre des commentaires pendant la période de recueil des commentaires du public, y compris les collèges n’ayant pas participé au groupe d’études. L’ensemble des commentaires doivent être accompagnés du nom de l’auteur du commentaire, de son expérience dans le domaine et de l’intérêt de l'auteur pour l’enjeu.
b. À la fin de la période de vingt (20) jours, le chef de l’équipe est responsable de la révision des commentaires reçus et de l’ajout de ceux paraissant appropriés pour être inclus, à la discrétion du chef de l’équipe, dans le Rapport du groupe d’études ou dans le Rapport initial (qui, associés, forment le « Rapport final »). Le chef de l’équipe n’est pas contraint d’inclure tous les commentaires faits pendant la période de recueil des commentaires en indiquant chaque commentaire fait par un individu ou une organisation.
c. Le chef de l’équipe doit préparer le Rapport final et le soumettre au président du Conseil dans les dix (10) jours civils suivant la fin de la période de recueil des commentaires du public.
a. Lors de la réception d’un Rapport final, qu’il soit le fruit du travail du groupe d’études ou autre, le président du Conseil (1) distribue le Rapport final à l’ensemble des membres du Conseil ; et (2) demande une réunion du Conseil dans les dix (10) jours civils suivants. Le Conseil peut débuter ses délibérations sur l’enjeu avant la réunion officielle, notamment par le biais de réunions en face à face, de conférences téléphoniques, de discussions par courriers électroniques et de tout autre moyen que le Conseil souhaite choisir. Le processus de délibération doit avoir pour point culminant une réunion officielle du Conseil en face à face ou via téléconférence, au cours de laquelle le Conseil travaille dans le but d’atteindre un vote à la majorité absolue des présents pour le Conseil d’administration.
b. Le Conseil peut, s’il en décide ainsi, solliciter les opinions de conseillers extérieurs lors de la réunion finale. Les opinions de ces conseillers, si elles sont relayées par le Conseil, doivent être (1) décrites dans le rapport du Conseil au Conseil d’administration, (2) précisément identifiées comme venant d'un conseiller extérieur ; et (3) accompagnées d’une déclaration détaillée des éléments suivants au sujet du conseiller : (a) qualifications et expérience dans le domaine ; et (b) conflits d’intérêt potentiels.
11. Rapport du Conseil au Conseil d’administration
Le chef de l'équipe doit être présent lors de la réunion finale du Conseil, et dispose de cinq (5) jours civils après la réunion pour incorporer les points de vue du Conseil dans un rapport devant être soumis au Conseil d’administration (le « Rapport du Conseil d’administration »). Le rapport du Conseil d’administration doit contenir au minimum les éléments suivants :
a. Une déclaration claire de toute recommandation validée par le vote à la majorité absolue du Conseil ;
b. Si aucun vote à la majorité absolue n’a été obtenu, une déclaration claire des points de vue des membres du Conseil. Chaque déclaration doit indiquer clairement (1) les raisons ayant mené à chaque point de vue et (2) le(s) collège(s) ayant soutenu le point de vue ;
c. Une analyse de la façon dont l’enjeu affecte chaque collège, y compris tout impact financier sur le collège ;
d. Une analyse de la période de temps nécessaire estimée pour mettre en œuvre la politique ;
e. Tout avis d’un conseiller extérieur suivi, devant être accompagné par une déclaration détaillée des éléments suivants au sujet du conseiller : (1) qualifications et expérience dans le domaine ; et (2) conflits d'intérêt potentiels ;
f. Le Rapport final soumis au Conseil ; et
g. Une copie des minutes des délibérations du Conseil sur l’enjeu de la politique, incluant l’ensemble des opinions exprimées au cours de ces délibérations, accompagnées par une description des personnes ayant exprimé ces opinions.
Un vote à la majorité absolue des membres du Conseil sera préféré pour refléter le point de vue du Conseil, et peut être transmis au Conseil d'administration comme recommandation du Conseil. Les abstentions ne sont pas autorisées ; et tous les membres du Conseil doivent exprimer leur vote, à moins qu’ils présentent un intérêt financier dans l’issue de l’enjeu de la politique. Nonobstant les faits précédemment cités, comme exposé ci-dessus, l’ensemble des points de vue exprimés par les membres du Conseil au cours du PDP doivent être inclus dans le Rapport du Conseil d’administration.
13. Vote du Conseil d'administration
a. Le Conseil d’administration se réunit pour discuter des recommandations du Conseil du GNSO le plus rapidement possible après la réception du Rapport du Conseil d’administration de la part du chef de l'équipe.
b. Dans l’éventualité où le Conseil a atteint un vote à la majorité absolue, le Conseil d’administration doit adopter la politique en accord avec la recommandation du vote à la majorité absolue du Conseil, à moins qu'un vote de plus de soixante-six pourcents (66 %) du Conseil d’administration ne détermine qu’une politique de ce type ne correspond pas au meilleur intérêt de la communauté ICANN ou de l’ICANN.
c. Dans l’éventualité où le Conseil d’administration détermine de pas suivre la recommandation du vote à la majorité absolue du Conseil, le Conseil d’administration doit (1) organiser les raisons de cette décision dans un rapport destiné au Conseil (la « Déclaration du Conseil d’administration ») ; et (2) soumettre la Déclaration du Conseil d’administration au Conseil.
d. Le Conseil doit passer en revue la Déclaration du Conseil d'administration pour une discussion avec le Conseil d'administration dans les vingt (20) jours civils suivant la réception par le Conseil de la Déclaration du Conseil d'administration. Le Conseil d’administration doit déterminer la méthode (par ex. par téléconférence, courrier électronique ou autre) que le Conseil et le Conseil d’administration utiliseront pour la discussion.
e. À la fin des discussions entre le Conseil et le Conseil d’administration, le Conseil doit se réunir pour confirmer ou modifier ses recommandations, puis communiquer cette décision (la « Recommandation complémentaire ») au Conseil d’administration, en incluant une explication de sa recommandation actuelle. Dans l’éventualité où le Conseil est en mesure d’atteindre un vote à la majorité absolue sur la Recommandation complémentaire, le Conseil d’administration doit adopter la recommandation, à moins qu’un vote de plus de soixante-six pourcents (66 %) du Conseil d'administration ne détermine qu’une politique de ce type ne correspond pas au meilleur intérêt de la communauté ICANN ou de l'ICANN.
f. Dans le cas où le Conseil ne serait pas capable d’atteindre un vote à la majorité absolue, un vote de la majorité du Conseil d’administration est suffisant.
g. Lorsqu'une décision finale à propos d’une recommandation du Conseil du GNSO ou une Recommandation complémentaire est dans les délais, le Conseil d'administration doit organiser un vote préliminaire et, dans la mesure du possible, publier une décision indicative permettant une période de dix (10) jours de recueil des commentaires du public avant une décision finale du Conseil d’administration.
14. Mise en œuvre de la politique
Lorsqu'une décision finale du Conseil d’administration est prise, le Conseil d’administration doit, selon les besoins, donner l’autorisation ou la direction à suivre à l’équipe de l’ICANN pour prendre toutes les dispositions nécessaires à la mise en œuvre de la politique.
15. Maintenance des enregistrements
Au cours du PDP, de la suggestion de politique à la décision finale du Conseil d’administration, l'ICANN assure la maintenance sur le site Web d’une page Web de suivi du Statut détaillant l'avancement de chaque enjeu abordé par le PDP, qui décrit :
a. La suggestion initiale d’une politique ;
b. Une liste de toutes les suggestions ne résultant pas dans la création d’un rapport ;
c. Le délai à respecter pour chaque politique ;
d. Toutes les discussions prises au sein du Conseil au sujet de la politique ;
e. Tous les rapports des groupes d’études, du chef de l’équipe, du Conseil et du Conseil d'administration ; et
16. Définitions supplémentaires
« Site de commentaires » et « site Web » désignent un ou plusieurs site(s) Web conçus par l’ICANN et sur lesquels des notifications et des commentaires au sujet du PDP seront publiés.
« Chef de l’équipe » désigne une ou des personne(s) de l’équipe de l’ICANN gérant le PDP.
« Vote à la majorité absolue » désigne un vote de plus de soixante-six (66) pourcents des membres présents à une réunion de l'organe concerné.
Annexe B : Processus d’élaboration des politiques du ccNSO (ccPDP)
Les processus suivants doivent gouverner le processus d’élaboration des politiques (« PDP ») du ccNSO :
1. Demande d’un rapport
Un rapport peut être demandé par les instances suivantes :
a. Conseil Le Conseil du ccNSO (dans cette Annexe B, le « Conseil ») peut demander la création d’un rapport par un vote affirmatif d’un minimum de sept des membres du Conseil présents à une réunion ou votant par courrier électronique.
b. Conseil d'administration. Le Conseil d’administration de l’ICANN peut demander la création d’un rapport en indiquant au Conseil de lancer le processus d’élaboration des politiques.
c. Organisme régional. Un ou plusieurs des organismes régionaux représentant les ccTLD au sein des régions reconnues par l’ICANN peuvent demander la création d'un rapport en indiquant au Conseil de lancer le processus d'élaboration des politiques.
d. Organisation de soutien ou Comité consultatif de l’ICANN. Une Organisation de soutien de l’ICANN ou un Comité consultatif de l’ICANN peut demander la création d’un rapport en indiquant au Conseil de lancer le processus d’élaboration des politiques.
e. Membres du ccNSO. Les membres du ccNSO peuvent demander la création d’un rapport par un vote affirmatif d’un minimum de dix des membres du ccNSO présents à une réunion ou votant par courrier électronique.
Toute demande de rapport doit être effectuée par écrit et doit définir l’enjeu sur lequel le rapport est demandé, avec des détails suffisants pour permettre la préparation du rapport. Il doit être ouvert au Conseil pour demander de plus amples informations ou entreprendre des recherches ou des investigations plus approfondies avec l’objectif de déterminer si le rapport demandé doit être créé ou non.
2. Création du rapport et Seuil de lancement
Dans les sept jours suivant un vote affirmatif, comme exposé dans le point 1(a) ci-dessus, ou la réception d’une demande, comme exposé dans les points 1 (b), (c), ou (d) ci-dessus, le Conseil doit nommer un responsable de la publication. Le responsable de la publication peut être un membre de l’équipe de l’ICANN (auquel cas les coûts du responsable de la publication sont supportés par l'ICANN) ou toute(s) autre(s) personne(s) sélectionnée(s) par le Conseil (auquel cas le ccNSO est responsable des coûts du responsable de la publication).
Dans les quinze (15) jours civils suivant la nomination (ou toute autre durée que le Conseil, en consultation avec le responsable de la publication, estime adaptée), le responsable de la publication doit créer un rapport . Chaque rapport doit traiter au minimum des sujets suivants :
a. Enjeu proposé à la discussion ;
b. Identité de la partie soumettant l’enjeu de la discussion ;
c. Mesure dans laquelle cette partie est concernée par cet enjeu ;
d. Soutien en faveur du lancement d’un PDP pour l’enjeu en question ;
e. Recommandation du responsable de la publication pour que le Conseil lance le PDP pour cet enjeu (la « recommandation du responsable de la publication »). Chaque recommandation du responsable doit inclure et être soutenue par l’opinion du Conseil général de l’ICANN concernant l’enjeu proposé pour lancer le PDP relève réellement du domaine de compétence du ccNSO. Lors de l’élaboration de son opinion, le Conseil général doit prendre en compte les éléments suivants :
1) L’enjeu concerné relève-t-il du domaine de compétence de l’ICANN ?
2) L’analyse des facteurs concernés conformément à l’Article IX, section 6(2) et à l’Annexe C démontre-t-elle formellement que l’enjeu concerné relève du domaine de compétence du ccNSO ?
Dans l’éventualité où le Conseil général atteint une opinion affirmative pour les points 1 et 2 ci-dessus, le Conseil général doit également examiner si l’enjeu :
3) Implique ou affecte une politique existante de l’ICANN ;
4) Est susceptible de servir de base pour de futures prises de décisions.
Dans tous les cas, la considération de révisions du ccPDP (cette Annexe B) ou du domaine de compétence du ccNSO (Annexe C) doit relever du domaine de compétence de l’ICANN et du ccNSO.
Dans l’éventualité où le Conseil général est de l’opinion que l’enjeu ne relève pas formellement du domaine de compétence du ccNSO, le responsable de la publication doit informer le Conseil de cette opinion. Si, après analyse des facteurs concernés conformément à l’Article IX, section 6 et à l’Annexe C, une majorité de 10 ou plus des membres du Conseil sont de l’opinion que l’enjeu relève du domaine de compétence du ccNSO, le président du ccNSO doit informer le responsable de la publication en conséquence. Le Conseil général et le Conseil du ccNSO doivent engager un dialogue selon les règles et les procédures convenus pour résoudre le problème. Dans l’éventualité où aucun accord n’est conclu entre le Conseil général et le Conseil quant à savoir si l’enjeu relève ou non du domaine de compétence du ccNSO, le vote de 15 membres ou plus du Conseil peut déterminer que l’enjeu relève du domaine de compétence du ccNSO. Le président du ccNSO doit informer le Conseil général et le responsable de la publication en conséquence. Le responsable de la publication doit ensuite émettre une recommandation déterminant si le Conseil doit ou non lancer le PDP en incluant à la fois l'opinion et l'analyse du Conseil général et du Conseil dans le rapport.
f. Dans l'éventualité où la recommandation du responsable est en faveur du lancement du PDP, une proposition de délai pour effectuer chacune des étapes du PDP exposées ici (frise du PDP).
g. Si possible, le rapport doit indiquer si le résultat est susceptible de résulter en une politique approuvée par le Conseil d’administration de l'ICANN. Dans certaines circonstances, il ne sera pas possible de le faire tant que des discussions approfondies sur l’enjeu n’auront pas eu lieu. Dans ces cas, le rapport doit indiquer cette incertitude. Une fois le rapport terminé, le responsable de la publication doit le distribuer à l’ensemble du Conseil afin qu’il vote pour ou contre le lancement du PDP.
3. Lancement du PDP
Le Conseil doit décider de lancer ou non le PDP de la façon suivante :
a. Dans les 21 jours suivant la réception d’un rapport de la part du responsable de la publication, le Conseil doit voter le lancement ou non du PDP. Ce vote doit avoir lieu lors d’une réunion organisée de n’importe quelle façon jugée appropriée par le Conseil, notamment en face à face ou par conférence téléphonique, mais si ce n’est pas faisable le vote peut avoir lieu par courrier électronique.
Un vote de dix ou plus des membres du Conseil présents en faveur du lancement du PDP est nécessaire pour lancer le PDP, à condition que le rapport indique que l’enjeu dépend du domaine de compétence de la déclaration de mission de l'ICANN et du ccNSO.
4. Décision de nommer ou non un groupe d'études ; Établissement d'un planning
Lors de la réunion du Conseil au cours de laquelle le PDP a été lancé (ou, si le Conseil utilise un vote par courrier électronique, lors de ce vote), conformément au point 3 ci-dessus, le Conseil doit décider, par un vote de la majorité des membres présents à la réunion (ou votant par courrier électronique), de nommer ou non un groupe d'études pour travailler sur l’enjeu abordé. Si le Conseil vote :
a. En faveur de l'instauration d'un groupe d'étude, il doit le faire en respectant les dispositions du point 7 ci-dessous.
b. Contre l’instauration d’un groupe d’étude, il doit collecter des informations au sujet de l’enjeu politique en respectant les dispositions du point 8 ci-dessous.
Le Conseil doit également, par un vote à la majorité absolue des membres présents à la réunion ou votant par courrier électronique, approuver ou modifier le planning du PDP défini dans le rapport.
5. Section 1. Composition et sélection des groupes d’études
a. Lors du vote pour la nomination d’un groupe d’études, le Conseil invite chaque organisation régionale (cf. l’Article IX, section 6) à nommer deux individus à participer au groupe d’études (les « Représentants »). En outre, le Conseil peut nommer jusqu’à trois conseillers (les « Conseillers ») extérieurs au ccNSO et, à la suite d’une demande officielle de participation du GAC dans le groupe d’études, accepter jusqu’à deux représentants du Comité consultatif gouvernemental à siéger dans le groupe d’études. Le Conseil peut augmenter le nombre de représentants siégeant dans un groupe d’études en son nom si les circonstances l’exigent et le permettent.
b. Toute organisation régionale souhaitant nommer des représentants dans le groupe d’études doit fournir les noms des représentants au responsable de la publication dans les dix (10) jours civils après une demande de ce type afin qu’ils soient inclus dans le groupe de travail. Les représentants de ce genre n’ont pas besoin d’être membres du Conseil, mais chacun d’entre eux doit être un individu ayant un intérêt, et dans l’idéal des connaissances et de l’expertise, dans le sujet abordé, en plus de la capacité à consacrer beaucoup de temps aux activités du groupe d’étude.
c. Le Conseil peut également suivre d'autres actions qui lui semblent appropriées pour assister dans le PDP, notamment la nomination d’un individu particulier ou d’une organisation pour rassembler des informations sur l’enjeu ou planifier des réunions de délibération ou d'information. Toutes les informations de ce type doivent être soumises au responsable de la publication conformément au planning du PDP.
6. Notification publique du lancement du PDP et période de recueil des commentaires
Après le lancement du PDP, l’ICANN doit publier une notification d'action sur le site Web et pour les autres organisations de soutien et Comités consultatifs de l’ICANN. Une période de recueil des commentaires (conformément au planning du PDP, et généralement long d’au minimum 21 jours) doit être lancée sur l’enjeu. Les commentaires doivent être acceptés de la part des responsables ccTLD, des autres organisations de soutien, des comités consultatifs et du public. Le responsable de la publication ou un autre représentant désigné du Conseil doit passer en revue les commentaires du public et les incorporer dans un rapport (le « Rapport des commentaires du public ») devant être inclus soit dans le Rapport préliminaire du groupe d'étude, soit dans le Rapport initial, selon les besoins.
7. Groupes d’études
a. Rôle du groupe d'études. Si un groupe d’études est créé, son rôle est de (1) rassembler des informations détaillant les postes des membres du ccNSO dans la région géographique et les autres parties ou groupes ; et (2) obtenir des informations permettant au Rapport du groupe d'études d'être aussi complet et informatif que possible afin de faciliter une délibération pertinente et informée du Conseil.
Le groupe d’études ne doit pas disposer d’une autorité officielle de prise de décisions. Le rôle du groupe d’études est davantage de rassembler des informations consignant les points de vue de différentes parties ou de différents groupes de la façon la plus spécifique et la plus complète possible, permettant ainsi au Conseil d’avoir une délibération pertinente et informée sur l’enjeu.
b. Charte ou termes de référence du groupe d’étude. Le Conseil, avec l’assistance du responsable de la publication, doit développer une charte ou des termes de référence pour le groupe d’études (la « Charte ») dans le temps désigné par le planning du PDP. Une charte de ce type doit inclure :
1. L’enjeu devant être traité par le groupe d’étude, tel qu’il a été défini pour le vote devant le Conseil qui a lancé le PDP ;
2. Le planning spécifique que le groupe de travail doit respecter, conformément aux indications ci-dessous, à moins que le Conseil ne décide qu’il existe une raison valable de l’étendre ; et
3. Toutes les instructions spécifiques du Conseil pour le groupe d’étude, y compris s'il doit ou non solliciter l’avis de conseillers extérieurs sur l’enjeu abordé.
Le groupe d’études doit préparer ses rapports et mener ses activités conformément à la charte. Toute demande de s’éloigner de la charte doit être officiellement présentée au Conseil et ne peut être mise en œuvre qu'après un vote de la majorité des membres du Conseil présents à la réunion ou votant par courrier électronique. Les exigences de quorum de l’Article IX, section 3(14) s’appliquent aux actions du Conseil jusqu’à ce point 7(b).
c. Nomination du président du groupe d’études. Le responsable de la publication doit organiser la première réunion du groupe d'études dans le temps désigné par le planning du PDP. Lors de la réunion initiale, les membres du groupe d’études doivent, entre autres choses, voter pour nommer le président du groupe d'études. Le président est responsable de l’organisation des activités du groupe d’études, notamment la compilation du Rapport du groupe d'études. Le président d'un groupe d'études doit être un membre du Conseil.
d. Collecte d’informations.
1. Déclarations des organisations régionales. Les représentants ont chacun la responsabilité de solliciter le point de vue de l’organisation régionale de leur région géographique, au minimum, et tous les autres commentaires qu'ils trouvent adaptés, notamment les commentaires des membres du ccNSO dans cette région qui ne sont pas membres de l’organisation régionale, au sujet de l’enjeu abordé. Le point de vue de l’organisation régionale et tous les autres commentaires collectés par les représentants doivent être soumis sous la forme d'une déclaration officielle au président du groupe d'études (une « Déclaration régionale » pour chacun) dans l'intervalle de temps indiqué par le planning du PDP. Chaque déclaration régionale doit inclure au moins les éléments suivants :
(1) Si un vote à la majorité absolue (défini par l’organisation régionale) a été obtenu, une déclaration claire du point de vue de l’organisation régionale sur l’enjeu ;
(2) Si aucun vote à la majorité absolue n’a été obtenu, une déclaration claire des points de vue des membres de l’organisation régionale ;
(3) Une déclaration claire de la façon dont l’organisation régionale est arrivée à ce(s) point(s) de vue. Précisément, la déclaration doit détailler les réunions, les téléconférences ou les autres moyens de délibérer sur un enjeu, ainsi qu’une liste des membres ayant participé ou ayant soumis leur point de vue ;
(4) Une déclaration des points de vue des membres du ccNSO qui ne sont pas membres de l’organisation régionale ;
(5) Une analyse de la façon dont l’enjeu affecte la région, y compris tout impact financier sur la région ; et
(6). Une analyse de la période de temps nécessaire estimée pour mettre en œuvre la politique.
2. Conseillers extérieurs. Le groupe d'études peut, à sa discrétion, solliciter les opinions de conseillers extérieurs, d’experts ou d’autres membres du public. Les opinions de ce type doivent être exposées dans un rapport préparé par des conseillers extérieurs de ce genre et (1) clairement indiquées comme venant de conseillers extérieurs ; (2) accompagnés par une déclaration détaillée des éléments suivants au sujet de conseillers : (a) qualifications et expérience dans le domaine ; et (b) conflits d’intérêt potentiels. Ces rapports doivent être soumis sous la forme d’une déclaration officielle au président du groupe d’études dans la période de temps indiquée dans le planning du PDP.
e. Rapport de groupe d'études. Le président du groupe d’études, en travaillant avec le responsable de la publication, doit compiler les Déclarations régionales, le Rapport des commentaires et les autres informations et rapports, dans la mesure du possible, dans un seul document (« Rapport préliminaire du groupe d’études ») et distribuer le Rapport préliminaire du groupe d’études à l’ensemble du groupe d'études dans la période de temps indiquée par le planning du PDP. Le groupe d'études doit organiser une réunion finale pour étudier les enjeux et essayer d'atteindre un vote à la majorité absolue. Après la réunion finale du groupe d’études, le président du groupe d’études et le responsable de la publication doivent créer le rapport final du groupe d'études (le « Rapport du groupe d’études ») et le publier sur le site Web et auprès des autres Organisations de soutien et Comités consultatifs de l’ICANN. Chaque rapport de groupe d’études doit comprendre les éléments suivants :
1. Une déclaration claire du point de vue atteint par le vote à la majorité absolue (66 %) du groupe d’études sur l’enjeu abordé ;
2. Si aucun vote à la majorité absolue n’a été atteint, une déclaration claire de tous les points de vue des membres du groupe d'études soumise dans le délai imparti pour la soumission de rapports de collèges. Chaque déclaration doit indiquer clairement (1) les raisons ayant mené à chaque point de vue et (2) les Organisations régionales ayant soutenu le point de vue ;
3. Une analyse de la façon dont l’enjeu affecte chaque région, y compris tout impact financier sur la région ;
4. Une analyse de la période de temps nécessaire estimée pour mettre en œuvre la politique ; et
5. Les avis des conseillers extérieurs nommés dans le groupe de travail par le Conseil, accompagnés par une déclaration détaillée des éléments suivants au sujet de conseillers : (1) qualifications et expérience dans le domaine ; et (2) conflits d’intérêt potentiels.
8. Procédure si aucun groupe d’études n’est formé
a. Si le Conseil décide de ne pas instaurer de groupe d’études, chaque organisation régionale doit, dans le délai indiqué par le planning du PDP, nommer un représentant pour solliciter les points de vue des régions sur l’enjeu abordé. Chaque représentant se voit demander de soumettre une déclaration régionale au responsable de la publication dans le délai indiqué par le planning du PDP.
b. Le Conseil peut, à sa discrétion, effectuer d’autres étapes qui lui semblent appropriées pour assister dans le PDP, notamment la nomination d’un individu particulier ou d’une organisation pour rassembler des informations sur l’enjeu ou planifier des réunions de délibération ou d'information. Toutes les informations de ce type doivent être soumises au responsable de la publication dans le délai indiqué par le planning du PDP.
c. Le Conseil doit demander officiellement au président du GAC de donner une opinion ou des conseils.
d. Le responsable de la publication récupère l’ensemble des Rapports régionaux, le Rapport des commentaires et autres informations et les compile en un Rapport initial (avant de le publier sur le site Web) dans le délai indiqué par le planning du PDP. Après cela, le responsable de la publication doit, conformément au point 9 ci-dessous, créer un Rapport final.
9. Commentaires au groupe d’études ou Rapport initial
a. Une période de recueil des commentaires (conformément au planning du PDP, et généralement long d’un minimum de 21 jours) doit être ouverte au sujet du Rapport du groupe d'études ou du Rapport initial. Les commentaires doivent être acceptés de la part des responsables ccTLD, des autres organisations de soutien, des comités consultatifs et du public. L’ensemble des commentaires doivent être accompagnés du nom de l’auteur du commentaire, de son expérience dans le domaine et de l’intérêt de l'auteur pour l’enjeu.
b. À la fin de la période de recueil des commentaires, le responsable de la publication est responsable de la révision des commentaires reçus et peut, à sa discrétion, inclure les commentaires adaptés dans le Rapport du groupe d’études ou dans le Rapport initial afin de préparer le « Rapport final ». Le responsable de la publication n’est pas contraint d’inclure tous les commentaires faits pendant la période, ni d’inclure l'ensemble des commentaires faits par un individu ou une organisation.
c. Le responsable de la publication doit préparer le Rapport final et le soumettre au président du Conseil dans le délai indiqué par le planning du PDP.
10. Délibération du Conseil
a. Lors de la réception du Rapport final, que ce soit le résultat d’un groupe d’études ou non, le président du Conseil doit (1) distribuer le Rapport final à l’ensemble des membres du Conseil ; (2) demander une réunion du Conseil dans le délai indiqué par le planning du PDP, au cours de laquelle le Conseil doit travailler pour parvenir à une recommandation à présenter au Conseil d'administration ; et (3) envoyer officiellement au président du GAC une invitation au GAC pour qu'il propose une opinion ou des conseils. Ce type de réunion peut être organisé de n’importe quelle façon jugée appropriée par le Conseil, notamment en personne ou par conférence téléphonique. Le responsable de la publication doit être présent à la réunion.
b. Le Conseil peut débuter ses délibérations sur l’enjeu avant la réunion officielle, notamment par le biais de réunions en face à face, de conférences téléphoniques, de discussions par courriers électroniques et de tout autre moyen que le Conseil souhaite choisir.
c. Le Conseil peut, s’il en décide ainsi, solliciter les opinions de conseillers extérieurs lors de la réunion finale. Les opinions de ces conseillers, si elles sont relayées par le Conseil, doivent être (1) décrites dans le rapport du Conseil au Conseil d’administration, (2) précisément identifiées comme venant d'un conseiller extérieur ; et (3) accompagnées d’une déclaration détaillée des éléments suivants au sujet du conseiller : (a) qualifications et expérience dans le domaine ; et (b) conflits d’intérêt potentiels.
11. Recommandation du Conseil
Lors de la concertation pour faire ou non une recommandation sur l’enjeu (une « Recommandation du Conseil »), le Conseil doit chercher à atteindre un consensus. Si une minorité s’oppose à un point de vue de consensus, cette minorité doit préparer et faire circuler auprès du Conseil une déclaration expliquant les raisons de cette opposition. Si la discussion du Conseil à propos de la déclaration n’atteint pas de consensus, une recommandation supportée par le vote de 14 membres ou plus du Conseil doit être estimée comme reflétant le point de vue du Conseil et doit être transmise aux membres en tant que recommandation du Conseil. Nonobstant les faits précédemment cités, comme exposé ci-dessous, l’ensemble des points de vue exprimés par les membres du Conseil au cours du PDP doivent être inclus dans le Rapport des membres.
12. Rapport du Conseil aux membres
Dans l’éventualité où une recommandation du Conseil est adoptée conformément au point 11, le responsable de la publication doit, dans les sept jours suivant la réunion du Conseil, intégrer la recommandation du Conseil avec tous les autres points de vue des membres du Conseil dans un Rapport des membres pour qu'elle soit approuvée par le Conseil puis soumise aux membres (le « Rapport des membres »). Le Rapport des membres doit contenir au minimum les éléments suivants :
a. Une déclaration claire de la recommandation du Conseil ;
b. Le Rapport final soumis au Conseil ; et
c. Une copie des minutes des délibérations du Conseil sur l’enjeu de la politique (voir point 10), incluant l’ensemble des opinions exprimées au cours de ces délibérations, accompagnées par une description des personnes ayant exprimé ces opinions.
13. Vote des membres
Après la soumission du Rapport des membres et dans le délai indiqué par le planning du PDP, les membres du ccNSO doivent se voir offrir une opportunité de voter sur la recommandation du Conseil. Le vote des membres doit être électronique et les votes des membres doivent être déposés sur une période de temps indiquée dans le planning du PDP (au moins 21 jours).
Dans l’éventualité où au moins 50 % des membres du ccNSO déposent des votes pendant la période de vote, le résultat du vote est employé sans autre traitement. Dans l’éventualité où moins de 50 % des membres du ccNSO déposent des votes au cours de la première session de vote, cette première session n’est pas employée et les résultats d’une deuxième session de vote finale, organisée après un préavis d’au moins trente jours aux membres du ccNSO, seront employés si au moins 50 % des membres du ccNSO votent. Dans l’éventualité où plus de 66 % des votes reçus à la fin de la période de vote sont en faveur de la recommandation du Conseil, la recommandation est envoyée au Conseil d’administration avec le point 14 ci-dessous comme recommandation du ccNSO.
14. Rapport du Conseil d’administration
Le responsable de la publication doit, dans les sept jours suivant la recommandation du ccNSO faite conformément au point 13, incorporer la recommandation du ccNSO dans un rapport devant être approuvé par le Conseil puis être soumis au Conseil d’administration (le « Rapport du Conseil d’administration »). Le Rapport du Conseil d’administration doit contenir au minimum les éléments suivants :
a. Une déclaration claire de la recommandation du ccNSO ;
b. Le Rapport final soumis au Conseil ; et
c. Le Rapport des membres
15. Vote du Conseil d'administration
a. Le Conseil d’administration se réunit pour discuter de la recommandation du ccNSO le plus rapidement possible après la réception du Rapport du responsable de la publication, conformément aux procédures pour l’examen du Conseil d’administration.
b. Le Conseil d’administration adopte la recommandation, à moins qu’un vote de plus de 66 % du Conseil d'administration ne détermine qu’une politique de ce type ne correspond pas au meilleur intérêt de la communauté ICANN ou de l'ICANN.
1. Dans l’éventualité où le Conseil d’administration déterminerait de ne pas suivre la recommandation du ccNSO, le Conseil d’administration doit (1) exposer les raisons de cette décision de ne pas agir en fonction de la recommandation du ccNSO dans un rapport destiné au Conseil (la « Déclaration du Conseil d’administration ») ; et (2) soumettre la Déclaration du Conseil d’administration au Conseil.
2. Le Conseil doit discuter de la Déclaration du Conseil d'administration pour une discussion avec le Conseil d'administration dans les trente jours suivant la soumission de la Déclaration du Conseil d'administration au Conseil. Le Conseil d’administration doit déterminer la méthode (par ex. par téléconférence, courrier électronique ou autre) que le Conseil et le Conseil d’administration utiliseront pour la discussion. Les discussions doivent être tenues en bonne foi, dans les plus brefs délais et de manière efficace afin de trouver un compromis acceptable.
3. À la fin des discussions du Conseil et du Conseil d’administration, le Conseil se réunit pour confirmer ou pour modifier la recommandation du Conseil. Une recommandation supportée par le vote de 14 membres ou plus du Conseil sera préférée pour refléter le point de vue du Conseil (la « Recommandation complémentaire » du Conseil. Cette Recommandation complémentaire doit être transmise aux membres dans un Rapport complémentaire des membres, en incluant une explication de la Recommandation complémentaire. Les membres doivent avoir l’opportunité de voter au sujet de la Recommandation complémentaire conformément aux conditions exposées au point 13. Dans l’éventualité ou plus de 66 % des votes des membres du ccNSO reçus pendant la période de vote sont en faveur de la Recommandation complémentaire, cette recommandation doit être transmise au Conseil d’administration, car la Recommandation complémentaire du ccNSO et le Conseil d'administration adoptent la recommandation, à moins qu'un vote de plus de 66 % du Conseil d’administration ne détermine que l’acceptation de cette politique constituerait une faute fiduciaire du Conseil d’administration envers l’entreprise.
4. Dans l’éventualité où le Conseil d'administration n'accepte pas la Recommandation complémentaire, il doit exposer ses raisons dans sa décision finale (« Déclaration complémentaire du Conseil d’administration »).
5. Dans l’éventualité où le Conseil d’administration décide de ne pas adopter la Recommandation complémentaire, le Conseil d’administration n’est pas autorisé à définir une politique sur l’enjeu concerné par la recommandation et le statu quo doit être préservé jusqu’au moment où le ccNSO, dans le cadre du ccPDP, fait une nouvelle recommandation sur l’enjeu estimée acceptable par le Conseil d’administration.
16. Mise en œuvre de la politique
Lors de l’adoption par le Conseil d’administration d’une Recommandation du ccNSO ou de la Recommandation complémentaire, le Conseil d’administration doit, selon les besoins, diriger ou autoriser l’équipe de l'ICANN pour la mise en œuvre de la politique.
17. Maintenance des enregistrements
Dans le cadre de chaque ccPDP pour lequel un rapport est demandé (voir point 1), l’ICANN doit maintenir sur le site Web une page de Statut détaillant l'avancement de chaque ccPDP, qui doit fournir une liste des dates concernant le ccPDP et également proposer des liens vers les documents suivants, dans la mesure où ils ont été préparés conformément au ccPDP :
a. Rapport ;
b. Planning du PDP ;
c. Rapport de commentaires ;
d. Déclaration(s) régionale(s) ;
e. Rapport préliminaire de groupe d'études ;
f. Rapport de groupe d'études ;
g. Rapport initial ;
h. Rapport final ;
i. Rapport des membres ;
j. Rapport du Conseil d’administration ;
k. Déclaration du Conseil d’administration
l. Rapport complémentaire des membres ; et
m. Déclaration complémentaire du Conseil d’administration.
En outre, l’ICANN doit publier sur le site Web des commentaires reçus par écrit sous forme électronique suggérant spécifiquement le lancement d'un ccPDP.
Annexe C : Domaine de compétence du ccNSO
Cette annexe décrit le domaine de compétence et les principes et méthodes d'analyse à utiliser pour tout développement ultérieur du domaine de compétence du rôle d'élaboration des politiques du ccNSO. Conformément à l’Article IX, section 6(2) ces Statuts, ce domaine de compétence est à définir selon les procédures du ccPDP.
Le domaine de compétence et les responsabilités de l’administration du ccNSO doivent reconnaître la relation complexe entre l’ICANN et les responsables/registres du ccTLD concernant les enjeux de la politique. Cette annexe assiste le ccNSO, le Conseil du ccNSO, le Conseil d’administration et l’équipe de l’ICANN pour faire ressortir les enjeux globaux de la politique.
Domaines de la politique
Le rôle politique du ccNSO doit se baser sur une analyse du modèle fonctionnel suivant du DNS :
1. Les données sont enregistrées/maintenues pour créer un fichier de zone,
2. Le fichier de zone est à son tour utilisé sur les serveurs de noms TLD.
Dans un TLD, deux fonctions doivent être exécutées (elles sont présentées plus en détail ci-dessous) :
1. Saisie des données dans une base de données (fonction de saisie des données) et
2. Maintenance et entretien des serveurs de noms pour le TLD (fonction serveur de noms).
Ces deux fonctions principales doivent être effectuées au niveau de l'enregistrement du registre ccTLD, ainsi qu’à un niveau supérieur (fonction IANA et serveurs racines) et à des niveaux inférieurs de la hiérarchie . Ce mécanisme, comme le montre la norme RFC 1591, est récursif :
Il n’existe aucune exigence pour les sous-domaines des domaines de premier niveau au-delà des domaines eux-mêmes. Cela signifie que les exigences de ce mémo sont appliquées de façon récursive. Plus particulièrement, tous les sous-domaines doivent être autorisés à piloter leurs propres serveurs de noms de domaine, à condition qu’ils y fournissent toute information que le responsable du sous-domaine juge adaptée (tant qu’elle est véridique et correcte).
Les fonctions principales
1. Fonction de saisie des données :
À un niveau plus détaillé, la première fonction (saisie et maintenance des données dans une base de données) doit être entièrement définie par une politique d’affectation de noms. Cette politique d'affectation des noms doit spécifier les règles et les conditions :
(a) sous lesquelles les données seront collectées et saisies dans une base de données, ou les données modifiées (au niveau du TLD entre autres, les données reflétant un transfert de registrant à registrant ou une modification de bureau d’enregistrement) dans la base de données.
(b) pour rendre certaines données disponibles au public et en général (par exemple par le biais de Whois ou de serveurs de noms).
2. La fonction de serveur de noms
La fonction de serveur de noms implique des enjeux d’interopérabilité et de stabilité essentiels au cœur du système de noms de domaines (DNS). L’importance de cette fonction s’étend aux serveurs de noms au niveau du ccTLD, mais également aux serveurs racines (et au système de serveurs racines) et aux serveurs de noms à des niveaux inférieurs.
De par eux-mêmes et du fait de considérations d’interopérabilité et de stabilité, les serveurs de noms fonctionnant correctement sont d’une importance cruciale pour l’individu, ainsi que pour les communautés Internet locales et globales.
Concernant la fonction du serveur de noms, de ce fait, les politiques doivent être définies et établies. La plupart des parties impliquées, notamment la majorité des registres ccTLD, ont accepté le besoin de politiques communes dans ce domaine en adhérant aux normes RFC adaptées, parmi lesquelles on trouve la norme RFC 1591.
Rôles respectifs concernant la politique, responsabilités et obligations
Il est dans l’intérêt de l’ICANN et des responsables du ccTLD d’assurer le fonctionnement stable et cohérent du système de noms de domaine (DNS). L’ICANN et les registres ccTLD ont chacun un rôle distinct à jouer dans ce domaine, qui peut être défini par les politiques adaptées. Le domaine de compétence du ccNSO ne peut être établi sans atteindre une compréhension commune de la répartition de l’autorité entre l’ICANN et les registres du ccTLD.
Trois rôles se distinguent, auxquels une certaine responsabilité doit être affectée sur tout enjeu donné :
- Rôle politique : la capacité et le pouvoir de définir une politique ;
- Rôle exécutif : la capacité et le pouvoir d’agir pour la mise en œuvre de la politique ;
- Rôle de responsabilité : la capacité et le pouvoir de rappeler à l’entité responsable ses obligations d’exercice du pouvoir.
Premièrement, la responsabilité suppose une politique et cela met en évidence le rôle de la politique. Selon l’enjeu à traiter, ceux qui sont impliqués dans la définition de cette politique doivent être déterminés et définis. Ensuite, cela suppose un rôle exécutif définissant le pouvoir à mettre en œuvre et imposer d'agir dans les limites d'une politique. Enfin, pour contrebalancer le rôle exécutif, le rôle de responsabilité doit être défini et déterminé.
Les informations ci-dessous fournissent de l’aide pour :
1. mettre en évidence et identifier les domaines de la politique ;
2. définir et déterminer les rôles concernant ces domaines spécifiques de la politique.
Cette annexe définit le domaine de compétence du ccNSO au sujet du développement des politiques. Le domaine de compétence est limité au rôle politique du processus d’élaboration des politiques (PDP) du ccNSO pour les fonctions et les niveaux clairement indiqués ci-dessous. On estime que la précision des affectations des rôles politiques, exécutifs et de responsabilité exposées ci-dessous sera étudiée pendant le processus ccPDP de définition du domaine de compétence.
Fonction de serveur de noms (ccTLD)
Niveau 1 : Serveurs de noms racines
Rôle politique : IETF, RSSAC (ICANN)
Rôle exécutif : Opérateurs du serveur racine
Rôle de responsabilité : RSSAC (ICANN), (Protocole d’accord entre le Département du Commerce des États-Unis et l’ICANN)Niveau 2 : Serveurs de noms de registres ccTLD concernant l’interopérabilité
Rôle politique : Processus d’élaboration des politiques du ccNSO (ICANN), pour les meilleures pratiques un processus ccNSO peut être organisé
Rôle exécutif : Responsable ccTLD
Rôle de responsabilité : partiellement l’ICANN (IANA), partiellement la Communauté Internet locale, incluant le gouvernement localNiveau 3 : Serveurs de noms d’utilisateurs
Rôle politique : Responsable ccTLD, IETF (RFC)
Rôle exécutif : Registrant
Rôle de responsabilité : Responsable ccTLD
Fonction de saisie des données (ccTLD)
Niveau 1 : Registre au niveau de la racine
Rôle politique : Processus d’élaboration des politiques de la ccNSO (ICANN)
Rôle exécutif : ICANN (IANA)
Rôle de responsabilité : Communauté ICANN, responsables ccTLD, Département du Commerce américain, (les gouvernements nationaux dans certains cas)Niveau 2 : Registre ccTLD
Rôle politique : Communauté Internet locale, incluant le gouvernement local et/ou le responsable ccTLD en fonction de la structure locale
Rôle exécutif : Responsable ccTLD
Rôle de responsabilité : Communauté Internet locale, incluant les gouvernements nationaux dans certains casNiveau 3 : Niveaux secondaires et inférieures
Rôle politique : Registrant
Rôle exécutif : Registrant
Rôle de responsabilité : Registrant, utilisateurs de noms de domaine de niveau inférieur