Skip to main content
Resources

STATUTO DI INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS | Emendamento del 24 giugno 2011 | Azienda no-profit californiana del settore pubblico

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

Emendamento del 24 giugno 2011

Questo documento è stato tradotto in diverse lingue solo a scopo informativo. Il testo ufficiale e valido (in lingua inglese) è disponibile all'indirizzo seguente: http://www.icann.org/en/general/bylaws.htm

SOMMARIO

ARTICOLO I: MISSIONE 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 ccNSO PER LO SVILUPPO DELLE POLICY
APPENDICE B: PROCESSO ccNSO PER LO SVILUPPO DELLE POLICY (ccPDP)
APPENDICE C: AMBITO DI ATTIVITÀ DI ccNSO

ARTICOLO I: MISSIONE 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 l'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);

c. Numeri di porta e parametro dei protocolli.

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.

Sezione 2. VALORI

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.

ARTICOLO II: POTERI

Sezione 1. POTERI GENERALI

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

Sezione 2. RESTRIZIONI

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.

ARTICOLO III: TRASPARENZA

Sezione 1. OBIETTIVO

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.

Sezione 2. SITO WEB

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, inclusi 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 le ore 23:59 del secondo giorno lavorativo successivo alla conclusione di ogni riunione (in base all'ora locale dell'area geografica della sede principale ICANN principale), ogni azione risolutiva approvata dal Consiglio direttivo nel corso della riunione 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. Il Segretario dovrà comunicare al Consiglio direttivo e ai Presidenti delle organizzazioni di supporto (come definito negli Articoli VIII e X del presente Statuto) e ai Comitati consultivi (come definito nell'Articolo XI del presente Statuto) l'avvenuta pubblicazione delle azioni risolutive.

3. Entro le ore 23:59 del settimo giorno lavorativo successivo alla conclusione di ogni riunione (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 e sarà soggetta alle restrizioni sulla divulgazione definite nella Sezione 5.2 sopra citata. 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.

4. 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 appropriati i 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

Sezione 1. OBIETTIVO

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 dello stesso menzionati nell' Articolo I di questo Statuto. 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.

Sezione 2. RICONSIDERAZIONE

1. ICANN implementerà un processo attraverso il quale qualsiasi persona o entità interessata materialmente da un'azione di ICANN potrà richiedere la revisione o la riconsiderazione di quell'azione da parte del Consiglio.

2. Qualsiasi persona o entità potrà presentare una richiesta di riconsiderazione o di revisione di un'azione o inazione ICANN ("Richiesta di riconsiderazione") nella misura in cui la persona abbia subito l'effetto negativo di:

a. una o più azioni o inazioni dello staff che contraddicono la politica o le politiche ICANN stabilite; o

b. una o più azioni o inazioni del Consiglio ICANN che sono state intraprese o la cui effettuazione è stata rifiutata senza l'esame di informazioni materiali, ad eccezione del caso in cui la parte che presenta la richiesta potrebbe aver presentato ma non lo ha fatto, le informazioni che il Consiglio doveva prendere in esame al momento dell'azione o del rifiuto dell'azione.

3. Il Consiglio ha designato il Board Governance Committee per rivedere e prendere in considerazione tali Richieste di riconsiderazione. Il Board Governance Committee avrà l'autorità di:

a. valutare le richieste di revisione o riconsiderazione;

b. determinare se è appropriata una sospensione dell'azione contestata in attesa di risoluzione della richiesta;

c. condurre qualsiasi accertamento dei fatti, se ritenuto adeguato;

d. richiedere che la parte interessata o altre parti presenti(ino) ulteriore documentazione scritta; e

e. effettuare una raccomandazione al Consiglio d'Amministrazione sui meriti della richiesta.

4. ICANN si assumerà i normali costi amministrativi del processo di riconsiderazione. Si riserva il diritto di recuperare dalla parte richiedente una revisione o una riconsiderazione di tutti i costi ritenuti di tipo straordinario. Se tali costi straordinari possono essere previsti, tale fatto e le ragioni per le quali tali costi sono necessari e adeguati per la valutazione della Richiesta di riconsiderazione andranno comunicati alla parte che richiede riconsiderazione, la quale avrà poi la possibilità di ritirare la richiesta o accettare di sostenere tali costi.

5. Tutte le Richieste di riconsiderazione devono essere presentate a un indirizzo e-mail definito dal Board Governance Committee entro trenta giorni dopo:

a. la data in cui le informazioni sull'azione del Consiglio ricusata sono state pubblicate per la prima volta in un rapporto preliminare o in minute delle riunioni del Consiglio, per richieste che ricusano le azioni del Consiglio; o

b. la data in cui la parte che presenta la richiesta è venuta a conoscenza della, o ragionevolmente sarebbe dovuta venire a conoscenza dell'azione dello staff ricusata, per richieste che ricusano azioni dello staff; o

c. la data in cui la persona interessata ha ragionevolmente concluso o avrebbe dovuto ragionevolmente concludere che l'azione non sarebbe stata effettuata tempestivamente, per richieste che ricusano inazioni del Consiglio o dello staff.

6. Tutte le Richieste di riconsiderazione devono includere le informazioni necessarie per il Board Governance Committee e comprenderanno almeno quanto di seguito indicato:

a. nome, indirizzo e informazioni di contatto per la parte richiedente, compresi indirizzi postali ed e-mail;

b. l'azione o l'inazione specifica di ICANN per la quale è richiesta una revisione o una riconsiderazione;

c. la data dell'azione o dell'inazione;

d. il modo in cui la parte richiedente sarà interessata dall'azione o dall'inazione;

e. la misura in cui, secondo la parte che presente la Richiesta di riconsiderazione, l'azione o l'inazione contestata ha effetti negativi su altri;

f. se è richiesta una sospensione temporanea di qualsiasi azione contestata e, in questo caso, i danni che ne derivano se l'azione non viene sospesa;

g. in caso di azione o inazione dello staff, una spiegazione dettagliata dei fatti così come presentata allo staff e le ragioni per le quali l'azione o l'inazione dello staff era incompatibile con la(e) politica(che) ICANN stabilita(e);

h. in caso di azione o inazione del Consiglio, una spiegazione dettagliata delle informazioni materiali non prese in considerazione dal Consiglio e, se le informazioni non sono state presentate al Consiglio, le ragioni per le quali la parte che presenta la richiesta non ha presentato tali informazioni al Consiglio prima che questo agisse od omettesse di agire;

i. quali passi specifici la parte richiedente ha richiesto di effettuare a ICANN, ovvero se e come l'azione deve essere revocata, annullata o modificata o quale azione specifica deve essere presa;

j. i motivi sulla base dei quali l'azione richiesta andrebbe effettuata; e

k. qualsiasi documento la parte richiedente desidera presentare a supporto di questa richiesta.

7. Tutte le Richieste di riconsiderazione saranno pubblicate sul sito Web.

8. Il Board Governance Committee avrà l'autorità di prendere in esame Richieste di riconsiderazione di diverse parti nello stesso procedimento se (i) le richieste riguardano la stessa azione o inazione generale e (ii) le parti che presentano Richieste di riconsiderazione sono interessate in modo simile da tale azione o inazione.

9. Il Board Governance Committee revisionerà le Richieste di riconsiderazione subito dopo averle ricevute e annuncerà, entro trenta giorni dal ricevimento, la sua intenzione di rifiutare di prendere in esame o di procedere a prendere in esame una Richiesta di riconsiderazione. L'annuncio sarà pubblicato sul sito Web.

10. L'annuncio del Board Governance Committee di una decisione di non esaminare una Richiesta di riconsiderazione deve contenere una spiegazione delle ragioni di tale decisione.

11. Il Board Governance Committee può richiedere ulteriori informazioni o chiarimenti alla parte che presenta la Richiesta di riconsiderazione.

12. Il Board Governance Committee può richiedere allo staff ICANN che cosa ne pensa della questione e i relativi commenti saranno resi pubblici sul sito Web.

13. Se il Board Governance Committee richiede ulteriori informazioni, può preferire la conduzione di un incontro con la parte richiedente la Riconsiderazione per telefono, e-mail o di persona se accettabile per la parte che richiede riconsiderazione. Nella misura in cui qualsiasi informazione raccolta in tale incontro è importante per qualsiasi raccomandazione del Board Governance Committee, ciò andrà così indicato nella sua raccomandazione.

14. Il Board Governance Committee può inoltre richiedere a terze parti informazioni importanti per la richiesta. Nella misura in cui qualsiasi informazione raccolta è importante per qualsiasi raccomandazione del Board Governance Committee, ciò andrà così indicato nella sua raccomandazione.

15. Il Board Governance Committee agirà in merito a una Richiesta di riconsiderazione sulla base della documentazione scritta pubblica, incluse le informazioni presentate dalla parte che richiede riconsiderazione o revisione, da parte dello staff ICANN e da qualsiasi terza parte.

16. Per proteggersi da un abuso del processo di riconsiderazione, una richiesta di riconsiderazione può essere respinta dal Board Governance Committee, se è ripetitiva, futile, non concreta o altrimenti illecita, o se la parte interessata ha ricevuto comunicazione di ed ha avuto l'opportunità di, ma non lo ha fatto, partecipare al periodo di commenti pubblici correlato all'azione contestata, se applicabile. Allo stesso modo, il Board Governance Committee può respingere una richiesta se la parte richiedente non dimostra che sarà interessata da un'azione di ICANN.

17. Il Board Governance Committee effettuerà una raccomandazione finale al Consiglio rispetto ad una Richiesta di riconsiderazione entro novanta giorni dal ricevimento, a meno che non sia inattuabile; in tal caso presenterà al Consiglio un rapporto sulle circostanze che gli hanno impedito di effettuare una raccomandazione finale e la sua migliore stima del tempo necessario per produrre una tale raccomandazione finale. La raccomandazione finale sarà pubblicata sul sito Web.

18. Il Consiglio non sarà vincolato a seguire le raccomandazioni del Board Governance Committee. La decisione finale del Consiglio sarà resa pubblica come parte del rapporto e delle minute preliminari della riunione del Consiglio durante la quale si interviene.

19. Il Board Governance Committee presenterà un rapporto al Consiglio su base annuale, contenente almeno le seguenti informazioni per l'anno di calendario precedente:

a. il numero e la natura generale delle Richieste di riconsiderazione ricevute;

b. il numero di Richieste di riconsiderazione per le quali il Board Governance Committee è intervenuto;

c. il numero di Richieste di riconsiderazione rimaste irrisolte al termine dell'anno di calendario e la lunghezza media del tempo per il quale tali Richieste di riconsiderazione sono rimaste in sospeso;

d. una descrizione delle Richieste di riconsiderazione che erano in sospeso al termine dell'anno di calendario da oltre novanta (90) giorni e le ragioni per le quali il Board Governance Committee non ha agito al riguardo;

e. il numero e la natura delle Richieste di riconsiderazione che il Board Governance Committee ha rifiutato di prendere in esame sulla base del fatto che non soddisfacevano i criteri definiti in questa politica;

f. per le Richieste di riconsiderazione che sono state negate, una spiegazione di qualsiasi meccanismo disponibile per garantire che ICANN sia responsabile rispetto alle persone materialmente interessate dalle sue decisioni; e

g. se o meno, secondo il Board Governance Committee, i criteri per i quali la riconsiderazione può essere richiesta debbano essere riveduti o un altro processo debba essere adottato o modificato, per assicurare che tutte le persone materialmente interessate dalle decisioni di ICANN abbiano un accesso significativo a un processo di revisione, il quale garantisca correttezza nel limitare le richieste futili.

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.

8. IRP avrà il potere di:

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 delle prestazioni e dell'operatività di ogni Organizzazione di sostegno, Comitato di organizzazione di sostegno, Comitato consultivo (diverso dal Comitato consultivo governativo) 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.

Se ritenuto fattibile da parte del Consiglio, tali revisioni periodiche dovranno essere effettuate almeno ogni cinque anni. Ogni ciclo quinquennale verrà calcolato a partire dal momento in cui il Consiglio riceverà dal gruppo di lavoro la relazione finale relativa alla revisione effettuata.

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. Il Comitato consultivo governativo dovrà provvedere ai propri meccanismi di revisione.

ARTICOLO V: OMBUDSMAN

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.

Sezione 2. MANDATO

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.

Sezione 3. ATTIVITÀ

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.

Sezione 5. RELAZIONE ANNUALE

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 sedici membri votanti ("Direttori"). Inoltre, dovranno essere designati cinque 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

1. I Direttori saranno:

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.

e. Un membro votante selezionato dall'At-Large Community secondo le disposizioni dell'Articolo XI del presente Statuto. Questa posizione all'interno del Consiglio direttivo viene citata nel presente Statuto come Posizione 15.

f. Il Presidente d'ufficio, in qualità di membro votante.

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. Mai durante l'effettuazione della sua selezione, il Comitato di nomina selezionerà un Consigliere perché occupi un qualsiasi posto vacante o assuma un incarico scaduto, la selezione del quale causerebbe la presenza di un numero totale di consiglieri (Presidente escluso) provenienti da una qualsiasi Regione geografica (come definito nella Sezione 5 di questo Articolo ) superiore a cinque; inoltre, il Comitato di nomina assicurerà che, durante l'effettuazione delle sue selezioni, il Consiglio includa almeno un Consigliere proveniente da un paese di ogni Regione geografica ICANN (“Calcolo diversità”).

Per gli scopi di questa sottosezione 2 dell'Articolo VI, Sezione 2 dello Statuto ICANN, se qualunque candidato alla posizione di consigliere ha la cittadinanza in più di un paese o è stato domiciliato per oltre cinque anni in un paese di cui non ha la cittadinanza (“Domicilio”), tale candidato può essere ritenuto provenire da uno o dall'altro paese e deve scegliere nella sua Dichiarazione di interesse il paese di cittadinanza o di domicilio che desidera che il Comitato di nomina utilizzi per il Calcolo diversità. Per gli scopi di questa sottosezione 2 dell'Articolo VI, Sezione 2 dello Statuto ICANN, una persona può avere solo un “Domicilio”, che sarà definito dal luogo in cui il candidato ha una residenza permanente e un domicilio.

3. Nel tener fede alle proprie responsabilità per l'esercizio delle Posizioni dalla 9 alla 15, le Organizzazioni di sostegno e l'At-Large Community 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 qualsiasi momento, non vi saranno due Consiglieri scelti da una Supporting Organization provenienti dallo stesso paese o da paesi della stessa Regione geografica.

Per gli scopi di questa sottosezione 3 dell'Articolo VI, Sezione 2 dello Statuto ICANN, se qualunque candidato alla posizione di consigliere ha la cittadinanza in più di un paese o è stato domiciliato per oltre cinque anni in un paese di cui non ha la cittadinanza (“Domicilio”), tale candidato può essere ritenuto provenire da uno o dall'altro paese e deve scegliere nella sua Dichiarazione di interesse il paese di cittadinanza o di domicilio che desidera che l'Organizzazione di Sostegno o l'At-Large Community utilizzi per la selezione. Per gli scopi di questa sottosezione 3 dell'Articolo VI, Sezione 2 dello Statuto ICANN, una persona può avere solo un “Domicilio”, che sarà definito dal luogo in cui il candidato ha una residenza permanente e un domicilio.

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 o dell'At-Large Community, tale persona non potrà, in seguito a tale nomina, partecipare a qualsivoglia discussione o votazione del Consiglio dell'organizzazione di sostegno o del comitato designato dall'At-Large Community relativa alla selezione dei Direttori da parte del Consiglio o della Community, finché il Consiglio o i comitati designati dall'At-Large Community non abbiano selezionato il complesso dei Direttori. Nel caso in cui una persona che ricopre una qualsiasi funzione all'interno del Consiglio dell'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 Consiglio. Nel caso in cui una persona che ricopre una qualsiasi funzione all'interno dell'At-Large Community accetti una nomina di ammissione alla selezione per il ruolo di Direttore, l'organizzazione At-Large regionale o qualsivoglia altro gruppo o ente che abbia selezionato tale persona potrà scegliere un sostituto ai fini del processo di selezione della Community.

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, le Organizzazioni di sostegno e l'At-Large Community 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. CONFLITTO D'INTERESSI DEI CONSIGLIERI

Il Consiglio, attraverso il Board Governance Committee, richiederà a ciascun Consigliere una dichiarazione da presentarsi non meno frequentemente di una volta l'anno indicante tutte le attività e altre affiliazioni in qualunque modo correlate all'attività e ad altre affiliazioni di ICANN. Ogni Consigliere sarà responsabile della divulgazione a ICANN di qualsiasi elemento che potrebbe essere ragionevolmente considerato rendere tale Consigliere un "consigliere interessato" ai sensi della Sezione 5233 della Legge California Nonprofit Public Benefit Corporation Law ("CNPBCL"). Inoltre, ogni Consigliere rivelerà a ICANN qualsiasi relazione o altro fattore che potrebbe essere ragionevolmente ritenuto causare la presa in considerazione del Consigliere come una "persona interessata" ai sensi della Sezione 5227 della Legge CNPBCL. Il Consiglio adotterà politiche riguardanti specificatamente i conflitti d'interessi di Consiglieri, Funzionari e Supporting Organization. Nessun Consigliere voterà su questioni in cui abbia un interesse materiale e finanziario diretto che sarebbe influenzato dal risultato del voto.

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. Il regolare mandato delle Posizioni di Direttore dalla 1 alla 15 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. I mandati delle Posizioni 9 e 12 saranno mantenuti fino al termine della riunione ICANN di metà anno successiva alla riunione annuale del 2011. I successivi mandati delle Posizioni 9 e 12 avranno inizio al termine della riunione di metà anno successiva alla riunione annuale di ICANN del 2011 e a ogni riunione annuale di ICANN dei tre anni successivi al 2011.

e. I mandati delle Posizioni 10 e 13 saranno mantenuti fino al termine della riunione di ICANN di metà anno successiva alla riunione annuale del 2012. I successivi mandati delle Posizioni 10 e 13 avranno inizio al termine della riunione di metà anno che si terrà dopo la riunione annuale di ICANN del 2012 e dopo ogni riunione annuale di ICANN dei tre anni successivi al 2012 e

f. I mandati delle Posizioni 11 e 14 avranno inizio al termine della riunione di ICANN di metà anno successiva alla riunione annuale di ICANN del 2010 e dopo ogni riunione annuale di ICANN dei tre anni successivi al 2010.

g. Il primo regolare mandato della Posizione 15 avrà inizio al termine della riunione di ICANN di metà anno successiva alla riunione annuale di ICANN del 2010 e dopo ogni riunione annuale di ICANN dei tre anni successivi al 2010. Nota: nel periodo precedente l'inizio del regolare mandato della Posizione 15, quest'ultima sarà ritenuta vacante. Mediante una procedura coordinata dall'At-Large Advisory Committee, l'At-Large Community ha selezionato un Direttore per la Posizione 15 vacante dandone comunicazione scritta al Segretario di ICANN. La Posizione 15 vacante è stata occupata al termine della riunione annuale di ICANN tenutasi nel 2010, con mandato da concludersi al termine del primo regolare mandato previsto per la Posizione 15, secondo quanto definito in questa Sezione dello Statuto. Fino al termine della riunione annuale di ICANN del 2010, il Comitato At-Large Committee ha nominato un funzionario di collegamento non votante partecipante, come specificato nelle Sezioni 9(3) e 9(5) del presente Articolo.

h. Il termine "Riunione di metà anno" menzionato in questa sezione fa riferimento alla prima riunione pubblica di ICANN che si tiene entro otto mesi a partire dal termine della riunione globale annuale di ICANN. In caso di pianificazione e successiva cancellazione di una riunione di metà anno entro sei mesi precedenti la data di inizio della stessa, il mandato per le posizioni previste al termine di tale riunione avrà inizio nella data di conclusione della riunione di metà anno precedentemente stabilita. Qualora non venga programmata alcuna riunione pubblica nel periodo di tempo definito per la riunione di metà anno, il mandato delle posizioni con inizio previsto al termine della riunione di metà anno avrà inizio sei mesi dopo la data di conclusione della riunione annuale di ICANN.

2. Ogni Direttore che ricopra una qualsiasi delle Posizioni dalla 1 alla 15, 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. Almeno due mesi prima della data di inizio del mandato, come descritto nei precedenti paragrafi 1.d-g, qualsiasi Organizzazione di sostegno o l'At-Large Community autorizzata alla selezione di un Direttore per una Posizione il cui mandato abbia inizio nello stesso anno 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 scopo, una persona scelta per occupare un posto vacante durante un incarico, non sarà ritenuta avere assunto quell'incarico. Le funzioni precedentemente svolte nelle Posizioni 9, 10, 11, 12, 13 e 14 con riferimento agli incarichi definiti nello Statuto alla data [inserire la data prima dell'attuazione dell'emendamento], a condizione che non siano state svolte per occupare un posto vacante, dovranno essere incluse nel calcolo dei mandati consecutivi descritti nel presente paragrafo.

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 IX 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 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. A seguito di notifica, qualsiasi Direttore può essere rimosso 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 votante del Consiglio nel calcolo dei tre quarti (3/4) previsto dalla procedura. Inoltre, ciascun voto per la rimozione di un Direttore dovrà costituire un voto specifico per la rimozione di tale Direttore. Se il Direttore è stato selezionato da un'Organizzazione di sostegno, quest'ultima e il Direttore stesso dovranno riceverne comunicazione nello stesso momento. Se il Direttore è stato selezionato dall'At-Large Community, quest'ultima e il Direttore dovranno riceverne comunicazione nello stesso momento.

2. Inoltre, ogni voto per la rimozione del Direttore costituirà un voto distinto esclusivamente in relazione alla rimozione di tale Direttore. 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.

Sezione 12. POSIZIONI VACANTI

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 di questo 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.

Sezione 13. RIUNIONI ANNUALI

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.

Sezione 17. QUORUM

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.

Sezione 20. POSTA ELETTRONICA

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.

Sezione 22. REMUNERAZIONE

Il Presidente del Consiglio di ICANN avrà diritto a ricevere una ragionevole remunerazione per l'incarico svolto in qualità di Direttore. Il comitato incaricato dovrà stabilire un livello accettabile di remunerazione per il Presidente del Consiglio di ICANN. Solo i membri del Comitato per le remunerazioni esenti da conflitti di interesse con la parte interessata alla remunerazione parteciperanno alle deliberazioni o ai voti in merito alla remunerazione proposta al Consiglio. Solo i membri del Consiglio esenti da conflitti di interesse con la parte interessata alla remunerazione parteciperanno alle deliberazioni o ai voti per l'approvazione dei compensi del Presidente del Consiglio di ICANN. Il Presidente non parteciperà mai alle deliberazioni o alle votazioni in merito al proprio compenso. Il Comitato per le remunerazioni e il Consiglio seguiranno le idonee procedure previste dall'Internal Revenue Code e dalle normative fiscali applicabili statunitensi al fine di garantire una presunzione legale relativa (non assoluta) delle legittime retribuzioni stabilite per il Presidente del Consiglio.

A eccezione del Presidente del Consiglio, i Direttori non riceveranno alcuna remunerazione per il servizio prestato. 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 a 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

Sezione 1. DESCRIZIONE

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

Sezione 2. COMPOSIZIONE

Il Comitato per l'assegnazione delle nomine sarà composto dalle figure seguenti:

1. Un Presidente non votante, nominato dal Consiglio di ICANN;

2. Un Presidente eletto non votante nominato dal Consiglio di ICANN come 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. I delegati con diritto di voto per il Comitato per l'assegnazione delle nomine saranno selezionati dalla Generic Names Supporting Organization, descritta all' Articolo X del presente Statuto, secondo le seguenti modalità:

a. Un delegato del gruppo delle parti interessate ai Registri;

b. Un delegato del gruppo delle parti interessati ai Registrar;

c. Due delegati dell'organizzazione Circoscrizione aziendale, uno che rappresenta gli utenti di piccole aziende e uno gli utenti delle grandi aziende;

d. Un delegato della Circoscrizione degli Internet Service Provider;

e. Un delegato della Circoscrizione delle proprietà intellettuali; e

f. Un delegato dei gruppi di consumatori e società civile selezionato dalla Circoscrizione degli utenti non commerciali.

8. Un delegato con diritto di voto selezionato da ciascuna delle seguenti entità:

a. Il Comitato dell'organizzazione Country Code Names Supporting Organization descritta all' Articolo IX del presente Statuto;

b. Il Comitato dell'organizzazione Address Supporting Organization descritta all' Articolo VIII del presente Statuto;

c. L'Internet Engineering Task Force; e

d. Il Technical Liaison Group di ICANN, descritto all' Articolo XI-A del presente Statuto;

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.

Sezione 3. MANDATI

Subordinato alle condizioni dell' Articolo sulla transizione di questo 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 eletto e qualsiasi Presidente Associato svolgeranno le proprie funzioni fino alla conclusione della riunione annuale di ICANN successiva.

4. Al termine del mandato del Presidente eletto, quest'ultimo verrà nominato dal Consiglio affinché ricopra la posizione di Presidente. Tuttavia, il Consiglio può nominare, a sua discrezione, un'altra persona come Presidente. Se al momento della nomina di un Presidente eletto il Consiglio stabilisce che la persona selezionata come Presidente sarà nominata tale per un mandato successivo, la posizione di Presidente eletto rimarrà vacante per il periodo stabilito dal Consiglio.

5. Le posizioni vacanti relative a delegati, funzionari di collegamento non votanti, Presidente o Presidente eletto saranno occupate dall'entità che ha diritto di selezionare il delegato, funzionario di collegamento non votante, Presidente o Presidente eletto. Per i mandati relativi alle posizioni di Presidente eletto vacanti, come definito nel paragrafo 4 di questo Articolo, o fino alla possibile occupazione di tali posizioni, il Consiglio può nominare un consigliere non votante come Presidente scegliendolo tra persone che abbiano svolto funzioni in precedenza nel Consiglio o nel Comitato per l'assegnazione delle nomine, incluso il Presidente del Comitato per l'assegnazione delle nomine immediatamente precedente. Le posizioni vacanti relative al Presidente Associato possono essere occupate dal Presidente in conformità ai criteri specificati nella Sezione 2(9) di questo Articolo.

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

6. Persone in grado di operare e comunicare nella lingua inglese scritta e parlata.

Sezione 5. DIVERSITÀ

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.

Sezione 7. PROCEDURE

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

Sezione 1. DESCRIZIONE

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

Sezione 1. DESCRIZIONE

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

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.

Sezione 2. ORGANIZZAZIONE

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.

Sezione 3. Consiglio 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. Subordinato alle condizioni dell' Articolo sulla transizione di questo 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 di questa 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 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.

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.

Sezione 4. COMPOSIZIONE

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 un'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 di questa 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

Sezione 1. DESCRIZIONE

Vi sarà un ente per lo sviluppo della politica noto come Generic Names Supporting Organization (GNSO), che sarà responsabile di sviluppare e raccomandare al Comitato direttivo ICANN politiche concrete relative ai domini generici di primo livello.

Sezione 2. ORGANIZZAZIONE

La GNSO sarà costituita da:

(i) Diverse circoscrizioni, se possibile, organizzate all'interno dei gruppi delle parti interessate, come descritto nella Sezione 5 di questo Articolo;

(ii) Quattro gruppi delle parti interessate organizzati all'interno di Camere, come descritto nella Sezione 5 di questo Articolo;

(iii) Due Camere all'interno del Consiglio di GNSO, come descritto nella Sezione 3(8) di questo Articolo; e

(iv) Un Consiglio di GNSO responsabile della gestione del processo di sviluppo delle politiche di GNSO, come descritto nella Sezione 3 di questo Articolo.

Salvo diversa indicazione nel presente Statuto, i quattro gruppi delle parti interessate e le Circoscrizioni saranno responsabili della definizione dei propri statuti con relativa approvazione da parte dei membri e del Consiglio direttivo di ICANN.

Sezione 3. CONSIGLIO GNSO

1. Secondo quanto disposto dall' Articolo XX di transizione, Sezione 5 di questo Statuto e come descritto nella Sezione 5 di questo Articolo, il Consiglio di GNSO sarà costituito da:

a. tre rappresentanti selezionati dal gruppo delle parti interessate ai Registri;

b. tre rappresentanti selezionati dal gruppo delle parti interessate ai Registrar;

c. sei rappresentanti selezionati dal gruppo delle parti interessate commerciale;

d. sei rappresentanti selezionati dal gruppo delle parti interessate non commerciale;

e. tre rappresentanti selezionati dal Comitato per l'assegnazione delle nomine di ICANN, di cui uno non votante ma con diritto di partecipazione alle stesse condizioni dei membri del Consiglio di GNSO, ad esempio prendere o assecondare iniziative e, se candidati, ricoprire incarichi da Presidente. Il Comitato per l'assegnazione delle nomine assegnerà a ciascuna Camera un rappresentante con diritto di voto designato dal Comitato per l'assegnazione delle nomine (come descritto nella Sezione 3(8) di questo Articolo ).

Un rappresentante non può ricoprire contemporaneamente più posizioni nel Consiglio di GNSO.

Nei propri statuti, i gruppi delle parti interessate devono garantire una rappresentanza del Consiglio di GNSO il più possibile diversificata e attendibile in termini di provenienza geografica, Circoscrizione GNSO, settore, abilità e sesso.

Nel Consiglio di GNSO potrebbero essere presenti anche funzionari di collegamento provenienti da altre organizzazioni di sostegno di ICANN e/o Comitati consultivi. L'organizzazione deputata alla nomina designerà, revocherà o sostituirà i suoi funzionari di collegamento all'interno del Consiglio di GNSO inviandone comunicazione scritta al Presidente del Consiglio di GNSO e al Segretario di ICANN. I funzionari di collegamento non saranno membri del Consiglio di GNSO o autorizzati a votare, prendere o assecondare iniziative o ricoprire incarichi di funzionari presso il Consiglio stesso, ma saranno autorizzati a partecipare alle medesime condizioni dei membri del Consiglio di GNSO.

2. Secondo quanto disposto dall' Articolo XX di transizione e dalla Sezione 5 di questo Statuto , il normale incarico di ogni membro del Consiglio di GNSO avrà inizio al termine della riunione annuale di ICANN e si concluderà al termine della seconda riunione annuale di ICANN successiva. Il normale incarico dei due rappresentanti selezionati dai gruppi delle parti interessate con tre posizioni presso il Consiglio inizierà in anni pari e il normale incarico dell'altro rappresentante selezionato dal gruppo delle parti interessate inizierà in anni dispari. Il normale incarico dei tre rappresentanti selezionati dai gruppi delle parti interessate con sei posizioni presso il Consiglio inizierà in anni pari e il normale incarico degli altri tre rappresentanti selezionati da quel gruppo delle parti interessate inizierà in anni dispari. Il normale incarico di uno dei tre membri selezionati dal Comitato per l'assegnazione delle nomine inizierà in anni pari e il normale incarico degli altri due dei tre membri selezionati dal Comitato per l'assegnazione delle nomine inizierà in anni dispari. Ciascun membro del Consiglio di GNSO 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.

A eccezione di “circostanze speciali”, come, a titolo esemplificativo, soddisfare la diversità geografica o altri tipi di diversità definiti dagli statuti dei gruppi delle parti interessate, laddove non siano disponibili rappresentanti alternativi, nessun membro del Consiglio può essere selezionato per assumere più di due incarichi consecutivi; in circostanze simili, un membro del Consiglio riceverà un ulteriore incarico. A questo scopo, una persona scelta per occupare un posto vacante durante un incarico, non sarà ritenuta avere assunto quell'incarico. Un ex membro del Consiglio che abbia ricoperto due incarichi consecutivi non deve assumere posizioni per un intero incarico prima di assumerne altri come membro del Consiglio. Le “circostanze speciali” vengono stabilite nelle Procedure operative di GNSO.

3. In caso di decesso, dimissioni o destituzione di un membro del Consiglio del GNSO, la relativa posizione sarà considerata vacante. I posti vacanti saranno occupati per il periodo rimanente del mandato a cura del Comitato per l'assegnazione delle nomine o del gruppo delle parti interessate che ha selezionato il membro che occupa la posizione prima che il posto diventasse vacante, comunicandone la selezione per iscritto al Segretario di GNSO. Le procedure relative alla gestione dei posti vacanti tra i membri del Consiglio di GNSO assegnati dal gruppo delle parti interessate, dimissioni e rimozioni dagli incarichi sono definite nello Statuto del gruppo delle parti interessate pertinente.

Un membro del Consiglio di GNSO selezionato dal Comitato per l'assegnazione delle nomine può essere rimosso dall'incarico per le seguenti cause: i) con il voto di tre quarti (3/4) di tutti i membri della Camera pertinente in cui è stato nominato un rappresentante del Comitato per l'assegnazione delle nomine; ii) con il voto di tre quarti (3/4) di tutti i membri di ciascuna Camera in presenza di un rappresentante del Comitato per l'assegnazione delle nomine non votante (vedere la Sezione 3(8) di questo Articolo ). Tale rimozione sarà soggetta a cambiamenti a discrezione del consiglio di ICANN su richiesta da parte del membro del Consiglio di GNSO interessato.

4. Il Consiglio del GNSO è responsabile della gestione del processo di sviluppo delle Policy del GNSO. Avrà inoltre il compito di adottare le procedure (“Procedure operative di GNSO”) che riterrà opportune per svolgere tale funzione, purché siano approvate da un voto di maggioranza di ciascuna Camera. Le Procedure operative di GNSO verranno attuate allo scadere di un periodo di discussione pubblica di ventuno (21) giorni e saranno soggette a supervisione e revisione da parte del Consiglio. Fino a quando il Consiglio di GNSO non suggerirà delle modifiche da apportare, le procedure applicabili saranno quelle descritte nella Sezione 6 di questo Articolo.

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 GNSO selezionerà i soggetti destinati a occupare le Posizioni 13 e 14 del Consiglio di ICANN tramite votazione scritta o nel corso di una riunione. Ciascuna Camera votante di GNSO, come descritto nella Sezione 3(8) di questo Articolo , selezionerà la persona che occuperà una delle due posizioni del Consiglio di ICANN, come descritto di seguito. Ogni selezione così effettuata richiede il voto favorevole del sessanta percento (60%) di tutti i membri della Camera votanti:

a. la Camera della parte acquisita selezionerà un rappresentante per la Posizione 13 e

b. la Camera della parte non acquisita selezionerà un rappresentante per la Posizione 14

I processi di elezione sono descritti nelle Procedure operative di GNSO.

Il Presidente della GNSO ha il dovere di informare per iscritto il Segretario di ICANN delle selezioni effettuate dal Consiglio, in conformità con le disposizioni dell'Articolo VI, Sezioni 8(4) e 12(1).

7. Il Consiglio di GNSO selezionerà il Presidente per un mandato che sarà cura del Consiglio specificare, ma non più lungo di un anno. Ciascuna Camera (come descritto nella Sezione 3.8 di questo Articolo ) selezionerà un Vicepresidente per l'intero Consiglio di GNSO, per un mandato che sarà cura del Consiglio stesso specificare, ma non più lungo di un anno. Le procedure relative alla selezione del Presidente e di qualsiasi altro funzionario sono definite nelle Procedure operative di GNSO. Se allo scadere del precedente mandato di Presidente il Consiglio di GNSO non ha eletto un Presidente, i Vicepresidenti opereranno come co-presidenti della GNSO provvisori fino alla successiva elezione.

8. Se non diversamente richiesto nel presente Statuto, per la fase di votazione, all'interno del Consiglio di GNSO (vedere la Sezione 3(1) di questo Articolo) verranno istituite due Camere, come descritto di seguito:

a. la Camera delle parti acquisite include il Gruppo delle parti interessate ai Registri (tre membri), il Gruppo delle parti interessate ai Registrar (tre membri) e un membro votante nominato dal Comitato per l'assegnazione delle nomine di ICANN, per un totale di sette membri votanti e

b. la Camera delle parti non acquisite include il Gruppo delle parti interessate commerciale (sei membri), il Gruppo delle parti interessate non commerciale (sei membri) e un membro votante nominato dal Comitato per l'assegnazione delle nomine di ICANN, per un totale di tredici membri votanti.

Se non diversamente specificato nel presente Statuto, ogni membro di una Camera votante dovrà esprimere un voto per ciascuna questione soggetta a votazione prima del Consiglio di GNSO.

9. Se non diversamente specificato nel presente Statuto, nell' Appendice A allegata o nelle Procedure operative di GNSO, la soglia massima per l'approvazione di una proposta del Consiglio di GNSO o di altre azioni oggetto di voto è fissata a un voto di maggioranza da parte di ciascuna Camera. Tale soglia, descritta di seguito, sarà applicata ai seguenti piani della GNSO:

a. Creazione di una relazione sulle problematiche: richiede più del 25% di voti favorevoli di ciascuna Camera o un voto di maggioranza di una Camera;

b. Avvio di un Processo di sviluppo delle policy (“PDP”, Policy Development Process) entro l'ambito di competenza di GNSO (come descritto nell' Appendice A ): richiede più del 33% dei voti favorevoli di ciascuna Camera o più del 66% dei voti espressi da una Camera;

