STATUTO DI INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS | Emendamento del 15 febbraio 2008
Note: this page is an archive of an old version of the bylaws. The current ICANN bylaws are always available at: https://www.icann.org/resources/pages/governance/bylaws-en
Azienda no-profit californiana del settore pubblico
Emendamento del 15 febbraio 2008
| Nota sulle traduzioni La versione originale del presente documento è in lingua inglese ed è disponibile all’indirizzo http://www.icann.org/en/general/bylaws.htm. In caso di differenze di interpretazione o se si ha il dubbio che esistano differenze fra l’edizione tradotta del presente documento e l’originale, farà fede il testo originale. |
ARTICOLO I: DICHIARAZIONE PROGRAMMATICA E VALORI
ARTICOLO II: POTERI
ARTICOLO III: TRASPARENZA
ARTICOLO IV: RESPONSABILITÀ E RIESAME
ARTICOLO V: OMBUDSMAN
ARTICOLO VI: CONSIGLIO DIRETTIVO
ARTICOLO VII: COMITATO PER L'ASSEGNAZIONE DELLE NOMINE
ARTICOLO VIII: ADDRESS SUPPORTING ORGANIZATION
ARTICOLO IX: COUNTRY-CODE NAMES SUPPORTING ORGANIZATION
ARTICOLO X: GENERIC NAMES SUPPORTING ORGANIZATION
ARTICOLO XI: COMITATI CONSULTIVI
ARTICOLO XI-A: ALTRI MECCANISMI DI CONSULTAZIONE
ARTICOLO XII: COMITATI DEL CONSIGLIO E TEMPORANEI
ARTICOLO XIII: FUNZIONARI
ARTICOLO XIV: RIMBORSI PER DIRETTORI, FUNZIONARI, DIPENDENTI E ALTRI AGENTI
ARTICOLO XV: DISPOSIZIONI GENERALI
ARTICOLO XVI: ASPETTI FISCALI
ARTICOLO XVII: MEMBRI
ARTICOLO XVIII: SEDI E MARCHIO
ARTICOLO XIX: EMENDAMENTI
ARTICOLO XX: ARTICOLO DI TRANSIZIONE
APPENDICE A: PROCESSO GNSO PER LO SVILUPPO DI POLITICHE
APPENDICE B: PROCESSO ccNSO PER LO SVILUPPO DI POLITICHE
APPENDICE C: AMBITO DI ATTIVITÀ DI ccNSO
ARTICOLO I: DICHIARAZIONE PROGRAMMATICA E VALORI
Sezione 1. DICHIARAZIONE PROGRAMMATICA
La funzione di Internet Corporation for Assigned Names and Numbers ("ICANN") consiste nel coordinare nel complesso i sistemi globali degli identificatori univoci di Internet e, in particolare, di garantirne il funzionamento stabile e sicuro. In particolar modo, ICANN:
1. Coordina l'allocazione e assegnazione dei tre tipi di identificatori univoci di Internet, ovvero
a. Nomi di dominio (i quali costituiscono un sistema denominato "DNS");
b. Indirizzi IP (Internet Protocol) e numeri del sistema autonomo ("AS", Autonomous System);
2. Coordina il funzionamento e l'evoluzione del sistema di server dei nomi DNS principale.
3. Coordina lo sviluppo di politiche ragionevoli e appropriate rispetto a queste funzioni tecniche.
Nel perseguimento della propria funzione, le decisioni e le azioni intraprese da ICANN sono orientate ai seguenti valori:
1. Preservare e migliorare i livelli di stabilità, affidabilità e sicurezza operativa, nonché l'interoperabilità globale di Internet.
2. Rispettare la creatività, l'innovazione e il flusso di informazioni resi possibili da Internet, limitando le attività di ICANN a tutti quegli ambiti coinvolti negli obiettivi aziendali che necessitano o beneficiano in larga misura del coordinamento globale.
3. Nella misura fattibile e appropriata, delegare le funzioni di coordinamento o riconoscere il ruolo delle politiche delle altre entità responsabili che riflettono gli interessi degli interlocutori.
4. Perseguire e supportare una diffusa partecipazione informata che rifletta la varietà funzionale, geografica e culturale di Internet a tutti i livelli dei processi di sviluppo di politiche e decision-making.
5. Nella misura fattibile e appropriata, affidarsi ai meccanismi di mercato per promuovere e sostenere un ambiente competitivo.
6. Introdurre e promuovere la concorrenza nel campo della registrazione dei nomi di dominio, dove possibile e auspicabile nell'interesse pubblico.
7. Utilizzare meccanismi di sviluppo delle politiche aperti e trasparenti, con l'obiettivo di (i) promuovere l'elaborazione di decisioni ponderate basate sulla consulenza degli esperti e (ii) assicurare la partecipazione dei principali enti interlocutori al processo di sviluppo delle politiche.
8. Elaborare decisioni ricorrendo all'applicazione neutrale e obiettiva delle politiche documentate, nel rispetto dei criteri di integrità e correttezza.
9. Agire secondo tempistiche adeguate alle esigenze dettate da Internet, avvalendosi per il processo di decision-making dell'input dei principali enti interlocutori.
10. Mantenersi responsabile nei confronti della comunità Internet attraverso meccanismi che migliorano l'efficacia di ICANN.
11. Pur conservando una matrice privata, riconoscere la responsabilità dei governi e delle pubbliche autorità nell'ambito delle politiche pubbliche e tenere nella dovuta considerazione i suggerimenti degli stessi.
Questi valori sono deliberatamente espressi in termini generali, affinché possano fornire indicazioni utili e pertinenti per la più ampia varietà di circostanze possibili. Non trattandosi di rigide prescrizioni, le specifiche modalità di applicazione, singola o in toto, di questi valori a ogni nuova situazione dipenderanno necessariamente da numerosi fattori non del tutto prevedibili o enumerabili; trattandosi inoltre di indicazioni di principio, piuttosto che pratiche, inevitabilmente si presenteranno situazioni in cui risulterà impossibile attenersi a tutti gli undici valori contemporaneamente. Qualsiasi organismo ICANN autore di un suggerimento o di una decisione dovrà stabilire a proprio giudizio quali siano i valori più rilevanti e in che modo si applichino alle specifiche circostanze del caso in questione, nonché conciliare i valori in contrasto in maniera appropriata e difendibile, qualora si renda necessario.
Ove non sia disposto diversamente dagli articoli di incorporazione o dal presente Statuto, i poteri di ICANN saranno esercitati dal Consiglio, che controlla inoltre le proprietà dell'azienda e ne conduce o dirige attività e trattative. In merito alle questioni riconducibili a quanto previsto nell'Articolo III, Sezione 6, il Consiglio può agire unicamente in virtù del voto di maggioranza di tutti i membri che lo compongono. In merito a tutte le altre questioni, fatto salvo per quanto diversamente disposto dal presente Statuto o dalle leggi in vigore, il Consiglio può agire in virtù del voto di maggioranza dei membri presenti alle riunioni annuali, ordinarie o straordinarie del Consiglio. I riferimenti ai voti del Consiglio contenuti nel presente Statuto si riferiscono al voto dei soli membri presenti alle riunioni che abbiano raggiunto il quorum, salvo quanto diversamente indicato con l'espressione "tutti i membri del Consiglio".
ICANN non dovrà agire in qualità di Registro di sistemi dei nomi di dominio o Registrar o Registro di indirizzi IP in competizione con gli enti influenzati dalle politiche ICANN. La presente Sezione non impedisce in alcun modo a ICANN di compiere tutte le azioni necessarie per proteggere la stabilità operativa di Internet in caso di fallimento finanziario di un Registro o Registrar o di qualsiasi altra emergenza.
Sezione 3. TRATTAMENTO NON DISCRIMINATORIO
ICANN non dovrà applicare i propri standard, politiche, procedure o prassi in maniera iniqua o riservare trattamenti diversi ai singoli interlocutori, salvo in presenza di giustificazioni sostanziali e ragionevoli, come ad esempio l'incoraggiamento di una efficace concorrenza.
ICANN e i relativi enti costitutivi dovranno operare in maniera quanto più possibile aperta e trasparente, nel rispetto delle procedure finalizzate a garantire la correttezza.
ICANN dovrà mantenere un sito Internet (il "sito Web") pubblicamente accessibile, con inclusi, in via esemplificativa, (i) un calendario delle riunioni programmate del Consiglio, delle Organizzazioni di sostegno e dei Comitati consultivi; (ii) una scheda relativa alle questioni di sviluppo delle politiche in corso, incluse le informazioni sulle tempistiche e lo stato attuale; (iii) note e ordini del giorno delle riunioni, come descritto di seguito; (iv) informazioni su budget, controlli annuali e contribuenti finanziari di ICANN, con ammontare del contributo di ognuno, e questioni correlate; (v) informazioni sulla disponibilità dei meccanismi di responsabilità, incluse le attività di revisione, revisione indipendente e Ombudsman, nonché informazioni sul risultato di specifiche richieste e reclami relativi al ricorso a tali meccanismi; (vi) annunci riguardanti le attività ICANN di interesse per vasti segmenti della comunità ICANN; (vii) commenti ricevuti dalla comunità riguardo le politiche sviluppate e altre questioni; (viii) informazioni sulle riunioni e i forum pubblici ICANN; (ix) altre informazioni di interesse per la comunità ICANN.
Sezione 3. RESPONSABILE DELLA PARTECIPAZIONE PUBBLICA
Dovrà essere designata la figura di Responsabile della partecipazione pubblica, altrimenti definita dal Presidente, che si occuperà sotto la direzione di quest'ultimo di coordinare i vari aspetti della partecipazione pubblica in ICANN, incluso il sito Web e diversi altri mezzi per la comunicazione e la ricezione di input dalla comunità generale di utenti Internet.
Sezione 4. NOTE E ORDINI DEL GIORNO DELLE RIUNIONI
Almeno sette giorni prima delle riunioni del Consiglio (o in caso di impossibilità, con il massimo anticipo possibile), sarà necessario pubblicare una nota delle riunioni stesse, unita a un ordine del giorno, per quanto noto.
Sezione 5. VERBALI E RELAZIONI PRELIMINARI
1. Tutti i verbali delle riunioni del Consiglio e delle Organizzazioni di sostegno (e relativi consigli) dovranno essere approvati tempestivamente dall'organismo di origine e forniti al Segretario di ICANN per la pubblicazione sul sito Web.
2. Entro i cinque (5) giorni lavorativi successivi a ogni riunione (calcolati in base all'ora locale dell'area geografica della sede ICANN principale), ogni azione intrapresa dal Consiglio dovrà essere resa nota al pubblico in una relazione preliminare pubblicata sul sito Web, fatto salvo per le azioni relative a questioni di personale o di impiego, questioni legali (nella misura in cui il Consiglio ritenga opportuno o necessario proteggere gli interessi di ICANN), questioni che ICANN non è autorizzata a divulgare per disposizioni di legge o contratto e ogni altra questione che il Consiglio giudichi inopportuno divulgare, previa votazione dei tre quarti (3/4) dei Direttori presenti e votanti in sede di riunione. Per le questioni non divulgate su decisione del Consiglio, quest'ultimo è tenuto a fornire nella relazione preliminare una descrizione generale dei motivi alla base di tale decisione.
3. Entro il giorno successivo alla data dell'approvazione formale del Consiglio (o qualora si tratti di un giorno non lavorativo, calcolato in base all'ora locale dell'area geografica della sede ICANN principale, entro il giorno lavorativo immediatamente successivo), i verbali dovranno essere resi noti al pubblico tramite il sito Web, fatto salvo per i verbali relativi a questioni di personale o di impiego, questioni legali (nella misura in cui il Consiglio ritenga opportuno o necessario proteggere gli interessi di ICANN), questioni che ICANN non è autorizzata a divulgare per disposizioni di legge o contratto e ogni altra questione che il Consiglio giudichi inopportuno divulgare, previa votazione dei tre quarti (3/4) dei Direttori presenti e votanti in sede di riunione. Per le questioni non divulgate su decisione del Consiglio, quest'ultimo è tenuto a fornire nei verbali una descrizione generale dei motivi alla base di tale decisione.
Sezione 6. NOTE E COMMENTI SULLE AZIONI IN MATERIA DI POLITICHE
1. In merito all'opportunità vagliata dal Consiglio di adottare politiche in grado di influire in maniera sostanziale sulla capacità operativa di Internet o di terze parti, inclusa l'imposizione di tariffe o quote, ICANN sarà tenuta a:
a. pubblicare sul sito Web una nota pubblica che illustri le politiche al vaglio per l'eventuale adozione, con relative motivazioni, almeno ventuno giorni prima (o più, se possibile) di ogni eventuale azione del Consiglio;
b. concedere agli interlocutori una ragionevole opportunità di commentare l'adozione delle politiche proposte, nonché di accedere e rispondere ai commenti altrui, prima che il Consiglio intraprenda qualsiasi azione;
c. nei casi in cui l'esercizio delle politiche influenzi aspetti di pubblico interesse, richiedere l'opinione del Comitato Consultivo Governativo e tenere nella dovuta considerazione qualsiasi indicazione puntualmente presentata da tale comitato, di sua spontanea iniziativa o su richiesta del Consiglio.
2. Qualora sia fattibile e coerente con il processo di sviluppo delle politiche in questione, dovrà tenersi un incontro pubblico per la discussione delle politiche proposte, come descritto nella Sezione 6(1)(b) di questo Articolo, prima di ogni azione definitiva del Consiglio.
3. Dopo aver intrapreso un'azione relativa alle politiche disciplinate da questa Sezione, il Consiglio è tenuto a riportare nei verbali di riunione le motivazioni alla base delle azioni intraprese, il voto espresso da ciascun Direttore a riguardo di tali azioni e la dichiarazione distinta dei Direttori che ne desiderino la pubblicazione.
Sezione 7. TRADUZIONE DEI DOCUMENTI
Nella misura appropriata e consentita dal budget di ICANN, quest'ultima è tenuta a facilitare la traduzione della versione definitiva dei documenti nelle lingue appropriate.
ARTICOLO IV: RESPONSABILITÀ E RIESAME
Nella realizzazione dell'obiettivo dichiarato nel presente Statuto, ICANN è responsabile nei confronti della comunità di operare in maniera conforme alle disposizioni dello Statuto e con il dovuto riguardo verso i valori nello stesso menzionati nell'Articolo I. Le disposizioni del presente Articolo riguardo la creazione di processi di revisione e riesame indipendente delle azioni intraprese da ICANN e di riesame periodico della struttura e delle procedure di ICANN hanno l'obiettivo di rafforzare i meccanismi di responsabilità menzionati nel presente Statuto, incluse le disposizioni in materia di trasparenza di cui all'Articolo III , nonché i meccanismi del Consiglio e gli altri meccanismi di selezione menzionati nel presente Statuto.
1. ICANN dovrà istituire un processo tramite il quale ogni persona o ente materialmente influenzato dalle azioni intraprese da ICANN possa richiedere il riesame o la revisione di tali azioni da parte del Consiglio.
2. Ogni persona o ente può presentare una richiesta per la revisione o il riesame di un'azione intrapresa o ignorata da ICANN ("Richiesta di revisione") nella misura in cui tale persona o ente sia stato penalizzato da:
a. una o più azioni intraprese o ignorate dal personale in contraddizione con le politiche di ICANN; oppure
b. una o più azioni intraprese o ignorate dal Consiglio di ICANN senza considerare informazioni materiali, a eccezione del caso in cui l'interlocutore che presenta la richiesta non abbia usufruito della possibilità di sottoporre tali informazioni all'attenzione del Consiglio al momento dell'attuazione o del rifiuto dell'azione.
3. Dovrà essere presente un Comitato del Consiglio composto da almeno tre Direttori con il compito di prendere in considerazione ed esaminare tali richieste ("Comitato di revisione"). Il Comitato di revisione avrà il potere di:
a. valutare le richieste di revisione o riesame;
b. stabilire l'opportunità di bloccare l'azione contestata in attesa della risoluzione della richiesta;
c. condurre tutte le indagini ritenute appropriate;
d. richiedere ulteriori documenti scritti all'interlocutore o a terze parti;
e. formulare un suggerimento per il Consiglio direttivo in merito alla richiesta.
4. ICANN assorbirà i normali costi amministrativi associati al processo di revisione, riservandosi il diritto di recuperare dall'interlocutore che avanza richiesta di revisione o riesame gli eventuali costi di natura straordinaria. Nei casi in cui sia possibile prevedere tali costi straordinari, le relative stime e i motivi per cui tali costi sono giudicati necessari e opportuni per la valutazione della Richiesta di revisione dovranno essere comunicati all'interlocutore richiedente, il quale potrà decidere se ritirare la richiesta di revisione o acconsentire a farsi carico dei costi in questione.
5. Le Richieste di revisione devono essere inviate a un indirizzo e-mail designato dal Comitato di revisione del Consiglio entro trenta giorni a partire da:
a. per le richieste riguardanti azioni del Consiglio, la data di pubblicazione delle informazioni relative all'azione del Consiglio contestata all'interno di una relazione preliminare o nei verbali delle riunioni del Consiglio; oppure
b. per le richieste riguardanti azioni del personale, la data in cui l'interlocutore che presenta la richiesta è venuto a conoscenza, o presumibilmente sarebbe dovuto venire a conoscenza, dell'azione del personale contestata; oppure
c. per le richieste riguardanti azioni ignorate dal Consiglio o dal personale, la data in cui il diretto interessato ha ragionevolmente dedotto, o avrebbe dovuto dedurre, che l'azione non sarebbe stata intrapresa in maniera puntuale.
6. Tutte le richieste di revisione devono includere le informazioni richieste dal Comitato di revisione, tra cui le seguenti:
a. nome, indirizzo e informazioni di contatto del richiedente, incluso l'indirizzo postale e di posta elettronica;
b. l'azione intrapresa o ignorata da ICANN di cui si desidera la revisione o il riesame;
d. la descrizione delle conseguenze di tale azione sul richiedente;
e. la misura in cui, secondo il richiedente, l'azione contestata penalizza anche terze parti;
f. l'eventuale richiesta di un blocco temporaneo dell'azione contestata, unita a una descrizione delle conseguenze che risulterebbero dal proseguimento di tale azione;
g. nel caso di azioni intraprese o ignorate dal personale, una spiegazione dettagliata delle informazioni presentate al personale e dei motivi per cui tale azione è stata intrapresa o ignorata in maniera incoerente rispetto alle politiche di ICANN;
h. nel caso di azioni intraprese o ignorate dal Consiglio, una spiegazione dettagliata delle informazioni materiali non considerate dal Consiglio e, qualora tali informazioni non siano state presentate al Consiglio, i motivi per cui la parte richiedente non abbia provveduto in tal senso prima della decisione del Consiglio di intraprendere o ignorare l'azione;
i. i provvedimenti specifici richiesti a ICANN, ovvero la revoca, l'annullamento o la modifica dell'azione, oppure le azioni specifiche da intraprendere;
j. gli ambiti in cui intraprendere l'azione richiesta;
k. eventuali documenti che il richiedente desidera inviare a sostegno della propria richiesta.
7. Le Richieste di revisione dovranno essere pubblicate sul sito Web.
8. Il Comitato di revisione avrà il potere di considerare nello stesso procedimento le Richieste di revisione di diversi interlocutori, a condizione che (i) le richieste riguardino la stessa azione generica intrapresa o ignorata e (ii) gli interlocutori che inviano le Richieste di revisione risultino penalizzati in maniera analoga da tale azione.
9. Il Comitato di revisione dovrà tempestivamente esaminare le richieste di revisione ricevute e annunciare entro trenta giorni la propria intenzione di respingere o accettare la richiesta in questione. Tale annuncio sarà pubblicato sul sito Web.
10. L'annuncio del Comitato di revisione riguardo la decisione di respingere una Richiesta di revisione deve contenere una spiegazione dei motivi alla base di tale decisione.
11. Il Comitato di revisione può richiedere ulteriori informazioni o chiarimenti all'interlocutore che presenta la Richiesta di revisione.
12. Il Comitato di revisione può richiedere al personale ICANN un'opinione in merito, che dovrà essere resa nota tramite la pubblicazione sul sito Web.
13. Qualora il Comitato di revisione necessiti di informazioni aggiuntive, può organizzare con l'interlocutore che richiede la revisione un incontro telefonico, tramite e-mail o, se possibile per l'interlocutore, di persona. Qualora le informazioni raccolte durante questo incontro risultino rilevanti per un eventuale suggerimento da parte del Comitato di revisione, quest'ultimo dovrà renderlo noto nel suggerimento stesso.
14. Il Comitato di revisione può inoltre richiedere informazioni attinenti alla richiesta a terze parti. Qualora le informazioni raccolte risultino rilevanti per un eventuale suggerimento da parte del Comitato di revisione, quest'ultimo dovrà renderlo noto nel suggerimento stesso.
15. Il Comitato di revisione dovrà agire nei confronti di una Richiesta di revisione sulla base della registrazione scritta pubblicamente accessibile, che include le informazioni fornite dall'interlocutore che richiede la revisione, dal personale ICANN e da eventuali terze parti.
16. Per evitare qualsivoglia abuso nei confronti del processo di revisione, il Comitato di revisione può respingere ogni richiesta che risulti ripetitiva, frivola, non degna di nota o comunque inammissibile o nel caso in cui l'interlocutore sia stato informato ma non abbia partecipato alla discussione pubblica sull'azione contestata, qualora prevista, durante il periodo disponibile. Analogamente, il Comitato di revisione può respingere una richiesta nel caso in cui il richiedente non sia in grado di dimostrarsi potenzialmente penalizzato dall'azione di ICANN.
17. Il Comitato di revisione dovrà presentare al Consiglio un suggerimento finale riguardo una Richiesta di revisione entro novanta giorni dalla ricezione di quest'ultima, qualora sia possibile; in caso contrario, il Comitato di revisione dovrà riferire al consiglio i motivi della mancata presentazione di tale suggerimento, unitamente a una stima il più possibile precisa dei tempi necessari per produrlo. Il suggerimento finale sarà pubblicato sul sito Web.
18. Il Consiglio non dovrà necessariamente attenersi ai suggerimenti del Comitato di revisione. La decisione finale del Consiglio dovrà essere resa pubblica all'interno della relazione preliminare e dei verbali relativi alla riunione del Consiglio in cui viene decisa l'azione.
19. Il Comitato di revisione dovrà presentare una relazione al Consiglio su base annua, la quale dovrà necessariamente contenere le seguenti informazioni sull'anno precedente:
a. il numero e la natura generale delle richieste di revisione ricevute;
b. il numero delle richieste di revisione per cui il Comitato ha intrapreso un'azione;
c. il numero delle richieste di revisione rimaste in sospeso al termine dell'anno solare e la durata media di tale sospensione;
d. una descrizione delle richieste di revisione che, al termine dell'anno solare, risultavano in sospeso da più di novanta (90) giorni e i motivi per cui il Comitato non ha intrapreso alcuna azione in relazione a tali richieste;
e. il numero e la natura delle richieste di revisione che il Comitato ha rifiutato di esaminare in quanto non conformi ai criteri delle politiche descritte nel presente Statuto;
f. per le richieste di revisione negate, una spiegazione degli altri meccanismi disponibili per sancire la responsabilità di ICANN nei confronti delle persone materialmente penalizzate dalle decisioni dell'azienda;
g. l'opportunità, stabilita dal Comitato, di rivedere o meno i criteri che rendono possibile richiedere una revisione, oppure di adottare o modificare un altro processo, in modo da assicurare che le persone materialmente influenzate dalle decisioni di ICANN possano accedere a un processo di revisione che garantisca l'aspetto della correttezza, limitando nel contempo le richieste non conformi.
20. Le relazioni annuali dovranno inoltre contenere le informazioni relative agli argomenti elencati al paragrafo 19(a)-(e) di questa Sezione per il periodo a partire dal 1 gennaio 2003.
Sezione 3. REVISIONE INDIPENDENTE DELLE AZIONI DEL CONSIGLIO
1. Oltre al processo di revisione descritto nella Sezione 2 di questo Articolo, ICANN dovrà istituire un processo distinto per la revisione effettuata da terze parti indipendenti delle azioni del Consiglio giudicate da un interlocutore incoerenti con lo Statuto o gli Articoli di incorporazione.
2. Qualsiasi persona materialmente influenzata da una decisione o da un'azione del Consiglio giudicata incoerente con lo Statuto o gli Articoli di incorporazione può richiedere una revisione indipendente di tale decisione o azione.
3. Tali richieste di revisione indipendente dovranno essere presentate a una Commissione di revisione indipendente ("IRP", Independent Review Panel), la quale avrà il compito di confrontare le azioni del Consiglio contestate con lo Statuto e gli Articoli di incorporazione, nonché di dichiarare se il Consiglio abbia agito coerentemente con le disposizioni dello Statuto e degli Articoli di incorporazione.
4. IRP dovrà essere gestita da un provider di servizi di arbitrato internazionale periodicamente incaricato da ICANN ("il Provider IRP") tramite arbitri sotto contratto o nominati da tale provider.
5. Previa approvazione del Consiglio, il Provider IRP dovrà stabilire regole e procedure operative, implementate e coerenti con la presente Sezione 3.
6. Ciascuna delle parti può richiedere che la richiesta di revisione indipendente sia presa in esame da una commissione di tre membri; in assenza di tale richiesta, la questione sarà presa in esame da una commissione di un membro unico.
7. Il Provider IRP dovrà stabilire una procedura per l'assegnazione dei membri a ciascuna commissione; su direttiva di ICANN, il Provider IRP dovrà istituire una commissione permanente per l'esame delle richieste.
a. richiedere ulteriori informazioni scritte all'interlocutore che richiede la revisione, al Consiglio, alle Organizzazioni di sostegno o a terze parti;
b. dichiarare se un'azione sia stata intrapresa o ignorata dal Consiglio in maniera incoerente rispetto allo Statuto o agli Articoli di incorporazione;
c. suggerire al Consiglio di bloccare qualsivoglia azione o decisione o di intraprendere qualsivoglia azione provvisoria, finché il Consiglio non possa rivedere e agire in base all'opinione di IRP.
9. Le persone che ricoprono una posizione o svolgono una funzione ufficiale nella struttura di ICANN non possono partecipare a IRP.
10. Per ridurre al minimo i costi e il carico di lavoro per la revisione indipendente, nella massima misura possibile RP porterà avanti i procedimenti tramite e-mail o, in alternativa, tramite Internet. Ove necessario, IRP può organizzare incontri telefonici.
11. IRP dovrà aderire alle politiche in materia di conflitto di interessi espresse nelle regole e procedure operative del Provider IRP, nella forma approvata dal Consiglio.
12. Le dichiarazioni di IRP dovranno essere in forma scritta. IRP dovrà formulare la propria dichiarazione unicamente in base alla documentazione, ai materiali di supporto e alle argomentazioni presentate dagli interlocutori, nonché designare nello specifico all'interno della dichiarazione stessa l'interlocutore prevalente. In genere, l'interlocutore non prevalente dovrà sostenere tutti i costi del Provider IRP, salvo casi straordinari in cui IRP può disporre nella propria dichiarazione che all'interlocutore prevalente venga assegnata una spesa massima pari alla metà dei costi del Provider IRP in base alle circostanze, incluso l'esame della ragionevolezza delle posizioni delle parti e del loro contributo all'interesse pubblico. Ciascuna parte coinvolta nei procedimenti IRP farà fronte alle proprie spese.
13. Le procedure operative di IRP, come anche le petizioni, i reclami e le dichiarazioni, dovranno essere pubblicate sul sito Web non appena disponibili.
14. A sua discrezione, IRP potrà consentire di mantenere la riservatezza di determinate informazioni contenute nelle richieste, quali ad esempio i segreti commerciali.
15. Ove possibile, il Consiglio prenderà in esame la dichiarazione IRP durante la riunione successiva.
Sezione 4. REVISIONE PERIODICA DI STRUTTURA E ATTIVITÀ ICANN
1. Il Consiglio organizzerà una revisione periodica, se possibile almeno ogni tre anni, delle prestazioni e dell'operatività di ogni Organizzazione di sostegno, Comitato di organizzazione di sostegno, Comitato consultivo (diverso dal Comitato Consultivo Organizzativo) e Comitato per l'assegnazione delle nomine, che verrà effettuata da uno o più enti indipendenti dall'organizzazione oggetto della revisione. L'obiettivo della revisione, da effettuarsi secondo criteri e standard indicati dal Consiglio, è stabilire (i) se l'organizzazione abbia una funzione continuativa nella struttura di ICANN e (ii) in tal caso, se sia auspicabile introdurre modifiche alla struttura o alle attività al fine di migliorare il livello di efficienza. I risultati della revisione dovranno essere pubblicati sul sito Web per consentire al pubblico di esaminarli e commentarli e dovranno essere esaminati dal Consiglio entro la seconda riunione programmata a partire dai 30 giorni successivi alla pubblicazione dei risultati. L'esame da parte del Consiglio include la possibilità di rivedere la struttura o il funzionamento dei settori di ICANN oggetto della revisione previa votazione dei due terzi dei membri del Consiglio.
2. La prima di queste revisioni, da avviare entro il 15 dicembre 2003 e da completare in tempo per l'esame da parte del Consiglio in occasione della riunione annuale di ICANN del 2004, riguarderà il Consiglio della GNSO e il Comitato consultivo del sistema root server di ICANN. La seconda, da avviare entro il 15 novembre 2004 e da completare in tempo per l'esame da parte del Consiglio in occasione della riunione annuale di ICANN del 2005, riguarderà il ccNSO, il relativo Comitato e le organizzazioni designate a discrezione del Consiglio.
3. Il Comitato consultivo governativo dovrà provvedere ai propri meccanismi di revisione.
Sezione 1. FUNZIONE DI OMBUDSMAN
1. La funzione di Ombudsman dovrà essere gestita da un funzionario Ombudsman e occuparsi del supporto del personale nella misura appropriata e fattibile stabilita dal Consiglio. La posizione Ombudsman dovrà essere a tempo pieno e ottenere retribuzioni e benefit adeguati alla funzione, nella misura stabilita dal Consiglio.
2. Il funzionario Ombudsman sarà incaricato dal Consiglio con un contratto iniziale di due anni, che potrà essere rinnovato dal Consiglio.
3. Il funzionario Ombudsman potrà essere licenziato dal Consiglio solo su votazione da parte dei tre quarti (3/4) dei membri totali del Consiglio.
4. Il budget annuale della funzione di Ombudsman verrà stabilito dal Consiglio durante il processo annuale di definizione del budget di ICANN. Il funzionario Ombudsman presenterà una proposta di budget al Presidente, il quale la inserirà in versione integrale e senza modifiche nel budget generale di ICANN suggerito dal Presidente del Consiglio di ICANN. Il presente Articolo non impedisce in alcun modo al Presidente di riferire al Consiglio diversi punti di vista riguardo la sostanza, l'ammontare o altre caratteristiche della proposta di budget presentata dal funzionario Ombudsman.
Il mandato del funzionario Ombudsman è risolvere con approccio neutrale le controversie relative alle questioni per cui le disposizioni delle politiche di revisione espresse nella Sezione 2 dell'Articolo IV o delle politiche di revisione indipendente espresse nella Sezione 3 dell'Articolo IV non sono state invocate. Il compito principale del funzionario Ombudsman è provvedere a una valutazione interna indipendente dei reclami sollevati dai membri della comunità ICANN che ritengono di avere subito un trattamento ingiusto da parte del personale, del Consiglio o di un ente costitutivo di ICANN. Il funzionario Ombudsman sarà garante obiettivo del principio di correttezza e dovrà valutare e, ove possibile, risolvere le accuse di trattamento ingiusto o inappropriato rivolte al personale, al Consiglio o agli enti costitutivi di ICANN, chiarendo i problemi e servendosi di strumenti per la risoluzione dei conflitti quali il patteggiamento, la facilitazione e il ricorso a mediatori diplomatici.
La funzione di Ombudsman avrà il compito di:
1. facilitare la risoluzione giusta, imparziale e tempestiva dei possibili problemi e reclami sollevati dai membri della comunità ICANN (esclusi dipendenti e fornitori di ICANN) in merito a particolari azioni intraprese o ignorate dal Consiglio o dal personale ICANN che non siano state fatte oggetto delle politiche di revisione o revisione indipendente;
2. accettare o rifiutare di prendere provvedimenti nei confronti di un reclamo o una contestazione, sviluppando procedure di esclusione dei reclami infondati, inconsistenti o relativi a interazioni di ICANN con la comunità tali da risultare estranei alla giurisdizione Ombudsman. Inoltre, senza limitare quanto finora sancito, il funzionario Ombudsman non dispone di alcuna autorità per agire in qualsivoglia maniera rispetto a questioni amministrative interne, questioni relative al personale, problemi relativi ai membri del Consiglio o alle relazioni con i fornitori;
3. esercitare il diritto di accedere a tutte le informazioni e le registrazioni necessarie sul personale e gli enti costitutivi di ICANN (ma non di pubblicarle, se riservate), ai fini di valutare il reclamo in questione in ogni sua parte e di contribuire alla risoluzione della controversia, ove possibile (nel solo rispetto dell'obbligo di confidenzialità imposto dall'autore del reclamo o delle altre politiche adottate da ICANN generalmente applicabili in materia di riservatezza delle informazioni);
4. consolidare la conoscenza del programma e delle funzioni Ombudsman per mezzo dell'interazione con la comunità ICANN e la disponibilità online;
5. mantenere un approccio neutrale e indipendente, senza alcun pregiudizio o interesse personale nei confronti di un risultato;
6. rispettare le politiche ICANN in materia di conflitto di interessi e riservatezza delle informazioni.
Sezione 4. INTERAZIONE CON ICANN ED ENTI ESTERNI
1. I dipendenti ICANN, i membri del Consiglio e gli altri membri delle Organizzazioni di sostegno o dei Comitati consultivi non potranno in alcun modo ostacolare o impedire la comunicazione tra il funzionario Ombudsman e la comunità ICANN (inclusi i suoi dipendenti). I dipendenti e i membri del Consiglio di ICANN avranno il compito di indirizzare i membri della comunità che esprimano problemi, preoccupazioni o lamentele su ICANN al funzionario Ombudsman, il quale provvederà a informarli sulle varie opzioni disponibili per l'esame di tali problemi, preoccupazioni o lamentele.
2. Il personale e gli altri membri di ICANN sono tenuti a osservare e rispettare le disposizioni della funzione di Ombudsman in merito alla riservatezza dei reclami ricevuti dalla funzione.
3. Le comunicazioni con il funzionario Ombudsman non avranno alcuna funzione di notifica per ICANN riguardo particolari azioni o cause di azione.
4. Qualora lo ritenga opportuno, il funzionario Ombudsman sarà espressamente autorizzato a sottoporre al Consiglio le relazioni su particolari questioni e relative soluzioni o problemi di risoluzione. In assenza di decisioni contrarie a sola discrezione del funzionario Ombudsman, tali relazioni saranno pubblicate sul sito Web.
5. Il funzionario Ombudsman non potrà intraprendere azioni non autorizzate dal presente Statuto e, in particolare, non dovrà avviare, subentrare o supportare in alcun modo qualsivoglia azione legale contro la struttura, le procedure o i processi di ICANN o qualsiasi comportamento del Consiglio, del personale o degli enti costitutivi di ICANN.
La funzione di Ombudsman dovrà pubblicare ogni anno un'analisi consolidata dei reclami avvenuti nel corso dell'anno e delle relative risoluzioni, nel rispetto degli obblighi e degli aspetti di confidenzialità. Tale relazione annuale dovrà contenere una descrizione di eventuali tendenze o elementi ai reclami ricevuti nel periodo in questione, insieme ai suggerimenti sui possibili provvedimenti da attuare per ridurre al minimo la quantità di reclami per il futuro. La relazione annua sarà pubblicata sul sito Web.
ARTICOLO VI: CONSIGLIO DIRETTIVO
Sezione 1. COMPOSIZIONE DEL CONSIGLIO
Il Consiglio direttivo di ICANN ("Consiglio") dovrà essere composto da quindici membri votanti ("Direttori"). Inoltre, dovranno essere designati sei funzionari di collegamento non votanti ("Funzionari") per gli scopi descritti nella Sezione 9 di questo Articolo. Per determinare il quorum e stabilire la validità delle votazioni indette dal Consiglio di ICANN saranno conteggiati solo i Direttori.
Sezione 2. DIRETTORI E SELEZIONE DEI DIRETTORI; ELEZIONE DI PRESIDENTE E VICEPRESIDENTE
a. Otto membri votanti selezionati dal Comitato per l'assegnazione delle nomine previsto dall'Articolo VII del presente Statuto. Queste posizioni all'interno del Consiglio direttivo sono citate nel presente Statuto come Posizione 1, fino alla Posizione 8.
b. Due membri votanti selezionati dall'organizzazione Address Supporting Organization (ASO) secondo le disposizioni dell'Articolo VIII del presente Statuto. Queste posizioni all'interno del Consiglio direttivo sono citate nel presente Statuto come Posizione 9 e Posizione 10.
c. Due membri votanti selezionati dall'organizzazione Country-Code Names Supporting Organization (ccNSO) secondo le disposizioni dell'Articolo IX del presente Statuto. Queste posizioni all'interno del Consiglio direttivo sono citate nel presente Statuto come Posizione 11 e Posizione 12.
d. Due membri votanti selezionati dall'organizzazione Generic Names Supporting Organization (GNSO) secondo le disposizioni dell'Articolo X del presente Statuto. Queste posizioni all'interno del Consiglio direttivo sono citate nel presente Statuto come Posizione 13 e Posizione 14.
2. Nel tener fede alle proprie responsabilità per l'esercizio delle Posizioni dalla 1 alla 8, il Comitato per l'assegnazione delle nomine dovrà fare il possibile per assicurare che il Consiglio di ICANN presenti una composizione nel complesso diversificata in termini di provenienza geografica, cultura, abilità, esperienza e prospettive, applicando i criteri specificati nella Sezione 3 di questo Articolo. In nessun momento il Comitato per l'assegnazione delle nomine potrà selezionare un Direttore per supplire a una posizione vacante o a un contratto scaduto, qualora questo faccia sì che il totale dei Direttori (escluso il Presidente) cittadini di paesi di una qualsiasi Regione Geografica (come stabilito nella Sezione 5 di questo Articolo) sia superiore a cinque; inoltre, il Comitato per l'assegnazione delle nomine dovrà provvedere alle selezioni in modo tale da garantire sempre la presenza nel Consiglio di almeno un Direttore cittadino di un paese di ciascuna Regione Geografica di ICANN.
3. Nel tener fede alle proprie responsabilità per l'esercizio delle Posizioni dalla 9 alla 14, le Organizzazioni di sostegno dovranno fare il possibile per assicurare che il Consiglio di ICANN presenti una composizione nel complesso diversificata in termini di provenienza geografica, cultura, abilità, esperienza e prospettive, applicando i criteri specificati nella Sezione 3 di questo Articolo. In nessun momento un'organizzazione di sostegno potrà selezionare due Direttori cittadini dello stesso paese o di paesi situati nella stessa Regione Geografica.
4. Ogni anno, il Consiglio dovrà scegliere un Presidente e un Vicepresidente fra tutti i Direttori, escluso il Presidente.
Sezione 3. CRITERI DI SELEZIONE DEI DIRETTORI
I Direttori di ICANN dovranno essere:
1. Persone affermate con caratteristiche di integrità, obiettività e intelligenza, dotate di buon senso e apertura mentale, nonché della capacità comprovata di elaborare decisioni di gruppo ponderate;
2. Persone votate al successo di ICANN, consapevoli degli obiettivi di quest'ultima e del potenziale impatto delle sue decisioni sulla comunità Internet globale;
3. Persone in grado di rappresentare all'interno del Consiglio la più ampia diversità culturale e geografica, nel rispetto degli altri criteri menzionati in questa Sezione;
4. Persone che, nel complesso, conoscono il funzionamento di registri e registrar gTLD, registri ccTLD, registri di indirizzi IP, protocolli e standard tecnici di Internet, procedure per lo sviluppo di criteri, tradizioni legali e interesse pubblico, oltre a conoscere l'ampia gamma di utenti Internet aziendali, privati, del mondo accademico e non commerciali;
5. Persone desiderose di operare come volontari, senza ricevere compensi al di fuori del rimborso di talune spese;
6. Persone in grado di operare e comunicare nella lingua inglese scritta e parlata.
Sezione 4. ULTERIORI QUALIFICHE
1. Nonostante quanto altrimenti previsto nel presente Statuto, nessun funzionario di governo nazionale o ente multinazionale istituito da trattati o altri accordi tra governi nazionali potrà ricoprire la posizione di Direttore. Nel presente Statuto, con il termine "funzionario" si intende una persona (i) che ricopra una funzione elettiva di governo oppure (ii) che lavori per tale governo o ente multinazionale e la cui funzione principale all'interno di questi sia sviluppare o influenzare le politiche di governo o pubbliche.
2. Nessuna persona che ricopra una qualsivoglia funzione (inclusa quella di funzionario di collegamento) all'intero del Comitato di qualsiasi Organizzazione di sostegno potrà al tempo stesso ricoprire la funzione di Direttore o funzionario di collegamento all'interno del Consiglio. Qualora tale persona accetti una nomina di ammissione alla selezione per il ruolo di Direttore da parte del Comitato dell'organizzazione di sostegno, tale persona non potrà, in seguito a tale nomina, partecipare a qualsivoglia discussione o votazione del Comitato dell'organizzazione di sostegno relativa alla selezione dei Direttori da parte del Consiglio, finché quest'ultimo non abbia selezionato il complesso dei Direttori da selezionare. Nel caso in cui una persona che ricopre una qualsiasi funzione nel Comitato di un'Organizzazione di sostegno accetti una nomina di ammissione alla selezione per il ruolo di Direttore, il gruppo di circoscrizione o qualsivoglia altro gruppo o ente che abbia selezionato tale persona potrà scegliere un sostituto ai fini del processo di selezione del Comitato.
3. Le persone che ricoprono una qualsiasi funzione all'interno del Comitato per l'assegnazione delle nomine non potranno partecipare alla selezione per ricoprire posizioni all'interno del Consiglio, come stabilito dall'Articolo VII, Sezione 8.
Sezione 5. RAPPRESENTANZA INTERNAZIONALE
Per assicurare un'ampia rappresentanza internazionale all'interno del Consiglio, la selezione dei Direttori da parte del Comitato per l'assegnazione delle nomine e ciascuna Organizzazione di sostegno dovranno attenersi a tutte le disposizioni applicabili in materia di diversità contenute nel presente Statuto o in qualsiasi Protocollo d'Intesa menzionato nel presente Statuto a proposito dell'Organizzazione di sostegno. Uno degli obiettivi di tali disposizioni in materia di diversità è assicurare che ogni Regione Geografica all'interno del Consiglio sia rappresentata da almeno un Direttore e mai da più di cinque Direttori (escluso il Presidente). Nel presente Statuto, con la definizione di "Regione Geografica" si intendono: Europa, Asia/Australia/Pacifico, America Latina/Caraibi, Africa e Nord America. Nello specifico, i paesi facenti parte di ogni Regione Geografica saranno decisi dal Consiglio, che periodicamente (almeno ogni tre anni) dovrà rivedere la presente Sezione per stabilire se sia opportuno introdurre modifiche, tenuto conto dello sviluppo di Internet.
Sezione 6. CONFLITTI DI INTERESSI DEI DIRETTORI
Almeno una volta l'anno, il Consiglio, tramite apposito comitato, richiederà a ogni Direttore il rilascio di una dichiarazione che annoveri tutte le attività e le affiliazioni in qualsiasi modo correlate all'attività e alle altre affiliazioni di ICANN. Ciascun Direttore avrà il dovere di informare ICANN di ogni questione ragionevolmente imputabile di poter rendere tale Direttore un "Direttore interessato" ai sensi della Sezione 5233 della normativa California Nonprofit Public Benefit Corporation Law ("CNPBCL"). Inoltre, ciascun Direttore avrà il dovere di informare ICANN di ogni eventuale relazione o diverso fattore ragionevolmente imputabile di far sì che tale Direttore possa essere considerato "persona interessata" ai sensi della Sezione 5227 della normativa CNPBCL. Il Consiglio dovrà adottare le politiche specifiche in materia di conflitto di interessi di Direttori, Funzionari e Organizzazioni di sostegno. Nessun Direttore potrà votare riguardo a qualsiasi questione in cui sia implicato un interesse finanziario materiale e diretto che verrebbe influenzato dal risultato della votazione.
Sezione 7. DOVERI DEI DIRETTORI
I Direttori saranno rappresentati da individui con il dovere di agire secondo ciò che ragionevolmente reputano il migliore interesse di ICANN e non in quanto rappresentanti dell'ente che li ha selezionati, dei propri dipendenti o di altre organizzazioni o enti costitutivi.
Sezione 8. CARICA DEI DIRETTORI
1. Fatto salvo quanto disposto dall'Articolo di Transizione del presente Statuto, la normale durata del mandato delle Posizioni di Direttore dalla 1 alla 14 avrà inizio secondo le seguenti modalità:
a. Il regolare mandato delle Posizioni dalla 1 alla 3 avrà inizio al termine della riunione annuale di ICANN del 2003 e di ogni riunione annuale di ICANN dei tre anni successivi al 2003;
b. Il regolare mandato delle Posizioni dalla 4 alla 6 avrà inizio al termine della riunione annuale di ICANN del 2004 e di ogni riunione annuale di ICANN dei tre anni successivi al 2004;
c. Il regolare mandato delle Posizioni dalla 7 alla 8 avrà inizio al termine della riunione annuale di ICANN del 2005 e di ogni riunione annuale di ICANN dei tre anni successivi al 2005;
d. Il regolare mandato delle Posizioni dalla 9 alla 12 avrà inizio sei mesi dopo il giorno della conclusione della riunione annuale di ICANN del 2002 e di ogni riunione annuale di ICANN dei tre anni successivi al 2002;
e. Il regolare mandato delle Posizioni dalla 10 alla 13 avrà inizio sei mesi dopo il giorno della conclusione della riunione annuale di ICANN del 2003 e di ogni riunione annuale di ICANN dei tre anni successivi al 2003;
f. Il regolare mandato delle Posizioni dalla 11 alla 14 avrà inizio sei mesi dopo il giorno della conclusione della riunione annuale di ICANN del 2004 e di ogni riunione annuale di ICANN dei tre anni successivi al 2004.
2. Ogni Direttore che ricopra una qualsiasi delle Posizioni dalla 1 alla 14, incluso il Direttore selezionato a copertura di una posizione vacante, manterrà la carica per almeno un mandato e finché non sarà stato selezionato e trovato idoneo un successore oppure finché tale Direttore non si dimetta o venga rimosso secondo le modalità previste dal presente Statuto.
3. Almeno un mese prima dell'inizio di ciascuna riunione annuale, il Comitato per l'assegnazione delle nomine dovrà presentare al Segretario di ICANN una notifica scritta dei Direttori selezionati per le posizioni il cui mandato ha inizio al termine della riunione annua.
4. Entro cinque mesi a partire dal termine di ogni riunione annuale, qualsiasi Organizzazione di sostegno abilitata alla selezione di un Direttore per una Posizione il cui mandato abbia inizio sei mesi dopo il giorno della conclusione della riunione annuale dovrà presentare al Segretario di ICANN una notifica scritta della selezione effettuata.
5. Fatto salvo quanto disposto dall'Articolo di Transizione del presente Statuto, nessun Direttore potrà mantenere la carica per più di tre mandati consecutivi. A questo proposito, qualora una persona sia stata selezionata per ricoprire una posizione vacante nel corso di un mandato, tale mandato non dovrà essere considerato.
6. Il mandato di Direttore di una persona con l'incarico di Presidente sarà valido solo finché tale persona ricoprirà l'incarico di Presidente.
Sezione 9. FUNZIONARI DI COLLEGAMENTO NON VOTANTI
1. I funzionari di collegamento non votanti includono:
a. Una persona nominata dal Comitato consultivo governativo;
b. Una persona nominata dal Comitato consultivo del sistema root server descritto all'Articolo XI del presente Statuto;
c. Una persona nominata dal Security and Stability Advisory Committee descritto all'Articolo XI del presente Statuto;
d. Una persona nominata dal Technical Liaison Group descritto all'Articolo XI-A del presente Statuto;
e. Una persona nominata dal Comitato ALAC (At-Large Advisory Committee) descritto all'Articolo XI del presente Statuto; e
f. Una persona nominata dall'Internet Engineering Task Force.
2. Fatto salvo quanto disposto dall'Articolo di Transizione del presente Statuto, i funzionari di collegamento non votanti avranno mandati che iniziano alla conclusione di ciascuna riunione annuale. Almeno un mese prima dell'inizio di ciascuna riunione annuale, ciascun organismo avente diritto di nominare un funzionario di collegamento non votante dovrà presentare al Segretario di ICANN una notifica scritta della nomina.
3. I funzionari di collegamento non votanti opereranno come volontari, senza ricevere compensi al di fuori del rimborso di talune spese.
4. Ciascun funzionario di collegamento non votante può essere nominato nuovamente e occuperà la propria posizione finché non sarà stato nominato un successore oppure finché il funzionario di collegamento non si dimetta o venga rimosso secondo le modalità previste dal presente Statuto.
5. I funzionari di collegamento non votanti avranno diritto di partecipare alle riunioni del Consiglio, di prendere parte alle discussioni e deliberazioni del Consiglio e di accedere (nell'ambito delle condizioni stabilite dal Consiglio) ai materiali forniti ai Direttori per l'utilizzo nelle discussioni, deliberazioni e riunioni del Consiglio, ma a parte questo non godranno di alcuno dei diritti e dei privilegi dei Direttori. I funzionari di collegamento non votanti avranno diritto (nell'ambito delle condizioni stabilite dal Consiglio) di utilizzare qualsiasi materiale fornito loro ai sensi di questa Sezione a scopo di consultazione con il rispettivo comitato o la rispettiva organizzazione.
Sezione 10. DIMISSIONI DI UN DIRETTORE O DI UN FUNZIONARIO DI COLLEGAMENTO NON VOTANTE
Come previsto dalla Sezione 5226 della normativa CNPBCL, qualsiasi Direttore o funzionario di collegamento non votante ha la facoltà di rassegnare le dimissioni in qualsiasi momento, verbalmente durante qualsiasi riunione del Consiglio (facendo quindi pervenire comunicazione scritta al Segretario di ICANN) o dandone notifica per iscritto al Presidente o al Segretario di ICANN. Tali dimissioni avranno effetto dal momento specificato e, salvo quanto diversamente indicato, la loro accettazione non sarà necessaria per renderle valide. Il successore verrà selezionato ai sensi della Sezione 12 di questo Articolo.
Sezione 11. RIMOZIONE DI UN DIRETTORE O DI UN FUNZIONARIO DI COLLEGAMENTO NON VOTANTE
1. Qualsiasi Direttore può essere rimosso, a seguito di notifica a tale Direttore e, se selezionato da un'organizzazione di sostegno, a tale organizzazione di sostegno, con il voto favorevole dei tre quarti (3/4) di tutti i Direttori. Il Direttore oggetto del voto di rimozione sarà escluso dalla votazione e non sarà conteggiato come membro del Consiglio nel calcolo dei tre quarti (3/4) previsto dalla procedura. Inoltre, ogni voto per la rimozione del Direttore costituirà un voto distinto esclusivamente in relazione alla rimozione di tale Direttore.
2. Fatta eccezione per i funzionari di collegamento non votanti nominati dal Comitato consultivo governativo, qualsiasi funzionario di collegamento non votante può essere rimosso, a seguito di notifica a tale funzionario di collegamento e all'organizzazione da cui tale funzionario di collegamento è stato selezionato, con il voto favorevole dei tre quarti (3/4) di tutti i Direttori, qualora l'organizzazione da cui è stato selezionato non provveda a rimuoverlo tempestivamente a seguito di tale notifica. Il Consiglio può richiedere che il Comitato consultivo governativo prenda in considerazione la sostituzione del funzionario di collegamento non votante nominato dal Comitato, se il Consiglio, con il voto favorevole dei tre quarti (3/4) di tutti i Direttori, determina che tale azione sia appropriata.
1. Una o più posizioni nel Consiglio direttivo saranno considerate vacanti in caso di morte, dimissioni o rimozione di un Direttore; in caso di aumento del numero di Direttori autorizzati; qualora un Direttore venga dichiarato incapace di intendere da una sentenza di tribunale, riconosciuto colpevole di un crimine o incarcerato per più di 90 giorni a seguito di una condanna oppure venga riconosciuto colpevole da una sentenza di tribunale del mancato rispetto di uno degli obblighi previsti dalle Sezioni 5230 e successive della normativa CNPBCL. Qualsiasi posizione vacante nel Consiglio direttivo verrà occupata dal Comitato per l'assegnazione delle nomine, a meno che (a) il Direttore sia stato selezionato da un'organizzazione di sostegno, nel qual caso la posizione vacante verrà occupata da tale organizzazione di sostegno, oppure (b) tale Direttore sia il Presidente, nel qual caso la posizione vacante verrà occupata come previsto dall'Articolo XIII del presente Statuto. L'organismo deputato alla selezione dovrà presentare al Segretario di ICANN notifica scritta delle nomine per l'occupazione delle posizioni vacanti. Un Direttore selezionato per occupare una posizione vacante nel Consiglio manterrà la carica per il periodo rimanente del mandato del proprio predecessore e finché non sarà stato selezionato e trovato idoneo un successore. Nessuna riduzione del numero di Direttori autorizzati avrà come effetto quello di rimuovere un Direttore prima della scadenza del relativo mandato.
2. Le organizzazioni deputate alla selezione dei funzionari di collegamento non votanti identificate nella Sezione 9 di questo Articolo sono responsabili dell'individuazione e dell'occupazione di qualsiasi posizione vacante in tali ruoli. Dovranno presentare al Segretario di ICANN notifica scritta delle nomine per l'occupazione delle posizioni vacanti.
ICANN organizzerà riunioni annuali allo scopo di eleggere i funzionari e deliberare su altre questioni che potrebbero rendersi necessarie prima della riunione. Ogni riunione annuale di ICANN si terrà presso la sede principale di ICANN, o in qualsiasi altro luogo appropriato scelto dal Consiglio, a condizione che tale riunione annuale venga organizzata entro 14 mesi da quella immediatamente precedente. Se il Consiglio lo ritenesse opportuno, la riunione annuale dovrà essere distribuita in tempo reale e tramite formati audio e video archiviati via Internet.
Sezione 14. RIUNIONI ORDINARIE
Le riunioni ordinarie del Consiglio si terranno in date che verranno stabilite dal Consiglio. Se non specificato diversamente, le riunioni ordinarie si svolgeranno presso la sede principale di ICANN.
Sezione 15. RIUNIONI STRAORDINARIE
Le riunioni straordinarie del Consiglio direttivo possono essere indette su richiesta di un quarto (1/4) dei membri del Consiglio o da parte del Presidente del Consiglio. La convocazione di una riunione straordinaria deve essere effettuata dal Segretario di ICANN. Se non specificato diversamente, le riunioni straordinarie si svolgeranno presso la sede principale di ICANN.
Sezione 16. AVVISI RELATIVI ALLE RIUNIONI
L'avviso relativo all'orario e alla sede di tutte le riunioni deve essere recapitato a mano, telefonicamente o tramite posta elettronica a ciascun Direttore e funzionario di collegamento non votante, oppure inviato tramite posta prioritaria (posta aerea per gli indirizzi al di fuori degli Stati Uniti) o via fax, senza costi per il destinatario, all'indirizzo del Direttore o del funzionario di collegamento non votante, come specificato dalle registrazioni in possesso di ICANN. Qualora l'avviso venga recapitato tramite servizio postale, dovrà essere depositato presso il servizio postale degli Stati Uniti almeno (14) giorni prima della data della riunione. Qualora l'avviso venga recapitato a mano o a mezzo telefono, fax o posta elettronica, dovrà essere recapitato almeno quarantotto (48) ore prima della data della riunione. Nonostante quanto altrimenti previsto nella presente Sezione, l'avviso relativo a una riunione non dovrà essere recapitato a un Direttore che abbia sottoscritto una rinuncia agli avvisi, un consenso alla convocazione della riunione o un'approvazione dei relativi verbali, prima o dopo la riunione, o che partecipi alla riunione senza reclamare, prima della riunione o al momento della sua apertura, per il mancato invio dell'avviso a tale Direttore. Tali rinunce, consensi e approvazioni dovranno essere archiviati con le registrazioni aziendali o essere inclusi nei verbali delle riunioni.
Nel corso delle riunioni annuali, ordinarie e straordinarie del Consiglio, la maggioranza del numero totale di Direttori in carica in quel momento costituirà un quorum in grado di deliberare sulle questioni all'esame del Consiglio e le azioni deliberate tramite voto di maggioranza da tale quorum saranno considerate azioni dell'intero Consiglio, salvo laddove diversamente disposto dal presente Statuto o dalla legge. Se in una riunione del Consiglio il quorum non fosse disponibile, i Direttori presenti potranno aggiornare la riunione in una sede, un orario o una data differenti. Se una riunione viene aggiornata per più di ventiquattro (24) ore, un avviso dovrà essere inviato ai Direttori non presenti alla riunione al momento dell'aggiornamento.
Sezione 18. AZIONI TRAMITE TELECONFERENZE O ALTRI DISPOSITIVI DI COMUNICAZIONE
I membri del Consiglio o di qualsiasi Comitato del Consiglio possono partecipare a una riunione del Consiglio o del Comitato del Consiglio tramite (i) telefono per teleconferenze o analogo dispositivo di comunicazione, a patto che tutti i Direttori partecipanti alla riunione possano reciprocamente parlarsi e udirsi o (ii) dispositivo di comunicazione elettronica a schermo o altro dispositivo di comunicazione; a patto che (a) tutti i Direttori partecipanti alla riunione possano reciprocamente parlarsi e udirsi, (b) tutti i Direttori abbiano la possibilità di intervenire a pieno di fronte al Consiglio o al Comitato del Consiglio in tutte le questioni prese in esame e (c) ICANN adotti e implementi un sistema che consenta di verificare che (x) un soggetto partecipante alla riunione è un Direttore o altro soggetto avente diritto di partecipazione e (y) tutte le azioni intraprese o i voti espressi dal Consiglio o dal Comitato del Consiglio siano intraprese o espressi solo da membri di questi ultimi e non da persone che non ne sono membri. La partecipazione a una riunione ai sensi di questa Sezione costituisce la presenza di persona a tale riunione. ICANN dovrà rendere disponibili presso la sede di ciascuna riunione del Consiglio i dispositivi di telecomunicazione necessari per consentire ai membri del Consiglio di partecipare tramite telefono.
Sezione 19. AZIONI SENZA RIUNIONI
Qualsiasi azione richiesta o consentita dal Consiglio o da un Comitato del Consiglio potrà essere intrapresa senza una riunione qualora tutti i Direttori che hanno diritto di voto esprimano individualmente o collettivamente per iscritto il proprio consenso a tale azione. Tale consenso scritto avrà lo stesso valore e lo stesso effetto di un voto unanime da parte di tali Direttori. Tali consensi scritti verranno archiviati con i verbali degli atti del Consiglio.
Se consentito dalla legge in vigore, le comunicazioni tramite posta elettronica dovranno essere considerate equivalenti a qualsiasi comunicazione altrimenti richiesta per iscritto. ICANN ricorrerà alle misure che riterrà appropriate nelle specifiche circostanze per garantire l'autenticità delle comunicazioni tramite posta elettronica.
Sezione 21. DIRITTI DI CONTROLLO
Ogni Direttore avrà il diritto, in qualsiasi momento ragionevole, di controllare e copiare tutti i libri, le registrazioni e i documenti di qualsiasi tipo e di controllare le strutture fisiche di ICANN. ICANN stabilirà procedure ragionevoli per assicurare la protezione dalla divulgazione inappropriata di informazioni riservate.
I Direttori non riceveranno alcuna remunerazione per i propri servizi in qualità di Direttori. Il Consiglio, tuttavia, può autorizzare il rimborso di spese ragionevoli effettive e necessarie sostenute dai Direttori e dai funzionari di collegamento non votanti nello svolgimento delle loro funzioni.
Sezione 23. PRESUNZIONE DI ASSENSO
Verrà dato per scontato che un Direttore presente a una riunione del Consiglio durante la quale viene intrapresa un'azione su qualsiasi questione aziendale abbia fornito il proprio assenso all'azione intrapresa, a meno che il suo dissenso o la sua astensione non siano stati specificati nei verbali della riunione o meno che tale Direttore non presenti per iscritto un dissenso o un'astensione nei confronti di tale azione alla persona che opera come segretario della riunione prima dell'aggiornamento o invii tale dissenso o astensione tramite lettera raccomandata al Segretario di ICANN immediatamente dopo l'aggiornamento della riunione. Il diritto di dissentire o di astenersi non vale per un Direttore che ha votato in favore di tale azione.
ARTICOLO VII: COMITATO PER L'ASSEGNAZIONE DELLE NOMINE
È previsto un Comitato per l'assegnazione delle nomine di ICANN, responsabile della selezione di tutti i Direttori di ICANN, ad eccezione del Presidente e dei Direttori selezionati dalle organizzazioni di sostegno di ICANN, oltre che delle ulteriori selezioni specificate nel presente statuto.
Il Comitato per l'assegnazione delle nomine sarà composto dalle figure seguenti:
1. Un Presidente non votante, nominato dal Consiglio di ICANN;
2. Il Presidente immediatamente precedente del Comitato per l'assegnazione delle nomine, quale consigliere non votante;
3. Un funzionario di collegamento non votante nominato dal Comitato consultivo del sistema root server di ICANN descritto all'Articolo XI del presente Statuto;
4. Un funzionario di collegamento non votante nominato dal Security and Stability Advisory Committee di ICANN descritto all'Articolo XI del presente Statuto;
5. Un funzionario di collegamento non votante nominato dal Comitato consultivo governativo;
6. Fatto salvo quanto disposto dall'Articolo di Transizione del presente Statuto, cinque delegati con diritto di voto selezionati dal Comitato ALAC (At-Large Advisory Committee) descritto all'Articolo XI del presente Statuto;
7. Due delegati con diritto di voto, uno che rappresenta gli utenti delle piccole aziende e uno gli utenti delle grandi aziende, selezionati dalla Circoscrizione degli utenti aziendali dell'organizzazione GNSO (Generic Names Supporting Organization) descritta all'Articolo X del presente Statuto;
8. Un delegato con diritto di voto selezionato da ciascuna delle seguenti entità:
a. La Circoscrizione dei Registri gTLD dell'organizzazione GNSO (Generic Names Supporting Organization) descritta all'Articolo X del presente Statuto;
b. La Circoscrizione dei Registrar gTLD dell'organizzazione GNSO (Generic Names Supporting Organization) descritta all'Articolo X del presente Statuto;
c. Il Comitato dell'organizzazione Country-Code Names Supporting Organization descritta all'Articolo IX del presente Statuto;
d. La Circoscrizione degli Internet Service Provider dell'organizzazione GNSO (Generic Names Supporting Organization) descritta all'Articolo X del presente Statuto;
e. La Circoscrizione delle proprietà intellettuali dell'organizzazione GNSO (Generic Names Supporting Organization) descritta all'Articolo X del presente Statuto;
f. Il Comitato dell'organizzazione Address Supporting Organization descritta all'Articolo VIII del presente statuto;
g. Un'entità designata dal Consiglio per rappresentare le organizzazione accademiche e di tipo analogo;
h. Gruppi di consumatori e della società civile, selezionati dalla Circoscrizione degli utenti non commerciali dell'organizzazione GNSO (Generic Names Supporting Organization) descritta all'Articolo X del presente Statuto;
i. L'Internet Engineering Task Force; e
j. Il Technical Liaison Group di ICANN, descritto all'Articolo XI-A del presente Statuto; e
9. Un Presidente Associato non votante, che può essere nominato dal Presidente a propria esclusiva discrezione, per una parte o per l'intero mandato del Presidente. Il Presidente Associato non può essere una persona che fa parte ad altro titolo dello stesso Comitato per l'assegnazione delle nomine. Il Presidente Associato assisterà il Presidente nello svolgimento delle sue funzioni, ma non potrà, in modo temporaneo o altrimenti, operare in sostituzione del Presidente.
Fatto salvo quanto disposto dall'Articolo di Transizione del presente Statuto:
1. Ogni delegato con diritto di voto avrà un mandato di un anno. Un delegato potrà svolgere le proprie funzioni al massimo per due mandati successivi della durata di un anno, dopo i quali dovranno trascorrere almeno due anni prima che la persona sia idonea per un altro mandato.
2. Il regolare mandato di ciascun delegato con diritto di voto avrà inizio alla conclusione di una riunione annuale di ICANN e terminerà alla conclusione della riunione annuale di ICANN immediatamente successiva.
3. I funzionari di collegamento non votanti svolgeranno le proprie funzioni nel corso del mandato designato dall'entità che li nomina. Il Presidente, il Presidente immediatamente precedente che opera come consigliere e qualsiasi Presidente Associato svolgeranno le proprie funzioni fino alla conclusione della riunione annuale di ICANN successiva.
4. Le posizioni vacanti relative a delegati, funzionari di collegamento non votanti o Presidente saranno occupate dall'entità che ha diritto di selezionare il delegato, funzionario di collegamento non votante o Presidente. Le posizioni vacanti relative al consigliere non votante (Presidente immediatamente precedente) possono essere occupate dal Consiglio scegliendo tra persone che abbiano svolto funzioni in precedenza nel Consiglio o nel Comitato per l'assegnazione delle nomine. Le posizioni vacanti relative al Presidente Associato possono essere occupate dal Presidente in conformità ai criteri specificati nella Sezione 2(9) di questo Articolo.
5. La presenza di eventuali posizioni vacanti non avrà alcuna influenza sull'obbligo da parte del Comitato per l'assegnazione delle nomine di svolgere le responsabilità ad esso attribuite nel presente Statuto.
Sezione 4. CRITERI PER LA SELEZIONE DEI DELEGATI AL COMITATO PER L'ASSEGNAZIONE DELLE NOMINE
I delegati al Comitato per l'assegnazione delle nomine di ICANN devono essere:
1. Persone affermate con caratteristiche di integrità, obiettività e intelligenza, dotate di buon senso e apertura mentale, nonché di esperienza e competenza nell'elaborazione di decisioni di gruppo;
2. Persone con numerosi contatti e un'ampia esperienza nella comunità Internet, oltre che votate al successo di ICANN;
3. Persone che, a giudizio dell'organismo deputato alla selezione, si consulteranno con gli altri e accetteranno i loro suggerimenti nello svolgimento delle proprie responsabilità;
4. Persone con un atteggiamento neutrale e obiettivo, senza alcun impegno fisso a livello personale nei confronti di particolari individui, organizzazioni o obiettivi commerciali nello svolgimento delle responsabilità del Comitato per l'assegnazione delle nomine;
5. Persone che conoscono gli obiettivi di ICANN e il potenziale impatto delle attività di ICANN sulla comunità Internet più vasta, oltre che desiderose di operare come volontari, senza ricevere compensi al di fuori del rimborso di talune spese; e
6. Persone in grado di operare e comunicare nella lingua inglese scritta e parlata.
Nello svolgimento delle proprie responsabilità per la selezione dei membri del Consiglio di ICANN (e le selezioni per qualsiasi altro organismo di ICANN di cui il Comitato per l'assegnazione delle nomine è responsabile secondo il presente Statuto), il Comitato per l'assegnazione delle nomine dovrà prendere in considerazione la continuità dei membri del Consiglio di ICANN (e degli altri organismi) e cercherà di assicurare che le persone selezionate per occupare le posizioni vacanti nel Consiglio di ICANN (e negli altri organismi), per quanto possibile e in conformità con gli altri criteri di cui è richiesta l'applicazione da parte della Sezione 4 di questo Articolo, effettuino selezioni sulla base valore 4 specificato nell'Articolo I, Sezione 2 .
Sezione 6. SUPPORTO AMMINISTRATIVO E OPERATIVO
ICANN fornirà il supporto amministrativo e operativo necessario per consentire al Comitato per l'assegnazione delle nomine di svolgere le proprie funzioni.
Il Comitato per l'assegnazione delle nomine adotterà le procedure operative che riterrà necessarie, che verranno pubblicate sul sito Web.
Sezione 8. NON IDONEITÀ ALLA SELEZIONE DA PARTE DEL COMITATO PER L'ASSEGNAZIONE DELLE NOMINE
Nessuna persona che svolge le proprie funzioni nel Comitato per l'assegnazione delle nomine in qualsiasi ruolo sarà idonea, per alcuno scopo, per la selezione per qualsiasi posizione nel Consiglio o in organismi di ICANN che dispongono di una o più posizioni la cui occupazione è responsabilità del Comitato per l'assegnazione delle nomine, fino alla conclusione di una riunione annuale di ICANN che coincide o è successiva alla conclusione del mandato di tale persona nel Comitato per l'assegnazione delle nomine.
Sezione 9. NON IDONEITÀ PER LA PARTECIPAZIONE AL COMITATO PER L'ASSEGNAZIONE DELLE NOMINE
Nessuna persona che lavori come dipendente o come consulente stipendiato di ICANN (incluso l'Ombudsman) potrà contemporaneamente ricoprire una delle posizioni nel Comitato per l'assegnazione delle nomine descritte nella Sezione 2 di questo Articolo.
ARTICOLO VIII: ADDRESS SUPPORTING ORGANIZATION
1. ASO (Address Supporting Organization) fornirà suggerimenti al Consiglio in merito agli aspetti relativi a funzionamento, assegnazione e gestione degli indirizzi Internet.
2. ASO sarà l'entità prevista dal Protocollo d'Intesa adottato il 21 ottobre 2004 da ICANN e NRO (Number Resource Organization), un'organizzazione degli attuali RIR (Regional Internet Registry).
Sezione 2. COMITATO PER GLI INDIRIZZI
1. ASO disporrà di un Comitato per gli indirizzi, formato dai membri del Number Council di NRO.
2. Il Comitato per gli indirizzi selezionerà i Direttori per le posizioni nel Consiglio designate per l'occupazione da parte di ASO.
ARTICOLO IX: COUNTRY-CODE NAMES SUPPORTING ORGANIZATION
È previsto un organismo per lo sviluppo di politiche denominato Country-Code Names Supporting Organization (ccNSO), che sarà responsabile per:
1. Lo sviluppo e il suggerimento al Consiglio di politiche globali relative ai domini di primo livello nazionali;
2. Promozione del consenso nella comunità ccNSO, incluse le attività relative al nome dei ccTLD; e
3. Coordinamento con altre organizzazioni di sostegno di ICANN, comitati o circoscrizioni sotto il controllo di ICANN.
Le politiche applicabili ai membri di ccNSO in quanto membri sono solo quelle sviluppate in accordo alle sezioni 4.10 e 4.11 di questo Articolo. ccNSO, tuttavia, può anche prendere parte ad altre attività autorizzate dai propri membri. L'adesione ai risultati di queste attività sarà volontaria e tali attività possono includere: sviluppo delle migliori strategie volontarie per i gestori ccTLD, assistenza nello sviluppo delle capacità all'interno della comunità globale di gestori ccTLD e miglioramento della cooperazione operativa e tecnica tra i gestori ccTLD.
ccNSO sarà formato da (i) gestori ccTLD che hanno concordato per iscritto la propria partecipazione a ccNSO (vedere la Sezione 4(2) di questo Articolo) e (ii) un responsabile del Consiglio di ccNSO responsabile di gestire il processo di sviluppo delle politiche di ccNSO.
1. Il Consiglio di ccNSO sarà formato da (a) tre membri del Consiglio di ccNSO selezionati dai membri di ccNSO all'interno di ciascuna Regione Geografica di ICANN nel modo descritto nelle Sezioni dalla 4(7) alla (9) di questo Articolo; (b) tre membri del Consiglio di ccNSO selezionati dal Comitato per l'assegnazione delle nomine di ICANN; (c) funzionari di collegamento come descritto nel paragrafo 2 di questa Sezione; e (iv) osservatori come descritto nel paragrafo 3 di questa Sezione.
2. È inoltre previsto un funzionario di collegamento con il Consiglio di ccNSO per ciascuna della organizzazioni seguenti, qualora scelgano di nominarlo: (a) il Comitato consultivo governativo; (b) il Comitato ALAC (At-Large Advisory Committee); e (c) ognuna delle organizzazioni regionali descritte nella Sezione 5 di questo Articolo. Tali funzionari di collegamento non saranno membri del Consiglio di ccNSO e non godranno del diritto di voto, ma saranno a parte questo sullo stesso piano degli altri membri del Comitato. Le nomine dei funzionari di collegamento saranno notificate per iscritto al Segretario di ICANN, informandone in copia il Presidente del Consiglio di ccNSO, e avranno la durata designata dall'organizzazione deputata alla nomina, come specificato nella comunicazione scritta. L'organizzazione deputata alla nomina può destituire o sostituire il proprio funzionario di collegamento in qualsiasi momento, notificando per iscritto la destituzione o la sostituzione al Segretario di ICANN e informandone in copia il Presidente del Consiglio di ccNSO.
3. Il Consiglio di ccNSO può concordare con il comitato di qualsiasi altra organizzazione di sostegno di ICANN lo scambio di osservatori. Tali osservatori non saranno membri del Consiglio di ccNSO e non godranno del diritto di voto, ma saranno a parte questo sullo stesso piano degli altri membri del Comitato. Il comitato che effettua la nomina può designare il proprio osservatore (o revocarne la nomina o cambiarne la designazione) presso il Consiglio di ccNSO in qualsiasi momento facendone pervenire notifica scritta al Segretario di ICANN e informandone in copia il Presidente del Consiglio di ccNSO.
4. Fatto salvo quanto disposto dall'Articolo di Transizione del presente Statuto: (a) il regolare mandato di ciascun membro del Consiglio di ccNSO inizierà alla conclusione di una riunione annuale di ICANN e terminerà alla conclusione della terza riunione annuale di ICANN successiva; (b) i regolari mandati dei tre membri del Consiglio di ccNSO selezionati dai membri di ccNSO all'interno di ciascuna Regione Geografica di ICANN saranno scaglionati in modo che il mandato di un membro inizi in un anno divisibile per tre, il mandato di un secondo membro inizi nel primo anno successivo a quello divisibile per tre e il mandato del terzo membro inizi nel secondo anno successivo a quello divisibile per tre; e (c) i regolari mandati dei tre membri del Consiglio di ccNSO selezionati dal Comitato per l'assegnazione delle nomine saranno scaglionati nello stesso modo. Ciascun membro del Consiglio di ccNSO resterà in carica per la durata del proprio regolare mandato e fino a quando un successore non viene selezionato e trovato idoneo oppure fino a quando il membro in questione non rassegna le dimissioni o viene destituito secondo le modalità previste dal presente Statuto.
5. Un membro del Consiglio di ccNSO ha la facoltà di rassegnare le dimissioni in qualsiasi momento, dandone notifica per iscritto al Segretario ICANN e informandone in copia il Presidente del Consiglio di ccNSO.
6. I membri del Consiglio di ccNSO possono essere rimossi se mancano di presenziare per tre volte consecutive alle riunioni del Comitato senza giusta causa ovvero se tengono una condotta gravemente inappropriata. In entrambi i casi, la decisione deve essere determinata da un voto minimo del 66% di tutti i membri del Consiglio di ccNSO.
7. In caso di decesso, dimissioni o destituzione di un membro del Consiglio di ccNSO, la relativa posizione sarà considerata vacante. Le posizioni vacanti dei tre membri la cui selezione spetta al Comitato per l'assegnazione delle nomine dovranno essere occupate, per il rimanente periodo del mandato, a cura di tale Comitato, il quale notificherà per iscritto al Segretario ICANN la propria selezione informandone in copia il Presidente del Consiglio di ccNSO. Le posizioni vacanti dei membri del Consiglio di ccNSO la cui selezione spetta ai membri del ccNSO dovranno essere occupate, per il rimanente periodo del mandato, seguendo la procedura descritta alle Sezioni dalla 4(7) alla (9) di questo Articolo.
8. Il ruolo del Consiglio di ccNSO è quello di amministrare e coordinare le attività del ccNSO (ivi compreso coordinare le riunioni, tra cui una riunione annuale, dei membri del ccNSO come descritto alla Sezione 4(6) di questo Articolo) nonché gestire lo sviluppo dei suggerimenti sulle Policy in conformità alla Sezione 6 del presente Articolo. Il Consiglio di ccNSO ricoprirà inoltre anche i ruoli che di volta in volta i membri del Comitato stesso vorranno deliberare.
9. Il Consiglio di ccNSO selezionerà i soggetti destinati ad occupare le Posizioni 11 e 12 del Consiglio direttivo tramite votazione scritta o tramite azione nel corso di una riunione; ogni selezione così effettuata richiede il voto favorevole della maggioranza di tutti i membri del Consiglio di ccNSO in carica in quel momento. Il Presidente del Consiglio di ccNSO ha il dovere di informare per iscritto il Segretario ICANN delle selezioni effettuate dal Comitato stesso, in conformità con le disposizioni dell'Articolo VI, Sezioni 8(4) e 12(1).
10. Il Consiglio di ccNSO selezionerà tra i propri membri il Presidente del Consiglio di ccNSO e i Vicepresidenti che riterrà appropriati. La selezione del Presidente del Consiglio di ccNSO e del/i Vicepresidente/i dovrà avvenire tramite votazione scritta o tramite azione nel corso di una riunione; ogni selezione così effettuata richiede il voto favorevole della maggioranza di tutti i membri del Consiglio di ccNSO in carica in quel momento. La durata del mandato del Presidente del Consiglio di ccNSO e del/i Vicepresidente/i dovrà essere specificata dal Consiglio di ccNSO prima della selezione oppure al momento della selezione stessa. Il Presidente del Consiglio di ccNSO o qualsiasi Vicepresidente possono essere destituiti seguendo la stessa procedura impiegata per la selezione.
11. Se indicato dai membri del ccNSO, il Consiglio di ccNSO dovrà adottare le regole e le procedure da esso ritenute necessarie, purché coerenti con il presente Statuto. Le regole che disciplinano la partecipazione al ccNSO e le procedure operative adottate dal Comitato saranno pubblicate sul sito Web.
12. Fatto salvo quanto disposto ai paragrafi 9 e 10 della presente Sezione, il Consiglio di ccNSO opererà tramite riunioni. Il Consiglio di ccNSO dovrà riunirsi a intervalli regolari, secondo le scadenze stabilite dal Comitato stesso, ma non meno di quattro volte nell'arco di ciascun anno solare. A discrezione del Consiglio di ccNSO, la partecipazione alle riunioni può avvenire sia di persona sia altrimenti, purché tutti i membri del Comitato possano partecipare secondo almeno una delle modalità descritte al paragrafo 14 di questa Sezione. Salvo laddove un voto di maggioranza dei membri del Consiglio di ccNSO stabilisca che una sessione a porte chiuse è indicata, tutti i soggetti interessati potranno presenziare alle riunioni. Nella misura in cui ciò è fattibile, le riunioni del Consiglio di ccNSO dovrebbero svolgersi in concomitanza con le riunioni del Consiglio direttivo o di uno o più degli altri organismi di supporto di ICANN.
13. Ciascun membro, funzionario di collegamento e osservatore del Consiglio di ccNSO deve essere informato, a mezzo e-mail, telefono, fax o notifica scritta recapitata a mano o tramite servizio postale, dell'ora e del luogo (nonché delle modalità di partecipazione ammesse, oltre alla presenza personale) di tutte le riunioni del Comitato. Qualora l'avviso venga recapitato tramite servizio postale, dovrà essere inviato almeno 21 giorni prima della data della riunione. Qualora l'avviso venga recapitato a mano o a mezzo telefono, fax o e-mail, dovrà essere inviato almeno sette giorni prima della data della riunione. Almeno sette giorni prima di ciascuna riunione del Consiglio di ccNSO (o in caso di impossibilità, con il massimo anticipo possibile), sarà necessario pubblicare una nota della riunione stessa, unitamente a un ordine del giorno, per quanto noto.
14. I membri del Consiglio di ccNSO possono partecipare a una riunione del Comitato sia di persona, sia tramite sistema di comunicazione elettronico (ad esempio telefono o videoconferenza), a patto che (a) tutti i membri del Comitato partecipanti alla riunione possano reciprocamente parlarsi e udirsi, (b) tutti i membri del Comitato partecipanti alla riunione abbiano la possibilità di intervenire a pieno di fronte al Comitato stesso in tutte le questioni prese in esame e (c) esistano metodi ragionevoli per verificare l'identità dei membri partecipanti alla riunione e dei relativi voti. La maggioranza dei membri del Consiglio di ccNSO (cioè di coloro che godono del diritto di voto) in carica in quel momento costituirà un quorum in grado di deliberare sulle questioni all'esame del Comitato e le azioni deliberate tramite voto di maggioranza da tale quorum saranno considerate azioni dell'intero Comitato, salvo laddove diversamente disposto dal presente Statuto. Il Consiglio di ccNSO trasmetterà i verbali delle proprie riunioni al Segretario ICANN, il quale provvederà a farli pubblicare sul sito Web non appena possibile dopo il termine della riunione e comunque entro e non oltre i 21 giorni successivi.
1. Il ccNSO dovrà essere composto da gestori ccTLD. Tutti i gestori ccTLD che soddisfano le qualifiche di composizione descritte al paragrafo 2 di questa Sezione possono diventare membri del ccNSO. Ai fini del presente Articolo, un gestore ccTLD è un'organizzazione o entità responsabile di gestire un dominio di primo livello nazionale ISO 3166, indicata nel database IANA come organizzazione di sostegno o con una qualsiasi variante successiva di quel dominio di primo livello nazionale.
2. Qualsiasi gestore ccTLD può diventare membro del ccNSO presentandone domanda al soggetto preposto dal Consiglio di ccNSO a tale funzione. Fatto salvo quanto disposto dall'Articolo di Transizione del presente Statuto, la domanda dovrà essere presentata per iscritto e rispettare la forma designata dal Consiglio di ccNSO. La domanda deve includere, da parte del gestore ccTLD, il riconoscimento del ruolo del ccNSO all'interno della struttura di ICANN nonché l'accettazione, per tutta la durata della sua partecipazione al ccNSO, (a) delle regole del ccNSO, ivi comprese quelle che disciplinano la condotta dei suoi membri, (b) delle Policy sviluppate e consigliate dal ccNSO e adottate dal Consiglio direttivo secondo le modalità descritte ai paragrafi 10 e 11 della presente Sezione e (c) dell'obbligo di pagamento della quota di appartenenza fissata dal Consiglio di ccNSO ai sensi della Sezione 7(3) di questo Articolo. Un membro del ccNSO può rinunciare alla propria posizione di membro in qualsiasi momento facendone pervenire notifica scritta al soggetto preposto dal Consiglio di ccNSO a tale funzione. Rinunciando alla posizione di membro, un gestore ccTLD cessa di accettare (a) le regole del ccNSO, ivi comprese quelle che disciplinano la condotta dei suoi membri, (b) le Policy sviluppate e consigliate dal ccNSO e adottate dal Consiglio direttivo secondo le modalità descritte ai paragrafi 10 e 11 della presente Sezione e (c) l'obbligo di pagamento della quota di appartenenza fissata dal Consiglio di ccNSO ai sensi della Sezione 7(3) di questo Articolo. Qualora il Consiglio di ccNSO non avesse designato alcun soggetto per ricevere le domande e le rinunce, esse dovranno essere indirizzate al Segretario ICANN il quale ne darà notifica al Consiglio di ccNSO.
3. La qualifica di membro del ccNSO o di una delle Organizzazioni Regionali descritte alla Sezione 5 di questo Articolo costituirà un requisito per accedere o essere registrati nel database IANA. L'eventuale relazione individuale di un gestore ccTLD con ICANN o la ricezione dei servizi IANA da parte di un gestore ccTLD non dipende in alcun modo dalla sua qualifica come membro del ccNSO.
4. Le Regioni Geografiche dei ccTLD saranno come descritte all' Articolo VI, Sezione 5 del presente Statuto. Ai fini del presente Articolo, i gestori ccTLD che si trovano all'interno di una Regione Geografica e sono membri del ccNSO vengono indicati come membri "all'interno" della Regione Geografica, a prescindere dall'ubicazione fisica del gestore ccTLD. Laddove la Regione Geografica di un membro del ccNSO non fosse chiara, il membro del ccTLD dovrà selezionarla personalmente seguendo le procedure adottate dal Consiglio di ccNSO.
5. Ciascun gestore ccTLD potrà designare per iscritto una persona, organizzazione o entità come proprio rappresentante. In assenza di tale designazione, il gestore ccTLD sarà rappresentato dalla persona, organizzazione o entità elencata come contatto amministrativo nel database IANA.
6. È prevista la convocazione di una riunione annuale dei membri del ccNSO che sarà coordinata dal Consiglio di ccNSO. La partecipazione alle riunioni annuali è aperta a tutti. Ai gestori ccTLD e ad altri soggetti non membri del ccNSO verrà concessa una ragionevole opportunità di prendere parte all'assemblea. Nella misura in cui ciò è fattibile, le riunioni annuali dei membri del ccNSO dovrebbero essere presenziate di persona e svolgersi in concomitanza con le riunioni del Consiglio direttivo o di uno o più degli altri organismi di supporto di ICANN.
7. I membri del Consiglio di ccNSO selezionati dai membri del ccNSO provenienti da ciascuna Regione Geografica (vedere la Sezione 3(1)(a) di questo Articolo) saranno selezionati tramite nomina e, se necessario, tramite elezione, dai membri del ccNSO di quella Regione Geografica. Non più tardi di 90 giorni prima dello scadere del regolare mandato di un membro del Consiglio di ccNSO selezionato da altri membri del ccNSO o quando la posizione di tale membro resta vacante, il Consiglio di ccNSO dovrà stabilire un programma per la nomina e l'elezione del sostituto, inviarlo a tutti i membri del ccNSO all'interno della Regione Geografica e pubblicarlo sul sito Web.
8. Qualsiasi membro del ccNSO potrà nominare una persona quale membro rappresentante della propria Regione Geografica presso il Consiglio di ccNSO. Le nomine devono essere appoggiate da un altro membro del ccNSO proveniente dalla stessa Regione Geografica. Accettando la designazione, le persone nominate quali membri del Consiglio di ccNSO accettano di appoggiare le Policy che i membri del ccNSO si sono impegnati a seguire.
9. Se alla chiusura delle nomine il numero di candidati designati (nonché appoggiati e accettati) per una particolare Regione Geografica non supera quello delle posizioni disponibili per quella Regione presso il Consiglio di ccNSO, i candidati nominati saranno selezionati per essere membri del Comitato. Diversamente, sarà necessario procedere a una votazione scritta (anche a mezzo e-mail) per selezionare tra i candidati designati (nonché appoggiati e accettati) chi sarà membro del Consiglio di ccNSO. I membri del ccNSO provenienti dalla Regione Geografica avranno il diritto di votare tramite i propri rappresentanti designati. Nel corso di tale votazione, il quorum sarà rappresentato dalla maggioranza di tutti membri del ccNSO aventi diritto di voto in quella Regione Geografica e il candidato selezionato dovrà ricevere la maggioranza delle preferenze espresse dai membri del ccNSO all'interno della Regione Geografica. Ai sensi del presente paragrafo, il Presidente del Consiglio di ccNSO notificherà per iscritto al Segretario ICANN la scelta espressa dai membri del Comitato.
10. Fatto salvo quanto previsto alla clausola 4(11), le Policy ICANN saranno applicabili ai membri del ccNSO in quanto membri, ma solo nella misura in cui le Policy (a) trattino esclusivamente questioni di competenza del ccNSO secondo l'Articolo IX, Sezione 6 e l'Appendice C; (b) siano state sviluppate attraverso il ccPDP come descritto alla Sezione 6 di questo Articolo, (c) siano per questo motivo oggetto di suggerimento da parte del ccNSO al Consiglio direttivo e (d) siano state adottate da quest'ultimo come Policy, ammesso che tali Policy non siano in conflitto con le disposizioni di legge applicabili al gestore ccTLD, le quali avranno sempre la precedenza. Inoltre, tali Policy si applicheranno alle attività ICANN relative ai ccTLD.
11. Un membro del ccNSO non sarà soggetto a tali vincoli se presenterà al Consiglio di ccNSO un'attestazione in cui dichiara che (a) l'implementazione della Policy lo costringerebbe a violare usi, pratiche religiose o costumi (non inclusi nelle leggi applicabili di cui al paragrafo 10 di questa Sezione) e (b) la mancata attuazione della Policy non impedisce il funzionamento o l'interoperabilità DNS, accompagnando le proprie affermazioni con motivazioni dettagliate. Una volta esaminata la questione, il Consiglio di ccNSO fornirà al membro una risposta all'attestazione fornita da quest'ultimo. Se il Consiglio di ccNSO non concorda con l'attestazione, cioè se i membri del Comitato esprimono il proprio dissenso con almeno 14 voti, il Comitato dovrà negare il proprio assenso all'attestazione e accompagnare la propria risposta con le dovute motivazioni. Diversamente, la risposta dovrà esprimere l'accettazione dell'attestazione da parte del Consiglio di ccNSO. Qualora il Consiglio di ccNSO esprimesse un dissenso, esso dovrà riesaminare la questione trascorso un periodo di sei mesi. Al termine di tale periodo, il Consiglio di ccNSO dovrà concludere se (a) l'implementazione della Policy da parte del membro del ccNSO costringerebbe quest'ultimo a violare usi, pratiche religiose o costumi (non inclusi nelle leggi applicabili di cui al paragrafo 10 di questa Sezione) e (b) la mancata attuazione della Policy impedisce il funzionamento o l'interoperabilità DNS. Se le conclusioni del Consiglio di ccNSO dissentono dall'attestazione, il Comitato procederà sulla base dell'unanimità che si riterrà raggiunta in presenza di almeno 14 voti favorevoli.
Sezione 5. ORGANIZZAZIONI REGIONALI
Il Consiglio di ccNSO può designare Organizzazioni Regionali per ciascuna Regione Geografica ICANN, a condizione che la partecipazione a tale Organizzazione Regionale sia aperta a tutti i membri del ccNSO all'interno di quella Regione Geografica. La decisione di designare o revocare l'istituzione di un'Organizzazione Regionale richiede il 66% dei voti di tutti i membri del Consiglio di ccNSO ed è soggetta a revisione secondo le procedure stabilite dal Consiglio direttivo.
Sezione 6. PROCEDURA E AMBITO DI SVILUPPO DELLE POLICY DEL ccNSO
1. L'ambito del ruolo di sviluppo delle Policy del ccNSO è descritto nell'Appendice C del presente Statuto; qualsiasi modifica a tale ambito deve essere suggerita al Consiglio direttivo dal ccNSO seguendo le procedure del ccPDP e dovrà essere approvata dal Consiglio stesso.
2. Nello sviluppo di Policy globali entro l'ambito di competenza del ccNSO e nel suggerirle al Consiglio direttivo, il ccNSO dovrà seguire il processo di sviluppo delle Policy (ccPDP). Il ccPDP dovrà avvenire come descritto nell'Appendice B del presente Statuto; eventuali modifiche devono essere suggerite al Consiglio direttivo dal ccNSO seguendo le procedure del ccPDP e dovranno essere approvate dal Consiglio stesso.
Sezione 7. SUPPORTO E FINANZIAMENTO DELLO STAFF
1. Su richiesta del Consiglio di ccNSO, un membro dello staff di ICANN può essere incaricato del supporto del ccNSO ed essere designato come ccNSO Staff Manager. In alternativa, il Consiglio di ccNSO può designare, a spese del ccNSO, un altro soggetto per svolgere le funzioni di ccNSO Staff Manager. Il lavoro del ccNSO Staff Manager nella sostanza viene assegnato dal Presidente del Consiglio di ccNSO e può includere i compiti di ccPDP Issue Manager.
2. Su richiesta del Consiglio di ccNSO, ICANN fornirà il supporto amministrativo e operativo necessario per consentire al ccNSO di svolgere le proprie funzioni. Tale supporto non implica in alcun modo che ICANN è tenuta a coprire le spese di viaggio sostenute dai membri del ccNSO per partecipare alle riunioni di quest'ultimo o per altri motivi. Il Consiglio di ccNSO può provvedere, a spese del ccNSO, alla copertura del supporto amministrativo e operativo in aggiunta o in alternativa al supporto fornito da ICANN.
3. Il Consiglio di ccNSO dovrà fissare la quota di partecipazione che i membri del ccNSO dovranno versare per coprire le spese descritte ai paragrafi 1 e 2 della presente Sezione, previa approvazione dei membri del ccNSO.
4. Gli avvisi scritti recapitati al Segretario ICANN ai sensi del presente Articolo dovranno essere conservati in un archivio permanente e resi visionabili su richiesta al Consiglio di ccNSO. Il Segretario ICANN manterrà una registrazione aggiornata dei membri del ccNSO che dovrà contenere anche il nome di ciascun rappresentante designato dei gestori ccTLD ed essere pubblicato sul sito Web.
ARTICOLO X: GENERIC NAMES SUPPORTING ORGANIZATION
Viene istituito un organismo per lo sviluppo delle Policy con il nome di Generic Names Supporting Organization (GNSO) la cui responsabilità sarà di sviluppare e suggerire al Consiglio direttivo ICANN Policy di rilevanza relative a domini di primo livello generici.
Il GNSO sarà composto da (i) varie Circoscrizioni, rappresentanti gruppi particolari di azionisti, come descritto alla Sezione 5 di questo Articolo e (ii) un responsabile del Consiglio del GNSO incaricato di gestire il processo di sviluppo delle Policy del GNSO.
1. Fatto salvo quanto disposto dall'Articolo di Transizione del presente Statuto, il Consiglio del GNSO sarà composto da tre rappresentanti selezionati da ognuna delle Circoscrizioni descritte alla Sezione 5 di questo Articolo, e da tre soggetti selezionati dal Comitato di ICANN per l'assegnazione delle nomine. Non è ammesso che due rappresentanti selezionati da una Circoscrizione siano cittadini dello stesso paese o di paesi che si trovano nella stessa Regione Geografica. Il Consiglio del GNSO può disporre inoltre di due funzionari di collegamento, nominati di volta in volta uno dal Comitato consultivo governativo e l'altro dal At-Large Advisory Committee, i quali non saranno membri del Consiglio del GNSO o non godranno del diritto di voto presso tale Consiglio, ma avranno comunque pari diritti di partecipazione a quelli degli altri membri del Consiglio del GNSO. Il Comitato consultivo che effettua la nomina dovrà designare il proprio funzionario di collegamento (o revocarne la nomina o cambiarne la designazione) presso il Consiglio del GNSO facendone pervenire la notifica scritta al Presidente del Consiglio del GNSO e al Segretario ICANN. Il Consiglio del GNSO può anche disporre di osservatori, come descritto al paragrafo 9 di questa Sezione.
2. Fatto salvo quanto disposto dall'Articolo di Transizione del presente Statuto: (a) il regolare mandato di ciascun membro del Consiglio del GNSO inizierà alla conclusione di una riunione annuale di ICANN e terminerà alla conclusione della seconda riunione annuale di ICANN successiva; (b) il regolare mandato di uno dei due rappresentanti selezionati da una Circoscrizione inizierà in un anno pari mentre il mandato del rappresentante selezionato dall'altra Circoscrizione inizierà in un anno dispari; (c) il regolare mandato di uno dei tre membri selezionati dal Comitato per l'assegnazione delle nomine inizierà in un anno pari mentre il regolare mandato dei rimanenti due membri inizierà in un anno dispari. Ciascun membro del Consiglio del GNSO resterà in carica per la durata del proprio regolare mandato e fino a quando un successore non viene selezionato e trovato idoneo ovvero fino a quando il membro in questione non rassegna le dimissioni o viene destituito secondo le modalità previste dal presente Statuto.
3. Un membro del Consiglio del GNSO ha la facoltà di rassegnare le dimissioni in qualsiasi momento, dandone notifica per iscritto al Segretario ICANN. Un membro del Consiglio del GNSO selezionato da una Circoscrizione può essere rimosso da quella Circoscrizione seguendo le procedure da essa pubblicate. Un membro del Consiglio del GNSO selezionato dal Comitato per l'assegnazione delle nomine può essere rimosso per giusta causa da tre quarti (3/4) dei voti (vedere la Sezione 5(2) di questo Articolo) di tutti i membri del Consiglio del GNSO (escluso il membro soggetto a rimozione), salvo approvazione del Consiglio direttivo di ICANN. In caso di decesso, dimissioni o destituzione di un membro del Consiglio del GNSO, la relativa posizione sarà considerata vacante. Le posizioni vacanti dovranno essere occupate per il periodo rimanente del mandato a cura del Comitato per l'assegnazione delle nomine, il quale notificherà per iscritto al Segretario ICANN la propria selezione. Se tuttavia la posizione rimasta vacante era occupata da un membro selezionato da una Circoscrizione, sarà cura di quest'ultima provvedere alla nomina di un nuovo membro per il periodo rimanente del mandato e notificare per iscritto al Segretario ICANN la propria selezione.
4. Il Consiglio del GNSO è responsabile della gestione del processo di sviluppo delle Policy del GNSO. Avrà il compito di adottare le procedure che riterrà opportune per svolgere tale funzione, purché tali procedure siano approvate dal Consiglio direttivo e purché si attenga, fino a quando le eventuali modifiche proposte dal Consiglio del GNSO non saranno approvate dal Consiglio direttivo, alle procedure applicabili descritte alla Sezione 6 di questo Articolo. Inoltre, il Consiglio del GNSO è responsabile della gestione di forum aperti, sotto forma di elenco di indirizzi (mailing list) o altro, per consentire a tutti coloro che lo desiderano di contribuire al lavoro del GNSO; tali forum dovranno essere appropriatamente moderati per garantire la massima concentrazione sulle attività del GNSO e ridurre al minimo gli interventi non pertinenti e ingiuriosi.
5. Solo un funzionario, dirigente o dipendente di una società o altra associazione (ivi comprese le controllate e le affiliate) avrà la facoltà di far parte del Consiglio del GNSO in qualsiasi momento.
6. Il Consiglio del GNSO selezionerà i soggetti destinati ad occupare le Posizioni 13 e 14 del Consiglio direttivo dell'ICANN tramite votazione scritta o tramite azione nel corso di una riunione; ogni selezione così effettuata richiede il voto favorevole della maggioranza di tutti i membri del Consiglio del GNSO. Il Presidente del Consiglio del GNSO ha il dovere di informare per iscritto il Segretario ICANN delle selezioni effettuate dal Consiglio, in conformità con le disposizioni dell'Articolo VI, Sezioni 8(4) e 12(1).
7. Il Consiglio del GNSO ha il compito di selezionare, tramite votazione scritta o tramite azione nel corso di una riunione, il Presidente del GNSO per un mandato che sarà cura del Consiglio stesso specificare, ma non più lungo di un anno. Tale selezione richiede il voto favorevole della maggioranza di tutti i membri del Consiglio del GNSO.
8. Fatto salvo quanto disposto al paragrafo 6 di questa Sezione, il Consiglio del GNSO opererà tramite riunioni. I membri del Consiglio del GNSO possono partecipare a una riunione del Consiglio del GNSO tramite (i) telefono per teleconferenze o analogo dispositivo di comunicazione, a patto che tutti i membri partecipanti alla riunione possano reciprocamente parlarsi e udirsi o (ii) dispositivo di comunicazione elettronica a schermo o altro dispositivo di comunicazione; a patto che (a) tutti i membri partecipanti alla riunione possano reciprocamente parlarsi e udirsi, (b) tutti i membri abbiano la possibilità di intervenire a pieno di fronte al Consiglio del GNSO in tutte le questioni prese in esame e (c) ICANN adotti e implementi un sistema che consenta di verificare che (x) un soggetto partecipante alla riunione è un membro del Consiglio del GNSO o altro soggetto avente diritto di partecipazione e (y) tutte le azioni intraprese o i voti espressi dal Consiglio del GNSO siano rispettivamente intraprese o espressi solo da membri di quest'ultimo e non da persone che non ne sono membri. La maggioranza del totale dei membri del Consiglio del GNSO aventi diritto di voto in carica in quel momento costituirà un quorum in grado di deliberare sulle questioni all'esame del Consiglio e gli atti deliberati tramite voto di maggioranza da tale quorum saranno considerati atti dell'intero Comitato, salvo laddove diversamente disposto dal presente Statuto. Vedere la Sezione 5(2) di questo Articolo sul numero di voti che i membri del Consiglio del GNSO possono esprimere. L'avviso di convocazione di tali riunioni dovrà essere pubblicato sul sito Web, se ragionevolmente fattibile, almeno 7 giorni prima della riunione stessa. Salvo laddove un voto di maggioranza (vedere la Sezione 5(2) di questo Articolo) dei membri del Consiglio del GNSO stabilisca che una sessione a porte chiuse è indicata, tutti i soggetti interessati potranno presenziare alle riunioni, sia di persona sia tramite sistema elettronico. Il Consiglio del GNSO trasmetterà i verbali delle proprie riunioni al Segretario ICANN, il quale provvederà a farli pubblicare sul sito Web non appena possibile dopo il termine della riunione e comunque entro e non oltre i 21 giorni successivi.
9. Il Consiglio del GNSO può concordare con il consiglio di qualsiasi altra organizzazione di sostegno di ICANN lo scambio di osservatori. Tali osservatori non saranno membri del Consiglio del GNSO e non godranno del diritto di voto, ma saranno a parte questo sullo stesso piano degli altri membri del Consiglio. Il consiglio che effettua la nomina dovrà designare il proprio osservatore (o revocarne la nomina o cambiarne la designazione) presso il Consiglio del GNSO facendone pervenire la notifica scritta al Presidente del Consiglio del GNSO e al Segretario ICANN.
Sezione 4. SUPPORTO E FINANZIAMENTO DELLO STAFF
1. Un membro dello staff di ICANN deve essere incaricato del supporto del GNSO. Sarà designato come GNSO Staff Manager (Staff Manager) e il lavoro concernente questioni rilevanti gli sarà assegnato dal Presidente del Consiglio del GNSO.
2. ICANN fornirà il supporto amministrativo e operativo necessario per consentire al GNSO di svolgere le proprie funzioni. Tale supporto non implica in alcun modo che ICANN è tenuta a coprire le spese di viaggio sostenute dai membri del GNSO per partecipare alle riunioni di quest'ultimo o per altri motivi.
1. Le seguenti Circoscrizioni autocostituite sono con la presente riconosciute come rappresentative di un gruppo specifico e significativo di soggetti interessati e, fatte salve le disposizioni dell'Articolo di Transizione del presente Statuto, selezioneranno ognuna due rappresentanti per il Consiglio del GNSO:
a. Registri gTLD (in rappresentanza di tutti i registri gTLD sotto contratto con ICANN);
b. Registrar (in rappresentanza di tutti i registrar sotto contratto con ICANN o da esso accreditati);
c. Internet Service and Connectivity Provider (in rappresentanza di tutte le entità che forniscono servizi e connettività agli utenti Internet);
d. Utenti commerciali e aziendali (in rappresentanza di utenti Internet commerciali sia di piccola che di grande entità);
e. Utenti non commerciali (in rappresentanza dell'intera gamma di utenti non commerciali di Internet); e
f. Soggetti interessati dalla proprietà intellettuale (in rappresentanza di tutti i soggetti interessati dai marchi e alla proprietà intellettuale per quanto attiene al DNS).
2. Il numero di voti che i membri del Consiglio del GNSO possono esprimere saranno equalizzati di modo che il numero aggregato di voti dei rappresentanti selezionati dalle Circoscrizioni (attualmente i Registri gTLD e i Registrar) che sono sotto contratto con ICANN e quindi tenuti ad implementare le Policy adottate da ICANN sia pari al numero dei voti dei rappresentanti selezionati dalle altre Circoscrizioni. In un primo momento, ciascun membro del Consiglio del GNSO selezionato dalla Circoscrizione dei Registri gTLD e da quella dei Registrar avrà il diritto di esprimere due voti, mentre tutti gli altri membri (ivi compresi quelli selezionati dal Comitato per l'assegnazione delle nomine) avrà il diritto di esprimere un solo voto. Qualora dovessero intervenire delle variazioni nelle Circoscrizioni che hanno il diritto di selezionare membri del Consiglio del GNSO con facoltà di voto, il Consiglio direttivo esaminerà le mutate circostanze e, tramite risoluzione, modificherà la procedura di equalizzazione dei voti in maniera coerente con quanto disposto dal presente paragrafo 2.
3. Ciascuna Circoscrizione indicata al paragrafo 1 di questa Sezione resterà riconosciuta e, di conseguenza, competente a selezionare rappresentanti per il Consiglio del GNSO, solo fintantoché rappresenterà effettivamente gli interessi globali delle community di soggetti interessati che dichiara di rappresentare e dovrà agire, nella massima misura possibile, in maniera trasparente e coerente con procedure designate a garantire equità. Nessuna persona fisica o giuridica potrà essere esclusa da una Circoscrizione solo perché partecipa già a un'altra.
4. Qualsiasi gruppo di persone fisiche o giuridiche ha la facoltà di richiedere al Consiglio direttivo, tramite petizione, il riconoscimento come Circoscrizione nuova o separata. Siffatta petizione dovrà fornire una spiegazione dettagliata di quanto segue:
a. Il motivo per cui l'aggiunta della Circoscrizione migliorerà la capacità del GNSO di svolgere le proprie funzioni di sviluppo delle Policy; e
b. Il motivo per cui la nuova Circoscrizione proposta rappresenta adeguatamente, su base globale, i soggetti interessati che si propone di rappresentare.
Qualsiasi petizione presentata per il riconoscimento di una nuova Circoscrizione dovrà essere pubblicata e resa apertamente commentabile.
5. Il Consiglio direttivo ha la facoltà di creare nuove Circoscrizioni, sia sulla scorta di tale petizione sia di propria iniziativa, qualora determinasse che una simile azione promuove gli scopi di ICANN. Nell'eventualità in cui il Consiglio direttivo prevedesse di agire di propria iniziativa, è suo dovere pubblicare una spiegazione dettagliata dei motivi per cui tale azione è necessaria o desiderabile, fissare un periodo di tempo durante il quale tale spiegazione può essere commentata apertamente e astenersi dal prendere una decisione finale sulla creazione della nuova Circoscrizione senza avere prima esaminato tutti i commenti ricevuti. Ogniqualvolta il Consiglio direttivo pubblica e rende apertamente commentabile una petizione o un suggerimento per la creazione di una nuova Circoscrizione, dovrà notificarne il Consiglio del GNSO ed esaminare le eventuali risposte prima di intraprendere qualsiasi azione.
Sezione 6. PROCESSO DI SVILUPPO DELLE POLICY
Da principio, la procedura di sviluppo delle Policy alla quale deve attenersi il GNSO sarà quella indicata all'Appendice A del presente Statuto. Tale procedura potrà essere oggetto di integrazioni o revisioni come descritto alla Sezione 3(4) di questo Articolo.
ARTICOLO XI: COMITATI CONSULTIVI
Sezione 1. DISPOSIZIONI GENERALI
Il Consiglio direttivo può creare uno o più Comitati consultivi oltre a quelli indicati nel presente Articolo. I Comitati consultivi possono essere composti da soli Direttori, da Direttori e non direttori oppure da soli non direttori e possono includere anche membri non votanti o sostituti. I Comitati consultivi non hanno l'autorità legale di agire per conto di ICANN, ma comunicano le proprie conclusioni e suggerimenti al Consiglio direttivo.
Sezione 2. COMITATI CONSULTIVI SPECIFICI
I Comitati consultivi saranno come minimo i seguenti:
1. Comitato consultivo governativo
a. Il Comitato consultivo governativo esamina e fornisce pareri sulle attività di ICANN relative a questioni di interesse per gli organi statali, in particolare questioni in cui le Policy di ICANN e le diverse leggi e i vari accordi internazionali potrebbero interagire oppure casi in cui le Policy di ICANN potrebbero avere ripercussioni su questioni di Policy pubbliche.
b. Tutti i governi nazionali possono essere membri del Comitato consultivo governativo. Anche le Economie Distinte riconosciute dai fori internazionali nonché le organizzazioni governative multinazionali e quelle basate su trattati, possono essere membri, se invitate dal Comitato stesso nella persona del Presidente.
c. Il Comitato consultivo governativo può adottare uno statuto proprio nonché procedure o principi operativi interni per guidare le proprie attività. Questi dovranno essere pubblicati sul sito Web.
d. Il Presidente del Comitato consultivo governativo viene eletto dai membri del Comitato stesso seguendo le procedure adottate da tali membri.
e. Ciascun membro del Comitato consultivo governativo nominerà un proprio rappresentante accreditato presso il Comitato. Il rappresentante accreditato di un membro deve occupare una posizione ufficiale formale nella pubblica amministrazione di quel membro. Il termine "ufficiale" indica che la persona ricopre un incarico di governo oppure lavora per tale governo, autorità pubblica, ente multinazionale o organizzazione basata su trattati e la sua funzione principale all'interno di tale governo, autorità pubblica o organizzazione è sviluppare o influenzare le politiche di governo o pubbliche.
f. Con cadenza annuale, il Comitato consultivo governativo nominerà al Consiglio direttivo di ICANN un funzionario di collegamento senza diritto di voto e senza limiti di rinnovo della nomina e al Comitato per l'assegnazione delle nomine di ICANN un funzionario di collegamento senza diritto di voto.
g. Il Comitato consultivo governativo può designare un funzionario di collegamento senza diritto di voto per ciascun Consiglio delle organizzazioni di sostegno e Comitato consultivo, nella misura in cui esso lo riterrà opportuno e utile.
h. Il Consiglio direttivo deve notificare con tempestività al Presidente del Comitato consultivo governativo qualsiasi proposta sollevi questioni pubbliche relative alle Policy per le quali le organizzazioni di sostegno di ICANN o i Comitati consultivi richiedono un commento del pubblico e, prima di intraprendere qualsiasi azione, deve prendere in dovuta considerazione qualsiasi risposta tempestiva a tale notifica.
i. Il Comitato consultivo governativo può sottoporre le questioni direttamente all'esame del Consiglio direttivo, sia sotto forma di commento o precedente consiglio, sia sotto forma di specifico suggerimento per lo sviluppo di nuove Policy o la revisione di quelle esistenti.
j. Il parere del Comitato consultivo governativo su questioni di Policy pubbliche dovrà essere tenuto in debita considerazione, sia per quanto riguarda la formulazione delle Policy sia per quanto riguarda la loro adozione. Nel caso in cui il Consiglio direttivo di ICANN determinasse di intraprendere azioni non coerenti con il parere del Comitato consultivo governativo, ne deve informare il Comitato stesso e deve spiegare i motivi per cui ha deciso di non seguire tale parere. Il Comitato consultivo governativo e il Consiglio direttivo di ICANN si adopereranno, quindi, in buona fede nonché in maniera tempestiva ed efficiente, per trovare una soluzione reciprocamente accettabile.
k. Se non fosse possibile addivenire a tale soluzione, il Consiglio direttivo di ICANN esporrà nella sua decisione finale i motivi per cui il parere del Comitato consultivo governativo non è stato seguito e tale dichiarazione non pregiudicherà né gli obblighi né i diritti del Comitato per quanto attiene alle questioni di sua competenza relative alle Policy pubbliche.
2. Security and Stability Advisory Committee
a. Il ruolo di Security and Stability Advisory Committee (comitato consultivo per la sicurezza e la stabilità, "SAC") è di fornire alla community e al Consiglio direttivo di ICANN il proprio parere sulle questioni relative alla sicurezza e all'integrità dei sistemi di allocazione dei nomi e degli indirizzi Internet. Ha le seguenti responsabilità:
1. Sviluppare un ambito di riferimento per i servizi di allocazione dei nomi e degli indirizzi Internet che definisca le principali aree di intervento e identifichi i soggetti responsabili di ciascuna area. Il comitato dovrà concentrare la propria attenzione su questioni operative concernenti infrastrutture fondamentali per l'assegnazione dei nomi.
2. Comunicare su questioni di sicurezza con la community tecnica di Internet nonché gli operatori e i gestori di vitali servizi di infrastruttura DNS, ivi compresi la community degli operatori di root name server, i registri e i registrar dei domini di primo livello, gli operatori dei reverse delegation tree, come ad esempio in-addr.arpa e ip6.arpa, e altri soggetti di volta in volta necessari sulla base degli eventi e degli sviluppi. Il Comitato ha il compito di raccogliere e indicare i requisiti da presentare ai soggetti incaricati di rivedere i protocolli relativi ai DNS e all'allocazione degli indirizzi nonché i requisiti da presentare ai soggetti incaricati di pianificare le operazioni.
3. Condurre su base continuativa un'analisi del rischio e una stima delle minacce per quanto riguarda i servizi di allocazione dei nomi e degli indirizzi Internet, per individuare le principali vulnerabilità in materia di stabilità e sicurezza e presentare alla community di ICANN il proprio parere in merito. Il Comitato proporrà tutte le azioni di revisione necessarie per stimare lo stato corrente del DNS e garantire la sicurezza delle allocazioni sulla base dei rischi e delle minacce individuate.
4. Tenersi in comunicazione con i soggetti direttamente responsabili delle questioni relative alla sicurezza dell'allocazione dei nomi e degli indirizzi Internet (IETF, RSSAC, RIR, registri dei nomi, ecc.), per garantire che il proprio parere sui rischi, sui problemi e sulle priorità sia correttamente sincronizzato con le attività esistenti di standardizzazione, distribuzione, operatività e coordinamento. Il Comitato ha il compito di monitorare queste attività e informare la community e il Consiglio direttivo di ICANN del relativo progresso, se appropriato.
5. Riferire periodicamente al Consiglio direttivo sulle proprie attività.
6. Suggerire Policy alla community e al Consiglio direttivo di ICANN.
b. Il Presidente e i membri del SAC sono nominati dal Consiglio direttivo.
c. Il SAC nominerà su base annua un funzionario di collegamento senza diritto di voto al Consiglio direttivo di ICANN in base alla Sezione 9 dell'Articolo VI.
3. Comitato consultivo del sistema root server
a. Il ruolo del Comitato consultivo del sistema root server ("RSSAC") è quello di fornire al Consiglio direttivo consigli sul funzionamento dei root name server del sistema dei nomi di dominio. L'RSSAC fa una valutazione e fornisce consigli sui requisiti di funzionamento dei root name server, ivi compresa la capacità hardware di hosting, i sistemi operativi e le versioni del software per name server, la connettività di rete e l'ambiente fisico. Sarà compito dell'RSSAC esaminare le questioni di sicurezza del sistema root name server e fornire un proprio parere in merito. L'RSSAC dovrà inoltre esaminare il numero, l'ubicazione e la distribuzione dei root name server facendo particolare attenzione alle prestazioni, solidità e affidabilità del sistema totale.
b. L'RSSAC sarà composto da (i) ciascun operatore di un root name server ufficiale (come da elenco all'indirizzo <> ) e (ii) altri soggetti nominati dal Consiglio direttivo di ICANN.>
c. Il primo Presidente del Comitato consultivo del sistema root server DNS sarà nominato dal Consiglio direttivo; i Presidenti successivi saranno nominati dal Comitato consultivo del sistema root server del DNS seguendo le procedure adottate dai suoi membri.
d. Con cadenza annuale, il Comitato consultivo del sistema root server nominerà al Consiglio direttivo di ICANN un funzionario di collegamento senza diritto di voto e senza limiti di rinnovo della nomina e al Comitato per l'assegnazione delle nomine di ICANN un funzionario di collegamento senza diritto di voto.
4. At-Large Advisory Committee
a. Il ruolo del At-Large Advisory Committee (comitato consultivo At-Large, "ALAC") è di valutare e fornire il proprio parere sulle attività di ICANN laddove queste riguardino gli interessi dei singoli utenti di Internet.
b. il Comitato ALAC sarà composto da (i) due membri selezionati da ciascuna organizzazione At-Large regionale ("RALO") istituita secondo quanto previsto al paragrafo 4(g) di questa Sezionee (ii) cinque membri selezionati dal Comitato per l'assegnazione delle nomine. I cinque membri selezionati dal Comitato per l'assegnazione delle nomine devono provenire ognuno da ciascuna delle cinque Regioni Geografiche previste dalla Sezione 5 dell'Articolo VI.
c. Fatto salvo quanto disposto dall'Articolo di Transizione del presente Statuto, la durata regolare di un mandato dei membri del Comitato ALAC sarà la seguente:
1. Il mandato di uno dei due membri selezionati da ogni RALO inizierà alla conclusione di una riunione annuale di ICANN in un anno pari.
2. Il mandato dell'altro dei due membri selezionati da ciascuna RALO inizierà alla conclusione di una riunione annuale di ICANN in un anno dispari.
3. Il mandato di tre membri selezionati dal Comitato per l'assegnazione delle nomine inizierà alla conclusione di una riunione annuale di un anno dispari mentre il mandato degli altri due membri selezionati dal Comitato per l'assegnazione delle nomine inizierà alla conclusione di una riunione annuale di un anno pari.
4. Il mandato regolare di ciascun membro terminerà alla conclusione della seconda riunione annuale di ICANN dopo l'inizio del mandato.
d. Il Presidente del Comitato ALAC viene eletto dai membri dell'ALAC seguendo le procedure adottate dal Comitato stesso.
e. Con cadenza annuale, il Comitato ALAC nominerà al Consiglio direttivo di ICANN un funzionario di collegamento senza diritto di voto e senza limiti di rinnovo della nomina e, dietro consultazione con ciascuna RALO, nominerà cinque delegati con diritto di voto (ognuno cittadino di un paese di una Regione Geografica diversa, come indicato alla Sezione 5 dell'Articolo VI) al Comitato per l'assegnazione delle nomine.
f. Fatto salvo quanto disposto dall'Articolo di Transizione del presente Statuto, il At-Large Advisory Committee può designare un funzionario di collegamento senza diritto di voto per il Consiglio di ccNSO e uno per il Consiglio del GNSO.
g. Per ciascuna Regione Geografica sarà istituito un unico RALO secondo quanto disposto dalla Sezione 5 dell'Articolo VI. Ciascun RALO svolgerà la funzione di forum e punto di coordinamento principale per i suggerimenti pubblici indirizzati a ICANN nelle relative Regioni Geografiche e dovrà essere un'organizzazione no-profit certificata da ICANN secondo i criteri e gli standard stabiliti dal Consiglio direttivo sulla base dei pareri forniti dal At-Large Advisory Committee. Un'organizzazione potrà diventare il RALO della propria Regione Geografica dopo aver sottoscritto un Protocollo d'Intesa con ICANN nel quale vengono delineati i rispettivi ruoli e responsabilità di ICANN e del RALO per quanto riguarda il processo di selezione dei membri ALAC nonché indicati i requisiti di apertura, possibilità di partecipazione, trasparenza, responsabilità e diversità della struttura e delle procedure del RALO, come pure i criteri e gli standard per le strutture At-Large costituenti il RALO.
h. Ciascun RALO sarà composto da strutture At-Large autonome all'interno della propria Regione Geografica, certificate per soddisfare i requisiti del Protocollo d'Intesa del RALO con ICANN secondo quanto disposto al paragrafo 4(i) di questa Sezione. Se previsto dal Protocollo d'Intesa con ICANN, un RALO può anche includere singoli utenti Internet che sono cittadini o residenti di paesi che si trovano all'interno della Regione Geografica del RALO stesso.
i. Composizione della At-Large Community
- I criteri e gli standard di certificazione delle strutture At-Large all'interno di ciascuna Regione Geografica saranno stabiliti dal Consiglio direttivo sulla base dei suggerimenti del Comitato ALAC e saranno indicati nel Protocollo d'Intesa tra ICANN e il RALO di ciascuna Regione Geografica.
- I criteri e gli standard di certificazione delle strutture At-Large saranno stabiliti in maniera tale da garantire che la partecipazione di singoli utenti Internet già cittadini o residenti di paesi della Regione Geografica (secondo quanto definito alla Sezione 5 dell'Articolo VI) del RALO sia predominante nel funzionamento di ciascuna struttura At-Large all'interno del RALO stesso, senza tuttavia necessariamente escludere la partecipazione aggiuntiva di altri soggetti, compatibilmente con gli interessi dei singoli utenti Internet della regione.
- Il Protocollo d'Intesa di ciascun RALO dovrà inoltre includere disposizioni che consentano, nella massima misura possibile, a ogni utente singolo di Internet cittadino di un paese della Regione Geografica del RALO di partecipare ad almeno una delle strutture At-Large del RALO stesso.
- Nella misura compatibile con i presenti obiettivi, i criteri e gli standard dovrebbero anche consentire a ciascun RALO l'adozione del tipo di struttura più indicato agli usi e alle caratteristiche della relativa Regione Geografica.
- Una volta stabiliti i criteri e gli standard secondo quanto disposto dalla presente Clausola i, il Comitato ALAC, con il parere e la partecipazione del RALO presso cui il richiedente risiede, sarà responsabile di certificare le organizzazioni che soddisfano i criteri e gli standard per l'accreditamento come strutture At-Large.
- La decisione di concedere o revocare la certificazione come struttura At-Large dovrà essere presa secondo le modalità stabilite dal Comitato ALAC nelle proprie Regole procedurali, fermo restando che qualsiasi modifica alle Regole procedurali per quanto riguarda le domande di certificazione ALS sarà soggetta al controllo da parte dei RALO e del Consiglio direttivo di ICANN.
- La decisione di concedere, non concedere o revocare la certificazione come struttura At-Large è soggetta a revisione conformemente alle procedure stabilite dal Consiglio direttivo.
- Su base permanente, il Comitato ALAC può inoltre fornire il proprio parere sulla conformità di una struttura At-Large con i criteri e gli standard applicabili.
j. Il Comitato ALAC è inoltre responsabile, in collaborazione con i RALO, della coordinazione delle seguenti attività:
1. Divulgazione delle notizie più importanti di ICANN alla community dei singoli utenti Internet;
2. Distribuzione (tramite pubblicazione o altro) di un'agenda aggiornata, di notizie su ICANN e di informazioni sugli elementi che concorrono al processo di sviluppo delle Policy ICANN;
3. Promozione di attività ad ampio raggio nella community dei singoli utenti Internet;
4. Sviluppo e mantenimento di programmi di informazione e istruzione su ICANN e relative attività;
5. Creazione di una strategia ad ampio raggio in ciascuna regione di un RALO su questioni relative a ICANN;
6. Divulgazione e analisi delle Policy proposte da ICANN e delle decisioni di quest'ultimo nonché dell'impatto (potenziale) regionale di tali Policy e del relativo effetto (potenziale) sui soggetti della Regione;
7. Offerta di meccanismi basati su Internet che consentono dibattiti tra i membri di strutture At-Large; e
8. Creazione di meccanismi e processi che permettano la comunicazione reciproca tra i membri di strutture At-Large e quelli coinvolti nei processi decisionali di ICANN, per consentire ai soggetti interessati di condividere le proprie opinioni su questioni relative a ICANN ancora in sospeso.
Ciascun Comitato consultivo determinerà le proprie regole procedurali e per il quorum.
Il mandato del Presidente e di ciascun membro di un Comitato durerà fino alla nomina di un successore ovvero, se tale evento si verifica prima, fino allo scioglimento del Comitato stesso ovvero fino alla rimozione del soggetto interessato o alle sue dimissioni o fino a quando esso cessa, per altri motivi, di essere idoneo per il Comitato.
Le posizioni vacanti di qualsiasi Comitato verranno occupate seguendo la stessa procedura prevista per le nomine originali.
I membri dei Comitati non riceveranno alcuna remunerazione per il servizio prestato in quanto tali. Il Consiglio direttivo ha tuttavia la facoltà di autorizzare il rimborso di spese effettive e necessarie sostenute dai membri dei Comitati, Direttori inclusi, nello svolgimento delle loro funzioni.
ARTICOLO XI-A: ALTRI MECCANISMI DI CONSULTAZIONE
Sezione 1. PARERE DI ESPERTI ESTERNI
1. Scopo. La richiesta di un parere esperto esterno ha lo scopo di consentire al processo di sviluppo delle Policy all'interno di ICANN di avvantaggiarsi dell'esperienza esistente nel settore pubblico o privato all'esterno di ICANN. Nei casi in cui vi siano organi pubblici competenti e dotati di esperienza o nei casi in cui l'esperienza privata potrebbe essere utile, il Consiglio direttivo e gli organi costituenti sono incoraggiati ad ascoltare il parere di tali organi o soggetti esperti.
2. Tipi di commissioni di esperti.
a. Di propria iniziativa o dietro suggerimento di un qualsiasi organo ICANN, il Consiglio direttivo può nominare, o autorizzare il Presidente a nominare, una Commissione di esperti composta da persone fisiche o giuridiche del settore pubblico o privato. Se il parere richiesto a tali Commissioni di esperti riguarda questioni relative a Policy pubbliche, le disposizioni della Sezione 1(3)(b) di questo Articolo saranno applicabili.
b. Inoltre, in conformità alla Sezione 1(3) di questo Articolo, il Consiglio direttivo può rimettere a un'organizzazione multinazionale governativa o basata su trattati questioni relative a Policy pubbliche concernenti argomenti che ricadono nell'ambito della dichiarazione programmatica di ICANN.
3. Processo per richiedere un parere in questioni di Policy pubbliche.
a. Il Comitato consultivo governativo può, in qualsiasi momento, suggerire al Consiglio direttivo di raccogliere il parere di una fonte esterna su una o più questioni relative a Policy pubbliche, come descritto in precedenza.
b. Se il Consiglio direttivo stabilisce, sulla scorta di tale suggerimento o altrimenti, che è necessario il parere di una fonte esterna su una o più questioni relative a Policy pubbliche, il Consiglio si consulterà, se appropriato, con il Comitato consultivo governativo per individuare il soggetto appropriato a cui richiedere tale parere ed elaborare la modalità, ivi compreso stabilire ambiti e modalità, per richiederlo e ottenerlo.
c. Se appropriato, il Consiglio direttivo trasmetterà al Comitato consultivo governativo qualsiasi domanda in base alla quale si richiede il parere di un'organizzazione multinazionale governativa o basata su trattati, ivi compresi specifici termini di riferimento, accompagnando tale domanda con il suggerimento che essa venga inoltrata dal Comitato consultivo governativo all'organizzazione multinazionale governativa o basata su trattati.
4. Processo per richiedere un parere in altre questioni. Nei casi che non riguardano questioni di Policy pubbliche, la richiesta del Consiglio direttivo o del presidente di ottenere il parere di una Commissione di esperti in conformità alla Sezione 1(2)(a) di questo Articolo dovrà essere coerente con i termini di riferimento utilizzati per descrivere le questioni su cui si richiede un parere nonché precisare le procedure e la tabella di marcia da seguire.
5. Ricezione del parere degli esperti e relativi effetti. Il parere esterno richiesto ai sensi di questa Sezione dovrà essere sotto forma scritta. Tale parere ha un valore unicamente consultivo e non vincolante e il suo scopo è quello di ampliare le informazioni disponibili al Consiglio direttivo o altro organo ICANN per lo svolgimento delle relative funzioni.
6. Possibilità di commentare. Il Comitato consultivo governativo, nonché le organizzazioni di sostegno e gli altri Comitati consultivi, avranno la possibilità di commentare il parere esterno ricevuto prima che il Consiglio direttivo prenda una decisione.
Sezione 2. GRUPPO DI COLLEGAMENTO TECNICO
1. Scopo. La qualità dell'opera svolta da ICANN dipende dalla possibilità di accedere a informazioni complete e competenti sugli standard tecnici che stanno alla base delle attività di ICANN stessa. Per questo motivo, il rapporto tra ICANN e le organizzazioni che stabiliscono tali standard è particolarmente importante. Il Gruppo di collegamento tecnico (TLG) avrà il compito di stabilire un collegamento tra il Consiglio direttivo e le fonti di informazioni tecniche su questioni pertinenti alle attività di ICANN.
2. Organizzazioni TLG. Il TLG sarà composto da quattro organizzazioni: lo European Telecommunications Standards Institute (ETSI), l'International Telecommunications Union's Telecommunication Standardization Sector (ITU-T), il World Wide Web Consortium (W3C) e l'Internet Architecture Board (IAB).
3. Ruolo. Il ruolo delle organizzazioni TLG sarà quello di incanalare informazioni tecniche e consigli verso il Consiglio direttivo e altre entità ICANN. Tale ruolo ha sia una componente che interviene solo su richiesta, sia una componente attiva "di sorveglianza" che comportano le seguenti responsabilità:
a. In risposta a una richiesta di informazioni, mettere in comunicazione il Consiglio direttivo o altro organo ICANN con la fonte corretta per un parere tecnico esperto. Questa componente del ruolo TLG riguarda le circostanze in cui ICANN cerca una risposta competente a una domanda tecnica specifica. Se sono necessarie informazioni su uno standard tecnico particolare del quale è responsabile un'organizzazione TLG, tale richiesta dovrà essere indirizzata all'organizzazione competente.
b. Nell'ambito di un'attività "di vigilanza" costante, informare il Consiglio amministrativo della pertinenza e dell'avanzamento degli sviluppi tecnici in corso nelle aree di competenza di ciascuna organizzazione e in grado di influenzare le decisioni del Consiglio direttivo o altre azioni di ICANN, nonché richiamare l'attenzione su questioni relative agli standard tecnici globali capaci di influenzare lo sviluppo delle Policy nell'ambito della dichiarazione programmatica di ICANN. Questa componente del ruolo TLG riguarda le circostanze in cui ICANN è all'oscuro di un nuovo sviluppo e non è quindi in grado di sapere che una domanda dovrebbe essere posta.
4. Procedure di TLG. TLG non ha funzionari, non tiene riunioni e non si affianca ai comitati nella proposta di politiche al Consiglio, sebbene il Consiglio possa chiedere la pronuncia delle singole organizzazioni TLG ove ciò si renda necessario negli ambiti di competenza dei rispettivi statuti. TLG non promuoverà né coordinerà confronti su temi di natura tecnica tra le diverse organizzazioni TLG, non stabilirà né tenterà di stabilire posizioni congiunte e non creerà né tenterà di creare strutture o livelli ulteriori al proprio interno né per lo sviluppo di standard tecnici né per qualsiasi altro scopo.
5. Ruolo tecnico di IANA. TLG non parteciperà al lavoro di IANA per IETF (Internet Engineering Task Force), IRTF (Internet Research Task Force) o IAB (Internet Architecture Board), come descritto nel Protocollo d'Intesa sul Ruolo tecnico di IANA (Internet Assigned Numbers Authority) ratificato dal Consiglio il 10 marzo del 2000.
6. Tecnici esperti indipendenti. Ogni organizzazione TLG designerà due tecnici esperti degli standard attinenti alle attività di ICANN. Tali otto esperti provvederanno a determinare, tramite scambio di e-mail, chi debba rispondere a eventuali richieste tecniche di ICANN non esplicitamente rivolte a una specifica organizzazione TLG.
7. Funzionario di collegamento al Consiglio e delegato al Comitato per l'assegnazione delle nomine. Ogni anno, a rotazione, una delle organizzazioni TLG nominerà un funzionario di collegamento non votante al Consiglio, come previsto dall'Articolo VI, Sezione 9(1)(d). Ogni anno, a rotazione, una delle organizzazioni TLG selezionerà un delegato votante al Comitato di ICANN per l'assegnazione delle nomine, come previsto dall'Articolo VII, Sezione 2(8)(j). L'ordine di rotazione per la nomina del funzionario di collegamento non votante al Consiglio sarà ETSI, ITU-T e W3C. L'ordine di rotazione per la selezione del delegato al Comitato per l'assegnazione delle nomine sarà W3C, ETSI e ITU-T. IAB non partecipa alle rotazioni in quanto IETF nomina un funzionario di collegamento non votante al Consiglio e seleziona un delegato al Comitato di ICANN per l'assegnazione delle nomine.
ARTICOLO XII: COMITATI DEL CONSIGLIO E TEMPORANEI
Sezione 1. COMITATI DEL CONSIGLIO
Il Consiglio può istituire uno o più Comitati del Consiglio, che resteranno attivi fino a nuova pronuncia del Consiglio. Solo i direttori possono essere nominati membri di un Comitato del Consiglio. Se un membro di un Comitato del Consiglio decade dalla carica di direttore, cessa anche di essere membro del Comitato del Consiglio. Ogni Comitato del Consiglio sarà costituito da due o più direttori. Per ciascun membro del comitato, il Consiglio può nominare uno o più direttori sostituti che presiederanno alle riunioni del comitato in assenza dei membri designati. I membri dei comitati possono essere rimossi dalla carica in qualsiasi momento con il voto favorevole dei due terzi (2/3) del Consiglio. I membri oggetto del voto di rimozione saranno esclusi dalla votazione e non saranno conteggiati come membri del Consiglio nel calcolo dei due terzi (2/3) previsto dalla procedura. In nessun caso un direttore potrà essere comunque rimosso da un comitato quando tale rimozione non sia approvata dalla maggioranza di tutti i membri del Consiglio.
Sezione 2. POTERI DEI COMITATI DEL CONSIGLIO
1. Il Consiglio può delegare ai Comitati del Consiglio la propria autorità legale, fatta eccezione per:
a. La copertura dei posti vacanti nel Consiglio o nei comitati;
b. L'emendamento o l'abrogazione dello statuto o di articoli di incorporazione o l'adozione di un nuovo statuto o di nuovi articoli di incorporazione;
c. L'emendamento o l'abrogazione di risoluzioni del Consiglio che escludono espressamente la delega dell'emendamento o dell'abrogazione;
d. La nomina di Comitati del Consiglio o dei relativi membri;
e. L'approvazione di transazioni a proprio beneficio, come definite nella Sezione 5233(a) di CNPBCL;
f. L'approvazione del bilancio annuale, come indicato nell'Articolo XVI; o
g. Il compenso dei funzionari descritti all'Articolo XIII.
2. Il Consiglio avrà facoltà di prescrivere i termini dell'operato di ogni comitato del Consiglio. In mancanza di tale prescrizione, il comitato potrà definire autonomamente le modalità del proprio operato. Ove non sia disposto diversamente da questo statuto, dal Consiglio o dai comitati, le riunioni ordinarie e straordinarie si terranno come previsto nell'Articolo VI in merito alle riunioni e agli atti del Consiglio. Ogni comitato stilerà regolari verbali dei propri atti e li trasmetterà periodicamente al Consiglio quando richiesto.
Sezione 3. COMITATI TEMPORANEI
Il Consiglio ha facoltà di istituire i Comitati temporanei che ritiene opportuni, con i relativi membri, compiti e responsabilità, come previsto nelle risoluzioni o negli statuti adottati dal Consiglio in materia.
I funzionari di ICANN saranno un Presidente (con funzioni di Amministratore delegato), un Segretario e un Direttore finanziario. A discrezione del Consiglio, ICANN può inoltre avvalersi di ulteriori funzionari in base alle necessità. Chiunque, eccetto il Presidente, può rivestire più di una carica, ma nessun membro del Consiglio (tranne il Presidente) può essere contemporaneamente funzionario di ICANN.
Sezione 2. ELEZIONE DEI FUNZIONARI
I funzionari di ICANN saranno eletti annualmente dal Consiglio, sentito il parere del Presidente o, nel caso del Presidente, sentito il parere del Presidente del Comitato direttivo di ICANN. Ogni funzionario resterà in carica fino all'elezione del proprio successore o fino a dimissioni, rimozione o dichiarazione di inidoneità.
Sezione 3. RIMOZIONE DEI FUNZIONARI
Tutti i funzionari possono essere rimossi, con provvedimento motivato o meno, mediante il voto favorevole dei due terzi (2/3) del Consiglio. I poteri e i compiti delle cariche eventualmente rimaste vacanti per morte, dimissioni, rimozione, dichiarazione di inidoneità di un funzionario o per qualsiasi altra ragione, possono essere assegnati dal Consiglio a un funzionario o a un direttore diverso fino all'elezione del successore.
Il Presidente sarà l'Amministratore delegato di ICANN a tutti gli effetti. Tutti gli altri funzionari e i membri del personale faranno capo al Presidente o al suo delegato, se non specificato diversamente in questo statuto. Il Presidente sarà membro d'ufficio del Consiglio e godrà degli stessi diritti e privilegi degli altri membri. Il Presidente avrà facoltà di convocare riunioni straordinarie del Consiglio come indicato in questo documento e assolverà agli altri compiti previsti da questo Statuto e assegnatigli di volta in volta dal Consiglio.
Il Segretario provvederà personalmente o indirettamente a tenere i verbali del Consiglio in uno o più registri dedicati, avrà cura che tutte le comunicazioni vengano debitamente diramate come prescritto da questo statuto e dalla legge vigente e in generale assolverà a tutti i compiti assegnatigli di volta in volta dal Presidente del Consiglio.
Sezione 6. DIRETTORE FINANZIARIO
Il Direttore finanziario sarà il direttore finanziario di ICANN. Se richiesto dal Consiglio, il Direttore finanziario darà prova dell'accurato espletamento dei propri compiti nella forma e con le garanzie richieste dal Consiglio. Il Direttore finanziario avrà in custodia tutti i fondi di ICANN e annoterà personalmente o indirettamente, in modo completo e accurato, tutte le entrate e le uscite su registri di proprietà di ICANN. Depositerà inoltre tutto il denaro e gli altri valori in nome di ICANN dove appositamente specificato dal Consiglio. Il Direttore finanziario attingerà ai fondi di ICANN per gli esborsi disposti dal Consiglio o dal Presidente e su richiesta trasmetterà al Consiglio o al Presidente il rendiconto delle transazioni eseguite e della condizione finanziaria di ICANN. Il Direttore finanziario sarà responsabile della programmazione e previsione finanziaria e assisterà il Presidente nella preparazione del bilancio annuale di ICANN. Il Direttore finanziario coordinerà e vigilerà sui flussi finanziari di ICANN esercitando anche un'attività di monitoraggio e di analisi su ICANN e sulle relative organizzazioni di sostegno. Il Direttore finanziario sarà responsabile di tutti i problemi relativi alle operazioni finanziarie di ICANN.
Sezione 7. ULTERIORI FUNZIONARI
Oltre ai funzionari sopra indicati, il Consiglio può eleggere o nominare assistenti o ulteriori funzionari che assolveranno ai compiti loro assegnati dal Presidente o dal Consiglio.
Il compenso dei funzionari di ICANN sarà approvato dal Consiglio. Le spese sostenute dai funzionari nello svolgimento del proprio lavoro potranno essere rimborsate previa approvazione del Presidente (per i funzionari che non siano il Presidente), di un altro funzionario designato dal Consiglio (nel caso del Presidente) o del Consiglio stesso.
Sezione 9. CONFLITTI DI INTERESSI
Il Consiglio, tramite apposito comitato, definirà una procedura in base alla quale ogni funzionario, almeno una volta l'anno, dovrà rilasciare una dichiarazione che annoveri tutte le attività e le affiliazioni in qualsiasi modo correlate all'attività e alle altre affiliazioni di ICANN.
ARTICOLO XIV: RIMBORSI PER DIRETTORI, FUNZIONARI, DIPENDENTI E ALTRI AGENTI
ICANN, nella misura massima consentita da CNPBCL, rimborserà a tutti i propri agenti spese, giudizi, sanzioni, conciliazioni e altri esborsi effettivamente e ragionevolmente sostenuti in relazione a un'azione legale loro derivante dal fatto di essere o essere stati agenti di ICANN, a condizione che abbiano agito in buona fede e nella ragionevole convinzione di perseguire gli interessi di ICANN senza intenti dolosi. Ai fini di questo articolo, per "agente" di ICANN si intende chiunque sia o sia stato direttore, funzionario, dipendente o agente di ICANN (compresi i membri delle organizzazioni di sostegno, dei Comitati consultivi, dei Comitati per l'assegnazione delle nomine o di qualsiasi altro comitato di ICANN o di Technical Liaison Group) che abbia agito nell'ambito delle proprie responsabilità o chiunque stia o stesse rispondendo alle richieste di ICANN in qualità di direttore, funzionario, dipendente o in qualità di agente di un'altra azienda, società, partner, consociata o fiduciaria. Il Consiglio può adottare una risoluzione per l'acquisto e il mantenimento di un'assicurazione che tuteli gli agenti di ICANN dalle responsabilità civili eventualmente loro imputate, derivanti dall'esercizio delle proprie funzioni o emergenti dallo stato di agente in quanto tale, a prescindere dal fatto che ICANN abbia o meno la possibilità di rimborsare gli agenti in base a quanto previsto dal presente articolo.
ARTICOLO XV: DISPOSIZIONI GENERALI
Il Consiglio può autorizzare uno o più funzionari o agenti a stipulare contratti o a realizzare o distribuire qualsiasi strumentazione in nome e per conto di ICANN in via generale o limitatamente a scopi specifici. In mancanza di una diversa autorizzazione del Consiglio, contratti e strumentazioni sono appannaggio dei seguenti funzionari: Presidente, vicepresidenti o Direttore finanziario. Se non autorizzato o approvato dal Consiglio, nessun altro funzionario, agente o dipendente avrà il potere o l'autorità di impegnare o vincolare ICANN.
Tutti i fondi di ICANN non altrimenti utilizzati verranno depositati periodicamente sul conto di ICANN in banche, in fiduciarie o in altri depositi, come disposto dal Consiglio o, su delega, dal Presidente.
Tutti gli assegni, le cambiali o gli altri ordini per il pagamento di denaro, effetti o altri titoli di credito emessi in nome di ICANN dovranno essere firmati da uno o più funzionari o agenti nelle modalità stabilite di volta in volta attraverso le risoluzioni del Consiglio.
ICANN non riceverà né concederà prestiti e non emetterà titoli di credito se non espressamente previsto da una risoluzione del Consiglio. L'eventuale autorizzazione in merito potrà essere generale o limitata a circostanze specifiche. In nessun caso ICANN concederà prestiti ai propri direttori o funzionari.
La fine dell'esercizio finanziario di ICANN sarà determinata dal Consiglio.
Al termine dell'esercizio finanziario, la contabilità di ICANN verrà chiusa e sottoposta alla revisione di ragionieri iscritti all'albo. La nomina dei revisori contabili spetta al Consiglio.
Sezione 3. RELAZIONE ANNUALE E RENDICONTO DI GESTIONE
Almeno una volta l'anno il Consiglio pubblicherà una relazione sulle attività svolte corredata del rendiconto di gestione revisionato e della descrizione dei pagamenti e dei rimborsi spese eseguiti a favore dei direttori. ICANN provvederà a preparare e trasmettere la relazione annuale e il rendiconto di gestione di determinate transazioni, come indicato da CNPBCL, a ciascun membro del Consiglio e agli altri soggetti eventualmente individuati dal Consiglio, entro centoventi (120) giorni dalla chiusura dell'esercizio finanziario.
Almeno 45 (quarantacinque) giorni prima dell'inizio di ciascun esercizio finanziario di ICANN, il Presidente preparerà e sottoporrà al Consiglio la propria proposta di bilancio annuale preventivo che verrà anche pubblicata sul sito Web. Il bilancio proposto includerà una previsione delle somme e delle fonti di entrata e una stima quanto più esatta possibile delle singole voci di spesa. Il Consiglio approva il bilancio annuale e lo pubblica sul sito Web.
Il consiglio può stabilire le tariffe da applicare per il godimento dei servizi e dei benefici offerti da ICANN, con l'intento di recuperare integralmente i costi ragionevolmente riconducibili all'operato di ICANN e di alimentare un fondo ragionevole per le spese e le evenienze future ragionevolmente prevedibili in virtù delle attività di ICANN. Tali tariffe saranno eque e contenute, verranno preventivamente sottoposte a pubblica valutazione tramite pubblicazione e, una volta adottate, verranno pubblicate sul sito Web in modo sufficientemente dettagliato da essere prontamente accessibili.
ICANN non ha membri, come definito in CNPBCL (California Nonprofit Public Benefit Corporation Law), sebbene il termine "membro" possa essere utilizzato in questo statuto, nei documenti di ICANN e negli atti del Consiglio o del personale di ICANN.
ARTICOLO XVIII: SEDI E MARCHIO
ICANN avrà la propria sede principale nella Contea di Los Angeles, California, Stati Uniti. Nel tempo potrà inoltre decidere di avvalersi di ulteriori uffici all'interno o all'esterno dei confini degli Stati Uniti.
Il Consiglio può adottare un marchio aziendale e utilizzarlo in forma originale o in copia per impressione, affissione, riproduzione o in qualsiasi altro modo.
Eccetto per quanto diversamente indicato negli Articoli di incorporazione o di questo statuto è possibile modificare, emendare, abrogare o creare ulteriori Articoli di incorporazione o dello statuto di ICANN solo con il voto favorevole dei due terzi (2/3) del Consiglio.
ARTICOLO XX: ARTICOLO DI TRANSIZIONE
Questo Articolo di transizione contiene le clausole per la transizione dai processi e strutture definiti dallo statuto di ICANN, come emendati e riformulati il 29 ottobre 1999 ed emendati dal 12 febbraio 2002 ("statuto precedente"), ai processi e strutture definiti dallo statuto di cui questo articolo è parte ("nuovo statuto").
Sezione 2. CONSIGLIO DIRETTIVO
1. Per il periodo che intercorre tra l'entrata in vigore di questo Articolo di transizione e l'insediamento del nuovo Consiglio, come descritto nel paragrafo 5 di questa Sezione 2, il Consiglio direttivo aziendale ("Consiglio di transizione") sarà costituito dai membri del Consiglio che sarebbero stati direttori in base allo statuto precedente immediatamente dopo la conclusione della riunione annuale del 2002. Tali membri del Consiglio At-Large sotto lo statuto precedente che si manifestano interessati informando il Segretario del Consiglio il 15 dicembre 2002 o tramite posta o e-mail non più tardi del 23 dicembre 2002 diverranno infatti anche membri del Consiglio di transizione. Contrariamente a quanto disposto dall'Articolo VI, Sezione 12 del nuovo statuto, i posti del Consiglio di transizione rimasti vacanti non verranno occupati. Il Consiglio di transizione non disporrà di funzionari di collegamento, come disposto dall'Articolo VI, Sezione 9 del nuovo statuto. I Comitati del Consiglio esistenti alla data di entrata in vigore di questo Articolo di transizione resteranno attivi e saranno soggetti alle modifiche eventualmente disposte dal Consiglio di transizione in merito ai Comitati del Consiglio stessi e ai relativi criteri di selezione dei membri.
2. Il Consiglio di transizione eleggerà un Presidente e un Vicepresidente che resteranno in carica fino all'entrata in vigore del nuovo Consiglio.
3. Il "nuovo Consiglio" è quello descritto nell'Articolo VI, Sezione 2(1) del nuovo statuto.
4. Subito dopo l'entrata in vigore di questo Articolo di transizione, verrà formato un Comitato per l'assegnazione delle nomine che includa, per quanto possibile, i delegati e i funzionari di collegamento descritti nell'Articolo VII, Sezione 2 del nuovo statuto, con mandato in scadenza al termine della riunione annuale di ICANN del 2003. Il Comitato per l'assegnazione delle nomine procederà a selezionare senza indugi i direttori destinati a occupare le Posizioni da 1 a 8 del nuovo Consiglio, fino all'inizio del primo regolare mandato previsto per tali Posizioni nell'Articolo VI, Sezione 8(1)(a)-(c) del nuovo statuto e comunicherà per iscritto la propria scelta al Segretario di ICANN.
5. Come prescritto dal Consiglio di transizione, il nuovo Consiglio si insedierà durante la prima riunione regolare di ICANN del 2003, che si terrà trascorsi almeno sette giorni di calendario da quando il Segretario di ICANN avrà ricevuto comunicazione scritta della selezione dei direttori che occuperanno almeno dieci delle Posizioni da 1 a 14 del nuovo Consiglio. Al momento dell'insediamento, tutti i diritti, doveri e compiti del Consiglio direttivo di ICANN passeranno dal Consiglio di transizione al nuovo Consiglio. Come previsto dalla Sezione 4 di questo Articolo, i direttori (Articolo VI, Sezione 2(1)(a)-(d)) e i funzionari di collegamento non votanti (Articolo VI, Sezione 9) della cui selezione il Segretario di ICANN avrà ricevuto notifica, siederanno con il Presidente (Articolo VI, Sezione 2(1)(e)) sin dal momento dell'insediamento del nuovo Consiglio, mentre ulteriori direttori e funzionari di collegamento non votanti entreranno in carica in seguito, quando il Segretario di ICANN avrà ricevuto comunicazione della relativa selezione.
6. Il primo compito del nuovo Consiglio sarà eleggere un Presidente e un Vicepresidente. Il mandato dei nuovi funzionari del Consiglio scadrà alla fine della riunione annuale del 2003.
7. Al momento dell'insediamento del nuovo Consiglio i Comitati del Consiglio esistenti resteranno attivi secondo quanto previsto dai rispettivi statuti, mentre il mandato dei membri di tali comitati scadrà immediatamente. Al momento dell'insediamento del nuovo Consiglio i Comitati temporanei esistenti resteranno attivi e i relativi membri resteranno in carica e saranno soggetti alle modifiche eventualmente disposte dal nuovo Consiglio.
8. Nel calcolo dei limiti di mandato previsti nella Sezione 8(5) dell'Articolo VI, il servizio svolto da un direttore del Consiglio prima dell'insediamento del nuovo Consiglio verrà conteggiato come un mandato.
Sezione 3. ADDRESS SUPPORTING ORGANIZATION
ASO (Address Supporting Organization) resterà operativa in base a quanto disposto nel Protocollo d'Intesa originariamente adottato il 18 ottobre 1999 tra ICANN e un gruppo di Registri Internet regionali (RIR, Regional Internet Registries) e successivamente emendato nell'ottobre 2000, finché non verrà adottato un nuovo Protocollo d'Intesa. Subito dopo l'entrata in vigore di questo Articolo di transizione, ASO provvederà a selezionare le seguenti figure e a darne comunicazione scritta al Segretario di ICANN:
1. direttori destinati a occupare le Posizioni 9 e 10 del nuovo Consiglio fino all'inizio dei primi mandati regolari previsti per tali Posizioni dall'Articolo VI, Sezione 8(1)(d) e (e) del nuovo statuto; e
2. delegato al Comitato per l'assegnazione delle nomine selezionato dal Consiglio di ASO, come previsto dall' Articolo VII, Sezione 2(8)(f) del nuovo statuto.
In merito ai criteri di eleggibilità dei direttori di ICANN, tenendo conto della necessità di una selezione rapida che consenta al nuovo Consiglio di divenire operativo al più presto possibile, ASO potrà individuare i direttori tra le persone che aveva già selezionato come tali in base allo statuto precedente. Se ASO non comunicherà per iscritto al Segretario di ICANN la propria scelta per le Posizioni 9 e 10 entro il 31 marzo 2003, si procederà come se avesse indicato per la Posizione 9 il direttore di ICANN che aveva selezionato in base allo statuto precedente per un mandato iniziato nel 2001 e, per la Posizione 10, il direttore di ICANN che aveva selezionato in base allo statuto precedente per un mandato iniziato nel 2002.
Sezione 4. COUNTRY-CODE NAMES SUPPORTING ORGANIZATION
1. Subito dopo la designazione di trenta gestori ccTLD (almeno quattro per ogni Regione Geografica) come membri del ccNSO, ne verrà data comunicazione scritta tramite il sito Web. Appena possibile, dopo tale comunicazione, i membri di ccNSO selezioneranno i membri del primo Consiglio di ccNSO seguendo le procedure previste dall'Articolo IX, Sezione 4(8) e (9). Al termine di tale procedura di selezione, sul sito Web verrà data comunicazione della costituzione del Consiglio di ccNSO. Per ogni Regione Geografica i membri di ccNSO selezioneranno per il Consiglio di ccNSO tre membri, aventi rispettivamente mandati con scadenza al termine della prima, della seconda e della terza riunione annuale tenuta da ICANN dopo la costituzione del Consiglio di ccNSO. La definizione di "gestore ccTLD" adottata nell'Articolo IX, Sezione 4(1) e le definizioni adottate nell'Articolo IX, Sezione 4(4) sono valide nella presente Sezione 4 dell'Articolo XX.
2. Dopo l'entrata in vigore dell'Articolo IX del presente Statuto, il Comitato per l'assegnazione delle nomine selezionerà i tre membri del Consiglio di ccNSO descritti nell'Articolo IX, Sezione 3(1)(b). Il Comitato per l'assegnazione delle nomine selezionerà per il Consiglio di ccNSO tre membri, aventi rispettivamente mandati con scadenza al termine della prima, della seconda e della terza riunione annuale tenuta da ICANN dopo la costituzione del Consiglio di ccNSO. I tre membri del Consiglio di ccNSO selezionati dal Comitato per l'assegnazione delle nomine si insedieranno solo dopo la costituzione del Consiglio di ccNSO.
3. Dopo la costituzione del Consiglio di ccNSO, ALAC (At-Large Advisory Committee) e il Comitato consultivo governativo potranno designare un funzionario di collegamento ciascuno al Consiglio di ccNSO, come previsto dall' Articolo IX, Sezione 3(2)(a) e (b).
4. Una volta costituito, il Consiglio di ccNSO potrà designare organizzazioni regionali come previsto dall'Articolo IX, Sezione 5. Le organizzazioni regionali designate potranno nominare un funzionario di collegamento al Consiglio di ccNSO.
5. Le posizioni 11 e 12 del nuovo Consiglio resteranno vacanti fino alla costituzione del Consiglio di ccNSO. Una volta costituito, il Consiglio di ccNSO selezionerà immediatamente i direttori destinati a occupare le Posizioni 11 e 12 del nuovo Consiglio fino all'inizio del regolare mandato successivo previsto per ciascuna di tali Posizioni dall'Articolo VI, Sezione 8(1)(d) e (f) del nuovo statuto e comunicherà per iscritto le proprie scelte al Segretario di ICANN.
6. Fino alla costituzione del Consiglio di ccNSO, il delegato al Comitato per l'assegnazione delle nomine, che ccNSO deve selezionare in base al nuovo statuto, verrà nominato dal Consiglio di transizione o dal nuovo Consiglio, a seconda di quale organismo sarà attivo al momento in cui si renderà necessaria una determinata nomina, sentiti i membri della comunità ccTLD. Una volta costituito, il Consiglio di ccNSO potrà scegliere di sostituire il delegato al Comitato per l'assegnazione delle nomine che il Consiglio di transizione o il nuovo Consiglio avrà nominato in base alla presente Sezione 4(9). A tale scopo, dovrà indicare il nuovo delegato entro tre mesi dal termine della riunione annuale di ICANN o nel momento in cui la posizione restasse vacante. Le successive nomine del delegato al Comitato per l'assegnazione delle nomine descritte dall'Articolo VII, Sezione 2(8)(c), verranno eseguite dal Consiglio di ccNSO.
Sezione 5. GENERIC NAMES SUPPORTING ORGANIZATION
1. L'organizzazione DNSO (Domain Name Supporting Organization) cesserà le attività all'entrata in vigore di questo Articolo di transizione, ma il relativo Comitato nomi potrà ancora operare al solo scopo di autorizzare il trasferimento di eventuali fondi raccolti verso l'organizzazione GNSO (Generic Names Supporting Organization).
2. Le attività dell'organizzazione GNSO (Generic Names Supporting Organization) avranno inizio all'entrata in vigore di questo Articolo di transizione e le sei circoscrizioni DNSO seguenti diverranno automaticamente circoscrizioni GNSO, conservando inizialmente i rispettivi statuti:
a. La circoscrizione delle entità commerciali e aziendali di DNSO diverrà la Circoscrizione degli utenti commerciali e aziendali di GNSO.
b. La circoscrizione dei Registri gTLD di DNSO diverrà la Circoscrizione dei Registri gTLD di GNSO.
c. La circoscrizione degli ISP e dei provider di connettività di DNSO diverrà la Circoscrizione degli Internet Service and Connectivity Provider di GNSO.
d. La circoscrizione dei titolari di nomi a dominio non commerciali di DNSO diverrà la Circoscrizione degli utenti non commerciali di GNSO.
e. La circoscrizione dei Registrar di DNSO diverrà la Circoscrizione dei Registrar di GNSO.
f. La circoscrizione dei soggetti interessati ai marchi, alle altre proprietà intellettuali e alla lotta alla contraffazione di DNSO diverrà la Circoscrizione delle proprietà intellettuali di GNSO.
3. Nonostante l'adozione del nuovo statuto, le circoscrizioni GNSO descritte al paragrafo 2 di questa Sezione 5 continueranno a operare come prima e i funzionari, le task force e le altra attività della circoscrizione non subiranno modifiche fino a nuova pronuncia della circoscrizione, fermo restante che le circoscrizioni GNSO presenteranno al Segretario di ICANN un nuovo statuto e una dichiarazione delle procedure operative, attinenti alle procedure della circoscrizione e coerenti con il nuovo statuto di ICANN, non oltre il 15 luglio 2003.
4. Fino al termine della riunione annuale di ICANN del 2003, il Consiglio di GNSO sarà costituito da tre rappresentanti di ogni circoscrizione GNSO più tre persone successivamente nominate dal Comitato per l'assegnazione delle nomine. Può inoltre includere funzionari di collegamento nominati dal Comitato consultivo governativo e dal Comitato ALAC (At-Large Advisory Committee) provvisorio, come previsto dall' Articolo X, Sezione 3(1) del nuovo statuto. La composizione del Consiglio di GNSO dipenderà quindi da quanto previsto nel nuovo statuto e dagli eventuali emendamenti successivi, senza tenere conto di questo Articolo di transizione. Tutti i comitati, le task force, i gruppi di lavoro, i comitati per la stesura delle bozze e gli altri gruppi analoghi creati dal Comitato nomi di DNSO e operanti al momento dell'entrata in vigore di questo Articolo di transizione resteranno attivi sotto forma di gruppi del Consiglio di GNSO con gli stessi statuti, membri e attività e saranno soggetti alle modifiche eventualmente disposte dal Consiglio di GNSO.
5. Al momento dell'entrata in vigore di questo Articolo di transizione, i tre rappresentanti del Comitato nomi di DNSO (Domain Name Supporting Organization) nominati da ciascuna delle sei circoscrizioni di DNSO siederanno al Consiglio di GNSO come rappresentanti delle circoscrizioni, come indicato di seguito:
a. I tre rappresentanti della circoscrizione delle entità commerciali e aziendali di DNSO diverranno rappresentanti della Circoscrizione degli utenti commerciali e aziendali di GNSO.
b. I tre rappresentanti della circoscrizione dei Registri gTLD di DNSO diverranno rappresentanti della Circoscrizione dei Registri gTLD di GNSO.
c. I tre rappresentanti della circoscrizione degli ISP e dei provider di connettività di DNSO diverranno rappresentanti della Circoscrizione degli Internet Service and Connectivity Provider di GNSO.
d. I tre rappresentanti della circoscrizione dei titolari di nomi a dominio non commerciali di DNSO diverranno rappresentanti della Circoscrizione degli utenti non commerciali di GNSO.
e. I tre rappresentanti della circoscrizione dei Registrar di DNSO diverranno rappresentanti della Circoscrizione dei Registrar di GNSO.
f. I tre rappresentanti della circoscrizione dei soggetti interessati ai marchi, alle altre proprietà intellettuali e alla lotta alla contraffazione di DNSO diverranno rappresentanti della Circoscrizione delle proprietà intellettuali di GNSO.
6. Il mandato dei membri del Consiglio di GNSO indicati al paragrafo 5 di questa Sezione 5 durerà fino alla scadenza prevista dallo statuto precedente, fermo restante che i mandati di tutti i membri del Consiglio di GNSO scadranno al termine della riunione annuale di ICANN del 2003. Ove una delle posizioni del Consiglio di GNSO indicate al paragrafo 5 di questa Sezione 5 dovesse rimanere anzitempo vacante, la circoscrizione che da quella posizione viene rappresentata provvederà a occuparla fino al termine della riunione annuale di ICANN del 2003. Nel selezionare tre persone destinate al Consiglio di GNSO, il primo Comitato per l'assegnazione delle nomine ne designerà una per un mandato con scadenza al termine della riunione annuale di ICANN del 2004 e le altre due per mandati con scadenza al termine della riunione annuale di ICANN del 2005.
7. Subito dopo l'entrata in vigore del presente Articolo di transizione, l'organizzazione GNSO (Generic Names Supporting Organization), tramite il Consiglio di GNSO, selezionerà i direttori destinati a occupare le Posizioni 13 e 14 del nuovo Consiglio fino all'inizio dei primi mandati regolari previsti per tali Posizioni dall'Articolo VI, Sezione 8(1)(d) e (e) del nuovo statuto e comunicherà per iscritto le proprie scelte al Segretario di ICANN.
8. In mancanza di ulteriori interventi in materia da parte del nuovo Consiglio, ogni circoscrizione GNSO selezionerà due rappresentanti al Consiglio di GNSO non oltre il primo ottobre 2003 e comunicherà per iscritto le proprie scelte al Segretario di ICANN. Di tali rappresentanti, uno riceverà un mandato di un anno e l'altro un mandato di due anni. I successori di tali rappresentanti avranno mandati di due anni.
9. Dal momento dell'entrata in vigore di questo Articolo di transizione e fino a ulteriore intervento del Consiglio di ICANN, il Consiglio di GNSO avrà la responsabilità degli elenchi di discussione e informazione via e-mail dell'Assemblea generale di DNSO.
10. Ogni circoscrizione indicata al paragrafo 5 di questa Sezione 5 e designata a selezionare uno o più delegati al Comitato per l'assegnazione delle nomine in base all'Articolo VII, Sezione 2 del nuovo statuto , all'entrata in vigore di questo Articolo di transizione comunicherà prontamente al Segretario di ICANN il nome delle persone selezionate.
Sezione 6. PROTOCOL SUPPORTING ORGANIZATION
L'organizzazione PSO (Protocol Supporting Organization) a cui si fa riferimento nello statuto precedente è sciolta.
Sezione 7. COMITATI CONSULTIVI E TECHNICAL LIAISON GROUP
1. Dopo l'adozione del nuovo statuto, il Comitato consultivo governativo continuerà a operare secondo i principi e le procedure vigenti fino a ulteriore intervento del comitato. Il Comitato consultivo governativo può designare funzionari di collegamento presso altri organismi di ICANN come previsto dal nuovo statuto dandone comunicazione scritta al Segretario di ICANN. Subito dopo l'entrata in vigore del presente Articolo di transizione, il Comitato consultivo governativo comunicherà al Segretario di ICANN la persona selezionata come delegato presso il Comitato per l'assegnazione delle nomine, come previsto dall'Articolo VII, Sezione 2 del nuovo statuto.
2. Ciascuna delle organizzazioni designate come membri del Technical Liaison Group nell'Articolo XI-A, Sezione 2(2) del nuovo statuto designerà i due tecnici esperti descritti nell'Articolo XI-A, Sezione 2(6) del nuovo statuto dandone comunicazione scritta al Segretario di ICANN. Appena possibile, il delegato del Technical Liaison Group presso il Comitato per l'assegnazione delle nomine verrà selezionato in base a quanto disposto dall'Articolo XI-A, Sezione 2(7) del nuovo statuto.
3. Dopo l'adozione del nuovo statuto, Security and Stability Advisory Committee continuerà a operare secondo i principi e le procedure vigenti fino a ulteriore intervento del comitato. Subito dopo l'entrata in vigore del presente Articolo di transizione, Security and Stability Advisory Committee comunicherà al Segretario di ICANN la persona selezionata come delegato presso il Comitato per l'assegnazione delle nomine, come previsto dall' Articolo VII, Sezione 2(4) del nuovo statuto.
4. Dopo l'adozione del nuovo statuto, il Comitato consultivo del sistema root server continuerà a operare secondo i principi e le procedure vigenti fino a ulteriore intervento del comitato. Subito dopo l'entrata in vigore del presente Articolo di transizione, il Comitato consultivo del sistema root server comunicherà al Segretario di ICANN la persona selezionata come delegato presso il Comitato per l'assegnazione delle nomine, come previsto dall'Articolo VII, Sezione 2(3) del nuovo statuto.
5. ALAC (At-Large Advisory Committee)
a. Esisterà un ALAC (At-Large Advisory Committee) provvisorio fintanto che ICANN riconoscerà, tramite l'inserimento in un Protocollo d'Intesa, tutte le organizzazioni At-Large regionali (RALO, Regional At-Large Organizations) indicate all'Articolo XI, Sezione 2(4) del nuovo statuto. Il Comitato ALAC provvisorio sarà composto da (i) dieci individui (due da ogni regione ICANN) selezionati dal Consiglio di ICANN tra le candidature di ALOC (At-Large Organizing Committee) e da (ii) cinque ulteriori individui (uno da ogni regione ICANN) selezionati dal primo Comitato per l'assegnazione delle nomine appena possibile in base ai principi stabiliti nell' Articolo VII, Sezione 5 del nuovo statuto. Il primo Comitato per l'assegnazione delle nomine designerà due di questi individui per mandati con scadenza al termine della riunione annuale di ICANN del 2004 e tre di questi individui per mandati con scadenza al termine della riunione annuale di ICANN del 2005.
b. Dopo l'inserimento nel Protocollo d'Intesa, le organizzazioni RALO avranno titolo per selezionare due individui cittadini e residenti nella regione quali membri del Comitato ALAC (At-Large Advisory Committee) descritto all'Articolo XI, Sezione 2(4) del nuovo statuto. Dopo la comunicazione scritta delle selezioni al Segretario di ICANN, le persone designate assumeranno immediatamente le posizioni occupate fino a quel momento dai membri del Comitato ALAC (At-Large Advisory Committee) provvisorio precedentemente selezionati dal Consiglio dalla regione RALO.
c. Dopo l'insediamento delle persone selezionate dalle cinque organizzazioni RALO, il Comitato ALAC provvisorio diverrà il Comitato ALAC, come previsto dall'Articolo XI, Sezione 2(4) del nuovo statuto. I cinque individui selezionati per il Comitato ALAC provvisorio dal Comitato per l'assegnazione delle nomine diverranno membri del Comitato ALAC fino alla fine del mandato per il quale erano stati selezionati.
d. Subito dopo la propria istituzione, il Comitato ALAC (At-Large Advisory Committee) provvisorio comunicherà al Segretario di ICANN le persone selezionate come delegati presso il Comitato per l'assegnazione delle nomine, come previsto dall'Articolo VII, Sezione 2(6) del nuovo statuto.
I funzionari di ICANN (come definiti nell'Articolo XIII del nuovo statuto) verranno eletti dal Consiglio di ICANN operante alla riunione annuale del 2002 e resteranno in carica fino alla riunione annuale del 2003.
Sezione 9. GRUPPI NOMINATI DAL PRESIDENTE
Nonostante l'adozione del nuovo statuto, i membri, la sfera di competenza e le attività delle task force e degli altri gruppi nominati dal Presidente di ICANN non cambieranno fino a nuova pronuncia del Presidente.
Sezione 10. CONTRATTI CON ICANN
Nonostante l'adozione del nuovo statuto, tutti gli accordi stretti con ICANN, compresi i contratti di consulenza e le assunzioni, resteranno validi.
Appendice A: Processo GNSO per lo sviluppo di politiche
La procedura seguente governerà il processo GNSO per lo sviluppo di politiche (PDP, Policy Development Process) fino a quando non emergeranno esigenze tali da richiedere modifiche che vengano approvate dal Consiglio direttivo di ICANN.
1. Segnalazione di un problema
Un problema può essere sottoposto a vaglio tramite PDP per uno dei seguenti eventi:
a. Segnalazione del Consiglio di ICANN. Il Consiglio di ICANN può avviare il PDP disponendo che il Consiglio di GNSO apra la procedura descritta in questa appendice.
b. Segnalazione del Consiglio di GNSO. Il Consiglio di GNSO può avviare il PDP con il voto favorevole del venticinque per cento (25%) dei membri presenti alla riunione in cui viene presentata la mozione di avvio del PDP.
c. Segnalazione del Comitato consultivo. Un Comitato consultivo può chiedere di sottoporre un problema a PDP tramite l'emanazione di un proprio atto e la trasmissione di tale richiesta al Consiglio di GNSO.
2. Stesura di una relazione sul problema
Entro quindici (15) giorni di calendario dalla ricezione (i) di una disposizione del Consiglio di ICANN; (ii) di una mozione opportunamente argomentata da parte di un membro del Consiglio di GNSO; o (iii) di una mozione opportunamente argomentata da parte di un Comitato consultivo, lo Staff Manager stilerà una relazione sul problema. La relazione sul problema dovrà includere almeno i seguenti punti:
a. Enunciazione del problema sottoposto a vaglio;
b. Identità del soggetto che ha segnalato il problema;
c. Effetti del problema su tale soggetto;
d. Supporto per l'avvio del problema al PDP;
e. Parere dello Staff Manager sull'opportunità o meno di avviare un PDP per il problema in esame. Tale parere includerà l'opinione del Procuratore generale di ICANN, che indica se il problema per il quale si richiede di avviare il PDP rientra o meno nell'ambito del processo per le politiche di ICANN e nell'ambito delle attività di GNSO. Per determinare se il problema rientra o meno nell'ambito del processo per le politiche di ICANN, il Procuratore generale esaminerà se il problema:
1. rientra nell'ambito della dichiarazione programmatica di ICANN;
2. investe un ampio numero di contesti o di organizzazioni;
3. può avere soluzioni di valore o fruibilità durevole, seppure tramite aggiornamenti occasionali;
f. Entro quindici (15) giorni, lo Staff Manager distribuirà la relazione sul problema a tutto il Consiglio di GNSO che voterà in merito all'avvio del PDP come indicato di seguito.
Il Consiglio di GNSO avvierà il PDP come segue:
a. Problema segnalato dal Consiglio di ICANN. Se il Consiglio di ICANN dispone che il Consiglio di GNSO avvii il PDP, il Consiglio di GNSO si riunirà e procederà come disposto entro quindici (15) giorni di calendario dalla ricezione della relazione sul problema, senza passare per la fase di voto.
b. Problema segnalato da un soggetto diverso dal Consiglio di ICANN. Se un problema riguardante una politica viene sottoposto al Consiglio di GNSO tramite apposita relazione, il Consiglio di GNSO si riunirà entro quindici (15) giorni di calendario dalla ricezione della relazione per votare in merito all'avvio del PDP. Tale riunione può essere svolta comunque il Consiglio di GNSO ritenga appropriato, ad esempio di persona, in teleconferenza o tramite e-mail.
c. Voto del Consiglio di GNSO. Per avviare il PDP sarà sufficiente che voti a favore più del 33% dei membri del Consiglio di GNSO presenti, a meno che il parere dello Staff Manager non indichi che il problema in esame non rientra propriamente nell'ambito del processo per le politiche di ICANN o di GNSO. In tal caso per avviare il PDP sarà necessario il voto favorevole di una maggioranza qualificata dei membri del Consiglio di GNSO presenti.
Durante la riunione che delibera l'avvio del PDP, il Consiglio di GNSO decide a maggioranza dei membri presenti se assegnare alla risoluzione del problema una task force dedicata. Se il Consiglio vota:
a. In favore dell'istituzione di una task force, lo farà come previsto dal seguente Punto 7.
b. Contro l'istituzione di una task force, raccoglierà informazioni sul problema come previsto dal seguente Punto 8.
5. Istituzione e selezione delle task force
a. Quando il voto conduce alla nomina di una task force, il Consiglio di GNSO inviterà tutte le circoscrizioni GNSO a nominare una persona da inserire nella task force. Il Consiglio di GNSO può inoltre nominare e inserire nella task force tre consulenti esterni. In questa appendice i membri della task force sono definiti "incaricati". Il Consiglio di GNSO può aumentare il numero di incaricati per circoscrizione a propria discrezione nei casi in cui lo ritenga opportuno.
b. Ogni circoscrizione che desideri nominare un incaricato per la task force deve comunicarne il nome allo Staff Manager entro dieci (10) giorni di calendario dalla richiesta. La persona designata non può essere un membro del Consiglio di GNSO, bensì deve avere un interesse, e preferibilmente una conoscenza e un'esperienza, nell'ambito in cui è chiamato a operare, oltre che la possibilità di dedicare una notevole quantità di tempo alle attività della task force.
c. Il Consiglio di GNSO può anche intraprendere ulteriori azioni che ritiene utili al PDP, come ad esempio affidare a un individuo o a un'organizzazione specifica la raccolta di informazioni sul problema o la pianificazione di riunioni per il confronto e la programmazione delle attività. Tutte le informazioni saranno presentate allo Staff Manager entro trentacinque (35) giorni di calendario dall'avvio del PDP.
6. Notifica pubblica dell'avvio del PDP
Dopo l'avvio del PDP, ICANN ne darà comunicazione sul sito Web. Si aprirà quindi un periodo di consultazione pubblica sul problema della durata di venti (20) giorni di calendario dall'inizio del PDP. Lo Staff Manager o un altro soggetto designato da ICANN esaminerà i commenti pubblici e li includerà in una "relazione sui commenti pubblici" che verrà acclusa alla relazione preliminare della task force (o alla relazione iniziale).
a. Ruolo della task force. Se viene istituita una task force, il suo ruolo generalmente consisterà (i) nella raccolta di informazioni che delineino le posizioni delle circoscrizioni GNSO formali ed eventualmente provvisorie e (ii) nella raccolta di ogni altra informazione che consenta di stilare la relazione della task force nel modo più esaustivo possibile.
La task force non avrà alcuna autorità decisionale formale. Il ruolo della task force consisterà piuttosto nel raccogliere informazioni che documentino nel modo più dettagliato ed esaustivo possibile le posizioni delle diverse parti coinvolte, affinché il Consiglio di GNSO possa deliberare sul problema in modo informato e pertinente.
b. Termini di riferimento e atto istitutivo della task force. Il Consiglio di GNSO, con l'assistenza dello Staff Manager, stilerà un "atto istitutivo" (o termini di riferimento) per la task force entro dieci (10) giorni di calendario dall'avvio del PDP. L'atto istitutivo indicherà:
1. il problema di cui la task force dovrà interessarsi, come presentato al voto con il quale il Consiglio di GNSO ha avviato il PDP;
2. la scadenza a cui la task force dovrà attenersi, come specificata di seguito, a meno che il Consiglio di ICANN non determini che sussistono valide ragioni per estendere i termini; e
3. tutte le istruzioni specifiche che il Consiglio di GNSO impartisce alla task force, tra cui l'autorizzazione o meno a ricorrere a consulenze esterne.
La task force preparerà la propria relazione e condurrà le altre attività in conformità con quanto indicato nell'atto istitutivo. Le eventuali richieste di discostarsi dall'atto istitutivo dovranno essere avanzate in via formale e approvate con il voto favorevole della maggioranza dei membri del Consiglio di GNSO presenti.
c. Nomina del Presidente della task force. Lo Staff Manager convocherà la prima riunione della task force entro cinque (5) giorni di calendario dalla ricezione dell'atto istitutivo. Durante la prima riunione, i membri della task force, tra le altre cose, voteranno per la nomina di un Presidente. Il Presidente sarà responsabile dell'organizzazione delle attività della task force, compresa la stesura della Relazione della task force. Il Presidente della task force non può essere un membro del Consiglio.
1. Relazioni di circoscrizione. Gli incaricati dovranno almeno rappresentare le posizioni delle rispettive circoscrizioni e potranno inoltre avanzare ogni commento che riterranno appropriato sul problema in esame. Le posizioni e gli eventuali commenti dovranno essere sottoposti al Presidente della task force tramite formale "relazione di circoscrizione" entro trentacinque (35) giorni di calendario dall'avvio del PDP. La relazione di circoscrizione dovrà includere almeno i seguenti punti:
(i) Se al voto è stata raggiunta una maggioranza qualificata, una descrizione chiara della posizione della circoscrizione sul problema;
(ii) Se al voto non è stata raggiunta una maggioranza qualificata, una descrizione chiara di tutte le posizioni assunte dai membri della circoscrizione;
(iii) Una descrizione chiara del modo in cui la circoscrizione ha maturato la posizione assunta. In particolare, la descrizione deve includere il dettaglio delle riunioni, delle teleconferenze o degli altri mezzi con cui la circoscrizione è arrivata a esprimere un giudizio sul problema, con l'elenco di tutti i membri che vi hanno contribuito;
(iv) Un'analisi dell'effetto che il problema ha sulla circoscrizione, comprese le implicazioni finanziarie; e
(v) Un'analisi del tempo che sarebbe necessario per implementare la politica.
2. Consulenti esterni. Qualora lo ritenga utile o appropriato, oltre al parere dei membri delle circoscrizioni la task force può richiedere il parere di consulenti esterni, esperti o altri esponenti del pubblico. Tali opinioni saranno raccolte in una relazione preparata dai consulenti esterni e dovranno essere (i) chiaramente identificate come provenienti da consulenti esterni e (ii) accompagnate da una descrizione dettagliata (A) delle qualifiche ed esperienze rilevanti e (B) dei possibili conflitti di interesse dei consulenti. Tali relazioni dovranno essere sottoposte in via formale al Presidente della task force entro trentacinque (35) giorni di calendario dall'avvio del PDP.
e. Relazione della task force. Il Presidente della task force, in collaborazione con lo Staff Manager, compilerà le relazioni di circoscrizione, la relazione sui commenti pubblici e le altre eventuali informazioni o relazioni in un unico documento, la "relazione preliminare della task force", che distribuirà a tutta la task force entro quaranta (40) giorni di calendario dall'avvio del PDP. La task force terrà un'ultima riunione entro cinque (5) giorni dalla distribuzione della relazione preliminare della task force per valutare il problema e provare a raggiungere un voto di maggioranza qualificata. Entro i cinque (5) giorni successivi all'ultima riunione della task force, il Presidente della task force e lo Staff Manager stileranno un documento conclusivo denominato "relazione della task force" e lo pubblicheranno sul sito dei commenti. La relazione della task force deve includere:
1. Una descrizione chiara di ogni posizione assunta dalla task force con voto di maggioranza qualificata;
2. Se al voto non è stata raggiunta una maggioranza qualificata, una descrizione chiara di tutte le posizioni assunte dai membri della task force comunicate entro la scadenza di venti giorni per la presentazione delle relazioni di circoscrizione. Ogni descrizione deve indicare chiaramente (i) le ragioni che inducono ad assumere la posizione e (ii) le circoscrizioni che condividono tale posizione;
3. Un'analisi dell'effetto che il problema ha su ogni circoscrizione della task force, comprese le implicazioni finanziarie;
4. Un'analisi del tempo che sarebbe necessario per implementare la politica; e
5. Il parere di ogni consulente esterno aggiunto alla task force dal Consiglio di GNSO, accompagnato da una descrizione dettagliata (i) delle qualifiche ed esperienze rilevanti e (ii) dei possibili conflitti di interesse del consulente.
8. Procedura da adottare se la task force non viene formata
a. Se il Consiglio di GNSO decide di non istituire una task force, chiederà che entro i dieci (10) giorni di calendario successivi ogni circoscrizione nomini un incaricato che riferisca sul punto di vista della circoscrizione in merito al problema. A tali incaricati verrà chiesto di presentare una relazione di circoscrizione allo Staff Manager entro trentacinque (35) giorni di calendario dall'avvio del PDP.
b. Il Consiglio di GNSO può anche intraprendere ulteriori azioni che ritiene utili al PDP, come ad esempio affidare a un individuo o a un'organizzazione specifica la raccolta di informazioni sul problema o la pianificazione di riunioni per il confronto e la programmazione delle attività. Tutte le informazioni saranno presentate allo Staff Manager entro trentacinque (35) giorni di calendario dall'avvio del PDP.
c. Lo Staff Manager raccoglierà tutte le relazioni di circoscrizione, la relazioni sui commenti pubblici e ogni altra eventuale informazione e compilerà (e poi pubblicherà sul sito dei commenti) una "relazione iniziale" entro cinquanta (50) giorni di calendario dall'avvio del PDP. Il PDP procederà quindi con la preparazione della relazione finale, come descritto al seguente Punto 9.
9. Commenti pubblici alla relazione della task force o alla relazione iniziale
a. Il periodo di consultazione pubblica durerà venti (20) giorni di calendario dalla pubblicazione della relazione della task force o della relazione iniziale. Qualsiasi individuo o organizzazione può avanzare commenti durante il periodo di consultazione pubblica, comprese le circoscrizioni che non hanno partecipato alla task force. Tutti i commenti riporteranno il nome dell'autore nonché le esperienze da questi maturate in materia e il relativo interesse in merito al problema in esame.
b. Allo scadere dei venti (20) giorni, lo Staff Manager avrà il compito di esaminare i commenti ricevuti e di includere quelli che riterrà appropriati nella relazione della task force o nella relazione iniziale (insieme, "relazione finale"). Lo Staff Manager non è tenuto a includere tutti i commenti ricevuti durante il periodo di consultazione da individui e organizzazioni.
c. Lo Staff Manager preparerà la relazione finale e la presenterà al Presidente del Consiglio di GNSO entro dieci (10) giorni di calendario dalla fine del periodo di consultazione pubblica.
a. Ricevuta la relazione finale, sia questa il risultato del lavoro di una task force o meno, il Presidente del Consiglio di GNSO (i) la distribuirà a tutti i membri del Consiglio di GNSO e (ii) indirà una riunione del Consiglio di GNSO entro i dieci (10) giorni di calendario successivi. Il Consiglio di GNSO può iniziare la propria valutazione del problema prima della riunione formale, attraverso riunioni, teleconferenze e scambi di e-mail o negli altri modi che sceglierà di adottare. Il processo di valutazione culminerà in una riunione formale del Consiglio di GNSO, che si terrà di persona o in teleconferenza, in cui si tenterà di convergere su un voto di maggioranza qualificata da presentare al Consiglio di ICANN.
b. Se lo ritiene opportuno, durante la riunione finale il Consiglio di GNSO può sentire il parere di consulenti esterni. Qualora incidano sulla valutazione del Consiglio di GNSO, le opinioni di tali consulenti saranno (i) inserite nella relazione che il Consiglio di GNSO stilerà per il Consiglio di ICANN; (ii) identificate specificamente come provenienti da consulenti esterni; e (iii) accompagnate da una descrizione dettagliata (x) delle qualifiche ed esperienze rilevanti e (y) dei possibili conflitti di interesse dei consulenti.
11. Relazione preparata dal Consiglio di GNSO per il Consiglio di ICANN
Lo Staff Manager parteciperà alla riunione finale del Consiglio di GNSO, quindi avrà cinque (5) giorni di calendario per presentare al Consiglio di ICANN una relazione che illustri le posizioni assunte dal Consiglio di GNSO. La relazione per il Consiglio di ICANN deve includere almeno i seguenti punti:
a. Una descrizione chiara di ogni suggerimento sul quale il Consiglio di GNSO è confluito in un voto di maggioranza qualificata;
b. Se al voto non è stata raggiunta un maggioranza qualificata, una descrizione chiara di tutte le posizioni assunte dai membri del Consiglio di GNSO. Ogni descrizione deve indicare chiaramente (i) le ragioni che inducono ad assumere una determinata posizione e (ii) le circoscrizioni che condividono tale posizione;
c. Un'analisi dell'effetto che il problema ha su ogni circoscrizione, comprese le implicazioni finanziarie;
d. Un'analisi del tempo che sarebbe necessario per implementare la politica;
e. Il parere di ogni consulente esterno ritenuto significativo, accompagnato da una descrizione dettagliata (i) delle qualifiche ed esperienze rilevanti e (ii) dei possibili conflitti di interesse del consulente.
f. La relazione finale presentata al Consiglio di GNSO; e
g. Una copia del verbale della delibera del Consiglio di GNSO in merito al problema in esame, comprensiva di tutte le opinioni espresse nell'occasione e corredata dell'identificazione dei soggetti che si sono pronunciati.
12. Pronuncia del Consiglio di GNSO
Qualora i membri del Consiglio di GNSO esprimessero una posizione congiunta attraverso un voto di maggioranza qualificata, tale posizione verrà intesa come posizione del Consiglio di GNSO e potrà essere trasmessa al Consiglio di ICANN come suggerimento del Consiglio di GNSO. L'astensione non sarà consentita. Pertanto tutti i membri del Consiglio di GNSO dovranno esprimere un voto a meno che non abbiano un interesse finanziario per l'esito del processo. Nonostante quanto sopra, come indicato in precedenza, tutti i pareri espressi dai membri del Consiglio di GNSO durante il PDP devono essere inseriti nella relazione per il Consiglio di ICANN.
13. Voto del Consiglio di ICANN
a. Il Consiglio di ICANN si riunirà per discutere del suggerimento del Consiglio di GNSO appena possibile dopo aver ricevuto la relazione per il Consiglio di ICANN dallo Staff Manager.
b. Se al voto del Consiglio di GNSO è stata raggiunta una maggioranza qualificata, il Consiglio di ICANN adotterà la politica raccomandata da tale voto di maggioranza a meno che, con il voto sfavorevole di più del sessantasei per cento (66%) dei membri, non decida di respingere la politica perché non coincidente con gli interessi di ICANN o della relativa comunità.
c. Nel caso in cui il Consiglio di ICANN decida di non agire in accordo con il suggerimento votato a maggioranza qualificata dal Consiglio di GNSO, (i) esprimerà chiaramente le ragioni delle proprie conclusioni in una "relazione del Consiglio di ICANN" e (ii) trasmetterà tale relazione al Consiglio di GNSO.
d. Il Consiglio di GNSO esaminerà la relazione del Consiglio di ICANN in vista del confronto che si terrà tra i due Consigli nei venti (20) giorni di calendario successivi. Il Consiglio di ICANN stabilirà in che modo (teleconferenza, e-mail o altro) i due Consigli si confronteranno in merito alla relazione del Consiglio di ICANN.
e. Al termine del confronto, il Consiglio di GNSO si riunirà per ribadire o modificare il proprio suggerimento e comunicherà le proprie conclusioni ("suggerimento supplementare") al Consiglio di ICANN motivandole. Se al voto per il suggerimento supplementare il Consiglio di GNSO raggiunge una maggioranza qualificata, il Consiglio di ICANN adotterà il suggerimento a meno che, con il voto sfavorevole di più del sessantasei per cento (66%) dei membri, non decida di respingere la politica perché non coincidente con gli interessi di ICANN o della relativa comunità.
f. Se il Consiglio di GNSO non converge su una posizione di maggioranza qualificata, il Consiglio di ICANN potrà procedere con un voto a maggioranza semplice.
g. Quando la tempestività della decisione finale sul suggerimento o sul suggerimento supplementare del Consiglio di GNSO è fondamentale, il Consiglio di ICANN procederà a una votazione preliminare e, quando possibile, pubblicherà la conseguente decisione provvisoria che verrà così sottoposta a un periodo di consultazione pubblica di dieci (10) giorni prima che il Consiglio di ICANN prenda la decisione finale.
14. Implementazione della politica
Dopo aver preso la decisione finale, il Consiglio di ICANN autorizzerà o guiderà il personale di ICANN all'implementazione della politica.
Durante tutto il PDP, dal suggerimento sulla politica da adottare alla decisione finale del Consiglio di ICANN, ICANN manterrà sul sito Web una pagina di stato che descrive l'evoluzione del processo e include i punti seguenti:
a. Il suggerimento sulla politica da adottare;
b. Un elenco di tutti i suggerimenti che non portano alla stesura di una relazione sul problema;
c. Le scadenze da osservare per ogni politica;
d. Tutte le discussioni del Consiglio di GNSO in merito alla politica;
e. Tutte le relazioni prodotte dalle task force, dallo Staff Manager, dal Consiglio di GNSO e dal Consiglio di ICANN; e
"Sito dei commenti" e "sito Web" si riferiscono a uno o più siti Web progettati da ICANN in cui verranno pubblicati commenti e notifiche relativi al PDP.
"Staff Manager" si riferisce a un individuo del personale di ICANN che gestisce il PDP.
"Voto a maggioranza qualificata" si riferisce al voto di più del sessantasei per cento (66%) dei membri presenti di un collegio.
Appendice B: Processo ccNSO per lo sviluppo di politiche
La procedura seguente regolerà il processo ccNSO per lo sviluppo di politiche (PDP, Policy Development Process).
1. Richiesta di una relazione sul problema
La relazione sul problema può essere richiesta da una delle seguenti entità:
a. Consiglio di ccNSO. Il Consiglio di ccNSO può chiedere la stesura di una relazione sul problema con il voto favorevole di almeno sette membri presenti a un riunione o votanti tramite e-mail.
b. Consiglio di ICANN. Il Consiglio di ICANN può chiedere la stesura di una relazione sul problema chiedendo al Consiglio di ccNSO di avviare il processo di sviluppo della politica.
c. Organizzazione regionale. Una o più organizzazioni regionali che rappresentano ccTLD nelle regioni riconosciute da ICANN possono chiedere la stesura di una relazione sul problema chiedendo al Consiglio di ccNSO di avviare il processo di sviluppo della politica.
d. Organizzazioni di supporto o comitati consultivi di ICANN. Un'organizzazione di supporto o un comitato consultivo di ICANN può chiedere la stesura di una relazione sul problema chiedendo al Consiglio di ccNSO di avviare il processo di sviluppo della politica.
e. Membri di ccNSO. I membri di ccNSO possono chiedere la stesura di una relazione sul problema con il voto favorevole di almeno dieci membri di ccNSO presenti a un riunione o votanti tramite e-mail.
Tutte le richieste di stesura di una relazione sul problema devono essere presentate per iscritto e devono illustrare il problema per il quale si richiede la relazione in modo sufficientemente dettagliato da consentire la preparazione della relazione sul problema. Il Consiglio di ccNSO avrà facoltà di richiedere ulteriori informazioni o di intraprendere ulteriori ricerche o investigazioni allo scopo di determinare se produrre o meno la relazione sul problema richiesta.
2. Stesura della relazione sul problema e valutazione preliminare
Entro sette giorni dal voto favorevole indicato al precedente Punto 1(a) o dalla ricezione della richiesta indicata ai precedenti punti 1(b), (c) o (d), il Consiglio di ccNSO nominerà un Issue Manager. L'Issue Manager può essere un membro del personale di ICANN (in tal caso i costi dell'Issue Manager saranno sostenuti da ICANN) o una o più persone selezionate dal Consiglio di ccNSO (in tal caso i costi dell'Issue Manager saranno responsabilità di ccNSO).
Entro quindici (15) giorni di calendario dalla nomina (o trascorso un tempo diverso che il Consiglio di ccNSO, sentito l'Issue Manager, riterrà opportuno), l'Issue Manager stilerà una relazione sul problema. La relazione sul problema dovrà includere almeno i seguenti punti:
a. Enunciazione del problema sottoposto a vaglio;
b. Identità del soggetto che ha segnalato il problema;
c. Effetti del problema su tale soggetto;
d. Supporto per l'avvio del problema al PDP;
e. Parere dell'Issue Manager sull'opportunità o meno di avviare un PDP per il problema in esame. Tale parere includerà e sarà supportato dall'opinione del Procuratore generale di ICANN, che indica se il problema per il quale si richiede di avviare il PDP rientra o meno nell'ambito del processo per le politiche di ICANN e nell'ambito delle attività di ccNSO. Nel formulare la propria opinione, il Procuratore generale verificherà se:
1) Il problema rientra nell'ambito della dichiarazione programmatica di ICANN;
2) L'analisi dei fattori rilevanti in base all'Articolo IX, Sezione 6(2) e all'Appendice C dimostra che il problema rientra nell'ambito delle attività di ccNSO;
Se il Procuratore generale matura un'opinione favorevole in base ai precedenti punti 1 e 2 dovrà anche considerare se il problema:
3) Compromette o inficia una politica esistente di ICANN;
4) Può avere soluzioni di valore o fruibilità durevole, seppure tramite aggiornamenti occasionali, e apre la strada a evoluzioni future.
In tutti i casi, le valutazioni sull'opportunità di modificare il ccPDP (questa Appendice B) o l'ambito di attività di ccNSO (Appendice C) saranno competenza di ICANN e di ccNSO.
Se il Procuratore generale matura l'opinione che il problema non rientri propriamente nell'ambito delle attività di ccNSO, l'Issue Manager informerà il Consiglio di ccNSO di tale opinione. Se dopo un'analisi dei fattori rilevanti in base all'Articolo IX, Sezione 6 e Appendice C, una maggioranza di 10 o più membri del Consiglio di ccNSO matura l'opinione che il problema rientri nell'ambito delle attività di ccNSO, il Presidente di ccNSO informerà l'Issue Manager di conseguenza. Il Procuratore generale e il Consiglio di ccNSO avvieranno un confronto basato sulle regole e sulle procedure vigenti per risolvere il problema. Se il Procuratore generale e il Consiglio di ccNSO non giungono a un accordo in merito alla competenza di ccNSO di pronunciarsi sul problema, il Consiglio di ccNSO potrà decidere che il problema rientra nell'ambito delle proprie attività tramite il voto favorevole di 15 o più membri. Il Presidente di ccNSO informerà il Procuratore generale e l'Issue Manager della decisione. L'Issue Manager formulerà quindi un suggerimento in cui propone al Consiglio di ccNSO di avviare o meno il PDP e includerà le opinioni e le analisi del Procuratore generale e del Consiglio di ccNSO nella relazione sul problema.
f. Se il suggerimento dell'Issue Manager è favorevole all'avvio del PDP, includerà il calendario delle diverse fasi del PDP.
g. Se possibile, la relazione sul problema indicherà se il PDP può condurre alla definizione di una politica che possa essere approvata dal Consiglio di ICANN. In alcuni casi non è possibile formulare questa ipotesi prima di discutere realmente il problema. In tali casi nella relazione sul problema verrà indicata questa incertezza. Al termine della stesura della relazione sul problema, l'Issue Manager la distribuirà a tutto il Consiglio di ccNSO che voterà in merito all'avvio del PDP.
3. Avvio del PDP
Il Consiglio di ccNSO deciderà se avviare il PDP come segue:
a. Entro 21 giorni dalla ricezione della relazione sul problema dall'Issue Manager, il Consiglio di ccNSO voterà in merito all'avvio del PDP. La votazione avverrà in una riunione svolta comunque il Consiglio di ccNSO ritenga appropriato, ad esempio di persona, in teleconferenza o tramite e-mail.
b. Per avviare il PDP sarà sufficiente che votino a favore dieci o più membri del Consiglio di ccNSO, posto che la relazione sul problema attesti che il problema in esame rientra propriamente nell'ambito della dichiarazione programmatica di ICANN e nell'ambito delle attività di ccNSO.
4. Decisione sulla nomina di una task force; Definizione di un calendario
Durante la riunione che delibera l'avvio del PDP (o in concomitanza con il voto via e-mail) in conformità al precedente Punto 3, il Consiglio di ccNSO decide a maggioranza dei membri presenti se assegnare alla risoluzione del problema una task force dedicata. Se il Consiglio vota:
a. In favore dell'istituzione di una task force, lo farà come previsto dal seguente Punto 7.
b. Contro l'istituzione di una task force, raccoglierà informazioni sul problema come previsto dal seguente Punto 8.
Il Consiglio di ccNSO, inoltre, con voto di maggioranza dei membri presenti alla riunione o votanti via e-mail, approva o emenda e approva il calendario del PDP definito nella relazione sul problema.
5. Istituzione e selezione delle task force
a. Quando il voto conduce alla nomina di una task force, il Consiglio di ccNSO inviterà tutte le organizzazioni regionali (vedere l'Articolo IX, Sezione 6) a nominare due persone da inserire nella task force (gli "incaricati"). Il Consiglio di ccNSO può inoltre nominare fino a tre consulenti esterni e, a seguito della richiesta di partecipazione formale di GAC, può inserire nella task force fino a due incaricati del Comitato consultivo governativo. Il Consiglio di ccNSO può aumentare il numero di incaricati nella task force a propria discrezione nei casi in cui lo ritenga opportuno.
b. Ogni organizzazione regionale che desideri nominare incaricati per la task force deve comunicarne i nomi all'Issue Manager entro dieci (10) giorni di calendario dalla richiesta. Gli incaricati non possono essere membri del Consiglio di ccNSO, bensì devono avere un interesse, e preferibilmente una conoscenza e un'esperienza, nell'ambito in cui sono chiamati a operare, oltre che la possibilità di dedicare una notevole quantità di tempo alle attività della task force.
c. Il Consiglio di ccNSO può anche intraprendere ulteriori azioni che ritiene utili al PDP, come ad esempio affidare a un individuo o a un'organizzazione specifica la raccolta di informazioni sul problema o la pianificazione di riunioni per il confronto e la programmazione delle attività. Tutte le informazioni dovranno essere inviate all'Issue Manager nei tempi previsti dal calendario del PDP.
6. Notifica pubblica dell'avvio del PDP e periodo di consultazione pubblica
Dopo l'avvio del PDP, ICANN ne darà comunicazione sul sito Web e informerà le organizzazioni di supporto e i Comitati consultivi. Si aprirà quindi un periodo di consultazione sul problema che, in base al calendario del PDP, avrà normalmente una durata non inferiore ai 21 giorni. Verranno accettati commenti dei gestori ccTLD, di altre organizzazioni di supporto, dei Comitati consultivi e del pubblico. L'Issue Manager o un altro soggetto designato dal Consiglio di ccNSO esaminerà i commenti e li includerà in una "relazione sui commenti" che verrà acclusa alla relazione preliminare della task force (o alla relazione iniziale).
7. Task force
a. Ruolo della task force. Se viene istituita una task force, il suo ruolo generalmente consisterà (i) nella raccolta di informazioni che delineino le posizioni dei membri di ccNSO nelle Regioni Geografiche e in altre parti o gruppi e (ii) nella raccolta di ogni altra informazione che consenta di stilare la Relazione della task force nel modo più esaustivo possibile, affinché il Consiglio di ccNSO possa deliberare sul problema in modo informato e pertinente.
La task force non avrà alcuna autorità decisionale formale. Il ruolo della task force consisterà piuttosto nel raccogliere informazioni che documentino nel modo più dettagliato ed esaustivo possibile le posizioni delle diverse parti coinvolte, affinché il Consiglio di ccNSO possa deliberare sul problema in modo informato e pertinente.
b. Termini di riferimento e atto istitutivo della task force. Il Consiglio di ccNSO, con l'assistenza dell'Issue Manager, stilerà un "atto istitutivo" (o termini di riferimento) per la task force nei tempi previsti dal calendario del PDP. L'atto istitutivo indicherà:
1. Il problema di cui la task force dovrà interessarsi, come presentato al voto con il quale il Consiglio di ccNSO ha avviato il PDP;
2. La scadenza a cui la task force dovrà attenersi, come specificata di seguito, a meno che il Consiglio di ccNSO non determini che sussistono valide ragioni per estendere i termini; e
3. Tutte le istruzioni specifiche che il Consiglio di ccNSO impartisce alla task force, tra cui l'autorizzazione o meno a ricorrere a consulenze esterne.
La task force preparerà la propria relazione e condurrà le altre attività in conformità con quanto indicato nell'atto istitutivo. Le eventuali richieste di discostarsi dall'atto istitutivo dovranno essere avanzate in via formale e approvate con il voto favorevole della maggioranza dei membri del Consiglio di ccNSO presenti a una riunione o votanti via e-mail. I requisiti di quorum previsti all'Articolo IX, Sezione 3(14) si applicheranno agli atti del Consiglio di ccNSO previsti a questo Punto 7(b).
c. Nomina del Presidente della task force. L'Issue Manager convocherà la prima riunione della task force entro i termini previsti dal calendario del PDP. Durante la prima riunione, i membri della task force, tra le altre cose, voteranno per la nomina di un Presidente. Il Presidente sarà responsabile dell'organizzazione delle attività della task force, compresa la stesura della Relazione della task force. Il Presidente della task force non può essere un membro del Consiglio.
d. Raccolta di informazioni.
1. Relazioni delle organizzazioni regionali. Gli incaricati dovranno almeno rappresentare le posizioni delle organizzazioni regionali delle rispettive Regioni Geografiche e potranno inoltre avanzare ogni commento che riterranno appropriato sul problema in esame, compresi i commenti dei membri di ccNSO di tale regione che non sono membri dell'organizzazione regionale. La posizione dell'organizzazione regionale e ogni altro commento raccolto dagli incaricati dovranno essere sottoposti al Presidente della task force tramite formale "relazione regionale" entro i termini previsti dal calendario del PDP. La relazione regionale dovrà includere almeno i seguenti punti:
(i) Se al voto è stata raggiunta la maggioranza qualificata (come definita dall'organizzazione regionale), una descrizione chiara della posizione dell'organizzazione regionale sul problema;
(ii) Se al voto non è stata raggiunta la maggioranza qualificata, una descrizione chiara di tutte le posizioni assunte dai membri dell'organizzazione regionale;
(iii) Una descrizione chiara del modo in cui l'organizzazione regionale ha maturato la posizione assunta. In particolare, la descrizione deve includere il dettaglio delle riunioni, delle teleconferenze o degli altri mezzi con cui si è arrivati a esprimere un giudizio sul problema, con l'elenco di tutti i membri che vi hanno contribuito;
(iv) Una descrizione della posizione di tutti i membri di ccNSO che non sono membri dell'organizzazione regionale;
(v) Un'analisi dell'effetto che il problema ha sulla regione, comprese le implicazioni finanziarie; e
(vi) Un'analisi del tempo che sarebbe necessario per implementare la politica.
2. Consulenti esterni. La task force può, a propria discrezione, richiedere il parere di consulenti esterni, esperti o altri esponenti del pubblico. Tali opinioni saranno raccolte in una relazione preparata dai consulenti esterni e dovranno essere (i) chiaramente identificate come provenienti da consulenti esterni e (ii) accompagnate da una descrizione dettagliata (a) delle qualifiche ed esperienze rilevanti e (b) dei possibili conflitti di interesse dei consulenti. Tali relazioni dovranno essere sottoposte in via formale al Presidente della task force entro i termini previsti dal calendario del PDP.
e. Relazione della task force. Il Presidente della task force, in collaborazione con l'Issue Manager, compilerà le relazioni regionali, la relazione sui commenti e le altre eventuali informazioni o relazioni in un unico documento, la "relazione preliminare della task force", che distribuirà a tutta la task force entro i termini previsti dal calendario del PDP. La task force terrà un'ultima riunione per valutare il problema e provare a raggiungere un voto di maggioranza qualificata. Dopo l'ultima riunione della task force, il Presidente della task force e l'Issue Manager stileranno un documento conclusivo denominato "relazione della task force", lo pubblicheranno sul sito Web e lo invieranno alle organizzazioni di supporto e ai Comitati consultivi di ICANN. La relazione della task force deve includere:
1. Una descrizione chiara di ogni posizione sulla quale la task force è confluita in un voto di maggioranza qualificata (66% della task force);
2. Se al voto non è stata raggiunta una maggioranza qualificata, una descrizione chiara di tutte le posizioni assunte dai membri della task force comunicate entro la scadenza per la presentazione delle relazioni di circoscrizione. Ogni descrizione deve indicare chiaramente (i) le ragioni che inducono ad assumere la posizione e (ii) le organizzazioni regionali che condividono tale posizione;
3. Un'analisi dell'effetto che il problema ha su ogni regione, comprese le implicazioni finanziarie;
4. Un'analisi del tempo che sarebbe necessario per implementare la politica; e
5. Il parere di ogni consulente esterno aggiunto alla task force dal Consiglio di ccNSO, accompagnato da una descrizione dettagliata (i) delle qualifiche ed esperienze rilevanti e (ii) dei possibili conflitti di interesse del consulente.
8. Procedura da adottare se la task force non viene formata
a. Se il Consiglio di ccNSO decide di non istituire una task force, ogni organizzazione regionale, entro i termini previsti dal calendario del PDP, nominerà un incaricato che riferisca sul punto di vista della Regione in merito al problema. A tali incaricati verrà chiesto di presentare una relazione regionale all'Issue Manager entro i termini previsti dal calendario del PDP.
b. Il Consiglio di ccNSO può, a propria discrezione, intraprendere ulteriori azioni che ritiene utili al PDP, come ad esempio affidare a un individuo o a un'organizzazione specifica la raccolta di informazioni sul problema o la pianificazione di riunioni per il confronto e la programmazione delle attività. Tutte le informazioni dovranno essere inviate all'Issue Manager entro i termini previsti dal calendario del PDP.
c. Il Consiglio di ccNSO chiederà formalmente al Presidente di GAC di offrire il parere o la consulenza di GAC.
d. L'Issue Manager raccoglierà tutte le relazioni regionali, la relazioni sui commenti e ogni altra eventuale informazione e compilerà (e poi pubblicherà sul sito Web) una "relazione iniziale" entro i termini previsti dal calendario del PDP. L'Issue Manager procederà quindi con la preparazione della relazione finale, come descritto al seguente Punto 9.
9. Commenti alla relazione della task force o alla relazione iniziale
a. La relazione sulla task force o la relazione iniziale verrà sottoposta a un periodo di consultazione che, in base al calendario del PDP, avrà normalmente una durata non inferiore ai 21 giorni. Verranno accettati commenti dei gestori ccTLD, di altre organizzazioni di supporto, dei Comitati consultivi e del pubblico. Tutti i commenti riporteranno il nome dell'autore nonché le esperienze da questi maturate in materia e il relativo interesse in merito al problema in esame.
b. Al termine del periodo di consultazione, l'Issue Manager esaminerà i commenti ricevuti e potrà aggiungere quelli che riterrà appropriati alla relazione della task force o alla relazione iniziale, per preparare la "relazione finale". L'Issue Manager non è tenuto a includere tutti i commenti fatti o ricevuti durante il periodo di consultazione da individui e organizzazioni.
c. L'Issue Manager preparerà la relazione finale e la presenterà al Presidente del Consiglio di ccNSO entro i termini previsti dal calendario del PDP.
10. Valutazione del Consiglio
a. Ricevuta la relazione finale, sia questa il risultato del lavoro di una task force o meno, il Presidente del Consiglio di ccNSO (i) la distribuirà a tutti i membri del Consiglio di ccNSO; (ii) indirà una riunione del Consiglio di ccNSO entro i termini previsti dal calendario del PDP in cui il Consiglio di ccNSO tenterà di formulare un suggerimento da presentare al Consiglio di ICANN; e (iii) invierà al Presidente di GAC un invito formale a offrire il parere o la consulenza di GAC. Tale riunione può essere svolta comunque il Consiglio di ccNSO ritenga appropriato, ad esempio di persona o in teleconferenza. L'Issue Manager sarà presente alla riunione.
b. Il Consiglio di ccNSO può iniziare la propria valutazione del problema prima della riunione formale, attraverso riunioni, teleconferenze e scambi di e-mail o negli altri modi che sceglierà di adottare.
c. Se lo ritiene opportuno, durante la riunione finale il Consiglio di ccNSO può sentire il parere di consulenti esterni. Qualora incidano sulla valutazione del Consiglio di ccNSO, le opinioni di tali consulenti saranno (i) inserite nella relazione che il Consiglio di ccNSO stilerà per il Consiglio di ICANN; (ii) identificate specificamente come provenienti da consulenti esterni; e (iii) accompagnate da una descrizione dettagliata (a) delle qualifiche ed esperienze rilevanti e (b) dei possibili conflitti di interesse dei consulenti.
11. Suggerimento del Consiglio di ccNSO
Nel valutare se formulare un "suggerimento del Consiglio di ccNSO" sul problema, il Consiglio di ccNSO cercherà l'unanimità. Se una minoranza si oppone alla posizione di unanimità, preparerà e farà circolare nel Consiglio di ccNSO una dichiarazione che illustra le ragioni della propria opposizione. Se il dibattito nel Consiglio di ccNSO non si conclude con l'unanimità, un suggerimento supportato da 14 o più membri del Consiglio di ccNSO verrà considerato espressione del Consiglio di ccNSO e sarà inviato ai membri come suggerimento del Consiglio di ccNSO. Nonostante quanto sopra, come indicato di seguito, tutti i pareri espressi dai membri del Consiglio di ccNSO durante il PDP devono essere inseriti nella relazione per i membri.
12. Relazione preparata dal Consiglio di ccNSO per i membri
Qualora venga formulato un suggerimento del Consiglio di ccNSO come indicato al Punto 11, l'Issue Manager, entro sette giorni dalla riunione del Consiglio di ccNSO, inserirà il suggerimento del Consiglio di ccNSO e le posizioni degli altri membri del Consiglio di ccNSO in una "relazione per i membri" che dovrà essere approvata dal Consiglio di ccNSO e quindi inviata ai membri. La relazione per i membri deve includere almeno i seguenti punti:
a. Una descrizione chiara del suggerimento formulato dal Consiglio di ccNSO;
b. La relazione finale presentata al Consiglio di ccNSO; e
c. Una copia del verbale della delibera del Consiglio di ccNSO in merito al problema in esame (vedere il Punto 10), comprensiva di tutte le opinioni espresse nell'occasione e corredata dell'identificazione dei soggetti che si sono pronunciati.
13. Voto dei membri
Dopo la trasmissione della relazione per i membri ed entro i termini previsti dal calendario del PDP, i membri di ccNSO avranno la possibilità di mettere ai voti il suggerimento del Consiglio di ccNSO. Il voto dei membri sarà elettronico e i voti verranno accumulati per un periodo specificato dal calendario del PDP (almeno 21 giorni).
Qualora almeno il 50% dei membri di ccNSO voti entro il periodo di voto, il voto risultante verrà utilizzato senza ulteriori elaborazioni. Se invece al primo turno vota meno del 50% dei membri di ccNSO, il primo turno non verrà utilizzato e si terrà un secondo turno finale di voto, almeno 30 giorni dopo la comunicazione ai membri di ccNSO, i cui risultati verranno utilizzati a condizione che voti almeno il 50% dei membri di ccNSO. Nel caso in cui più del 66% dei voti ricevuti alla fine del periodo di voto siano favorevoli al suggerimento del Consiglio di ccNSO, il suggerimento verrà trasmesso al Consiglio di ICANN come suggerimento di ccNSO, come previsto dal seguente Punto 14.
14. Relazione per il Consiglio di ICANN
L'Issue Manager, entro sette giorni dalla formulazione di un suggerimento di ccNSO in conformità a quanto previsto al Punto 13, inserirà il suggerimento di ccNSO in una "relazione per il Consiglio di ICANN", che dovrà essere approvata dal Consiglio di ccNSO e quindi inviata al Consiglio di ICANN. La relazione per il Consiglio di ICANN deve includere almeno i seguenti punti:
a. Una descrizione chiara del suggerimento formulato da ccNSO;
b. La relazione finale presentata al Consiglio di ccNSO; e
c. La relazione per i membri.
15. Voto del Consiglio di ICANN
a. Il Consiglio di ICANN si riunirà per discutere del suggerimento di ccNSO appena possibile dopo aver ricevuto la relazione per il Consiglio di ICANN dall'Issue Manager, tenendo conto delle procedure di valutazione vigenti presso il Consiglio di ICANN.
b. Il Consiglio di ICANN adotterà il suggerimento di ccNSO a meno che, con il voto sfavorevole di più del 66% dei membri, non decida di respingere la politica perché non coincidente con gli interessi di ICANN o della relativa comunità.
1. Nel caso in cui il Consiglio di ICANN ritenga di non agire in accordo con il suggerimento di ccNSO, (i) esprimerà chiaramente le ragioni delle proprie conclusioni in una "relazione del Consiglio di ICANN" e (ii) trasmetterà tale relazione al Consiglio di ccNSO.
2. Il Consiglio di ccNSO esaminerà la relazione del Consiglio di ICANN in vista del confronto che si terrà tra i due Consigli nei trenta giorni di calendario successivi. Il Consiglio di ICANN stabilirà in che modo (teleconferenza, e-mail o altro) i due Consigli si confronteranno in merito alla relazione del Consiglio di ICANN. Il dibattito si terrà in buona fede e in modo rapido ed efficiente con l'intento di trovare una soluzione accettabile per entrambe le parti.
3. Al termine del confronto, il Consiglio di ccNSO si riunirà per ribadire o modificare il proprio suggerimento. Un suggerimento supportato da 14 o più membri del Consiglio di ccNSO verrà considerato espressione del Consiglio di ccNSO ("suggerimento supplementare del Consiglio di ccNSO"). Tale suggerimento supplementare verrà trasmesso ai membri in una relazione supplementare per i membri, corredata di spiegazioni. I membri avranno la possibilità di mettere ai voti il suggerimento supplementare nelle modalità già descritte al Punto 13. Qualora più del 66% dei voti espressi dai membri di ccNSO durante il periodo di voto siano favorevoli al suggerimento supplementare, quest'ultimo verrà trasmesso al Consiglio di ICANN come suggerimento supplementare di ccNSO e il Consiglio di ICANN adotterà il suggerimento a meno che, con il voto sfavorevole di più del 66% dei membri, non concluda che accettare tale politica infrangerebbe il rapporto di fiducia tra il Consiglio di ICANN e l'Azienda.
4. Nel caso in cui il Consiglio di ICANN non accetti il suggerimento supplementare di ccNSO, esprimerà chiaramente le ragioni delle proprie conclusioni nella "relazione supplementare del Consiglio di ICANN".
5. Se il Consiglio di ICANN decide di non accettare il suggerimento supplementare di ccNSO, non potrà adottare una politica in merito al problema oggetto del suggerimento e lo status quo verrà preservato fino al momento in cui ccNSO, attraverso il ccPDP, formulerà un suggerimento che il Consiglio di ICANN potrà ritenere accettabile.
16. Implementazione della politica
Dopo aver adottato un suggerimento di ccNSO o un suggerimento supplementare di ccNSO, il Consiglio di ICANN autorizza o guida il personale di ICANN all'implementazione della politica.
17. Conservazione degli atti
Per ogni ccPDP per cui viene richiesta una relazione sul problema (vedere il Punto 1), ICANN manterrà sul sito Web una pagina di stato che descrive l'evoluzione del processo e include un elenco delle date significative, nonché collegamenti ai seguenti documenti eventualmente prodotti:
a. Relazione sul problema;
b. Calendario del PDP;
c. Relazione sui commenti;
d. Relazioni regionali;
e. Relazione preliminare della task force;
f. Relazione della task force;
g. Relazione iniziale;
h. Relazione finale;
i. Relazione per i membri;
j. Relazione per il Consiglio di ICANN;
k. Relazione del Consiglio di ICANN;
l. Relazione supplementare per i membri; e
m. Relazione supplementare del Consiglio di ICANN.
ICANN pubblicherà inoltre sul sito Web i commenti ricevuti per via telematica che suggeriscono specificamente l'avvio di un ccPDP.
Appendice C: Ambito di attività di ccNSO
In questa appendice vengono descritti l'ambito di attività e i principi operativi, nonché i metodi di analisi da utilizzare per ogni ulteriore estensione del ruolo di sviluppo della politica di ccNSO. Come previsto dall'Articolo IX, Sezione 6(2) dello statuto, tale ambito deve essere definito tenendo conto delle procedure del ccPDP.
L'ambito dell'autorità e delle responsabilità di ccNSO deve tenere conto della complessa relazione tra ICANN e i gestori/registri ccTLD in merito ai problemi inerenti le politiche. Con questa appendice si intende facilitare a ccNSO, al Consiglio di ccNSO e al Consiglio e al personale di ICANN il compito di delineare i problemi inerenti le politiche di rilevanza globale.
Aree inerenti le politiche
Il ruolo di ccNSO in tema di politiche deve essere basato su un'analisi dei seguenti modelli funzionali del DNS:
1. Si esegue la registrazione/archiviazione di dati per generare un zone file,
2. Lo zone file viene a sua volta utilizzato nei TLD name server.
All'interno di un TLD vengono svolte due funzioni (descritte di seguito in maggior dettaglio):
1. Immissione di dati in un database e (funzione di immissione dei dati)
2. Manutenzione e garanzia di efficienza dei name server per il TLD (funzione di name server).
Queste due funzioni fondamentali devono essere svolte a livello di registro ccTLD, nonché a livello superiore (funzione IANA e root server) e inferiore della gerarchia DNS. Questo meccanismo, come rilevato nella RFC 1591, è ricorsivo:
Non vi sono requisiti sui sottodomini dei domini di primo livello oltre ai requisiti esistenti sugli stessi domini di livello superiore. I requisiti indicati in questo promemoria vengono pertanto applicati in modo ricorsivo. In particolare, tutti i sottodomini potranno detenere domain name server propri, offrendo tramite essi qualsiasi informazione il gestore del sottodominio ritenga opportuna (posto che sia vera e corretta).
Funzioni fondamentali
1. Funzione di inserimento dati (DEF, Data Entry Function):
Osservando in maggior dettaglio, la prima funzione (inserimento e archiviazione dei dati in un database) dovrebbe essere completamente definita da un politica di denominazione. Questa politica di denominazione deve specificare i ruoli e le condizioni:
(a) in cui i dati verranno raccolti e inseriti in un database o verranno modificati (ad esempio a livello di TLD, per riflettere un trasferimento da proprietario a proprietario o un cambio di registrar) nel database.
(b) per rendere determinati dati pubblicamente e genericamente disponibili (ad esempio tramite Whois o name server).
2. Funzione di name server (NSF, Name-Server Function)
La funzione di name server solleva problemi essenziali di interoperabilità e stabilità al cuore del sistema dei nomi di dominio. L'importanza di questa funzione si estende ai name server a livello di ccTLD, ma anche ai root server (e sistema root server) e name server di livelli inferiori.
Per il valore intrinseco e per le considerazioni sull'interoperabilità e la stabilità, il corretto funzionamento dei name server è di assoluta importanza sia per gli individui che per le comunità Internet locali e globali.
È pertanto necessario definire e fissare politiche inerenti il funzionamento dei name server. La maggior parte delle parti coinvolte, tra cui la maggioranza dei registri ccTLD, hanno riconosciuto l'esigenza di politiche comuni in quest'area aderendo alle RFC rilevanti, tra cui la RFC 1591.
Rispettivi ruoli in merito a politiche, responsabilità e oneri
È interesse di ICANN e dei gestori ccTLD assicurare il funzionamento stabile e corretto del sistema dei nomi di dominio. Sia ICANN che i registri ccTLD rivestono in quest'ambito ruoli peculiari che possono essere definiti dalle politiche inerenti. L'ambito di attività ccNSO non può essere definito senza raggiungere una posizione comune sulla ripartizione di autorità tra ICANN e i registri ccTLD.
Questi ruoli possono essere delineati pensando a come assegnare la responsabilità di un dato problema:
- Ruolo politico: capacità e potere di definire una politica;
- Ruolo esecutivo: capacità e potere di agire di conseguenza e implementare la politica; e
- Ruolo di responsabilità: capacità e potere di mantenere l'entità responsabile in grado di esercitare il proprio potere.
In primo luogo, la responsabilità presuppone una politica e questo delinea il ruolo politico. A seconda del problema da risolvere, chi è coinvolto nella definizione e nell'attuazione della politica deve essere chiaro e determinato. In secondo luogo, questo presuppone un ruolo esecutivo che definisce il potere di implementare e agire nei limiti di una politica. Infine si rende necessario definire e determinare il ruolo di responsabilità per controbilanciare il ruolo esecutivo.
Le informazioni seguenti costituiscono un aiuto per:
1. delineare e identificare aree specifiche inerenti le politiche;
2. definire e determinare ruoli in relazione a tali aree specifiche inerenti le politiche.
In questa appendice viene definito l'ambito di attività di ccNSO in merito allo sviluppo di politiche. L'ambito è limitato al ruolo politico del processo ccNSO per lo sviluppo di politiche per le funzioni e i livelli esplicitamente descritti di seguito. Si premette che l'accuratezza delle assegnazioni dei ruoli politico, esecutivo e di responsabilità illustrati di seguito verrà considerata durante un processo ccPDP di definizione dell'ambito.
Funzione di name server (come per ccTLD)
Livello 1: root name server
Ruolo politico: IETF, RSSAC (ICANN)
Ruolo esecutivo: operatori del sistema root server
Ruolo di responsabilità: RSSAC (ICANN), (Protocollo d'Intesa tra US DoC e ICANN)Livello 2: name server di registro ccTLD in relazione all'interoperabilità
Ruolo politico: processo ccNSO per lo sviluppo di politiche (ICANN), per le migliori strategie di organizzazione di un processo di ccNSO
Ruolo esecutivo: gestore ccTLD
Ruolo di responsabilità: parte ICANN (IANA), parte la comunità Internet locale, compresi i governi localiLivello 3: name server dell'utente
Ruolo politico: gestore ccTLD, IETF (RFC)
Ruolo esecutivo: proprietario
Ruolo di responsabilità: gestore ccTLD
Funzione di inserimento dati (come per ccTLD)
Livello 1: registro root level
Ruolo politico: processo ccNSO per lo sviluppo di politiche (ICANN)
Ruolo esecutivo: ICANN (IANA)
Ruolo di responsabilità: comunità di ICANN, gestori ccTLD, US DoC, talvolta autorità nazionaliLivello 2: registro ccTLD
Ruolo politico: comunità Internet locale, compresi i governi locali, e/o gestore ccTLD in accordo con le strutture locali
Ruolo esecutivo: gestore ccTLD
Ruolo di responsabilità: comunità Internet locale, talvolta comprese le autorità nazionaliLivello 3: secondo livello e livelli inferiori
Ruolo politico: proprietario
Ruolo esecutivo: proprietario
Ruolo di responsabilità: proprietario, utenti di nomi di dominio di livelli inferiori