RÈGLEMENTS DE L'ICANN | Société de droit californien à but non lucratif
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
Suivant les modifications du 24 juin 2011
Ce document a été traduit dans plusieurs langues dans un but purement informatif. Le texte original faisant foi (en anglais) peut être consulté sur: http://www.icann.org/en/general/bylaws.htm
TABLE DES MATIÈRES
ARTICLE I: MISSION ET PRINCIPALES VALEURS
ARTICLE II : POUVOIRS
ARTICLE III : TRANSPARENCE
ARTICLE IV : RESPONSABILITÉ ET RÉVISION
ARTICLE V : MÉDIATEUR
ARTICLE VI : CONSEIL D'ADMINISTRATION
ARTICLE VII : COMITÉ DE NOMINATION
ARTICLE VIII : ORGANISATION DE SOUTIEN AUX POLITIQUES D'ADRESSAGE
ARTICLE IX : ORGANISATION DE SOUTIEN AUX NOMS DE CODES DE PAYS
ARTICLE X : ORGANISATION DE SOUTIEN DES NOMS GÉNÉRIQUES
ARTICLE XI : COMITÉS CONSULTATIFS
ARTICLE XI-A : AUTRES MÉCANISMES CONSULTATIFS
ARTICLE XII : CONSEIL D'ADMINISTRATION ET COMITÉS PROVISOIRES
ARTICLE XIII : MEMBRES DE LA DIRECTION
ARTICLE XIV : INDEMNISATION DES ADMINISTRATEURS, CADRES DE DIRECTION, EMPLOYÉS ET AUTRES AGENTS
ARTICLE XV : DISPOSITIONS GÉNÉRALES
ARTICLE XVI : FISCALITÉ
ARTICLE XVII : MEMBRES
ARTICLE XVIII : BUREAUX ET CACHET
ARTICLE XIX : AMENDEMENTS
ARTICLE XX : ARTICLE DE TRANSITION
ANNEXE A : PROCESSUS D'ÉLABORATION DES POLITIQUES DE LA 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 la Société pour l'attribution des noms de domaine et des numéros sur Internet (Internet Corporation for Assigned Names and Numbers – ICANN) est de coordonner, à un niveau général, les systèmes mondiaux d'identificateurs uniques d'Internet et notamment d'en assurer 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 l'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 racine des noms du DNS.
3. Coordonne le développement des politiques associées de façon raisonnable et pertinente à ces fonctions techniques.
Section 2. VALEURS PRINCIPALES
Pour mener à bien sa 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 d'Internet.
2. Respect de la créativité, de l'innovation et de la diffusion des informations rendues possibles par Internet en limitant les activités de l'ICANN aux questions relevant de sa mission, exigeant ou bénéficiant substantiellement 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 de politiques d'autres entités responsables reflétant les intérêts des parties concernées.
4. Recherche et soutien d'une participation étendue et éclairée reflétant la diversité fonctionnelle, géographique et culturelle d'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 les décisions bien informées fondées sur des conseils experts et (ii) garantissent 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 documents, en toute intégrité et équité.
9. Rapidité d'action permettant de répondre aux besoins d'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 de la responsabilité des gouvernements et autorités publiques en matière de politique publique et prise en compte légitime des recommandations émanant des gouvernements ou des autorités publiques.
Ces valeurs clés sont volontairement exprimées dans des termes très généraux, afin d'offrir des repères utiles et pertinents dans les circonstances les plus diverses possibles. En raison de leur caractère non restrictif, la façon précise dont elles s'appliqueront, séparément ou collectivement, à chaque nouvelle situation dépendra nécessairement de nombreux facteurs ne pouvant pas être totalement anticipés ou répertoriés. En outre, dans la mesure où il s'agit de déclarations de principe plutôt que de situations concrètes, il y aura inévitablement des cas où il sera impossible de respecter parfaitement la totalité de ces onze valeurs clés. Lorsqu'un organe de l'ICANN effectue une recommandation ou prend une décision, il lui appartient de juger quelles sont les valeurs clés les plus importantes et comment elles doivent s'appliquer aux circonstances précises du cas concerné, ainsi que de déterminer, si nécessaire, un équilibre approprié et justifiable entre les valeurs en concurrence.
ARTICLE II : POUVOIRS
Sauf disposition contraire dans les statuts ou dans ces règlements, les pouvoirs de l'ICANN sont 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. Concernant toute question relative qui serait régie par les dispositions 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 toutes les autres questions, sauf stipulation contraire de ces règlements 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 règlements à un vote du Conseil d'administration renvoie uniquement au vote des membres présents à la réunion au cours de laquelle il existe un quorum, sauf stipulation contraire incluse dans ces règlements, l'élargissant à « tous les membres du Conseil d'administration ».
L'ICANN n'agit pas en tant que registre de système de noms de domaine, de bureau d'enregistrement ou encore de registre d'adresses IP en concurrence avec des entités touchées par les politiques de l'ICANN. Rien dans cette section n'est voulu 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 n'applique pas ses normes, politiques, procédures ou pratiques de façon inéquitable et ne traite pas une partie particulière de façon différente à moins que cela ne soit justifié par un motif sérieux et valable, telle que la promotion d'une concurrence efficace.
ARTICLE III : TRANSPARENCE
L'ICANN et ses collègues constituants doivent fonctionner le plus possible de manière ouverte et transparente en se dotant de procédures conçues pour assurer l'équité.
L'ICANN maintient un site Web accessible au public (désigné ci-après par « site Web »), qui peut comprendre, entre autres, (i) un calendrier des différentes réunions au programme du Conseil d'administration, des organisations de soutien, et des comités consultatifs ; (ii) un registre de toutes les questions en suspens relatives à l'élaboration des politiques, 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, à l'audit annuel, aux intervenants financiers ainsi qu'au montant de leurs contributions, et à d'autres questions pertinentes, (v), les informations concernant la disponibilité des mécanismes de responsabilité, y compris le réexamen, la révision indépendante et les activités du médiateur, ainsi que les informations relatives au résultat de demandes spécifiques et de plaintes invoquant ces 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 d'élaboration 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. GESTIONNAIRE DE LA PARTICIPATION DU PUBLIC
Un poste intitulé gestionnaire de la participation du public, ou un autre titre déterminé par le président, doit être établi. Sous la direction du président, ce gestionnaire est en charge de la coordination des différents aspects de la participation du public au sein de l' ICANN, y compris le site web et les autres moyens variés de communication et de réception des contributions provenant de la communauté élargie des utilisateurs de l'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 sont publiés en ligne au minimum sept jours avant chaque réunion du conseil d'administration (ou si ceci n'est pas réalisable, le plus tôt possible).
Section 5. COMPTES-RENDUS ET RAPPORTS PRÉLIMINAIRES
1. Tous les comptes-rendus des réunions du Conseil d'administration et des organisations de soutien (et de tout autre conseil) sont approuvés dans les plus brefs délais par les organes à l'origine de ces réunions et remis au Secrétaire de l'ICANN qui se chargera de les publier sur le site Web.
2. Au plus tard à 11h59 du soir, le deuxième jour ouvrable après la clôture de chaque réunion (heure locale du bureau principal de l'ICANN), toutes les résolutions prises par le Conseil d'administration lors de cette réunion seront rendues publiques sur le site Web ; cependant, ne devront pas être incluses dans le rapport préliminaire rendu public toutes les actions ayant trait à des questions de personnel ou d'emploi, ou encore à des 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), à des points qu'il est légalement ou contractuellement interdit à l'ICANN de divulguer, et à d'autres points qui, selon un vote à la majorité des trois-quarts(3/4) des Administrateurs présents lors de la réunion et ayant droit de vote, sont jugés inappropriés à une diffusion publique. Le Secrétaire préviendra le Conseil d'administration et les présidences des organisations de soutien (comme prévu aux Articles VIII et X de ces Règlements) ainsi que les Comités consultatifs (comme prévu à l'Article XI de ces Règlements) pour les informer que les résolutions ont été publiées.
3. Au plus tard à 11h59 du soir du septième jour ouvrable après la clôture de chaque réunion (heure locale du bureau principal de l'ICANN), toutes les mesures prises par le Conseil d'administration devront être publiées dans un rapport préliminaire sur le site Web, sous réserve des limitations concernant leur diffusion prévues dans la Section 5.2. ci-dessus. Pour toutes les questions qu'il choisit de ne pas divulguer, le Conseil d'administration décrit dans le rapport préliminaire et ce en des termes généraux, les raisons de cette non-divulgation.
4. 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 jour ouvrable suivant), les comptes rendus devront être rendus publics sur le site Web. Cependant, tous comptes rendus ayant trait à des questions de personnel ou d'emploi, ou encore à des 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), à des points qu'il est légalement ou contractuellement interdit à l'ICANN de divulguer, et à d'autres points qui, selon un vote à la majorité des trois-quarts (3/4) des administrateurs du Conseil d'administration présents lors de la réunion et ayant droit de vote, sont jugés inappropriés à une diffusion publique, ne seront pas inclus dans le compte rendu diffusé à l'intention du public. Pour toutes les questions qu'il choisit de ne pas divulguer, le Conseil d'administration décrit dans le compte rendu pertinent et ce en des termes généraux, les raisons de cette non-divulgation.
Section 6. AVIS ET COMMENTAIRES SUR LES ACTIONS DE POLITIQUES
1. Concernant toute politique que le Conseil d'administration envisage d'adopter et qui aurait une nette incidence sur le fonctionnement de l'Internet ou de tiers, y compris l'imposition de frais quelconques, l'ICANN devra :
a. annoncer et expliquer publiquement sur son site Web quelles sont les politiques dont l'adoption est envisagée et pourquoi, et ce, vingt et un jours au plus tard (et si possible, plus tôt) précédant toute action du Conseil d'administration ;
b. donner aux parties la possibilité légitime 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. dans les cas où la politique aurait une incidence sur des intérêts de politique publique, demander l'avis du comité consultatif gouvernemental (GAC) et prendre en compte tout conseil fourni par le GAC de sa propre initiative ou à la demande du Conseil d'administration.
2. Dans la mesure du possible et en accord avec le processus d'élaboration de politique pertinent, un forum public avec participation en personne est également tenu afin de discuter des politiques proposées, tel que décrit à la Section 6(1)(b) de cet Article, avant toute action définitive du Conseil d'administration.
3. Après avoir pris des mesures concernant tout sujet ayant trait à une politique entreprise par le biais de ce processus, le Conseil d'administration publie dans le compte-rendu de sa réunion, les raisons justifiant la mesure prise, le vote de chaque administrateur ayant voté sur cette mesure, ainsi que la déclaration séparée de tout administrateur 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 facilite la traduction des documents définitifs publiés dans 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 règlements, l'ICANN est responsable vis-à-vis de la communauté d'un fonctionnement en accord avec ces règlements, et en tenant parfaitement compte des principales valeurs définies Article I de ces Règlements. Les dispositions de cet article, engendrant un processus de réexamen 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é présentés dans ces règlements, y compris les dispositions de transparence de l'Article III et du Conseil d'administration, ainsi que d'autres mécanismes de sélection mentionnés dans ces règlements.
1. L'ICANN met en place un processus par lequel toute personne ou entité substantiellement touchée par une quelconque action de l'ICANN peut demander une révision ou un réexamen de cette action par le Conseil d'administration.
2. Toute personne ou entité peut soumettre une demande de réexamen ou de révision d'une action ou inaction de l'ICANN (« demande de réexamen ») dans la mesure où elle a été négativement affectée par :
a. une ou plusieurs actions ou inactions du personnel en contradiction avec la ou les politiques établies par l'ICANN ; ou
b. une ou plusieurs actions ou inactions du Conseil d'administration de l'ICANN entreprises ou refusées sans prendre en compte des informations importantes, sauf si la partie soumettant la demande aurait pu remettre, mais n'a pas remis ces informations au Conseil d'administration au moment de l'action ou du refus d'agir.
3. Un comité du Conseil d'administration composé de trois administrateurs au minimum est mis en place, afin de réviser et examiner de telles demandes (« comité de réexamen »). Le comité de réexamen a toute autorité pour :
a. évaluer les demandes de révision ou de remise en cause ;
b. déterminer si un sursis de l'action contestée est approprié en attendant la résolution de la demande ;
c. mener toute enquête factuelle qu'il considère appropriée ;
d. demander des propositions écrites supplémentaires à la partie concernée ou à d'autres parties ; et
e. faire une recommandation au Conseil d'administration concernant la valeur et les arguments de la demande.
4. L'ICANN prend en charge les coûts administratifs normaux du processus de réexamen. L'ICANN se réserve le droit d'exiger de la partie faisant une demande de révision ou de réexamen de prendre en charge tout coût jugé extraordinaire par nature. Lorsque de telles dépenses extraordinaires peuvent être prévues, ce fait et les raisons pour lesquelles de telles dépenses sont nécessaires et indispensables à l'évaluation de la demande de réexamen sont communiqués à la partie demandant le réexamen, cette dernière ayant ensuite le choix de retirer la demande ou d'accepter la prise en charge desdites dépenses.
5. Toutes les demandes de réexamen doivent être soumises par courrier électronique à une adresse désignée par le comité de réexamen du Conseil d'administration dans les trente jours suivant :
a. pour les demandes contestant des 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 comptes-rendus des réunions du Conseil d'Administration ; ou
b. pour les demandes concernant des actions du personnel, la date à laquelle la partie soumettant la demande a pris connaissance de, ou aurait dû raisonnablement prendre connaissance de l'action contestée du personnel ; ou
c. pour les demandes contestant une inaction du Conseil d'Administration ou du personnel, la date à laquelle la personne affectée a conclu, ou aurait dû raisonnablement conclure qu'une action ne serait pas entreprise de manière opportune.
6. Toutes les demandes de réexamen doivent comprendre les informations requises par le comité de réexamen. Celles-ci comprennent au moins :
a. le nom, l'adresse, et les coordonnées de contact de la partie demanderesse, y comprises les adresses postale et de courrier électronique ;
b. l'action ou l'inaction spécifique de l'ICANN pour laquelle une révision ou un réexamen est demandé ;
c. la date de l'action ou inaction ;
d. la manière de laquelle la partie demanderesse sera affectée par l'action ou l'inaction ;
e. la mesure dans laquelle, à l'avis de la partie soumettant la demande de réexamen, l'action ou l'inaction faisant l'objet de la plainte, affecte-t-elle négativement d'autres parties ;
f. si un sursis provisoire de toute action contestée est nécessaire, et dans l'affirmative, les torts qui résulteront en cas de non sursis de l'action ;
g. dans le cas d'une action ou d'une inaction du personnel, une explication détaillée des faits tels que présentés au personnel, et des raisons qui ont rendu l'action ou l'inaction du personnel incompatible avec la ou les politiques établie(s) par l'ICANN ;
h. dans le cas d'une action ou d'une inaction du Conseil d' Administration, une explication détaillée de l'information importante qui n'a pas été prise en considération par le Conseil d'Administration, et, si l'information n'avait pas été présentée au Conseil d'Administration, les raisons pour lesquelles la partie soumettant la demande ne les avait pas soumises au Conseil d'administration avant que celui-ci n'agisse ou n'omette d'agir ;
i. les démarches spécifiques que la partie demanderesse demande à l'ICANN d'entreprendre, à savoir si et comment l'action devrait être inversée, annulée ou modifiée ou encore quelle action spécifique doit-elle être entreprise ;
j. les motifs pour lesquels l'action demandée devrait être entreprise ; et
k. tous documents que la partie demanderesse souhaite soumettre pour soutenir sa demande.
7. Toutes les demandes de réexamen sont publiées sur le site Web.
8. Le comité de réexamen a toute autorité pour examiner les demandes de réexamen émanant de différentes parties dans le cadre d'une même procédure pour autant que (i) les demandes concernent la même action ou inaction générale et (ii) les parties soumettant les demandes de réexamen soient affectées de manière similaire par une telle action ou inaction.
9. Le comité de réexamen examine les demandes de réexamen rapidement dès leur réception et annonce, dans un délai de trente jours, son intention de décliner ou de procéder à l'examen d'une demande de réexamen après la réception de cette demande. L'annonce doit être publiée sur le site Web.
10. L'annonce d'une décision du comité de réexamen de ne pas donner suite à une demande de réexamen doit comprendre une explication des motifs de cette décision.
11. Le comité de réexamen peut demander des informations supplémentaires ou éclaircissements de la part de la partie ayant soumis la demande de réexamen.
12. Le comité de réexamen peut demander au personnel de l'ICANN son avis sur la question, et les commentaires du personnel sont rendus publics sur le site Web.
13. Si le comité de réexamen a besoin d'informations supplémentaires, il peut choisir de s'entretenir avec la partie demandant le réexamen soit par téléphone ou par courrier électronique, soit en personne si ceci est acceptable par la partie demandant le réexamen. Dans la mesure où toute information recueillie au cours d'un tel entretien s'avère utile à toute recommandation du comité de réexamen, ce dernier le mentionne dans sa recommandation.
14. Le comité de réexamen peut également demander à des tiers des informations ayant rapport avec la demande. Dans la mesure où toute information recueillie s'avère utile à toute recommandation du comité de réexamen, ce dernier le mentionne dans sa recommandation.
15. Le comité de réexamen tient compte d'une demande de réexamen en l'enregistrant par écrit, le procès-verbal devant comprendre les informations soumises par la partie demandant le réexamen ou la révision, par le personnel de l'ICANN, et par tous tiers.
16. Pour la protection contre un abus de la procédure de réexamen, une demande de réexamen peut être rejetée par le comité de réexamen lorsqu'elle est répétitive, qu'elle manque de sérieux, qu'elle est sans substance ou d'une manière ou d'une autre abusive, ou lorsque la partie concernée avait été avertie de et avait l'occasion de participer mais n'avait pas participé à la période de consultation publique relative à l'action contestée, le cas échéant. De même, le comité de réexamen peut rejeter une demande lorsque la partie demanderesse ne démontre pas qu'elle sera affectée par l'action de l'ICANN.
17. Le comité de réexamen formule sa recommandation définitive au Conseil d'administration au sujet d'une demande de réexamen, dans les quatre-vingt-dix jours suivant la réception de la demande, sauf si ceci est impossible. Dans ce cas, le comité de réexamen rend compte au Conseil d'administration des circonstances qui l'ont empêché de faire sa recommandation définitive, ainsi que du temps estimé nécessaire pour formuler une telle recommandation définitive. La recommandation définitive est publiée sur le site Web.
18. Le conseil d'administration n'est pas tenu de suivre les recommandations du comité de réexamen. La décision finale du Conseil d'administration est rendue publique dans le cadre du rapport préliminaire et du compte-rendu de la réunion du Conseil d'administration au cours de laquelle la mesure est prise.
19. Le comité de réexamen soumet chaque année au Conseil d'administration un rapport comprenant au moins les informations suivantes pour l'année civile précédente :
a. le nombre et la nature générale des demandes de réexamen reçues ;
b. le nombre de demandes de réexamen pour lesquelles le comité a pris des mesures ;
c. le nombre de demandes de réexamen restées en suspens à la fin de l'année civile et la durée moyenne depuis laquelle de telles demandes de réexamen sont en suspens ;
d. une description de toutes demandes de réexamen en suspens à la fin de l'année civile depuis plus de quatre-vingt-dix (90) jours, et les raisons pour lesquelles le comité n'a pas pris de mesure les concernant ;
e. le nombre et la nature des demandes de réexamen que le comité a refusé de prendre en compte dans la mesure où elles ne satisfaisaient pas les critères établis dans cette politique ;
f. pour les demandes de réexamen rejetées, une explication de tout autre mécanisme disponible pour garantir que l'ICANN soit responsable vis-à-vis des personnes substantiellement affectées par ses décisions ; et
g. si oui ou non, à l'avis du comité, les critères selon lesquels un réexamen peut être demandé devraient être révisés, ou si un autre processus devrait être adopté ou modifié, pour s'assurer que toutes personnes substantiellement affectées par les décisions de l'ICANN aient bien accès à un processus de révision qui garantisse l'équité, tout en limitant les plaintes manquant de sérieux.
20. Chaque rapport annuel regroupe également les informations relatives aux sujets répertoriés au paragraphe 19(a)-(e) de cette Section pour la période commençant le 1er janvier 2003.
Section 3. RÉVISION INDÉPENDANTE DES ACTIONS DU CONSEIL D'ADMINISTRATION
1. Outre le processus de réexamen décrit dans la Section 2 de cet Article l'ICANN met en place un processus distinct pour un examen indépendant, effectué par un tiers, des actions du conseil d'administration jugées incompatibles, selon une partie concernée, avec les statuts ou les règlements.
2. Toute personne matériellement affectée par une décision ou action du conseil d'administration qu'elle juge incompatible avec les statuts ou les règlements peut soumettre une demande pour obtenir la révision indépendante de cette décision ou action.
3. Les demandes d'une telle révision indépendante doivent renvoyer à un panel de révision indépendant (« IRP »), en charge de comparer les actions du conseil d'administration contestées aux statuts et aux règlements et de déclarer si le conseil d'administration a agi en accord avec les dispositions de ces statuts et règlements.
4. L'IRP est géré par un fournisseur d'arbitrage international nommé de temps à autre par l'ICANN (« le fournisseur de l'IRP »)
5. Sous réserve de l'approbation du conseil d'administration, le fournisseur de l'IRP établit des règles et des procédures de fonctionnement qui mettent en application cette Section 3.
6. Chacune des parties peut choisir que la demande de révision indépendante soit considérée par une commission composée de trois membres ; en l'absence d'un tel choix, la question est examinée par un panel composé d'un seul membre.
7. Le fournisseur de l'IRP détermine une procédure pour nommer les membres des commissions individuelles, à condition que, si l'ICANN l'ordonne ainsi, le fournisseur de l'IRP établisse un panel permanent pour recevoir de telles plaintes.
8. L'IRP a toute autorité pour :
a. exiger des propositions supplémentaires écrites de la partie demanderesse, du conseil d'administration, des organisations de soutien ou d'autres parties ;
b. déclarer si oui ou non une action ou inaction du Conseil d'administration a été incompatible avec les statuts ou les règlements ; 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 de l'IRP.
9. Toute personne occupant une fonction ou un poste officiels au sein des structures de l'ICANN n'est pas éligible à l'IRP.
10. Dans le but de maintenir les coûts et charges de la révision indépendante aussi réduits que possible, l'IRP mène ses procédures, autant que possible, par e-mail ou par Internet. Si nécessaire, l'IRP peut tenir des réunions par téléphone.
11. L'IRP respecte la politique des conflits d'intérêt indiquée dans les règles et procédures de fonctionnement du fournisseur de l'IRP, telles qu'approuvées par le conseil d'administration.
12. Les déclarations de l'IRP sont faites par écrit. L'IRP fonde sa déclaration uniquement sur la documentation, les pièces justificatives, ainsi que les différents arguments soumis par les parties, et désigne spécifiquement dans sa déclaration la partie dominante. La partie dominée prend d'ordinaire en charge tous les frais encourus par le fournisseur de l'IRP, mais, dans un cas extraordinaire, ce dernier peut attribuer dans sa déclaration jusqu'à la moitié des frais du fournisseur de l'IRP à la partie dominante en se fondant sur les circonstances, et en prenant en considération le bien-fondé des positions des parties ainsi que leur contribution à l'intérêt public. Chaque partie impliquée dans les procédures de l'IRP prend ses propres frais à sa charge.
13. Les procédures de fonctionnement de l'IRP, ainsi que toutes les pétitions, revendications et déclarations sont publiées sur le site Web, dès qu'elles sont disponibles.
14. L'IRP peut, à sa discrétion, accéder à la demande d'une partie de garder certaines informations confidentielles, comme par exemple des secrets industriels.
15. Le cas échéant, le Conseil d'administration examine la déclaration de l'IRP 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 met en place une révision périodique de la performance et du fonctionnement de chaque organisation de soutien, chaque conseil d'organisation de soutien, chaque comité consultatif (à part le comité consultatif gouvernemental), ainsi que du comité de nomination, réalisée par une ou plusieurs entités indépendantes de l'organisation en cours d'examen. Le but de l'audit, entrepris à 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 le fonctionnement serait souhaitable pour améliorer son efficacité.
Ces audits périodiques seront effectués tous les cinq ans au moins, tenant compte de leur faisabilité, déterminée par le Conseil d'administration. Chaque cycle de cinq ans sera compté à partir du moment où le Conseil d'administration aura reçu le rapport final de l'audit du Groupe de travail pertinent.
Les résultats de ces audits seront publiés sur le site Web pour révision et commentaires du public et ils seront pris en considération par le Conseil au plus tard lors de la deuxième réunion du Conseil prévue après la publication de ces résultats 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. Le comité consultatif gouvernemental pourvoit à ses propres mécanismes de révision.
ARTICLE V : MÉDIATEUR
Section 1. BUREAU DU MÉDIATEUR
1. Un bureau de médiateur est mis en place, dirigé par un médiateur et bénéficiant du soutien en personnel que le Conseil d'administration juge approprié et réalisable. Le poste de médiateur est une fonction à plein-temps, rémunérée par un salaire et par les avantages appropriés à la fonction, tel qu'établi par le Conseil d'administration.
2. Le médiateur est 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 est passible de licenciement par le Conseil d'administration uniquement sur vote des 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 la substance, 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 sert à agir de manière neutre lors de la résolution de litiges concernant les questions pour lesquelles les dispositions de la politique de réexamen stipulées dans la Section 2 de l'Article IV ou de la politique de révision indépendante stipulées dans la Section 3 de l'Article IV n'ont pas été invoquées. La fonction principale du médiateur consiste à 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 constitutif de l'ICANN. Le médiateur milite objectivement pour l'équité, cherche à évaluer et, si possible, à résoudre les plaintes relatives à un traitement injuste ou inapproprié de la part du personnel de l'ICANN, du Conseil d'administration ou d'organes constitutifs de l'ICANN, en éclaircissant les problèmes et en utilisant des outils de résolution de litiges tels que la négociation, la facilitation et les « démarches diplomatiques » pour obtenir des résultats.
Le bureau du médiateur :
1. facilite la résolution équitable, impartiale et opportune des problèmes et plaintes que les membres concernés de la communauté de l'ICANN (à l'exception des employés et 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 réexamen ou de révision indépendante ;
2. décide à sa discrétion d'accepter ou de refuser de traiter une plainte ou une question, y compris en développant des procédures pour abandonner les plaintes jugées insuffisamment concrètes, substantielles, ou liées aux interactions de l'ICANN avec la communauté de sorte à ne pas pouvoir être traitées par le médiateur. En outre, et sans limitation des faits précités, le médiateur n'est pas autorisé à agir de quelque manière que ce soit par rapport à des questions administratives internes, des questions personnelles, ou des problèmes ayant trait à l'appartenance au Conseil d'administration ou à des relations vendeur / fournisseur ;
3. a 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 constitutifs pour permettre un examen documenté de la plainte, et faciliter, si possible, la résolution de litiges (sous réserve unique 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. sensibilise au programme du médiateur et à ses fonctions à travers des interactions de routine avec la communauté de l'ICANN et une disponibilité en ligne ;
5. garde sa neutralité et son indépendance, et n'a pas de parti pris ou d'enjeu personnel dans un résultat ; et
6. se conforme à toutes les politiques relatives aux conflits d'intérêt et à la confidentialité de l'ICANN.
Section 4. INTERACTION AVEC LES ENTITÉS DE L'ICANN OU EXTÉRIEURES À L'ICANN
1. Nul employé de l'ICANN, membre du Conseil d'administration, ou autre participant aux organisations 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 et les membres du conseil d'administration doivent diriger les membres de la communauté de l'ICANN qui expriment des problèmes, des préoccupations ou des plaintes à propos de l'ICANN vers le médiateur, qui doit conseiller les plaignants sur les différentes options possibles pour examiner ces problèmes, préoccupations ou plaintes.
2. Le personnel de l'ICANN et les autres membres observent et respectent les décisions du bureau du médiateur concernant la confidentialité des plaintes reçues par ce bureau.
3. Le contact avec le médiateur n'a pas valeur de notification de l'ICANN d'une action particulière ou de la justification d'une action.
4. Le médiateur est spécifiquement autorisé à rendre compte au conseil d'administration à propos d'une question particulière et de sa résolution ou de l'incapacité à la résoudre, selon qu'il le juge 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 sont publiés sur le site Web.
5. Le médiateur ne prend en aucun cas de mesures non autorisées par ces règlements. Notamment, il n'institue pas, n'adhère pas et ne soutient pas, de quelque manière que ce soit, des actions judiciaires contestant la structure, les procédures, ou processus de l'ICANN, ou encore toute conduite de son Conseil d'administration, personnel ou organes constitutifs.
Chaque année, le bureau du médiateur publie 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 des recommandations de démarches à suivre à l'avenir pour réduire le nombre de plaintes. Le rapport annuel est publié sur le site Web.
ARTICLE VI : CONSEIL D'ADMINISTRATION
Section 1. COMPOSITION DU CONSEIL D'ADMINISTRATION
Le Conseil d'administration de l'ICANN (« Conseil d'administration ») se compose de seize membres ayant droit de vote (appelés « administrateurs »). Par ailleurs, cinq agents de liaison (« agents de liaison ») sans droit de vote sont nommés aux fins exposées dans la Section 9 de cet Article. Seuls les administrateurs sont inclus pour atteindre un quorum 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
1. Les administrateurs se composent de :
a. huit membres ayant droit de vote, sélectionnés par le comité de nomination établi par l'Article VII de ces Règlements. Ces sièges au Conseil d'administration sont désignés dans ces règlements comme étant les sièges 1 à 8.
b. deux membres ayant droit de vote sélectionnés par l'organisation de soutien aux politiques d'adressage, conformément aux dispositions de l'Article VIII de ces Règlements. Ces sièges au Conseil d'administration sont désignés dans ces règlements comme étant les sièges 9 et 10.
c. deux membres ayant droit de vote sélectionnés par l'organisation de soutien aux politiques de codes de pays, conformément aux dispositions de l'Article IX de ces Règlements. Ces sièges au Conseil d'administration sont désignés dans ces règlements comme étant les sièges 11 et 12.
d. deux membres ayant droit de vote sélectionnés par l'organisation de soutien aux politiques des noms génériques, conformément aux dispositions de l'Article X de ces Règlements. Ces sièges au Conseil d'administration sont désignés dans ces règlements comme étant les sièges 13 et 14.
e. Un membre ayant droit de vote élu par la communauté des utilisateurs d'Internet conformément aux dispositions de l'Article XI de ces Règlements. Ce siège au Conseil d'administration est désigné dans ces règlements comme étant le Siège 15.
2. En exécutant sa mission consistant à pourvoir les sièges 1 à 8, le comité de nomination cherche à s'assurer que le Conseil d'administration de l'ICANN soit composé de membres qui, dans leur totalité, affichent une diversité géographique, culturelle, de compétences, d'expérience et de perspectives, en appliquant les critères énoncés dans la Section 3 de cet Article. A aucun moment, le comité de nomination ne sélectionne un administrateur pour pourvoir un poste vacant ou un mandat expiré, dont la sélection élèverait à plus de cinq le nombre total d'administrateurs (à l'exception du président) citoyens de pays appartenant à une région géographique (tel que défini dans la Section 5 de cet Article) ; et le comité de nomination s'assure de par ses sélections, que le conseil d'administration comprend, à tout moment, au moins un administrateur citoyen d'un pays de chaque région géographique de l'ICANN.
Pour cette sous sections 2 de l'article VI, section 2 des lois d'ICANN, Si un candidat au conseil détient plusieurs nationalités ou à vécu plus de cinq ans dans un pays dont il n'a pas la nationalité ("Domicile"), le candidat peut être considéré comme représentant de chaque pays et doit choisir dans sa déclaration d'Intérêt le pays dont il est citoyen ou le pays où se trouve son domicile qu'il souhaite que le comité de nomination utilise pour le Calcul de Diversité. Pour cette sous-section 2 de l'article VI, section 2 des lois ICANN, une personne ne peut avoir qu'un seul pays "domicile", qui doit être le pays de résidence permanente.
3. En remplissant son rôle et en allouant les sièges 9 à 15, les organisations de soutien et la communauté des utilisateurs d'Internet doivent chercher à assurer que le conseil soit composé de membres affichant une diversité de géographie, de culture, de capacités, d'expérience et de points de vue, en appliquant les critères stipulés dans la Section 3 de cet Article. A aucun moment donné, deux administrateurs sélectionnés par une organisation de soutien peuvent être citoyens du même pays, ou de pays situés dans la même région géographique.
Pour cette sous sections 3 de l'article VI, section 2 des lois d'ICANN, Si un candidat au conseil détient plusieurs nationalités ou à vécu plus de cinq ans dans un pays dont il n'a pas la nationalité ("Domicile"), le candidat peut être considéré comme représentant de chaque pays et doit choisir dans sa déclaration d'Intérêt le pays dont il est citoyen ou le pays où se trouve son domicile qu'il souhaite que les organisations de soutien et la communauté At-Large utilisent pour la sélection. Pour cette sous-section 3 de l'article VI, section 2 des lois ICANN, une personne ne peut avoir qu'un seul pays "domicile", qui doit être le pays de résidence permanente.
4. Chaque année, le Conseil d'administration élit 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 le fonctionnement des registres et bureaux d'enregistrement de gTLD ; avec les registres de ccTLD ; avec les registres d'adresses IP ; avec les normes et protocoles techniques de l'Internet ; avec les procédures d'élaboration de politiques, les coutumes juridiques et l'intérêt public ; avec la grande variété d'utilisateurs commerciaux, individuels, académiques et non-commerciaux de l'Internet ;
5. des personnes désireuses d'agir de manière bénévole, 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.
Section 4. QUALIFICATIONS SUPPLÉMENTAIRES
1. Sauf disposition contraire, nul fonctionnaire d'un gouvernement national ou officiel d'une entité multinationale établie par traité ou par tout autre accord entre des gouvernements nationaux ne peut remplir la fonction d'administrateur. Le terme d'« officiel » mentionné ci-dessus désigne une personne (i), qui a été élue à une charge gouvernementale ou (ii) qui est employée par un tel gouvernement ou une entité multinationale, et dont la fonction première auprès de ce gouvernement ou de cette entité consiste à élaborer ou influencer les politiques gouvernementales ou publiques.
2. Nulle personne exerçant une fonction (y compris celle d'agent de liaison) au sein du conseil d'une organisation de soutien ne peut agir à la fois en tant qu'administrateur et agent de liaison auprès du conseil d'administration. Si une telle personne accepte une nomination par une Organisation de Soutien ou la communauté des utilisateurs d'Internet pour être directeur, cette personne ne devra plus participer à aucun vote, aucune discussion tenue par ces entités concernant la sélection des directeurs par le conseil ou la communauté, jusqu'à ce le(s) comité(s) désigné(s) par la communauté des utilisateurs d'Internet n'ait sélectionné la totalité des directeurs. Au cas où une personne ayant une fonction quelconque au Conseil d'une Organisation de soutien accepterait une nomination pour être élu comme directeur, le collège ou un autre groupe ou une autre entité ayant choisi cette personne pourra sélectionner un remplaçant pour le processus de sélection du Conseil. Au cas où une personne ayant une fonction quelconque au sein de l'ALAC accepterait une nomination pour être élu par l'ALAC en tant que directeur, le Groupe régional d'organisations d'utilisateurs d'Internet (RALO) ou un autre groupe ou une autre entité ayant sélectionné cette personne pourra choisir un remplaçant pour le processus de sélection de la communauté d'utilisateurs d'Internet.
3. Les personnes exerçant une fonction au sein du comité de nomination ne sont pas éligibles à la sélection aux postes du conseil d'administration, tel qu'indiqué à l'Article VII, Section 8.
Section 5. REPRÉSENTATION INTERNATIONALE
Afin d'assurer que le Conseil soit représenté de façon internationale, la sélection des directeurs par le comité de nomination, chaque organisation supportrice et la communauté At-Large, devra respecter toutes les provisions applicables de ces lois ou tout mémorandum d'entente mentionné dans ces lois concernant l'Organisation de Support. Un des objectifs de ces dispositions 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é plus de cinq administrateurs au Conseil d'administration (sans compter le président). Dans ces règlements, on désigne par « région géographique » : Europe; Asie/Australie/Pacifique; Amérique Latine/Caraïbes; Afrique; et Amérique du Nord. Les pays inclus dans chaque Région Géographique doivent être déterminés par le conseil, et cette section doit être révisée par le conseil de temps en temps (au moins tous les trois ans) pour déterminer si un changement serait approprié, en tenant compte de l'évolution de l'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, exige 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 raisonnablement considérée faire de cet administrateur « un administrateur intéressé », dans le sens de la section 5233 de la loi CNPBCL (loi de Californie régissant les associations à but non lucratif). En outre, chaque administrateur divulgue à l'ICANN toute relation ou tout autre facteur susceptible d'être raisonnablement considéré faire de cet administrateur une « personne intéressée », dans le sens de la section 5227 de la Loi CNPBCL. Le Conseil d'administration adopte des politiques visant spécifiquement les conflits d'intérêt des administrateurs, des cadres, et des organisations de soutien. Nul administrateur ne vote sur des affaires pour lesquelles il a un intérêt financier direct et matériel qui pourrait être affecté par le résultat du vote.
Section 7. DEVOIRS DES ADMINISTRATEURS
Les administrateurs agissent 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 employeurs ou autres organisations ou regroupements.
Section 8. MANDATS DES ADMINISTRATEURS
1. Le mandat régulier des sièges des Administrateurs 1 à 15 commenceront comme indiqué ci-dessous :
a. les mandats réguliers des sièges 1 à 3 commencent à la clôture de l'assemblée annuelle de l'ICANN en 2003 et à celle de chaque assemblée annuelle de l'ICANN tenue tous les trois ans après 2003 ;
b. les mandats réguliers des sièges 4 à 6 commencent à la clôture de l'assemblée annuelle de l'ICANN en 2004, et à celle de chaque assemblée annuelle de l'ICANN tenue tous les trois ans après 2004 ;
c. les mandats réguliers des sièges 7 à 8 commencent à la clôture de l'assemblée annuelle de l'ICANN en 2005, et à celle de chaque assemblée annuelle de l'ICANN tenue tous les trois ans après 2005 ;
d. les mandats des sièges 9 et 12 continueront jusqu'à la clôture de la réunion du milieu de l'année de l'ICANN après l'assemblée annuelle de l'ICANN en 2011. Le prochain mandat des sièges 9 et 12 commencera à la clôture de la réunion du milieu de l'année ayant lieu après l'assemblée annuelle de l'ICANN de 2011 et à celle de chaque assemblée annuelle de l'ICANN tenue tous les trois ans après 2011 ;
e. les mandats des sièges 10 et 13 continueront jusqu'à la clôture de la réunion du milieu de l'année de l'ICANN ayant lieu après l'assemblée annuelle de l'ICANN de 2012. Les prochains mandats des sièges 10 et 13 commenceront à la clôture de la réunion du milieu de l'année qui aura lieu après l'assemblée annuelle de l'ICANN de 2012 et à celle de chaque assemblée annuelle de l'ICANN tenue tous les trois ans après 2012 ; et
f. Les prochains mandats des sièges 11 et 14 commenceront à la clôture de la réunion du milieu de l'année de l'ICANN qui aura lieu après l'assemblée annuelle de l'ICANN de 2010 et à celle de chaque assemblée annuelle de l'ICANN tenue tous les trois ans après 2010.
g. Le premier mandat régulier du siège 15 commencera à la clôture de la réunion du milieu de l'année de l'ICANN qui aura lieu après l'assemblée annuelle de l'ICANN de 2010 et à celle de chaque assemblée annuelle de l'ICANN tenue tous les trois ans après 2010 (Remarque : Pendant la période précédant le début du mandat régulier du siège 15, celui-ci est considéré comme vacant. Par un processus coordonné par l'ALAC, la communauté des utilisateurs d'Internet fait la sélection d'un administrateur pour occuper le siège 15 vacant et en informe par écrit le Secrétariat de l'ICANN. Le siège 15 vacant a été pourvu à la clôture de l'assemblée annuelle de l'ICANN de 2010, avec un mandat qui conclura avec le début d'un premier mandat régulier spécifié pour le siège 15 conformément à la présente section des Règlements. Jusqu'à la fermeture du meeting annuel ICANN 2010, une liaison non votante désignée par l'ALAC a participé comme spécifié dans les sections 9(3) et 9(5) de cet article.
h. Aux fins de cette section, le terme « réunion du milieu de l'année » concerne la première réunion publique de l'ICANN ayant lieu entre six et huit mois après la clôture de l'Assemblée générale annuelle de l'ICANN. Au cas où une réunion du milieu de l'année serait programmée et puis annulée dans les six mois précédant son début, le mandat de tout siège programmé pour commencer à la clôture de cette réunion du milieu de l'année commencera à la date préalablement programmée pour la clôture. Au cas où aucune réunion publique ne serait programmée pendant le temps défini pour la réunion du milieu de l'année, le mandat de tout siège devant commencer à la clôture de cette réunion du milieu de l'année devra alors débuter six mois après la clôture de l'Assemblée annuelle de l'ICANN.
2. Chaque administrateur occupant un des sièges 1 à 15, y compris l'administrateur sélectionné pour pourvoir un poste vacant, exerce sa fonction pour un mandat qui dure jusqu'au début du mandat suivant pour ce siège et jusqu'à ce qu'un successeur ait été sélectionné et qualifié ou jusqu'à ce que l'administrateur démissionne ou soit relevé de ses fonctions conformément à ces règlements.
3. Au minimum deux mois avant le début de chaque assemblée annuelle, le comité de nomination remet au secrétaire de l'ICANN un avis comprenant sa sélection d'administrateurs pour les sièges dont les mandats commencent à la clôture de l'assemblée annuelle.
4. Au moins deux mois avant la date spécifiée pour le commencement d'un mandat, comme indiqué aux paragraphes 1.d-g ci-dessus, toute Organisation de soutien ou communauté d'utilisateurs d'Internet ayant droit à la sélection d'un administrateur pour un siège avec un mandat qui commence cette année devra informer par écrit de sa décision le Secrétaire de l'ICANN.
5. Sous réserve des dispositions de l'article de transition de ces règlements, nul 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. Tout service préalable aux sièges 9, 10, 11, 12, 13 et 14 dans les termes définis dans les Règlements en date du (insérer la date avant la modification en vigueur), dans la mesure où ce service ne concernait pas une vacance, devra être inclus dans le calcul des mandats consécutifs aux termes du présent paragraphe.
6. Le mandat d'administrateur de la personne exerçant la fonction de président dure aussi longtemps que, et seulement aussi longtemps que, la personne exerce la fonction de président.
Section 9. AGENTS DE LIAISON SANS DROIT DE VOTE
1. Les agents de liaison sans droit de vote comprennent :
a. un agent de liaison nommé par le Comité consultatif gouvernemental ;
b. un agent de liaison nommé par le comité consultatif du système de serveurs racine établi par l'Article XI de ces Règlements ;
c. un agent de liaison nommé par le comité consultatif sur la sécurité et la stabilité établi par l'Article XI de ces Règlements ;
d. un agent de liaison nommé par le groupe de liaison technique établi par l'Article XI-A de ces Règlements ;
e. un agent de liaison nommé par le groupe de travail de l'ingénierie Internet.
2. Sous réserve des dispositions de l'Article de transition de ces Règlements, les agents de liaison sans droit de vote exercent des mandats prenant effet à la clôture de chaque assemblée annuelle. Chaque entité habilitée à nommer un agent de liaison sans droit de vote remet au secrétaire de l'ICANN, au minimum un mois avant le début de chaque assemblée annuelle, un avis comprenant sa nomination.
3. Les agents de liaison sans droit de vote sont des bénévoles, sans autre compensation que le remboursement de certains frais.
4. Chaque agent de liaison sans droit de vote peut être renommé et conserve ses fonctions jusqu'à ce qu'un successeur ait été nommé ou jusqu'à ce que l'agent de liaison démissionne ou soit relevé de ses fonctions conformément à ces règlements.
5. Les agents de liaison sans droit de vote sont habilités à assister aux réunions du Conseil d'administration, à participer aux discussions et délibérations du Conseil d'administration, et ont accès (selon des conditions établies par le Conseil d'administration) aux documents fournis aux administrateurs et utilisés dans les discussions, délibérations et réunions du Conseil d'administration. Ils ne bénéficient en revanche d'aucun droit ni privilège d'administrateur. Les agents de liaison sans droit de vote sont habilités (selon des conditions établies par le Conseil d'administration) à utiliser tous documents qui leur sont fournis en accord avec cette section pour pouvoir consulter leur comité ou leur organisation respective.
Section 10. DÉMISSION D'UN ADMINISTRATEUR OU D'UN AGENT DE LIAISON SANS DROIT DE VOTE
Sous réserve de la section 5226 de la loi 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 (rapidement suivie d'un avis à l'adresse du secrétaire de l'ICANN) soit par voie écrite au président ou secrétaire de l'ICANN. Cette démission entre en vigueur au moment indiqué, et, sauf spécification contraire, l'acceptation de cette démission n'est pas nécessaire pour la rendre effective. Le successeur sera sélectionné 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é, après avoir été prévenu, par le vote d'une majorité des trois-quarts (3/4) des administrateurs ; et ce, pourvu que l'administrateur faisant l'objet de cette révocation ne soit pas habilité à voter sur cette action ou ne compte pas pour un membre du Conseil d'administration ayant droit de vote lors du calcul des trois-quarts (3/4) des votes requis ; et ce, pourvu encore que chaque vote pour la révocation d'un administrateur soit un vote séparé concernant uniquement la question de la révocation de cet administrateur en particulier. Si l'administrateur a été sélectionné par une organisation de soutien, celle-ci devra en être notifiée en même temps que l'administrateur. Si l'administrateur a été sélectionné par la communauté des utilisateurs d'Internet, l'ALAC devra en être notifié en même temps que l'administrateur.
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 avis transmis à ce dernier ainsi qu'à l'organisation par laquelle l'agent de liaison a été sélectionné, sur vote de la majorité de trois-quarts (3/4) des administrateurs si l'organisation qui l'a sélectionné omet de révoquer cet agent de liaison sans délai après un tel avis. Le Conseil d'administration peut exiger du comité consultatif gouvernemental d'envisager le remplacement de l'agent de liaison sans droit de vote nommé par ce comité si le Conseil d'administration, sur vote de la majorité de trois-quarts (3/4) des administrateurs, décide que cette action est appropriée.
1. Un ou plusieurs postes d'administrateurs vacants sont réputés exister en cas de décès, de démission ou de révocation de tout administrateur ; si le nombre autorisé d'administrateurs est augmenté ; si un administrateur a été jugé ne pas jouir de toutes ses facultés mentales par ordonnance définitive ou s'il a été condamné pour crime ou incarcéré pendant plus de 90 jours suite à une condamnation ou encore s'il a été jugé par ordonnance définitive ou par jugement de tout tribunal coupable d'une atteinte au droit moral au sens des sections 5230 et suivantes de la loi CNPBCL. Tout poste vacant au Conseil d'administration est pourvu par le comité de nomination, à moins (a) que cet administrateur n'ait été sélectionné par une organisation de soutien, auquel cas ce poste est pourvu par cette organisation de soutien ; ou (b) que l'administrateur n'ait rempli la fonction de président, et dans ce cas, le poste vacant est pourvu conformément aux dispositions de l'Article XIII de ces Règlements. L'organe chargé de la sélection remet un avis au secrétaire de l'ICANN avec ses nominations pour pourvoir lesdits postes vacants. Un administrateur sélectionné pour pourvoir un poste vacant au Conseil d'administration remplit cette fonction pour la durée restante du mandat 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 n'a pour effet de révoquer un administrateur avant que son mandat ne vienne à expiration.
2. Les organisations en charge de la sélection des agents de liaison sans droit de vote identifiés dans la Section 9 de cet Article sont en charge de déterminer l'existence de tout poste vacant et, le cas échéant, de pourvoir ces postes. Elles remettent un avis au secrétaire de l'ICANN avec leurs nominations pour pourvoir ces postes vacants.
Section 13. ASSEMBLÉES ANNUELLES
Des assemblées annuelles de l'ICANN sont tenues dans le but d'élire les membres de la direction et de traiter toute autre affaire éventuellement survenue avant la réunion. Toutes les assemblées annuelles de l'ICANN se tiennent dans les bureaux principaux de l'ICANN ou à tout autre endroit approprié à la date et à la convenance du Conseil d'administration, à condition qu'une telle assemblée annuelle soit organisée dans les 14 mois suivant la toute dernière assemblée annuelle. Si le Conseil d'administration l'estime pratique, l'assemblée annuelle pourra ê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 sont tenues aux dates qu'il aura indiquées. En l'absence de toute autre spécification, les réunions régulières sont tenues dans les bureaux principaux de l'ICANN.
Section 15. RÉUNIONS EXTRAORDINAIRES
Les réunions extraordinaires du Conseil d'administration peuvent être convoquées par ou à 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 de convocation d'une réunion extraordinaire est formulée par le secrétaire de l'ICANN. En l'absence de toute autre spécification, les réunions extraordinaires sont tenues dans les bureaux principaux de l'ICANN.
Section 16. AVIS DE CONVOCATION DES RÉUNIONS
Un avis de convocation de toutes les réunions indiquant le jour et l'endroit est remis personnellement, par téléphone ou par courrier électronique, à chaque administrateur et agent de liaison sans droit de vote, ou envoyé par courrier prioritaire (par avion pour les adresses en dehors des Etats-Unis) ou par 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, telle qu'indiquée dans les registres de l'ICANN. Dans le cas où l'avis de convocation est adressé par courrier, il doit être posté aux États-Unis au minimum quatorze (14) jours avant la tenue de la réunion. Dans le cas où l'avis de convocation est délivré personnellement, par téléphone, télécopie, ou courrier électronique, il doit être délivré personnellement, par téléphone, télécopie ou courrier électronique au minimum quarante-huit (48) heures avant la tenue de la réunion. Nonobstant toute disposition contraire dans cette section, l'avis de convocation d'une réunion ne doit pas être remis à un administrateur ayant renoncé ou consenti par écrit à la tenue de la réunion ou ayant signé une approbation du compte-rendu, avant ou après la réunion ou encore ayant assisté à la réunion sans protester, avant celle-ci ou à l'ouverture, pour la non réception d'avis de convocation par cet administrateur. Ces renonciations, consentements et approbations sont incorporés aux documents sociaux ou aux comptes-rendus des réunions.
Lors de toutes les assemblées annuelles, réunions régulières ou extraordinaires du Conseil d'administration, une majorité de l'ensemble des administrateurs alors en fonction constitue un quorum pour le traitement des affaires, et l'action d'une majorité des administrateurs présents à toute réunion ayant atteint le quorum, constitue une action du Conseil d'administration, sauf dispositions contraires de la loi ou de ces règlements. Si le quorum n'est pas atteint lors d'une réunion du Conseil d'administration, les administrateurs présents peuvent ajourner la réunion à un(e) autre endroit, heure ou date. Si la réunion est ajournée de plus de vingt-quatre (24) heures, un avis de convocation est remis aux administrateurs absents au moment de l'ajournement.
Section 18. ACTION PAR TÉLÉCONFÉRENCE OU TOUT AUTRE MOYEN DE COMMUNICATION
Les membres du Conseil d'administration ou de tout comité du Conseil d'administration peuvent participer à une réunion du Conseil d'administration ou du comité du Conseil d'administration via (i) une téléconférence ou un autre moyen de communication similaire, à condition que tous les administrateurs prenant part à une telle réunion puissent se parler et s'entendre les uns les autres, ou via (ii) des écrans de communication électronique ou autre moyen de communication, à condition que (a) tous les administrateurs prenant part à une telle réunion puissent se parler et s'entendre les uns les autres, (b) que les moyens de participer pleinement à l'ensemble de la procédure auprès du Conseil d'administration ou du comité de ce Conseil d'administration soient fournis à tous les administrateurs, et (c) que l'ICANN adopte et mette en place des moyens de vérifier (x) qu'une personne participant à une telle réunion est bien un administrateur ou une autre personne habilitée à participer à la réunion et (y) que toutes les mesures, ou votes du Conseil d'administration ou du comité du Conseil d'administration sont uniquement pris ou exprimés par les membres du Conseil d'administration ou du comité et non par des personnes qui ne sont pas membres. La participation à une réunion conformément à cette section revient à assister en personne à une telle réunion. L'ICANN met à disposition des membres du Conseil d'administration, sur le lieu de chaque réunion du Conseil d'administration, l'équipement de télécommunication nécessaire pour leur permettre de participer par téléphone.
Section 19. ACTION SANS RÉUNION
Toute action requise ou que le Conseil d'administration ou un comité du Conseil d'administration est autorisé à entreprendre peut l'être sans réunion, si tous les administrateurs habilités à voter formulent individuellement ou collectivement par écrit leur consentement vis-à-vis d'une telle action. Ce consentement écrit aura la même force et les mêmes effets que le vote unanime de ces directeurs. Ce consentement ou consentements écrits seront déposés dans les minutes des procédures du Conseil d'administration.
Section 20. COURRIER ÉLECTRONIQUE
Si la loi en vigueur le permet, la communication par courrier électronique est considérée équivalente à toute autre communication ne nécessitant pas d'être formulée par écrit. L'ICANN prend les 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 a le droit, à tout moment raisonnable, de contrôler et de copier tous les livres, registres et documents en tout genre ainsi que d'inspecter les propriétés physiques de l'ICANN. L'ICANN établit des procédures raisonnables pour se protéger contre la divulgation inappropriée d'informations confidentielles.
Le Président du Conseil d'administration de l'ICANN sera autorisé à percevoir une rémunération raisonnable pour ses services en tant qu'administrateur. Le comité de rémunération devra recommander une rémunération d'un niveau raisonnable pour le Président du Conseil d'administration. Seuls les membres du comité de rémunération qui ne sont pas concernés par des conflits d'intérêts par rapport à la partie pour laquelle il faut analyser la rémunération participeront aux délibérations ou voteront la recommandation pour le Conseil d'administration. Seuls les membres du Conseil d'administration qui ne sont pas concernés par des conflits d'intérêts par rapport à la partie pour laquelle il faut analyser la rémunération participeront aux délibérations ou voteront l'approbation pour le Conseil d'administration. Le Président du Conseil d'administration ne participera jamais aux délibérations ni au vote concernant la rémunération pour la présidence du Conseil d'administration. Le Comité de rémunérations et le Conseil d'administration suivront les processus appropriés prévus au code des impôts des Etats-Unis et dans la réglementation applicable du Trésor des Etats-Unis pour garantir qu'il y a une présomption réfutable d'une rémunération raisonnable établie pour le Président du Conseil d'administration.
Aucun administrateur, autre que le Président du Conseil d'administration, ne recevra de rémunération pour ses services en tant qu'administrateur. Le Conseil d'administration peut toutefois autoriser le remboursement de dépenses réelles et nécessaires raisonnables engagées par n'importe lequel des administrateurs et des agents de liaison sans droit de vote dans le cadre de leur fonction d'administrateur ou d'agent de liaison sans droit de vote.
Section 23. PRÉSOMPTION D'ASSENTIMENT
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 désaccord ou son abstention ne soient mentionnés dans le compte-rendu de la réunion, ou qu'il remette par écrit son désaccord ou son abstention par rapport à une telle action à la personne agissant en tant que secrétaire de la réunion avant l'ajournement, ou transmette son désaccord ou son abstention par courrier recommandé au secrétaire de l'ICANN immédiatement après l'ajournement de la réunion. Un tel droit au désaccord ou à l'abstention n'est pas applicable à un administrateur ayant voté en faveur de ladite action.
ARTICLE VII : COMITÉ DE NOMINATION
Il est établi 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 organisations de soutien de l'ICANN, ainsi que des autres sélections indiquées dans ces règlements.
Le comité de nomination se compose des personnes suivantes :
1. un président sans droit de vote, nommé par le Conseil d'administration de l'ICANN ;
2. un président élu sans droit de vote, nommé par le Conseil d'administration de l'ICANN en tant que conseiller sans droit de vote ;
3. Un agent de liaison sans droit de vote nommé par le comité consultatif du système de serveurs racine établi par l'Article XI de ces Règlements ;
4. un agent de liaison sans droit de vote nommé par le comité consultatif pour la sécurité et la stabilité établi par l'Article XI de ces Règlements ;
5. un agent de liaison sans droit de vote nommé par le Comité consultatif gouvernemental ;
6. sous réserve des dispositions de l'article de transition de ces règlements, cinq délégués dotés d'un droit de vote, sélectionnés par le comité consultatif At-Large établi par l'Article XI de ces Règlements ;
7. Les délégués dotés d'un droit de vote du Comité de nomination seront sélectionnés par l'Organisation de soutien aux politiques des noms génériques suivant ce qui est établi dans l'Article X de ces Règlements ;
a. Un délégué du groupe multipartite des registres ;
b. Un délégué du groupe multipartite des bureaux d'enregistrement ;
c. Deux délégués du regroupement des utilisateurs commerciaux d'Internet, l'un représentant les utilisateurs commerciaux et l'autre représentant les grandes entreprises ;
d. Un délégué du collège regroupant les fournisseurs de services Internet ;
e. Un délégué du regroupement de la propriété intellectuelle ; et
f. Un délégué des groups des consommateurs et de la société civile, sélectionnés par le regroupement des utilisateurs non commerciaux.
8. Un délégué doté d'un droit de vote sélectionné par les entités suivantes :
a. le Conseil de l'Organisation de soutien aux politiques des noms de pays (CCNSO), établie par l'Article IX de ces Règlements ;
b. Le conseil des organisations de soutien aux politiques d'adressage établi par Article VIII de ces Règlements ;
c. le groupe de travail de l'ingénierie Internet ; et
d. le groupe de liaison technique de l'ICANN, établi par l'Article XI-A de ces Règlements ; et
9. un président adjoint 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. Le président adjoint ne peut pas être une personne autrement membre du même comité de nomination. Le président adjoint assiste le président dans l'exercice de sa fonction, mais n'agit en aucun cas, temporairement ou autre, à sa place.
Sous réserve des dispositions de l'Article de transition de ces Règlements :
1. tout délégué ayant droit de vote exerce 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 doit attendre au minimum deux ans pour être à nouveau éligible.
2. Le mandat régulier de chaque délégué ayant droit de vote commence à la clôture de l'assemblée annuelle de l'ICANN et se termine à la clôture de l'assemblée annuelle suivante de l'ICANN.
3. Les agents de liaison sans droit de vote exercent leur fonction au cours du mandat indiqué par l'entité à l'origine de leur nomination. Le président, le président élu et tout président associé exerceront leurs fonctions jusqu'à la clôture de l'assemblée annuelle suivante de l'ICANN.
4. Selon toute vraisemblance, à la fin du mandat du président élu, le président élu sera nommé par le Conseil d'administration pour la présidence. Toutefois, le Conseil d'administration peut, à sa discrétion, nommer toute autre personne pour la présidence. Si, au moment de la nomination d'un président élu, le Conseil d'administration détermine que la personne destinée à la fonction du président doit être nommée comme président pour une période consécutive, la fonction du président élu restera vacante pour la période désignée par le Conseil d'administration.
5. Les postes vacants de délégués, d'agents de liaison sans droit de vote, du président ou du président élu sont pourvus par l'entité habilitée à la sélection des délégués, agents de liaison sans droit de vote, président ou président élu concernés. Pour toute période à laquelle le poste de président élu est vacant conformément au paragraphe 4 de cet Article, ou jusqu'à ce que tout autre poste vacant pour un président élu puisse être pourvu, un conseiller sans droit de vote pour la présidence pourra être nommé par le Conseil d'administration parmi les personnes ayant préalablement servi au Conseil d'administration ou à un Comité de nomination, y compris le dernier président du Comité de nomination. Un poste vacant de président adjoint peut être pourvu par le président, conformément aux critères établis par la section 2(9) de cet article.
6. L'existence de postes vacants n'affecte pas l'obligation du comité de nomination d'assumer les responsabilités qui lui sont confiées dans ces règlements.
Section 4. CRITÈRES POUR LA SÉLECTION DES DÉLÉGUÉS DU COMITÉ DE NOMINATION
Les délégués au comité de nomination de l'ICANN sont :
1. des personnes réputées pour leur intégrité, objectivité et intelligence, ainsi que pour leur bon jugement, leur ouverture d'esprit, 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 dévouées au 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 contributions 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 activités sur l'ensemble de la communauté Internet au sens large, et qui soient prêtes à s'engager bénévolement, 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 l'exécution de ses responsabilités de sélection des membres du Conseil d'administration de l'ICANN (ainsi que de sélection à tout autre organe de l'ICANN dont le comité de nomination est responsable, conformément à ces règlements), le comité de nomination prend en considération l'adhésion continue des membres du Conseil d'administration (et de tout autre organe), et cherche à garantir que les personnes sélectionnées pour pourvoir les postes vacants au Conseil d'administration de l'ICANN (et de tout autre organe de la sorte) effectueront, dans la mesure du possible et conformément aux autres critères exigés dans la Section 4 de cet Article, des sélections guidées par la valeur principale 4 de l' Article I, Section 2.
Section 6. SOUTIEN ADMINISTRATIF ET OPÉRATIONNEL
L'ICANN fournit au comité de nomination le soutien administratif et opérationnel nécessaire pour l'exercice de ses responsabilités.
Le comité de nomination adopte les procédures de fonctionnement qu'il juge nécessaires. Celles-ci sont publiées sur le site Web.
Section 8. INÉLIGIBILITÉ A 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 à une quelconque position au Conseil d'administration ou à 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 assemblée annuelle de l'ICANN qui coïncide avec, ou survient après la fin du service de cette personne dans le comité de nomination.
Section 9. INÉLIGIBILITÉ AU SERVICE DANS LE COMITÉ DE NOMINATION
Aucun employé ou consultant rémunéré de l'ICANN (y compris le médiateur) ne peut simultanément exercer de fonction aux postes du comité de nomination décrites dans la Section 2 de cet Article.
ARTICLE VIII : ORGANISATION DE SOUTIEN AUX POLITIQUES D'ADRESSAGE
1. L'organisation de soutien aux politiques d'adressage (ASO) conseille le Conseil d'administration de l'ICANN sur les questions de politiques relatives au fonctionnement, à l'attribution et à la gestion des adresses Internet.
2. L'ASO est l'entité établie par le protocole d'entente conclu le 21 octobre 2004 entre l'ICANN et le NRO (Number Resource Organization), une organisation des registres Internet régionaux actuels (RIR).
Section 2. CONSEIL D'ADRESSAGE
1. L'ASO a un conseil d'adressage, composé des membres du conseil du NRO.
2. Le conseil d'adressage sélectionne les administrateurs aux sièges du Conseil d'administration désignés comme devant être pourvus par l'ASO.
ARTICLE IX : ORGANISATION DE SOUTIEN AUX POLITIQUES DE CODES DE PAYS
Il est établi un organe de développement de politiques appelé organisation de soutien aux politiques de codes de pays (ccNSO), chargé de :
1. développer et recommander au Conseil d'administration de l'ICANN des politiques mondiales relatives aux noms de domaines de codes de pays de premier niveau ;
2. promouvoir un consensus au sein de la communauté de la ccNSO, notamment concernant les activités des ccTLD liées aux noms ; et
3. collaborer avec d'autres organisations de soutien, comités et regroupements de l'ICANN.
Les politiques appliquées aux membres de la ccNSO en vertu de leur adhésion sont uniquement celles établies conformément aux sections 4.10 et 4.11 de cet article. Toutefois, le ccNSO peut é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 peuvent consister à : chercher à développer bénévolement de meilleures pratiques pour les gestionnaires de ccTLD, participer au renforcement de compétences au sein de la communauté mondiale des gestionnaires de ccTLD, et améliorer la coopération opérationnelle et technique parmi les gestionnaires de ccTLD.
Le ccNSO se compose de (i) gestionnaires de ccTLD qui ont accepté par écrit d'être membres de la ccNSO (voir la section 4(2) de cet article) et (ii) d'un conseil de la ccNSO responsable de la gestion du processus d'élaboration de politiques de la ccNSO.
Section 3. CONSEIL De la ccNSO
1. Le conseil de la ccNSO se compose de (a) trois membres du conseil de la ccNSO sélectionnés par les membres de la ccNSO au sein de chaque Région géographique de l'ICANN, comme décrit dans la Section 4(7) à (9) de cet Article ; (b) trois membres du conseil de la ccNSO sélectionnés par le comité de nomination de l'ICANN ; (c) des agents de liaison, comme indiqué au paragraphe 2 de cette Section; et (iv) des observateurs, comme mentionné au paragraphe 3 de cette Section.
2. Il y a également un agent de liaison du conseil de la ccNSO provenant de chacune des organisations suivantes, dans la mesure où ces dernières choisissent de nommer un tel agent de liaison : (a) le comité consultatif gouvernemental (GAC) ; (b) le comité consultatif At-Large ; et (c) chacune des organisations régionales décrites dans la Section 5 de cet Article. Ces agents de liaison ne sont pas membres ou habilités à voter au conseil de la ccNSO, mais sont cependant habilités à participer sur un pied d'égalité avec les membres du conseil de la ccNSO. Les nominations des agents de liaison sont effectuées en soumettant un avis au secrétaire de l'ICANN, ainsi qu'une copie de notification au président du conseil de la ccNSO, et concernent le mandat désigné par l'organisation chargée de la nomination comme indiqué dans l'avis. L'organisation chargée de la nomination peut révoquer ou remplacer son agent de liaison à tout moment en remettant un avis au secrétaire de l'ICANN faisant part de la révocation ou du remplacement, et en adressant une copie de notification au président du conseil de la ccNSO.
3. Le conseil de la ccNSO peut convenir avec le conseil de toute autre organisation de soutien de l'ICANN d'échanger des observateurs. Ces observateurs ne sont pas membres ou habilités à voter au conseil de la ccNSO, mais sont cependant habilités à participer sur un pied d'égalité avec les membres du conseil de la ccNSO. Le conseil chargé de la nomination peut, à tout moment, désigner son observateur (ou révoquer ou changer la désignation de celui-ci) au conseil de la ccNSO, en remettant un avis au secrétaire de l'ICANN ainsi qu'une copie de notification au président du conseil de la ccNSO.
4. Sous réserve des dispositions de Article de transition de ces Règlements : (a) le mandat régulier de chaque membre du conseil de la ccNSO commence à la clôture d'une assemblée annuelle de l'ICANN et prend fin à la clôture de la troisième assemblée annuelle de l'ICANN suivante ; (b) les mandats réguliers des trois membres du conseil de la ccNSO sélectionnés par les membres de la ccNSO au sein de chaque région géographique de l'ICANN sont échelonnés de manière à ce que le mandat d'un des membres commence au cours d'une année divisible par trois, celui d'un deuxième membre au cours de la première année suivant une année divisible par trois, et que le mandat du troisième membre commence au cours de la deuxième année suivant une année divisible par trois ; et (c) les mandats réguliers des trois membres du conseil de la ccNSO sélectionnés par le comité de nomination sont échelonnés de la même manière. Chaque membre du conseil de la ccNSO garde ses fonctions au cours de son mandat régulier et jusqu'à ce qu'un successeur ait été sélectionné et qualifié ou jusqu'à ce que ce membre démissionne ou soit relevé de ses fonctions conformément à ces règlements.
5. Un membre du conseil de la ccNSO peut démissionner à tout moment en remettant un préavis au secrétaire de l'ICANN, et en adressant une copie de notification au président du conseil de la ccNSO.
6. Les membres du conseil de la ccNSO peuvent être révoqués en cas de trois absences consécutives au conseil de la ccNSO en l'absence d'une justification suffisante ou en cas de comportement tout à fait inapproprié, les deux cas devant être déterminés par le vote d'au moins 66% de tous les membres du conseil de la ccNSO.
7. Un poste au conseil de la ccNSO est considéré vacant en cas de décès, démission ou révocation de tout membre du conseil de la ccNSO. Des postes vacants des trois membres sélectionnés par le comité de nomination sont pourvus pour la durée restante du mandat par le comité de nomination, qui remettra au secrétaire de l'ICANN un avis comprenant sa sélection, ainsi qu'une copie de notification adressée au président du conseil de la ccNSO. Les postes vacants de membres du conseil de la ccNSO sélectionnés par les membres de la ccNSO sont pourvus pour la durée restante du mandat selon la procédure décrite dans la Section 4(7) à (9) de cet Article.
8. La fonction du conseil de la ccNSO consiste à administrer et à coordonner les activités de la ccNSO (y compris la coordination des réunions, y compris l'assemblée annuelle, des membres de la ccNSO comme stipulé dans la Section 4(6) de cet Article) et à gérer l'élaboration de recommandations de politiques, conformément à la section 6 de cet article. Le conseil de la ccNSO assume également d'autres rôles de temps à autre, selon les décisions des membres de la ccNSO.
9. Le conseil de la ccNSO procède aux sélections pour pourvoir les sièges 11 et 12 au Conseil d'administration, par scrutin ou par mesure prise lors d'une réunion ; toute sélection doit obtenir les votes affirmatifs de la majorité de l'ensemble des membres du conseil de la ccNSO alors en fonction. La notification des sélections du conseil de la ccNSO est faite par écrit par le président du conseil de la ccNSO au secrétaire de l'ICANN, conformément à l'article VI, Sections 8(4) et 12(1).
10. Le conseil de la ccNSO choisit parmi ses membres le président du conseil de la ccNSO ainsi que le ou les vice(s) président(s), tel qu'il le juge approprié. Les sélections du président et du / des vice(s) président(s) du conseil de la ccNSO sont effectuées par scrutin ou par mesure prise lors d'une réunion ; toute sélection doit obtenir les votes affirmatifs de la majorité de l'ensemble des membres du conseil de la ccNSO, alors en fonction. Le mandat du président et du / des vice(s) président(s) du conseil de la ccNSO est celui défini par le conseil de la ccNSO au moment où, ou avant que la sélection ne soit faite. Le président ou le / les vice(s) président(s) du conseil de la ccNSO peut être révoqué par la même procédure que celle utilisée pour la sélection.
11. Le conseil de la ccNSO, sur les conseils des membres de la ccNSO, adopte les règles et procédures pour le ccNSO qu'il juge nécessaires, à condition qu'elles soient conformes à ces règlements. Les règles concernant l'adhésion au ccNSO et les procédures de fonctionnement adoptées par le conseil de la ccNSO sont publiées sur le site Web.
12. Sauf dispositions des paragraphes 9 et 10 de cette Section, le conseil de la ccNSO intervient lors des réunions. Le conseil de la ccNSO tient des réunions régulières qu'il aura préalablement programmées, à raison d'un minimum de quatre réunions par année civile. A la discrétion du conseil de la ccNSO, les réunions peuvent être tenues en personne ou par tout autre moyen, à condition que les membres du conseil de la ccNSO puissent participer par le biais d'au moins l'un des moyens décrits dans le paragraphe 14 de cette Section. Sauf lorsqu'un vote majoritaire des membres du conseil de la ccNSO présents établit qu'une session en huis-clos est appropriée, les réunions physiques sont ouvertes à toute personne intéressée et désireuse d'y assister. Dans la mesure du possible, les réunions du conseil de la ccNSO devraient être tenues conjointement avec des réunions du conseil d'administration, ou d'une ou de plusieurs des autres organisations de soutien de l'ICANN.
13. Un avis comprenant la date et le lieu (et des informations concernant les moyens de participation autres que la présence personnelle) de toutes les réunions du conseil de la ccNSO est transmis à chaque membre du conseil de la ccNSO, agent de liaison et observateur, par courrier électronique, téléphone, télécopie, ou encore sur support papier délivré personnellement ou posté. Dans le cas où l'avis est adressé par la poste, il est posté au minimum 21 jours avant le jour de la réunion. Dans le cas où l'avis est remis personnellement, par téléphone, télécopie, ou courrier électronique, il est délivré au minimum sept jours avant le jour de la réunion. Au moins sept jours avant chaque réunion du conseil de la ccNSO (sinon le plus tôt possible), un avis de la réunion, et dans la mesure du possible, un ordre du jour pour la réunion sont publiés en ligne.
14. Les membres du conseil de la ccNSO peuvent participer à une réunion du conseil de la ccNSO en s'y rendant personnellement, ou par le biais d'une communication électronique (comme le téléphone ou la vidéoconférence), à condition (a) que tous les membres du conseil de la ccNSO participant à la réunion puissent parler et s'entendre les uns les autres, (b) que tous les membres du conseil de la ccNSO participant à la réunion aient à leur disposition les moyens de participer activement à toutes les questions auprès du conseil de la ccNSO, et (c) qu'il soit possible de vérifier, par des moyens raisonnables, l'identité des membres du conseil de la ccNSO participant à la réunion et leurs votes. Une majorité des membres du conseil de la ccNSO (c'est-à-dire ceux habilités à voter) alors en fonction constitue un quorum pour le traitement des affaires, et les actes d'un vote majoritaire des membres du conseil de la ccNSO présents à toute réunion ayant atteint un quorum constituent des actes du conseil de la ccNSO, sauf disposition contraire dans ces règlements. Le conseil de la ccNSO transmet les comptes-rendus de ses réunions au secrétaire de l'ICANN, qui fait en sorte qu'ils soient publiés sur le site Web, aussitôt que possible et au plus tard 21 jours après la réunion.
1. Les membres de la ccNSO sont des gestionnaires de ccTLD. Tout gestionnaire de ccTLD remplissant les critères d'adhésion précisés au paragraphe 2 de cette Section est habilité à devenir membre de la ccNSO. Aux fins de cet article, on entend par « gestionnaire de ccTLD », l'organisation ou entité responsable de la gestion d'un nom de domaine de premier niveau de code de pays ISO 3166 et désigné dans la base de données de l'IANA sous l'intitulé actuel d'« organisation commanditaire », ou sous toute autre variante future, pour ce nom de domaine de premier niveau de code de pays.
2. Tout gestionnaire de ccTLD devient membre de la ccNSO en soumettant sa candidature à une personne désignée par le conseil de la ccNSO pour recevoir les différentes candidatures. Sous réserve de l'article de transition de ces règlements, la candidature doit être formulée par écrit et selon le modèle indiqué par le conseil de la ccNSO. La candidature doit inclure la reconnaissance de la part du gestionnaire de ccTLD du rôle de la ccNSO au sein de la structure de l'ICANN ainsi que l'accord du gestionnaire de ccTLD, pendant la durée de son adhésion au ccNSO, (a) sur l'adhésion aux règles de la ccNSO, y compris aux règles d'adhésion, (b) sur le respect des politiques élaboré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) sur le règlement des frais d'adhésion établis par le conseil de la ccNSO dans la Section 7(3) de cet Article. Un membre de la ccNSO peut, à tout moment, résilier son adhésion en remettant un préavis à une personne désignée par le conseil de la ccNSO pour recevoir les préavis de démission. A compter de sa démission, le gestionnaire de ccTLD ne convient plus (a) d'adhérer aux règles de la ccNSO, y compris à celles concernant l'adhésion, (b) de respecter les politiques élaborées et recommandées par le ccNSO et adoptées par le conseil d'administration, telles qu'elles sont décrites aux 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 de la ccNSO d'une personne chargée de recevoir les candidatures et préavis de démission, ceux-ci sont envoyés au secrétaire de l'ICANN, qui avertit le conseil de la ccNSO de leur réception.
3. Aucune adhésion au ccNSO ou à toute autre organisation régionale décrite dans la Section 5 de cet Article ne constitue une condition pour l'accès ou l'inscription à la base de données de l'IANA. Toute relation individuelle entre un gestionnaire de ccTLD et l'ICANN ou la réception de services de l'IANA par le gestionnaire de ccTLD n'influence en aucun cas l'adhésion au ccNSO.
4. Les régions géographiques des ccTLD sont telles que stipulées dans l'Article VI, Section 5 de ces Règlements. Aux fins de cet article, les gestionnaires de ccTLD dans une région géographique membres de la ccNSO sont désignés comme étant des membres de la ccNSO « appartenant à » la région géographique, quel que soit l'emplacement physique du gestionnaire de ccTLD. Dans le cas où la région géographique d'un membre de la ccNSO n'est pas clairement définie, le membre ccTLD devrait lui-même choisir, conformément aux procédures adoptées par le conseil de la ccNSO.
5. Chaque gestionnaire de ccTLD peut désigner par écrit une personne, une organisation ou une entité chargée de représenter le gestionnaire de ccTLD. En l'absence d'une telle désignation, le gestionnaire de ccTLD est représenté par la personne, l'organisation ou l'entité répertoriée comme contact administratif dans la base de données de l'IANA.
6. Une assemblée annuelle des membres de la ccNSO est tenue et coordonnée par le conseil de la ccNSO. Les assemblées annuelles devraient être ouvertes à tous, et les gestionnaires de ccTLD qui ne sont pas membres de la ccNSO ainsi que tous les autres non-membres de la ccNSO doivent également avoir la possibilité de participer à la réunion. Les assemblées annuelles des membres de la ccNSO sont, si possible, tenues en personne et devraient avoir lieu conjointement avec des réunions du Conseil d'administration, ou d'une ou de plusieurs autres organisations de soutien de l'ICANN.
7. Les membres du conseil de la ccNSO sélectionnés par les membres de la ccNSO de chaque région géographique (voir la Section 3(1)(a) de cet Article) sont sélectionnés sur désignation et, si nécessaire, sur élection, par les membres du conseil de la ccNSO appartenant à cette région géographique. Au minimum 90 jours avant la fin du mandat régulier de tout membre sélectionné de la ccNSO au conseil de la ccNSO, ou dans le cas d'un siège vacant de membre du conseil de la ccNSO, le conseil de la ccNSO établit un programme de mise en candidature et d'élections qui est envoyé à tous les membres de la ccNSO appartenant à la région géographique et publié sur le site Web.
8. Tout membre de la ccNSO peut poser la candidature d'une personne donnée à la fonction de membre du conseil de la ccNSO représentant la région géographique du membre de la ccNSO. Les candidatures doivent être appuyées par un autre membre de la ccNSO provenant de la même région géographique. En acceptant leur nomination, les personnes nommées au conseil de la ccNSO acceptent de soutenir les politiques engagées par les membres de la ccNSO.
9. Si à la fin des mises en candidature, il y a autant de candidats nommés (bénéficiant d'appuis et d'acceptations) dans une région géographique particulière que de sièges disponibles au conseil de la ccNSO pour cette région géographique, les candidats nommés sont alors sélectionnés pour exercer leurs fonctions au conseil de la ccNSO. Dans le cas contraire, une élection par scrutin (qui peut se faire par courrier électronique) est organisée pour sélectionner les membres du conseil de la ccNSO parmi les candidats nommés (bénéficiant d'appuis et d'acceptations), les membres de la ccNSO de la région géographique étant habilités à voter par le biais de leurs représentants désignés. Lors d'une telle élection, une majorité de tous les membres de la ccNSO dans la région géographique habilités à voter constitue un quorum, et le candidat sélectionné doit obtenir la majorité des votes des membres de la ccNSO appartenant à la région géographique. Le président du conseil de la ccNSO remet rapidement au secrétaire de l'ICANN, un avis écrit comprenant la sélection des membres du conseil de la ccNSO en accord avec ce paragraphe.
10. Sous réserve de la clause 4(11), les politiques de l'ICANN s'appliquent aux membres de la ccNSO, en vertu de leur adhésion, dans la mesure où, et uniquement dans la mesure où, les politiques (a) traitent uniquement des questions se trouvant bien dans le champ d'activités de la ccNSO, conformément à l'article IX, section 6 et annexe C, et (b) ont été élaborées par le biais d'un ccPDP, comme décrit dans la Section 6 de cet Article, et (c) ont été recommandées comme telles par le ccNSO au Conseil d'administration, et (d) sont adoptées par le Conseil d'administration comme politiques, à condition qu'elles n'entrent pas en conflit avec la loi applicable au gestionnaire de ccTLD qui prévaut à tout moment. En outre, de telles politiques sont applicables à l'ICANN dans les activités ayant trait aux ccTLD.
11. Un membre de la ccNSO n'est pas tenu par une politique s'il fournit une déclaration au conseil de la ccNSO déclarant (a) qu'une mise en place de la politique le contraindrait à enfreindre la coutume, la religion ou la politique publique (non incorporée dans la loi en vigueur indiquée dans le paragraphe 10 de cette Section), et (b) que la non mise en place de la politique n'affecterait pas les opérations ou l'interopérabilité du DNS, en donnant des raisons détaillées renforçant ses arguments. Après enquête, le conseil de la ccNSO fournira une réponse à la déclaration du membre de la ccNSO. En cas de consensus du conseil de la ccNSO désapprouvant la déclaration, qui peut être établi par le vote de 14 membres ou plus du conseil de la ccNSO, la réponse doit exprimer le désaccord du conseil de la ccNSO avec la déclaration ainsi que les motifs de ce désaccord. Dans le cas contraire, la réponse doit exprimer l'accord du conseil de la ccNSO avec cette déclaration. Si le conseil de la ccNSO désapprouve, il doit réviser la situation après une période de six mois. A la fin de cette période, le conseil de la ccNSO doit conclure (a) si oui ou non la mise en place de la politique contraindrait le membre à enfreindre la coutume, la religion ou la politique publique (non incorporée dans la loi en vigueur indiquée dans le paragraphe 10 de cette Section), et (b), si oui ou non la non mise en place de la politique affecterait les opérations ou l'interopérabilité DNS. Pour toutes conclusions désapprouvant la déclaration, le conseil de la ccNSO doit procéder par consensus, qui peut être établi par le vote de 14 membres ou plus du conseil de la ccNSO.
Section 5. ORGANISATIONS RÉGIONALES
Le conseil de la ccNSO peut désigner une organisation régionale pour chaque région géographique de l'ICANN, à condition que l'organisation régionale soit ouverte à toute adhésion de l'ensemble des membres de la ccNSO appartenant à la région géographique. Les décisions visant la désignation ou de suppression de désignation d'une organisation régionale requièrent 66% des votes de l'ensemble des membres du conseil de la ccNSO et font 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 LA CCNSO ET CHAMP D'ACTION
1. L'étendue du rôle de la ccNSO dans l'élaboration des politiques est celle indiquée dans l'Annexe C de ces Règlements ; toute modification du champ d'action est recommandée au Conseil d'administration par le ccNSO au moyen des procédures du ccPDP, et soumise à l'approbation du Conseil d'administration.
2. En développant des politiques mondiales dans le cadre du champ d'action de la ccNSO et en les recommandant au Conseil d‘administration, le ccNSO suit le processus d'élaboration des politiques de la ccNSO (ccPDP). Le ccPDP est tel qu'indiqué dans l'Annexe B de ces Règlements ; toutes modifications sont recommandées au Conseil d'administration par le ccNSO au moyen des procédures du ccPDP, et sont soumises à l'approbation du Conseil d'administration.
Section 7. SOUTIEN EN PERSONNEL ET FINANCEMENT
1. A la demande du conseil de la ccNSO, un membre du personnel de l'ICANN peut être désigné pour assister le ccNSO et est désigné comme chef du personnel de l'ICANN. Le conseil de la ccNSO peut également désigner, aux frais de la ccNSO, une autre personne pour exercer la fonction de chef du personnel de la ccNSO. Le travail du chef du personnel de la ccNSO sur des questions essentielles est confié par le président du conseil de la ccNSO, et peut inclure les fonctions de gestionnaire de problématique de ccPDP.
2. A la demande du conseil de la ccNSO, l'ICANN fournit le soutien administratif et opérationnel nécessaire au ccNSO pour l'exercice de ses responsabilités. Un tel soutien ne comprend pas l'obligation de la part de l'ICANN de financer les frais de déplacement engagés par les participants de la ccNSO pour se rendre à toute réunion de la ccNSO ou pour toute autre raison. Le conseil de la ccNSO peut prévoir, aux frais de la ccNSO, un soutien administratif et opérationnel en plus de ou comme alternative au soutien fourni par l'ICANN.
3. Le conseil de la ccNSO établit les cotisations que les membres de la ccNSO devront payer pour couvrir les dépenses de la ccNSO, comme décrit aux paragraphes 1 et 2 de cette Section et approuvé par les membres de la ccNSO.
4. Les avis remis au secrétaire de l'ICANN, conformément à cet article, sont conservés de manière permanente, et mis à disposition, sur demande, pour être révisés par le conseil de la ccNSO. Le secrétaire de l'ICANN dresse également la liste des membres de la ccNSO, qui comprend le nom de chaque représentant désigné de gestionnaire de ccTLD et est publiée sur le site Web.
ARTICLE X : ORGANISATION DE SOUTIEN AUX POLITIQUES DES NOMS GÉNÉRIQUES
Il doit exister un organe de développement des politiques, appelé GNSO (Organisation de soutien aux politiques 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 se compose de :
(i) Un nombre de regroupements, selon le cas, organisé au sein des groupes des parties prenantes tel que décrit dans la Section 5 de cet Article ;
(ii) Quatre groups des parties prenantes organisés au sein des chambres tel que décrit dans Section 5 de cet Article ;
(iii) Trois chambres au sein du Conseil du GNSO tel que décrit dans la Section 3 de cet Article ; et
(iv) un conseil du GNSO responsable de gérer le processus de développement de politiques du GNSO, tel que décrit dans la Section 3 de cet Article.
Sauf disposition contraire de ces Statuts, les quatre groupes des parties prenantes et les regroupements seront responsables de définir leurs propres chartes avec l'approbation de leurs membres ainsi que celle du Conseil d'administration de l'ICANN.
1. Sous réserve des dispositions de Article de transition XX, Section 5 de ces Règlements et tel que décrit dans Section 5 de l'Article X, le conseil du GNSO se compose de :
a. trois représentants sélectionnés au sein du groupe multipartite des registres ;
b. six représentants sélectionnés au sein groupe multipartite des bureaux d'enregistrement ;
c. six représentants sélectionnés au sein du groupe des parties prenantes commerciales ;
d. six représentants sélectionnés au sein du groupe des parties prenantes non commerciales ;
e. trois représentants sélectionnés par le comité de nomination de l'ICANN ; l'un deux n'aura pas droit de vote mais il sera autorisé à participer sur un pied d'égalité avec les membres du conseil du GNSO y compris, par exemple, la réalisation et l'appui des motions et agir en tant que président s'il était élu. Un représentant nommé par le comité de nomination avec droit de vote sera assigné à chaque Chambre (tel que décrit dans Section 3(8) de cet Article par le comité de nomination.
Aucun représentant individuel ne pourra occuper plus d'un siège au conseil du GNSO en même temps.
Dans leurs chartes, les groupes des parties prenantes devraient assurer une représentation aussi diverse que possible au sein du conseil du GNSO, y compris la diversité géographique, le regroupement du GNSO, le secteur, les compétences et le sexe.
Le conseil du GNSO peut également comprendre deux agents de liaison, nommés un par le comité consultatif gouvernemental et un par le comité consultatif At-Large de temps à autre. L'organisation chargée de la nomination peut désigner, révoquer ou modifier son agent de liaison avec le Conseil du GNSO, en remettant une note écrite au président du Conseil du GNSO et au secrétaire de l'ICANN. Ces agents de liaison ne sont pas membres ou habilités à voter au conseil du GNSO, mais sont autrement habilités à participer sur un pied d'égalité avec les membres du conseil du GNSO.
2. Sous réserve des dispositions de l'Article de transition XX, et Section 5 de ces Règlements, le mandat régulier de chaque membre du Conseil du GNSO doit débuter à 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. Le mandat régulier de deux représentants sélectionnés par chaque groupe des parties prenantes avec trois sièges au Conseil doit débuter au cours d'une année paire et celui des autres représentants sélectionnés dans ce groupe des parties prenantes doit débuter au cours d'une année impaire. Le mandat régulier de trois représentants sélectionnés par chaque groupe des parties prenantes avec six sièges au Conseil doit débuter au cours d'une année paire et celui des autres représentants sélectionnés dans ce groupe des parties prenantes doit débuter au cours d'une année impaire. Le mandat régulier d'un des trois membres sélectionnés par le Comité de nomination doit débuter au cours d'une année paire et celui des deux autres représentants sélectionnés doit débuter au cours d'une année impaire. Chaque membre du conseil du GNSO se doit d'exercer ses fonctions tout au long de son mandat régulier jusqu'à la nomination et la prise de fonction d'un successeur, à moins qu'il ne démissionne ou ne soit révoqué, conformément aux statuts en vigueur.
Sauf dans des « circonstances spéciales » telles que, sans limitation, la satisfaction d'exigences géographiques ou autres exigences de diversité définies dans les chartes des groupes de parties prenantes, lorsque nul autre représentant alternatif n'est disponible pour cette fonction, nul membre du conseil ne peut être sélectionné pour remplir plus de deux mandats consécutifs. Dans de telles circonstances spéciales, un membre du conseil peut remplir un mandat supplémentaire. 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. Un ancien membre du Conseil ayant servi pendant deux mandats consécutifs doit attendre qu'un mandat entier se soit écoulé après la fin de son mandat avant de pouvoir être réélu comme membre du Conseil. Une « circonstance spéciale » est définie dans les Procédures de fonctionnement du GNSO.
3. Un poste vacant au conseil du GNSO est réputé exister en cas de décès, de démission ou de révocation de tout membre. Les postes vacants sont pourvus par le comité de nomination pour la durée restante du mandat, sur avis de sélection remis au secrétaire de l'ICANN, à moins que le membre exerçant cette fonction avant que le poste ne soit vacant, n'ait été sélectionné par un regroupement, auquel cas le regroupement doit pourvoir le poste pour la durée restante du mandat en remettant son avis de sélection au secrétaire de l'ICANN. Les procédures pour remplir les postes vacants du groupe des parties prenantes, les démissions et les révocations sont établies dans la Charte du groupe des parties prenantes en vigueur.
Un membre du conseil du GNSO sélectionné par le comité de nomination peut être révoqué par une raison motivée : i) établie par les trios quarts (3/4) des votes de tous les membres de la chambre à laquelle le membre du comité de nomination est affecté ; ou établie par les trois quarts (3/4) des votes de tous les membres de chaque chambre dans le cas d'un membre sans droit de vote du comité de nomination (voir Section 3(8) de cet Article). Le conseil de l''ICANN décidera l'annulation de cette révocation si le membre affecté du conseil du GNSO présentait un appel.
4. Le conseil du GNSO est le responsable de gérer le processus de développement de politiques du GNSO. Il adoptera ces procédures (les « procédures de fonctionnement du GNSO ») s'il évalue qu'il doit répondre à cette responsabilité, pourvu que ces procédures soient approuvées par le vote majoritaire de chaque chambre. Les procédures de fonctionnement du GNSO deviendront effectives dès l'expiration de la période de commentaires publics de vingt-et-un (21) jours et le Conseil sera le responsable de leur surveillance et révision. Jusqu'à ce que le conseil du GNSO recommande des modifications, les procédures applicables seront établies à Section 6 de cet Article.
5. Au maximum un cadre, directeur ou employé d'une société en particulier ou d'une autre organisation (y compris les filiales et les affiliés) aura un mandat au sein du conseil du GNSO à un moment donné.
6. Le GNSO procèdera aux sélections pour pourvoir les sièges 13 et 14 du Conseil de l'ICANN par scrutin ou par mesure prise lors d'une réunion. Chacune des deux chambres du GNSO, tel que décrit dans la Section 3(8) de cet Article, feront une sélection pour remplir un des deux sièges du Conseil de l'ICANN, tel que décrit ci-dessus ; cette sélection devra avoir les votes affirmatifs de soixante pour cent (60 %) des membres respectifs de la chambre ayant droit de vote.
a. la chambre pour les parties contractées fera la sélection du représentant pour le siège 13 ; et
b. la chambre pour les parties non contractées fera la sélection du représentant pour le siège 14.
Les procédures d'élection sont définies dans les Procédures de fonctionnement du GNSO.
La notification des sélections des sièges du conseil sera faite 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 choisira le président du GNSO pour une durée établie par le conseil du GNSO ne dépassant pas un an. Chaque chambre (tel que décrit dans la Section 3.8 de cet Article) fera la sélection du vice-président, qui sera le vice-président de la totalité du conseil du GNSO, pour une durée établie par le conseil du GNSO ne dépassant pas un an. Les procédures pour sélectionner le président ou tout autre cadre sont incluses dans les procédures de fonctionnement du GNSO. Si le conseil du GNSO n'avait pas élu le président du GNSO avant la fin de la période de présidence précédente, les vice-présidents joueront le rôle de co-présidents intérims du GNSO jusqu'à ce que l'élection soit réalisée.
8. Sauf dispositions contraires des présents Statuts, à des fins de vote, le conseil du GNSO (voir la Section 3(1) de cet Article) sera organisé dans une structure de chambre bicamérale tel que décrit ci-dessous :
a. la chambre des parties contractées inclut le groupe multipartite des registres (trois membres), le groupe multipartite des bureaux d'enregistrement (trois membres), et un membre avec droit de vote nommé par le comité de nomination de l'ICANN, à savoir un total de sept membres avec droit de vote ; et
b. la chambre des parties non contractées inclut le groupe multipartite des registres (six membres), le groupe multipartite des bureaux d'enregistrement (six membres), et un membre avec droit de vote nommé par le comité de nomination de l'ICANN pour cette chambre pour un total de treize membres avec droit de vote.
Sauf dispositions contraires des présents statuts, chaque membre d'une chambre élective aura le droit d'émettre un vote sur chaque question séparée avant le conseil du GNSO.
9. Sauf dispositions contraires des présents statuts, Annexe A, ou dans les procédures de fonctionnement du GNSO, le seuil par défaut pour passer une motion du conseil du GNSO ou d'autres actions de vote sera la majorité simple des votes pour chaque chambre. Les seuils de vote décrits ci-dessous seront applicables aux actions du GNSO suivantes :
a. Créer un rapport : exige le vote affirmatif de plus de 25 % des votes de chaque chambre ou la majorité d'une chambre ;
b. Lancer un processus de développement des politiques (« PDP ») relevant de sa compétence (tel que décrit à l'Annexe A : exige le vote affirmatif de plus de 33% des votes de chaque chambre ou plus de 66 % d'une chambre ;
c. Lancer un PDP ne relevant pas de sa compétence : exige le vote affirmatif de plus de 75% des votes de chaque chambre et la majorité de l'autre chambre (« vote à la majorité absolue du GNSO ») ;
d. Approuver une recommandation PDP sans le vote à la majorité absolue du GNSO : exige le vote affirmatif de la majorité de chaque chambre et par la suite exige qu'un membre du conseil du GNSO d'au mois 3 des 4 groupes des parties prenantes soutienne la recommandation ;
e. Approuver une recommandation PDP avec le vote à la majorité absolue du GNSO : exige un vote affirmatif du vote à la majorité absolue du GNSO ; et
f. Approuver la recommandation PDP imposant de nouvelles obligations à certaines des parties contractantes : si une disposition du contrat de l'ICANN établit que « le vote des deux tiers du conseil » montre l'existence d'un consensus, le seuil de vote à la majorité qualifiée du GNSO devra être atteint ou dépassé par toute partie contractante soumise à cette disposition du contrat.
Section 4. SOUTIEN EN PERSONNEL ET FINANCEMENT
1. Un membre du personnel de l'ICANN est désigné pour assister le GNSO. Son travail ayant trait à des questions essentielles est confié par le président du conseil du GNSO, et il est désigné comme chef du personnel du GNSO (chef du personnel).
2. L'ICANN fournit le soutien administratif et opérationnel nécessaire au GNSO pour l'exécution de ses responsabilités. Un tel soutien ne comprend pas d'obligation de la part de l'ICANN de 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. À sa discrétion, l'ICANN pourra financer les frais de déplacement des participants du GNSO sous toute procédure d'aide au transport ou des directives pouvant être adoptées de temps en temps.
1. Les groupes de parties prenantes suivants sont reconnus comme représentant un groupe spécifique d'un regroupement ou plus ou de groupes d'intérêt, sous réserve des dispositions de l'Article de transition XX, Section 5 de ces Règlements :
a. registres de gTLD (représentant tous les registres de gTLD sous contrat avec l'ICANN) ;
b. groupe multipartite des bureaux d'enregistrement représentant tous les registraires accrédités par, et sous contrat avec l'ICANN ;
c. Le groupe des parties prenantes commerciales représentant la gamme complète des petites et grandes entités de l'Internet ; et
d. Le groupe des parties prenantes non commerciales représentant la gamme complète des petites et grandes entités de l'Internet.
2. Un nombre de sièges spécifiques est alloué à chaque groupe des parties prenantes au sein du Conseil, conformément à la Section 3(1) de cet Article.
3. Chaque groupe des parties prenantes identifié dans paragraphe 1 de cette Section et chacun de ses regroupements associés, le cas échéant, maintiendront la reconnaissance avec le conseil de l'ICANN. La reconnaissance est garantie par le Conseil sur la base que, en fait, l'entité représente les intérêts mondiaux des communautés multipartites qu'elle prétend représenter et fonctionne dans la mesure du possible de manière ouverte et transparente, cohérente avec les procédures visant à assurer l'équité. Le groupe des parties prenantes et les chartes des regroupements seront révisées régulièrement tel que prévu par le Conseil d'administration.
4. Tout groupe d'individus ou d'entités peut adresser une demande au Conseil d'administration pour la reconnaissance d'un regroupement nouveau ou distinct. Toute demande de la sorte contient une explication détaillée de :
a. la raison pour laquelle l'ajout d'un tel regroupement améliorera la capacité du GNSO à exécuter ses responsabilités d'élaboration de politiques ; et
b. la raison pour laquelle le nouveau regroupement proposé représenterait de manière adéquate, sur une échelle mondiale, les parties prenantes qu'il cherche à représenter.
c. une recommandation pour le classement opérationnel dans un groupe multipartite donné ; et
d. une charte proposée conforme aux principes et aux procédures contenus dans ces Statuts.
Toute demande de reconnaissance d'un nouveau regroupement est publiée pour être commentée publiquement.
5. Le Conseil d'administration peut créer de nouveaux regroupements, tels qu'ils sont définis dans la Section 5(3) , en réponse à une telle demande, ou de son propre chef, s'il estime qu'une telle action pourrait servir les besoins de l'ICANN. Dans le cas où le Conseil d'administration envisage d'agir de sa propre motion, il publie une explication détaillée des raisons rendant cette action nécessaire ou souhaitable, il définit une date raisonnable pour la sollicitation de commentaires publics, et ne prend pas de décision finale concernant la création ou non d'un tel regroupement avant d'avoir examiné tous les commentaires reçus. Dès lors que le Conseil d'administration publie une demande pétition ou recommandation concernant la création d'un nouveau regroupement pour consultation publique, il en avertit le conseil du GNSO et considère toute réponse à cet avis avant de prendre une quelconque mesure.
Section 6. PROCESSUS D'ÉLABORATION DES POLITIQUES
Les procédures d'élaboration des politiques que le GNSO doit suivre sont telles que mentionnées dans l'Annexe A de ces Statuts. Ces procédures peuvent être complétées ou révisées de la manière définie dans 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 indiqués dans cet article. Les membres du comité consultatif peuvent être des administrateurs uniquement, des administrateurs et des non administrateurs, ou des non administrateurs seulement, ou encore des membres suppléants ou sans droit de vote. Les comités consultatifs n'ont pas d'autorité légale pour agir au nom de l'ICANN, mais rendent compte de leurs conclusions et recommandations au Conseil d'administration.
Section 2. COMITÉS CONSULTATIFS SPÉCIFIQUES
Les comités consultatifs suivants sont établis au minimum :
1. Comité consultatif gouvernemental
a. Le comité consultatif gouvernemental étudie et donne des conseils sur les activités de l'ICANN 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 accords internationaux ou susceptibles d'affecter des enjeux de réglementation publique.
b. L'adhésion au comité consultatif gouvernemental est ouverte à tous les gouvernements nationaux. L'adhésion est également ouverte aux économies distinctes, reconnues dans les instances internationales, ainsi qu'aux organisations gouvernementales multinationales et établies par traité, sur invitation du comité consultatif gouvernemental par le biais de son président.
c. Le comité Consultatif gouvernemental peut adopter sa propre charte ainsi que des principes de fonctionnement ou des procédures internes pour guider ses activités. Ceux-ci 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 ces membres.
e. Chaque membre du comité consultatif gouvernemental nomme un représentant accrédité au comité. Le représentant accrédité d'un membre doit exercer une fonction officielle formelle auprès de l'administration publique de ce membre. Le terme « officiel » comprend une personne qui a été élue à une charge gouvernementale, ou qui est employée par un tel gouvernement, autorité publique, ou organisation gouvernementale multinationale ou établie par traité, et dont la fonction première auprès de ce gouvernement, de cette autorité publique ou de cette organisation consiste à élaborer ou influencer les politiques gouvernementales ou publiques.
f. Chaque année, le comité consultatif gouvernemental nomme 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 organisations de soutien et comités consultatifs, dans la mesure où le comité consultatif gouvernemental le juge approprié et utile.
h. Le Conseil d'administration informe le président du comité consultatif gouvernemental, dans les plus brefs délais, de toute proposition soulevant des problèmes de politique publique pour laquelle le Conseil d'administration ou toute autre organisation de soutien de l'ICANN ou comité de nomination, cherche à obtenir des commentaires du public. Le Conseil d'administration prend, par ailleurs, dûment en considération toute réponse opportune à cet avis avant de prendre une quelconque mesure.
i. Le comité consultatif gouvernemental peut directement proposer au Conseil d‘administration des questions à traiter, soit en commentant ou conseillant au préalable, soit en recommandant de manière spécifique une nouvelle mesure ou l'élaboration d'une nouvelle politique ou la révision de politiques existantes.
j. Les conseils du comité consultatif gouvernemental au sujet des questions de politique publique sont dûment pris en considération, autant dans la formulation que dans l'adoption de politiques. Si le Conseil de l'ICANN décide d'agir contrairement à l'avis du GAC, il doit en avertir ce dernier, en précisant les raisons pour lesquelles il n'a pas respecté cet avis. Le GAC et le Conseil de l'ICANN devront alors s'efforcer de trouver une solution efficace et bénéfique pour les deux parties, en toute bonne foi et avec diligence.
k. Si une telle solution s'avère impossible à trouver, le Conseil d'administration de l'ICANN indiquera dans sa décision finale les raisons pour lesquelles les conseils du comité consultatif gouvernemental n'ont pas été suivis, et une telle déclaration ne portera pas préjudice aux droits et obligations des membres du comité consultatif gouvernemental concernant les problèmes de politique publique dont ils sont responsables.
2. Comité consultatif pour la sécurité et la stabilité
a. Le rôle du comité consultatif pour la sécurité et la stabilité (« SSAC ») 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'attribution d'adresses Internet. Il est chargé :
1. de communiquer à propos de questions de sécurité avec la communauté technique d'Internet ainsi que les opérateurs et gestionnaires des services d'infrastructures DNS critiques, d'inclure la communauté des opérateurs de serveurs de noms racine, les registres et les bureaux d'enregistrement de noms de domaine de premier niveau, 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é rassemble et énonce les exigences à proposer aux parties impliquées dans la révision technique des protocoles liés au DNS et à l'attribution d'adresses et celles impliquées dans la planification opérationnelle.
2. de conduire une évaluation continue des menaces et une analyse des risques pour les systèmes de nommage et d'attribution d'adresses Internet pour localiser les principales menaces à la stabilité et à la sécurité, et conseiller la communauté de l'ICANN en conséquence. Le comité recommande toute activité d'audit nécessaire pour évaluer l'état actuel du DNS et traiter la sécurité de l'attribution d'adresses par rapport aux risques et menaces identifiés.
3. de communiquer avec ceux ayant des responsabilités directes dans les questions de sécurité du nommage et des attributions d'adresses Internet (IETF, RSSAC, RIR, registres de noms, etc.), de s'assurer que ses conseils sur les risques pour la sécurité, les problèmes et les priorités sont correctement harmonisés avec les activités de normalisation, de déploiement, de fonctionnement et de coordination existantes. Le comité surveille ces activités et informe, selon les besoins, la communauté de l'ICANN et le Conseil d'administration de leur évolution.
4. de rendre compte de ses activités au Conseil d'administration de manière périodique.
5. de formuler des recommandations de politiques à la communauté de l'ICANN et au Conseil d'administration.
b. Le président et les membres du SSAC seront nommés par le Conseil d'administration. La nomination pour l'adhésion au SSAC sera pour une période de trois ans, qui commencera le 1ier janvier d'une année déterminée et finira le 31 décembre de la troisième année. Le président et les membres pourront être renommés et il n'y a pas de limite au nombre de périodes pendant lesquelles le président ou les membres pourront exercer leurs fonctions. Le président du SSAC peut faire des recommandations au Conseil d'administration concernant les nominations pour le SSAC. Le président du SSAC échelonnera les recommandations pour les nominations de telle manière qu'un tiers (1/3) environ des adhérents du SSAC soit considéré pour la nomination ou pour une nouvelle nomination chaque année. Le Conseil d'administration aura aussi la faculté de révoquer les personnes nommées par le SSAC, suivant les recommandations du SSAC ou au moyen d'une consultation avec celui-ci. (Remarque : Le premier mandat complet en vertu de ce paragraphe commencera le 1ier janvier 2011 et se terminera le 31 décembre 2013. Avant le 1ier janvier 2011, le SSAC sera composé tel que défini dans les Règlements suivant les modifications du 25 juin 2010, et le président du SSAC recommandera la nouvelle nomination de tous les membres actuels du SSAC pour des périodes complètes ou partielles, pour se conformer aux dispositions du présent paragraphe.
c. Chaque année, le SSAC nomme 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 sur le système de serveurs racine
a. Le rôle du comité consultatif du système de serveurs racine (« RSSAC ») est de conseiller le Conseil d'administration sur le fonctionnement des serveurs de noms racine du système de noms de domaine. Le RSSAC examine et donne des conseils à propos des exigences opérationnelles des serveurs de noms racine, y compris des capacités du matériel informatique hôte, des versions de système d'exploitation et de logiciels de serveurs de noms, ainsi qu'au sujet du réseau de connectivité et de l'environnement physique. Le RSSAC examine et donne des conseils au sujet des aspects concernant la sécurité du système de serveurs de noms racine. De plus, le RSSAC passe en revue le nombre, l'emplacement et la répartition des serveurs de noms racine en prenant en considération la performance, la robustesse et la fiabilité de l'ensemble du système.
b. Les membres du RSSAC sont (i) chaque opérateur d'un serveur de noms racine de référence (tel que répertorié sur <ftp://ftp.internic.net/domain/named.root>), 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 racine du DNS est nommé par le Conseil d'administration ; les présidents suivants sont élus par les membres du comité consultatif du système des serveurs racine du DNS, conformément aux procédures adoptées par les membres.
d. Chaque année, le comité consultatif du système des serveurs racine nomme 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 des utilisateurs d'Internet (ALAC)
a. Le Comité consultatif At-Large (ALAC) est l'organisation d'accueil principale au sein de l'ICANN pour les utilisateurs individuels d'Internet. a. Le rôle de l'ALAC consiste à étudier et fournir des conseils sur les activités de l'ICANN, dans la mesure où les intérêts des utilisateurs d'Internet sont concernés. Ceci comprend des politiques définies par l'intermédiaire des organisations de soutien de l'ICANN, aussi bien que beaucoup d'autres questions pour lesquelles sont nécessaires les commentaires et les conseils de la communauté. L'ALAC, qui joue un rôle important dans les mécanismes de responsabilité de l'ICANN, coordonne aussi quelques actions de sensibilisation de l'ICANN adressées aux utilisateurs d'Internet.
b. L'ALAC se compose de (a) deux membres sélectionnés par chacune des organisations régionales At-Large (« RALO »), établies selon 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 inclure un citoyen d'un pays appartenant à chacune des cinq régions géographiques établies selon la Section 5 de l'Article VI.
c. Sous réserve des dispositions de l'Article de transition de ces Règlements, les mandats réguliers des membres de l'ALAC devront respecter les points suivants :
1. le mandat d'un membre sélectionné par chacune des RALO commence à la clôture d'une assemblée annuelle de l'ICANN au cours d'une année paire.
2. le mandat de l'autre membre sélectionné par chacune des RALO commence à la clôture d'une assemblée 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 commencent à la clôture d'une assemblée 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 assemblée annuelle au cours d'une année paire.
4. Le mandat régulier de chaque membre prend fin à la clôture de la seconde assemblée annuelle de l'ICANN suivant le début dudit mandat.
d. Le président de l'ALAC est élu par les membres de l'ALAC conformément aux procédures adoptées par le comité.
e. Après consultation avec chaque RALO, l'ALAC devra nommer chaque année cinq délégués ayant droit de vote pour le comité de nomination ; il faudra éviter que deux de ces délégués soient des ressortissants de pays de la même région géographique, suivant ce qui est établi à la Section 5 de l'Article VI.
f. Sous réserve des dispositions de l'Article de transition de ces Règlements, l'ALAC peut nommer des agents de liaison sans droit de vote au conseil de la ccNSO et au Conseil du GNSO.
g. Une RALO est établie pour chaque région géographique conformément à la Section 5 de l'Article VI. Chaque RALO constitue le principal forum et point de coordination pour la contribution du public à l'ICANN dans sa région géographique correspondante et doit être une organisation à 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 du comité consultatif At-Large. Une organisation devient la RALO reconnue pour sa région géographique à la signature d'un protocole d'entente avec l'ICANN, qui définit les rôles et les responsabilités respectives de l'ICANN et de la RALO en ce qui concerne le processus de sélection des membres de l'ALAC et les exigences d'ouverture, les opportunités de participation, la transparence, la responsabilité et la diversité au sein de la structure de la RALO, les procédures ainsi que les critères et les normes régissant les structures At-Large constituant la RALO.
h. Chaque RALO se compose de structures At-Large indépendantes situées dans sa région géographique et qui ont été certifiées conformes aux exigences du protocole d'entente entre la RALO et l'ICANN, selon le paragraphe 4(i) de cette Section. Si cela est stipulé dans le protocole d'entente avec l'ICANN, une RALO peut également inclure des utilisateurs individuels d'Internet qui sont citoyens ou résidents de pays appartenant à la région géographique de la RALO.
i. Adhésion à la communauté At-Large
- Les critères et normes d'accréditation des structures At-Large au sein de chaque région géographique sont établis par le Conseil d'administration en fonction des recommandations de l'ALAC et sont stipulés dans le protocole d'entente entre l'ICANN et la RALO pour chaque région géographique.
- Les critères et normes d'accréditation des structures At-Large sont établis de façon à ce que la participation d'utilisateurs individuels d'Internet citoyens ou résidents de pays appartenant à la région géographique (suivant la définition de la Section 5 de l'Article VI) de la RALO prédomine dans le fonctionnement de chaque structure At-Large au sein de la RALO, sans nécessairement exclure la participation supplémentaire d'autres citoyens, compatible avec les intérêts des utilisateurs individuels d'Internet de la région.
- Chaque protocole d'entente de la RALO inclut également des dispositions conçues pour permettre, dans la mesure du possible, à chaque utilisateur individuel d'Internet citoyen d'un pays appartenant à la région géographique de la RALO de participer dans au moins une des structures At-Large de la RALO.
- Dans la mesure où ils restent conformes à ces objectifs, les critères et les normes permettent également à chaque RALO d'adopter le type de structure qui correspond le mieux aux coutumes et au caractère de sa région géographique.
- Une fois les critères et les normes établis tel que stipulé dans cette clause i, l'ALAC, avec les conseils et la participation de la RALO de la région où le candidat est basé, est responsable de l'accréditation des organisations selon les critères et les normes d'accréditation d'une structure At-Large.
- Les décisions relatives à l'accréditation ou à la révocation de l'accréditation d'une structure At-Large sont prises selon les modalités décidées par l'ALAC dans ses règles de procédure, sous réserve que toutes modifications apportées à ces règles de procédure en matière de candidatures de structures At-Large fassent l'objet d'une révision de la part des RALO et du Conseil d'administration de l'ICANN.
- Les décisions portant sur l'accréditation, la non accréditation ou la révocation de l'accréditation d'une structure At-Large font l'objet d'une révision selon les procédures établies par le Conseil d'administration.
- Sur une base permanente, l'ALAC peut également donner des conseils à propos de la satisfaction des critères et des normes applicables de la part d'une structure At-Large candidate.
j. L'ALAC est également responsable, en collaboration avec les RALO, de la coordination des activités suivantes :
1. La sélection faite par la communauté At-Large pour pourvoir le siège 15 du Conseil d'administration. La notification de la sélection de la communauté At-Large, sera faite par écrit par le président de l'ALAC au secrétaire de l'ICANN, conformément à l'article VI, Sections 8(4) and 12(1).
2. La communication à la communauté des utilisateurs individuels d'Internet des informations importantes de l'ICANN ;
3. La diffusion (par e-mail 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 ;
4. La promotion d'activités de formation au sein de la communauté des utilisateurs individuels d'Internet ;
5. Le développement et mise à jour de programmes continus d'information et de formation, concernant l'ICANN et ses réalisations ;
6. La mise en place d'une stratégie de formation sur les sujets traités par l'ICANN dans chaque région de RALO ;
7. La participation aux processus d'élaboration de politiques de l'ICANN et les commentaires et les conseils qui reflètent avec précision les points de vue des utilisateurs d'Internet ;
8. La diffusion au public et l'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 ;
9. La fourniture de mécanismes basés sur Internet permettant les discussions entre les membres des organisations d'utilisateurs d'Internet ;
10. L'é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 sujets en suspens traités par l'ICANN.
Chaque comité consultatif détermine ses propres règles de procédure et exigences de quorum.
Le président et chaque membre d'un comité exercent leur mandat jusqu'à la nomination de leur successeur, ou jusqu'à la résiliation du comité, ou jusqu'à ce qu'il soit relevé de ses fonctions, démissionne ou ne soit plus habilité à être un membre du comité.
Les postes vacants au sein des comités sont pourvus de la même façon que prévue pour les nominations initiales.
Les membres du comité ne reçoivent pas de rémunération pour leurs services 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 l'exercice de leur fonction de membres d'un comité.
ARTICLE XI-A : AUTRES MÉCANISMES CONSULTATIFS
Section 1. CONSULTATION D'EXPERTS EXTERNES
1. Objectif. La consultation d'experts externes 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 pertinente existent, ou dans lesquels l'accès à une expertise privée pourrait s'avérer utile, le Conseil d'administration et ses organes constitutifs devraient être encouragés à solliciter les conseils de tels organes ou individus experts.
2. Types de panels d'experts consultatifs.
a. De sa propre initiative, ou suite à la suggestion d'un organe de l'ICANN, le Conseil d'administration peut nommer ou autoriser le président à nommer les panels d'experts consultatifs comportant des individus ou des entités du secteur public ou du secteur privé. Si les conseils sollicités de ces panels concernent des questions de politiques publiques, les dispositions de la Section 1(3)(b) de cet Article sont applicables.
b. En outre, conformément à la Section 1(3) de cet Article, le Conseil d'administration peut soumettre des questions de politique publique ayant trait à la mission de l'ICANN à une organisation gouvernementale multinationale ou à une organisation établie par traité.
3. Processus de consultation d'experts - questions de politique publique.
a. Le Comité consultatif gouvernemental peut à tout moment recommander que le Conseil d'administration demande conseil au sujet d'une ou plusieurs question(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'une expertise externe est nécessaire concernant une ou plusieurs question(s) de politique publique, le Conseil d'administration doit, selon les besoins, consulter le comité consultatif gouvernemental au sujet de la source convenable auprès de laquelle solliciter les conseils et les dispositions, y compris la définition du contenu et du processus, afin de demander et d'obtenir ces conseils.
c. Selon les besoins, le Conseil d'administration transmet toute demande de consultation d'une organisation gouvernementale multinationale ou d'une organisation établie par traité, incluant le cahier des charges, au comité consultatif gouvernemental, avec la suggestion que la demande soit transmise par le comité consultatif gouvernemental à l'organisation gouvernementale multinationale ou à l'organisation établie par traité.
4. Processus de consultation d'experts – autres questions. Toute consultation de la part du Conseil d'administration ou du président d'un panel consultatif d'experts pour des questions ne concernant pas la politique publique, conformément à la Section 1(2)(a) de cet Article sera effectuée conformément au cahier des charges décrivant les questions sur lesquelles des commentaires et des conseils sont sollicités ainsi que les procédures et les délais à respecter.
5. Réception des conseils d'experts et leurs effets. Les conseils externes associés à cette section sont 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, a l'opportunité de faire des commentaires sur tous conseils externes reçus avant la prise de toute décision par le Conseil d'administration.
Section 2. GROUPE DE LIAISON TECHNIQUE
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 qui sous-tendent les 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) connecte le Conseil d'administration aux sources convenables de conseils techniques au sujet des problèmes ayant rapport aux activités d'ICANN.
2. Organisations TLG. Le TLG comporte 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, Conseil pour l'organisation de l'Internet).
3. Rôle. Le rôle des organisations du TLG est de canaliser des informations et des conseils techniques vers le Conseil d'administration et les autres entités de l'ICANN. Ce rôle comporte à la fois une composante de réactivité et une composante 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 du TLG couvre les circonstances dans lesquelles l'ICANN recherche une réponse qui fait autorité à une question technique spécifique. Lorsque des informations concernant une norme technique particulière dont une organisation du TLG est responsable sont requises, cette demande est adressée à ladite organisation du 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 attirer l'attention sur les problèmes relatifs aux normes techniques mondiales touchant l'élaboration des politiques dans le cadre de la mission de l'ICANN. Cette composante du rôle du 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 devrait être posée.
4. Procédures du TLG. Le TLG n'a pas de cadres, ne tient pas de réunions et ne fournit pas de conseils sur les politiques au Conseil d'administration en tant que comité (même si les organisations du TLG peuvent se voir demander individuellement par le Conseil d'administration de le faire en tant que de besoin dans des domaines en rapport avec leurs chartes individuelles). Le TLG ne débat pas non plus ni n'a la charge de coordonner des questions techniques à travers ses organisations ; il n'établit ni n'essaie d'établir des positions unifiées ; il ne crée ni ne tente de créer des niveaux ou des structures supplémentaires dans le TLG pour l'élaboration de normes techniques ou pour tout autre propos.
5. Travail technique de l'IANA. Le TLG ne s'implique pas dans le travail de l'IANA pour le groupe de travail de l'ingénierie Internet, le groupe de travail de la recherche Internet, ou du conseil pour l'organisation de l'Internet, tel que décrit dans le protocole d'entente 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 TLG désigne deux experts techniques individuels familiarisés avec les problèmes de normes techniques ayant rapport aux activités de l'ICANN. Ces 8 experts sont disponibles en cas de besoin afin de déterminer, par le biais d'un échange de messages électroniques, où diriger une question technique de la part de l'ICANN lorsque l'ICANN ne la pose pas directement à une organisation spécifique du TLG.
7. Agent de liaison auprès du Conseil d'administration et délégué au comité de nomination. Chaque année, en rotation, une organisation du TLG nomme un agent de liaison sans droit de vote auprès du Conseil d'administration, conformément à l'Article VI, Section 9(1)(d). Chaque année, en rotation, une organisation du TLG choisit un délégué ayant droit de vote au 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 sans droit de vote est le suivant : ETSI, ITU-T puis W3C. L'ordre de rotation pour la sélection du délégué au Comité de nomination est le suivant : W3C, ETSI et ITU-T. (L'IAB ne prend pas part à ces rotations parce que l'IETF nomme par ailleurs un agent de liaison sans droite de vote auprès du Conseil d'administration et sélectionne un délégué au 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 se compose de deux administrateurs ou plus. Le Conseil d'administration peut désigner un ou plusieurs administrateur(s) en tant que membres suppléants de tout comité de ce genre, pouvant remplacer un membre absent lors des réunions du comité. Les membres d'un comité peuvent être révoqués à tout moment d'un comité sur vote de la majorité de deux tiers (2/3) de l'ensemble des membres du Conseil d'administration ; à 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 pour la majorité de deux tiers (2/3) requise ; et à 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 sauf par rapport :
a. aux postes vacants à pourvoir au sein du Conseil d'administration ou de tout comité ;
b. à la modification ou l'abrogation des règlements ou des statuts ou l'adoption de nouveaux règlements ou de nouveaux statuts ;
c. à la modification ou l'abrogation de toute résolution du Conseil d'administration qui, selon ses termes explicites, ne peut être modifiée ou 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, telle que définie dans la section 5233(a) du CNPBCL ;
f. à l'approbation du budget annuel requis par l'Article XVI ; ou
g. à la rémunération de tout membre de la direction décrite à l'Article XIII.
2. Le Conseil d'administration a le pouvoir de dicter la manière selon laquelle les procédures de chaque comité du Conseil d'administration doivent être conduites. En l'absence de toute prescription, un tel comité a le pouvoir de dicter la manière selon laquelle ses procédures doivent être conduites. Sauf disposition contraire de ces règlements, du Conseil d'administration ou dudit comité, les réunions régulières et extraordinaires sont régies par les dispositions de l'Article VI portant sur les réunions et les actions du Conseil d'administration. Chaque comité rédige des comptes-rendus de ses réunions et fournit des rapports occasionnels au Conseil d'administration lorsque celui-ci le demande.
Section 3. COMITÉS PROVISOIRES
Le Conseil d'administration peut selon ses besoins établir des comités provisoires, 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 DE LA DIRECTION
Section 1. CADRES DE DIRECTION
Les membres de la direction de l'ICANN sont un président (ayant le poste de président directeur général), un secrétaire et un directeur financier. L'ICANN peut également, à la discrétion du Conseil d'administration, avoir les membres supplémentaires qu'elle juge appropriés. Mis à part le président, toute personne peut remplir plus d'une fonction mais nul membre du Conseil d'administration (mis à part le président) ne peut simultanément être membre de la direction de l'ICANN.
Section 2. ÉLECTION DES CADRES DE DIRECTION
Les cadres de direction 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 cadres de direction conserve son poste jusqu'à sa démission, sa révocation, sa disqualification ou l'élection de son successeur.
Section 3. RÉVOCATION DES CADRES DE DIRECTION
Tout cadre de direction 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 toute autre raison, le Conseil d'administration peut déléguer les pouvoirs et les devoirs inhérents au poste à tout cadre de direction ou administrateur jusqu'à ce qu'un successeur soit élu au poste de direction.
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 de la direction et du personnel rendent des comptes au président ou à son délégué, sauf mention contraire dans ces règlements. Le président est membre d'office 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 règlements, et exerce toutes les autres fonctions pouvant être requises par ces règlements et pouvant être confiées de temps à autre par le Conseil d'administration.
Le secrétaire consigne ou fait consigner les comptes rendus du Conseil d'administration dans un ou plusieurs livre(s) prévus à cet effet, vérifie que tous les avis sont dûment remis, conformément aux dispositions de ces règlements ou de la loi, et effectue généralement l'ensemble des tâches que peut lui affecter le président ou le Conseil d'administration de temps à autre.
Section 6. DIRECTEUR FINANCIER
Le directeur financier (Chief Financial Officer – CFO) est le directeur financier de l'ICANN. Sur demande du Conseil d'administration, le directeur donne une garantie de bonne exécution de ses fonctions sous la forme et contre la caution ou les cautions déterminées par le Conseil d'administration. Le directeur financier a la charge et la garde de l'ensemble des capitaux 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 désigné à cet effet par le Conseil d'administration. Le directeur financier dépense les capitaux 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, y compris les audits ou autres révisions de l'ICANN ou de ses organisations de soutien. Le directeur financier est responsable de toute autre question relative aux opérations financières de l'ICANN.
Section 7. CADRES DE DIRECTION SUPPLÉMENTAIRES
En plus des cadres de direction décrits ci-dessus, les cadres de direction ou assistants supplémentaires élus ou nommés par le Conseil d'administration effectuent les tâches qui leur sont affectées par le président ou le Conseil d'administration.
Section 8. RÉMUNÉRATION ET DÉPENSES
La rémunération de tout cadre de direction de l'ICANN est approuvée par le Conseil d'administration. Les frais engagés dans le cadre de l'exercice de leurs fonctions de cadre de direction peuvent être remboursées sur approbation du président (dans le cas de cadres de direction autres que le président), d'un autre cadre de direction 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, établit une politique exigeant, au minimum une fois par an, une déclaration de la part de chaque cadre de direction décrivant 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.
ARTICLE XIV : INDEMNISATION DES ADMINISTRATEURS, DES CADRES DE DIRECTION, DES EMPLOYÉS ET D'AUTRES AGENTS
Dans la mesure du possible permise par le CNPBCL, l'ICANN indemnise chacun de ses agents pour les dépenses, les jugements, les amendes, les 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. Aux fins de cet article, un « agent » de l'ICANN désigne toute personne qui est ou a été un administrateur, un cadre de direction, 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) agissant dans le cadre de ses responsabilités ; ou toute personne qui agit ou agissait à la demande de l'ICANN en tant qu'administrateur, cadre de direction, employé ou agent d'une autre société, d'un partenariat, d'une coentreprise, d'un trust ou d'une autre entreprise. Le Conseil d'administration peut adopter une résolution autorisant l'achat et le maintien d'une assurance au nom de tout agent de l'ICANN, contre toute responsabilité opposable ou engagée par l'agent en cette capacité ou inhérente à son statut, que l'ICANN ait ou non la possibilité d'indemniser l'agent contre cette responsabilité, conformément aux dispositions de cet article.
ARTICLE XV : DISPOSITIONS GÉNÉRALES
Le Conseil d'administration peut autoriser tous cadre ou cadres de direction, agent ou agents, à souscrire un contrat, à exécuter ou à émettre tout acte notarié au nom et de la part de l'ICANN, un tel pouvoir pouvant être général ou restreint à des cas spécifiques. En l'absence d'une autorisation contraire du Conseil d'administration, les contrats et actes notariés ne peuvent être exécutés que par les cadres de direction suivants : le président, tout vice-président ou le directeur financier. À moins d'être autorisé ou agréé par le Conseil d'administration, nul autre cadre de direction, 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.
Tous les fonds de l'ICANN non utilisés autrement feront l'objet d'un dépôt en faveur de l'ICANN dans les banques, compagnies de fidéicommis ou d'autres établissements désignés à cet effet par le Conseil ou par le président agissant par délégation de celui-ci.
Tous les chèques, toutes les traites ou ordres de paiement, notes, ou justificatifs d'endettement émis au nom de l'ICANN sont signés par le cadre ou les cadres de direction, l'agent ou les agents de l'ICANN désignés par le Conseil d'administration, de la façon déterminée par le Conseil d'administration de temps à autre.
Nul emprunt n'est contracté par ou pour l'ICANN et nul justificatif d'endettement n'est émis en son nom sauf si autorisé par une résolution du Conseil d'administration. Un tel pouvoir peut être général ou restreint à des cas spécifiques ; à condition, toutefois, que nul prêt ne soit accordé par l'ICANN à ses administrateurs ou cadres de direction.
ARTICLE XVI : FISCALITÉ
La fin de l'exercice fiscal de l'ICANN est déterminée par le Conseil d'administration.
A la fin de l'exercice fiscal, les livres comptables de l'ICANN sont clos et font l'objet d'un audit par des experts-comptables agréés. La nomination des auditeurs est du ressort du 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, y compris 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 fait rédiger et envoyer le rapport annuel et la déclaration annuelle de certaines transactions tel que requis par le CNPBCL à chaque membre du Conseil d'administration et à toute autre personne désignée par le Conseil d'administration, au plus tard cent-vingt (120) jours suivant la clôture de l'exercice fiscal de l'ICANN.
Au moins quarante-cinq (45) jours avant le début de chaque exercice fiscal, le président prépare et présente au Conseil d'administration une proposition de budget de l'ICANN pour l'exercice fiscal à venir, qui est 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, sont publiés en ligne pour consultation publique avant leur adoption, et, une fois adoptés, sont publiés sur le site Web d'une façon suffisamment détaillée pour qu'ils soient facilement accessibles.
ARTICLE XVII : MEMBRES
L'ICANN n'a pas de membres, au sens de la loi CNPBCL (California Nonprofit Public Benefit Corporation Law), nonobstant l'utilisation du terme « Membre » dans ces règlements, dans tout document de l'ICANN ou dans toute action du Conseil d'administration ou du personnel de l'ICANN.
ARTICLE XVIII : BUREAUX ET CACHET
Le bureau principal pour la conduite des affaires de l'ICANN se situe dans le comté de Los Angeles, en Californie, aux États-Unis. L'ICANN peut également disposer d'un ou de plusieurs bureaux supplémentaires aux États-Unis ou dans d'autres pays, qu'elle peut établir de temps à autre.
Le Conseil d'administration peut adopter un cachet social et l'utiliser en le faisant apposer ou en faisant apposer une reproduction, ou une impression ou autrement.
ARTICLE XIX : AMENDEMENTS
Sauf disposition contraire dans les statuts ou ces règlements, les statuts ou les règlements de l'ICANN peuvent être modifiés, amendés ou abrogés, et de nouveaux statuts ou règlements adoptés sur vote des 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 règlements de l'ICANN, tels qu'amendés et redéfinis le 29 octobre 1999, puis amendés le 21 février 2002 (les « Anciens Règlements »), et les processus et structures définis par les règlements dont cet article fait partie (les « Nouveaux Règlements »). [Note explicative (du 10 décembre 2009) : Pour la Section 5(3) de cet article, la référence aux anciens règlements concerne les Règlements tels qu'ils ont été modifiés et redéfinis jusqu'au 20 mars 2009.]
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, tel que défini 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 Règlements immédiatement après la conclusion de l'assemblée annuelle de 2002, sauf les membres At-Large du Conseil d'administration selon les anciens règlements, qui sont également membres du Conseil d'administration de transition s'ils choisissent de le faire en avisant le secrétaire du Conseil d'administration le 15 décembre 2002 par écrit, ou bien par courrier électronique au plus tard le 23 décembre 2002. Malgré les dispositions de l'Article VI, Section 12 des Nouveaux Règlements, les postes vacants du Conseil de transition ne seront pas pourvus. Le Conseil d'administration de transition ne dispose pas d'agents de liaison, conformément à l'Article VI, Section 9 des Nouveaux Règlements. Les comités du Conseil d'administration existant à la date d'adoption de cet article de transition continuent à exister sous réserve de tout changement au sein des comités du Conseil d'administration ou de leur composition que le Conseil d'administration de transition peut adopter par résolution.
2. Le Conseil d'administration de transition élit un président et un vice-président qui exercent leurs fonctions 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 à l'Article VI, Section 2(1) des Nouveaux Règlements.
4. Après l'adoption de cet article de transition, un comité de nomination doit être formé dans les plus brefs délais, et inclure, dans la mesure du possible, les délégués et les agents de liaison décrits à l'Article VII, Section 2 des Nouveaux Règlements, dont les mandats se terminent à la conclusion de l'assemblée 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 à l'Article VI, Section 8(1)(a)-(c) des Nouveaux Règlements, 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 seront, conformément aux indications du Conseil d'administration de transition, une date et une heure survenant au cours de l'assemblée annuelle de l'ICANN de 2003, au moins sept jours calendaires après la réception par le secrétaire de l'ICANN de l'avis de sélection des administrateurs destiné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, ce dernier reprendra du Conseil d'administration de transition l'ensemble des droits, fonctions et obligations du Conseil d'administration de l'ICANN. Sous réserve de 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 un avis de sélection siègent, en même temps que le président (Article VI, Section 2(1)(e)), dès la date et à l'heure d'entrée en vigueur du nouveau Conseil, et ensuite les administrateurs et les agents de liaison sans droit de vote peuvent siéger à partir du moment où le secrétaire de l'ICANN reçoit l'avis 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 l'assemblée 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 existantes, 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 provisoires existant à la date et à l'heure d'entrée en vigueur continuent à exister conformément à leurs chartes et composition existantes, sous réserve de tout changement que le nouveau Conseil d'administration adopte par résolution.
8. En application de la disposition de limitation des mandats de la Section 8(5) de l'Article VI, l'exercice des fonctions 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 SOUTIEN AUX POLITIQUES D'ADRESSAGE
L'organisation de soutien aux politiques d'adressage continue à fonctionner conformément aux dispositions du protocole d'entente souscrit à l'origine le 18 octobre 1999 entre l'ICANN et un groupe de registres Internet régionaux (RIR), et amendé en octobre 2000, jusqu'à ce qu'un protocole d'entente de remplacement entre en vigueur. Après l'adoption de cet article de transition, l'organisation de soutien aux politiques d'adressage doit sélectionner dans les plus brefs délais, 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 premiers mandats réguliers spécifiés pour chacun de ces sièges à l'Article VI, Section 8(1)(d) et (e) des Nouveaux Règlements; et
2. Le délégué au comité de nomination sélectionné par le conseil de l'organisation de soutien aux politiques d'adressage, conformément à l'Article VII, Section 2(8)(f) des Nouveaux Règlements.
En ce qui concerne les administrateurs de l'ICANN qu'elle est habilitée à choisir et tenant compte du besoin d'une sélection rapide afin d'assurer l'entrée en vigueur du nouveau Conseil d'administration le plus rapidement possible, l'organisation de soutien aux politiques d'adressage peut choisir ces administrateurs parmi les personnes précédemment sélectionnées comme administrateurs de l'ICANN selon les anciens règlements. Dans la mesure où l'organisation de soutien aux politiques d'adressage ne prévient pas par écrit le secrétaire de l'ICANN avant le 31 mars 2003 inclus de ses sélections pour les sièges 9 et 10, l'organisation de soutien aux politiques d'adressage est estimée avoir choisi pour le siège 9 la personne qu'elle a choisie comme administrateur de l'ICANN selon les anciens règlements pour un mandat débutant en 2001 et pour le siège 10 la personne qu'elle a choisie comme administrateur de l'ICANN selon les anciens règlements pour un mandat débutant en 2002.
Section 4. ORGANISATION DE SOUTIEN AUX POLITIQUES DE CODES DE PAYS
1. A l'enrôlement de trente gestionnaires de ccTLD (dont au moins quatre dans chaque région géographique) en tant que membres de la ccNSO, un avis est publié sur le site Web. Le plus rapidement possible après cet avis, les membres du conseil initial de la ccNSO devant être sélectionnés par les membres de la ccNSO sont sélectionnés conformément aux procédures énoncées à l'Article IX, Section 4(8) et (9). A l'achèvement de ce processus de sélection, un avis indiquant que le conseil de la ccNSO a été constitué est publié sur le site Web. Trois membres du conseil de la ccNSO sont sélectionnés par les membres de la ccNSO appartenant à chaque région géographique, parmi lesquels un membre effectue un mandat se terminant à la clôture de la première assemblée annuelle de l'ICANN après la constitution du conseil de la ccNSO, un second membre effectue un mandat se terminant à la clôture de la seconde assemblée annuelle de l'ICANN après la constitution du conseil de la ccNSO et le troisième membre effectue un mandat se terminant à la clôture de la troisième assemblée annuelle après la constitution du conseil de la ccNSO. (La définition de « gestionnaire de ccTLD » énoncée à l'Article IX, Section 4(1) et les définitions énoncées à 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 Règlements, le comité de nomination sélectionne les trois membres du conseil de la ccNSO décrits à l'Article IX, Section 3(1)(b). En sélectionnant trois personnes pour siéger au conseil de la ccNSO, le comité de nomination en désigne une appelée à effectuer un mandat se terminant à la clôture de la première assemblée annuelle de l'ICANN après la constitution du conseil de la ccNSO, une deuxième appelée à effectuer un mandat se terminant à la clôture de la seconde assemblée annuelle de l'ICANN après la constitution du conseil de la ccNSO, et une troisième appelée à effectuer un mandat se terminant à la clôture de la troisième assemblée annuelle de l'ICANN après la constitution du Conseil de la ccNSO. Les trois membres du conseil de la ccNSO sélectionnés par le comité de nomination n'occupent pas leurs sièges avant que le conseil de la ccNSO ne soit constitué.
3. A la constitution du conseil de la ccNSO, le comité consultatif At-Large et le comité consultatif gouvernemental peuvent désigner un agent de liaison auprès du conseil de la ccNSO, conformément à l'Article IX, Section 3(2)(a) et (b).
4. A la constitution du conseil de la ccNSO, le conseil peut désigner des organisations régionales, conformément à l'Article IX, Section 5. A sa désignation, une organisation régionale peut nommer un agent de liaison auprès du conseil de la ccNSO.
5. Jusqu'à la constitution du conseil de la ccNSO, les sièges 11 et 12 du nouveau Conseil d'administration restent vacants. Après la constitution du conseil de la ccNSO, le ccNSO sélectionne dans les plus brefs délais, par l'intermédiaire du conseil de la ccNSO, les administrateurs destiné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 à l'Article VI, Section 8(1)(d) et (f) des Nouveaux Règlements, et informe par écrit le secrétaire de l'ICANN de ses sélections.
6. Jusqu'à la constitution du conseil de la ccNSO, le délégué au comité de nomination établi par les nouveaux règlements devant être sélectionné par le ccNSO, est désigné par le 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 des membres de la communauté des ccTLD. A la constitution du conseil de la 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 de la ccNSO peut remplacer ce délégué par un autre de son choix dans les trois mois après la clôture de l'assemblée 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 à l'Article VII, Section 2(8)(c) sont effectuées par le conseil de la ccNSO.
Section 5. ORGANISATION DE SOUTIEN AUX POLITIQUES DES NOMS GÉNÉRIQUES
1. L'organisation de soutien aux politiques des noms génériques (« GNSO ») continue ses activités à compter de l'adoption de cet article de transition ; elle sera néanmoins restructurée en quatre nouveaux groupes de parties prenantes qui représenteront, dans l'organisation, les regroupements préalables de la GNSO, sous réserve de l'approbation par le Conseil d'administration de l'ICANN de la charte de chaque groupe de parties prenantes :
a. Le regroupement des registres gTLD sera attribué au groupe multipartite des registres ;
b. Le regroupement des bureaux d'enregistrement sera attribué au groupe multipartite des registraires ;
c. Le regroupement des utilisateurs commerciaux d'Internet sera attribué au groupe multipartite commercial ;
d. Le regroupement de la propriété intellectuelle sera attribué au groupe multipartite commercial ;
e. Le regroupement des fournisseurs de services Internet sera attribué au groupe multipartite commercial ; et
f. Le regroupement des utilisateurs non commerciaux sera attribué au groupe multipartite non commercial ;
2. Chaque regroupement GNSO décrit au paragraphe 1 de cette sous-section continuera à opérer en substance comme avant et comme un groupe de travail de regroupement non officiel ; une autre activité sera changée pour les actions futures du regroupement, à condition que chaque regroupement GNSO décrit dans le paragraphe 1 (c-f) présente au secrétaire de l'ICANN une nouvelle charte, ou une charte révisée, incluant ces procédures de fonctionnement, adoptées conformément les procédures du regroupement et cohérente avec les amendements réalisés aux statuts, au plus tard lors de la réunion de l'ICANN d'octobre 2009, ou à une autre date établie par résolution du Conseil.
3. Avant le début de la réunion de l'ICANN d'octobre 2009, ou à une autre date établie par résolution du Conseil, le conseil de la GNSO devra être cohérent avec sa structure de regroupements et de direction actuelle telles que décrites à l'Article X, Section 3(1) des Règlements, amendé et reformulé en octobre 1999 et amendée le 20 mars 2009 (les « anciens Règlements »). Par la suite, la composition du conseil de la GNSO devra respecter les dispositions de ces statuts et leurs amendements ultérieurs. Tous les comités, groupes d'études, groupes de travail, comités de rédaction et des groupes similaires établis par le conseil de la GNSO et existants immédiatement avant l'adoption de cet article de transition devront continuer leur existence sous les mêmes chartes, avec les mêmes membres et activités, pouvant faire l'objet de changements décidés par le conseil du GNSO ou par le Conseil d'administration de l'ICANN.
4. À partir du commencement de la réunion de l'ICANN du mois d'octobre 2009, ou une autre date décidée par résolution du Conseil (la "date effective de la transition"), les sièges du conseil de la GNSO seront assignés comme suit :
a. Les trois sièges normalement assignés au regroupement des registres sera réassigné avec les trois sièges pour le groupe multipartite des registres ;
b. Les trois sièges normalement assignés au regroupement des bureaux d'enregistrement sera réassigné avec les trois sièges pour le groupe multipartite des registraires ;
c. Les trois sièges normalement assignés au regroupement des utilisateurs commerciaux d'Internet, au regroupement de la propriété intellectuelle et au regroupement des fournisseurs de services Internet (neuf en tout) seront réduits à six sièges attribués au groupe des parties prenantes commerciales ;
d. Les trois sièges normalement assignés au regroupement des utilisateurs non commerciaux sera augmenté à six sièges pour le groupe des parties prenantes non commerciales ;
e. Les trios sièges normalement sélectionnés par le comité de nomination seront réassignés par le comité de nomination comme suit : un membre avec droit de vote pour la chambre pour les parties contractées, un membre avec droit de vote pour la chambre pour les parties non contractées, et un membre sans droit de vote assigné au conseil du GNSO en général.
Des représentants du conseil du GNSO seront nommés ou élus conformément les dispositions prévues dans chaque charte du groupe des parties prenantes en vigueur, approuvées par le Conseil et suffisamment avant la réunion d'octobre 2009 de l'ICANN ce qui permettra aux représentants d'agir officiellement dès le début de cette réunion.
5. Le conseil de la GNSO, comme une partie de son plan de restructuration déterminera : comment les postes vacants, s'il y en avait, seront gérés pendant la période de transition ; (b) pour chaque groupe des parties prenantes, comment seront remplis les sièges alloués au Conseil pour que cela prenne effet lors de la réunion annuelle de l'ICANN de 2009, s'il y avait un nouveau délai, ou une nouvelle élection ou nomination ; (c) comment prévoit-on faire l'échelonnement pour que le conseil de la GNSO puisse raisonnablement préserver la continuité ; et (d) l'effet des statuts sur la limite du nombre de mandats pour chaque membre du Conseil.
6. Dès que cela sera réalisable après le commencement de la réunion d'octobre 2009 de l'ICANN, ou une autre date décidée par résolution du Conseil d'administration, le Conseil de la GNSO, conformément Article X, Section 3(7) et les procédures de fonctionnement de la GNSO, devra élire des membres et en informer par écrit le secrétaire de l'ICANN.
Section 6. ORGANISATION DE SOUTIEN AUX PROTOCOLES
L'Organisation de soutien aux protocoles mentionnée dans les anciens Règlements est supprimée.
Section 7. COMITÉS CONSULTATIFS ET GROUPE DE LIAISON TECHNIQUE
1. A l'adoption des nouveaux règlements, 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 règlements, en informant le secrétaire de l'ICANN par écrit. A compter de l'adoption de cet article de transition, le comité consultatif gouvernemental informe dans les plus brefs délais 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 Règlements.
2. Les organisations désignées comme membres du groupe de liaison technique conformément à l'Article XI-A, Section 2(2) des Nouveaux Règlements désignent chacune les deux experts techniques individuels décrits à l'Article XI-A, Section 2(6) des Nouveaux Règlements, en informant le secrétaire de l'ICANN par écrit. Aussitôt que possible, le délégué du groupe de liaison technique au comité de nomination est sélectionné conformément à l'Article XI-A, Section 2(7) des Nouveaux Règlements.
3. A l'adoption des nouveaux règlements, le Comité consultatif sur la sécurité et la stabilité continue à fonctionner conformément à ses principes et pratiques de fonctionnement existants, jusqu'à ce que le comité prenne les mesures qui s'imposent. A compter de l'adoption de cet article de transition, le comité consultatif pour la sécurité et la stabilité informe le plus tôt possible 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 Règlements.
4. A l'adoption des nouveaux règlements, le Comité consultatif sur le système des serveurs racine continue à fonctionner conformément à ses principes et pratiques de fonctionnement existants, jusqu'à ce que le comité prenne les mesures qui s'imposent. Au plus tôt après l'adoption de cet article de transition, le comité consultatif du système de serveurs racine informe 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 Règlements.
5. Comité consultatif At-Large
a. Un comité consultatif At-Large intérimaire est établi jusqu'à ce que l'ICANN reconnaisse, par la signature d'un protocole d'entente, l'ensemble des organisations régionales At-Large (RALO) identifiées à l'Article XI, Section 2(4) des Nouveaux Règlements. Le comité consultatif At-Large intérimaire se compose de (i) dix personnes (deux de chaque région de l'ICANN) sélectionnées par le Conseil d'administration de l'ICANN après nomination par le comité d'organisation At-Large et (ii) de cinq personnes supplémentaires (une de chaque région de l'ICANN) sélectionnées par le comité de nomination initial aussitôt que possible conformément aux principes établis à l'Article VII, Section 5 des Nouveaux Règlements. Le comité de nomination initial désigne deux de ces personnes pour effectuer des mandats jusqu'à la clôture de l'assemblée annuelle de l'ICANN de 2004 et trois de ces personnes pour effectuer des mandats jusqu'à la clôture de l'assemblée annuelle de l'ICANN de 2005.
b. A la signature d'un tel protocole d'entente par chaque RALO, cette entité est habilitée à sélectionner deux personnes qui sont citoyennes et résidentes de cette région pour les postes de membres du comité consultatif At-Large établi par l'Article XI, Section 2(4) des Nouveaux Règlements. A compter de la remise de l'avis de sélection de l'entité au secrétaire de l'ICANN, ces personnes occupent immédiatement les sièges pourvus jusqu'à cet avis par les membres du comité consultatif At-Large intérimaire et précédemment sélectionnés par le Conseil d'administration au sein de la région RALO.
c. A l'entrée en fonction des personnes sélectionnées par les cinq RALO, le comité consultatif At-Large intérimaire devient le comité consultatif At-Large, conformément à l'Article XI, Section 2(4) des Nouveaux Règlements. Les cinq personnes sélectionnées au comité consultatif At-Large intérimaire par le comité de nomination deviennent membres du comité consultatif At-Large et ce jusqu'à la fin du mandat pour lequel elles ont été sélectionnées.
d. Le plus tôt possible après sa création, le comité consultatif At-Large intérimaire informe 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 Règlements.
Section 8. CADRES DE DIRECTION
Les cadres de direction de l'ICANN (tels qu'ils sont définis à l'Article XIII des Nouveaux Règlements) sont élus par le Conseil d'administration de l'ICANN en place lors de l'assemblée annuelle de 2002 pour remplir leurs fonctions jusqu'à l'assemblée annuelle de 2003.
Section 9. GROUPES NOMMÉS PAR LE PRÉSIDENT
Nonobstant l'adoption ou l'entrée en vigueur des nouveaux règlements, les équipes d'étude et les autres groupes nommés par le président de l'ICANN conservent la même composition, le même champ 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'entrée en vigueur des nouveaux règlements, tous les contrats, y compris les contrats de travail et de conseil, souscrits par l'ICANN restent en vigueur conformément à leurs termes.
Annexe A : Processus d'élaboration des politiques de la GNSO
Le processus suivant régit le processus d'élaboration des politiques (« PDP ») de la GNSO jusqu'au moment où des modifications sont recommandées au Conseil d'administration de l'ICANN (« Conseil d'administration ») et validées par ce dernier. [Remarque : cette annexe contient des amendements nécessaires pour une base provisoire permettant à la GNSO de fonctionner pendant que les discussions du Conseil et de la communauté sur le développement des politiques et les procédures de fonctionnement continuent].
1. Proposition d'une problématique
Une problématique à examiner dans le cadre d'un PDP peut être proposée d'une des manières suivantes :
a. Lancement par le Conseil d'administration. Le Conseil d'administration peut lancer le PDP en enjoignant au conseil de la GNSO (« conseil ») d'entamer le processus présenté dans cette annexe.
b. Lancement par le conseil. Le conseil de la GNSO peut lancer le PDP par le vote d'au moins vingt-cinq pour cent (25%) des membres du conseil présents à toute réunion au cours de laquelle une motion en faveur du lancement d'un PDP est déposée.
c. Lancement par un comité consultatif. Un comité consultatif peut proposer une problématique à aborder dans le cadre d'un processus d'élaboration de politique par décision en faveur du lancement du PDP et transmission de sa requête au conseil de la GNSO.
2. Création du rapport sur la problématique
Dans les quinze (15) jours calendaires à compter de la réception (i) d'une directive du Conseil d'administration ; (ii) d'une motion correctement soutenue d'un membre du conseil ; ou (iii) d'une motion correctement soutenue d'un comité consultatif, le chef du personnel créera un rapport (un « rapport sur la problématique »). Chaque rapport sur une problématique comprend au minimum :
a. la problématique proposée à la discussion ;
b. l'identité de la partie soumettant la problématique ;
c. comment cette partie est concernée par cette problématique ;
d. le soutien en faveur du lancement d'un PDP pour aborder la problématique en question ;
e. une recommandation du chef du personnel concernant l'opportunité du lancement par le conseil d'un PDP pour aborder cette problématique (« recommandation du personnel »). Chaque recommandation du personnel inclut l'opinion de l'avocat-conseil de l'ICANN concernant la mesure dans laquelle la problématique proposée pour lancer le PDP relève réellement du champ d'action du processus de politiques de l'ICANN et du champ d'action de la GNSO. Afin de déterminer si la problématique concernée relève réellement du champ d'action du processus de politiques de l'ICANN, l'avocat-conseil vérifie si cette problématique :
1. relève de l'étendue de la déclaration de mission de l'ICANN ;
2. s'applique globalement à des situations ou à des organisations multiples ;
3. est susceptible de rester longtemps applicable ou d'actualité, quoique nécessitant des mises à jour occasionnelles ;
4. établira un guide ou un cadre pour de futures prises de décision ; ou
f. Dans la limite des quinze (15) jours, le chef du personnel distribue le rapport sur la problématique à l'ensemble du conseil pour le vote sur la question du lancement du PDP, comme décrit ci-dessous.
Le conseil lance le PDP de la façon suivante :
a. Problématique proposée par le Conseil d'administration. Si le Conseil d'administration ordonne au conseil de lancer le PDP, le conseil se réunit pour le faire dans les quinze (15) jours calendaires suivant la réception du rapport sur la problématique, sans vote intermédiaire du conseil.
b. Problématique proposée par un organe différent du Conseil d'administration. Si une problématique de politique est présentée au conseil pour examen par le biais d'un rapport sur la problématique, le conseil se réunit dans les quinze (15) jours calendaires suivant la réception dudit rapport pour voter en faveur ou non du lancement du PDP. Cette réunion peut être convoquée de la manière jugée appropriée par le conseil, y compris en personne, par téléconférence ou par courrier électronique.
c. Vote du conseil. Un vote de plus de 33% des membres du conseil présents de chaque chambre ou de plus de 66% des votes d'une chambre en faveur du lancement du PDP relevant de leur compétence suffit à lancer le PDP, à moins que la recommandation du personnel n'ait déclaré que la problématique ne relevait pas du champ d'action du processus de politiques de l'ICANN ou de la GNSO, auquel cas un vote à la majorité qualifiée tel qu'établi à l'Article X, Section 3, paragraphe 9(c) 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 vote majoritaire des membres présents à la réunion, s'il faut nommer une équipe d'étude pour traiter la problématique. Si le conseil vote :
a. en faveur de l'établissement d'une équipe d'étude, il le fait conformément aux dispositions de l'Item 7 ci-dessous.
b. contre l'établissement d'une équipe d'étude, il rassemblera alors des informations sur la problématique de politique conformément aux dispositions de l'Item 8 ci-dessous.
5. Composition et sélection des équipes d'étude
a. A compter du vote pour la nomination d'une équipe d'étude, le conseil invite chacun des regroupements de la GNSO à nommer une personne qui fera partie de l'équipe d'étude. En outre, le conseil peut nommer jusqu'à trois conseillers externes pour faire partie de l'équipe d'étude. (Chaque membre d'une équipe d'étude est désigné dans cette annexe par le terme « représentant », et collectivement, par le terme « représentants »). Le conseil peut, à sa discrétion, augmenter le nombre de représentants par regroupement pouvant faire partie d'une équipe d'étude, s'il le juge nécessaire ou approprié.
b. Tout regroupement souhaitant nommer un représentant dans l'équipe d'étude doit soumettre le nom de la personne désignée par le regroupement au chef du personnel dans les dix (10) jours calendaires après une telle demande pour que le représentant soit inclus dans l'équipe d'étude. Une telle personne désignée n'a pas besoin d'être un membre du conseil, mais doit être une personne 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 de l'équipe d'étude.
c. Le conseil peut également prendre d'autres mesures qui lui semblent appropriées et utiles pour le PDP, y compris la nomination d'une personne ou d'une organisation particulière pour rassembler des informations sur la problématique ou programmer des réunions de délibération ou d'information. Toutes ces informations sont soumises au chef du personnel dans les trente-cinq (35) jours calendaires suivant le lancement du PDP.
6. Annonce du lancement du PDP
Après le lancement du PDP, l'ICANN publie une annonce de cette action en ligne sur le site Web. Une période de consultation publique sur la problématique est ouverte pendant vingt (20) jours calendaires après le lancement du PDP. Le chef du personnel, 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 de la consultation publique ») devant être inclus soit dans le rapport préliminaire de l'équipe d'étude, soit dans le rapport initial, selon les besoins.
a. Rôle de l'équipe d'étude. Si une équipe d'études est créée, son rôle sera généralement (i) de rassembler des informations décrivant en détail les positions des groupes de parties prenantes et des regroupements officiels et des regroupements provisoires, s'il en existe, au sein de la GNSO ; et (ii) d'obtenir des informations pertinentes qui permettront au rapport de l'équipe d'étude d'être aussi complet et informatif que possible.
L'équipe d'étude ne dispose d'aucune autorité officielle pour la prise de décisions. Le rôle de l'équipe d'étude est plutôt de rassembler les informations à l'appui des positions de parties ou de groupes divers de la façon la plus spécifique et la plus détaillée possible, permettant ainsi au conseil d'avoir une délibération utile et avisée sur la problématique.
b. Charte ou cahier des charges de l'équipe d'étude. Le conseil, assisté par le chef du personnel, élabore une charte ou un cahier des charges pour l'équipe d'étude (la « charte ») dans les dix (10) jours calendaires suivant le lancement du PDP. Cette charte inclura :
1. la problématique devant être abordée par l'équipe d'études, telle qu'elle a été exprimée pour le vote devant le conseil qui a lancé le PDP ;
2. les délais spécifiques que l'équipe d'étude doit respecter, conformément aux indications ci-dessous, à moins que le Conseil d'administration ne décide qu'il existe une raison valable pour prolonger les délais ; et
3. toutes les instructions spécifiques du conseil à l'adresse de l'équipe d'étude, y compris si cette dernière doit ou non solliciter l'avis de conseillers externes sur la problématique abordée.
L'équipe d'étude prépare ses rapports et mène ses activités conformément à la charte. Toute demande de déviation par rapport à la charte doit être officiellement présentée au conseil et ne peut être mise en œuvre par l'équipe d'étude qu'après un vote de la majorité des membres du conseil présents.
c. Nomination du président de l'équipe d'étude. Le chef du personnel organise la première réunion de l'équipe d'étude dans les cinq (5) jours calendaires suivant la réception de la charte. Lors de la réunion initiale, les membres de l'équipe d'étude devront, entre autres, voter pour nommer un président de l'équipe d'étude. Le président est responsable de l'organisation des activités de l'équipe d'étude, y compris de l'établissement du rapport de l'équipe d'étude. Le président d'une équipe d'études n'est pas nécessairement un membre du conseil.
d. Rassemblement des informations.
1. Déclarations des regroupements. Les représentants seront responsables chacun, au minimum, de solliciter le point de vue de leur regroupement, concernant la problématique en question et d'autres commentaires que chaque représentant juge opportuns. Cette position et d'autres commentaires, le cas échéant, devraient être soumis sous forme d'une déclaration officielle au président de l'équipe d'étude (une « déclaration du regroupement » pour chacun) dans les trente-cinq (35) jours calendaires suivant le lancement du PDP. Chaque déclaration de regroupement doit inclure au moins les éléments suivants :
(i) si un vote à la majorité qualifiée est acquis, une déclaration claire de la position du regroupement par rapport à la problématique ;
(ii) si un vote à la majorité qualifiée n'est pas acquis, une déclaration claire de toutes les positions adoptées par les membres du regroupement ;
(iii) une déclaration claire de la façon dont le regroupement est arrivé à cette ou ces positions. Précisément, la déclaration devrait décrire en détail les réunions spécifiques du regroupement, les téléconférences ou les autres moyens de délibérer sur une problématique, ainsi qu'une liste de tous les membres qui ont participé ou autrement soumis leurs points de vue ;
(iv) une analyse de la façon dont la problématique affecterait le regroupement, y compris tout impact financier sur le regroupement ; et
(v) une analyse de la période de temps estimée nécessaire pour mettre en œuvre la politique.
2. Conseillers externes. L'équipe d'étude peut, si elle l'estime approprié ou utile, solliciter les opinions de conseillers externes, d'experts ou d'autres membres du public, en plus de celles des membres du regroupement. Ces opinions devraient être présentées dans un rapport préparé par ces conseillers externes et (i) être clairement identifiées comme provenant de conseillers externes ; (ii) être accompagnées par une déclaration détaillée (A) des qualifications et de l'expérience pertinente des conseillers ; et (B) des conflits d'intérêt potentiels des conseillers. Ces rapports devraient être soumis sous forme de déclaration officielle au président de l'équipe d'étude dans les trente-cinq (35) jours calendaires suivant le lancement du PDP.
e. Rapport de l'équipe d'étude. Le président de l'équipe d'étude, en collaboration avec le chef du personnel, réunit les déclarations de regroupements, le rapport de la consultation publique et les autres informations et rapports, le cas échéant, en un seul document (« rapport préliminaire de l'équipe d'étude ») et distribue le rapport préliminaire de l'équipe d'étude à l'ensemble de l'équipe d'étude dans les quarante (40) jours calendaires suivant le lancement du PDP. L'équipe d'étude organise une réunion finale dans les cinq (5) jours après la date de distribution du rapport préliminaire de l'équipe d'étude afin de délibérer sur la problématique abordée et d'essayer d'acquérir un vote à la majorité qualifiée. Dans les cinq (5) jours calendaires suivant la réunion finale de l'équipe d'étude, le président de l'équipe d'étude et le chef du personnel rédigent le rapport final de l'équipe d'étude (le « rapport de l'équipe d'étude ») et le publient en ligne sur le site de sollicitation de commentaires. Chaque rapport d'équipe d'étude doit comprendre :
1. une déclaration claire de toute position relative à la problématique abordée et votée à la majorité qualifiée de l'équipe d'étude ;
2. Si un vote à la majorité qualifiée n'a pas été acquis, une déclaration claire de toutes les positions adoptées par les membres de l'équipe d'étude soumise dans le délai de vingt jours pour la soumission de rapports de regroupements. Chaque déclaration devrait clairement indiquer (i) les raisons sous-tendant la position et (ii) le(s) regroupement(s) ayant adopté la position ;
3. une analyse de la façon dont la problématique affecterait chaque regroupement de l'équipe d'étude, y compris tout impact financier sur le regroupement ;
4. une analyse de la période de temps estimée nécessaire pour mettre en œuvre la politique ; et
5. L'avis des conseillers externes nommés à l'équipe d'étude par le Conseil, accompagné d'une déclaration détaillée (i) des qualifications et de l'expérience pertinente des conseillers ainsi que (ii) des conflits d'intérêts potentiels.
8. Procédure si une équipe d'étude n'est pas établie
a. Si le conseil décide de ne pas réunir une équipe d'étude, le conseil demandera que, dans les dix (10) jours calendaires suivants, chaque regroupement nomme un représentant pour solliciter les points de vue du regroupement sur la problématique. Chacun de ces représentants est requis de soumettre une déclaration de regroupement au chef du personnel dans les trente-cinq (35) jours calendaires suivant le lancement du PDP.
b. Le conseil peut également choisir d'autres options qu'il estime appropriées en matière d'assistance au PDP, y compris la nomination d'une personne ou d'une organisation particulière pour rassembler des informations sur la problématique ou programmer des réunions de délibération ou d'information. Toutes ces informations sont soumises au chef du personnel dans les trente-cinq (35) jours calendaires suivant le lancement du PDP.
c. Le chef du personnel recevra l'ensemble des rapports de regroupements, des rapports de consultation publique et autres informations et les réunira (et publiera sur le site des commentaires) en un rapport initial dans les cinquante (50) jours calendaires suivant le lancement du PDP. Par la suite, le PDP se déroule selon les dispositions du point 9 ci-dessous pour la rédaction d'un rapport final.
9. Commentaires du public sur le rapport de l'équipe d'étude ou le rapport initial
a. La période de consultation publique durera vingt (20) jours après la publication du rapport de l'équipe d'étude ou du rapport initial. Toute personne ou organisation peut soumettre des commentaires pendant la période de consultation publique, y compris les regroupements n'ayant pas participé à l'équipe d'étude. Tous les commentaires doivent être accompagnés du nom de l'auteur des commentaires, de son expérience pertinente et de son intérêt par rapport à la problématique.
b. À la fin de la période de vingt (20) jours, le chef du personnel sera 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 du personnel, dans le rapport de l'équipe d'étude ou dans le rapport initial (collectivement, le « rapport final »). Le chef du personnel n'est pas obligé d'inclure tous les commentaires faits pendant la période de consultation publique, ni d'inclure tous les commentaires par une seule personne ou organisation.
c. Le chef du personnel prépare le rapport final et le soumet au président du conseil dans les dix (10) jours calendaires suivant la fin de la période de consultation publique.
a. A la réception d'un rapport final, qu'il soit le fruit du travail de l'équipe d'étude ou autre, le président du conseil (i) distribuera le rapport final à tous les membres du conseil ; et (ii) convoquera une réunion du conseil dans les dix (10) jours calendaires suivants. Le conseil peut commencer ses délibérations sur la problématique avant la réunion officielle, y compris par le biais de réunions en face à face, de téléconférences, d'échanges de courriers électroniques et de tout autre moyen du choix du conseil. Le processus de délibération aboutira à une réunion officielle du conseil en face à face ou par téléconférence, au cours de laquelle le conseil œuvrera dans le but d'acquérir un vote à la majorité qualifiée à présenter au Conseil d'administration.
b. Le conseil peut, s'il en décide ainsi, solliciter les opinions de conseillers externes lors de la réunion finale. Si le conseil se fie aux opinions des conseillers, celles-ci sont (i) incorporées dans le rapport du conseil au Conseil d'administration, (ii) spécifiquement identifiées comme provenant d'un conseiller externe ; et (iii) accompagnées d'une déclaration détaillée (x) des qualifications et de l'expérience pertinente du conseiller ; et (y) des conflits d'intérêt potentiels du conseiller.
11. Rapport du conseil au Conseil d'administration
Le chef du personnel sera présent lors de la réunion finale du conseil, et disposera de cinq (5) jours calendaires 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 au Conseil d'administration »). Le rapport au Conseil d'administration doit contenir au minimum les éléments suivants :
a. une déclaration claire de toute recommandation validée par un vote à la majorité qualifiée du conseil ;
b. si un vote à la majorité qualifiée n'a pas été acquis, une déclaration claire de toutes les positions adoptées par les membres du conseil. Chaque déclaration devrait clairement indiquer (i) les raisons sous-tendant chaque position et (ii) le(s) regroupement(s) ayant adopté la position ;
c. une analyse de la façon dont la problématique affecterait chaque regroupement, y compris tout impact financier sur le regroupement ;
d. une analyse de la période de temps estimée nécessaire pour mettre en œuvre la politique ;
e. les avis des conseillers externes auxquels le conseil s'est fié, qui devraient être accompagnés par une déclaration détaillée des (i) qualifications et de l'expérience pertinente des conseillers ; et (ii) des conflits d'intérêt potentiels des conseillers ;
f. le rapport final soumis au conseil ; et
g. une copie du compte-rendu des délibérations du conseil sur la problématique de la politique, incluant toutes les 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é qualifiée des membres du conseil sera réputé refléter le point de vue du conseil, et peut être transmis au Conseil d'administration comme recommandation du conseil. Au cas où le vote à la majorité qualifiée de la GNSO n'était pas atteint, l'approbation des recommandations contenues dans le rapport final a besoin de la majorité des deux chambres et aussi qu'un représentant d'au moins 3 des 4 groupes multipartites donne son soutien à ces recommandations. Les abstentions ne sont pas autorisées ; ainsi tous les membres du conseil doivent exprimer leur vote, à moins qu'ils n'identifient un intérêt financier dans le résultat de la problématique de la politique. Nonobstant les faits précédemment cités, comme exposé ci-dessus, tous les points de vue exprimés par les membres du conseil au cours du PDP doivent être inclus dans le rapport au Conseil d'administration.
13. Vote du Conseil d'administration
a. Le Conseil d'administration se réunira pour discuter des recommandations du conseil de la GNSO le plus rapidement possible après la réception du rapport au Conseil d'administration de la part du chef du personnel.
b. Dans le cas où le conseil a voté à la majorité qualifiée, le Conseil d'administration adopte la politique en accord avec la recommandation votée à la majorité qualifiée du conseil, à moins qu'un vote de plus de soixante six pour cent (66%) du Conseil d'administration ne décide qu'une telle politique n'est pas dans le meilleur intérêt de la communauté de l'ICANN ou de l'ICANN.
c. Dans le cas où le Conseil d'administration décide de pas suivre la recommandation votée à la majorité qualifiée du conseil, le Conseil d'administration doit (i) exprimer les raisons de cette décision dans un rapport adressé au conseil (la « déclaration du Conseil d'administration ») ; et (ii) soumettre la déclaration du Conseil d'administration au conseil.
d. Le conseil examine la déclaration du Conseil d'administration pour une discussion avec le Conseil d'administration dans les vingt (20) jours calendaires suivant la réception par le conseil de la déclaration du Conseil d'administration. Le Conseil d'administration décide quelle méthode (par ex. par téléconférence, courrier électronique ou autre) utiliser pour discuter avec le conseil.
e. À la fin des discussions entre le conseil et le Conseil d'administration, le conseil se réunit pour confirmer ou modifier sa recommandation, et communique cette résolution (la « recommandation complémentaire ») au Conseil d'administration, en incluant une explication de sa recommandation actuelle. Dans le cas où le conseil est en mesure d'acquérir un vote à la majorité qualifiée sur la recommandation complémentaire, le Conseil d'administration doit adopter la recommandation, à moins qu'un vote de plus de soixante six pour cent (66%) du Conseil d'administration ne décide qu'une telle politique n'est pas dans le meilleur intérêt de la communauté de l'ICANN ou de l'ICANN.
f. Dans le cas où le conseil n'est pas en mesure d'acquérir un vote à la majorité qualifiée, un vote de la majorité du Conseil d'administration est suffisant pour agir.
g. Lorsqu'une décision finale à propos d'une recommandation ou une recommandation complémentaire du conseil de la GNSO est opportune, le Conseil d'administration organise un vote préliminaire et, dans la mesure du possible, publie une décision provisoire accordant une période de consultation publique de dix (10) jours avant une décision finale du Conseil d'administration.
14. Mise en œuvre de la politique
A la prise de décision finale du Conseil d'administration, le Conseil d'administration donne l'autorisation ou enjoint au personnel de l'ICANN, selon le cas, de prendre toutes les dispositions nécessaires à la mise en œuvre de la politique.
Tout au long du PDP, à compter de la suggestion de la politique jusqu'à la décision finale prise par le Conseil d'administration, l'ICANN maintiendra sur le site Web, une page Web de l'état du PDP décrivant en détail le progrès de chaque problématique abordée par le PDP, à savoir :
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 sur la problématique ;
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 équipes d'étude, du chef du personnel, 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 désignés par l'ICANN et sur lesquels des avis et des commentaires au sujet du PDP seront publiés.
« Vote à la majorité qualifiée » désigne un vote de plus de soixante six (66) pour cent des membres présents à une réunion de l'organe concerné, à l'exception du conseil de la GNSO.
« Chef du personnel » désigne un membre du personnel de l'ICANN en charge de gérer le PDP.
Le « vote à la majorité qualifiée de la GNSO » aura la signification établie dans les Règlements.
Un « vote à la majorité qualifiée de la GNSO » est un vote affirmatif du Conseil de la GNSO qui atteint les seuls de vote établis à l'Article X, Section 3(9) y compris, sans limitation, le vote à la majorité qualifiée de la GNSO.
Annexe B : Processus d'élaboration des politiques de la ccNSO (ccPDP)
Le processus suivant régit le processus d'élaboration des politiques (« PDP ») de la ccNSO :
1. Demande d'un rapport sur une problématique
Un rapport sur une problématique peut être demandé par les instances suivantes :
a. Conseil. Le Conseil de la ccNSO (dans cette annexe B, le « conseil ») peut requérir la création d'un rapport sur la problématique 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 requérir la création d'un rapport sur une problématique en enjoignant au conseil de lancer le processus d'élaboration de politiques.
c. Organisation régionale. Une ou plusieurs des organisations régionales représentant les ccTLD dans les régions reconnues de l'ICANN peuvent requérir la création d'un rapport sur une problématique en demandant au conseil de lancer le processus d'élaboration de 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 requérir la création d'un rapport sur une problématique en demandant au conseil de lancer le processus d'élaboration de politiques.
e. Membres de la ccNSO. Les membres de la ccNSO peuvent requérir la création d'un rapport sur une problématique par un vote affirmatif d'au moins dix des membres de la ccNSO présents à une réunion ou votant par courrier électronique.
Toute demande de rapport sur une problématique doit être effectuée par écrit et doit définir la problématique pour laquelle le rapport est demandé, avec suffisamment de détails pour permettre la préparation du rapport sur la problématique. Le conseil peut, à son gré, demander de plus amples informations ou entreprendre des recherches ou des investigations plus approfondies dans le but de déterminer si le rapport sur la problématique demandé doit être créé ou non.
2. Création du rapport sur la problématique et seuil de lancement
Dans les sept jours suivant un vote affirmatif, tel que mentionné dans le point 1(a) ci-dessus, ou la réception d'une demande, tel que mentionné dans les points 1 (b), (c), ou (d) ci-dessus, le conseil nomme un gestionnaire de problématique. Le gestionnaire de problématique peut être un membre du personnel de l'ICANN (auquel cas les frais du gestionnaire de problématique sont assumé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 frais du gestionnaire de problématique).
Dans les quinze (15) jours calendaires suivant la nomination (ou toute autre durée que le conseil, en consultation avec le gestionnaire de problématique, estime adaptée), le gestionnaire de problématique crée un rapport sur la problématique. Chaque rapport sur une problématique comprend au minimum :
a. la problématique proposée à la discussion ;
b. l'identité de la partie soumettant la problématique ;
c. comment cette partie est concernée par cette problématique ;
d. le soutien en faveur du lancement d'un PDP pour aborder la problématique en question ;
e. une recommandation du gestionnaire de problématique concernant l'opportunité du lancement par le conseil d'un PDP pour aborder cette problématique (« recommandation du gestionnaire »). Chaque recommandation du gestionnaire inclut et est appuyée par l'opinion de l'avocat-conseil de l'ICANN concernant la mesure dans laquelle la problématique proposée pour lancer le PDP relève réellement du champ d'action du processus de politiques de l'ICANN et du champ d'action de la ccNSO. Afin de former son opinion, l'avocat-conseil vérifie si :
1) la problématique relève de l'étendue de la déclaration de mission de l'ICANN ;
2) l'analyse des facteurs pertinents conformément à l'Article IX, Section 6(2) et à l'Annexe C démontre de manière affirmative que la problématique relève du champ d'action de la ccNSO ;
Dans le cas où l'opinion de l'avocat-conseil est affirmative en ce qui concerne les points 1 et 2 ci-dessus, il vérifie également alors si l'enjeu :
3) implique ou affecte une politique existante de l'ICANN ;
4) est susceptible de rester longtemps applicable ou d'actualité, quoique nécessitant des mises à jour occasionnelles, et de servir de base ou de cadre pour de futures prises de décisions.
Dans tous les cas, la considération des révisions du ccPDP (cette Annexe B) ou du champ d'action de la ccNSO (Annexe C) doit relever du champ d'action de l'ICANN et de la ccNSO.
Dans le cas où l'avocat-conseil est d'avis que la problématique ne relève pas formellement du champ d'action de la ccNSO, le gestionnaire de problématique informe le conseil de cette opinion. Si, après une analyse des facteurs pertinents 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 la problématique relève du champ d'action de la ccNSO, le président de la ccNSO en informe le gestionnaire de problématique. L'avocat-conseil et le conseil de la ccNSO engagent alors un dialogue selon les règles et les procédures convenues pour résoudre la question. En l'absence d'accord entre l'avocat-conseil et le conseil quant à l'appartenance ou non de la problématique au champ d'action de la ccNSO, le conseil peut décider par vote de 15 ou plus de ses membres que la problématique appartient au champ d'action. Le président de la ccNSO informe l'avocat-conseil et le gestionnaire de problématique en conséquence. Le gestionnaire de problématique rédige alors une recommandation en faveur ou non du lancement du PDP par le conseil, et inclut à la fois l'opinion et l'analyse de l'avocat-conseil et du conseil dans le rapport sur la problématique.
f. Dans le cas où la recommandation du gestionnaire est en faveur du lancement du PDP, une proposition de délai pour réaliser chacune des étapes du PDP décrites ici est faite (calendrier du PDP).
g. Si possible, le rapport sur la problématique indique si la considération est susceptible de résulter en une politique devant être approuvée par le Conseil d'administration de l'ICANN. Dans certains cas, il ne sera pas possible de le faire tant que des discussions approfondies sur la problématique n'auront pas eu lieu. Dans ces cas, le rapport sur la problématique devrait indiquer cette incertitude. Une fois le rapport sur la problématique terminé, le gestionnaire de problématique le distribue à l'ensemble du conseil afin que le lancement du PDP soit mis aux voix.
Le Conseil décide de lancer ou non le PDP de la façon suivante :
a. Dans les 21 jours suivant la réception d'un rapport sur une problématique de la part du gestionnaire de problématique, le conseil se réunit pour mettre le lancement du PDP aux voix. Cette réunion est convoquée de la manière jugée appropriée par le conseil, y compris, en personne, par téléconférence ou même par courrier électronique.
b. Un vote de dix ou plus des membres du conseil en faveur du lancement du PDP est nécessaire pour lancer le PDP, à condition que le rapport sur la problématique indique que la problématique relève de l'étendue de la déclaration de mission de l'ICANN et appartient au champ d'action de la ccNSO.
4. Décision de nommer ou non une équipe d'étude ; Établissement d'un calendrier
Lors de la réunion du conseil au cours de laquelle le PDP a été lancé (ou, si le conseil a recours à un vote par courrier électronique, lors de ce vote), conformément au point 3 ci-dessus, le conseil décide, par vote majoritaire des membres présents à la réunion (ou votant par courrier électronique), s'il faut nommer une équipe d'études pour traiter la problématique. Si le conseil vote :
a. en faveur de l'établissement d'une équipe d'étude, il le fait conformément aux dispositions du point 7 ci-dessous.
b. contre l'établissement d'une équipe d'étude, il rassemblera alors des informations sur la problématique de politique conformément aux dispositions du point 8 ci-dessous.
Le Conseil doit également, par vote à la majorité qualifiée des membres présents à la réunion ou votant par courrier électronique, approuver ou modifier et approuver le calendrier du PDP défini dans le rapport.
5. Composition et sélection des équipes d'étude
a. Après le vote pour la nomination d'un groupe d'étude, le conseil invite chaque organisation régionale (voir l'Article IX, Section 6) à nommer deux personnes qui feront partie de l'équipe d'étude (les « représentants »). En outre, le conseil peut nommer jusqu'à trois conseillers (les « conseillers ») externes au ccNSO et, à la suite d'une demande officielle de participation du GAC à l'équipe d'étude, accepter jusqu'à deux représentants du comité consultatif gouvernemental qui feront partie de l'équipe d'étude. Le conseil peut, à sa discrétion, augmenter le nombre de représentants pouvant faire partie d'une équipe d'étude, s'il le juge nécessaire et approprié.
b. Toute organisation régionale souhaitant nommer des représentants dans l'équipe d'étude doit soumettre les noms des représentants au gestionnaire de problématique dans les dix (10) jours calendaires après une telle demande pour qu'ils soient inclus dans l'équipe d'étude. Ces représentants n'ont pas besoin d'être membres du conseil, mais chacun d'entre eux doit être une personne 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 de l'équipe d'étude.
c. Le conseil peut également prendre d'autres mesures qui lui semblent appropriées en matière d'assistance au PDP, y compris la nomination d'une personne ou d'une organisation particulière pour rassembler des informations sur la problématique ou programmer des réunions de délibération ou d'information. Toutes ces informations sont soumises au gestionnaire de problématique conformément au calendrier du PDP.
6. Annonce publique du lancement du PDP et période de consultation publique
Après le lancement du PDP, l'ICANN publie une annonce de cette action en ligne sur le site Web et à l'intention des autres organisations de soutien et comités consultatifs de l'ICANN. Une période de consultation publique sur la problématique (conformément au calendrier du PDP, et généralement d'une durée minimum de 21 jours) est ouverte. Les commentaires sont reçus de la part des gestionnaires de ccTLD, des autres organisations de soutien, des comités consultatifs et du public. Le gestionnaire de problématique, 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 de la consultation publique ») devant être inclus soit dans le rapport préliminaire de l'équipe d'étude, soit dans le rapport initial, selon les besoins.
a. Rôle de l'équipe d'étude. Si une équipe d'étude est créée, son rôle sera (i) de rassembler des informations décrivant en détail les positions des membres de la ccNSO dans les régions géographiques et des autres parties ou groupes ; et (ii) d'obtenir des informations pertinentes qui permettront au rapport de l'équipe d'étude d'être aussi complet et informatif que possible afin de faciliter une délibération utile et avisée du conseil.
L'équipe d'étude ne dispose d'aucune autorité officielle pour la prise de décisions. Le rôle de l'équipe d'étude est plutôt de rassembler les informations à l'appui des positions de parties ou de groupes divers de la façon la plus spécifique et la plus détaillée possible, permettant ainsi au conseil d'avoir une délibération utile et avisée sur la problématique.
b. Charte ou cahier des charges de l'équipe d'étude. Le conseil, assisté par le gestionnaire de problématique, élabore une charte ou un cahier des charges pour l'équipe d'étude (la « charte ») dans les délais définis dans le calendrier du PDP. Cette charte inclura :
1. la problématique devant être traitée par l'équipe d'étude, telle qu'elle a été définie pour le vote devant le conseil qui a lancé le PDP ;
2. les délais spécifiques que l'équipe d'étude doit respecter, conformément aux indications ci-dessous, à moins que le conseil ne décide qu'il existe une raison valable pour prolonger les délais ; et
3. toutes les instructions spécifiques du conseil à l'adresse de l'équipe d'étude, y compris si elle doit ou non solliciter l'avis de conseillers externes sur la problématique abordée.
L'équipe d'étude prépare ses rapports et mène ses activités conformément à la charte. Toute demande de déviation par rapport à 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 au titre de ce point 7(b).
c. Nomination du président de l'équipe d'étude. Le gestionnaire de problématique organise la première réunion de l'équipe d'étude dans les délais indiqués dans le calendrier du PDP. Lors de la réunion initiale, les membres de l'équipe d'étude devront, entre autres, voter pour nommer le président de l'équipe d'étude. Le président est responsable de l'organisation des activités de l'équipe d'étude, y compris de l'établissement du rapport de l'équipe d'étude. Le président d'une équipe d'études n'est pas nécessairement un membre du conseil.
d. Rassemblement des informations.
1. Déclarations des organisations régionales. Les représentants sont responsables chacun, au minimum, de solliciter le point de vue de l'organisation régionale de leur région géographique sur la problématique en question. Ils peuvent solliciter d'autres commentaires que chaque représentant juge opportuns, y compris les commentaires des membres de la ccNSO dans cette région qui ne sont pas membres de l'organisation régionale. La position de l'organisation régionale et les autres commentaires recueillis par les représentants sont soumis sous forme d'une déclaration officielle au président de l'équipe d'étude (une « déclaration régionale » pour chacun) dans les délais indiqués dans le calendrier du PDP. Chaque déclaration régionale doit inclure au moins les éléments suivants :
(i) si un vote à la majorité qualifiée (tel que définie par l'organisation régionale) a été acquis, une déclaration claire de la position de l'organisation régionale par rapport à la problématique ;
(ii) si un vote à la majorité qualifiée n'a pas été acquis, une déclaration claire de toutes les positions adoptées par les membres de l'organisation régionale ;
(iii) une déclaration claire de la façon dont l'organisation régionale est arrivée à cette ou à ces positions. Précisément, la déclaration devrait décrire en détail les réunions spécifiques, les téléconférences ou les autres moyens de délibérer sur une problématique, ainsi qu'une liste de tous les membres qui ont participé ou autrement soumis leurs points de vue ;
(iv) une déclaration de la position pertinente à la problématique de tous membres de la ccNSO qui ne sont pas membres de l'organisation régionale ;
(v) une analyse de la façon dont la problématique affecterait la région, y compris tout impact financier sur la région ; et
(vi) une analyse de la période de temps estimée nécessaire pour mettre en œuvre la politique.
2. Conseillers externes. L'équipe d'étude peut, à sa discrétion, solliciter les opinions de conseillers externes, d'experts ou d'autres membres du public. Ces opinions devraient être présentées dans un rapport préparé par ces conseillers externes et (i) être clairement identifiées comme provenant de conseillers externes ; (ii) être accompagnées par une déclaration détaillée (a) des qualifications et de l'expérience pertinente des conseillers ; et (b) des conflits d'intérêt potentiels des conseillers. Ces rapports devraient être soumis sous forme de déclaration officielle au président de l'équipe d'étude dans les délais indiqués dans le calendrier du PDP.
e. Rapport de l'équipe d'étude. Le président de l'équipe d'étude, en collaboration avec le gestionnaire de problématique, réunit les déclarations régionales, le rapport de consultation publique et les autres informations et rapports, le cas échéant, en un seul document (« rapport préliminaire de l'équipe d'étude ») et distribue le rapport préliminaire de l'équipe d'étude à l'ensemble de l'équipe d'étude dans les délais indiqués dans le calendrier du PDP. L'équipe d'étude organise une réunion finale afin de délibérer sur les problématiques et d'essayer d'obtenir un vote à la majorité qualifiée. Après la réunion finale de l'équipe d'étude, le président de l'équipe d'étude et le gestionnaire de problématique rédigent le rapport final de l'équipe d'étude (le « rapport de l'équipe d'étude ») et le publient en ligne sur le site Web et à l'intention des autres organisations de soutien et comités consultatifs de l'ICANN. Chaque rapport d'équipe d'étude doit comprendre :
1. une déclaration claire de toute position relative à la problématique et votée à la majorité qualifiée (66%) de l'équipe d'étude ;
2. si un vote à la majorité qualifiée n'a pas été acquis, une déclaration claire de toutes les positions adoptées par les membres de l'équipe d'étude soumise dans le délai imparti pour la soumission de rapports de regroupements. Chaque déclaration devrait clairement indiquer (i) les raisons sous-tendant la position et (ii) les organisations régionales ayant adopté la position ;
3. une analyse de la façon dont la problématique affecterait chaque région, y compris tout impact financier sur la région ;
4. une analyse de la période de temps estimée nécessaire pour mettre en œuvre la politique ; et
5. les avis des conseillers externes nommés à l'équipe d'étude par le conseil, accompagnés par une déclaration détaillée des (i) qualifications et de l'expérience pertinente des conseillers ; et (ii) des conflits d'intérêt potentiels des conseillers.
8. Procédure si une équipe d'étude n'est pas établie
a. Si le conseil décide de ne pas réunir d'équipe d'étude, chaque organisation régionale nomme, dans les délais indiqués dans le calendrier du PDP, un représentant pour solliciter les points de vue des régions sur la problématique. Chacun de ces représentants est requis de soumettre une déclaration régionale au gestionnaire de problématique dans les délais indiqués dans le calendrier du PDP.
b. Le conseil peut, à sa discrétion, prendre d'autres mesures d'assistance au PDP, y compris, par exemple, la nomination d'un individu ou d'une organisation particulière pour rassembler des informations sur la problématique ou programmer des réunions de délibération ou d'information. Toutes ces informations sont soumises au gestionnaire de problématique dans les délais indiqués dans le calendrier du PDP.
c. Le conseil demande officiellement au président du GAC de fournir une opinion ou des conseils.
d. Le gestionnaire de problématique rassemble tous les rapports régionaux, le rapport de la consultation publique et autres informations et les réunit (et publie en ligne sur le site Web) en un rapport initial, dans les délais indiqués dans le calendrier du PDP. Par la suite, le gestionnaire de problématique rédige le rapport final conformément au point 9 ci-dessous.
9. Commentaires du public sur le rapport de l'équipe d'étude ou sur le rapport initial
a. Une période de consultation publique (conformément au calendrier du PDP, et généralement d'une durée de 21 jours au moins) est ouverte pour la sollicitation de commentaires sur le rapport de l'équipe d'étude ou le rapport initial. Les commentaires sont reçus de la part des gestionnaires de ccTLD, des autres organisations de soutien, des comités consultatifs et du public. Tous les commentaires doivent être accompagnés du nom de leur auteur, de son expérience pertinente et de son intérêt par rapport à la problématique.
b. À la fin de la période de consultation publique, le gestionnaire de problématique révise les commentaires reçus et peut, à sa discrétion, ajouter des commentaires opportuns au rapport de l'équipe d'étude ou au rapport initial afin de préparer le « rapport final ». Le gestionnaire de problématique n'est pas obligé d'inclure tous les commentaires faits pendant la période de consultation publique, ni d'inclure tous les commentaires par une seule personne ou organisation.
c. Le gestionnaire de problématique prépare le rapport final et le soumet au président du conseil dans les délais indiqués dans le calendrier du PDP.
a. A la réception d'un rapport final, qu'il soit le fruit du travail d'un groupe d'études ou autre, le président du conseil (i) distribuera le rapport final à tous les membres du conseil ; (ii) convoquera une réunion du conseil dans les délais indiqués dans le calendrier du PDP, au cours de laquelle le conseil cherche à parvenir à une recommandation à présenter au Conseil d'administration ; et (iii) envoie officiellement au président du GAC une invitation pour que le GAC offre une opinion ou des conseils. Cette réunion peut être tenue de la manière jugée appropriée par le Conseil, y compris en personne ou par téléconférence. Le gestionnaire de problématique assiste à cette réunion.
b. Le Conseil peut commencer ses délibérations sur la problématique avant la réunion officielle, y compris par le biais de réunions en face à face, de téléconférences, d'échanges de courriers électroniques et de tout autre moyen du choix du conseil.
c. Le Conseil peut, s'il en décide ainsi, solliciter les opinions de conseillers externes lors de la réunion finale. Si le conseil se fie aux opinions de ces conseillers, celles-ci sont (i) incorporées dans le rapport du conseil au Conseil d'administration, (ii) spécifiquement identifiées comme provenant d'un conseiller externe ; et (iii) accompagnées d'une déclaration détaillée (a) des qualifications et de l'expérience pertinente du conseiller ; et (b) des conflits d'intérêt potentiels du conseiller.
Lors de la concertation pour faire ou non une recommandation sur la problématique (une « recommandation du conseil »), le conseil cherche à obtenir un consensus. Si une minorité s'oppose à une position consensuelle, cette minorité prépare et remet au conseil une déclaration expliquant les raisons de cette opposition. Si la discussion du conseil à propos de la déclaration ne résulte pas en un consensus, une recommandation appuyée par le vote de 14 membres ou plus du conseil est réputée refléter le point de vue du conseil et est transmise aux membres en tant que recommandation du conseil. Nonobstant les faits précédemment cités, comme exposé ci-dessous, tous les 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 le cas où une recommandation du conseil est adoptée conformément au point 11, le gestionnaire de problématique doit, dans les sept jours suivant la réunion du conseil, incorporer la recommandation du Conseil avec tous autres points de vue des membres du conseil dans un rapport des membres devant être approuvé par le conseil et soumis par la suite 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 du compte-rendu des délibérations du conseil sur la problématique de la politique (voir point 10), incluant toutes les opinions exprimées au cours de ces délibérations, accompagnées par une description des personnes ayant exprimé ces opinions.
Suite à la soumission du rapport des membres et dans les délais indiqués dans le calendrier du PDP, les membres de la ccNSO ont l'opportunité de voter en faveur ou contre la recommandation du conseil. Les membres votent par voie électronique et leurs votes doivent être déposés au cours d'une période de temps indiquée dans le calendrier du PDP (au moins 21 jours).
Dans le cas où au moins 50% des membres de la ccNSO déposent des votes pendant la période de vote, le résultat du vote est utilisé sans autre forme de procès. Dans le cas où moins de 50% des membres de la ccNSO déposent des votes au cours de la première session de vote, cette première session est reconduite et les résultats d'une deuxième session de vote finale, organisée suite à un préavis d'au moins trente jours aux membres de la ccNSO, seront utilisés si au moins 50% des membres de la ccNSO déposent des votes. Dans le cas 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 transmise au Conseil d'administration conformément au point 14 ci-dessous comme recommandation de la ccNSO.
14. Rapport au Conseil d'administration
Dans les sept jours suivant la recommandation de la ccNSO faite conformément au point 13, le gestionnaire de problématique incorpore la recommandation de la ccNSO dans un rapport devant être approuvé par le conseil et par la suite soumis au Conseil d'administration (le « rapport au Conseil d'administration »). Le rapport au Conseil d'administration doit contenir au minimum les éléments suivants :
a. une déclaration claire de la recommandation de la ccNSO ;
15. Vote du Conseil d'administration
a. Le Conseil d'administration se réunit pour discuter de la recommandation de la ccNSO le plus rapidement possible après la réception du rapport du gestionnaire de problématique, 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 telle politique n'est pas dans le meilleur intérêt de la communauté de l'ICANN ou de l'ICANN.
1. Dans le cas où le Conseil d'administration décide de ne pas suivre la recommandation de la ccNSO, le Conseil d'administration doit (i) exprimer les raisons de cette décision de ne pas agir selon la recommandation de la ccNSO dans un rapport adressé au conseil (la « déclaration du Conseil d'administration ») ; et (ii) soumettre la déclaration du Conseil d'administration au conseil.
2. Le conseil discute la déclaration du Conseil d'administration 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 décide quelle méthode (par ex. par téléconférence, courrier électronique ou autre) utiliser pour discuter avec le conseil. Les discussions sont tenues de bonne foi, dans les plus brefs délais et de manière opportune et efficace afin de trouver une solution mutuellement acceptable.
3. À la fin des discussions entre le conseil et le Conseil d'administration, le conseil se réunit pour confirmer ou modifier sa recommandation de conseil. Une recommandation appuyée par le vote de 14 membres ou plus du conseil sera réputée refléter le point de vue du conseil (la « recommandation complémentaire » du conseil). Cette recommandation complémentaire est transmise aux membres dans un rapport complémentaire des membres, en incluant une explication de la recommandation complémentaire. Les membres ont l'opportunité de voter en faveur ou contre la recommandation complémentaire selon les mêmes modalités décrites au point 13. Dans le cas ou plus de 66% des votes exprimés par les membres de la ccNSO pendant la période de vote sont en faveur de la recommandation complémentaire, cette recommandation est alors transmise au Conseil d'administration en tant que recommandation complémentaire de la ccNSO et le Conseil d'administration adopte la recommandation, à moins qu'un vote de plus de 66% du Conseil d'administration ne décide que l'acceptation d'une telle politique constituerait une violation des devoirs fiduciaires du Conseil d'administration envers l'entreprise.
4. Dans le cas où le Conseil d'administration n'accepte pas la recommandation complémentaire de la ccNSO, il énonce ses motifs sa décision finale (« déclaration complémentaire du Conseil d'administration »).
5. Dans le cas 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 la problématique concernée 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 la problématique estimée acceptable par le Conseil d'administration.
16. Mise en œuvre de la politique
A l'adoption par le Conseil d'administration d'une recommandation de la ccNSO ou d'une recommandation complémentaire de la ccNSO, le Conseil d'administration enjoint ou donne l'autorisation au personnel de l'ICANN, selon le cas, de mettre en œuvre de la politique.
Concernant chaque ccPDP pour lequel un rapport sur la problématique est demandé (voir point 1), l'ICANN maintient sur le site Web, une page Web de l'état d'avancement de chaque ccPDP, comprenant une liste détaillée des dates pertinentes au ccPDP, en proposant également des liens vers les documents suivants, dans la mesure où ces documents ont été préparés conformément au ccPDP :
a. rapport sur la problématique ;
c. rapport de consultation publique ;
d. déclaration(s) régionale(s) ;
e. rapport préliminaire de l'équipe d'étude ;
f. rapport de l'équipe d'étude ;
j. rapport au Conseil d'administration ;
k. déclaration du Conseil d'administration
En outre, l'ICANN publie sur le site Web les commentaires reçus sous forme électronique écrite et suggérant spécifiquement le lancement d'un ccPDP.
Annexe C : Champ d'action de la ccNSO
Cette annexe décrit le champ d'action et les principes et méthodes d'analyse à utiliser pour tout développement ultérieur de l'étendue du rôle d'élaboration de politiques de la ccNSO. Tel que stipulé à l'Article IX, Section 6(2) des règlements, ce champ d'action est défini selon les procédures du ccPDP.
L'étendue de l'autorité et des responsabilités de la ccNSO doit reconnaître la relation complexe entre l'ICANN et les gestionnaires/registres de ccTLD concernant les problématiques de politiques. Cette annexe aide le ccNSO, le conseil de la ccNSO, le Conseil d'administration et l'équipe de l'ICANN à déterminer les problématiques de politiques mondiales pertinentes.
Domaines des politiques
Le rôle de la ccNSO en matière de politiques devrait 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. un 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 du registre de ccTLD, ainsi qu'à un niveau supérieur (fonction IANA et serveurs racines) et à des niveaux inférieurs de l'hiérarchie du DNS. Ce mécanisme, comme le souligne la norme RFC 1591, est récursif :
Il n'existe aucune exigence pour les sous-domaines des domaines de premier niveau au-delà des exigences relatives aux domaines de plus haut niveau en tant que tels. Cela signifie que les exigences de cette note sont appliquées de façon récursive. Plus particulièrement, tous les sous-domaines sont autorisés à gérer leurs propres serveurs de noms de domaine, y fournissant toutes informations que le gestionnaire du sous-domaine juge adaptée (dans la mesure où elles sont véridiques et correctes).
Les fonctions principales
1. Fonction de saisie des données (DEF) :
À un niveau plus détaillé, la première fonction (saisie et maintenance des données dans une base de données) devrait être entièrement définie par une politique de nommage. Cette politique de nommage doit spécifier les règles et les conditions :
(a) sous lesquelles les données seront recueillies 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 titulaire de nom de domaine à un autre titulaire de nom de domaine ou un changement 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 du Whois ou de serveurs de noms).
2. La fonction de serveur de noms (NSF)
La fonction de serveur de noms implique des problématiques d'interopérabilité et de stabilité essentielles au cœur du système de noms de domaines (DNS). L'importance de cette fonction s'étend aux serveurs de noms au niveau des ccTLD, mais également aux serveurs racines (et au système de serveurs racines) et aux serveurs de noms à des niveaux inférieurs.
De par leur propre nature et du fait de considérations d'interopérabilité et de stabilité, les serveurs de noms fonctionnant correctement sont d'une importance cruciale pour les particuliers, ainsi que pour les communautés Internet locales et mondiales.
Concernant la fonction du serveur de noms, de ce fait, des politiques doivent être définies et établies. La plupart des parties impliquées, y compris la majorité des registres de ccTLD, ont consenti au besoin de politiques communes dans ce domaine en adhérant aux normes RFC pertinentes, la RFC 1591 entre autres.
Rôles respectifs concernant les politiques, les responsabilités et les obligations
Il est dans l'intérêt de l'ICANN et des gestionnaires de ccTLD d'assurer le fonctionnement stable et cohérent du système de noms de domaine (DNS). L'ICANN et les registres de ccTLD ont chacun un rôle distinct à jouer dans ce domaine, qui peut être défini par les politiques pertinentes. Le champ d'action de la ccNSO ne peut être établi sans atteindre une compréhension commune de la répartition de l'autorité entre l'ICANN et les registres de ccTLD.
Trois rôles se distinguent, auxquels une certaine responsabilité doit être affectée concernant toute problématique donnée :
- Rôle stratégique : à savoir, la capacité et le pouvoir de définir une politique ;
- Rôle exécutif : à savoir, la capacité et le pouvoir d'agir pour la mise en œuvre de la politique ;
- Rôle de responsabilité : à savoir, la capacité et le pouvoir de tenir l'entité responsable en termes d'exercice de son pouvoir.
D'abord, la responsabilité présuppose une politique et ceci détermine le rôle de la politique. Selon la problématique à traiter, ceux qui sont impliqués dans la définition de cette politique doivent être déterminés et définis. Deuxièmement, ceci présuppose un rôle exécutif définissant le pouvoir de mettre en œuvre et 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. déterminer et identifier les domaines de politiques spécifiques ;
2. définir et déterminer les rôles concernant ces domaines de politiques spécifiques.
Cette annexe définit le champ d'action de la ccNSO par rapport à l'élaboration de politiques. Le champ d'action est limité au rôle stratégique du processus d'élaboration de politiques (PDP) de la ccNSO pour les fonctions et les niveaux clairement indiqués ci-dessous. Il est prévu que la précision des affectations des rôles stratégiques, exécutifs et de responsabilité décrites ci-dessous sera examinée dans le cadre d'un processus ccPDP de définition du champ d'action.
Fonction de serveur de noms (par rapport aux ccTLD)
Niveau 1 : serveurs de noms racines
Rôle stratégique : IETF, RSSAC (ICANN)
Rôle exécutif : opérateurs du système de serveurs racine
Rôle de responsabilité : RSSAC (ICANN), (protocole d'entente entre le Ministère du Commerce des États-Unis et l'ICANN)Niveau 2 : serveurs de noms de registres ccTLD concernant l'interopérabilité
Rôle stratégique : processus d'élaboration de politiques de la ccNSO (ICANN), pour les meilleures pratiques un processus ccNSO peut être organisé
Rôle exécutif : gestionnaire de 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 stratégique : gestionnaire de ccTLD, IETF (RFC)
Rôle exécutif : titulaire de nom de domaine
Rôle de responsabilité : gestionnaire de ccTLD
Fonction de saisie des données (ccTLD)
Niveau 1 : registre au niveau de la racine
Rôle stratégique : processus d'élaboration des politiques de la ccNSO (ICANN)
Rôle exécutif : ICANN (IANA)
Rôle de responsabilité : communauté ICANN, gestionnaires de ccTLD, Ministère du Commerce des Etats-Unis, (les gouvernements nationaux dans certains cas)Niveau 2 : registre de ccTLD
Rôle stratégique : communauté Internet locale, incluant le gouvernement local et/ou le gestionnaire de ccTLD en fonction de la structure locale
Rôle exécutif : gestionnaire de ccTLD
Rôle de responsabilité : communauté Internet locale, incluant les gouvernements nationaux dans certains casNiveau 3 : niveaux secondaires et inférieurs
Rôle stratégique : titulaire de nom de domaine
Rôle exécutif : titulaire de nom de domaine
Rôle de responsabilité : titulaire de nom de domaine, utilisateurs de noms de domaine de niveau inférieur