c. Avvio di un PDP entro l'ambito di competenza di GNSO: richiede più del 75% di voti favorevoli di una Camera o un voto di maggioranza dell'altra Camera (“Maggioranza qualificata di GNSO”).

d. Approvazione di una proposta relativa al PDP senza una maggioranza qualificata di GNSO: richiede un voto favorevole di maggioranza di ciascuna Camera e l'adesione di un rappresentante membro del Consiglio di GNSO di almeno 3 gruppi delle parti interessate.

e. Approvazione di una proposta relativa al PDP con una maggioranza qualificata di GNSO: richiede un voto favorevole a maggioranza qualificata di GNSO; e

f. Approvazione di una proposta relativa al PDP che impone nuovi doveri su alcune parti contraenti: nel caso in cui un contratto fornito da ICANN indichi che il consenso viene raggiunto con “i due terzi dei voti del Consiglio”, dovrà essere raggiunta o superata la soglia massima dei voti a maggioranza qualificata di GNSO relativa alle parti contraenti interessate.

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. ICANN può, a sua discrezione, rimborsare le spese di viaggio ai membri della GNSO adottando di volta in volta le procedure o le linee guida relative al supporto di viaggio.

Sezione 5. GRUPPI DELLE PARTI INTERESSATE

1. I seguenti Gruppi delle parti interessate sono con la presente riconosciuti come rappresentanti di un gruppo specifico di uno o più Circoscrizioni o gruppi di interesse e soggetti alle disposizioni dell' Articolo XX di transizione, Sezione 5 del presente Statuto.

a. Gruppo delle parti interessate ai Registri in rappresentanza di tutti i registri gTLD sotto contratto con ICANN;

b. Gruppo delle parti interessate ai Registrar in rappresentanza di tutti i registrar sotto contratto con ICANN e da esso accreditati;

c. Gruppo delle parti interessate commerciale in rappresentanza dell'intera gamma di piccoli o grandi enti commerciali di servizi Internet;

d. Gruppo delle parti interessate non commerciale in rappresentanza dell'intera gamma di enti non commerciali di servizi Internet.

2. A ogni gruppo delle parti interessate viene assegnato un numero specifico di posizioni all'interno del Consiglio, come riportato nella Sezione 3(1) di questo Articolo.

3. Se applicabile, ciascun gruppo delle parti interessate riportato nel paragrafo 1 di questa Sezione e ciascuna Circoscrizione a esso associata devono essere riconosciuti dal Consiglio di ICANN. Tale riconoscimento viene concesso dal Consiglio fintantoché l'ente rappresenterà di fatto gli interessi delle community delle parti interessate che dichiara di rappresentare e agirà, nella massima misura possibile, in maniera trasparente e coerente con le procedure designate a garantire equità. Gli Statuti del gruppo delle parti interessate e della circoscrizione possono essere soggetti a revisione periodica, come stabilito dal Consiglio.

4. Qualsiasi gruppo di persone fisiche o giuridiche ha la facoltà di richiedere al Consiglio, tramite petizione, il riconoscimento come Circoscrizione nuova o separata della Camera delle parti non acquisite. Tale petizione dovrà contenere i seguenti elementi:

a. Una descrizione dettagliata del motivo per cui l'aggiunta della Circoscrizione migliorerà la capacità della GNSO di svolgere le proprie funzioni di sviluppo delle policy;

b. Una descrizione dettagliata del motivo per cui la nuova Circoscrizione proposta rappresenta adeguatamente, su base globale, le parti interessate che si propone di rappresentare;

c. Una proposta relativa a disposizioni di tipo organizzativo all'interno di uno specifico gruppo delle parti interessate; e

d. La proposta di uno statuto che si attenga ai principi e alle procedure contenuti in questo Statuto.

Qualsiasi petizione presentata per il riconoscimento di una nuova Circoscrizione e il relativo statuto dovranno essere pubblicati e resi apertamente commentabili.

5. Il Consiglio direttivo ha la facoltà di creare nuove Circoscrizioni, come descritto nella Sezione 5(3) sia in risposta a 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 di GNSO e il gruppo delle parti interessate in questione ed esaminare le eventuali risposte prima di intraprendere qualsiasi azione.

Sezione 6. PROCESSO DI SVILUPPO DELLE POLICY

Il processo di sviluppo delle policy alle quali la GNSO deve attenersi saranno quelle indicate 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. 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.

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

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

4. Riferire periodicamente al Consiglio direttivo sulle proprie attività.

5. Suggerire Policy alla community e al Consiglio direttivo di ICANN.

b. Il Presidente e i membri del SAC sono nominati dal Consiglio direttivo. La nomina dei membri SSAC prevederà un mandato della durata di tre anni, a partire dall'1 gennaio fino al 31 dicembre del secondo anno successivo. Il Presidente e i membri possono essere rinominati, senza alcun limite sul numero dei mandati. Il Presidente del SSAC può fornire al Consiglio suggerimenti in merito alle nomine all'interno del SSAC stesso. Il Presidente del SSAC fornirà suggerimenti relativi alle nomine in modo che circa un terzo (1/3) dei membri del SSAC venga considerato per la nomina o per un rinnovo della nomina su base annuale. Il Consiglio avrà inoltre il potere di rimuovere un rappresentante del SSAC dietro suggerimento o consultazione con il SSAC stesso. Nota: la durata complessiva del primo mandato, come descritto in questo paragrafo, sarà dall'1 gennaio 2011 al 31 dicembre 2013. Prima dell'1 gennaio 2011, verrà introdotto il SSAC, come definito nell'emendamento del 25 giugno 2010 dello Statuto, e il Presidente del SSAC suggerirà la rinomina completa o parziale di tutti i relativi membri in carica, come opportuno per applicare quanto definito nel presente paragrafo.

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 <ftp://ftp.internic.net/domain/named.root>) 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. ALAC (At-Large Advisory Committee)

a. Il Comitato ALAC (At-Large Advisory Committee) costituisce la principale sede organizzativa di ICANN per singoli utenti di Internet. Il ruolo dell'ALAC è di valutare e fornire il proprio parere sulle attività di ICANN laddove queste riguardino gli interessi dei singoli utenti di Internet. Esse comprendono anche le policy create attraverso le organizzazioni di sostegno di ICANN e le altre problematiche che richiedono il contributo e i consigli della community. L'ALAC, che gioca un ruolo fondamentale nel meccanismo di responsabilità di ICANN, coordina anche alcune azioni di sostegno di ICANN su 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 Sezione e (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. Dietro consultazione con ogni RALO, l'ALAC nominerà annualmente cinque delegati con diritto di voto (ognuno proveniente da paesi di Regioni geografiche diverse, come indicato nella Sezione 5 dell'Articolo VI ) per il Comitato per l'assegnazione delle nomine.

f. Fatto salvo quanto disposto dall' Articolo di Transizione del presente Statuto, l'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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. La decisione di concedere, non concedere o revocare la certificazione come struttura At-Large è soggetta a revisione conformemente alle procedure stabilite dal Consiglio direttivo.
  8. 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. Effettuare una selezione mediante l'At-Large Community per occupare la Posizione 15 all'interno del Consiglio. Il Presidente dell'ALAC ha il dovere di informare per iscritto il Segretario di ICANN della selezione effettuata dall'At-Large Community, in conformità con le disposizioni dell'Articolo VI, Sezioni 8(4) e12(1).

2. Divulgazione delle notizie più importanti di ICANN alla community dei singoli utenti Internet;

3. 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;

4. Promozione di attività ad ampio raggio nella community dei singoli utenti Internet;

5. Sviluppo e mantenimento di programmi di informazione e istruzione su ICANN e relative attività;

6. Creazione di una strategia di sostegno in ciascuna regione di un RALO su questioni relative a ICANN;

7. Partecipazione ai processi di sviluppo delle policy di ICANN e contributo e consigli che riflettano accuratamente i punti di vista dei singoli utenti di Internet.

8. 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;

9. Offerta di meccanismi basati su Internet che consentono dibattiti tra i membri di strutture At-Large; e

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

Sezione 3. PROCEDURE

Ciascun Comitato consultivo determinerà le proprie regole procedurali e per il quorum.

Sezione 4. MANDATO

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.

Sezione 5. POSIZIONI VACANTI

Le posizioni vacanti di qualsiasi Comitato verranno occupate seguendo la stessa procedura prevista per le nomine originali.

Sezione 6. REMUNERAZIONE

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. Obiettivo. 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. Obiettivo. 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 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 di un Comitato possono essere rimossi tramite un voto di maggioranza pari ai due terzi (2/3) di tutti i membri del Consiglio. Il direttore o i direttori oggetto dell'azione di rimozione saranno esclusi dalla votazione e non saranno conteggiati come membri del Consiglio nel calcolo dei due terzi (2/3) richiesti. In nessun caso, inoltre, un direttore sarà rimosso da un comitato, a meno che tale rimozione non sia stata approvata da almeno un voto di 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.

ARTICOLO XIII: FUNZIONARI

Sezione 1. FUNZIONARI

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.

Sezione 4. PRESIDENTE

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.

Sezione 5. SEGRETARIO

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.

Sezione 8. COMPENSO E SPESE

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. CONFLITTO D'INTERESSI

Il Consiglio, attraverso il Board Governance Committee, stabilirà una politica secondo la quale a ciascun Funzionario sarà richiesta una dichiarazione da presentarsi non meno frequentemente di una volta l'anno indicante tutte le attività e altre affiliazioni in qualunque modo correlate all'attività e ad 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

Sezione 1. CONTRATTI

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.

Sezione 2. DEPOSITI

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.

Sezione 3. ASSEGNI

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.

Sezione 4. PRESTITI

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.

ARTICOLO XVI: ASPETTI FISCALI

Sezione 1. CONTABILITÀ

La fine dell'esercizio finanziario di ICANN sarà determinata dal Consiglio.

Sezione 2. CONTROLLO

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.

Sezione 4. BILANCIO ANNUALE

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.

Sezione 5. TARIFFE APPLICATE

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.

ARTICOLO XVII: MEMBRI

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

Sezione 1. SEDI

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.

Sezione 2. MARCHIO

Il Consiglio può adottare un marchio aziendale e utilizzarlo in forma originale o in copia per impressione, affissione, riproduzione o in qualsiasi altro modo.

ARTICOLO XIX: EMENDAMENTI

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

Sezione 1. OBIETTIVO

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 "). [Nota esplicativa (10 dicembre 2009): per la sezione 5(3) di questo Articolo, il riferimento allo "statuto precedente" indica lo statuto come emendato e riformulato fino al 20 marzo 2009.]

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) ed (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. La GNSO (Generic Names Supporting Organization), dopo l'entrata in vigore di questo Articolo di transizione, continuerà a operare come di consueto, ma verrà organizzata in quattro nuovi gruppi delle parti interessate che rappresenteranno, in termini organizzativi, le precedenti Circoscrizioni della GNSO, con l'approvazione da parte del Consiglio di ICANN di ogni singolo statuto del gruppo delle parti interessate:

a. La Circoscrizione dei registri gTLD sarà assegnata al Gruppo delle parti interessate ai Registri;

b. La Circoscrizione dei registrar sarà assegnata al Gruppo delle parti interessate ai Registrar;

c. La Circoscrizione commerciale sarà assegnata al Gruppo delle parti interessate commerciale;

d. La Circoscrizione delle proprietà intellettuali sarà assegnata al Gruppo delle parti interessate commerciale;

e. La Circoscrizione degli Internet Service Provider sarà assegnata al Gruppo delle parti interessate commerciale e

f. La Circoscrizione degli utenti non commerciali sarà assegnata al Gruppo delle parti interessate non commerciale.

2. Sostanzialmente, ogni Circoscrizione GNSO descritta nel paragrafo 1 di tale sottosezione continuerà a operare normalmente e i funzionari, i gruppi di lavoro o le altre attività non subiranno modifiche fino a nuova pronuncia della circoscrizione, fermo restante che le Circoscrizioni GNSO descritte nel paragrafo 1 (c-f) presenteranno al Segretario di ICANN uno Statuto rielaborato e rivisto comprensivo di tutte le procedure operative, attinenti alle procedure della circoscrizione e coerenti con il nuovo Statuto di ICANN, non oltre la data di riunione di ICANN di ottobre 2009 o un'altra data indicata in alternativa dal Consiglio.

3. Prima dell'inizio della riunione di ICANN nell'ottobre 2009, o un'altra data indicata in alternativa dal Consiglio, il Consiglio di GNSO manterrà la Circoscrizione e i funzionari in quel momento in carica, secondo quanto descritto nell' Articolo X, Sezione 3(1) dello Statuto (rivisto e riformulato il 29 ottobre 1999 e completato il 20 marzo 2009 (“statuto precedente”)). La composizione del Consiglio di GNSO dipenderà quindi da quanto previsto da questo Statuto e dagli eventuali emendamenti successivi. 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 GNSO e operanti al momento dell'entrata in vigore di questo Articolo di transizione resteranno attivi con gli stessi statuti, membri e attività e saranno soggetti alle modifiche eventualmente disposte dal Consiglio di GNSO o di ICANN.

4. A partire dall'inizio della riunione di ICANN di ottobre 2009, o un'altra data indicata in alternativa dal Consiglio (“Data effettiva della transizione”), l'assegnazione delle posizioni all'interno del Consiglio di GNSO avverrà nel modo seguente:

a. Le tre posizioni al momento assegnate alla Circoscrizione dei Registri saranno riassegnate sotto forma di tre posizioni del Gruppo delle parti interessate ai Registri.

b. Le tre posizioni al momento assegnate alla Circoscrizione dei Registrar saranno riassegnate sotto forma di tre posizioni del Gruppo delle parti interessate ai Registrar.

c. Le tre posizioni al momento assegnate a ciascuna Circoscrizione commerciale, delle proprietà intellettuali e degli Internet Service Provider (per un totale di nove) saranno ridotte a sei posizioni del Gruppo delle parti interessate commerciale.

d. Le tre posizioni al momento assegnate alla Circoscrizione degli utenti non commerciali ammonteranno a sei posizioni del Gruppo delle parti interessate non commerciale.

e. Le tre posizioni al momento selezionate dal Comitato per l'assegnazione delle nomine saranno assegnate dal Comitato secondo la seguente modalità: un membro votante per la Camera delle parti acquisite, uno per la Camera delle parti non acquisite e un membro non votante assegnato al Consiglio di GNSO At-Large.

I rappresentanti del Consiglio di GNSO saranno nominati o eletti secondo quanto disposto negli statuti del gruppo delle parti interessati applicabile, approvato dal Consiglio e con largo anticipo rispetto alla riunione di ICANN di ottobre 2009. Ciò permetterà ai rappresentanti di agire in veste ufficiale all'inizio della riunione citata.

5. In quanto parte del Piano di ristrutturazione, il Consiglio di GNSO fornirà le seguenti informazioni: (a) la modalità di gestione durante il periodo di transizione dell'eventuale numero presente di posti vacanti; (b) il modo in cui ogni gruppo delle parti interessate occuperà le posizioni assegnate all'interno del Consiglio che diverranno effettive nel corso della riunione annuale di ICANN del 2009, mediante quindi un mandato continuativo o una nuova elezione o nomina; (c) il piano di risoluzione per i mandati scaglionati in modo che il nuovo Consiglio GNSO mantenga la massima continuità possibile; e (d) le conseguenze del limite dei mandati definito nello Statuto su ciascun membro del Consiglio.

6. Non appena possibile, a seguito dell'inizio della riunione di ICANN di ottobre 2009, o un'altra data indicata in alternativa dal Consiglio, il Consiglio di GNSO, in conformità con l' Articolo X, Sezione 3(7) e le Procedure operative di GNSO, eleggerà i funzionari e comunicherà per iscritto la selezione al Segretario di ICANN.

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, il 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, il 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 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 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.

Sezione 8. FUNZIONARI

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. [Nota: questa appendice include gli emendamenti necessari per una base ad interim per consentire alla GNSO di operare mentre sono in corso le discussioni della community e del Consiglio sulle procedure operative e per lo sviluppo delle politiche riviste].

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 tramite un voto di almeno il venticinque percento (25%) dei membri del Consiglio di ciascuna Camera o la maggioranza di una sola Camera.

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;

4. apre la strada a evoluzioni future o

5. compromette o inficia una politica esistente di ICANN.

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.

3. Avvio del PDP

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 un PDP che rientri nell'ambito delle attività di ICANN sarà sufficiente che voti a favore più del 33% dei membri del Consiglio di ciascuna Camera o più del 66% di una Camera, a meno che il parere dello staff non indichi che il problema 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 di GNSO, come definito nell' Articolo X, Sezione 3, paragrafo 9(c).

4. Avvio del PDP

Durante la riunione che delibera l'avvio del PDP, il Consiglio di GNSO decide a maggioranza dei membri di ciascuna Camera 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 inviterà tutte le circoscrizioni e/o i Gruppi delle parti interessate di 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 o gruppo delle parti interessate a propria discrezione nei casi in cui lo ritenga opportuno.

b. Ogni circoscrizione o gruppo delle parti interessate 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).

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 gruppi delle parti interessate e delle circoscrizioni 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 al Consiglio in via formale e approvate con il voto favorevole della maggioranza di ciascuna camera 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.

d. Raccolta di informazioni.

1. Dichiarazioni della Circoscrizione e del gruppo delle parti interessate. Gli incaricati dei gruppi delle parti interessate dovranno almeno rappresentare le posizioni dei rispettivi gruppi delle parti interessate o 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/gruppo delle parti interessate" entro trentacinque (35) giorni di calendario dall'avvio del PDP. Le dichiarazioni della circoscrizione o dei gruppi delle parti interessate dovranno includere almeno i seguenti punti:

(i) Se è stato raggiunto un voto di maggioranza qualificata, una descrizione chiara della posizione della circoscrizione o del gruppo delle parti interessate sul problema;

(ii) Se è stato raggiunto un voto di maggioranza qualificata, una descrizione chiara di tutte le posizioni assunte dai membri della circoscrizione o del gruppo delle parti interessate;

(iii) Una descrizione chiara del modo in cui la circoscrizione o il gruppo delle parti interessate 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 o il gruppo delle parti interessate è 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 o sul gruppo delle parti interessate, 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 o del gruppo delle parti interessate, 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 non è stato raggiunto un voto di 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 della circoscrizione o del gruppo delle parti interessate. Ogni descrizione deve indicare chiaramente (i) le ragioni che inducono ad assumere la posizione e (ii) le circoscrizioni o i gruppi delle parti interessate che condividono tale posizione;

3. (iv) Un'analisi dell'effetto che il problema ha sulla circoscrizione o sul gruppo delle parti interessate 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 o gruppo delle parti interessate nomini un incaricato che riferisca sul punto di vista della circoscrizione o del gruppo delle parti interessate 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 o i gruppi delle parti interessate 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.

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

b. Se non è stato espresso un voto favorevole, 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 ogni posizione e (ii) le circoscrizioni o i gruppi delle parti interessate che condividono tale posizione.

c. Un'analisi dell'effetto che il problema ha su ogni circoscrizione o gruppo delle parti interessate, 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

A. Un voto favorevole dei membri del Consiglio di GNSO verrà considerato come espressione del Consiglio stesso e potrà essere trasmesso al Consiglio di ICANN come suggerimento del Consiglio di GNSO. Qualora non venga raggiunto un voto di maggioranza qualificata, per ottenere l'approvazione dei suggerimenti contenuti nella relazione finale è necessario raggiungere la maggioranza di entrambe le Camere oltre al sostegno da parte di un rappresentante di almeno 3 gruppi delle parti interessate. 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 GNSO, 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 da 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 raggiunge un voto di maggioranza qualificata, il Consiglio di ICANN potrà procedere con un voto di 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.

15. Conservazione degli atti

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

f. Tutti i commenti pubblici ricevuti.

16. Definizioni ulteriori

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

"Voto di maggioranza qualificata" si riferisce al voto di più del sessantasei percento (66%) dei membri presenti a una riunione del collegio, a eccezione del Consiglio di GNSO.

"Staff Manager" si riferisce a un individuo del personale di ICANN che gestisce il PDP.

Il concetto di “Voto di maggioranza qualificata di GNSO” sarà quello definito nello Statuto.

Un “Voto di GNSO favorevole” è un voto favorevole espresso dal Consiglio di GNSO in conformità con la relativa soglia dei voti, come indicato nell' Articolo X, Sezione 3(9) , incluso, senza limitazioni, un voto di maggioranza qualificata del Consiglio di GNSO.


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 avviare il processo di sviluppo delle policy.

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 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 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 GNSO 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 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 ccNSO 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 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 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 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 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 (a) delle qualifiche ed esperienze rilevanti e (b) dei possibili conflitti di interesse dei consulenti.

11. Suggerimento del Consiglio di GNSO

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 GNSO 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 locali

Livello 3: name server dell'utente
Ruolo politico: gestore ccTLD, IETF (RFC)
Ruolo esecutivo: Registrant
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à nazionali

Livello 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à nazionali

Livello 3: secondo livello e livelli inferiori
Ruolo politico: Registrant
Ruolo esecutivo: Registrant
Ruolo di responsabilità: proprietario, utenti di nomi di dominio di livelli inferiori

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."