STATUTEN DER INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS | Ab 24. Juni 2011 gültige Fassung | Gemeinnützige Gesellschaft mit Sitz in Kalifornien
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
Ab 24. Juni 2011 gültige Fassung
Dieses Dokument wurde zu Informationszwecken in mehrere Sprachen übersetzt. Den ursprünglichen und verbindlichen Text (auf Englisch) finden Sie unter http://www.icann.org/en/general/bylaws.htm
INHALT
ARTIKEL I: ZWECK UND KERNWERTE
ARTIKEL II: BEFUGNISSE
ARTIKEL III: TRANSPARENZ
ARTIKEL IV: VERANTWORTLICHKEIT UND PRÜFUNG
ARTIKEL V: OMBUDSMANN
ARTIKEL VI: BOARD OF DIRECTORS
ARTIKEL VII: NOMINATING COMMITTEE
ARTIKEL VIII: ADDRESS SUPPORTING ORGANIZATION
ARTIKEL IX: COUNTRY-CODE NAMES SUPPORTING ORGANIZATION
ARTIKEL X: GENERIC NAMES SUPPORTING ORGANIZATION
ARTIKEL XI: ADVISORY COMMITTEES
ARTIKEL XI-A: SONSTIGE BERATUNGSMECHANISMEN
ARTIKEL XII: BOARD AND TEMPORARY COMMITTEES
ARTIKEL XIII: OFFICER
ARTIKEL XIV: HAFTUNGSFREISTELLUNG FÜR DIREKTOREN, OFFICER, MITARBEITER UND SONSTIGE VERTRETER
ARTIKEL XV: ALLGEMEINE BESTIMMUNGEN
ARTIKEL XVI: FINANZANGELEGENHEITEN
ARTIKEL XVII: MITGLIEDER
ARTIKEL XVIII: STANDORTE UND SIEGEL
ARTIKEL XIX: ÄNDERUNGEN
ARTIKEL XX: ÜBERGANGSARTIKEL
ANHANG A: GNSO-RICHTLINIENENTWICKLUNGSPROZESS
ANHANG B: ccNSO-RICHTLINIENENTWICKLUNGSPROZESS (ccPDP)
ANHANG B: AUFGABENBEREICH DER ccNSO
ARTIKEL I: ZWECK UND KERNWERTE
Zweck der Internet Corporation for Assigned Names and Numbers ("ICANN") ist die "Gesamtkoordinierung der Unique Identifier-Systeme für das globale Internet und vor allem auch Sicherstellung des stabilen und sicheren Betriebs dieser Systeme." Insbesondere übernimmt ICANN folgende Aufgaben:
1. Koordination der Zuweisung und Zuteilung der drei Gruppen von eindeutigen Identifikatoren für das Internet:
a. Domainnamen (diese bilden ein als "DNS" bezeichnetes System)
b. Internetprotokolladressen ("IP-Adressen") und Nummern für autonome Systeme ("ASN") sowie
2. Koordination des Betriebs und der Entwicklung des DNS-Rootnameserver-Systems
3. Koordination der Richtlinienentwicklung mit angemessenem Bezug zu den technischen Funktionen
Den Entscheidungen und Handlungen von ICANN im Hinblick auf die Erfüllung des Zwecks der Organisation liegen folgende Kernwerte zugrunde:
1. Wahrung und Verbesserung der operationalen Stabilität, Zuverlässigkeit, Sicherheit und weltweiten Interoperabilität des Internets
2. Anerkennung der Kreativität, der Innovation und des Informationsflusses mithilfe des Internets durch Beschränkung der ICANN-Aktivitäten auf Angelegenheiten, die im Zusammenhang mit dem Zweck von ICANN stehen und die eine globale Koordination erfordern oder von einer solchen wesentlich profitieren
3. Delegieren von Koordinationsfunktionen in angemessenem oder machbarem Umfang an andere verantwortliche Organisationen, die die Interessen der betroffenen Parteien vertreten, oder Anerkennung der Bedeutung solcher Organisationen
4. Anstreben und Unterstützung einer breiten, informierten Beteiligung, die die funktionale, geografische und kulturelle Vielfalt des Internets widerspiegelt, auf allen Ebenen der Richtlinienentwicklung und Entscheidungsfindung
5. In angemessenem und machbarem Rahmen Ausrichtung auf Marktmechanismen zur Förderung und Wahrung einer wettbewerbsfähigen Umgebung
6. Schaffung und Förderung des Wettbewerbs bei der Registrierung von Domainnamen, sofern praktikabel und im Interesse der Allgemeinheit
7. Anwendung offener und transparenter Richtlinienentwicklungsmechanismen, die (i) gut informierte Entscheidungen auf der Grundlage von sachverständiger Beratung fördern und (ii) sicherstellen, dass die am stärksten betroffenen Organisationen am Prozess der Richtlinienentwicklung teilnehmen können
8. Treffen von Entscheidungen durch neutrale und objektive Anwendung dokumentierter Richtlinien auf der Basis von Integrität und Fairness
9. Handeln in einem internetgerechten Tempo und gleichzeitig – als Teil des Entscheidungsprozesses – Sammeln von Informationsbeiträgen der betroffenen Organisationen
10. Verantwortungsbewusstes Handeln im Interesse der Internet-Community durch Mechanismen, mit denen sich die Effektivität von ICANN steigern lässt
11. Unveränderte Ausrichtung auf den Privatsektor und Anerkennung, dass Regierungen und Behörden für öffentliche Belange verantwortlich sind, dabei angemessene Berücksichtigung der Empfehlungen von Regierungen oder Behörden
Diese Kernwerte sind bewusst sehr allgemein formuliert, sodass sie unter allen möglichen Umständen eine sinn- und wertvolle Orientierungshilfe bieten. Da die Kernwerte sich nicht auf konkrete Einzelfälle beziehen, hängt deren allgemeine und individuelle Umsetzung in einer unbekannten Situation unweigerlich von vielen Faktoren ab, die sich nicht vorausahnen oder beziffern lassen, und da es sich bei den Kernwerten eher um Grundsatzerklärungen als um Anwendungsregeln handelt, treten zwangsläufig Situationen auf, in denen die gleichzeitige Einhaltung aller elf Kernwerte nicht möglich ist. Jedes ICANN-Organ, das eine Empfehlung ausspricht oder eine Entscheidung trifft, sollte sein gesundes Urteilsvermögen walten lassen, um zu bestimmen, welche Kernwerte ausschlaggebend sind und wie sie sich unter den gegebenen Umständen verwirklichen lassen, und um gegebenenfalls zwischen konkurrierenden Werten sorgfältig abzuwägen.
ARTIKEL II: BEFUGNISSE
Abschnitt 1. ALLGEMEINE BEFUGNISSE
Sofern die Gesellschaftssatzung oder diese Stauten nichts anderes vorsehen, obliegt die Wahrnehmung der Befugnisse, die Kontrolle des Eigentums und die Führung der Geschäfte von ICANN dem Board. Unter Berücksichtigung aller Angelegenheiten, die möglicherweise unter Artikel III, Abschnitt 6 fallen, handelt das Board nur nach Mehrheitsvotum aller Board-Mitglieder. In allen anderen Angelegenheiten, sofern nicht durch diese Statuten oder gesetzlich anders vorgeschrieben, handelt das Board nach Mehrheitsvotum der bei jährlichen, regelmäßigen oder außerordentlichen Veranstaltungen des Boards anwesenden Mitglieder. Sofern nicht in den vorliegenden Statuten durch die Formulierung "aller Board-Mitglieder" anderweitig geregelt, beziehen sich die Begriffe "Abstimmung" bzw. "Votum" in diesen Statuten auf eine Abstimmung der bei einer Veranstaltung anwesenden Mitglieder, vorausgesetzt, es handelt sich dabei um eine beschlussfähige Anzahl an Mitgliedern.
ICANN tritt nicht als Registry oder Registrar eines Domainnamensystems oder als Registry von Internetprotokolladressen in Konkurrenz zu Organisationen auf, für die die ICANN-Richtlinien gelten. ICANN wird durch den Inhalt dieses Abschnitts in keiner Weise daran gehindert, notwendige Schritte zu ergreifen, um die operationale Stabilität des Internets im Fall des finanziellen Zusammenbruchs einer Registry oder eines Registrars oder in einem anderen Notfall zu sichern.
Abschnitt 3. KEINE UNGLEICHBEHANDLUNG
ICANN wendet seine Standards, Richtlinien, Verfahren oder Praktiken so an, dass keine bestimmte Partei ungerecht oder gesondert behandelt wird, sofern kein wesentlicher und vernünftiger Grund dafür vorliegt, beispielsweise die Förderung eines effektiven Wettbewerbs.
ARTIKEL III: TRANSPARENZ
ICANN und seine konstituierenden Organe arbeiten im weitestmöglichen Umfang offen und transparent sowie in Einklang mit den ausgestalteten Verfahren, um die Fairness sicherzustellen.
ICANN unterhält eine öffentlich zugängliche World Wide Web-Site im Internet (die "Website"), die unter anderem folgende Inhalte umfassen kann: (i) einen Kalender mit terminierten Veranstaltungen des Boards, der Supporting Organizations und der Advisory Committees; (ii) eine Übersicht über alle noch ausstehenden Angelegenheiten in Bezug auf die Richtlinienentwicklung, einschließlich Zeitplan und Status; (iii) Hinweise auf Veranstaltungen einschließlich Tagesordnung; (iv) auf ICANN bezogene Informationen über Budget, Jahresabschlussprüfung, Geldgeber einschließlich der Höhe ihrer Beiträge sowie damit zusammenhängende Angelegenheiten; (v) Informationen zur Verfügbarkeit von Mechanismen zur Erfüllung der Rechenschaftspflicht, einschließlich Entscheidungsüberprüfung, unabhängige Prüfung und Aktivitäten des Ombudsmanns sowie Informationen zu den Auswirkungen bestimmter Anfragen und Beschwerden, bei denen sich auf diese Mechanismen berufen wird; (vi) Ankündigung von ICANN-Aktivitäten, die für wichtige Bereiche der ICANN-Community von Interesse sind; (vii) Anmerkungen seitens der Community zu Richtlinien in der Entwicklungsphase und anderen Angelegenheiten; (viii) Informationen zu Präsenzveranstaltungen und öffentlichen Foren von ICANN; und (ix) sonstige Informationen, die für die ICANN-Community von Interesse sind.
Abschnitt 3. MANAGER OF PUBLIC PARTICIPATION
Es wird eine Funktion mit dem Titel "Manager of Public Participation" oder einem anderen vom Präsidenten festgelegten Titel geschaffen, die unter der Leitung des Präsidenten für die Koordination der verschiedenen Aspekte einer öffentlichen Beteiligung an ICANN, einschließlich der Website und anderer Mittel zur Kommunikation oder zur Erfassung von Beiträgen der Allgemeinheit der Internetbenutzer, verantwortlich ist.
Abschnitt 4. HINWEISE AUF VERANSTALTUNGEN EINSCHLIESSLICH TAGESORDNUNG
Spätestens sieben Tage vor jeder Board-Veranstaltung (zum frühestmöglichen Zeitpunkt) wird ein Hinweis auf die betreffende Veranstaltung und, soweit bekannt, die Tagesordnung der Veranstaltung veröffentlicht.
Abschnitt 5. PROTOKOLLE UND VORLÄUFIGE BERICHTE
1. Sämtliche Protokolle der Veranstaltungen des Boards und der Supporting Organizations (sowie deren Councils) werden umgehend vom urhebenden Organ genehmigt und dem Sekretär von ICANN zur Veröffentlichung auf der Website bereitgestellt.
2 . Spätestens um 23:59 Uhr am zweiten Geschäftstag nach dem Abschluss einer jeden Sitzung (maßgebend ist die Ortszeit am Hauptsitz von ICANN) werden alle vom Board of Directors während der Sitzung verabschiedeten Entscheidungen auf der Website veröffentlicht; jedoch mit der Einschränkung, dass alle Maßnahmen, die sich auf Personal- und Beschäftigungsangelegenheiten, rechtliche Angelegenheiten (soweit nach Auffassung des Boards erforderlich oder angemessen, um die Interessen von ICANN zu schützen), Angelegenheiten, die laut Gesetz oder Vertrag nicht von ICANN öffentlich gemacht werden dürfen, und sonstige Angelegenheiten, die nach Dreiviertelmehrheit (3/4) der bei der Veranstaltung anwesenden und abstimmenden Direktoren im Board nicht für die Veröffentlichung geeignet sind, beziehen, nicht im Rahmen des vorläufigen Berichts veröffentlicht werden dürfen. Der Sekretär informiert das Board of Directors und die Vorsitzenden der Supporting Organizations (gemäß Artikel VIII - X dieser Statuten) und der Advisory Committees (gemäß Artikel XI dieser Statuten), dass die Entscheidungen veröffentlicht wurden.
3. Spätestens um 23:59 Uhr am siebten Geschäftstag nach dem Abschluss einer jeden Sitzung (maßgebend ist die Ortszeit am Hauptsitz von ICANN) werden alle vom Board ergriffenen Maßnahmen auf der Website in einem vorläufigen Bericht veröffentlicht, mit Ausnahme der in Abschnitt 5.2 oben dargelegten Einschränkungen für die Offenlegung. Zu jeder Angelegenheit, die nach Entscheidung des Boards nicht öffentlich gemacht wird, gibt das Board im entsprechenden vorläufigen Bericht in allgemeiner Form den Grund für die Nichtveröffentlichung an.
4. Spätestens einen Tag nach der offiziellen Genehmigung durch das Board (oder, wenn es sich dabei nicht um einen Geschäftstag handelt, am unmittelbar darauffolgenden Geschäftstag, maßgebend ist die Ortszeit am Hauptsitz von ICANN) werden die Protokolle auf der Website veröffentlicht; jedoch mit der Einschränkung, dass alle Protokolle, die sich auf Personal- und Beschäftigungsangelegenheiten, rechtliche Angelegenheiten (soweit nach Auffassung des Boards erforderlich oder angemessen, um die Interessen von ICANN zu schützen), Angelegenheiten, die laut Gesetz oder Vertrag nicht von ICANN öffentlich gemacht werden dürfen, und sonstige Angelegenheiten, die nach Dreiviertelmehrheit (3/4) der bei der Veranstaltung anwesenden und abstimmenden Direktoren im Board nicht für die Veröffentlichung geeignet sind, beziehen, nicht im Rahmen der Protokolle veröffentlicht werden dürfen. Zu jeder Angelegenheit, die nach Entscheidung des Boards nicht öffentlich gemacht wird, gibt das Board im entsprechenden Protokoll in allgemeiner Form den Grund für die Nichtveröffentlichung an.
Abschnitt 6. MITTEILUNG UND ANMERKUNG ZU RICHTLINIENMASSNAHMEN
1. Im Hinblick auf sämtliche Richtlinien, die das Board als umsetzbar erachtet und die den Betrieb des Internets oder Dritte betreffen, einschließlich der Erhebung von Gebühren oder Abgaben, wird ICANN:
a. spätestens einundzwanzig Tage (falls möglich früher) vor Ergreifung einer Maßnahme durch das Board eine öffentliche Mitteilung auf der Website veröffentlichen, in der erklärt wird, welche Richtlinien umgesetzt werden sollen und warum;
b. vor Ergreifung einer Maßnahme durch das Board anderen Parteien eine angemessene Gelegenheit bieten, zur Umsetzung der vorgeschlagenen Richtlinien Stellung zu beziehen, die Anmerkungen anderer zu lesen und diese zu kommentieren; und
c. in den Fällen, in denen die Richtlinienmaßnahme öffentliche Belange berührt, die Gelegenheit bieten, eine Stellungnahme vom Governmental Advisory Committee anzufordern und jeden vom Governmental Advisory Committee in Eigeninitiative oder auf Bitte des Boards rechtzeitig unterbreiteten Vorschlag angemessen zu berücksichtigen.
2. Sofern praktisch umsetzbar und mit dem betreffenden Richtlinienentwicklungsprozess vereinbar, wird vor einer endgültigen Maßnahme des Boards ein persönliches und öffentliches Diskussionsforum eingerichtet, in dem die in Abschnitt 6(1)(b) dieses Artikels beschriebenen Richtlinienvorschläge besprochen werden.
3. Nach der Ergreifung einer Maßnahme in Bezug auf die in diesem Abschnitt beschriebenen Richtlinien gibt das Board im Rahmen des Protokolls die Gründe für eine solche Maßnahme, das Votum jedes abstimmenden Direktors sowie eine gesonderte Stellungnahme jedes Direktors, der die Veröffentlichung einer solchen Stellungnahme wünscht, bekannt.
Abschnitt 7. ÜBERSETZUNG VON DOKUMENTEN
In angemessener Weise und im gemäß ICANN-Budget vorgesehenen Umfang ermöglicht ICANN die Übersetzung von in endgültiger Form veröffentlichten Dokumenten in die dafür vorgesehenen Sprachen.
ARTIKEL IV: VERANTWORTLICHKEIT UND PRÜFUNG
Gemäß seinem in den vorliegenden Statuten beschriebenen Zweck ist ICANN gegenüber der Community zu einer Arbeitsweise verpflichtet, die mit diesen Statuten übereinstimmt und die die in Artikel I dieser Statuten beschriebenen Kernwerte angemessen berücksichtigt. Die Bestimmungen dieses Artikels, wonach Prozesse zur Entscheidungsüberprüfung und unabhängigen Prüfung von ICANN-Maßnahmen sowie zur regelmäßigen Überprüfung der Struktur und Verfahrensweisen von ICANN entwickelt werden, dienen zur Unterstützung der an anderer Stelle in diesen Statuten beschriebenen Mechanismen zur Erfüllung der Rechenschaftspflicht, einschließlich der Transparenzvorschrift gemäß Artikel III und einschließlich der Mechanismen zur Auswahl des Boards sowie anderer Auswahlmechanismen, die in diesen Stauten dargelegt sind.
Abschnitt 2. ENTSCHEIDUNGSÜBERPRÜFUNG
1. ICANN muss ein Verfahren einrichten, wonach jede natürliche oder Rechtsperson, die von einer ICANN-Maßnahme wesentlich betroffen ist, eine Überprüfung oder Entscheidungsüberprüfung dieser Maßnahme durch das Board beantragen kann.
2. Jede natürliche oder Rechtsperson kann die Überprüfung oder Entscheidungsüberprüfung einer von ICANN ergriffenen oder versäumten Maßnahme beantragen („Antrag auf Entscheidungsüberprüfung“), sofern sich eine der folgenden Handlungen oder Versäumnisse nachteilig auf die natürliche oder Rechtsperson ausgewirkt hat:
a. Maßnahmen oder Versäumnisse seitens eines Mitarbeiters oder mehrerer Mitarbeiter, die im Widerspruch zu den von ICANN aufgestellten Richtlinien stehen; oder
b. eine oder mehrere Maßnahmen oder Versäumnisse des ICANN-Boards, die ohne Berücksichtigung wesentlicher Informationen ergriffen oder verweigert wurden, außer in Fällen, in denen die beantragende Partei die vom Board zu berücksichtigenden Informationen zum Zeitpunkt der Maßnahme oder des Versäumnisses hätte vorlegen können, dies aber nicht getan hat.
3. Das Board hat das Board Governance Committee zur Überprüfung und Berücksichtigung solcher Anträge auf Entscheidungsüberprüfung ernannt. Das Board Governance Committee ist berechtigt:
a. den Antrag auf Überprüfung oder Entscheidungsüberprüfung zu bewerten;
b. zu bestimmen, ob eine angefochtene Maßnahme ausgesetzt werden soll, bis eine Lösung gefunden ist;
c. als angemessen erachtete Untersuchungen durchzuführen;
d. zusätzliche schriftliche Beiträge von der betroffenen Partei oder von anderen Parteien anzufordern; und
e. gegenüber dem Board of Directors eine Empfehlung auf Grundlage des Antrages auszusprechen.
4. ICANN trägt die üblichen Verwaltungskosten, die im Zusammenhang mit dem Prozess der Entscheidungsüberprüfung entstehen. ICANN behält sich das Recht vor, außerordentliche Kosten von einer Partei, die eine Überprüfung oder Entscheidungsüberprüfung beantragt, zurückzufordern. Lassen sich außerordentliche Kosten absehen, sollten die Umstände und Gründe, warum solche Kosten erforderlich und angemessen sind, um den Antrag auf Entscheidungsüberprüfung zu bewerten, der beantragenden Partei mitgeteilt werden, die daraufhin ihren Antrag zurücknehmen oder sich damit einverstanden erklären kann, die dadurch entstehenden außerordentlichen Kosten zu tragen.
5. Alle Anträge auf Entscheidungsüberprüfung müssen an eine vom Board Governance Committee vorgegebene E-Mail-Adresse gesendet werden, und zwar:
a. bei Anträgen, mit denen eine Maßnahme des Boards angefochten wird, binnen dreißig Tagen nach dem Datum, an dem Informationen über die betreffende Maßnahme des Boards erstmals in einem vorläufigen Bericht oder in einem Protokoll zu den Versammlungen des Boards veröffentlicht werden; oder
b. bei Anträgen, mit denen die Maßnahme eines Mitarbeiters angefochten wird, binnen dreißig Tagen nach dem Datum, an dem die Partei, welche den Antrag vorlegt, von der betreffenden Maßnahme des Mitarbeiters erfährt oder nach vernünftiger Einschätzung hätte erfahren müssen; oder
c. bei Anträgen, mit denen Versäumnisse des Boards oder eines Mitarbeiters angefochten werden, binnen dreißig Tagen nach dem Datum, an dem die betroffene Person gefolgert hat oder nach vernünftiger Einschätzung hätte folgern müssen, dass die Maßnahme nicht rechtzeitig ergriffen wird.
6. Alle Anträge auf Entscheidungsüberprüfung müssen die vom Board Governance Committee benötigten Informationen enthalten, u. a.:
a. Name, Adresse und Kontaktinformationen der beantragenden Partei, einschließlich Anschrift und E-Mail-Adresse;
b. die konkrete Maßnahme oder das Versäumnis von ICANN, für die/das eine Überprüfung oder Entscheidungsüberprüfung beantragt wird;
c. das Datum der Maßnahme oder des Versäumnisses;
d. die Art und Weise, wie sich die Maßnahme oder das Versäumnis auf die beantragende Partei auswirkt;
e. das Ausmaß, in dem sich die angefochtene Maßnahme oder das Versäumnis nach Auffassung der beantragenden Partei auf andere auswirkt;
f. die Angabe, ob eine vorläufige Aussetzung der angefochtenen Maßnahme beantragt wird, und falls ja, die Angabe, welche negativen Folgen eine Fortführung der Maßnahme hat;
g. für den Fall, dass die Maßnahme oder das Versäumnis eines Mitarbeiters angefochten wird, eine detaillierte Darstellung der Sachlage gegenüber dem Mitarbeiter und die Gründe, warum die Maßnahme oder das Versäumnis des Mitarbeiters im Widerspruch zu den von ICANN aufgestellten Richtlinien steht;
h. für den Fall, dass eine Maßnahme oder ein Versäumnis des Boards angefochten wird, eine detaillierte Darlegung der wesentlichen vom Board nicht berücksichtigten Informationen und, falls die Informationen dem Board nicht vorgelegt wurden, die Gründe, warum die beantragende Partei dem Board die Informationen nicht vor der angefochtenen Maßnahme oder dem Versäumnis vorgelegt hat;
i. die Angabe, welche konkreten Schritte die beantragende Partei von ICANN erwartet, d. h. ob und wie die Maßnahme aufgehoben, verworfen oder geändert werden soll oder welche konkrete Maßnahme ergriffen werden soll;
j. die Gründe, warum die beantragte Maßnahme ergriffen werden soll; und
k. sämtliche Dokumente, die die beantragende Partei zur Untermauerung ihres Antrags vorlegen möchte.
7. Alle Anträge auf Entscheidungsüberprüfung werden auf der Website veröffentlicht.
8. Das Board Governance Committee ist berechtigt, von verschiedenen Parteien ausgehende Anträge auf Entscheidungsüberprüfung in einem einzigen Verfahren zu prüfen, sofern (i) sich die Anträge auf die gleiche allgemeine Maßnahme oder das Versäumnis beziehen und (ii) die beantragenden Parteien auf ähnliche Weise von einer solchen Maßnahme oder einem Versäumnis betroffen sind.
9. Das Board Governance Committee prüft die Anträge auf Entscheidungsüberprüfung umgehend nach Erhalt und kündigt binnen dreißig Tagen an, ob es den Antrag auf Entscheidungsüberprüfung berücksichtigt oder nicht berücksichtigt. Diese Ankündigung wird auf der Website veröffentlicht.
10. Beschließt das Board Governance Committee, den Antrag auf Entscheidungsüberprüfung nicht zu berücksichtigen, muss diese Entscheidung in der Ankündigung begründet werden.
11. Das Board Governance Committee kann von der beantragenden Partei zusätzliche Informationen oder Erklärungen anfordern.
12. Das Board Governance Committee kann ICANN-Mitarbeiter um ihre Stellungnahme zur betreffenden Angelegenheit ersuchen; derartige Stellungnahmen werden auf der Website veröffentlicht.
13. Benötigt das Board Governance Committee weitere Informationen, kann es zwecks Informationsaustausch mit der beantragenden Partei telefonisch, per E-Mail oder, falls für die beantragende Partei zumutbar, persönlich in Kontakt treten. Sofern die im Rahmen eines solchen Austauschs gesammelten Informationen für die Empfehlung des Board Governance Committees von Belang sind, wird dies in der Empfehlung erwähnt.
14. Das Board Governance Committee kann außerdem Informationen anfordern, die für die Anfragen Dritter von Belang sind. Sofern die gesammelten Informationen für die Empfehlung des Board Governance Committees von Belang sind, wird dies in der Empfehlung erwähnt.
15. Nach dem Antrag auf Entscheidungsüberprüfung handelt das Board Governance Committee auf Grundlage der öffentlichen Aufzeichnungen, einschließlich der Informationen, die von der beantragenden Partei, von ICANN-Mitarbeitern und von Dritten vorgelegt wurden.
16. Um sich davor zu schützen, dass die Möglichkeit zur Einleitung eines Verfahrens zur Entscheidungsüberprüfung missbraucht wird, kann das Board Governance Committee den Antrag auf Entscheidungsüberprüfung zurückweisen, wenn dieser zum wiederholten Male übermittelt wurde, ungerechtfertigt, unbedeutend oder auf sonstige Weise unangemessen ist oder wenn die betroffene Partei die Gelegenheit hatte, im betreffenden Zeitraum öffentlich zu der angefochtenen Maßnahme Stellung zu beziehen, dies jedoch nicht tat. Ebenso kann das Board Governance Committee einen Antrag zurückweisen, wenn die beantragende Partei nicht belegen kann, dass sie von der ICANN-Maßnahme betroffen ist.
17. Das Board Governance Committee gibt dem Board eine abschließende Empfehlung in Bezug auf den Antrag auf Entscheidungsüberprüfung binnen neunzig Tagen nach Erhalt eines solchen Antrages, sofern dies praktikabel ist; andernfalls schildert das Board Governance Committee dem Board die Umstände, die das Committee daran gehindert haben, eine abschließende Empfehlung zu geben, mit Angabe der geschätzten Dauer bis zur Vorlage einer solchen abschließenden Empfehlung. Die abschließende Empfehlung wird auf der Website veröffentlicht.
18. Das Board ist nicht an die Empfehlungen des Board Governance Committees gebunden. Die endgültige Entscheidung des Boards wird im vorläufigen Bericht und im Protokoll zu der Board-Versammlung, bei der die Maßnahme ergriffen wurde, veröffentlicht.
19. Das Board Governance Committee sendet dem Board jedes Jahr einen Bericht, der die folgenden Informationen für das vorangegangene Kalenderjahr enthält:
a. die Anzahl und allgemeine Art der eingegangenen Anträge auf Entscheidungsüberprüfung;
b. die Anzahl der Anträge auf Entscheidungsüberprüfung, bei denen das Board Governance Committee Maßnahmen ergriffen hat;
c. die Anzahl der Anträge auf Entscheidungsüberprüfung, die am Ende des Kalenderjahrs noch unerledigt waren, und die durchschnittliche Zeit, für die solche Anträge unerledigt geblieben sind;
d. eine Beschreibung der am Ende des Kalenderjahrs seit über neunzig (90) Tagen unerledigten Anträge auf Entscheidungsüberprüfung und die Gründe, warum das Board Governance Committee nicht aktiv geworden ist;
e. die Anzahl und Art der Anträge auf Entscheidungsüberprüfung, die vom Board Governance Committee nicht berücksichtigt wurden, weil die in dieser Richtlinie zugrunde gelegten Kriterien nicht erfüllt waren;
f. bei zurückgewiesenen Anträgen auf Entscheidungsüberprüfung eine Erläuterung anderer möglicher Verfahrensweisen, mit denen gewährleistet werden kann, dass ICANN Personen gegenüber rechenschaftspflichtig ist, die wesentlich von ICANN-Entscheidungen betroffen sind; und
g. die Angabe, ob nach Auffassung des Board Governance Committees die Kriterien, für die möglicherweise eine Entscheidungsüberprüfung beantragt wird, überprüft werden sollen oder ob ein anderer Prozess angewendet oder geändert werden soll, um sicherzustellen, dass alle Personen, die von ICANN-Entscheidungen wesentlich betroffen sind, angemessenen Zugang zu einem Überprüfungsprozess haben, der Fairness gewährleistet, gleichzeitig jedoch ungerechtfertigte Forderungen unterbindet.
20. In jedem Jahresbericht werden auch die Informationen zu den in Absatz 19(a)-(e) dieses Abschnitts aufgeführten Themen für den Zeitraum ab 1. Januar 2003 zusammengefasst.
Abschnitt 3. UNABHÄNGIGE PRÜFUNG VON BOARD-MASSNAHMEN
1. Zusätzlich zu dem in Abschnitt 2 dieses Artikels beschriebenen Prozess der Entscheidungsüberprüfung verfügt ICANN über einen gesonderten Prozess für die unabhängige Prüfung der von einer betroffenen Partei als nicht mit den Statuten oder der Gesellschaftssatzung übereinstimmend erachteten Board-Maßnahmen durch Dritte.
2. Jede Person, die von einer Entscheidung oder Maßnahme des Boards wesentlich betroffen ist oder die eine solche Entscheidung oder Maßnahme als nicht mit den Statuten oder der Gesellschaftssatzung übereinstimmend erachtet, kann eine unabhängige Prüfung dieser Entscheidung oder Maßnahme anfordern.
3. Die Anforderung einer solchen unabhängigen Prüfung wird an ein Independent Review Panel ("IRP") gesendet, dessen Aufgabe es ist, die angefochtenen Maßnahmen des Boards anhand der Statuten und der Gesellschaftssatzung zu überprüfen und festzustellen, ob das Board entsprechend den Bestimmungen der Statuten und der Gesellschaftssatzung gehandelt hat.
4. Das IRP wird von einer internationalen Schiedsstelle ("der IRP-Organisator") organisiert, die zeitweise von ICANN ("der IRP-Betreiber") beauftragt wird und Schlichter einsetzt, die einen Vertrag mit dem IRP abgeschlossen haben oder vom IRP ernannt wurden.
5. Abhängig von der Genehmigung des Boards legt der IRP-Organisator Regeln und Verfahren für die Arbeitsweise des IRP fest, die gemäß diesem Abschnitt 3 angewendet werden sollen.
6. Jede Partei kann entscheiden, dass sich ein aus drei Mitgliedern bestehendes Panel mit der Anforderung einer unabhängigen Prüfung befasst; bleibt eine solche Entscheidung aus, wird ein Ein-Personen-Panel mit der Angelegenheit betraut.
7. Der IRP-Organisator legt ein Verfahren für die Zuweisung von Mitgliedern zu einzelnen Panels fest; eine entsprechende ICANN-Anweisung vorausgesetzt, richtet der IRP-Organisator ein ständiges Panel für die Prüfung solcher Forderungen ein.
a. zusätzliche schriftliche Beiträge von der anfordernden Partei, dem Board, den Supporting Organizations oder anderen Parteien einzuholen;
b. zu erklären, ob eine Maßnahme oder Unterlassung des Boards nicht mit den Statuten oder der Gesellschaftssatzung übereinstimmte; und
c. zu empfehlen, dass das Board Maßnahmen oder Entscheidungen aussetzt bzw. aufhebt oder dass das Board Übergangsmaßnahmen ergreift, bis es sich mit der Auffassung des IRP beschäftigt hat und daraufhin aktiv wird.
9. Einzelpersonen, die eine offizielle Position oder ein offizielles Amt innerhalb der ICANN-Struktur innehaben, sind nicht berechtigt, im IRP mitzuwirken.
10. Um die Kosten und den Aufwand einer unabhängigen Prüfung so gering wie möglich zu halten, sollte das IRP so weit wie möglich per E-Mail und Internet kommunizieren. Falls erforderlich, sollte das IRP telefonische Besprechungen durchführen.
11. Das IRP befolgt die Richtlinien zu Interessenkonflikten gemäß den vom Board genehmigten Regeln und Verfahren für die Arbeitsweise des IRP.
12. Erklärungen des IRP erfolgen schriftlich. Das IRP gibt seine Erklärung ausschließlich auf der Basis der Dokumentation, des weiterführenden Materials und der von den Parteien vorgebrachten Argumente ab und bezeichnet in seiner Erklärung konkret die obsiegende Partei. Die unterlegene Partei trägt in der Regel alle Kosten des IRP-Organisators, im Einzelfall kann das IRP jedoch in seiner Erklärung festlegen, dass unter Berücksichtigung der Umstände bis zur Hälfte der Kosten des IRP-Organisators von der obsiegenden Partei getragen werden, mit Rücksicht auf die Angemessenheit der Position der Parteien und deren Beitrag zum öffentlichen Interesse. Jede am IRP-Verfahren beteiligte Partei trägt ihre eigenen Kosten.
13. Die Verfahrensweise des IRP sowie alle Eingaben, Forderungen und Erklärungen werden umgehend auf der Website veröffentlicht.
14. Das IRP kann in eigenem Ermessen der Bitte einer Partei um die vertrauliche Behandlung bestimmter Informationen, z. B. Geschäftsgeheimnisse, entsprechen.
15. Sofern machbar, befasst sich das Board bei der nächsten Board-Veranstaltung mit der IRP-Erklärung.
Abschnitt 4. REGELMÄSSIGE ÜBERPRÜFUNG DER ICANN-STRUKTUR UND -ARBEITSWEISE
1. Das Board veranlasst, eine regelmäßige Überprüfung der Leistung und Arbeitsweise jeder Supporting Organization, jedes Supporting Organization Councils, jedes Advisory Committees (mit Ausnahme des Governmental Advisory Committees) und des Nominating Committees durch eine oder mehrere Organisationen, die von der zu prüfenden Organisation unabhängig sind. Ziel der Überprüfung, die nach vom Board festgelegten Kriterien und Standards zu erfolgen hat, ist die Feststellung, (i) ob die betreffende Organisation einen fortwährenden Zweck in der ICANN-Struktur erfüllt und, (ii) falls ja, ob Änderungen an der Struktur oder Arbeitsweise im Hinblick auf höhere Effektivität erwünscht sind.
Diese periodischen Überprüfungen finden mindestens alle fünf Jahre statt, nach Maßgabe der vom Board festgelegten Durchführbarkeit. Jeder Fünfjahreszyklus beginnt mit dem Empfang des Abschlussberichts der entsprechenden mit der Prüfung beauftragten Arbeitsgruppe durch das Board.
Die Ergebnisse solcher Überprüfungen werden auf der Website veröffentlicht, sodass sie von den Nutzern der Website aufgerufen und kommentiert werden können, und werden spätestens bis zur zweiten planmäßigen Veranstaltung des Boards, ausgehend von einem Zeitraum von 30 Tagen nach Veröffentlichung der Ergebnisse, vom Board berücksichtigt. Dabei zieht das Board unter anderem die Möglichkeit in Betracht, die Struktur oder Arbeitsweise der überprüften ICANN-Bereiche per Zweidrittelmehrheit (2/3) aller Board-Mitglieder zu revidieren.
2. Das Governmental Advisory Committee stellt seine eigenen Prüfmechanismen zur Verfügung.
ARTIKEL V: OMBUDSMANN
Abschnitt 1. AMT DES OMBUDSMANNS
1. Es ist das Amt eines Ombudsmanns zu schaffen, das vom Ombudsmann geleitet wird und, soweit vom Board als angemessen und machbar erachtet, von Mitarbeitern unterstützt wird. Der Ombudsmann ist in Vollzeit tätig und erhält eine vom Board festgelegte und der Funktion angemessene Vergütung.
2. Der Ombudsmann wird vom Board zunächst für einen Zeitraum von zwei Jahren ernannt; über eine Verlängerung des Zeitraums entscheidet das Board.
3. Der Ombudsmann kann auf der Basis einer Dreiviertelmehrheit (3/4) des gesamten Boards abgesetzt werden.
4. Das jährliche Budget für das Amt des Ombudsmanns wird als Teil des jährlichen ICANN-Budgetprozesses vom Board festgelegt. Der Ombudsmann schlägt dem Präsidenten ein Budget vor, das vom Präsidenten vollständig und unverändert in das ICANN-Gesamtbudget übernommen wird, das der ICANN-Präsident dem Board empfiehlt. Der Präsident wird durch den Inhalt dieses Artikels in keiner Weise daran gehindert, eigene Auffassungen hinsichtlich des Wesens, des Umfangs oder sonstiger Merkmale des dem Board vom Ombudsmann vorgeschlagenen Budgets zu vertreten.
Die Funktion des Ombudsmanns besteht darin, als unparteiischer Schiedsmann in Angelegenheiten zu handeln, in denen sich nicht auf die Bestimmungen der in Abschnitt 2 von Artikel IV beschriebenen Richtlinie für Entscheidungsüberprüfungen oder auf die Bestimmungen der in Abschnitt 3 von Artikel IV beschriebenen Richtlinie für unabhängige Prüfungen berufen wurde. Die Hauptaufgabe des Ombudsmanns ist es, Beschwerden von Mitgliedern der ICANN-Community, die sich von ICANN-Mitarbeitern, dem Board oder einem konstituierenden ICANN-Organ ungerecht behandelt fühlen, unabhängig intern zu beurteilen. Der Ombudsmann tritt objektiv für Fairness ein und sollte bestrebt sein, Beschwerden über ungerechte oder unangemessene Behandlung durch ICANN-Mitarbeiter, das Board oder ein konstituierendes ICANN-Organ zu beurteilen und entsprechende Streitfälle so weit wie möglich zu schlichten, indem er die Angelegenheit prüft und Konflikte mithilfe seines Verhandlungsgeschicks, seiner Vermittlertätigkeit und durch "Pendeldiplomatie" zu lösen sucht.
Kraft seines Amts hat der Ombudsmann
1. die Aufgabe, eine faire, unparteiische und rechtzeitige Lösung von Problemen und Beschwerden, die betroffene Mitglieder der ICANN-Community (ausgenommen sind Mitarbeiter und Lieferanten/Auftragnehmer von ICANN) im Zusammenhang mit bestimmten Maßnahmen oder Unterlassungen durch das Board oder durch ICANN-Mitarbeiter vorbringen und bei denen sich nicht auf die Richtlinien zur Entscheidungsüberprüfung bzw. unabhängigen Prüfung berufen werden kann, zu erleichtern;.
2. das Recht, in eigenem Ermessen zu entscheiden, ob er auf eine Beschwerde oder Frage hin tätig wird, einschließlich der Entwicklung von Verfahren zur Zurückweisung von Beschwerden, die ungenau, unbedeutend oder in Bezug auf die Interaktionen zwischen ICANN und der Community irrelevant sind, sodass kein Grund für ein Eingreifen des Ombudsmanns besteht. Darüber hinaus ist der Ombudsmann nicht berechtigt, in internen Verwaltungsangelegenheiten, Personalangelegenheiten, Angelegenheiten in Bezug auf die Mitgliedschaft im Board oder Angelegenheiten im Zusammenhang mit der Beziehung zu Auftragnehmern/Lieferanten aktiv zu werden;
3. das Recht, auf alle erforderlichen Informationen und Aufzeichnungen von ICANN-Mitarbeitern und konstituierenden ICANN-Organen zuzugreifen (wobei er vertrauliche Informationen und Aufzeichnungen nicht veröffentlichen darf), um über eine solide Grundlage zur Beurteilung der Beschwerde zu verfügen und bei der Lösung von Streitfällen gegebenenfalls mitzuwirken (dabei unterliegt er ausschließlich Vertraulichkeitserklärungen seitens des Beschwerdeführers oder allgemeingültigen, von ICANN angewendeten Vertraulichkeitsrichtlinien);
4. die Möglichkeit, das Bewusstsein für das Ombudsmann-Programm und seine Funktionen durch regelmäßige Interaktion mit der ICANN-Community und durch Online-Veröffentlichungen zu stärken;
5. Neutralität und Unabhängigkeit zu wahren und weder Vorbehalte noch persönliches Interesse in Bezug auf den Ausgang eines Streitfalls zu hegen; und
6. in Übereinstimmung mit allen ICANN-Richtlinien zu Vertraulichkeit und Interessenkonflikten zu handeln.
Abschnitt 4. INTERAKTION MIT ICANN UND EXTERNEN ORGANISATIONEN
1. Kein ICANN-Mitarbeiter, Board-Mitglied oder anderer Angehöriger der Supporting Organizations oder Advisory Committees darf den Kontakt zwischen dem Ombudsmann und der ICANN-Community (einschließlich der Mitarbeiter von ICANN) unterbinden. ICANN-Mitarbeiter und Board-Mitglieder verweisen Mitglieder der ICANN-Community, die Probleme, Bedenken oder Beschwerden im Zusammenhang mit ICANN vorbringen, an den Ombudsmann, der die Beschwerdeführer über die verschiedenen Möglichkeiten zur Prüfung solcher Probleme, Bedenken oder Beschwerden berät.
2. ICANN-Mitarbeiter und andere ICANN-Angehörige beachten und respektieren die vom Amt des Ombudsmanns in Bezug auf die Vertraulichkeit eingegangener Beschwerden getroffenen Entscheidungen.
3. Der Kontakt mit dem Ombudsmann geht nicht damit einher, dass ICANN über eine bestimmte Maßnahme oder Vorgehensweise in Kenntnis gesetzt wird.
4. Der Ombudsmann ist konkret berechtigt, dem Board gegenüber Bericht zu erstatten, wenn er dies in Bezug auf eine bestimmte Angelegenheit und deren Lösung bzw. die Unmöglichkeit einer solchen Lösung als angemessen erachtet. Sofern nicht vom Ombudsmann nach ausschließlich eigenem Ermessen als unangemessen erachtet, werden solche Berichte auf der Website veröffentlicht.
5. Der Ombudsmann ergreift keinerlei Maßnahmen, zu denen er gemäß diesen Statuten nicht berechtigt ist, und beteiligt sich insbesondere nicht an gerichtlichen Schritten zur Anfechtung der ICANN-Struktur, von ICANN-Verfahren und -Prozessen oder zur Anfechtung des Verhaltens des ICANN-Boards, von ICANN-Mitarbeitern oder konstituierenden ICANN-Organen.
Das Amt des Ombudsmanns veröffentlicht auf jährlicher Basis eine konsolidierte Analyse der Beschwerden und Streitlösungen, wobei auf angemessene Weise mit Vertraulichkeitspflichten und -bedenken umgegangen wird. Der Jahresbericht enthält eine Beschreibung aller Tendenzen oder allgemeinen Merkmale von Beschwerden, die im entsprechenden Zeitraum eingegangen sind, sowie alle Empfehlungen für Maßnahmen zur Vermeidung künftiger Beschwerden. Der Jahresbericht wird auf der Website veröffentlicht.
ARTIKEL VI: BOARD OF DIRECTORS
Abschnitt 1. ZUSAMMENSETZUNG DES BOARDS
Das Board of Directors von ICANN ("Board") setzt sich aus fünfzehn stimmberechtigten Mitgliedern zusammen ("Direktoren"). Darüber hinaus sind sechs Vertreter ohne Stimmrecht ("Vertreter") für die in Abschnitt 9 dieses Artikels genannten Zwecke zu bestimmen. Bei der Bestimmung, ob ein Quorum vorhanden ist und ob die Abstimmung des ICANN-Boards gültig war, sind nur Direktoren zu berücksichtigen.
Abschnitt 2. DIREKTOREN UND IHRE AUSWAHL, WAHL DES VORSITZENDEN UND DES STELLVERTRETENDEN VORSITZENDEN
1. Die Direktoren setzen sich folgendermaßen zusammen:
a. Acht stimmberechtigte Mitglieder, die vom Nominating Committee ausgewählt werden, welches durch Artikel VII dieser Statuten gegründet wird. Diese Sitze im Board of Directors werden in den Statuten als Sitze 1 bis 8 bezeichnet.
b. Zwei stimmberechtigte Mitglieder, die von der Address Supporting Organization gemäß den Bestimmungen von Artikel VIII dieser Statuten ausgewählt werden. Diese Sitze im Board of Directors werden in den Statuten als Sitze 9 und 10 bezeichnet.
c. Zwei stimmberechtigte Mitglieder, die von der Country-Code Names Supporting Organization gemäß den Bestimmungen von Artikel IX dieser Statuten ausgewählt werden. Diese Sitze im Board of Directors werden in den Statuten als Sitze 11 und 12 bezeichnet.
d. Zwei stimmberechtigte Mitglieder, die von der Generic Names Supporting Organization gemäß den Bestimmungen von Artikel X dieser Statuten ausgewählt werden. Diese Sitze im Board of Directors werden in den Statuten als Sitze 13 und 14 bezeichnet.
e. Ein stimmberechtigtes Mitglied, das von der At-Large-Community gemäß den Bestimmungen von Artikel XI dieser Statuten ausgewählt wird. Dieser Sitz im Board of Directors werden in den Statuten als Sitz 15 bezeichnet.
f. Der Präsident von Amts wegen, der ein stimmberechtigtes Mitglied ist.
2. Bei der Wahrnehmung seiner Pflichten zur Besetzung der Sitze 1 bis 8 hat sich das Nominating Committee unter Anwendung der in Abschnitt 3 dieses Artikels genannten Kriterien darum zu bemühen, dass sich das ICANN-Board aus Mitgliedern zusammensetzt, die sich insgesamt durch eine Vielfalt in Bezug auf Geografie, Kultur, Fähigkeiten, Erfahrung und Perspektiven auszeichnen. Unter keinen Umständen wählt das Nominating Committee zur Besetzung eines frei gewordenen Mandates oder eines Mandates, dessen Amtszeit abgelaufen ist, einen Direktor aus, dessen Auswahl dazu führen würde, dass die Gesamtzahl der Direktoren (ohne den Präsidenten) aus Ländern in einer bestimmten geografischen Region (wie in Abschnitt 5 dieses Artikels definiert) fünf überschreitet, und das Nominating Committee hat durch seine Auswahlentscheidungen jederzeit sicherzustellen, dass das Board mindestens einen Direktor aus einem Land aus jeder geografischen Region von ICANN hat („Ermittlung der Vielfalt“).
Im Sinne des vorliegenden Artikels VI Abschnitt 2 Unterabschnitt 2 der ICANN-Statuten gilt für den Fall, dass ein Kandidat für das Amt des Direktors die Staatsbürgerschaft von mehr als einem Land besitzt oder seinen Wohnsitz seit mehr als fünf Jahren in einem Land hat, dessen Staatsbürgerschaft er nicht besitzt („Wohnsitz“), dass dieser als Staatsbürger beider Länder betrachtet werden kann und in seiner Interessenbekundung das Land seiner Staatsbürgerschaft oder seines Wohnsitzes anzugeben hat, welches das Nominating Committee zum Zweck der Ermittlung der Vielfalt verwenden soll. Im Sinne des vorliegenden Artikels VI, Abschnitt 2, Unterabschnitt 2 der ICANN-Statuten kann eine Person nur einen „Wohnsitz“ haben, welcher sich danach richtet, wo der Kandidat seinen ständigen Aufenthalt und festen Wohnsitz hat.
3. Bei der Wahrnehmung seiner Pflichten zur Besetzung der Sitze 9 bis 15 haben sich die Supporting Organizations und das At-Large Community unter Anwendung der in Abschnitt 3 dieses Artikels genannten Kriterien darum zu bemühen, dass sich das ICANN-Board aus Mitgliedern zusammensetzt, die sich insgesamt durch eine Vielfalt in Bezug auf Geografie, Kultur, Fähigkeiten, Erfahrung und Perspektiven auszeichnen. Zu keiner Zeit dürfen zwei von einer Supporting Organization ausgewählte Direktoren Staatsbürger desselben Landes oder aus Ländern innerhalb derselben geografischen Region sein.
Im Sinne des vorliegenden Artikels VI, Abschnitt 2, Unterabschnitt 3 der ICANN-Statuten gilt für den Fall, dass ein Kandidat für das Amt des Direktors die Staatsbürgerschaft von mehr als einem Land besitzt oder seinen Wohnsitz seit mehr als fünf Jahren in einem Land hat, dessen Staatsbürgerschaft er nicht besitzt („Wohnsitz“), dass dieser als Staatsbürger beider Länder betrachtet werden kann und in seiner Interessenbekundung das Land seiner Staatsbürgerschaft oder seines Wohnsitzes anzugeben hat, welches das Nominating Committee oder die At-Large Community zum Zweck der Ermittlung der Vielfalt verwenden soll. Im Sinne des vorliegenden Artikels VI, Abschnitt 3, Unterabschnitt 2 der ICANN-Statuten kann eine Person nur einen „Wohnsitz“ haben, welcher sich danach richtet, wo der Kandidat seinen ständigen Aufenthalt und festen Wohnsitz hat.
4. Das Board wählt jährlich einen Vorsitzenden und einen stellvertretenden Vorsitzenden unter den Direktoren, zu denen nicht der Präsident zählt.
Abschnitt 3. KRITERIEN ZUR AUSWAHL VON DIREKTOREN
ICANN-Direktoren sollten:
1. fähige Personen sein, die sich durch Integrität, Objektivität und Intelligenz auszeichnen sowie den Ruf genießen, über ein gesundes Urteilsvermögen zu verfügen, unvoreingenommen zu sein und erwiesenermaßen die Fähigkeit besitzen, wohlüberlegte Entscheidungen in einer Gruppe zu treffen;
2. Personen sein, die die Mission und die potenziellen Auswirkungen von ICANN-Entscheidungen auf die globale Internet-Community kennen und sich für den Erfolg von ICANN einsetzen;
3. Personen sein, die im Board eine möglichst große kulturelle und geografische Vielfalt ergeben, in Übereinstimmung mit den anderen in diesem Abschnitt aufgeführten Kriterien;
4. Personen sein, die in ihrer Gesamtheit mit der Funktionsweise von gTLD-Registries und Registrars, mit IP-Adress-Registries, mit technischen Standards und Protokollen des Internets, mit Strategieentwicklungsverfahren, rechtlichen Gebräuchen und dem öffentlichen Interesse sowie mit dem breiten Spektrum an geschäftlichen, privaten, akademischen und nichtgewerblichen Nutzern des Internets persönlich vertraut sind;
5. Personen sein, die bereit sind, ehrenamtlich und abgesehen von der Erstattung bestimmter Spesen ohne Vergütung tätig zu sein; und
6. Personen sein, die in der Lage sind, in schriftlichem und gesprochenem Englisch zu arbeiten und zu kommunizieren.
Abschnitt 4. ZUSÄTZLICHE QUALIFIKATIONEN
1. Ungeachtet anderslautender Bestimmungen in diesen Statuten ist keine Amtsperson einer nationalen Regierungsbehörde oder einer multinationalen juristischen Person, die durch ein Abkommen oder einen anderen Vertrag zwischen nationalen Regierungsbehörden gegründet wurde, berechtigt, als Direktor zu fungieren. Im Sinne dieser Statuten bezeichnet der Begriff "Amtsperson" eine Person, (i) die ein gewähltes behördliches Amt innehat oder (ii) von einer solchen Regierungsbehörde oder multinationalen juristischen Person beschäftigt wird und deren Hauptaufgabe bei einer solchen Regierungsbehörde oder multinationalen juristischen Person darin besteht, staatliche oder öffentliche politische Grundsätze zu entwickeln oder zu beeinflussen.
2. Keine Person, die in einem Supporting Organization Council in beliebiger Funktion (einschließlich als Vertreter) tätig ist, darf gleichzeitig im Board als Direktor oder Vertreter fungieren. Wenn eine solche Person eine Ernennung annimmt, für die Auswahl als Direktor durch einen Supporting Organization Council oder die At-Large Community in Erwägung gezogen zu werden, darf die Person im Anschluss an eine solche Ernennung erst dann an Diskussionen oder Abstimmungen des Supporting Organization Councils oder des von der At-Large Community berufenen Ausschusses im Zusammenhang mit der Auswahl der Direktoren durch den Council oder die Community teilnehmen, wenn der Council oder die von der Community bestimmten Ausschüsse sämtliche Direktoren ausgewählt haben, für deren Auswahl sie verantwortlich sind. Wenn eine Person, die in beliebiger Funktion in einem Supporting Organization Council tätig ist, eine Ernennung annimmt, für die Auswahl als Direktor in Erwägung gezogen zu werden, ist die Constituency-Gruppe oder andere Gruppe oder juristische Person, die die Person ausgewählt hat, berechtigt, für das Auswahlverfahren des Councils einen Ersatz auszuwählen. Wenn eine Person, die in beliebiger Funktion im At-Large Advisory Committee tätig ist, eine Ernennung annimmt, für die Auswahl als Direktor in Erwägung gezogen zu werden, ist die regionale At-Large Organization oder andere Gruppe oder juristische Person, die die Person ausgewählt hat, berechtigt, für das Auswahlverfahren der Community einen Ersatz auszuwählen.
3. Personen, die in beliebiger Funktion im Nominating Committee tätig sind, können nicht für Positionen im Board ausgewählt werden, wie in Artikel VII, Abschnitt 8 geregelt.
Abschnitt 5. INTERNATIONALE VERTRETUNG
Um eine vielfältige internationale Vertretung im Board sicherzustellen, hat die Auswahl von Direktoren durch das Nominating Committee und die jeweilige Supporting Organization und die At-Large Community allen geltenden Bestimmungen in Bezug auf Vielfalt in diesen Statuten oder in Memorandums of Understanding, auf die in diesen Statuten in Bezug auf die Supporting Organization verwiesen wird, zu entsprechen. Ein Ziel dieser Bestimmungen in Bezug auf Vielfalt besteht darin zu gewährleisten, dass jede geografische Region jederzeit über mindestens einen Direktor verfügt, und keine Region darf zu irgendeinem Zeitpunkt über mehr als fünf Direktoren im Board (ohne den Präsidenten) verfügen. Im Sinne dieser Statuten gilt jede der folgenden Regionen als eine "geografische Region": Europa, Asien/Australien/Pazifik, Lateinamerika/Karibische Inseln, Afrika und Nordamerika. Die jeweiligen Länder, die die einzelnen geografischen Regionen umfassen, sind vom Board zu bestimmen, und dieser Abschnitt ist gelegentlich (jedoch mindestens alle drei Jahre) zu prüfen, um festzustellen, ob unter Berücksichtigung der Weiterentwicklung des Internets eine Änderung angemessen ist.
Abschnitt 6. INTERESSENKONFLIKTE DER DIREKTOREN
Über das Board Governance Committee verlangt das Board mindestens einmal jährlich von jedem Direktor eine Erklärung, in der alle unternehmerischen und sonstigen Zugehörigkeiten aufgeführt werden, die in irgendeiner Form mit den unternehmerischen und sonstigen Zugehörigkeiten von ICANN zusammenhängen. Jeder Direktor ist dafür verantwortlich, ICANN gegenüber jegliche Angelegenheiten offenzulegen, die vernünftigerweise so ausgelegt werden können, dass dieser Direktor dadurch ein „befangener Direktor“ (Interested Director) im Sinne von Section 5233 des California Nonprofit Public Benefit Corporation Law („CNPBCL“) wird. Zudem hat jeder Direktor ICANN gegenüber Beziehungen oder sonstige Faktoren offenzulegen, die vernünftigerweise so ausgelegt werden können, dass sie bewirken, dass der Direktor dadurch als „befangener Direktor“ (Interested Director) im Sinne von Section 5227 des „CNPBCL“ betrachtet wird. Das Board hat Richtlinien einzuführen, die speziell auf Interessenkonflikte von Direktoren, Officers und Supporting Organization eingehen. Kein Direktor ist in Angelegenheiten stimmberechtigt, in denen er oder sie wesentliche oder unmittelbare finanzielle Interessen hat, die durch das Abstimmungsergebnis beeinflusst würden.
Abschnitt 7. PFLICHTEN VON DIREKTOREN
Direktoren haben als Personen zu agieren, die die Pflicht haben, nach vernünftiger eigener Einschätzung im besten Interesse von ICANN zu handeln, und nicht als Vertreter der juristischen Person, von der sie ausgewählt wurden, ihres Arbeitgebers oder anderer Organisationen oder Constituencies.
Abschnitt 8. AMTSZEIT VON DIREKTOREN
1 Die reguläre Amtszeit von Direktoren der Sitze 1 bis 15 beginnt wie folgt:
a. Die reguläre Amtszeit der Sitze 1 bis 3 beginnt mit Abschluss der ICANN-Jahresversammlung 2003 und jeder ICANN-Jahresversammlung in jedem dritten Jahr nach 2003.
b. Die reguläre Amtszeit der Sitze 4 bis 6 beginnt mit Abschluss der ICANN-Jahresversammlung 2004 und jeder ICANN-Jahresversammlung in jedem dritten Jahr nach 2004.
c. Die reguläre Amtszeit der Sitze 7 und 8 beginnt mit Abschluss der ICANN-Jahresversammlung 2005 und jeder ICANN-Jahresversammlung in jedem dritten Jahr nach 2005.
d. Die Amtszeit der Sitze 9 und 12 reicht bis zum Ende der ICANN-Sitzung zur Jahresmitte nach der ICANN-Jahressitzung 2011. Die nächste Amtszeit der Sitze 9 und 12 beginnt mit dem Ende der ICANN-Sitzung zur Jahresmitte, die nach der ICANN-Jahressitzung 2011 stattfindet sowie jeder ICANN-Jahressitzung in jedem dritten Jahr nach 2011.
e. Die Amtszeit der Sitze 10 und 13 reicht bis zum Ende der ICANN-Sitzung zur Jahresmitte nach der ICANN-Jahressitzung 2012. Die nächste Amtszeit der Sitze 10 und 13 beginnt mit dem Ende der ICANN-Sitzung zur Jahresmitte, die nach der ICANN-Jahressitzung 2012 stattfindet sowie jeder ICANN-Jahressitzung in jedem dritten Jahr nach 2012; und
f. Die Amtszeit der Sitze 11 und 14 beginnt mit dem Ende der ICANN-Sitzung zur Jahresmitte, die nach der ICANN-Jahressitzung 2010 stattfindet sowie jeder ICANN-Jahressitzung in jedem dritten Jahr nach 2010.
g. Die erste reguläre Amtszeit von Sitz 15 beginnt mit dem Ende der ICANN-Sitzung zur Jahresmitte, die nach der ICANN-Jahressitzung 2010 stattfindet sowie jeder ICANN-Jahressitzung in jedem dritten Jahr nach 2010. (Hinweis: In der Zeit vor dem Beginn der regulären Amtszeit von Sitz 15 wird Sitz 15 als vakant betrachtet. Die At-Large Community wählt mittels eines mit dem At Large Advisory Committee abgestimmten Prozesses einen Direktor aus, der den vakanten Sitz 15 besetzt und informiert den ICANN-Sekretär schriftlich über seine Wahl. Der vakante Sitz wurde zum Ende der ICANN-Jahresversammlung 2010 mit einer Amtszeit besetzt, die gemäß dieses Abschnitts der Statuten zu Beginn der ersten regulären Amtszeit von Sitz 15 endet. Bis zum Ende der ICANN-Jahresversammlung 2010 wurde vom At Large Advisory Committee ein Vertreter ohne Stimmrecht bestimmt, der an den Versammlungen gemäß der Abschnitte 9(3) und 9(5) dieses Artikels teilgenommen hat.)
h. Im Sinne dieses Abschnitts bezeichnet der Begriff „Versammlung zur Jahresmitte“ die erste öffentliche ICANN-Versammlung die mindestens sechs und spätestens acht Monate nach dem Ende der allgemeinen ICANN-Jahresversammlung stattfindet. Für den Fall, dass eine Versammlung zur Jahresmitte angesetzt und schließlich innerhalb von sechs Monaten vor dem festgesetzten Termin abgesagt wird, beginnen die Amtszeiten aller Sitze deren Beginn zum Ende der Versammlung zur Jahresmitte geplant war, an dem Datum, an dem die Versammlung zur Jahresmitte ursprünglich beendet werden sollte. Für den Fall, dass während der für die Versammlung zur Jahresmitte festgelegten Zeit keine öffentliche Versammlung geplant wird, beginnt die Amtszeit aller Sitze, deren Beginn für das Ende der Versammlung zur Jahresmitte geplant war, sechs Monate nach dem Ende der ICANN-Jahresversammlung.
2. Jeder Direktor, der einen der Sitze 1 bis 15 innehat, einschließlich Direktoren, die zur Besetzung eines frei gewordenen Sitzes ausgewählt wurden, bleibt für einen Zeitraum im Amt, der bis zum Beginn der nächsten Amtszeit für den Sitz und bis zur Auswahl und Qualifizierung eines Nachfolgers dauert oder bis zum Rücktritt oder der Entlassung des betreffenden Direktors in Übereinstimmung mit diesen Statuten.
3. Mindestens zwei Monate vor Beginn der nächsten Jahresversammlung hat das Nominating Committee dem Sekretär von ICANN seine Auswahl der Direktoren für die Sitze schriftlich mitzuteilen, wobei die Amtszeiten mit Abschluss der Jahresversammlung beginnen.
4. Mindestens zwei Monate vor dem Beginn der in Absatz 1.d-g oben festgelegten Amtszeit informiert jede Supporting Organization oder das At-Large-Community, die oder das zur Auswahl eines Direktors für einen Sitz berechtigt ist, dessen Amtszeit in diesem Jahr beginnt, den ICANN-Sekretär schriftlich über die Auswahl.
5. Vorbehaltlich der Bestimmungen des Übergangsartikels dieser Statuten ist kein Direktor berechtigt, mehr als drei Amtszeiten in Folge als Direktor tätig zu sein. Zu diesem Zweck gilt, dass einer Person, die zur Besetzung eines freien Mandates ausgewählt wird, diese Amtszeit nicht als abgeleistet angerechnet wird. Alle früheren Amtszeiten für die Sitze 9, 10, 11, 12, 13 und 14, deren Amtszeiten in den Statuten von [Datum vor Inkrafttreten der Änderungen eingeben] definiert waren, und solange diese Amtszeiten keine freien Mandate ausfüllten, werden auf die Zählung aufeinanderfolgender Amtszeiten gemäß dieses Absatzes angerechnet.
6. Die Amtszeit, die die Person im Amt des Präsidenten als Direktor absolviert, dauert so lange und nur so lange wie ihre Amtszeit als Präsident.
Abschnitt 9. VERTRETER OHNE STIMMRECHT
1. Zu den Vertretern ohne Stimmrecht gehören folgende:
a. ein durch das Governmental Advisory Committee gewählter Vertreter,
b. ein durch das Root Server System Advisory Committee, das mit Artikel XI dieser Statuten gegründet wird, gewählter Vertreter,
c. ein durch das Security and Stability Advisory Committee, das mit Artikel XI dieser Statuten gegründet wird, gewählter Vertreter,
d. ein durch das Technical Liaison Group, das mit Artikel XI-A dieser Statuten gegründet wird, gewählter Vertreter,
e. ein durch die Internet Engineering Task Force gewählter Vertreter
2. Vorbehaltlich der Bestimmungen des Übergangsartikels dieser Statuten sind Vertreter ohne Stimmrecht für Amtszeiten tätig, die mit Abschluss jeder Jahresversammlung beginnen. Mindestens einen Monat vor Beginn der nächsten Jahresversammlung hat jedes Organ, das zur Ernennung eines Vertreters ohne Stimmrecht berechtigt ist, dem Sekretär von ICANN seine Ernennung schriftlich mitzuteilen.
3. Vertreter ohne Stimmrecht haben ehrenamtlich und abgesehen von der Erstattung bestimmter Spesen ohne Vergütung tätig zu sein.
4. Jeder Vertreter ohne Stimmrecht kann erneut ernannt werden und behält diese Position inne, bis ein Nachfolger ernannt wurde oder bis der Vertreter zurücktritt oder in Übereinstimmung mit diesen Statuten entlassen wird.
5. Die Vertreter ohne Stimmrecht sind berechtigt, Board-Sitzungen beizuwohnen, sich an Board-Diskussionen und -Beratungen zu beteiligen, und haben (unter vom Board festgelegten Bedingungen) Zugriff auf Materialien, die den Direktoren zur Verwendung bei Board-Diskussionen, -Beratungen und -Sitzungen zur Verfügung gestellt werden, genießen jedoch abgesehen davon keine der Rechte und Privilegien von Direktoren. Vertreter ohne Stimmrecht sind (unter vom Board festgelegten Bedingungen) berechtigt, die ihnen gemäß diesem Abschnitt zur Verfügung gestellten Materialien zum Zwecke der Rücksprache mit ihrem jeweiligen Ausschluss oder ihrer Organisation zu verwenden.
Abschnitt 10. RÜCKTRITT EINES DIREKTORS ODER EINES VERTRETERS OHNE STIMMRECHT
Vorbehaltlich Abschnitt 5226 des CNPBCL können Direktoren oder Vertreter ohne Stimmrecht jederzeit zurücktreten, entweder durch mündliche Erklärung des Rücktritts bei einer Sitzung des Boards (gefolgt von einer unverzüglichen schriftlichen Mitteilung an den ICANN-Sekretär) oder durch schriftliche Mitteilung an den Präsidenten oder den Sekretär von ICANN. Ein solcher Rücktritt wird zum angegebenen Zeitpunkt wirksam, und die Annahme eines solchen Rücktritts ist, sofern nicht anders angegeben, für dessen Wirksamkeit nicht erforderlich. Der Nachfolger ist gemäß Abschnitt 12 dieses Artikels auszuwählen.
Abschnitt 11. ENTLASSUNG EINES DIREKTORS ODER EINES VERTRETERS OHNE STIMMRECHT
1. Jeder Direktor kann nach Mitteilung an diesen Direktor mit einer Mehrheit von drei Vierteln (3/4) der Stimmen aller Direktoren entlassen werden, jedoch mit der Maßgabe, dass der zu entlassende Direktor weder zur Teilnahme an der diesbezüglichen Abstimmung berechtigt ist noch bei der Berechnung der erforderlichen Mehrheit von drei Vierteln (3/4) der Stimmen als stimmberechtigtes Mitglied des Boards zu zählen ist, und unter der Voraussetzung, dass jede Abstimmung zur Entlassung eines Direktors als separate Abstimmung allein zur Frage der Entlassung des betreffenden Direktors gilt. Wenn der Direktor von einer Supporting Organization ausgewählt wurde, muss diese Supporting Organization zur gleichen Zeit informiert werden wie der Direktor. Wenn der Direktor vom At-Large Community ausgewählt wurde, muss das At-Large Community zur gleichen Zeit informiert werden wie der Direktor.
2. Mit Ausnahme des vom Governmental Advisory Committee ernannten Vertreters ohne Stimmrecht kann jeder Vertreter ohne Stimmrecht nach Mitteilung an diesen Vertreter und an die Organisation, von der dieser Vertreter ausgewählt wurde, mit einer Mehrheit von drei Vierteln (3/4) der Stimmen aller Direktoren entlassen werden, wenn die auswählende Organisation diesen Vertreter nach entsprechender Mitteilung nicht unverzüglich entlässt. Das Board ist berechtigt, das Governmental Advisory Committee aufzufordern, die Ersetzung des von diesem Committee ernannten Vertreters ohne Stimmrecht in Erwägung zu ziehen, wenn das Board mit einer Mehrheit von drei Vierteln (3/4) der Stimmen aller Direktoren bestimmt, dass eine solche Maßnahme angemessen ist.
1. Ein oder mehrere freie Sitze im Board of Directors liegen bei einem Todesfall, bei einem Rücktritt oder einer Entlassung eines Direktors vor oder wenn die zulässige Anzahl von Direktoren erhöht wurde oder ein Direktor durch einen endgültigen Gerichtsbeschluss für unzurechnungsfähig erklärt oder für eine Straftat verurteilt oder aufgrund einer Verurteilung für eine Straftat mehr als 90 Tage lang inhaftiert oder durch einen endgültigen Beschluss oder ein Urteil eines beliebigen Gerichts für schuldig befunden wurde, eine Pflicht gemäß Abschnitt 5230 und folgende des CNPBCL verletzt zu haben. Freie Sitze im Board of Directors sind vom Nominating Committee zu besetzen, es sei denn, (a) der betreffende Direktor wurde von einer Supporting Organization ausgewählt, wobei dieser freie Sitz von der betreffenden Supporting Organization zu besetzen ist, oder (b) der betreffende Direktor war der Präsident, wobei der freie Sitz gemäß den Bestimmungen von Artikel XIII dieser Statuten zu besetzen ist. Das auswählende Organ hat dem Sekretär von ICANN die Ernennungen zur Besetzung der freien Sitze schriftlich mitzuteilen. Ein zur Besetzung eines freien Sitzes im Board ausgewählter Direktor übernimmt das Amt für die laufende Amtszeit seines Amtsvorgängers und bis ein Nachfolger ausgewählt und qualifiziert wird. Eine Reduzierung der zulässigen Anzahl von Direktoren bewirkt nicht die Entlassung eines Direktors, bevor dessen Amtszeit als Direktor abgelaufen ist.
2. Die Organisationen, die die in Abschnitt 9 dieses Artikels genannten Vertreter ohne Stimmrecht auswählen, sind dafür verantwortlich, das Vorhandensein von freien Sitzen in diesen Positionen festzustellen und diese zu besetzen. Sie haben dem Sekretär von ICANN die Ernennungen zur Besetzung der freien Sitze schriftlich mitzuteilen.
Abschnitt 13. JAHRESVERSAMMLUNGEN
Jahresversammlungen von ICANN sind zu dem Zweck abzuhalten, Officers zu wählen und sonstigen Geschäften nachzugehen, die für die Versammlung vorgesehen sind. Jede Jahresversammlung für ICANN ist am Hauptsitz von ICANN oder einem anderen angemessenen, vom Board zu bestimmenden Ort zu einem vom Board zu bestimmenden Zeitpunkt abzuhalten, wobei die Jahresversammlung innerhalb von 14 Monaten der unmittelbar vorhergehenden Jahresversammlung stattfinden muss. Sofern das Board es als praktikabel erachtet, sollte die Jahresversammlung in Echtzeit im Internet verbreitet und in Video- und Audioformaten im Internet archiviert werden.
Abschnitt 14. REGULÄRE SITZUNGEN
Reguläre Sitzungen des Boards sind zu vom Board festgelegten Terminen abzuhalten. Wenn keine andere Festlegung getroffen wurde, finden die regulären Sitzungen am Hauptsitz von ICANN statt.
Sondersitzungen des Boards können von einem Viertel (1/4) der Mitglieder des Boards oder vom Vorsitzenden des Boards oder vom Präsidenten oder auf deren Wunsch einberufen werden. Ein Aufruf zu einer Sondersitzung hat vom Sekretär von ICANN zu erfolgen. Wenn keine andere Festlegung getroffen wurde, finden die Sondersitzungen am Hauptsitz von ICANN statt.
Abschnitt 16. MITTEILUNG ÜBER SITZUNGEN
Zeit und Ort aller Sitzungen sind jedem Direktor und Vertreter ohne Stimmrecht persönlich oder telefonisch oder per E-Mail oder per First-Class-Post (an Adressen außerhalb der USA per Luftpost) oder Fax mitzuteilen, wobei alle Gebühren vorauszubezahlen sind und die Mitteilung an jeden Direktor bzw. Vertreter ohne Stimmrecht an die in den Unterlagen von ICANN hinterlegte Anschrift des jeweiligen Direktors bzw. Vertreters ohne Stimmrecht zu senden ist. Wenn die Mitteilung per Post versendet wird, ist sie mindestens vierzehn (14) Tage vor dem für die Sitzung anberaumten Termin bei der US-amerikanischen Post abzugeben. Wenn die Mitteilung persönlich oder per Telefon oder Fax oder E-Mail erfolgt, muss dies mindestens achtundvierzig (48) Stunden vor dem für die Sitzung anberaumten Termin geschehen. Ungeachtet anderslautender Bestimmungen in diesem Abschnitt muss einem Direktor, der eine Erklärung über den Verzicht auf Mitteilungen oder eine schriftliche Einverständniserklärung zum Stattfinden der Sitzung oder eine Genehmigung des Protokolls darüber unterzeichnet hat oder der ohne vor der Sitzung oder bei dessen Beginn geäußerten Widerspruch gegen das Nichtvorhandensein einer solchen Mitteilung an diesen Direktor an der Sitzung teilnimmt, keine Mitteilung über eine Sitzung gemacht werden, ob vor oder nach der Sitzung. Alle derartigen Verzicht- und Einverständniserklärungen und Genehmigungen sind in den Unternehmensunterlagen abzulegen oder in das Protokoll der Sitzungen aufzunehmen.
Bei allen Jahresversammlungen, regulären und Sondersitzungen des Boards stellt eine Mehrheit der Gesamtzahl der zu dem Zeitpunkt amtierenden Direktoren ein Quorum für die Durchführung von Geschäften dar, und der Beschluss einer Mehrheit der bei einer Sitzung, bei der ein Quorum gegeben ist, zu einem beliebigen Zeitpunkt anwesenden Direktoren gilt als Beschluss des Boards, sofern in diesem Dokument oder gesetzlich vorgeschrieben nichts Gegenteiliges ist. Wenn bei einer Sitzung des Boards kein Quorum gegeben ist, können die bei der Sitzung anwesenden Direktoren die Sitzung gelegentlich auf einen anderen Ort oder einen anderen Termin vertagen. Wenn eine Sitzung für mehr als vierundzwanzig (24) Stunden vertagt wird, ist dies den nicht bei der Sitzung anwesenden Direktoren zum Zeitpunkt der Vertagung mitzuteilen.
Abschnitt 18. BESCHLUSS PER TELEFONISCHE SITZUNG ODER DURCH ANDERE KOMMUNIKATIONSGERÄTE
Mitglieder des Boards oder eines Committees des Boards sind berechtigt, durch Verwendung von (i) Telefonkonferenz- oder ähnlichen Kommunikationsgeräten, sofern alle an dieser Sitzung teilnehmenden Direktoren miteinander sprechen und einander hören können, oder von (ii) elektronischen Videobildschirmkommunikations- oder sonstigen Kommunikationsgeräten an einer Sitzung des Boards oder Committees des Boards teilzunehmen, und zwar unter der Voraussetzung, dass (a) alle Direktoren, die an einer solchen Sitzung teilnehmen miteinander sprechen und einander hören können, (b) allen Direktoren die Mittel für eine uneingeschränkte Beteiligung an allen Angelegenheiten zur Verfügung gestellt wird, die vom Board bzw. vom Committee des Boards erörtert werden, und (c) ICANN Methoden einführt und umsetzt, mit denen überprüft werden kann, ob (x) eine Person, die an einer solchen Sitzung teilnimmt, ein Direktor oder eine andere zur Teilnahme an der Sitzung berechtigte Person ist, und ob (y) alle Beschlüsse oder Abstimmungen des Boards oder des Committees des Boards ausschließlich von den Mitgliedern des Boards bzw. Committees gefasst bzw. durchgeführt werden, und nicht von Personen, die nicht Mitglied sind. Die Teilnahme an einer Sitzung in Übereinstimmung mit diesem Abschnitt entspricht der persönlichen Anwesenheit bei einer solchen Sitzung. ICANN hat am Ort einer Sitzung des Boards die nötigen Telekommunikationsgeräte zur Verfügung zu stellen, die den Mitgliedern des Boards die telefonische Teilnahme ermöglichen.
Abschnitt 19. MASSNAHMEN OHNE SITZUNG
Maßnahmen, die vom Board oder von einem Committee des Boards ergriffen werden müssen oder dürfen, können ohne Sitzung ergriffen werden, wenn alle diesbezüglich stimmberechtigten Direktoren dieser Maßnahme einzeln oder kollektiv schriftlich zustimmen. Eine solche schriftliche Zustimmung hat die gleiche Verbindlichkeit und Wirkung wie eine einstimmige Abstimmung dieser Direktoren. Die schriftliche Zustimmung bzw. die schriftlichen Zustimmungen sind mit dem Protokoll zum Vorgehen des Boards abzulegen.
Sofern nach geltendem Recht zulässig, haben Mitteilungen per E-Mail den gleichen Wert wie alle sonstigen Mitteilungen, die schriftlich erfolgen müssen. ICANN hat die unter den gegebenen Umständen nach eigener Einschätzung angemessenen Maßnahmen zu ergreifen, um sich Gewissheit darüber zu verschaffen, dass Mitteilungen per E-Mail authentisch sind.
Abschnitt 21. RECHTE AUF EINSICHT IN UNTERLAGEN
Jeder Direktor hat das Recht, zu einem angemessenen Zeitpunkt alle Bücher, Unterlagen und Dokumente jeglicher Art einzusehen und zu kopieren sowie die physischen Standorte von ICANN zu inspizieren. ICANN hat angemessene Verfahren einzuführen, um vertrauliche Informationen vor einer unangemessenen Offenlegung zu schützen.
Der Vorsitzende des ICANN-Boards ist berechtigt, eine angemessene Vergütung für seine Tätigkeit als Direktor zu erhalten. Das Compensation Committee ist verantwortlich für die Empfehlung einer angemessenen Vergütung für den Vorsitzenden des Boards. An den Erörterungen und Abstimmungen über die Empfehlungen an das Board dürfen nur Mitglieder des Compensation Committees teilnehmen, die in Bezug auf die Partei, für die die Vergütung erwogen wird, frei von Interessenkonflikten sind. An den Erörterungen und Abstimmungen über die Genehmigung der Vergütung für den Vorsitzenden des Boards dürfen nur Mitglieder des Boards teilnehmen, die in Bezug auf die Partei, für die die Vergütung erwogen wird, frei von Interessenkonflikten sind. Der Vorsitzende des Boards darf zu keiner Zeit an den Erörterungen oder Abstimmungen zur Vergütung des Vorsitzenden des Boards teilnehmen. Das Compensation Committee und das Board folgt den im United States Internal Revenue Code niedergelegten Verfahren und Finanzbestimmungen, um zu gewährleisten, die angemessene Vergütung des Vorsitzenden des Boards auf der Grundlage einer wiederlegbaren Vermutung erfolgt.
Alle anderen Direktoren, außer dem Vorsitzenden des Boards, erhalten für ihre Dienste als Direktoren keine Vergütung. Das Board ist jedoch berechtigt, die Erstattung tatsächlicher und notwendiger Ausgaben in angemessenem Umfang zu genehmigen, die den Direktoren und Vertretern ohne Stimmrecht bei der Erfüllung ihrer Pflichten als Direktor bzw. Vertreter ohne Stimmrecht entstehen.
Abschnitt 23. ANNAHME DER ZUSTIMMUNG
Bei einem bei einer Board-Sitzung, bei der über eine Maßnahme oder eine Angelegenheit der Organisation entschieden wird, anwesenden Direktor wird die Zustimmung zu der Maßnahme angenommen, wenn im Sitzungsprotokoll kein Widerspruch bzw. keine Enthaltung dieser Person angegeben ist oder wenn dieser Direktor bis zur Vertagung der Sitzung keinen schriftlichen Widerspruch bzw. keine schriftliche Enthaltung in Bezug auf diese Maßnahme bei der Person hinterlegt, die als Sekretär der Sitzung fungiert, oder unmittelbar nach Vertagung der Sitzung keinen Widerspruch bzw. keine Enthaltung per Einschreiben an den Sekretär von ICANN sendet. Dieses Recht auf Widerspruch bzw. Enthaltung gilt nicht für Direktoren, die für eine solche Maßnahme gestimmt haben.
ARTIKEL VII: NOMINATING COMMITTEE
Es ist ein Nominating Committee von ICANN zu gründen, das für die Auswahl aller ICANN-Direktoren mit Ausnahme des Präsidenten und der Direktoren, die von den Supporting Organizations von ICANN ausgewählt werden, sowie für andere Auswahlvorgänge verantwortlich ist, die in diesen Statuten aufgeführt werden.
Das Nominating Committee hat sich aus folgenden Personen zusammenzusetzen:
1. ein Vorsitzender ohne Stimmrecht, der vom ICANN-Board ernannt wird,
2. ein nachfolgender Vorsitzender ohne Stimmrecht, der vom ICANN-Board als Berater ohne Stimmrecht ernannt wird,
3. ein durch das ICANN Root Server System Advisory Committee, das mit Artikel XI dieser Statuten gegründet wird, gewählter Vertreter ohne Stimmrecht,
4. ein durch das ICANN Security and Stability Advisory Committee, das mit Artikel XI dieser Statuten gegründet wird, gewählter Vertreter ohne Stimmrecht,
5. ein Vertreter ohne Stimmrecht, der vom Governmental Advisory Committee ernannt wird,
6. vorbehaltlich der Bestimmungen des Übergangsartikels dieser Statuten fünf durch das At-Large Advisory Committee, das mit Artikel XI dieser Statuten gegründet wird, ausgewählte stimmberechtigte Delegierte,
7. Stimmberechtigte Delegierte des Nominating Committees werden von der Generic Names Supporting Organization ausgewählt, die gemäß Artikel X dieser Statuten eingesetzt wird, und zwar folgendermaßen:
a. ein Delegierter der Registries-Interessengruppe
b. ein Delegierter der Registrars-Interessengruppe
c. zwei Delegierte des Bezirks für den Handel, von denen einer Benutzer kleiner Unternehmen und einer Benutzer großer Unternehmen repräsentiert
d. ein Delegierter des Bezirks für Internet Service Provider
e. ein Delegierter des Bezirks für geistiges Eigentum und
f. ein Delegierter der Verbrauchergruppen und Nichtregierungsorganisationen, ausgewählt vom Bezirk für nichtgewerbliche Nutzer
8. jeweils ein stimmberechtigter Delegierter, der von folgenden juristischen Personen ausgewählt wird:
a. dem Council der Country Code Names Supporting Organization, die mit Artikel IX dieser Statuten gegründet wird,
f. dem Council der Address Supporting Organization, die mit Artikel VIII dieser Statuten gegründet wird,
c. der Internet Engineering Task Force und
d. der ICANN Technical Liaison Group, die mit Artikel XI-A dieser Statuten gegründet wird
9. einem beisitzenden Vorsitzenden (Associate Chair) ohne Stimmrecht, der vom Vorsitzenden nach dessen Ermessen ernannt werden kann und während der gesamten Amtszeit des Vorsitzenden oder eines Teils davon amtiert. Der beisitzende Vorsitzende darf keine Person sein, die anderweitig Mitglied desselben Nominating Committees ist. Der beisitzende Vorsitzende hat den Vorsitzenden bei der Erfüllung der Pflichten des Vorsitzenden zu unterstützen, darf jedoch weder vorübergehend noch anderweitig als Vorsitzender agieren.
Nach den Bestimmungen des Übergangsartikels dieser Statuten:
1. Für jeden stimmberechtigten Delegierten beträgt die Amtszeit ein Jahr. Ein Delegierter darf maximal zwei einjährige Amtszeiten in Folge amtieren; danach müssen mindestens zwei Jahre verstreichen, bis die Person für eine weitere Amtszeit in Frage kommt.
2. Für jeden stimmberechtigten Delegierten beginnt die reguläre Amtszeit bei Abschluss der ICANN-Jahresversammlung und endet mit Abschluss der unmittelbar darauffolgenden ICANN-Jahresversammlung.
3. Vertreter ohne Stimmrecht amtieren während der von der juristischen Person, die sie ernannt hat, festgelegten Amtszeit. Der Vorsitzende, der nachfolgende Vorsitzender und der beisitzende Vorsitzende amtieren bis zum Abschluss der nächsten ICANN-Jahresversammlung.
4. Es wird davon ausgegangen, dass der nachfolgende Vorsitzende nach dem Ende seiner Amtszeit vom Board zum Vorsitzenden ernannt wird. Es obliegt jedoch der Entscheidung des Boards, eine beliebige andere Person zum Vorsitzenden zu ernennen. Wenn das Board zum Zeitpunkt der Ernennung eines nachfolgenden Vorsitzen beschließt, dass die als Vorsitzender bestimmte Person für eine weitere Amtszeit ernannt wird, bleibt die Position des nachfolgenden Vorsitzenden für die vom Board bestimmte Zeit unbesetzt.
5. Freie Positionen als Delegierter, Vertreter ohne Stimmrecht, Vorsitzender oder nachfolgender Vorsitzender sind von der juristischen Person zu besetzen, die zur Auswahl des jeweiligen Delegierten, Vertreters ohne Stimmrecht, Vorsitzenden bzw. nachfolgenden Vorsitzenden berechtigt ist. Für die Zeit, die die Position des nachfolgenden Vorsitzenden gemäß Absatz 4 dieses Artikel unbesetzt bleibt, oder bis zu dem Zeitpunkt, zu dem die aus anderem Grund unbesetzte Position des nachfolgenden Vorsitzenden besetzt werden kann, kann das Board aus früheren Mitgliedern des Boards oder eines Nominating Committees, einschließlich des unmittelbar vorangegangenen Vorsitzenden des Nominating Committees, einen Berater ohne Stimmrecht für den Vorsitzenden ernennen. Eine freie Position als beisitzender Vorsitzender kann vom Vorsitzenden in Übereinstimmung mit den Kriterien in Abschnitt 2(9) dieses Artikels besetzt werden.
6. Das Vorhandensein von freien Positionen hat keinerlei Auswirkungen auf die Verpflichtung des Nominating Committees, seine ihm in diesen Statuten zugewiesenen Pflichten zu erfüllen.
Abschnitt 4. KRITERIEN ZUR AUSWAHL VON DELEGIERTEN DES NOMINATING COMMITTEES
Delegierte des ICANN Nominating Committees sollten:
1. fähige Personen sein, die sich durch Integrität, Objektivität und Intelligenz auszeichnen sowie den Ruf genießen, über ein gesundes Urteilsvermögen zu verfügen, unvoreingenommen sowie erfahren und kompetent in Bezug auf kollektive Entscheidungen in einer großen Gruppe zu sein;
2. Personen mit breit gefächerten Kontakten und vielseitigen Erfahrungen in der Internet-Community sein und sich mit Engagement für den Erfolg von ICANN einsetzen;
3. Personen sein, die nach Einschätzung des auswählenden Organs bei der Erfüllung ihrer Pflichten auf breiter Ebene Rücksprache halten und Beiträge anderer annehmen;
4. Personen sein, die unparteiisch und objektiv sowie bei der Erfüllung ihrer Pflichten im Rahmen des Nominating Committees ohne feste persönliche Verpflichtungen gegenüber Personen, Organisationen oder kommerziellen Zielen sind;
5. Personen sein, die die Mission und die potenziellen Auswirkungen von ICANN-Aktivitäten auf die allgemeine Internet-Community kennen, die bereit sind, ehrenamtlich und abgesehen von der Erstattung bestimmter Spesen ohne Vergütung tätig zu sein; und
6. Personen sein, die in der Lage sind, in schriftlichem und gesprochenem Englisch zu arbeiten und zu kommunizieren.
Bei der Erfüllung der Pflichten zur Auswahl von Mitgliedern des ICANN-Boards (und zur Wahl in andere ICANN-Organe, für die das Nominating Committee diesen Statuten entsprechend zuständig ist) hat das Nominating Committee die fortbestehende Mitgliedschaft des ICANN-Boards (und anderer Organe dieser Art) zu berücksichtigen und sich darum zu bemühen, dass die zur Besetzung von freien Positionen im ICANN-Board (und jedem anderen derartigen Organ) ausgewählten Personen im realistischen Umfang und in Übereinstimmung mit den übrigen gemäß Abschnitt 4 dieses Artikels anwendbaren Kriterien Entscheidungen treffen, die sich an Kernwert 4 in Artikel I, Abschnitt 2 orientieren.
Abschnitt 6. VERWALTUNGS- UND ORGANISATIONSUNTERSTÜTZUNG
ICANN hat die nötige Verwaltungs- und Organisationsunterstützung bereitzustellen, die das Nominating Committee zur Erfüllung seiner Pflichten benötigt.
Das Nominating Committee hat die nach eigenem Ermessen notwendigen Betriebsverfahren anzuwenden, die auf der Website zu veröffentlichen sind.
Abschnitt 8. NICHTWÄHLBARKEIT DURCH NOMINATING COMMITTEE
Eine Person, die in beliebiger Funktion im Nominating Committee tätig ist, kann nur dann auf beliebige Weise für eine Position im Board oder einem anderen ICANN-Organ, das über mindestens eine Mitgliedsposition verfügt, für deren Besetzung das Nominating Committee zuständig ist, ausgewählt werden, wenn eine ICANN-Jahresversammlung abgeschlossen ist, die mit dem Abschluss der Amtszeit der Person im Nominating Committee zusammenfällt oder danach liegt.
Abschnitt 9. NICHTVERFÜGBARKEIT FÜR EIN AMT IM NOMINATING COMMITTEE
Keine Person, die Mitarbeiter oder bezahlter Berater von ICANN ist (einschließlich Ombudsmann) ist, darf gleichzeitig eine der Position im Nominating Committee übernehmen, die in Abschnitt 2 dieses Artikels beschrieben ist.
ARTIKEL VIII: ADDRESS SUPPORTING ORGANIZATION
1. Die Address Supporting Organization (ASO) berät das Board in Bezug auf Strategiefragen hinsichtlich des Betriebs, der Zuweisung und der Verwaltung von Internetadressen.
2. Die ASO stellt dabei eine gemäß dem am 21. Oktober 2004 zwischen der ICANN und der Number Resource Organization (NRO), einer Organisation der bestehenden regionalen Internetregister (RIRs), geschlossenen Memorandum of Understanding gegründeten Instanz dar.
1. Die ASO hat einen Address Council einzusetzen, der aus Mitgliedern des NRO Number Councils besteht.
2. Aufgabe des Address Councils ist die Auswahl von Direktoren für die Positionen im Board, die vom ASO zu besetzen sind.
ARTIKEL IX: COUNTRY-CODE NAMES SUPPORTING ORGANIZATION
Es ist ein Strategieentwicklungsorgan namens Country-Code Names Supporting Organization (ccNSO) zu gründen, das folgende Aufgaben hat:
1. Ausarbeitung von globalen Richtlinien in Bezug auf länderspezifische Top-Level-Domains und Empfehlungen an das Board;
2. Fördern des Konsenses in der gesamten ccNSO-Community, einschließlich der namensbezogenen Aktivitäten von ccTLDs; und
3. Koordination mit anderen ICANN-Supporting Organizations, -Committees und -Constituencies.
Richtlinien, die für ccNSO-Mitglieder aufgrund ihrer Mitgliedschaft gelten, sind nur jene Richtlinien, die in Übereinstimmung mit Abschnitt 4.10 und 4.11 dieses Artikels erarbeitet werden. Die ccNSO ist jedoch berechtigt, auch anderen Aktivitäten nachzugehen, die von ihren Mitgliedern genehmigt wurden. Die Einhaltung der Ergebnisse dieser Aktivitäten ist freiwillig, und zu diesen Aktivitäten zählen folgende: Bemühen um die Entwicklung von freiwilligen Best Practices für ccTLD-Manager, Unterstützung beim Aufbau von Fähigkeiten innerhalb der globalen Community der ccTLD-Manager sowie Verbesserung der betrieblichen und technischen Zusammenarbeit unter ccTLD-Managern.
Die ccNSO besteht aus (i) ccTLD-Managern, die sich schriftlich bereit erklärt haben, Mitglied der ccNSO zu werden (siehe Abschnitt 4(2) dieses Artikels) und (ii) einem ccNSO Council, das für die Verwaltung des Richtlinienausarbeitungsprozesses der ccNSO zuständig ist.
1. Der ccNSO Council besteht aus (a) drei ccNSO Council-Mitgliedern, die von den ccNSO-Mitgliedern innerhalb der jeweiligen geografischen Region von ICANN in der in Abschnitt 4(7) bis (9) dieses Artikels beschriebenen Weise ausgewählt werden, (b) drei ccNSO Council-Mitgliedern, die vom ICANN Nominating Committee ausgewählt werden, (c) Vertretern, wie in Absatz 2 dieses Abschnitts beschrieben, und (iv) Beobachtern, wie in Absatz 3 dieses Abschnitts beschrieben.
2. Außerdem soll es im ccNSO Council jeweils einen Vertreter aus den folgenden Organisationen geben, und zwar in dem Umfang, den sie dem Vertreter zuweisen: (a) dem Governmental Advisory Committee, (b) dem At-Large Advisory Committee und (c) jeder der in Abschnitt 5 dieses Artikels beschriebenen regionalen Organisationen. Diese Vertreter sind keine Mitglieder des ccNSO Councils und haben in diesem Organ kein Stimmrecht, sind jedoch andernfalls berechtigt, sich auf gleicher Ebene mit den Mitgliedern des ccNSO Councils zu beteiligen. Ernennungen von Vertretern müssen mit schriftlicher Mitteilung an den ICANN-Sekretär erfolgen, mit einer Benachrichtigungskopie an den Vorsitzenden des ccNSO Councils, und erstrecken sich über eine Amtszeit, die von der ernennenden Organisation, wie in der schriftlichen Mitteilung angegeben, festgelegt wird. Die ernennende Organisation ist berechtigt, ihren Vertreter jederzeit seines Amtes zu entheben oder zu ersetzen, und zwar mit schriftlicher Mitteilung über die Enthebung oder den Ersatz an den ICANN-Sekretär, mit Benachrichtigungskopie an den Vorsitzenden des ccNSO Councils.
3. Der ccNSO Council kann mit dem Council einer anderen ICANN-Supporting Organization den Austausch von Beobachtern vereinbaren. Diese Beobachter sind keine Mitglieder des ccNSO Councils und haben in diesem Organ kein Stimmrecht, sind jedoch andernfalls berechtigt, sich auf gleicher Ebene mit den Mitgliedern des ccNSO Councils zu beteiligen. Der ernennende Council ist berechtigt, seine Beobachter im ccNSO Council jederzeit zu ernennen (bzw. die Ernennung seiner Beobachter zurückzunehmen oder zu ändern), und zwar mit schriftlicher Mitteilung an den ICANN-Sekretär, mit Benachrichtigungskopie an den Vorsitzenden des ccNSO Councils.
4. Nach den Bestimmungen des Übergangsartikels dieser Statuten: (a) hat die reguläre Amtszeit eines Mitglieds des ccNSO Councils mit Abschluss einer ICANN-Jahresversammlung zu beginnen und mit Abschluss der dritten ICANN-Jahresversammlung danach zu enden, (b) sind die regulären Amtszeiten der drei durch die ccNSO-Mitglieder innerhalb der geografischen Region von ICANN gewählten ccNSO Council-Mitglieder so zu staffeln, dass die Amtszeit eines Mitglieds in einem durch drei teilbaren Jahr, die Amtszeit eines zweiten Mitglieds im ersten Jahr nach dem durch drei teilbaren Jahr und die Amtszeit des dritten Mitglieds im zweiten Jahr nach dem durch drei teilbaren Jahr beginnt, und (c) sind die regulären Amtszeiten der drei ccNSO Council-Mitglieder, die durch das Nominating Committee gewählt wurden, auf gleiche Weise zu staffeln. Jedes Mitglied des ccNSO Councils bleibt bis zum Ende der regulären Amtszeit im Amt bzw. bis zu dem Zeitpunkt, zu dem ein geeigneter Nachfolger gewählt worden ist, dieses Mitglied zurücktritt oder im Einklang mit diesen Statuten aus dem Amt entlassen wird.
5. Ein Mitglied des ccNSO Councils kann jederzeit durch schriftliche Mitteilung an den ICANN-Sekretär mit Benachrichtigungskopie an den Vorsitzenden des ccNSO Councils zurücktreten.
6. Mitglieder des ccNSO Councils können aus dem Amt entlassen werden, wenn sie ohne ausreichenden Grund drei Sitzungen des ccNSO Councils in Folge fernbleiben oder sich äußerst unangemessen verhalten; in beiden Fällen ist bei einer diesbezüglichen Abstimmung eine Mehrheit von mindestens 66 % aller Mitglieder des ccNSO Councils erforderlich.
7. Ein freier Sitz im ccNSO Council existiert im Falle des Todes, Rücktritts oder Entlassens eines Mitglieds. Freie Positionen der drei Mitglieder, die vom Nominating Committee gewählt werden, sind für die betreffende unvollendete Amtszeit durch das Nominating Committee zu besetzen, wobei dem ICANN-Sekretär die Auswahl schriftlich mitzuteilen ist, mit einer Benachrichtigungskopie an den Vorsitzenden des ccNSO Councils. Freie Positionen unter den Mitgliedern des ccNSO Councils, die durch ccNSO-Mitglieder gewählt werden, sind nach dem in Abschnitt 4(7) bis (9) dieses Artikels beschriebenen Verfahren für die unvollendete Amtszeit zu besetzen.
8. Die Aufgabe des ccNSO Councils besteht darin, die Angelegenheiten des ccNSO zu verwalten und zu koordinieren (einschließlich Koordination von Sitzungen, darunter auch einer Jahresversammlung, von ccNSO-Mitgliedern, wie in Abschnitt 4(6) dieses Artikels beschrieben) sowie die Entwicklung von Richtlinienempfehlungen in Übereinstimmung mit Abschnitt 6 dieses Artikels zu leiten. Der ccNSO Council hat außerdem sonstige Funktionen zu übernehmen, die die Mitglieder des ccNSO von Zeit zu Zeit beschließen.
9. Der ccNSO Council hat zur Besetzung der Sitze 11 und 12 des Boards eine schriftliche Wahl durchzuführen oder auf einer Veranstaltung eine Initiative zu ergreifen; einer solchen Besetzung hat die Mehrheit sämtlicher zu dem Zeitpunkt amtierenden Mitglieder des ccNSO Councils zuzustimmen. Der Vorsitzende des ccNSO Councils hat den ICANN-Sekretär über die Besetzung des ccNSO Councils schriftlich zu informieren sowie im Einklang mit Artikel VI, Abschnitt 8(4) und 12(1).
10. Der ccNSO Council hat unter seinen Mitgliedern den Vorsitzenden des ccNSO Councils sowie eine nach eigenem Ermessen angemessene Anzahl von stellvertretenden Vorsitzenden zu wählen. Die Wahl des Vorsitzenden und des/der stellvertretenden Vorsitzenden des ccNSO Councils hat in Form einer schriftlichen Wahl zu erfolgen oder durch eine Initiative auf einer Veranstaltung; einer solchen Wahl hat die Mehrheit sämtlicher zu dem Zeitpunkt amtierenden Mitglieder des ccNSO Councils zuzustimmen. Die Amtszeit des Vorsitzenden und etwaiger stellvertretender Vorsitzender des ccNSO Councils hat den Angaben zu entsprechen, die der ccNSO Council bei oder vor der Wahl gemacht hat. Der Vorsitzende bzw. etwaige stellvertretende Vorsitzende des ccNSO Councils können mit demselben Verfahren wie bei der Wahl aus dem Amt abberufen werden.
11. Der ccNSO Council hat, vorbehaltlich Anweisungen der ccNSO-Mitglieder, Vorschriften und Verfahrensweisen für die ccNSO einzuführen, die es für notwendig erachtet, sofern sie diesen Statuten entsprechen. Vorschriften für ccNSO-Mitgliedschafts- und -Betriebsverfahren, die vom ccNSO Council eingeführt werden, sind auf der Website zu veröffentlichen.
12. Sofern nicht durch die Absätze 9 und 10 dieses Abschnitts anders vorgesehen, hat der ccNSO Council auf Veranstaltungen aktiv mitzuwirken. Der ccNSO Council hat sich nach einem von ihm bestimmten Zeitplan regelmäßig zu versammeln, jedoch mindestens vier Mal pro Kalenderjahr. Nach Ermessen des ccNSO Councils können Sitzungen durch persönliche Teilnahme oder mit anderen Methoden abgehalten werden, sofern es allen Mitgliedern des ccNSO Councils gestattet ist, durch mindestens eine der in Absatz 14 dieses Abschnitts genannten Methoden teilzunehmen. Sofern nicht durch Mehrheitsbeschluss der anwesenden Mitglieder des ccNSO Councils beschlossen wird, dass eine geschlossene Sitzung angemessen ist, kann Veranstaltungen von Interessierten persönlich beigewohnt werden. Soweit machbar sollten ccNSO Council-Sitzungen zusammen mit Sitzungen des Boards oder mit Sitzungen von einer oder mehreren sonstigen Supporting Organizations von ICANN stattfinden.
13. Zeit und Ort (sowie Informationen über die Teilnahmemethode, wenn die Teilnahme nicht persönlich erfolgt) aller Sitzungen des ccNSO Councils sind jedem ccNSO Council-Mitglied, -Vertreter und -Beobachter per E-Mail, Telefon, Fax oder als persönlich ausgehändigte oder postalisch versendete Mitteilung auf Papier mitzuteilen. Wenn die Mitteilung postalisch versendet wird, ist sie mindestens einundzwanzig (21) Tage vor dem Sitzungstermin abzusenden. Wenn die Mitteilung persönlich oder per Telefon, Fax oder E-Mail erfolgt, muss dies mindestens sieben (7) Tage vor dem Sitzungstermin geschehen. Spätestens sieben Tage vor jeder Sitzung des ccNSO Councils (zum frühestmöglichen Zeitpunkt) wird eine Mitteilung über die betreffende Sitzung und, soweit bekannt, die Tagesordnung der Sitzung veröffentlicht.
14. Mitglieder des ccNSO Councils sind berechtigt, durch persönliche Anwesenheit oder Verwendung elektronischer Kommunikation (wie Telefon- oder Videokonferenz) an einer Sitzung des ccNSO Councils teilzunehmen, sofern (a) alle Mitglieder des ccNSO Councils, die an der Sitzung teilnehmen, miteinander sprechen und einander hören können, (b) allen Mitgliedern des ccNSO Councils, die an der Sitzung teilnehmen, die Mittel für eine uneingeschränkte Beteiligung in allen Angelegenheiten zur Verfügung gestellt werden, die vom ccNSO Council erörtert werden, und (c) angemessene Methoden zur Verfügung stehen, um die Identität von Mitgliedern des ccNSO Councils, die an der Sitzung teilnehmen, und deren Stimmberechtigung zu überprüfen. Eine Mehrheit der sich im Amt befindlichen Mitglieder des ccNSO Councils (d. h. der stimmberechtigten Mitglieder) stellt ein Quorum für die Durchführung von Geschäften dar, und Beschlüsse einer Mehrheit der bei einer Sitzung, bei der ein Quorum gegeben ist, zu einem beliebigen Zeitpunkt anwesenden ccNSO Council-Mitglieder gelten als Beschlüsse des ccNSO Councils, sofern in diesen Statuten nichts Gegenteiliges vorgeschrieben ist. Der ccNSO Council hat ein Sitzungsprotokoll an den ICANN-Sekretär zu übermitteln, der nach Veranstaltungsschluss umgehend, jedoch nicht später als 21 Tage nach Veranstaltungsschluss, die Veröffentlichung dieses Protokolls auf der Website zu veranlassen hat.
1. Die Mitglieder des ccNSO sind ccTLD-Manager. ccTLD-Manager, die die in Absatz 2 dieses Abschnitts aufgeführten Mitgliedschaftskriterien erfüllen, sind berechtigt, Mitglied des ccNSO zu werden. Im Sinne dieses Artikels ist ein ccTLD-Manager die Organisation oder juristische Person, die für die Verwaltung einer länderspezifischen Top-Level-Domain nach ISO 3166 verantwortlich ist und in der IANA-Datenbank für diese länderspezifische Top-Level-Domain unter der aktuellen Überschrift "Sponsoring Organization" oder unter einer späteren Variante geführt wird.
2. Jeder ccTLD-Manager kann durch Einreichen eines Antrags bei einer Person, die vom ccNSO Council für den Erhalt von Anträgen angegeben wurde, ccNSO-Mitglied werden. Vorbehaltlich der Bestimmungen des Übergangsartikels dieser Statuten hat der Antrag schriftlich in einer vom ccNSO Council vorgegebenen Form zu erfolgen. Der Antrag hat die Anerkennung der Rolle der ccNSO innerhalb der ICANN-Struktur durch den ccTLD-Manager sowie die Verpflichtung des ccTLD-Managers für die Dauer der Mitgliedschaft in der ccNSO zu enthalten, (a) sich an die Vorschriften der ccNSO zu halten, einschließlich der Vorschriften für die Mitgliedschaft, (b) die Richtlinien, die von der ccNSO erarbeitet und empfohlen sowie vom Board verabschiedet wurden, in der in den Absätzen 10 und 11 dieses Abschnitts beschriebenen Weise einzuhalten und (c) die vom ccNSO Council gemäß Abschnitt 7(3) dieses Artikels festgelegten ccNSO-Mitgliedschaftsgebühren zu zahlen. Ein ccNSO-Mitglied kann jederzeit durch schriftliche Mitteilung an eine vom ccNSO Council für den Erhalt von Rücktrittserklärungen bestimmte Person von der Mitgliedschaft zurücktreten. Mit Rücktritt des ccTLD-Managers endet die Verpflichtung, (a) sich an die Vorschriften der ccNSO zu halten, einschließlich der Vorschriften für die Mitgliedschaft, (b) die Richtlinien, die von der ccNSO erarbeitet und empfohlen sowie vom Board verabschiedet wurden, in der in den Absätzen 10 und 11 dieses Abschnitts beschriebenen Weise einzuhalten und (c) die vom ccNSO Council gemäß Abschnitt 7(3) dieses Artikels festgelegten ccNSO-Mitgliedschaftsgebühren zu zahlen. Wenn der ccNSO Council keine Person für den Erhalt von Anträgen und Rücktrittserklärungen bestimmt hat, sind diese an den ICANN-Sekretär zu senden, der den ccNSO Council über den Erhalt eines solchen Antrags bzw. einer solchen Erklärung zu informieren hat.
3. Weder die Mitgliedschaft in der ccNSO noch die Mitgliedschaft in einer regionalen Organisation, die in Abschnitt 5 dieses Artikels beschrieben ist, darf Voraussetzung für den Zugriff auf oder die Anmeldung an der IANA-Datenbank sein. Jede einzelne Beziehung, die ein ccTLD-Manager zu ICANN hat, oder der Erhalt von IANA-Services durch den ccTLD-Manager ist in keiner Weise von der Mitgliedschaft in der ccNSO abhängig.
4. Die geografischen Regionen der ccTLDs haben den Angaben in Artikel VI, Abschnitt 5 dieser Statuten zu entsprechen. Im Sinne dieses Artikels werden Manager von ccTLDs innerhalb einer geografischen Region, die Mitglied der ccNSO sind, unabhängig vom physischen Standort des ccTLD-Managers als ccNSO-Mitglieder "innerhalb" der geografischen Region bezeichnet. Falls die geografische Region eines ccNSO-Mitglieds unklar ist, sollte das ccTLD-Mitglied in Übereinstimmung mit den vom ccNSO Council verabschiedeten Verfahren selbst eine Auswahl treffen.
5. Jeder ccTLD-Manager ist berechtigt, schriftlich eine Person, Organisation oder juristische Person als Vertretung des ccTLD-Managers zu bestimmen. Wurde keine solche Bestimmung vorgenommen, wird der ccTLD-Manager von der Person, Organisation oder juristischen Person vertreten, die in der IANA-Datenbank als Verwaltungskontaktperson angegeben ist.
6. Die ccNSO-Mitglieder haben eine Jahresversammlung abzuhalten, die vom ccNSO Council zu koordinieren ist. An Jahresversammlung sollten alle teilnehmen können, und ccTLD-Managern, die nicht Mitglied der ccNSO sind, sowie anderen, die nicht Nichtmitglied der ccNSO sind, sollte eine angemessene Gelegenheit gegeben werden, bei der Versammlung vorzusprechen. Soweit machbar sollten Jahresversammlungen der ccNSO-Mitglieder unter persönlicher Anwesenheit und zusammen mit Sitzungen des Boards oder mit Sitzungen von einer oder mehreren sonstigen Supporting Organizations von ICANN stattfinden.
7. Die von den ccNSO-Mitgliedern aus jeder geografischen Region (siehe Abschnitt 3(1)(a) dieses Artikels) ausgewählten Mitglieder des ccNSO Councils sind durch Nominierung auszuwählen, und, sofern eine Wahl erforderlich ist, von den ccNSO-Mitgliedern innerhalb dieser Region zu wählen. Mindestens 90 Tage vor Ende der regulären Amtszeit eines von ccNSO-Mitgliedern ausgewählten Mitglieds des ccNSO Councils oder nach Freiwerden eines Sitzes eines solchen Mitglieds des ccNSO Councils hat der ccNSO Council einen Nominierungs- und Wählplan aufzustellen, der an alle ccNSO-Mitglieder innerhalb der geografischen Region zu senden und auf der Website zu veröffentlichen ist.
8. Jedes ccNSO-Mitglied ist berechtigt, eine Person als Mitglied des ccNSO Councils zu nominieren, das die geografische Region des ccNSO-Mitglieds vertritt. Nominierungen müssen von einem weiteren ccNSO-Mitglied aus derselben geografischen Region unterstützt werden. Durch Annahme ihrer Nominierung verpflichten sich vom ccNSO Council nominierte Personen, die Richtlinien zu unterstützen, zu denen sich ccNSO-Mitglieder verpflichtet haben.
9. Wenn bei Abschluss der Nominierungen in einer bestimmten geografischen Region nicht mehr Kandidaten nominiert sind (inklusive Unterstützung durch ein weiteres Mitglied und Annahme der Nominierung) als im ccNSO Council Sitze für diese geografische Region vorhanden sind, dann werden die nominierten Kandidaten in den ccNSO Council gewählt. Andernfalls ist eine schriftliche Wahl (die per E-Mail erfolgen kann) durchzuführen, um die Mitglieder des ccNSO Councils unter den Nominierten (inklusive Unterstützung durch ein weiteres Mitglied und Annahme der Nominierung) auszuwählen, wobei ccNSO-Mitglieder aus der geografischen Region berechtigt sind, durch ihre ernannten Vertreter an der Abstimmung teilzunehmen. Bei einer solchen Wahl stellt die Mehrheit aller stimmberechtigten ccNSO-Mitglieder in der geografischen Region ein Quorum dar, und der ausgewählte Kandidat muss die Mehrheit der von ccNSO-Mitgliedern innerhalb der geografischen Region abgegebenen Stimmen erhalten. Der Vorsitzende des ccNSO Councils hat den ICANN-Sekretär unverzüglich schriftlich über die Auswahl von Mitgliedern des ccNSO Councils in Übereinstimmung mit diesem Absatz zu informieren.
10. Vorbehaltlich Klausel 4(11) gelten ICANN-Richtlinien für ccNSO-Mitglieder aufgrund ihrer Mitgliedschaft insoweit und nur insoweit die Richtlinien (a) nur Themen betreffen, die innerhalb des Aufgabenbereichs der ccNSO gemäß Artikel IX, Abschnitt 6 und Anhang C fallen, (b) durch den ccPDP, wie in Abschnitt 6 dieses Artikels beschrieben, entwickelt wurden und (c) als solche dem Board von der ccNSO empfohlen wurden und (d) vom Board als Richtlinien verabschiedet werden, sofern diese Richtlinien nicht im Widerspruch zu dem für den ccTLD-Manager geltenden Recht stehen, welches jederzeit Vorrang hat. Darüber hinaus gelten diese Richtlinien für ICANN bei den Aktivitäten im Zusammenhang mit ccTLDs.
11. Ein ccNSO-Mitglied ist nicht gebunden, wenn er dem ccNSO Council eine Erklärung vorlegt, die besagt, dass (a) die Umsetzung der Richtlinie das Mitglied dazu zwingen würde, gegen Gebräuche, Religion oder die guten Sitten (nicht im geltenden Recht enthalten, das in Absatz 10 dieses Abschnitts beschrieben ist) zu verstoßen, und dass (b) die Nichtumsetzung der Richtlinie den DNS-Betrieb oder die DNS-Interoperabilität nicht beeinträchtigen würde, wobei detaillierte Erläuterungen zur Untermauerung dieser Aussagen anzugeben sind. Nach einer Prüfung wird der ccNSO Council zur Erklärung des ccNSO-Mitglieds Stellung nehmen. Wenn der ccNSO Council die Erklärung einstimmig ablehnt, was mit einer Abstimmung von mindestens 14 Mitgliedern des ccNSO Councils demonstriert werden kann, ist in der Stellungnahme die Ablehnung der Erklärung durch den ccNSO Council unter Angabe der Gründe für die Ablehnung zu erklären. Andernfalls ist in der Stellungnahme zu erklären, dass der ccNSO Council mit der Erklärung einverstanden ist. Wenn der ccNSO Council nicht einverstanden ist, hat der ccNSO Council die Situation nach einem Zeitraum von sechs Monaten erneut zu prüfen. Am Ende dieses Zeitraums hat der ccNSO Council zu Ergebnissen zu gelangen, was die Fragen angeht, (a) ob die Umsetzung der Richtlinie durch die ccNSO-Mitglieder das Mitglied dazu zwingen würde, gegen Gebräuche, Religion oder die guten Sitten (nicht im geltenden Recht enthalten, das in Absatz 10 dieses Abschnitts beschrieben ist) zu verstoßen, und (b) ob die Nichtumsetzung der Richtlinie den DNS-Betrieb oder die DNS-Interoperabilität nicht beeinträchtigen würde. Bei der Suche nach Ergebnissen, die der Erklärung widersprechen, hat der ccNSO Council einstimmig vorzugehen, was mit einer Abstimmung von mindestens 14 Mitgliedern des ccNSO Councils demonstriert werden kann.
Abschnitt 5. REGIONALE ORGANISATIONEN
Der ccNSO Council ist berechtigt, für jede geografische Region von ICANN eine regionale Organisation zu bestimmen, sofern die regionale Organisation allen ccNSO-Mitgliedern innerhalb der geografischen Region für eine uneingeschränkte Mitgliedschaft offen steht. Für Entscheidungen zur Bestimmung oder zur Aufhebung der Bestimmung einer regionalen Organisation sind 66 % der Stimmen aller Mitglieder des ccNSO Councils erforderlich, und diese Entscheidungen sind den vom Board festgelegten Verfahren entsprechend zu prüfen.
Abschnitt 6. ccNSO-RICHTLINIENENTWICKLUNGSPROZESS UND -AUFGABENBEREICH
1. Der Aufgabenbereich der Richtlinienentwicklungsfunktion der ccNSO hat den Angaben in Anhang C dieser Statuten zu entsprechen; Änderungen am Aufgabenbereich sind dem Board von der ccNSO unter Anwendung der Verfahren des ccPDP zu empfehlen und müssen vom Board genehmigt werden.
2. Bei der Entwicklung globaler Richtlinien innerhalb des Aufgabenbereichs der ccNSO und deren Empfehlung an das Board hat die ccNSO den ccNSO-Richtlinienentwicklungsprozess (ccPDP) zu befolgen. Der ccPDP hat den Angaben in Anhang B dieser Statuten zu entsprechen. Änderungen sind dem Board von der ccNSO unter Anwendung der Verfahren des ccPDP zu empfehlen und müssen vom Board genehmigt werden.
Abschnitt 7. FINANZIERUNG UND UNTERSTÜTZUNG VON MITARBEITERN
1. Auf Anfrage des ccNSO Councils kann ein Mitglied des ICANN-Personals mit der Unterstützung des ccNSO beauftragt werden und ist in diesem Fall als ccNSO Staff Manager zu bezeichnen. Alternativ kann der ccNSO Council auf Kosten der ccNSO eine andere Person zum ccNSO Staff Manager ernennen. Die Arbeit des ccNSO Staff Managers an wesentlichen Themen ist vom Vorsitzenden des ccNSO Councils zuzuweisen und kann die Pflichten des ccPDP Issue Managers umfassen.
2. Auf Aufforderung des ccNSO Councils hat ICANN die nötige Verwaltungs- und Organisationsunterstützung bereitzustellen, die die ccNSO zur Erfüllung ihrer Pflichten benötigt. Die Unterstützung umfasst keine Verpflichtung seitens ICANN zur Finanzierung von Reisekosten, die den ccNSO-Teilnehmern für Reisen zu Veranstaltungen der ccNSO oder aus anderen Gründen entstehen. Der ccNSO Council kann zusätzlich oder als Alternative zur von ICANN bereitgestellten Unterstützung auf Kosten der ccNSO Verwaltungs- und Organisationsunterstützung bereitstellen.
3. Der ccNSO Council hat von ccNSO-Mitgliedern zu zahlende Gebühren festzulegen, um die ccNSO-Ausgaben, wie in Absatz 1 und 2 dieses Abschnitts beschrieben, umzulegen, wie von den ccNSO-Mitgliedern genehmigt.
4. Schriftliche Mitteilungen an den ICANN-Sekretär im Zusammenhang mit diesem Artikel sind dauerhaft aufzubewahren und dem ccNSO Council auf Verlangen zur Prüfung vorzulegen. Der ICANN-Sekretär hat außerdem die Liste der Mitglieder der ccNSO zu pflegen, die für jeden ccTLD-Manager den Namen seines benannten Vertreters enthält und die auf der Website zu veröffentlichen ist.
ARTIKEL X: GENERIC NAMES SUPPORTING ORGANIZATION
Ein Richtlinienentwicklungsorgan mit der Bezeichnung Generic Names Supporting Organization (GNSO) ist einzusetzen, das für die Entwicklung und Empfehlung von Strategien in Bezug auf generische Top-Level-Domains gegenüber dem ICANN-Board verantwortlich zeichnet.
Die GNSO setzt sich folgendermaßen zusammen:
(i) aus einer Anzahl von Bezirken, die gegebenenfalls in Interessengruppen organisiert sind, wie in Abschnitt 5 dieses Artikels beschrieben
(ii) aus vier Interessengruppen, organisiert in Häusern, wie in Abschnitt 5 dieses Artikels beschrieben
(iii) aus zwei Häusern innerhalb des GNSO Councils, wie in Abschnitt 3(8) dieses Artikels beschrieben und
(iv) aus einem GNSO Council, verantwortlich für die Verwaltung der Richtlinienentwicklung der GNSO, wie in Abschnitt 3 dieses Artikels beschrieben
Wenn nicht in diesen Statuten anderweitig definiert, sind die vier Interessengruppen und die Bezirke verantwortlich für die Definition ihrer eigenen Satzungen, die von ihren Mitgliedern und den Direktoren des ICANN-Boards genehmigt werden.
1. Nach den Bestimmungen von Übergangsartikel XX, Abschnitt 5 dieser Statuten und wie beschrieben in Abschnitt 5 von Artikel X, setzt sich der GNSO Council folgendermaßen zusammen:
a. drei Vertretern, ausgewählt von der Registries-Interessengruppe
b. drei Vertretern, ausgewählt von der Registrars-Interessengruppe
c. sechs Vertretern, ausgewählt von der kommerziellen Interessengruppe
d. sechs Vertretern, ausgewählt von der nichtkommerziellen Interessengruppe und
e. drei Vertretern, ausgewählt vom ICANN Nominating Committee, von denen einer kein Stimmrecht besitzt, jedoch ansonsten die gleichen Rechte wie die anderen Mitglieder des GNSO Councils besitzt, z. B. Einbringen und Unterstützen von Anträgen und im Falle einer Wahl Fungieren als Vorsitzender. Ein vom Nominating Committee ernannter stimmberechtigter Vertreter wird vom Nominating Committee jedem Haus zugewiesen (wie in Abschnitt 3(8) dieses Artikels beschrieben).
Kein einzelner Vertreter darf im GNSO Council zur gleichen Zeit mehrere Sitze besetzen.
Interessengruppen sollen in ihren Satzungen sicherstellen, dass ihre Vertreter im GNSO Council so vielseitig wie möglich sind, dies gilt in Bezug auf Geografie, GNSO-Bezirk, Sektor, Fähigkeit und Geschlecht.
Im GNSO Council können zeitweilig auch Vertreter aus anderen ICANN Supporting Organizations und/oder Advisory Committees vertreten sein. Die ernennende Organisation teilt die Ernennung, Zurückziehung oder Änderungen ihres Vertreters im GNSO Council dem Vorsitzenden des GNSO Councils und dem ICANN-Sekretär schriftliche mit. Vertreter sind keine Mitglieder des GNSO Councils und haben in diesem Organ kein Stimmrecht, dürfen keine Anträge einbringen oder unterstützen oder im GNSO Council als Officer fungieren, können sich jedoch ansonsten gleichberechtigt mit den Mitgliedern des GNSO Councils beteiligen.
2. Nach den Bestimmungen des Übergangsartikels XX, und Abschnitt 5 dieser Statuten beginnt die reguläre Amtszeit aller GNSO Council-Mitglieder zum Abschluss einer ICANN-Jahresversammlung und endet mit dem Abschluss der zweiten auf diese folgenden ICANN-Jahresversammlung. Die reguläre Amtszeit von zwei durch Interessengruppen mit drei Council-Sitzen gewählten Vertretern beginnt in einem Jahr mit gerader Jahreszahl und die reguläre Amtszeit des jeweils anderen durch die Interessengruppe gewählten Vertreters in einem Jahr mit ungerader Jahreszahl. Die reguläre Amtszeit von drei durch Interessengruppen mit sechs Council-Sitzen gewählten Vertretern beginnt in einem Jahr mit gerader Jahreszahl und die reguläre Amtszeit der drei anderen durch die Interessengruppe gewählten Vertreter in einem Jahr mit ungerader Jahreszahl. Die reguläre Amtszeit eines der drei durch das Nominating Committee gewählten Mitglieder beginnt in einem Jahr mit gerader Jahreszahl und die reguläre Amtszeit der übrigen zwei der drei durch das Nominating Committee gewählten Mitglieder in einem Jahr mit ungerader Jahreszahl. Jedes Mitglied des GNSO Councils bleibt bis zum Ende der regulären Amtszeit im Amt bzw. bis zu dem Zeitpunkt, zu dem ein geeigneter Nachfolger gewählt worden ist, dieses Mitglied zurücktritt oder im Einklang mit diesen Statuten aus dem Amt entlassen wird.
Mit Ausnahme des Vorliegens „besonderer Umstände“, wie, jedoch nicht ausschließlich, wenn geografische oder sonstige durch die Satzung der Interessengruppe festgelegte Anforderungen an die Vielfalt nicht erfüllt werden können, und kein alternativer Vertreter zur Verfügung steht, darf kein Council-Mitglied für zwei aufeinanderfolgende Amtszeiten gewählt werden. Bei Vorliegen von besonderen Umständen ist eine weitere Amtszeit möglich. Zu diesem Zweck gilt, dass einer Person, die zur Besetzung eines freien Mandates ausgewählt wird, diese Amtszeit nicht als abgeleistet angerechnet wird. Ehemalige Mitglieder des Councils, die zwei aufeinanderfolgende Amtszeiten ausgefüllt haben, haben eine vollständige Amtszeit auszusetzen, bevor sie für eine weitere Amtszeit als Mitglied des Councils tätig werden. „Besondere Umstände“ werden in den GNSO-Verfahrensweisen definiert.
3. Ein freier Sitz im GNSO Council existiert im Falle des Todes, Ausscheidens oder Entfernens eines Mitglieds. Freie Sitze werden für die verbleibende Amtszeit von dem entsprechenden Nominating Committee oder der Interessengruppe besetzt, das oder die das Mitglied, das den Sitz vor dem Freiwerden inne hatte, ausgewählt hatte, indem das GNSO-Sekretariat schriftlich über die Auswahl informiert wird. Verfahren für die Handhabung von freien Stellen, Rücktritten und Entlassungen von Mitgliedern des GNSO Council, die von Interessengruppen benannt wurden, werden in der entsprechenden Satzung der Interessengruppe dargelegt.
Ein vom Nominating Committee ausgewähltes Mitglied des GNSO Councils kann unter den folgenden Umständen entlassen werden: i) auf Entscheidung von Dreivierteln (3/4) aller Mitglieder des entsprechenden Hauses, dem das von dem Nominating Committee ernannte Mitglied zugeordnet ist; oder ii) auf Entscheidung von Dreivierteln (3/4) aller Mitglieder aller Häuser bei einem vom Nominating Committee ernannte Mitglied ohne Stimmrecht (siehe Abschnitt 3(8) dieses Artikels). Eine derartige Entlassung kann auf Antrag des entsprechenden Mitglieds des GNSO Councils durch das ICANN Board zurückgenommen werden.
4. Dem GNSO Council obliegt die Verwaltung des Richtlinienentwicklungsprozesses der GNSO. Es soll dabei die Verfahren anwenden (die „GNSO-Verfahrensweisen“), die es für die Umsetzung dieser Verantwortlichkeit als geeignet erachtet, vorausgesetzt, dass diese Verfahren von der Mehrheit eines jeden Hauses genehmigt wurden. Die GNSO-Verfahrensweisen treten nach dem Ablauf eines Zeitraums für die öffentliche Stellungnahme von einundzwanzig (21) Tagen in Kraft und unterliegen der Überwachung und Überprüfung durch das Board. Bis etwaige Veränderungen vom GNSO Council empfohlen werden, werden die gültigen Verfahren in Abschnitt 6 dieses Artikels dargelegt.
5. Höchstens ein Officer, Direktor oder Mitarbeiter einer bestimmten Organisation (einschließlich deren Tochtergesellschaften und verbundenen Gesellschaften) darf zu einer gegebenen Zeit ein Amt im GNSO Council innehaben.
6. Die GNSO nimmt die Auswahl zur Besetzung der Sitze 13 und 14 des ICANN Boards durch schriftliche Wahl oder Handlungen während einer Sitzung vor. Jedes der beiden wahlberechtigten Häuser der GNSO, wie erläutert in Abschnitt 3(8) dieses Artikels, nimmt eine Auswahl vor, um einen von zwei Sitzen im ICANN Board zu besetzen, wie unten dargelegt. Jede dieser Auswahlen muss die Zustimmung von sechzig Prozent (60 %) aller entsprechenden Mitglieder des wahlberechtigten Hauses erhalten:
a. das Haus der Vertragsparteien wählt einen Vertreter für Sitz 13 aus und
a. das Haus der Nichtvertragsparteien wählt einen Vertreter für Sitz 14 aus
Wahlverfahren werden in den GNSO-Verfahrensweisen definiert.
Der Vorsitzende des GNSO Councils hat den ICANN-Sekretär über die Besetzung des Boards-Sitzes schriftlich zu informieren sowie in Übereinstimmung mit Artikel VI, Abschnitt 8(4) und 12(1).
7. Der GNSO Council wählt den GNSO-Vorsitzenden für eine vom GNSO Council festgelegte Amtszeit, die ein Jahr jedoch nicht überschreiten darf. Jedes Haus (wie in Abschnitt 3.8 dieses Artikels erläutert) wählt einen stellvertretenden Vorsitzenden für das gesamte GNSO Council für eine vom GNSO Council festgelegte Amtszeit, die ein Jahr jedoch nicht überschreiten darf. Die Verfahren für die Wahl des Vorsitzenden und aller anderen Officer werden in den GNSO-Verfahrensweisen dargelegt. Für den Fall, dass der GNSO Council zum Ende der Amtszeit des vorherigen Vorsitzenden keinen GNSO-Vorsitzenden gewählt hat, fungieren die stellvertretenden Vorsitzenden als vorläufige Ko-Vorsitzende, bis eine erfolgreiche Wahl stattgefunden hat.
8. Wenn durch diese Statuten nicht anderweitig festgelegt, wird der GNSO Council (siehe Abschnitt 3(1) dieses Artikels) für Wahlverfahren als Zweikammernhaus organisiert, wie im Anschluss erläutert:
a. das Haus der Vertragsparteien umfasst die Registries-Interessengruppe (drei Mitglieder), die Registrars-Interessengruppe (drei Mitglieder) und ein vom ICANN Nominating Committee benanntes stimmberechtigtes Mitglied, somit insgesamt sieben stimmberechtigte Mitglieder
b. das Haus der Nichtvertragsparteien umfasst die kommerzielle Interessengruppe (sechs Mitglieder), die nichtkommerzielle Interessengruppe (sechs Mitglieder) und ein vom ICANN Nominating Committee für dieses Haus benanntes stimmberechtigtes Mitglied, somit insgesamt dreizehn stimmberechtigte Mitglieder
Wenn nicht durch diese Statuten anderweitig festgelegt, ist jedes Mitglied eines stimmberechtigten Hauses zur Abgabe einer Stimme pro Abstimmung berechtigt.
9. Wenn nicht durch diese Statuten, Anhang A hierzu, oder die GNSO-Verfahrensweisen anderweitig festgelegt, gilt ein Antrag oder ein anderer Wahlvorgang durch den GNSO Council als angenommen, wenn er die einfache Mehrheit eines jeden Hauses erzielt. Die im Anschluss erläuterten Mehrheiten gelten für die folgenden GNSO-Handlungen:
a. Erstellen eines Problemberichts: erfordert die Zustimmung von mindestens 25 % eines jeden Hauses oder die Mehrheit eines Hauses
b. Initiieren eines Richtlinienentwicklungsprozesses (Policy Development Process, PDP) innerhalb des Aufgabenbereichs (wie in Anhang A erläutert): erfordert die Zustimmung von mindestens 33 % eines jeden Hauses oder von über 66 % eines Hauses
c. Initiieren eines PDP außerhalb des Aufgabenbereichs: erfordert die Zustimmung von mindestens 75 % eines jeden Hauses oder die Mehrheit des anderen Hauses („GSNO-Zweidrittelmehrheit“)
d. Genehmigung einer PDP-Empfehlung ohne GNSO-Zweidrittelmehrheit: erfordert die Zustimmung der Mehrheit eines jeden Hauses sowie die Unterstützung eines Mitglieds des GNSO Councils, das mindestens 3 der 4 Interessengruppen vertritt
e. Genehmigung einer PDP-Empfehlung mit GNSO-Zweidrittelmehrheit: erfordert die Zustimmung einer GNSO-Zweidrittelmehrheit und
f. Genehmigung einer PDP-Empfehlung, aus der sich neue Verpflichtungen für bestimmte Vertragsparteien ergeben: Wenn eine ICANN-Vertragsbestimmung festlegt, dass „eine Zweidrittelmehrheit des Councils“ für die Demonstration des Konsenses erforderlich ist, muss die GNSO-Zweidrittelmehrheit in Bezug auf jede Vertragspartei erzielt werden, die von dieser Vertragsbestimmung betroffen ist.
Abschnitt 4. FINANZIERUNG UND UNTERSTÜTZUNG VON MITARBEITERN
1. Ein Mitglied des ICANN-Personals ist mit der Unterstützung des GNSO zu beauftragen, dessen Arbeit an wesentlichen Themen von dem Vorsitzenden des GNSO Councils zuzuweisen ist und der die Bezeichnung GNSO-Staff Manager tragen soll.
2. ICANN hat die nötige Verwaltungs- und Organisationsunterstützung bereitzustellen, die die GNSO zur Erfüllung ihrer Pflichten benötigt. Die Unterstützung umfasst keine Verpflichtung seitens ICANN zur Finanzierung von Reisekosten, die den GNSO-Teilnehmern für Reisen zu Veranstaltungen der GNSO oder aus anderen Gründen entstehen. ICANN kann nach eigenem Ermessen und nach selbst festgelegten Richtlinien Reisekosten für GNSO-Teilnehmer erstatten.
Abschnitt 5. INTERESSENGRUPPEN
1. Die folgenden Interessengruppen werden hiermit gemäß der Bestimmungen von Übergangsartikel XX, Abschnitt 5 dieser Statuten als Vertreter einer bestimmten Gruppe oder eines oder mehrerer Bezirke von Interessengruppen anerkannt:
a. Registries-Interessengruppe, die sämtliche mit ICANN vertraglich verbundenen gTLD Registries repräsentieren;
b. Registrars-Interessengruppe, die sämtliche Registrars repräsentieren, die von ICANN anerkannt und mit dieser vertraglich verbunden sind;
c. kommerzielle Interessengruppe, die die gesamte Bandbreite großer und kleiner kommerzieller Körperschaften im Internet repräsentiert und
d. nichtkommerzielle Interessengruppe, die die gesamte Bandbreite nicht-gewerblicher Körperschaften im Internet repräsentiert
2. Jeder Interessengruppe wird in Übereinstimmung mit Abschnitt 3(1) dieses Artikels eine bestimmte Anzahl von Council-Sitzen zugewiesen.
3. Jede in Absatz 1 dieses Abschnitts genannte Interessengruppe und alle gegebenenfalls zugeordneten Bezirke werden vom ICANN Board anerkannt. Die Anerkennung durch das Board erfolgt in dem Maße, in dem die Körperschaft tatsächlich die globalen Interessen der Interessengemeinschaften, die sie zu repräsentieren vorgeben, repräsentieren sowie in dem Maße, wie diese bei ihren Aktivitäten im höchstmöglichen Umfang eine Kultur der Fairness pflegen. Satzungen von Interessengruppen und Bezirken können gemäß den Anordnungen des Boards regelmäßig überprüft werden.
4. Jede Gruppe aus natürlichen oder juristischen Personen ist berechtigt, das Board um Anerkennung als neuer oder eigenständiger Bezirk im Haus der Nichtvertragsparteien zu ersuchen. Diese Anträge müssen Folgendes enthalten:
a. eine detaillierte Erklärung, aus welchen Gründen das Hinzufügen eines solchen Bezirks die GNSO darin unterstützen wird, ihre Pflichten im Hinblick auf die Richtlinienentwicklung zu erfüllen
b. eine detaillierte Erklärung aus welchen Gründen der neue Bezirk geeignet ist, die Beteiligten, deren Vertretung er anstrebt, auf globaler Ebene angemessen zu vertreten
c. eine Empfehlung für die organisatorische Einordnung in einer bestimmten Interessengruppe und
d. eine vorgeschlagene Satzung, die den Prinzipien und Verfahren dieser Statuten entspricht
Jedes Gesuch in Bezug auf Anerkennung eines neues Bezirks und die entsprechende Satzung ist zur öffentlichen Diskussion zu stellen.
5. Das Board ist berechtigt, neue Bezirke, wie in Abschnitt 5(3) beschrieben, als Reaktion auf ein solches Gesuch oder aufgrund eigener Initiative zu schaffen, sofern es der Ansicht ist, dass ein solches Vorgehen dem Zweck von ICANN dienlich ist. Sollte das Board auf eigene Initiative hin tätig werden, hat es eine ausführliche Erklärung darüber abzugeben, warum eine solche Handlung notwendig oder zweckdienlich ist, sowie eine angemessene Frist für eine öffentliche Diskussion einzuräumen und darf ferner erst nach Durchsicht der eingegangenen Stellungnahmen einen abschließenden Entschluss über die Schaffung des betreffenden neuen Bezirks treffen. Wenn das Board ein Gesuch oder eine Empfehlung für einen neuen Bezirk zur öffentlichen Diskussion stellt, hat es stets den GNSO Council hierüber zu benachrichtigen und die Reaktion auf diese Benachrichtigung vor dem Ergreifen erster Maßnahmen abzuwarten und zu berücksichtigen.
Abschnitt 6. RICHTLINIENENTWICKLUNGSPROZESS
Die vom GNSO zu befolgenden Richtlinienentwicklungsprozesse sind in Anhang A dieser Statuten dargelegt. Diese Verfahren können jedoch gemäß Abschnitt 3(4) dieses Artikels ergänzt und überarbeitet werden.
ARTIKEL XI: ADVISORY COMMITTEES
Das Board darf ein oder mehrere Advisory Committees zusätzlich zu den in diesem Artikel aufgeführten einsetzen. Ein Advisory Committee kann sich wahlweise ausschließlich aus Direktoren, aus Direktoren und Nicht-Direktoren oder ausschließlich aus Nicht-Direktoren sowie aus nicht stimmberechtigten Mitgliedern oder Ersatzmitgliedern zusammensetzen. Advisory Committees haben keine Vertretungsvollmacht für ICANN, sondern berichten über ihre Ergebnisse und geben Empfehlungen an das Board.
Abschnitt 2. BESONDERE ADVISORY COMMITTEES
Es müssen zumindest die folgenden Advisory Committees eingesetzt sein:
1. Governmental Advisory Committee
a. Das Governmental Advisory Committee hat Empfehlungen zu den Aktivitäten von ICANN im Zusammenhang mit den Interessen von Regierungen zu erarbeiten und auszusprechen, insbesondere im Falle von Angelegenheiten, bei denen ICANN-Prinzipien nicht mit einzelnen gesetzlichen Vorschriften und internationalen Abkommen vereinbar sind oder öffentliche Belange beeinträchtigt werden.
b. Die Mitgliedschaft im Governmental Advisory Committee steht allen nationalen Regierungen offen. Ferner steht die Mitgliedschaft bestimmten in internationalen Foren anerkannten Volkswirtschaften (Distinct Economies) sowie multinationalen Regierungsorganisationen und Bündnissen auf Einladung des Vorsitzenden des Governmental Advisory Committees offen.
c. Das Governmental Advisory Committee darf eine eigene Satzung oder Geschäftsordnung und eigene Prozesse zur Geschäftsführung festlegen, die jeweils auf der Website zu veröffentlichen sind.
d. Der Vorsitzende des Governmental Advisory Committees wird von den Mitgliedern des Governmental Advisory Committees gemäß den von den Mitgliedern bestimmten Verfahren gewählt.
e. Jedes Mitglied des Governmental Advisory Committees hat einen akkreditierten Vertreter im Committee zu ernennen. Der akkreditierte Vertreter eines Mitglieds muss eine formale und offizielle Position in der öffentlichen Administration des Mitglieds innehaben. Der Begriff "Amtsperson" bezeichnet eine Person, die ein gewähltes behördliches Amt innehat oder von einer solchen Regierungsbehörde, öffentlichen Behörde oder multinationalen Regierungsorganisation oder Bündnis beschäftigt wird und deren Hauptaufgabe bei einer solchen Regierungsbehörde, öffentlichen Behörde oder multinationalen Regierungsorganisation oder Bündnis darin besteht, staatliche oder öffentliche politische Grundsätze zu entwickeln oder zu beeinflussen.
f. Das Governmental Advisory Committee hat jährlich einen nicht-stimmberechtigten Vertreter in das ICANN-Board of Directors (erneute Wahl möglich) und jährlich einen nicht-stimmberechtigten Vertreter ins ICANN-Nominating Committee zu wählen.
g. Das Governmental Advisory Committee kann einen nicht-stimmberechtigten Vertreter in jedem der Supporting Organization Councils und Advisory Committees bestimmen, solange das Governmental Advisory Committee dies als geeignete und zweckdienliche Maßnahme erachtet.
h. Das Board hat den Vorsitzenden des Governmental Advisory Committees zeitnah über Vorschläge zu öffentlichen Belangen zu benachrichtigen, zu denen auf dessen Wunsch oder den Wunsch einer der Supporting Organizations oder Advisory Committees von ICANN Stellungnahmen eingeholt werden sollen, und ferner die zeitnahe Reaktion auf diese Benachrichtigung vor Tätigwerden zu berücksichtigen.
i. Das Governmental Advisory Committee kann unmittelbar Einfluss auf das Board nehmen, etwa auf dem Wege der Kommentierung, der vorherigen Empfehlung oder der Aufforderung, bestimmte Handlungen durchzuführen, neue Richtlinienentwicklungen zu fördern oder bestehende Strategien zu überarbeiten.
j. Die Empfehlung des Governmental Advisory Committees in Bezug auf öffentliche Belange ist bei der Ausformulierung sowie der Anpassung von Strategien zu berücksichtigen. Sollte das ICANN-Board beschließen, eine Handlung vorzunehmen, die nicht mit der Empfehlung des Governmental Advisory Committees im Einklang steht, hat es das Committee hierüber zu informieren und darüber hinaus die Gründe für die Missachtung der Empfehlung zu erläutern. Das Governmental Advisory Committee und das ICANN-Board werden dann versuchen, in gutem Glauben und auf effiziente Art und Weise eine beidseitig akzeptable Lösung zu erarbeiten.
k. Kann eine solche Lösung nicht erarbeitet werden, hat das ICANN-Board in seinem abschließenden Beschluss die Gründe dafür aufzuführen, warum der Empfehlung des Governmental Advisory Committees nicht Folge geleistet worden ist, wobei solche Gründe die Rechte und Pflichten der Mitglieder des Governmental Advisory Committees in Bezug auf öffentliche Belange, die in deren Verantwortungsbereich fallen, nicht berühren.
2. Security and Stability Advisory Committee
a. Aufgabe des Security and Stability Advisory Committees („SSAC“) ist es, der ICANN-Community und dem ICANN-Board in Bezug auf die Sicherheit und Integrität der Internetzuweisungssysteme für Benennungen und Adressen mit Empfehlungen zur Seite zu stehen. Ihm obliegen folgende Pflichten:
1. Die Kommunikation in Bezug auf Sicherheitsaspekte mit Anbietern und Betreibern von Internettechnik und wichtigen DNS-Infrastrukturdiensten sowie die Einbeziehung der Betreiber von Rootnameservern, der Top-Level-Domain Registries und Registrars, der Betreiber der Reverse Delegation Trees, wie etwa in-addr.arpa und ip6.arpa, und gegebenenfalls weiterer Organisationen. Das Committee hat Anforderungen für diejenigen zusammenzustellen und zu artikulieren, die in der technischen Überarbeitung der Protokolle in Bezug auf DNS und Adresszuweisung sowie in der Ablaufplanung engagiert sind.
2. Die Vornahme von fortlaufender Bedrohungsbewertung und Risikoanalyse in Bezug auf Zuweisungsdienste für Internetbenennungen und –adressen, die Bewertung der grundlegenden Bedrohungen für Stabilität und Sicherheit sowie die entsprechende Beratung der ICANN-Community. Das Committee hat notwendige Auditaktivitäten vorzuschlagen, um den gegenwärtigen Status von DNS- und Adresszuweisungssicherheit im Verhältnis zur Identifikation von Risiken und Bedrohungen beurteilen zu können.
3. Die Kommunikation mit den Verantwortlichen für Sicherheitsbelange der Zuweisungsdienste für Internetbenennungen und –adressen (IETF, RSSAC, RIRs, Name Registries usw.), die Sicherstellung, dass abgegebene Empfehlungen über Sicherheitsrisiken, -probleme und -prioritäten im Einklang stehen mit vorhandenen Standardisierungs-, Bereitstellungs-, Betriebs- und Koordinierungsmaßnahmen. Das Committee hat diese Maßnahmen zu überwachen und die ICANN-Community und das ICANN-Board über etwaige Fortschritte zu informieren.
4. Die regelmäßige Berichterstattung gegenüber dem Board in Bezug auf dessen Aktivitäten.
5. Die Abgabe von Empfehlungen an die ICANN-Community und das Board.
b. Der Vorsitzende und die Mitglieder des SSAC werden vom Board ernannt. Die Ernennung für die SSAC-Mitgliedschaft erfolgt für eine Amtszeit von drei Jahren. Diese beginnt am 1. Januar und endet am 2. darauffolgenden Jahr am 31. Dezember. Der Vorsitzende und die Mitglieder können erneut ernannt werden, und es bestehen keine Beschränkungen bezüglich der Amtszeiten des Vorsitzenden und der Mitglieder. Der SSAC-Vorsitzende kann dem Board Empfehlungen bezüglich Ernennungen für das SSAC aussprechen. Der SSAC-Vorsitzende soll die Empfehlungen für die Ernennungen gestaffelt aussprechen, damit etwa ein Drittel (1/3) der Mitgliedschaft des SSAC jedes Jahr für die Empfehlung oder erneute Empfehlung ansteht. Das Board ist darüber hinaus berechtigt, SSAC-Mitglieder auf Empfehlung des oder in Abstimmung mit dem SSAC zu entlassen. (Hinweis: Die erste vollständige Amtszeit gemäß dieses Absatzes beginnt am 1. Januar 2011 und endet am 31. Dezember 2013. Vor dem 1. Januar 2011 setzt sich das SSAC gemäß den Statuten mit den Änderungen vom 25. Juni 2010 zusammen, und der SSAC-Vorsitzende soll die erneute Ernennung aller aktuellen SSAC-Mitglieder für vollständige oder anteilige Amtszeiten vorschlagen, um die Bestimmungen dieses Absatzes umzusetzen.)
c. Im jährlichen Turnus ernennt das SSAC einen nicht stimmberechtigten Board-Vertreter, und zwar nach Maßgabe des Abschnitts 9 von Artikel VI.
3. Root Server System Advisory Committee
a. Die Aufgabe des Root Server System Advisory Committees ("RSSAC") besteht in der Abgabe von Empfehlungen gegenüber dem Board in Bezug auf den Betrieb des Rootnameservers des Domainnamensystems. Das RSSAC hat Empfehlungen zu den Betriebsanforderungen des Rootnameservers, einschließlich Hardwarekapazitäten, Versionen von Betriebssystem und Nameserversoftware, Netzwerkkonnektivität und physische Umgebung abzugeben. Ferner hat das RSSAC Sicherheitsaspekte des Rootnameserversystems zu untersuchen und hierzu Empfehlungen abzugeben. Darüber hinaus hat das RSSAC die Anzahl, den Aufstellort und die Verteilung von Rootnameservern zu prüfen und dabei stets die Leistung, Stabilität und Verlässlichkeit des Gesamtsystems zu berücksichtigen.
b. Mitglieder des RSSAC sind (i) die Betreiber von maßgeblichen Rootnameservern (wie unter <ftp://ftp.internic.net/domain/named.root> aufgeführt) sowie (ii) andere vom ICANN-Board ernannte Personen.
c. Der erste Vorsitzende des DNS Root Server System Advisory Committees ist vom Board zu ernennen; dessen Nachfolger sind gemäß den von den Mitgliedern festgelegten Prozeduren von den Mitgliedern des DNS Root Server System Advisory Committees zu wählen.
d. Das Root Server System Advisory Committee hat jährlich einen nicht-stimmberechtigten Vertreter in das ICANN-Board of Directors (erneute Wahl möglich) und jährlich einen nicht-stimmberechtigten Vertreter ins ICANN-Nominating Committee zu wählen.
4. At-Large Advisory Committee
a. Das At-Large Advisory Committee (ALAC) ist die wichtigste Organisationseinheit für individuelle Internetbenutzer innerhalb von ICANN. Das ALAC ist für Überlegungen und Beratungstätigkeiten in Bezug auf die Aktivitäten von ICANN verantwortlich, die im Zusammenhang mit den Interessen einzelner Internet-Benutzer stehen. Dies umfasst durch Supporting Organizations von ICANN erstellte Richtlinien sowie zahlreiche andere Probleme, für die Rückmeldungen und Ratschläge von der Community empfehlenswert sind. Das ALAC, das eine wichtige Rolle bei den Mechanismen für die Rechenschaftspflicht spielt, koordiniert zudem einige der Angebote von ICANN für einzelne Internetbenutzer.
b. Das ALAC besteht aus (i) zwei Mitgliedern, die von den jeweiligen Regional At-Large Organizations ("RALOs") gewählt werden, die gemäß Absatz 4(g) dieses Abschnitts eingesetzt werden sowie (ii) aus fünf Mitgliedern, die durch das Nominating Committee gewählt werden. Unter den fünf Mitgliedern, die durch das Nominating Committee gewählt werden, muss sich ein Staatsbürger eines jeweiligen Landes innerhalb der fünf geografischen Regionen befinden, die gemäß Abschnitt 5 von Artikel VI definiert werden.
c. Vorbehaltlich der Bestimmungen des Übergangsartikels dieser Statuten sind die regulären Bestimmungen in Bezug auf Mitglieder des ALAC wie folgt:
1. Die Amtszeit eines durch eine RALO gewählten Mitglieds beginnt mit Abschluss der ICANN-Jahresversammlung in einem Jahr mit gerader Jahreszahl.
2. Die Amtszeit des anderen durch eine RALO gewählten Mitglieds beginnt mit Abschluss der ICANN-Jahresversammlung in einem Jahr mit ungerader Jahreszahl.
3. Die Amtszeit der drei durch das Nominating Committee gewählten Mitglieder beginnt mit Abschluss einer Jahresversammlung in einem Jahr mit ungerader Jahreszahl, und die Amtszeit der anderen zwei durch das Nominating Committee gewählten Mitglieder beginnt mit Abschluss der Jahresversammlung in einem Jahr mit gerader Jahreszahl.
4. Für jedes Mitglied endet die reguläre Amtszeit bei Abschluss der zweiten ICANN-Jahresversammlung nach Beginn der Amtszeit.
d. Der Vorsitzende des ALAC wird von den Mitgliedern des ALAC gemäß den vom Committee bestimmten Verfahren gewählt.
e. Das ALAC ernennt nach Abstimmung mit jedem RALO jährlich fünf stimmberechtigte Vertreter für das Nominating Committee, die Staatsbürger von Ländern aus unterschiedlichen geografischen Regionen sein müssen, wie in Abschnitt 5 von Artikel VI definiert ist.
f. Vorbehaltlich der Bestimmungen des Übergangsartikels dieser Statuten darf das At-Large Advisory Committee nicht stimmberechtigte Vertreter für den ccNSO Council und den GNSO Council ernennen.
g. Es ist gemäß Abschnitt 5 von Artikel VI eine RALO für jede geografische Region einzusetzen. Jede RALO dient der ICANN in ihrer geografischen Region als Hauptforum und Koordinierungspunkt für öffentliche Beteiligungen und ist eine gemeinnützige Organisation, die durch ICANN gemäß den Kriterien und Standards, wie sie basierend auf den Empfehlungen des At-Large Advisory Committee durch das Board aufgestellt worden sind, zertifiziert ist. Eine Organisation wird nach Verabschiedung eines Memorandum of Understanding mit der ICANN als RALO für eine geografische Region anerkannt, das die spezifischen Aufgaben und Pflichten der ICANN und der RALO in Bezug auf den Prozess der Auswahl von ALAC-Mitgliedern und die Anforderungen an Offenheit, Beteiligungsmöglichkeiten, Transparenz, Rechenschaftspflicht und Diversifizität in den Strukturen und Prozessen der RALO sowie den Kriterien und Standards für die konstituierenden At-Large-Strukturen der RALOs beschreibt.
h. Jede RALO besteht innerhalb ihrer geografischen Region aus sich selbst tragenden At-Large-Strukturen, die die Anforderungen des Memorandum of Understanding mit ICANN gemäß Absatz 4(i) dieses Abschnitts erfüllen und als solche zertifiziert sind. Sofern dies im Memorandum of Understanding mit ICANN so vorgesehen ist, darf eine RALO auch einzelne Internetbenutzer einbeziehen, die Staatsbürger von Ländern innerhalb der geografischen Region der RALO sind bzw. in diesen Ländern wohnhaft sind.
i. Mitgliedschaft in der At-Large-Community
- Die Kriterien und Standards für die Zertifizierung von At-Large-Strukturen innerhalb jeder geografischen Region werden vom Board auf der Grundlage der Empfehlungen des ALAC festgelegt und im Memorandum of Understanding zwischen ICANN und der RALO für jede geografische Region niedergeschrieben.
- Die Kriterien und Standards für die Zertifizierung von At-Large-Strukturen sind in einer Weise einzurichten, dass die Beteiligung einzelner Internetbenutzer, die Staatsbürger der Länder innerhalb der geografischen Region (wie in Abschnitt 5 von Artikel VI definiert) der RALO bzw. in diesen Ländern wohnhaft sind, in den Arbeitsabläufen jeder At-Large-Struktur innerhalb der RALO überwiegt. Dies schließt jedoch nicht unbedingt die zusätzliche Beteiligung anderer aus, die mit den Interessen der einzelnen Internet-Benutzer innerhalb der Region vereinbar ist.
- Das Memorandum of Understanding jeder RALO enthält auch Bestimmungen, die es jedem einzelnen Internetbenutzer, der Staatsbürger eines Landes innerhalb der geografischen Region der RALO bzw. in einem dieser Länder wohnhaft ist, im größtmöglichen Umfang ermöglichen, in mindestens einer At-Large-Struktur der RALO mitzuwirken.
- In einem mit diesen Zielen vereinbaren Maß sollten die Kriterien und Standards jeder RALO auch die Art von Struktur ermöglichen, die den Gewohnheiten und dem Charakter ihrer geografischen Region am besten entspricht.
- Sobald die Kriterien und Standards wie in Absatz i vorgesehen festgelegt wurden, ist das ALAC unter Beratung mit und Beteiligung der für das Land des Antragstellers zuständigen RALO für die Zertifizierung von Organisationen als kriterien- und standardkonform in Bezug auf die Akkreditierung von At-Large-Strukturen zuständig.
- Entscheidungen über die Zertifizierung oder Dezertifizierung einer At-Large-Struktur werden auf der Grundlage der vom ALAC in seinen Verfahrensregeln festgelegten Vorgaben getroffen, wobei jegliche Änderungen der Verfahrensregeln in Bezug auf ALS-Anträge stets von den RALOs und vom ICANN-Board geprüft werden müssen.
- Entscheidungen bezüglich der Akkreditierung, Nichtakkreditierung oder Deakkreditierung einer At-Large-Struktur unterliegen der Prüfung gemäß den vom Board festgelegten Verfahren.
- Das ALAC kann des Weiteren fortlaufend Ratschläge dahingehend geben, ob eine potenzielle At-Large-Struktur die anwendbaren Kriterien und Standards erfüllt.
j. Das ALAC ist darüber hinaus in Zusammenarbeit mit den RALOs für die Koordination der folgenden Aktivitäten verantwortlich:
1. Auswahl des At-Large Communitys zur Besetzung von Sitz 15 des Boards. Die Benachrichtigung über die Wahl des At-Large Communitys erfolgt in Übereinstimmung mit Artikel VI, Abschnitte 8(4) und 12(1) schriftlich durch den ALAC-Vorsitzenden an den ICANN-Sekretär.
2. Information der einzelnen Internetbenutzer über die wichtigen Neuigkeiten der ICANN
3. Verteilung (über Posting oder in anderer Weise) einer aktualisierten Agenda, Neuigkeiten zu ICANN und Informationen zu Elementen im ICANN-Richtlinienentwicklungsprozess
4. Förderung von Outreach-Aktivitäten in der Community der einzelnen Internetbenutzer
5. Entwicklung und Aufrechterhaltung der laufenden Informations- und Weiterbildungsprogramme bezüglich ICANN und ihrer Arbeiten
6. Einrichtung einer Outreach-Strategie zu ICANN-Themen in jeder RALO-Region
7. Teilnahme am ICANN-Richtlinienentwicklungsprozess und Bereitstellung von Rückmeldungen und Ratschlägen, die die Ansichten der einzelnen Internetbenutzer zuverlässig widerspiegeln
8. Bekanntgabe und Analyse der vorgeschlagenen Richtlinien und Entscheidungen von ICANN und deren (potenzieller) regionaler Auswirkungen und (potenzieller) Effekte auf einzelne Benutzer in der Region
9. Angebot internetbasierter Mechanismen, die Diskussionen zwischen Mitgliedern von At-Large-Strukturen ermöglichen
10 Einrichtung von Mechanismen und Prozessen, die eine Zwei-Wege-Kommunikation zwischen Mitgliedern von At-Large-Strukturen und den an der ICANN-Entscheidungsfindung Beteiligten ermöglichen, damit interessierte Personen ihre Ansichten zu offenen ICANN-Themen einbringen können
Jedes Advisory Committee legt seine eigenen Verfahrensregeln und Quorum-Anforderungen fest.
Der Vorsitzende und die Mitglieder eines Committees bleiben bis zur Ernennung ihres jeweiligen Nachfolgers im Amt oder, falls das betreffende Committee zuvor aufgelöst wird, bis zu diesem Zeitpunkt oder bis sie entlassen werden, zurücktreten oder aus anderen Gründen nicht länger Mitglieder des Committees sein können.
Frei gewordene Sitze in einem Committee werden in derselben Weise neu besetzt wie für den Fall der ursprünglichen Ernennung vorgesehen.
Die Mitglieder eines Committees erhalten für ihre Dienste als Mitglieder eines Committees keine Vergütung. Das Board ist jedoch berechtigt, die Erstattung tatsächlicher und notwendiger Ausgaben zu genehmigen, die den Mitgliedern eines Committees, einschließlich den Direktoren, bei der Erfüllung ihrer Pflichten als Mitglieder eines Committees entstehen.
ARTIKEL XI-A: SONSTIGE BERATUNGSMECHANISMEN
Abschnitt 1. RAT VON EXTERNEN FACHLEUTEN
1. Zweck Ratschläge von externen Fachleuten werden eingeholt, um den Richtlinienentwicklungsprozess innerhalb von ICANN auf Basis der im öffentlichen oder privaten Sektor, jedoch außerhalb von ICANN vorhandenen Fachkompetenz zu verbessern. In Fällen, wo relevante öffentliche Organisationen über Fachwissen verfügen oder wo der Zugang zu Fachwissen von Einzelpersonen hilfreich sein könnte, sind das Board und die konstituierenden Organe aufgefordert, Ratschläge von solchen Organisationen oder Einzelpersonen einzuholen.
2. Arten von Expert Advisory Panels.
a. Auf Eigeninitiative oder Vorschlag eines ICANN-Organs kann das Board Expert Advisory Panels (Fachberatergremien), denen Einzelpersonen oder Organisationen aus dem öffentlichen oder privaten Sektor angehören, einberufen oder den Präsidenten zur Einberufung solcher Expert Advisory Panels bevollmächtigen. Betreffen die Ratschläge solcher Panels Angelegenheiten von öffentlichem Belang, sind die Bestimmungen in Abschnitt 1(3)(b) dieses Artikels anzuwenden.
b. Darüber hinaus kann das Board in Übereinstimmung mit Abschnitt 1(3) dieses Artikels Angelegenheiten, die im Zusammenhang mit dem Zweck von ICANN stehen und öffentliche Belange betreffen, an eine multinationale Regierungsorganisation oder ein Bündnis weiterleiten.
3. Prozess zum Einholen von Ratschlägen zu Angelegenheiten von öffentlichem Belang.
a. Das Governmental Advisory Committee kann jederzeit empfehlen, dass das Board, wie oben beschrieben, von einer externen Quelle Ratschläge in Bezug auf Angelegenheiten von öffentlichem Belang einholt.
b. Sollte das Board nach einer solchen Empfehlung oder aus einem anderen Grund beschließen, dass externer Rat zu Angelegenheiten von öffentlichem Belang eingeholt werden soll, berät das Board, soweit erforderlich, gemeinsam mit dem Governmental Advisory Committee darüber, welche Quelle konsultiert und auf welche Weise der Rat eingeholt werden soll, einschließlich Umfang und Verfahren.
c. Das Board leitet, soweit erforderlich, sämtliche Anträge auf Beratung durch eine multinationale Regierungsorganisation oder ein Bündnis, einschließlich Angaben zum Aufgabenbereich, an das Governmental Advisory Committee weiter, mit dem Vorschlag, dass der Antrag auf Beratung vom Governmental Advisory Committee an die multinationale Regierungsorganisation oder das Bündnis übermittelt wird.
4. Prozess zum Einholen von Ratschlägen zu sonstigen Angelegenheiten. Jegliche Weiterleitung von Angelegenheiten, die nicht von öffentlichem Belang sind, an ein Expert Advisory Panel durch das Board oder den Präsidenten gemäß Abschnitt 1(2)(a) dieses Artikels erfolgt in Übereinstimmung mit der Beschreibung des Aufgabenbereichs, in der festgelegt ist, welche Beiträge und Ratschläge eingeholt, welche Verfahren angewendet und welche Pläne zugrunde gelegt werden.
5. Ratschläge und deren Auswirkungen. Externe Ratschläge nach den Bestimmungen dieses Abschnitts erfolgen in Schriftform. Diese Ratschläge sind unverbindlich und dienen als Ergänzung zu den verfügbaren Informationen, die das Board oder andere ICANN-Organe zur Erfüllung ihrer Pflichten benötigen.
6. Gelegenheit zur Stellungnahme. Das Governmental Advisory Committee hat zusätzlich zu den Supporting Organizations und anderen Advisory Committees die Gelegenheit, vor der Entscheidung des Boards eine Stellungnahme zu sämtlichen externen Ratschlägen abzugeben.
Abschnitt 2. TECHNICAL LIAISON GROUP
1. Zweck Die Qualität der Arbeit von ICANN hängt vom Zugang zu vollständigen und maßgeblichen Informationen in Bezug auf die technischen Standards, die den Aktivitäten von ICANN zugrunde liegen, ab. Die Beziehung zwischen ICANN und den Organisationen, die diese Standards entwickeln, spielt daher eine besonders große Rolle. Die Technical Liaison Group (TLG) sorgt dafür, dass dem Board geeignete Ressourcen für technische Ratschläge zu bestimmten Themen im Zusammenhang mit den Aktivitäten von ICANN zur Verfügung stehen.
2. TLG-Organisationen. Die TLG besteht aus vier Organisationen: dem European Telecommunications Standards Institute (ETSI), dem International Telecommunications Union's Telecommunication Standardization Sector (ITU-T), dem World Wide Web Consortium (W3C) und dem Internet Architecture Board (IAB).
3. Aufgabe Die Hauptaufgabe der TLG-Organisationen besteht darin, technische Informationen und Ratschläge an das Board und an andere ICANN-Organisationen weiterzuleiten. Diese Hauptaufgabe lässt sich in eine reaktive Komponente und eine aktive Komponente unterteilen, die folgende Aufgaben umfassen:
a. Als Reaktion auf eine Informationsanfrage sorgen die TLG-Organisationen dafür, dass dem Board oder einem anderen ICANN-Organ geeignete Ressourcen für technisches Fachwissen zur Verfügung stehen. Diese Komponente der TLG-Rolle kommt in Situationen zum Tragen, in denen ICANN eine verlässliche Antwort auf eine bestimmte technische Frage benötigt. Werden Informationen zu einem bestimmten technischen Standard angefragt, für den eine TLG-Organisation verantwortlich ist, so ist diese Anfrage an die betreffende TLG-Organisation zu richten.
b. Die aktive Komponente der TLG-Organisation besteht darin, das Board laufend über die Bedeutung und den Fortschritt technischer Entwicklungen in den Bereichen der jeweiligen Organisation zu informieren, die sich auf Entscheidungen des Boards oder andere ICANN-Maßnahmen auswirken könnten, und auf Angelegenheiten im Zusammenhang mit globalen technischen Standards aufmerksam zu machen, die sich auf die Richtlinienentwicklung innerhalb des Aufgabenbereichs von ICANN auswirken. Diese Komponente der TLG-Rolle kommt in Situationen zum Tragen, in denen ICANN über eine neue Entwicklung nicht informiert ist und daher nicht erkennt, dass eine Frage gestellt werden sollte.
4. TLG-Verfahren. Die TLG hat keine Vorstände, hält keine Veranstaltungen ab und gibt dem Board als Committee keinerlei Ratschläge zu Richtlinien (allerdings können TLG-Organisationen in Einzelfällen vom Board um Rat gebeten werden, wenn in den relevanten Bereichen ein entsprechender Bedarf entsteht). Ebenso wenig ist es der TLG gestattet, technische Angelegenheiten in ihren Organisationen zu besprechen oder zu koordinieren, einheitliche Positionen festzulegen bzw. dies zu versuchen oder zusätzliche Ebenen oder Strukturen innerhalb der TLG für die Entwicklung von technischen Standards oder zu einem anderen Zweck zu schaffen bzw. dies zu versuchen.
5. Technische Aufgaben der IANA. Die TLG ist in keiner Weise an der Arbeit der IANA für die Internet Engineering Task Force, die Internet Research Task Force oder das Internet Architecture Board beteiligt, wie in dem am 10. März 2000 vom Board gebilligten Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority (Memorandum of Understanding in Bezug auf die technischen Aufgaben der Internet Assigned Numbers Authority) dargelegt.
6. Technische Experten. Jede TLG-Organisation bestimmt zwei technische Experten, die mit den für ICANN-Aktivitäten relevanten Angelegenheiten in Bezug auf technische Standards vertraut sind. Diese insgesamt acht Experten stehen bei Bedarf zur Verfügung, um per Austausch von E-Mail-Nachrichten festzulegen, an wen eine technische Frage von ICANN gerichtet werden soll, falls sich ICANN nicht direkt an eine bestimmte TLG-Organisation wendet.
7. Vertreter im Board und Delegierter des Nominating Committees. Im jährlichen Turnus ernennt eine TLG-Organization gemäß Artikel VI, Abschnitt 9(1)(d) einen nicht stimmberechtigten Board-Vertreter. Im jährlichen Turnus wählt eine TLG-Organisation gemäß Artikel VII, Abschnitt 2(8)(j) einen stimmberechtigten Delegierten in das ICANN Nominating Committee. Die Reihenfolge für die Ernennung des nicht stimmberechtigten Board-Vertreters lautet ETSI, ITU-T, W3C. Die Reihenfolge für die Wahl des Delegierten in das Nominating Committee lautet W3C, ETSI, ITU-T. (IAB nimmt an diesen Turnussen nicht teil, da die IETF andernfalls einen nicht stimmberechtigten Board-Vertreter ernennt und einen Delegierten in das ICANN Nominating Committee wählt.)
ARTIKEL XII: BOARD UND TEMPORARY COMMITTEES
Das Board kann ein oder mehrere Board Committees einsetzen, die so lange fortbestehen, bis das Board etwas anderes bestimmt. In die Committees des Boards können nur Direktoren berufen werden. Wenn eine in ein Committee des Boards berufene Person nicht länger Direktor ist, kann diese Person auch nicht weiter in einem Committee des Boards vertreten sein. Jedes Committee des Boards besteht aus zwei oder mehr Direktoren. Das Board kann ein oder mehrere Direktoren als Ersatzmitglieder eines solchen Committees bestimmen, die berechtigt sind, abwesende Mitglieder bei Committee-Sitzungen zu vertreten. Die Mitglieder eines Committees können jederzeit mit einer Mehrheit von zwei Dritteln (2/3) der Stimmen aller Board-Mitglieder aus einem Committee entlassen werden, jedoch nur unter der Voraussetzung, dass der Direktor/die Direktoren, der/die entlassen werden soll(en), bei diesem Verfahren nicht stimmberechtigt ist/sind bzw. bei der Berechnung der erforderlichen Mehrheit von zwei Dritteln (2/3) der Stimmen nicht als Mitglieder des Boards mitgerechnet wird/werden, und unter der weiteren Voraussetzung, dass ein Direktor in keinem Fall aus einem Committee entlassen werden kann, sofern die Entlassung nicht von mindestens der Mehrheit aller Board-Mitglieder genehmigt wird.
Abschnitt 2. BEFUGNISSE DER BOARD COMMITTEES
1. Das Board kann sämtliche rechtlichen Befugnisse auf die Committees des Boards übertragen, mit Ausnahme der folgenden Angelegenheiten:
a. Besetzung frei gewordener Stellen im Board oder in einem Committee;
b. Änderung oder Aufhebung der Statuten oder der Gesellschaftssatzung oder Annahme neuer Statuten oder einer neuen Gesellschaftssatzung;
c. Änderung oder Aufhebung eines Beschlusses des Boards, der nach seinem ausdrücklichen Wortlaut nicht in dieser Weise abgeändert oder aufgehoben werden darf;
d. Einsetzung von Committees des Boards und Bestellung der jeweiligen Mitglieder;
e. Genehmigung von In-sich-Geschäften gemäß der Definition in Abschnitt 5233(a) des CNPBCL;
f. Genehmigung des Jahresbudgets gemäß den Bestimmungen von Artikel XVI; oder
g. Vergütung der Officer gemäß Artikel XIII.
2. Das Board ist berechtigt, vorzuschreiben, in welcher Art und Weise die Vorgänge in einem Committee des Boards durchzuführen sind. Sofern keine diesbezüglichen Vorschriften vorliegen, ist das jeweilige Committee berechtigt, die Art und Weise, in der die Vorgänge durchzuführen sind, selbst festzulegen. Sofern diese Statuten, das Board oder die Committees nichts Anderweitiges festgelegt haben, unterliegen die regelmäßigen Sitzungen und die Sondersitzungen den Bestimmungen des Artikels VI in Bezug auf die Sitzungen und Handlungen des Boards. Jedes Committee hat regelmäßig über seine Vorgänge Protokoll zu führen und dem Board von Zeit zu Zeit auf Verlangen des Boards hierüber Bericht zu erstatten.
Abschnitt 3. TEMPORARY COMMITTEES
Das Board kann Temporary Committees einsetzen, wenn es dies für erforderlich hält; Mitgliedschaft, Aufgaben und Zuständigkeiten richten sich nach den Beschlüssen oder Satzungen, die das Board beim Einsetzen dieser Committees verabschiedet.
ARTIKEL XIII: OFFICER
Zu den Officern von ICANN gehören ein Präsident (der das Amt des Chief Executive Officer übernimmt), ein Sekretär sowie ein Finanzvorstand (Chief Financial Officer). Darüber hinaus kann ICANN nach dem Ermessen des Boards über weitere, für erforderlich gehaltene Officer verfügen. Jede Person, mit Ausnahme des Präsidenten, kann mehr als ein Amt innehaben, jedoch mit der Einschränkung, dass kein Mitglied des Boards (mit Ausnahme des Präsidenten) gleichzeitig Officer von ICANN sein darf.
Die Officer von ICANN werden jährlich auf Empfehlung des Präsidenten vom Board gewählt, bzw. im Falle der Wahl des Präsidenten, auf Empfehlung des Vorsitzenden des ICANN-Boards. Jeder Officer bleibt so lange im Amt, bis er zurücktritt, entlassen wird, sein Amt aus einem anderen Grund niederlegen muss oder sein Nachfolger gewählt wird.
Abschnitt 3. ENTLASSUNG VON OFFICERN
Jeder Officer kann mit oder ohne Angabe von Gründen mit einer Mehrheit von zwei Dritteln (2/3) der Stimmen aller Mitglieder des Boards entlassen werden. Sollte ein Amt aufgrund von Tod, Rücktritt, Entlassung, Amtsunfähigkeit oder einem anderen Grund frei werden, kann das Board die Befugnisse und Aufgaben dieses Amts auf einen anderen Officer oder Direktor für die Zeit übertragen, bis ein Nachfolger für das Amt gewählt wurde.
Der Präsident ist gleichzeitig der Chief Executive Officer (CEO) von ICANN und für alle Aktivitäten und Geschäftsvorgänge von ICANN zuständig. Alle anderen Officer und Mitarbeiter unterstehen dem Präsidenten oder seinem Bevollmächtigten, sofern in diesen Statuten nichts Anderweitiges angegeben ist. Der Präsident gehört dem Board von Amts wegen an und verfügt über die gleichen Rechte und Privilegien wie jedes Mitglied des Boards. Der Präsident ist befugt, Sondersitzungen des Boards gemäß den in diesen Statuten aufgeführten Bestimmungen einzuberufen und sämtliche anderen Aufgaben wahrzunehmen, die in diesen Statuten festgelegt sind und ihm von Zeit zu Zeit vom Board zugewiesen werden können.
Der Sekretär führt in einem oder mehreren zu diesem Zweck bereitgestellten Büchern für das Board Protokoll oder lässt Protokoll führen; er trägt dafür Sorge, dass alle Mitteilungen ordnungsgemäß und rechtzeitig in Übereinstimmung mit den Bestimmungen dieser Statuten oder gesetzlichen Vorgaben übermittelt werden, und erfüllt im Allgemeinen alle Aufgaben, die ihm von Zeit zu Zeit vom Präsidenten oder dem Board aufgetragen werden.
Abschnitt 6. CHIEF FINANCIAL OFFICER
Der Chief Financial Officer ("CFO") ist der Finanzvorstand von ICANN. Auf Verlangen des Boards erbringt der CFO eine Sicherheitsleistung für die gewissenhafte Ausübung seiner Aufgaben in einer vom Board bestimmten Weise und mit einer vom Board bestimmten Art von Sicherheitsleistung. Der CFO ist für sämtliche Geldmittel von ICANN und deren Aufbewahrung zuständig und führt in ICANN gehörenden Büchern lückenlos über die genauen Beträge aller Einnahmen und Ausgaben Buch oder lässt hierüber Buch führen und verwahrt das gesamte Geld und sämtliche anderen Vermögenswerte im Namen von ICANN in Depots, die vom Board zu diesem Zweck bestimmt werden können. Der CFO gibt die Geldmittel von ICANN auf Anordnung des Boards oder des Präsidenten aus und erstattet dem Board und dem Präsidenten auf Verlangen Bericht über alle getätigten Transaktionen als CFO sowie über die finanzielle Situation von ICANN. Der CFO ist für die Finanzplanung und -vorschau von ICANN zuständig und unterstützt den Präsidenten bei der Vorbereitung des Jahresbudgets von ICANN. Der CFO koordiniert und beaufsichtigt die Finanzierung von ICANN einschließlich Audits und anderer Prüfungen von ICANN oder ihrer Supporting Organizations. Der CFO ist für alle anderen Angelegenheiten im Zusammenhang mit den Finanzgeschäften von ICANN zuständig.
Abschnitt 7. ZUSÄTZLICHE OFFICER
Zusätzlich zu den oben beschriebenen Officern erfüllen gegebenenfalls vom Board gewählte oder ernannte weitere oder beigeordnete Officer die ihnen vom Präsidenten oder dem Board zugewiesenen Aufgaben.
Abschnitt 8. VERGÜTUNG UND SPESEN
Die Vergütung der Officer von ICANN wird vom Board genehmigt. Spesen, die im Zusammenhang mit der Durchführung der Aufgaben als Officer anfallen, werden den Officern nach Genehmigung durch den Präsidenten (wenn es sich bei den Officern nicht um den Präsidenten selbst handelt), einen anderen vom Board bestimmten Officer (im Falle des Präsidenten) oder das Board zurückerstattet.
Abschnitt 9. INTERESSENKONFLIKTE
Über das Board Governance Committee führt das Board eine Regelung ein, die vorschreibt, dass jeder Officer mindestens einmal jährlich eine Erklärung abgeben muss, in der er alle unternehmerischen und sonstigen Zugehörigkeiten aufführt, die in irgendeiner Form mit den unternehmerischen und sonstigen Zugehörigkeiten von ICANN zusammenhängen.
ARTIKEL XIV: HAFTUNGSFREISTELLUNG FÜR DIREKTOREN, OFFICER, MITARBEITER UND SONSTIGE VERTRETER
ICANN stellt all ihre Vertreter im größtmöglichen gemäß CNPBCL zulässigen Umfang von allen Kosten, Urteilen, Geldstrafen, Schlichtungszahlungen und anderen Beträgen frei, die diese Personen tatsächlich und in angemessener Weise im Zusammenhang mit Vorgängen, die auf ihrer Eigenschaft als Vertreter oder ehemalige Vertreter von ICANN beruhen, übernommen oder sich zugezogen haben, vorausgesetzt die Handlungen der freigestellten Personen wurden in gutem Glauben und in einer Weise durchgeführt, bei der die freigestellten Personen vernünftigerweise annahmen, im besten Interesse von ICANN zu handeln und keine strafbare Handlung zu begehen. Im Sinne dieses Artikels bezeichnet "Vertreter" von ICANN jede Person, die Direktor, Officer, Mitarbeiter oder ein sonstiger Vertreter von ICANN ist oder war (einschließlich Mitarbeitern einer Supporting Organization, eines Advisory Committees, des Nominating Committees, eines sonstigen ICANN-Committees oder der Technical Liaison Group) und im Rahmen ihrer Zuständigkeiten handelt(e), oder die auf Wunsch von ICANN als Direktor, Officer, Mitarbeiter oder Vertreter einer anderen Organisation, Partnerschaft, eines Joint Ventures, Trusts oder anderen Unternehmens tätig ist/war. Das Board kann einen Beschluss fassen, mit dem der Erwerb und Beibehalt einer Versicherung für jeden ICANN-Vertreter gegen jede Haftbarkeit, die einem Vertreter in seiner Eigenschaft als Vertreter zugeschrieben wird, von ihm eingegangen wird oder von seinem Status als Vertreter herrührt, bewilligt wird, unabhängig davon, ob ICANN den Vertreter im Rahmen der Bestimmungen dieses Artikels von der Haftung freistellen kann oder nicht.
ARTIKEL XV: ALLGEMEINE BESTIMMUNGEN
Das Board kann jeden Officer oder mehrere Officer, jeden Vertreter oder mehrere Vertreter bevollmächtigen, im Namen und im Auftrag von ICANN Verträge abzuschließen oder Urkunden auszufertigen oder auszuhändigen. Es kann sich dabei um eine allgemeine Vollmacht oder eine auf bestimmte Fälle beschränkte Vollmacht handeln. Sofern keine anderweitige Bevollmächtigung des Boards vorliegt, dürfen Verträge und Urkunden nur von den folgenden Officern ausgefertigt werden: vom Präsidenten, einem Vizepräsidenten oder dem CFO. Sofern keine Bevollmächtigung oder Zustimmung des Boards vorliegt, ist kein anderer Officer, Vertreter oder Mitarbeiter berechtigt oder bevollmächtigt, ICANN vertraglich zu verpflichten oder für Schulden oder Verpflichtungen haftbar zu machen.
Alle Geldmittel von ICANN, die nicht anderweitig verwendet werden, werden von Zeit zu Zeit zugunsten von ICANN auf Banken, Treuhandbanken oder andere Depots eingezahlt, die das Board oder der Präsident in dessen Auftrag auswählen kann.
Alle Schecks, Wechsel oder andere Zahlungsanweisungen, Schuldscheine oder andere Schuldbelege, die im Namen von ICANN ausgestellt werden, werden von dem/den Officer(n) oder Vertreter(n) von ICANN und in solch einer Weise unterzeichnet wie von Zeit zu Zeit per Beschluss des Boards festgelegt.
Sofern nicht durch einen Beschluss des Boards eine Vollmacht ausgestellt wurde, dürfen keine Darlehen durch oder für ICANN gewährt und keine Schuldbelege in deren Namen ausgestellt werden. Es kann sich dabei um eine allgemeine Vollmacht oder eine auf bestimmte Fälle beschränkte Vollmacht handeln, jedoch unter der Voraussetzung, dass von ICANN keine Darlehen an ihre Direktoren oder Officer gewährt werden.
ARTIKEL XVI: FINANZANGELEGENHEITEN
Das Ende des Geschäftsjahres von ICANN wird vom Board festgelegt.
Am Ende des Geschäftsjahres werden die Bücher von ICANN geschlossen und von Wirtschaftsprüfern geprüft. Das Board ist für die Bestellung der Finanzprüfer zuständig.
Abschnitt 3. JAHRESBERICHT UND JAHRESABRECHNUNG
Das Board veröffentlicht mindestens einmal im Jahr einen Bericht, in dem seine Aktivitäten aufgeführt werden, samt einer geprüften Jahresabrechnung und einer Darstellung aller Zahlungen, die ICANN an Direktoren getätigt hat (einschließlich der Erstattung von Spesen). ICANN sorgt dafür, dass der gemäß CNPBCL erforderliche Jahresbericht und die ebenso erforderliche Jahresabrechnung über bestimmte Transaktionen erstellt und jedem Mitglied des Boards sowie gegebenenfalls anderen vom Board bestimmten Personen spätestens hundertzwanzig (120) Tage nach Abschluss des Geschäftsjahres von ICANN zugestellt wird.
Mindestens fünfundvierzig (45) Tage vor dem Beginn eines jeden Geschäftsjahres bereitet der Präsident einen Entwurf des Jahresbudgets von ICANN für das nächste Geschäftsjahr vor und übermittelt ihn an das Board. Dieser Entwurf wird auf der Website veröffentlicht. In diesem Jahresbudgetentwurf werden die voraussichtlichen Einnahmequellen sowie die voraussichtliche Höhe der Einnahmen aufgezeigt und, soweit machbar, die voraussichtlichen wesentlichen Ausgabenposten als Einzelposten. Das Board verabschiedet ein Jahresbudget und veröffentlicht das Budget auf der Website.
Abschnitt 5. GEBÜHREN UND ABGABEN
Das Board kann Gebühren und Abgaben für die von ICANN bereitgestellten Dienste und Leistungen festsetzen, mit dem Ziel, die angemessenen Kosten für den Geschäftsbetrieb von ICANN vollständig zu decken und angemessene Reserven für zukünftige Ausgaben und Eventualitäten im angemessenen Zusammenhang mit den rechtmäßigen Aktivitäten von ICANN zu bilden. Sie werden vor der Einführung zur öffentlichen Stellungnahme bekannt gegeben und nach der Einführung ausführlich auf der Website dargestellt, sodass jederzeit auf sie zugegriffen werden kann.
ARTIKEL XVII: MITGLIEDER
ICANN hat keine Mitglieder gemäß der Definition im California Nonprofit Public Benefit Corporation Law ("CNPBCL") trotz der Verwendung des Begriffs "Mitglied" in diesen Statuten, in Dokumenten von ICANN oder in Maßnahmen des Boards oder der Mitarbeiter von ICANN.
ARTIKEL XVIII: STANDORTE UND SIEGEL
Der Hauptsitz für die Durchführung der Geschäfte von ICANN befindet sich im County Los Angeles im Bundesstaat Kalifornien der Vereinigten Staaten von Amerika. ICANN kann zeitweise weitere Standorte innerhalb oder außerhalb der Vereinigten Staaten von Amerika einrichten.
Das Board kann ein Körperschaftssiegel einführen und dieses oder eine Nachbildung dessen durch Aufdruck, Anbringung, Reproduktion oder sonstige Art der Anwendung verwenden lassen.
ARTIKEL XIX: ÄNDERUNGEN
Sofern die Gesellschaftssatzung oder diese Statuten nichts anderes vorsehen, dürfen die Gesellschaftssatzung oder die Statuten von ICANN nur mit zwei Dritteln (2/3) der Stimmen aller Mitglieder des Boards abgeändert, ergänzt oder aufgehoben werden, und für die Verabschiedung einer neuen Gesellschaftssatzung oder neuer Statuten ist ebenfalls die genannte Zweidrittelmehrheit erforderlich.
ARTIKEL XX: ÜBERGANGSARTIKEL
Dieser Übergangsartikel legt die Bestimmungen für den Übergang von den Prozessen und Strukturen fest, die durch die ICANN-Statuten in der geänderten Fassung vom 29. Oktober 1999 mit den Änderungen bis zum 12. Februar 2002 festgelegt wurden (die " Alten Statuten"), zu den Prozessen und Strukturen, die durch die vorliegenden Statuten definiert werden, deren Bestandteil dieser Artikel ist (die " Neuen Statuten"). [Erklärender Hinweis (10. Dezember 2009): Für Abschnitt 5(3) dieses Artikels bezieht sich der Verweis auf die Alten Statuten auf die Statuten mit den Änderungen bis zum 20. März 2009.]
Abschnitt 2. BOARD OF DIRECTORS
1. Während des Zeitraums ab der Annahme dieses Übergangsartikels bis zum Datum und der Uhrzeit der Einsetzung des neuen Boards, wie in Absatz 5 dieses Abschnitts 2 definiert, besteht das Board of Directors der Corporation ("Übergangs-Board") aus den Mitgliedern des Boards, die unmittelbar nach Abschluss der Jahresversammlung 2002 Direktoren gewesen wären, mit der Ausnahme, dass die At-Large-Mitglieder des Boards unter den alten Statuten, die sich durch Mitteilung an den Sekretär des Boards am 15. Dezember 2002 oder schriftlich oder per E-Mail bis spätestens am 23. Dezember 2002 entsprechend entscheiden, ebenfalls Mitglieder des Übergangs-Boards sind. Ungeachtet der Bestimmungen von Artikel VI, Abschnitt 12 der neuen Statuten werden frei gewordene Sitze im Übergangs-Board nicht besetzt. Das Übergangs-Board besitzt keine Vertreter gemäß Artikel VI, Abschnitt 9 der neuen Statuten. Die zum Zeitpunkt der Annahme dieses Übergangsartikels vorhandenen Board Committees bleiben gemäß der Änderungen der Board Committees oder ihrer Mitgliedschaft bestehen, die das Übergangs-Board gemäß Entscheidung verfügt.
2. Das Übergangs-Board wählt einen Vorsitzenden und einen stellvertretenden Vorsitzenden, die bis zum Datum und der Uhrzeit der Einsetzung des neuen Boards im Amt sind.
3. Das "neue Board" ist das Board, das in Artikel VI, Abschnitt 2(1) der neuen Statuten beschrieben wird.
4. Unmittelbar nach Annahme dieses Übergangsartikels wird ein Nominating Committee gebildet, in dem, soweit machbar, die in Artikel VII, Abschnitt 2 der neuen Statuten beschriebenen Delegierten und Vertreter vertreten sind, deren Amtszeit mit dem Abschluss der ICANN-Jahresversammlung 2003 endet. Das Nominating Committee wählt unverzüglich Direktoren für die Sitze 1 bis 8 im neuen Board aus, für die gilt, dass ihre Amtszeit mit Beginn der ersten regulären Amtszeit für diese Sitze, wie in Artikel VI, Abschnitt 8(1)(a)-(c) der neuen Statuten festgelegt, endet, und setzt den ICANN-Sekretär schriftlich von dieser Auswahl in Kenntnis.
5. Das Datum und die Uhrzeit der Einsetzung des neuen Boards ist ein durch das Übergangs-Board festgelegter Zeitpunkt während der ersten regulären Sitzung des ICANN 2003, der frühestens sieben Kalendertage nach Eingang einer schriftlichen Mitteilung beim ICANN-Sekretär mit der Auswahl der Direktoren für die Besetzung von mindestens zehn der Sitze 1 bis 14 des neuen Boards beginnt. Ab dem Datum und der Uhrzeit der Einsetzung des neuen Boards übernimmt das neue Board vom Übergangs-Board alle Rechte, Pflichten und Verpflichtungen des Boards of Directors von ICANN. Vorbehaltlich Abschnitt 4 dieses Artikels werden die Direktoren ( Artikel VI, Abschnitt 2(1)(a)-(d)) und Vertreter ohne Stimmrecht ( Artikel VI, Abschnitt 9), von deren Auswahl der ICANN-Sekretär in Kenntnis gesetzt wurde, zusammen mit dem Präsidenten ( Artikel VI, Abschnitt 2(1)(e)) zum Datum und zur Uhrzeit der Einsetzung des neuen Boards eingesetzt. Im Anschluss daran werden alle weiteren Direktoren und Vertreter ohne Stimmrecht bei Eingang beim ICANN-Sekretär der Mitteilung ihrer Auswahl eingesetzt.
6. Das neue Board wählt als erste Amtshandlung einen Vorsitzenden und einen stellvertretenden Vorsitzenden. Die Amtszeit dieser Board-Positionen läuft mit dem Ende der Jahresversammlung 2003 aus.
7. Die Committees des Boards, die zum Datum und zur Uhrzeit der Einsetzung des neuen Boards bestehen, bestehen weiterhin gemäß ihren jeweiligen Satzungen, aber die Amtszeit aller Mitglieder dieser Committees endet mit dem Datum und der Uhrzeit der Einsetzung des neuen Boards. Temporary Committees, die zum Datum und zur Uhrzeit der Einsetzung des neuen Boards bestehen, bestehen weiterhin mit ihren jeweiligen Satzungen und Mitgliedern, vorbehaltlich aller Änderungen, die das neue Board durch Beschluss annehmen kann.
8. In Anwendung der Bestimmung zur Begrenzung der Amtszeiten in Artikel VI, Abschnitt 8(5) wird die Amtszeit eines Direktors im Board vor dem Datum und der Uhrzeit der Einsetzung des neuen Boards als eine Amtszeit gerechnet.
Abschnitt 3. ADDRESS SUPPORTING ORGANIZATION
Die Address Supporting Organization setzt ihre Arbeit gemäß den Bestimmungen des Memorandum of Understanding, ursprünglich geschlossen am 18. Oktober 1999 zwischen ICANN und einer Gruppe regionaler Internet Registries (RIRs) und im Oktober 2000 geändert fort, bis ein Ersatz für dieses Memorandum of Understanding in Kraft tritt. Unmittelbar nach Annahme dieses Übergangsartikels nimmt die Address Supporting Organization eine Auswahl für die zu besetzenden Positionen vor und setzt den ICANN-Sekretär von dieser Auswahl in Kenntnis. Diese Auswahl betrifft:
1. Direktoren, die die Sitze 9 und 10 des neuen Board einnehmen, mit einer Amtszeit, die mit dem Beginn der ersten regulären Amtszeit für jeden dieser Sitze endet, wie in Artikel VI, Abschnitt 8(1)(d) und (e) der neuen Statuten festgelegt und
2. den Delegierten für das Nominating Committee, der durch den Council der Address Supporting Organization ausgewählt wird, wie in Artikel VII, Abschnitt 2(8)(f) der neuen Statuten dargelegt.
Hinsichtlich der ICANN-Direktoren, zu deren Auswahl die Address Supporting Organization berechtigt ist, und unter Berücksichtigung der Notwendigkeit einer raschen Auswahl, um sicherzustellen, dass das neue Board so rasch wie möglich arbeitsfähig wird, kann die Address Supporting Organization Direktoren unter den Personen auswählen, die sie zuvor als ICANN-Direktoren gemäß den alten Statuten ausgewählt hatte. Sofern die Address Supporting Organization den ICANN-Sekretär nicht bis spätestens 31. März 2003 schriftlich von ihrer Auswahl für die Sitze 9 und 10 in Kenntnis setzt, wird angenommen, dass die Address Supporting Organization für Sitz 9 die Person, die sie zuvor als ICANN-Direktor gemäß der alten Satzung mit einer Amtszeit ab 2001 ausgewählt hatte, und für Sitz 10 die Person, die sie zuvor als ICANN-Direktor gemäß der alten Satzung mit einer Amtszeit ab 2002 ausgewählt hatte, ausgewählt hat.
Abschnitt 4. COUNTRY-CODE NAMES SUPPORTING ORGANIZATION
1. Nach der Registrierung von dreißig ccTLD-Managern (mindestens vier von diesen in jeder geografischen Region) als Mitglieder in die ccNSO, wird eine schriftliche Mitteilung auf der Website veröffentlicht. Im Anschluss an diese Mitteilung werden baldmöglichst die Mitglieder des anfänglichen ccNSO Councils, die durch die ccNSO-Mitglieder auszuwählen sind, gemäß den in Artikel IX, Abschnitt 4(8) und (9) dargelegten Verfahren bestimmt. Nach Abschluss dieses Auswahlprozesses wird eine schriftliche Mitteilung, dass der ccNSO Council errichtet wurde, auf der Website veröffentlicht. Drei Mitglieder des ccNSO Councils werden durch die ccNSO-Mitglieder in jeder geografischen Region ausgewählt, wobei die Amtszeit eines dieser Mitglieder mit dem Abschluss der ersten ICANN-Jahresversammlung nach Konstituierung des ccNSO Councils endet, die Amtszeit des zweiten dieser Mitglieder mit dem Abschluss der zweiten ICANN-Jahresversammlung nach Konstituierung des ccNSO Councils endet, und die Amtszeit des dritten dieser Mitglieder mit dem Abschluss der dritten ICANN-Jahresversammlung nach der Konstituierung des ccNSO Councils endet. (Die Definition des "ccTLD-Manager" in Artikel IX, Abschnitt 4(1) und die Definitionen in Artikel IX, Abschnitt 4(4) gelten im Rahmen dieses Abschnitts 4 von Artikel XX.)
2. Nach der Annahme von Artikel IX dieser Statuten wählt das Nominating Committee die drei Mitglieder des ccNSO Councils aus, wie in Artikel IX, Abschnitt 3(1)(b) beschrieben. Bei der Auswahl der drei Personen für den ccNSO Council bezeichnet das Nominating Committee ein Mitglied, dessen Amtszeit mit dem Abschluss der ersten ICANN-Jahresversammlung nach Konstituierung des ccNSO Councils endet, ein zweites Mitglied, dessen Amtszeit mit dem Abschluss der zweiten ICANN-Jahresversammlung nach Konstituierung des ccNSO Councils endet, und ein drittes Mitglied, dessen Amtszeit mit dem Abschluss der dritten ICANN-Jahresversammlung nach der Konstituierung des ccNSO Councils endet. Die drei Mitglieder des ccNSO Councils, die durch das Nominating Committee ausgewählt werden, werden erst nach der Konstituierung des ccNSO Councils eingesetzt.
3. Nach der Konstituierung des ccNSO Councils können das At-Large Advisory Committee und das Governmental Advisory Committee jeweils einen Vertreter für den ccNSO Council ernennen, wie in Artikel IX, Abschnitt 3(2)(a) und (b) dargelegt.
4. Nach der Konstituierung des ccNSO Councils kann der Council regionale Organisationen bezeichnen, wie in Artikel IX, Abschnitt 5 dargelegt. Eine regionale Organisation kann nach ihrer Bezeichnung einen Vertreter in den ccNSO Council ernennen.
5. Bis zur Konstituierung des ccNSO Councils bleiben die Sitze 11 und 12 im neuen Board nicht besetzt. Unmittelbar nach Konstituierung des ccNSO Councils nimmt die ccNSO über den ccNSO Council die Auswahl der Direktoren für die Sitze 11 und 12 im neuen Board vor, deren Amtszeit mit Beginn der nächsten regelmäßigen Amtszeit endet, die für diese Sitze in Artikel VI, Abschnitt 8(1)(d) und (f) der neuen Statuten festgelegt ist, und setzt den ICANN-Sekretär schriftlich von dieser Auswahl in Kenntnis.
6. Bis zur Konstituierung des ccNSO Councils wird der Delegierte im Nominating Committee, dessen Auswahl gemäß den neuen Statuten durch die ccNSO erfolgen soll, durch das Übergangs-Board oder das neue Board ernannt, abhängig davon, welches Board zu dem Zeitpunkt besteht, an dem eine bestimmte Ernennung erforderlich ist, nach ordnungsgemäßer Konsultation der Mitglieder der ccTLD-Community. Nach Konstituierung des ccNSO Councils bleibt der dann amtierende Delegierte im Nominating Committee, der gemäß diesem Abschnitt 4(9) durch das Übergangs-Board oder das neue Board ernannt wurde, im Amt, mit der Ausnahme, dass der ccNSO Council diesen Delegierten innerhalb von drei Monaten nach Abschluss der ICANN-Jahresversammlung oder wenn der Sitz frei ist, durch einen Delegierten seiner Wahl ersetzen kann. Die nachfolgenden Ernennungen des Delegierten im Nominating Committee, wie in Artikel VII, Abschnitt 2(8)(c) beschrieben, werden durch den ccNSO Council vorgenommen.
Abschnitt 5. GENERIC NAMES SUPPORTING ORGANIZATION
1. Die Generic Names Supporting Organization ("GNSO") setzt ihre Tätigkeit mit der Annahme dieses Übergangsartikels fort, sie wird jedoch in Form von vier neuen Interessengruppen neu strukturiert, die organisatorisch die früheren Bezirke der GNSO repräsentieren. Die Satzungen der einzelnen Interessengruppen sind vom ICANN Board zu genehmigen.
a. Der Bezirk für gTLD-Registries wird der Registries-Interessengruppe zugeordnet.
b. Der Bezirk für Registrars wird der Registrars-Interessengruppe zugeordnet.
c. Der Bezirk für den Handel wird der kommerziellen Interessengruppe zugeordnet.
d. Der Bezirk für geistiges Eigentum wird der kommerziellen Interessengruppe zugeordnet.
e. Der Bezirk für Internet Services Provider wird der kommerziellen Interessengruppe zugeordnet.
f . Der Bezirk für nichtgewerbliche Nutzer wird der nichtkommerziellen Interessengruppe zugeordnet.
2. Jeder in Absatz 1 dieses Unterabschnitts beschriebene GNSO-Bezirk setzt seine Arbeit im Wesentlichen wie zuvor fort, und kein Amtsträger eines Bezirks, keine Arbeitsgruppe, und keine andere Aktivität wird bis zu weiteren Maßnahmen des Bezirks geändert, unter der Voraussetzung, dass jeder in Absatz 1 (c-f) beschriebene GNSO-Bezirk dem ICANN-Sekretär spätestens bis zur ICANN-Versammlung im Oktober 2009 oder einem anderen vom Board festgelegten Datum eine neue überarbeitete Satzung einreicht, einschließlich der an die Verfahren des Bezirks angepassten Betriebsverfahren, die sich in Übereinstimmung mit den Änderungen dieser Statuten befinden müssen.
3. Bis zum Beginn der ICANN-Versammlung im Oktober 2009 oder einem anderen vom Board festgesetzten Datum, bleibt die aktuelle Bezirks- und Officerstruktur des GNSO Councils, wie in Artikel X, Abschnitt 3(1) der Statuten beschrieben (mit den Änderungen vom 29. Oktober 1999 und den Änderungen bis zum 20. März 2009 (die „Alten Statuten“)), erhalten. Im Anschluss daran setzt sich der GNSO Council gemäß dieser Statuten in ihrer von Zeit zu Zeit geänderten Fassung zusammen. Alle vom GNSO Council eingerichteten Committees, Task-Forces, Arbeitsgruppen, Drafting Committees und ähnlichen Gruppen, die unmittelbar vor der Annahme dieses Übergangsartikels bestanden, bleiben weiterhin mit denselben Satzungen, Mitgliedern und Aktivitäten, bestehen, vorbehaltlich aller Änderungen durch Aktionen des GNSO Councils oder ICANN Boards.
4. Mit dem Beginn der ICANN-Versammlung im Oktober 2009 oder einem anderen vom Board festgelegten Datum (das „Datum des Inkrafttretens des Übergangs“) werden die Sitze des GNSO Councils wie folgt zugewiesen:
a. Die drei zurzeit dem Registry-Bezirk zugewiesenen Sitze werden als drei Sitze der Registries-Interessengruppe neu zugewiesen.
b . Die drei zurzeit dem Registrar-Bezirk zugewiesenen Sitze werden als drei Sitze der Registrars-Interessengruppe neu zugewiesen.
c. Die drei Sitze, die zurzeit jeweils dem Bezirk für den Handel, dem Bezirk für geistiges Eigentum und dem Bezirk für Internet Services Provider (insgesamt neun) zugewiesen sind, werden auf sechs Sitze für die kommerzielle Interessengruppe verringert.
d. Die drei zurzeit dem Bezirk für nichtgewerbliche Nutzer zugewiesenen Sitze werden auf sechs Sitze der nichtkommerziellen Interessengruppe erhöht.
e. Die drei zurzeit vom Nominating Committee ausgewählten Sitze werden vom Nominating Committee wie folgt zugewiesen: ein stimmberechtigtes Mitglied für das Haus der Vertragsparteien, ein stimmberechtigtes Mitglied für das Haus der Nichtvertragsparteien, und ein dem GNSO Council insgesamt zugewiesenes nicht stimmberechtigtes Mitglied.
Vertreter für den GNSO Council werden in Übereinstimmung mit den Bestimmungen der vom Board genehmigten Satzungen der entsprechenden Interessengruppe ernannt oder gewählt. Dies geschieht rechtzeitig vor der ICANN-Versammlung vom Oktober 2009, damit diese Vertreter zu Beginn dieser Versammlung in ihrem Amt tätig werden können.
5. Der GNSO Council wird im Rahmen seines Implementierungsplans für die Restrukturierung folgendes dokumentieren: (a) wie gegebenenfalls vorhandene freie Sitze während der Übergangszeit gehandhabt werden; (b) wie für jede Interessengruppe jeder zugewiesen und auf der ICANN-Jahresversammlung 2009 wirksam werdende Council-Sitz besetzt wird, ob durch Fortsetzung einer bestehenden Amtszeit oder eine neue Wahl oder Ernennung; (c) wie gestaffelte Amtszeiten geplant werden sollen, damit dem GNSO Council so viel Kontinuität wie möglich erhalten bleibt; (d) die Auswirkungen der Amtszeitbegrenzungen aufgrund der Statuten für jedes Council-Mitglied.
6. So schnell wie möglich wird der GNSO Council in Übereinstimmung mit Artikel X, Abschnitt 3(7) und seinen GNSO-Verfahrensweisen nach dem Beginn der ICANN-Versammlung vom Oktober 2009 oder einem anderen vom Board festgelegten Datum Officer wählen und das ICANN-Sekretariat schriftlich von seiner Wahl in Kenntnis setzen.
Abschnitt 6. PROTOCOL SUPPORTING ORGANIZATION
Die in den alten Statuten genannte Protocol Supporting Organization wird eingestellt.
Abschnitt 7. ADVISORY COMMITTEES UND TECHNICAL LIAISON GROUP
1. Nach der Annahme der neuen Statuten setzt das Governmental Advisory Committee seine Arbeit gemäß seinen bestehenden Arbeitsgrundsätzen und Praktiken bis zu weiteren Aktionen des Committees fort. Das Governmental Advisory Committee kann durch schriftliche Mitteilung an den ICANN-Sekretär Vertreter bezeichnen, die bei anderen ICANN-Organen wie durch die neuen Statuten vorgesehen tätig werden. Unverzüglich nach Annahme dieses Übergangsartikels nennt das Governmental Advisory Committee dem ICANN-Sekretär die Person, die das Committee als Delegierten für das Nominating Committee ausgewählt hat, wie in Artikel VII, Abschnitt 2 der neuen Statuten dargelegt.
2. Die als Mitglieder der Technical Liaison Group unter Artikel XI-A, Abschnitt 2(2) der neuen Statuten bezeichneten Organisationen bestimmen die zwei technischen Experten, wie in Artikel XI-A, Abschnitt 2(6) der neuen Statuten dargelegt, durch schriftliche Mitteilung an den ICANN-Sekretär. Der Delegierte der Technical Liaison Group beim Nominating Committee wird baldmöglichst gemäß Artikel XI-A, Abschnitt 2(7) der neuen Statuten gewählt.
3. Nach Annahme der neuen Statuten setzt das Security and Stability Advisory Committee seine Arbeit gemäß seinen bestehenden Arbeitsgrundsätzen und Praktiken bis zu weiteren Aktionen des Committees fort. Unverzüglich nach Annahme dieses Übergangsartikels nennt das Security and Stability Advisory Committee dem ICANN-Sekretär die Person, die das Committee als Delegierten für das Nominating Committee ausgewählt hat, wie in Artikel VII, Abschnitt 2(4) der neuen Statuten dargelegt.
4. Nach Annahme der neuen Statuten setzt das Root Server System Advisory Committee seine Arbeit gemäß seinen bestehenden Arbeitsgrundsätzen und Praktiken bis zu weiteren Aktionen des Committees fort. Unverzüglich nach Annahme dieses Übergangsartikels nennt das Root Server Advisory Committee dem ICANN-Sekretär die Person, die das Committee als Delegierten für das Nominating Committee ausgewählt hat, wie in Artikel VII, Abschnitt 2(3) der neuen Statuten dargelegt.
5. At-Large Advisory Committee
a. Ein vorläufiges At-Large Advisory Committee besteht bis zu dem Zeitpunkt, an dem ICANN durch den Abschluss eines Memorandum of Understanding alle regionalen At-Large Organizations (RALOs) anerkennt, die in Artikel XI, Abschnitt 2(4) der neuen Statuten genannt werden. Das vorläufige At-Large Advisory Committee setzt sich zusammen aus (i) zehn Einzelpersonen (zwei aus jeder ICANN-Region), die durch das ICANN-Board im Anschluss an die Nominierungen durch das At-Large Organizing Committee ausgewählt werden, sowie (ii) fünf weiteren Einzelpersonen (eine aus jeder ICANN-Region), die durch das anfängliche Nominating Committee baldmöglichst gemäß den in Artikel VII, Abschnitt 5 der neuen Statuten dargelegten Grundsätzen ausgewählt werden. Das anfängliche Nominating Committee bestimmt zwei dieser Einzelpersonen, für die die Amtszeit bis zum Abschluss der ICANN-Jahresversammlung 2004 läuft, und drei dieser Einzelpersonen, für die die Amtszeit bis zum Abschluss der ICANN-Jahresversammlung 2005 läuft.
b. Nach Abschluss eines solchen Memorandums of Understanding durch jede RALO ist diese RALO berechtigt, zwei Personen, die Staatsbürger und Bewohner dieser Region sind, als Mitglieder des gemäß Artikel XI, Abschnitt 2(4) der neuen Statuten eingerichteten At-Large Advisory Committee auszuwählen. Nachdem der ICANN-Sekretär schriftlich von dieser Auswahl benachrichtigt wurde, übernehmen diese Personen sofort die Sitze, die bis zu dieser Benachrichtigung durch die Mitglieder des vorläufigen At-Large Advisory Committees eingenommen wurden, welche zuvor durch das Board aus der Region der RALO ausgewählt wurden.
c. Nachdem die durch alle fünf RALOs ausgewählten Personen ihre Sitze eingenommen haben, wird das vorläufige At-Large Advisory Committee zum At-Large Advisory Committee, wie durch Artikel XI, Abschnitt 2(4) der neuen Statuten dargelegt, eingerichtet. Die fünf Einzelpersonen, die das Nominating Committee für das vorläufige At-Large Advisory Committee ausgewählt hat, werden für den Rest der Amtszeit, für die sie ausgewählt wurden, zu Mitgliedern des At-Large Advisory Committees.
d. Unverzüglich nach seiner Schaffung nennt das vorläufige At-Large Advisory Committee dem ICANN-Sekretär die Personen, die das Committee als Delegierte für das Nominating Committee ausgewählt hat, wie in Artikel VII, Abschnitt 2(6) der neuen Statuten dargelegt.
ICANN-Officer (gemäß der Definition in Artikel XIII der neuen Statuten) werden durch das zu diesem Zeitpunkt bestehende ICANN-Board bei der Jahresversammlung 2002 mit einer Amtszeit bis zur Jahresversammlung 2003 gewählt.
Abschnitt 9. DURCH DEN PRÄSIDENTEN ERNANNTE GRUPPEN
Ungeachtet der Annahme oder Wirksamkeit der neuen Statuten bleiben Task-Forces oder andere durch den ICANN-Präsidenten ernannte Gruppen unverändert in Bezug auf Mitgliedschaft, Zweck und Arbeitsweise bestehen, bis Änderungen durch den Präsidenten vorgenommen werden.
Abschnitt 10. VERTRÄGE MIT ICANN
Ungeachtet der Annahme oder Wirksamkeit der neuen Statuten bleiben alle Verträge, einschließlich Arbeits- und Beratungsverträge, die ICANN eingegangen ist, gemäß der in den Verträgen enthaltenen Bestimmungen in Kraft.
Anhang A: GNSO-Richtlinienentwicklungsprozess
Der folgende Prozess regelt den GNSO-Richtlinienentwicklungsprozess (Policy Development Process, "PDP") bis zu dem Zeitpunkt, an dem Änderungen an diesem Prozess durch das Board of Directors von ICANN ("Board") empfohlen und genehmigt werden. [Hinweis: Dieser Anhang enthält Änderungen, die vorübergehend erforderlich waren, um der GNSO die Arbeit zu ermöglichen, während die Diskussionen der Community und des Boards zu überarbeiteten Richtlinienentwicklungen und Verfahrensweisen fortgesetzt werden.]
Ein Problem kann im Rahmen des PDP auf folgende Weise zur Erörterung angeschnitten werden:
a. Initiierung durch das Board. Das Board kann den PDP initiieren, indem es den GNSO Council ("Council") anweist, den in diesem Anhang umrissenen Prozess einzuleiten.
b. Initiierung durch den Council. Der GNSO Council kann den PDP durch einen Beschluss mit einer Mehrheit von mindestens fünfundzwanzig Prozent (25 %) der Council-Mitglieder eines jeden Hauses oder der Mehrheit eines Hauses initiieren.
c. Initiierung durch ein Advisory Committee. Ein Advisory Committee kann ein die Richtlinienentwicklung betreffendes Problem durch eine Aktion dieses Committees zur Einleitung des PDP und durch Übermittlung dieser Anforderung an den GNSO Council anschneiden.
2. Erstellen des Problemberichts
Innerhalb von fünfzehn (15) Kalendertagen nach Eingang (i) einer Anweisung des Boards, (ii) eines ordnungsgemäß unterstützten Antrags eines Council-Mitglieds oder (iii) eines ordnungsgemäß unterstützten Antrags eines Advisory Committees erstellt der Staff Manager einen Bericht (einen "Problembericht"). Jeder Problembericht enthält mindestens folgende Elemente:
a. Das Problem, das zur Erörterung vorgeschlagen wird
b. Die Identität der Partei, die das Problem vorlegt
c. Die Art und Weise, in der diese Partei durch das Problem betroffen ist
d. Unterstützung für das Problem zur Initiierung des PDP
e. Eine Empfehlung des Staff Managers, ob der Council den PDP für dieses Problem initiieren sollte (die "Staff-Empfehlung"). Jede Staff-Empfehlung umfasst eine Stellungnahme des General Counsel von ICANN dazu, ob das Problem, für das eine Initiierung des PDP vorgeschlagen wird, ordnungsgemäß innerhalb des Aufgabenbereichs des ICANN-Richtlinienprozesses und innerhalb der GNSO liegt. Bei der Bestimmung, ob das Problem ordnungsgemäß innerhalb des Aufgabenbereichs des ICANN-Richtlinienprozesses liegt, prüft der General Counsel folgende Aspekte:
1. Liegt das Problem im Rahmen des Mission-Statement von ICANN?
2. Betrifft das Problem eine Vielzahl von Situationen oder Organisationen?
3. Hat das Problem wahrscheinlich anhaltenden Wert oder anhaltende Gültigkeit, wenngleich gelegentliche Aktualisierungen möglich sein können ?
4. Wird dadurch eine Leitlinie oder ein Rahmen für die zukünftige Entscheidungsfindung geschaffen?
5. Steht das Problem in Verbindung mit einer bestehenden ICANN-Richtlinie oder hat es Auswirkungen auf eine solche Richtlinie?
f. Spätestens am Tag des Ablaufs der Frist von fünfzehn (15) Tagen verteilt der Staff Manager den Problembericht an den gesamten Council zur Abstimmung darüber, ob der PDP wie nachstehend diskutiert initiiert werden soll.
Der Council initiiert den PDP in folgender Weise:
a. Durch das Board angeschnittenes Problem. Wenn das Board den Council anweist, den PDP zu initiieren, tritt der Council innerhalb von fünfzehn (15) Kalendertagen nach Erhalt des Problemberichts zusammen und initiiert diesen ohne Zwischenabstimmung des Councils.
b. Durch andere als das Board angeschnittenes Problem. Wenn ein Richtlinienproblem mittels eines Problemberichts dem Council zur Erörterung vorgelegt wird, tritt der Council innerhalb von fünfzehn (15) Kalendertagen nach Erhalt dieses Problemberichts zusammen und stimmt über die Initiierung des PDP ab. Eine solche Sitzung kann in einer durch den Council für angemessen erachteten Weise einberufen werden, entweder als Sitzung mit persönlicher Anwesenheit, Konferenzgespräch oder via E-Mail.
c. Abstimmung des Councils. Eine Mehrheit von über 33 % Council-Mitglieder eines jeden Hauses oder mehr als 66 % eines Hauses zugunsten der Initiierung des PDP innerhalb des Aufgabenbereich ist ausreichend, um den PDP zu initiieren, sofern in der Staff-Empfehlung nicht ausgeführt wird, dass das Problem nicht ordnungsgemäß im Aufgabenbereich des ICANN-Richtlinienprozesses oder der GNSO liegt. In letzterem Fall ist eine Zweidrittelmehrheit gemäß Artikel X, Abschnitt 3, Absatz 9(c) erforderlich, um den PDP zu initiieren.
Bei der Sitzung des Councils, bei der der PDP initiiert wird, entscheidet der Council durch Mehrheitsbeschluss der Mitglieder eines jeden Hauses, ob eine Task-Force ernannt wird, um das Problem anzugehen. Wenn der Council:
a. zugunsten der Einberufung einer Task-Force entscheidet, so geht er dabei gemäß den Bestimmungen von Punkt 7 unten vor.
b. sich gegen die Einberufung einer Task-Force entscheidet, sammelt er Informationen zu dem Richtlinienproblem gemäß den Bestimmungen von Punkt 8 unten vor.
5. Zusammensetzung und Auswahl von Task-Forces
a. Nachdem der Council den Beschluss zur Ernennung einer Task-Force getroffen hat, lädt der Council alle Bezirke und/oder Interessengruppen der GNSO ein, eine Person für die Teilnahme an der Task-Force zu ernennen. Zusätzlich kann der Council bis zu drei externe Berater als Mitglieder der Task-Force ernennen. (Jedes Mitglied der Task-Force wird in diesem Anhang als "Vertreter", zusammen die "Vertreter", bezeichnet). Der Council kann nach eigenem Ermessen und unter Umständen, unter denen der Council dies als notwendig oder angemessen erachtet, die Anzahl der Vertreter pro Bezirk oder Interessengruppe erhöhen, die an der Task-Force teilnehmen.
b. Jeder Bezirk oder jede Interessengruppe, der oder die einen Vertreter für die Task-Force ernennen möchte, muss dem Staff Manager den Namen der durch den Bezirk oder die Interessengruppe vorgeschlagenen Person innerhalb von zehn (10) Kalendertagen nach einer solchen Anforderung vorlegen, damit dieser in die Task-Force aufgenommen werden kann. Diese Vertreter müssen nicht Mitglied des Councils sein. Sie müssen jedoch Personen sein, die Interessen und idealerweise Fachwissen und Erfahrung im Hinblick auf die Thematik haben, ebenso wie die Möglichkeit, viel Zeit für die Task-Force-Aktivitäten aufzubringen.
c. Der Council kann auch andere Optionen verfolgen, die er zur Unterstützung des PDP für angemessen hält, unter anderem die Ernennung einer bestimmten Einzelperson oder Organisation zur Sammlung von Informationen zu dem Problem oder die Ansetzung von Sitzungen zur Beratung oder Lagebesprechung. Alle diese Informationen sind dem Staff Manager innerhalb von fünfunddreißig (35) Kalendertagen nach der Initiierung des PDP vorzulegen.
6. Öffentliche Bekanntmachung der Initiierung des PDP
Nach der Initiierung des PDP veröffentlicht ICANN eine Bekanntmachung dieser Aktion auf der Website. Ein Zeitraum für die öffentliche Stellungnahme für das Problem wird gestartet, der über zwanzig (20) Kalendertage nach Initiierung des PDP läuft. Der Staff Manager oder ein anderer bezeichneter Vertreter von ICANN prüft die öffentlichen Stellungnahmen und integriert diese in einen Bericht (der "Bericht öffentlicher Stellungnahmen"), der entweder in den vorläufigen Task-Force-Bericht bzw. in den anfänglichen Bericht aufgenommen wird.
a. Rolle der Task-Force. Wenn eine Task-Force gebildet wird, besteht ihre Aufgabe im Allgemeinen darin, (i) Informationen zu sammeln, die die Positionen der Interessengruppen und der formellen Bezirke und der gegebenenfalls vorhandenen provisorischen Bezirke innerhalb der GNSO detailliert darlegen, und (ii) in anderer Weise relevante Informationen einzuholen, die es ermöglichen, dass der Task-Force-Bericht so vollständig und informativ wie möglich wird.
Die Task-Force ist formal nicht befugt, eine Entscheidung zu treffen. Stattdessen besteht die Aufgabe der Task-Force darin, möglichst spezifische und umfassende Informationen zu sammeln, die die Positionen der verschiedenen Parteien oder Gruppen dokumentieren, und es dem Council dadurch zu ermöglichen, eine aussagefähige und informierte Beratung zu dem Problem durchzuführen.
b. Task-Force-Satzung oder Aufgabenbeschreibung. Der Council entwickelt mit Unterstützung des Staff Managers innerhalb von zehn (10) Kalendertagen nach Initiierung des PDP eine Satzung oder Aufgabenbeschreibung für die Task-Force (die "Satzung"). Diese Satzung umfasst Folgendes:
1. das durch die Task-Force anzugehende Problem, so wie dieses Problem dem Council zur Abstimmung vorgelegt wurde, bevor der PDP begonnen wurde
2. der spezielle Zeitplan, den die Task-Force einhalten muss, wie nachstehend dargelegt, sofern das Board nicht entscheidet, dass ein zwingender Grund zur Ausdehnung des Zeitplans vorliegt
3. alle speziellen Anweisungen des Councils an die Task-Force, unter anderem dazu, ob die Task-Force eine Beratung durch externe Berater zu dem Problem einholen soll oder nicht
Die Task-Force erstellt ihren Bericht und führt ihre sonstigen Aktivitäten gemäß der Satzung durch. Anträge zur Abweichung von der Satzung müssen dem Council formell vorgelegt werden und dürfen durch die Task-Force nur dann vorgenommen werden, wenn eine Mehrheit der anwesenden Council-Mitglieder dem entsprechenden Antrag zugestimmt hat.
c. Ernennung des Task-Force-Vorsitzenden. Der Staff Manager beruft die erste Sitzung der Task-Force innerhalb von fünf (5) Kalendertagen nach Eingang der Satzung ein. Bei der ersten Sitzung wählen die Task-Force-Mitglieder unter anderem einen Task-Force-Vorsitzenden. Der Vorsitzende ist verantwortlich für die Organisation der Aktivitäten der Task-Force, einschließlich der Zusammenstellung des Task-Force-Berichts. Der Vorsitzende einer Task-Force muss nicht Mitglied des Councils sein.
1. Erklärungen der Bezirke und Interessengruppen. Die Vertreter der Interessengruppen sind verantwortlich dafür, mindestens die Positionen ihrer Interessengruppen und ihrer Bezirke einzuholen, sowie weitere Stellungnahmen, die die einzelnen Vertreter angesichts des erörterten Problems für angemessen halten. Diese Position und gegebenenfalls weitere Stellungnahmen sollten dem Task-Force-Vorsitzenden als formelle Erklärung (jeweils eine „Bezirks-/Interessengruppenerklärung“) innerhalb von fünfunddreißig (35) Kalendertagen nach der Initiierung des PDP vorgelegt werden. Jede Bezirks-/Interessengruppenerklärung umfasst mindestens folgende Elemente:
(i) wenn eine Zweidrittelmehrheit erreicht wurde, eine klare Erklärung der Position der Bezirke oder Interessengruppe zu dem Problem
(ii) wenn keine Zweidrittelmehrheit erreicht wurde, eine klare Erklärung aller Positionen, die die Mitglieder der Bezirke oder Interessengruppe zu dem Problem geäußert haben
(iii) Eine klare Aussage, wie der Bezirk oder die Interessengruppe zu ihrer Position bzw. ihren Positionen gekommen ist. Insbesondere sollte die Erklärung detailliert spezielle Sitzungen der Bezirke oder Interessengruppen, Telekonferenzen oder andere Mittel der Beratung eines Problems sowie eine Liste aller Mitglieder aufführen, die teilgenommen oder in anderer Weise ihre Standpunkte vorgelegt haben.
(iv) Eine Analyse, wie sich das Problem auf den Bezirk oder die Interessengruppe auswirken würde, einschließlich aller finanziellen Auswirkungen auf den Bezirk oder die Interessengruppe und
(v) eine Analyse des Zeitraums, der wahrscheinlich notwendig ist, um die Richtlinie umzusetzen.
2. Externe Berater. Wenn die Task-Force es für angemessen oder hilfreich hält, kann sie neben den Meinungen der Mitglieder des Bezirks oder der Interessengruppe die Meinungen externer Berater, Experten oder anderer Vertreter der Öffentlichkeit einholen. Diese Meinungen sollten in einem von diesen externen Beratern erstellten Bericht dargelegt werden und (i) eindeutig als die Meinungen externer Berater kenntlich gemacht werden, (ii) von einer detaillierten Erklärung (A) der Qualifikation und relevanten Erfahrung der Berater und (B) potenzieller Interessenkonflikte begleitet sein. Diese Berichte sollten dem Task-Force-Vorsitzenden als formelle Erklärung innerhalb von fünfunddreißig (35) Kalendertagen nach der Initiierung des PDP vorgelegt werden.
e. Task-Force-Bericht. Der Vorsitzende der Task-Force stellt in Zusammenarbeit mit dem Staff Manager die Erklärungen der Bezirke/Interessengruppen, den Bericht öffentlicher Stellungnahmen und gegebenenfalls sonstige Informationen oder Berichte in einem einzigen Dokument (dem "vorläufigen Task-Force-Bericht") zusammen und verteilt den vorläufigen Task-Force-Bericht an die gesamte Task-Force innerhalb von vierzig (40) Tagen nach der Initiierung des PDP. Die Task-Force hält eine abschließende Task-Force-Sitzung innerhalb von fünf (5) Tagen nach der Verteilung des vorläufigen Task-Force-Berichts ab, um die Probleme zu beraten und nach Möglichkeit eine Entscheidung mit einer Zweidrittelmehrheit zu erreichen. Innerhalb von fünf (5) Tagen nach der abschließenden Task-Force-Sitzung erstellen der Vorsitzende der Task-Force und der Staff Manager den abschließenden Task-Force-Bericht (den "Task-Force-Bericht"), und veröffentlichen diesen auf der Website für Stellungnahmen, der Comment Site. Jeder Task-Force-Bericht muss folgende Elemente umfassen:
1. eine klare Erklärung jeder mit Zweidrittelmehrheit angenommenen Position der Task-Force zu dem Problem
2. Wenn keine Zweidrittelmehrheit erreicht wurde, eine klare Erklärung aller von Task-Force-Mitgliedern geäußerten Positionen, die innerhalb des zwanzigtägigen Zeitplans für die Vorlage von Berichten der Bezirke oder Interessengruppen vorgelegt wurden. Jede Erklärung sollte klar (i) die Begründungen für die Position sowie (ii) den oder die Bezirk(e) oder Interessengruppe(n) enthalten, die die Position vertreten haben.
3. Eine Analyse, wie sich das Problem jeden Bezirk oder jede Interessengruppe der Task-Force auswirken würde, einschließlich aller finanziellen Auswirkungen auf den Bezirk oder die Interessengruppe
4. eine Analyse des Zeitraums, der wahrscheinlich notwendig ist, um die Richtlinie umzusetzen und
5. den Rat aller externen Berater, die durch den Council in die Task-Force berufen wurden, begleitet von einer detaillierten Erklärung (i) der Qualifikation und relevanten Erfahrung der Berater und (ii) potenzieller Interessenkonflikte
8. Verfahren, wenn keine Task-Force gebildet wird
a. Wenn der Council entscheidet, keine Task-Force einzuberufen, fordert der Council, dass jeder Bezirk oder jede Interessengruppe innerhalb von zehn (10) Kalendertagen nach einer solchen Anforderung einen Vertreter ernennt, der die Standpunkte des Bezirks oder der Interessengruppe zu dem Problem einholt. Jeder dieser Vertreter wird aufgefordert, dem Staff Manager innerhalb von fünfunddreißig (35) Kalendertagen nach der Initiierung des PDP eine Erklärung des Bezirks/der Interessengruppe vorzulegen.
b. Der Council kann auch andere Optionen verfolgen, die er zur Unterstützung des PDP für angemessen hält, unter anderem die Ernennung einer bestimmten Einzelperson oder Organisation zur Sammlung von Informationen zu dem Problem oder die Ansetzung von Sitzungen zur Beratung oder Lagebesprechung. Alle diese Informationen sind dem Staff Manager innerhalb von fünfunddreißig (35) Kalendertagen nach der Initiierung des PDP vorzulegen.
c. Der Staff Manager nimmt alle Erklärungen der Bezirke/Interessengruppen, Erklärungen öffentlicher Stellungnahmen und andere Informationen und stellt diese innerhalb von fünfzig (50) Kalendertagen nach der Initiierung des PDP in einem anfänglichen Bericht zusammen (und veröffentlicht diesen Bericht auf der Website für Stellungnahmen, der Comment Site). Im Anschluss daran folgt der PDP den Bestimmungen von Punkt 9 unten zur Erstellung eines Abschlussberichts.
9. Öffentliche Stellungnahmen zum Task-Force-Bericht oder anfänglichen Bericht
a. Der Zeitraum für die öffentliche Stellungnahme dauert mindestens zwanzig (20) Kalendertage nach der Veröffentlichung des Task-Force-Berichts oder anfänglichen Berichts. Alle Einzelpersonen oder Organisationen können während des Zeitraums für die öffentliche Stellungnahme Stellungnahmen vorlegen, einschließlich aller Bezirke oder Interessengruppen, die nicht an der Task-Force teilgenommen haben. Alle Stellungnahmen müssen mit Angaben des Namens des Autors der Stellungnahme, der relevanten Erfahrung des Autors und des Interesses des Autors an dem Problem versehen sein.
b. Am Ende des Zeitraums von zwanzig (20) Tagen ist der Staff Manager verantwortlich für die Prüfung der eingegangenen Stellungnahmen und das Aufnehmen der Stellungnahmen, die der Staff Manager nach eigenem pflichtgemäßem Ermessen für angemessen hält, in den Task-Force-Bericht oder anfänglichen Bericht (zusammen der "Abschlussbericht"). Der Staff Manager ist nicht verpflichtet, alle Stellungnahmen, einschließlich aller Stellungnahmen durch eine Einzelperson oder Organisation, aufzunehmen, die während des Zeitraums für die öffentliche Stellungnahme vorgelegt werden.
c. Der Staff Manager erstellt den Abschlussbericht und legt ihn dem Vorsitzenden des Councils innerhalb von zehn (10) Kalendertagen nach dem Ende des Zeitraums für die öffentliche Stellungnahme vor.
10. Beratung durch den Council
a. Nach Eingang eines Abschlussberichts, ob als Ergebnis der Task-Force oder in anderer Weise, (i) verteilt der Vorsitzende des Councils den Abschlussbericht an alle Council-Mitglieder und (ii) beruft eine Council-Sitzung innerhalb von (10) Tagen im Anschluss daran ein. Der Council kann seine Beratung zu dem Problem vor der formellen Sitzung beginnen, auch in Sitzungen mit persönlicher Anwesenheit, Konferenzgesprächen, E-Mail-Diskussionen oder anderen Mitteln, die der Council wählen kann. Der Beratungsprozess gipfelt in einer formellen Council-Sitzung mit persönlicher Anwesenheit oder über Telekonferenz, bei der der Council darauf hinarbeitet, eine Zweidrittelmehrheit der anwesenden Mitglieder dem Board zu präsentieren.
b. Der Council kann, wenn er dies wählt, die Meinungen externer Berater bei seiner Abschlusssitzung einholen. Die Meinungen dieser Berater sollten, wenn der Council auf diese vertraut, (i) in den Bericht des Councils an das Board integriert werden, (ii) speziell als die Meinungen externer Berater kenntlich gemacht werden und (iii) von einer detaillierten Erklärung (x) der Qualifikation und relevanten Erfahrung der Berater und (y) potenzieller Interessenkonflikte begleitet sein.
11. Bericht des Councils an das Board
Der Staff Manager ist bei der Abschlusssitzung des Councils anwesend und hat im Anschluss an die Sitzung fünf (5) Kalendertage Zeit, um die Standpunkte des Councils in einen Bericht zu integrieren, der dem Board vorgelegt wird (der "Board-Bericht"). Der Board-Bericht muss mindestens folgende Elemente enthalten:
a. Eine klare Erklärung jeder mit erfolgreicher GNSO-Mehrheit angenommenen Empfehlung des Councils
b. Wenn keine Zweidrittelmehrheit erreicht wurde, eine klare Erklärung aller Positionen, die Council-Mitglieder geäußert haben. Jede Erklärung sollte klar (i) die Begründungen für jede Position sowie (ii) den oder die Bezirk(e) oder Interessengruppe(n) enthalten, die die Position vertreten haben.
c. Eine Analyse, wie sich das Problem auf jeden Bezirk oder jede Interessengruppe auswirken würde, einschließlich aller finanziellen Auswirkungen auf den Bezirk oder die Interessengruppe
d. Eine Analyse des Zeitraums, der wahrscheinlich notwendig ist, um die Richtlinie umzusetzen
e. Die Ratschläge aller externen Berater, auf die vertraut wurde, begleitet von einer detaillierten Erklärung (i) der Qualifikation und relevanten Erfahrung der Berater und (ii) potenzieller Interessenkonflikte
f. Den Abschlussbericht, der dem Council vorgelegt wurde und
g. Eine Kopie des Protokolls der Council-Beratung zu dem Richtlinienproblem, einschließlich aller Meinungen, die während dieser Beratung geäußert wurden, begleitet von einer Beschreibung der Personen, die diese Meinungen geäußert haben.
Eine erfolgreiche GNSO-Mehrheit der Council-Mitglieder wird als den Standpunkt des Councils wiedergebend betrachtet und kann als Empfehlung des Councils an das Board weitergeleitet werden. Wenn keine GNSO-Zweidrittelmehrheit erzielt wird, ist für die Genehmigung der im Abschlussbericht enthaltenen Empfehlungen eine Mehrheit beider Häuser erforderlich sowie eine Unterstützung der Empfehlung durch einen Vertreter, der mindestens 3 der 4 Interessengruppen repräsentiert. Enthaltungen sind nicht zulässig; daher müssen alle Council-Mitglieder eine Stimme abgeben, sofern sie nicht angeben, dass sie ein finanzielles Interesse am Ergebnis des Richtlinienproblems haben. Ungeachtet des Vorstehenden müssen alle durch die Council-Mitglieder im PDP geäußerten Standpunkte wie oben dargelegt in den Board-Bericht aufgenommen werden.
a. Das Board kommt baldmöglichst nach Eingang des Board-Berichts vom Staff Manager zusammen, um die Empfehlung des GNSO Councils zu diskutieren.
b. Falls im Council eine Zweidrittelmehrheit der GNSO erreicht wurde, übernimmt das Board die Richtlinie gemäß der mit Zweidrittelmehrheit der GNSO angenommenen Empfehlung, sofern nicht eine Mehrheit von über sechsundsechzig Prozent (66 %) des Boards entscheidet, dass eine solche Richtlinie nicht im besten Interesse der ICANN-Community oder ICANN ist.
c. Falls das Board beschließt, nicht gemäß der mit Zweidrittelmehrheit der GNSO angenommenen Empfehlung des Councils zu handeln, (i) formuliert das Board die Gründe für seine Entscheidung in einem Bericht an den Council (die "Board-Erklärung") und (ii) legt die Board-Erklärung dem Council vor.
d. Der Council prüft die Board-Erklärung zur Diskussion mit dem Board innerhalb von zwanzig (20) Kalendertagen nach Eingang der Board-Erklärung beim Council. Das Board legt die Methode (z. B. per Telekonferenz, per E-Mail oder in anderer Weise) fest, in der der Council und das Board die Board-Erklärung diskutieren.
e. Zum Abschluss der Diskussionen zwischen Council und Board tritt der Council zusammen, um seine Empfehlung zu bestätigen oder zu ändern und diesen Beschluss (die "Ergänzungsempfehlung") dem Board mitzuteilen, einschließlich einer Erklärung zu seiner aktuellen Empfehlung. Falls im Council eine Zweidrittelmehrheit der GNSO bezüglich der Ergänzungsempfehlung erreicht werden kann, übernimmt das Board die Empfehlung, sofern nicht eine Mehrheit von über sechsundsechzig Prozent (66 %) des Boards entscheidet, dass eine solche Richtlinie nicht im besten Interesse der ICANN-Community oder ICANN ist.
f. In allen Fällen, in denen der Council keine Zweidrittelmehrheit der GNSO erreichen kann, ist eine Mehrheitsentscheidung des Boards ausreichend für das Handeln.
g. Wenn eine abschließende Entscheidung zu einer Empfehlung oder Ergänzungsempfehlung des GNSO Councils frühzeitig gefällt wird, nimmt das Board eine vorläufige Abstimmung vor und veröffentlicht, sofern praktisch möglich, eine vorläufige Entscheidung, die einen Zeitraum von zehn (10) Tagen für die öffentliche Stellungnahme vor einer endgültigen Entscheidung durch das Board erlaubt.
Nach einer endgültigen Entscheidung des Boards autorisiert das Board das ICANN-Personal bzw. weist das ICANN-Personal an, alle notwendigen Schritte zur Umsetzung der Richtlinie zu ergreifen.
Während des gesamten PDP, vom Vorschlag für die Richtlinie bis zu einer endgültigen Entscheidung durch das Board, pflegt ICANN auf der Website eine Status-Webseite, auf der die Fortschritte bei jedem PDP-Problem ausführlich dargestellt werden, mit folgenden Angaben:
a. der anfängliche Vorschlag für eine Richtlinie
b. eine Liste aller Vorschläge, die nicht zur Erstellung eines Problemberichts führen
c. der für jede Richtlinie zu verfolgende Zeitplan
d. alle Diskussionen im Council zu der Richtlinie
e. alle Berichte von Task-Forces, dem Staff Manager, dem Council und dem Board und
"Comment Site" und "Website" sind eine oder mehrere Websites, die von ICANN bezeichnet werden und auf denen Benachrichtigungen und Stellungnahmen zum PDP veröffentlicht werden.
"Zweidrittelmehrheit" ist eine Mehrheit von mehr als sechsundsechzig (66) Prozent der bei einer Sitzung des jeweiligen Organs anwesenden Mitglieder, mit Ausnahme des GNSO Councils.
"Staff Manager" ist ein Mitglied bzw. mehrere Mitglieder des ICANN-Personals, die den PDP verwalten.
“Zweidrittelmehrheit der GNSO” besitzt die in den Statuten festgelegte Bedeutung.
Eine “Erfolgreiche GNSO-Mehrheit” ist eine Entscheidung des GNSO Councils die die in Artikel X, Anschnitt 3(9) dargelegten Mehrheiten erzielt hat, einschließlich und uneingeschränkt die Zweidrittelmehrheit der GNSO.
Anhang B: ccNSO-Richtlinienentwicklungsprozess (ccPDP)
Der folgende Prozess regelt den ccNSO-Richtlinienentwicklungsprozess (Policy Development Process, "PDP").
1. Anforderung eines Problemberichts
Ein Problembericht kann durch eines der folgenden Organe oder Personen angefordert werden:
a. Council. Der ccNSO Council (in diesem Anhang B der "Council") kann das Erstellen eines Problemberichts durch ein zustimmendes Votum von mindestens sieben der bei einer Sitzung anwesenden oder per E-Mail abstimmenden Mitglieder des Councils anfordern.
b. Board. Das ICANN-Board kann das Erstellen eines Problemberichts anfordern, indem es den Council auffordert, den Richtlinienentwicklungsprozess zu beginnen.
c. Regionale Organisation. Eine oder mehrere der regionalen Organisationen, die die ccTLDs in den vom ICANN anerkannten Regionen repräsentieren, können das Erstellen eines Problemberichts anfordern, indem sie den Council auffordern, den Richtlinienentwicklungsprozess zu beginnen.
d. ICANN-Supporting Organization oder Advisory Committee. Eine ICANN-Supporting Organization oder ein ICANN-Advisory Committee kann das Erstellen eines Problemberichts anfordern, indem sie den Council auffordern, den Richtlinienentwicklungsprozess zu beginnen.
e. Mitglieder der ccNSO. Die Mitglieder der ccNSO können das Erstellen eines Problemberichts durch ein zustimmendes Votum von mindestens zehn der bei einer Sitzung anwesenden oder per E-Mail abstimmenden Mitglieder der ccNSO anfordern.
Jede Anforderung eines Problemberichts muss schriftlich erfolgen und das Problem, zu dem ein Problembericht angefordert wird, ausreichend detailliert darlegen, um das Erstellen eines Problemberichts zu ermöglichen. Es steht dem Council offen, weitere Informationen anzufordern oder weitere Forschungen oder Untersuchungen anzustellen, um zu ermitteln, ob der angeforderte Problembericht erstellt werden soll oder nicht.
2. Erstellung des Problemberichts und Initiierungsschwelle
Innerhalb von sieben Tagen nach einem zustimmenden Votum wie in Punkt 1 (a) oben dargelegt oder dem Eingang einer Anforderung wie in Punkt 1 (b), (c) oder (d) oben dargelegt ernennt der Council einen Issue Manager. Der Issue Manager kann ein Mitarbeiter von ICANN sein (in diesen Fall werden die Kosten für den Issue Manager durch ICANN getragen) oder eine andere Person bzw. andere Personen, die der Council auswählt (in diesen Fall ist die ccNSO verantwortlich für die Kosten des Issue Managers).
Innerhalb von fünfzehn (15) Kalendertagen nach seiner Ernennung (oder innerhalb eines anderen Zeitraums, den der Council in Beratung mit dem Issue Manager für geeignet hält) erstellt der Issue Manager einen Problembericht. Jeder Problembericht enthält mindestens folgende Elemente:
a. Das Problem, das zur Erörterung vorgeschlagen wird
b. Die Identität der Partei, die das Problem vorlegt
c. Die Art und Weise, in der diese Partei durch das Problem betroffen ist
d. Unterstützung für das Problem zur Initiierung des PDP
e. Eine Empfehlung des Issue Managers, ob der Council die Initiierung des PDP in Angriff nehmen sollte (die "Manager-Empfehlung"). Jede Manager-Empfehlung umfasst eine diese stützende Stellungnahme des General Counsel von ICANN, in der ausgeführt wird, ob das Problem ordnungsgemäß innerhalb des Umfangs des ICANN-Richtlinienprozesses und innerhalb der ccNSO liegt. Bei der Entwicklung seiner Stellungnahme prüft der General Counsel folgende Punkte:
1) Liegt das Problem im Rahmen des Mission-Statements von ICANN?
2) Bestätigt eine Analyse der relevanten Faktoren gemäß Artikel IX, Abschnitt 6(2) und Anhang C, dass das Problem im Rahmen des Aufgabenbereichs der ccNSO liegt?
Falls der General Counsel die Punkte 1 und 2 oben bestätigen kann, erwägt der General Counsel darüber hinaus folgende Punkte:
3) Steht das Problem in Verbindung mit einer bestehenden ICANN-Richtlinie oder hat es Auswirkungen auf eine solche Richtlinie?
4) Dauert das Problem wahrscheinlich an, auch wenn gelegentliche Aktualisierungen möglich sein können, und wird dadurch eine Leitlinie oder ein Rahmen für die zukünftige Entscheidungsfindung geschaffen?
In jedem Fall muss die Erwägung von Änderungen am ccPDP (dieser Anhang B) oder am Aufgabenbereich der ccNSO ( Anhang C) innerhalb des Aufgabenbereichs von ICANN und der ccNSO liegen.
Falls der General Counsel der Meinung ist, dass das Problem nicht ordnungsgemäß innerhalb des Umfangs des ccNSO-Aufgabenbereichs liegt, teilt der Issue Manager dem Council diese Meinung mit. Wenn im Anschluss an eine Analyse der relevanten Faktoren gemäß Artikel IX, Abschnitt 6 und Anhang C eine Mehrheit von 10 oder mehr Council-Mitgliedern der Meinung ist, dass das Problem im Aufgabenbereich liegt, teilt der Vorsitzende der ccNSO dies dem Issue Manager mit. Der General Counsel und der ccNSO Council nehmen einen Dialog gemäß den vereinbarten Regeln und Verfahren auf, um die Angelegenheit zu lösen. Falls keine Einigkeit zwischen dem General Counsel und dem Council in Bezug darauf erreicht wird, ob das Problem innerhalb des Aufgabenbereichs der ccNSO liegt, kann der Council mit einer Mehrheit von 15 oder mehr Mitgliedern des Councils entscheiden, dass das Problem innerhalb des Aufgabenbereichs liegt. Der Vorsitzende der ccNSO teilt dies dem General Counsel und dem Issue Manager mit. Der Issue Manager arbeitet dann weiter an einer Empfehlung, ob der Council die Initiierung des PDP in Angriff nehmen sollte oder nicht und nimmt dabei die Meinung und die Analyse des General Counsel und des Councils in den Problembericht auf.
f. Falls die Manager-Empfehlung zugunsten einer Initiierung des PDP ausfällt, wird ein vorgeschlagener Zeitplan für die Durchführung der einzelnen hier umrissenen Phasen des PDP genannt (PDP-Zeitplan).
g. Wenn möglich wird im Problembericht angegeben, ob das daraus folgende Ergebnis wahrscheinlich in einer Richtlinie mündet, die durch das ICANN-Board angenommen wird. Unter bestimmten Umständen kann dies erst angegeben werden, wenn wesentliche Diskussionen zu dem Problem stattgefunden haben. In diesen Fällen sollte im Problembericht auf diese Unsicherheit hingewiesen werden. Nach Abschluss des Problemberichts verteilt der Issue Manager diesen an den ganzen Council zur Abstimmung darüber, ob der PDP initiiert werden soll.
3. Initiierung des PDP
Der Council entscheidet in folgender Weise, ob der PDP initiiert werden soll:
a. Innerhalb von 21 Kalendertagen nach Erhalt eines Problemberichts vom Issue Manager stimmt der Council über die Initiierung des PDP ab. Eine solche Abstimmung wird bei einer Sitzung durchgeführt, die in einer vom Council als angemessen erachteten Art und Weise abgehalten wird, ob mit persönlicher Anwesenheit oder durch Konferenzgespräch. Eine Abstimmung per E-Mail ist jedoch nicht zulässig.
b. Eine Mehrheit von zehn oder mehr Council-Mitgliedern zugunsten der Initiierung des PDP ist erforderlich, vorausgesetzt, im Problembericht ist angegeben, dass das Problem ordnungsgemäß in den Bereich des Mission-Statements von ICANN und in den Aufgabenbereich ccNSO fällt.
4. Entscheidung über die Ernennung einer Task-Force; Festlegung des Zeitplans
Bei der Sitzung des Councils, bei der gemäß Punkt 3 oben der PDP initiiert wurde (oder, falls der Council eine Abstimmung per E-Mail nutzt, bei dieser Abstimmung), entscheidet der Council durch ein Mehrheitsvotum der bei der Sitzung anwesenden (oder per E-Mail abstimmenden) Mitglieder, ob eine Task-Force zur Lösung des Problems ernannt wird oder nicht. Wenn der Council:
a. zugunsten der Einberufung einer Task-Force entscheidet, so geht er dabei gemäß den Bestimmungen von Punkt 7 unten vor
b. sich gegen die Einberufung einer Task-Force entscheidet, sammelt er Informationen zu dem Richtlinienproblem gemäß den Bestimmungen von Punkt 8 unten
Der Council genehmigt bzw. ändert und genehmigt auch durch Mehrheitsbeschluss der bei der Sitzung anwesenden oder per E-Mail abstimmenden Mitglieder den im Problembericht dargelegten PDP-Zeitplan.
5. Zusammensetzung und Auswahl von Task-Forces
a. Nachdem der Council den Beschluss zur Ernennung einer Task-Force getroffen hat, lädt der Council jede der regionalen Organisationen (siehe Artikel IX, Abschnitt 6) ein, zwei Einzelpersonen für die Teilnahme an der Task-Force zu ernennen (die "Vertreter"). Zusätzlich kann der Council bis zu drei Berater (die "Berater") von außerhalb der ccNSO ernennen und, im Anschluss an die formelle Anforderung einer GAC-Beteiligung an der Task-Force, bis zu zwei Vertreter des Governmental Advisory Committee in der Task-Force akzeptieren. Der Council kann nach eigenem Ermessen unter Umständen, unter denen der Council dies als notwendig oder angemessen erachtet, die Anzahl der an der Task-Force teilnehmenden Vertreter erhöhen.
b. Jede regionale Organisation, die Vertreter für die Task-Force ernennen möchte, muss dem Issue Manager die Namen der Vertreter innerhalb von zehn (10) Kalendertagen nach einer solchen Anforderung vorlegen, damit diese in die Task-Force aufgenommen werden. Diese Vertreter müssen nicht Mitglied des Councils sein. Sie müssen jedoch Personen sein, die Interessen und idealerweise Fachwissen und Sachverstand im Hinblick auf die Thematik haben, ebenso wie die Möglichkeit, viel Zeit für die Task-Force-Aktivitäten aufzubringen.
c. Der Council kann auch andere Maßnahmen verfolgen, die er zur Unterstützung des PDP für angemessen hält, unter anderem die Ernennung einer bestimmten Einzelperson oder Organisation zur Sammlung von Informationen zu dem Problem oder die Ansetzung von Sitzungen zur Beratung oder Lagebesprechung. Alle diese Informationen sind dem Issue Manager gemäß dem PDP-Zeitplan vorzulegen.
6. Öffentliche Bekanntmachung der Initiierung des PDP und Zeitraum für die Stellungnahme
Nach der Initiierung des PDP veröffentlicht ICANN eine Bekanntmachung dieser Maßnahme auf der Website und bei anderen ICANN-Supporting Organizations und Advisory Committees. Ein Zeitraum für die Stellungnahme (gemäß dem PDP-Zeitplan, in der Regel mindestens 21 Tage) läuft für das Problem an. Es werden Stellungnahmen von ccTLD-Managern, anderen Supporting Organizations, Advisory Committees und von der Öffentlichkeit akzeptiert. Der Issue Manager oder ein anderer bezeichneter Vertreter des Councils prüft die Stellungnahmen und integriert diese in einen Bericht (der "Bericht der Stellungnahmen"), der entweder in den vorläufigen Task-Force-Bericht bzw. in den anfänglichen Bericht aufgenommen wird.
7. Task-Forces
a. Rolle der Task-Force. Wenn eine Task-Force gebildet wird, besteht ihre Rolle darin, (i) Informationen zu sammeln, die die Positionen der ccNSO-Mitglieder in den geografischen Regionen und die anderer Parteien und Gruppen dokumentieren, und (ii) in anderer Weise relevante Informationen einzuholen, die es ermöglichen, dass der Task-Force-Bericht vollständig und so informativ wie möglich wird, um es dem Council zu erleichtern, eine effektive Behandlung des Problems auf der Basis relevanter Informationen durchzuführen.
Die Task-Force ist formal nicht befugt, eine Entscheidung zu treffen. Stattdessen besteht die Aufgabe der Task-Force darin, möglichst spezifische und umfassende Informationen zu sammeln, die die Positionen der verschiedenen Parteien oder Gruppen dokumentieren, und es dem Council dadurch zu ermöglichen, eine aussagefähige und informierte Beratung zu dem Problem durchzuführen.
b. Task-Force-Satzung oder Aufgabenbeschreibung. Der Council entwickelt mit Unterstützung des Issue Managers innerhalb der im PDP-Zeitplan vorgesehenen Frist eine Satzung oder Aufgabenbeschreibung für die Task-Force (die "Satzung"). Diese Satzung umfasst Folgendes:
1. das durch die Task-Force anzugehende Problem, so wie dieses Problem dem Council zur Abstimmung vorgelegt wurde, bevor der PDP begonnen wurde
2. Der spezielle Zeitplan, den die Task-Force einhalten muss, wie nachstehend dargelegt, sofern der Council nicht entscheidet, dass ein zwingender Grund zur Ausdehnung des Zeitplans vorliegt
3. alle speziellen Anweisungen des Councils an die Task-Force, unter anderem dazu, ob die Task-Force eine Beratung durch externe Berater zu dem Problem einholen soll oder nicht
Die Task-Force erstellt ihren Bericht und führt ihre sonstigen Aktivitäten gemäß der Satzung durch. Anträge zur Abweichung von der Satzung müssen dem Council formell vorgelegt werden und dürfen durch die Task-Force nur dann vorgenommen werden, wenn eine Mehrheit der bei einer Sitzung anwesenden oder per E-Mail abstimmenden Council-Mitglieder dem entsprechenden Antrag zugestimmt hat. Die Quorum-Anforderungen von Artikel IX, Abschnitt 3(14) gelten für die Aktionen des Councils unter diesem Punkt 7(b).
c. Ernennung des Task-Force-Vorsitzenden. Der Issue Manager beruft die erste Sitzung der Task-Force innerhalb der im PDP-Zeitplan vorgesehenen Frist ein. Bei der ersten Sitzung wählen die Task-Force-Mitglieder unter anderem einen Task-Force-Vorsitzenden. Der Vorsitzende ist verantwortlich für die Organisation der Aktivitäten der Task-Force, einschließlich der Zusammenstellung des Task-Force-Berichts. Der Vorsitzende einer Task-Force muss nicht Mitglied des Councils sein.
d. Sammlung von Informationen.
1. Erklärung der regionalen Organisation. Die Vertreter sind jeweils verantwortlich für das Einholen der Positionen mindestens der regionalen Organisation für ihre geografische Region, und sie können weitere Stellungnahmen einholen, die jeder Vertreter für angemessen hält, einschließlich Stellungnahmen der ccNSO-Mitglieder in dieser Region, die nicht Mitglieder der regionalen Organisation sind, zu dem betrachteten Problem. Die Position der regionalen Organisation und alle weiteren Stellungnahmen, die die Vertreter eingeholt haben, sind innerhalb der im PDP-Zeitplan vorgesehenen Frist in einer formalen Erklärung dem Task-Force-Vorsitzenden vorzulegen (jeweils eine "Regionale Erklärung"). Jede regionale Erklärung umfasst mindestens folgende Elemente:
(i) wenn eine Zweidrittelmehrheit (gemäß der Definition durch die regionale Organisation) erreicht wurde, eine klare Erklärung der Position der regionalen Organisation zu dem Problem,
(ii) wenn keine Zweidrittelmehrheit erreicht wurde, eine klare Erklärung aller Positionen, die die Mitglieder der regionalen Organisation zu dem Problem geäußert haben
(iii) eine klare Aussage, wie die regionale Organisation zu ihrer Position bzw. ihren Positionen gekommen ist. Insbesondere sollte die Erklärung detailliert spezielle Sitzungen, Telekonferenzen oder andere Mittel der Beratung eines Problems sowie eine Liste aller Mitglieder aufführen, die teilgenommen oder in anderer Weise ihre Standpunkte vorgelegt haben.
(iv) eine Erklärung der Position aller ccNSO-Mitglieder zu dem Problem, die nicht Mitglied der regionalen Organisation sind,
(v) eine Analyse, wie sich das Problem auf die Region auswirken würde, einschließlich aller finanziellen Auswirkungen auf die Region und
(vi) eine Analyse des Zeitraums, der wahrscheinlich notwendig ist, um die Richtlinie umzusetzen.
2. Externe Berater. Die Task-Force kann nach eigenem Ermessen die Meinungen externer Berater, Experten oder anderer Vertreter der Öffentlichkeit einholen. Diese Meinungen sollten in einem von diesen externen Beratern erstellten Bericht dargelegt werden und (i) eindeutig als die Meinungen externer Berater kenntlich gemacht werden, (ii) von einer detaillierten Erklärung (a) der Qualifikation und relevanten Erfahrung der Berater und (b) potenzieller Interessenkonflikte begleitet sein. Diese Berichte sollten dem Task-Force-Vorsitzenden als formelle Erklärung innerhalb der im PDP-Zeitplan vorgesehenen Frist vorgelegt werden.
e. Task-Force-Bericht. Der Vorsitzende der Task-Force stellt in Zusammenarbeit mit dem Issue Manager die Regionalen Erklärungen, den Bericht der Stellungnahmen und gegebenenfalls sonstige Informationen oder Berichte in einem einzigen Dokument (dem "vorläufigen Task-Force-Bericht") zusammen und verteilt den vorläufigen Task-Force-Bericht an die gesamte Task-Force innerhalb der im PDP-Zeitplan vorgesehenen Frist. Die Task-Force hält eine abschließende Task-Force-Sitzung ab, bei der die Probleme erörtert werden und versucht wird, zu einem Beschluss mit Zweidrittelmehrheit zu kommen. Nach der abschließenden Task-Force-Sitzung erstellen der Vorsitzende der Task-Force und der Issue Manager den abschließenden Task-Force-Bericht (den "Task-Force-Bericht"), und veröffentlichen diesen auf der Website und bei den anderen ICANN-Supporting Organizations und Advisory Committees. Jeder Task-Force-Bericht muss folgende Elemente umfassen:
1. eine klare Erklärung jeder mit Zweidrittelmehrheit (66 % der Stimmen der Task-Force) angenommenen Position der Task-Force zu dem Problem,
2. Wenn keine Zweidrittelmehrheit erreicht wurde, eine klare Erklärung aller von Task-Force-Mitgliedern geäußerten Positionen, die innerhalb des Zeitplans für die Vorlage von Constituency-Berichten vorgelegt wurden. Jede Erklärung sollte klar (i) die Begründungen für jede Position sowie (ii) die regionalen Organisationen angeben, die die Position vertreten haben.
3. eine Analyse, wie sich das Problem auf jede Region auswirken würde, einschließlich aller finanziellen Auswirkungen auf die Region,
4. eine Analyse des Zeitraums, der wahrscheinlich notwendig ist, um die Richtlinie umzusetzen und
5. den Rat aller externen Berater, die durch den Council in die Task-Force berufen wurden, begleitet von einer detaillierten Erklärung (i) der Qualifikation und relevanten Erfahrung der Berater und (ii) potenzieller Interessenkonflikte
8. Verfahren, wenn keine Task-Force gebildet wird
a. Wenn der Council entscheidet, keine Task-Force einzuberufen, ernennt jede regionale Organisation innerhalb der im PDP-Zeitplan genannten Frist einen Vertreter, der die Standpunkte der Region zu dem Problem einholt. Jeder dieser Vertreter wird aufgefordert, dem Issue Manager innerhalb der im PDP-Zeitplan genannten Frist eine Regionale Erklärung vorzulegen.
b. Der Council kann nach eigenem Ermessen auch andere Schritte zur Unterstützung des PDP unternehmen, beispielsweise die Ernennung einer bestimmten Einzelperson oder Organisation zur Sammlung von Informationen zu dem Problem oder die Ansetzung von Sitzungen zur Beratung oder Lagebesprechung. All diese Informationen sind dem Issue Manager innerhalb der im PDP-Zeitplan genannten Frist vorzulegen.
c. Der Council fordert den Vorsitzenden des GAC formell auf, seine Meinung zu äußern oder Ratschläge zu geben.
d. Der Issue Manager sammelt alle Regionalen Erklärungen, den Bericht der Stellungnahmen und andere Informationen und stellt diese innerhalb der im PDP-Zeitplan genannten Frist in einem anfänglichen Bericht zusammen (und veröffentlicht diesen Bericht auf der Website). Im Anschluss daran erstellt der Issue Manager einen Abschlussbericht gemäß Punkt 9 unten.
9. Öffentliche Stellungnahmen zum Task-Force-Bericht oder anfänglichen Bericht
a. Ein Zeitraum für die Stellungnahme (gemäß dem PDP-Zeitplan, in der Regel mindestens 21 Tage) wird für Stellungnahmen zum Task-Force-Bericht oder zum anfänglichen Bericht eröffnet. Es werden Stellungnahmen von ccTLD-Managern, anderen Supporting Organizations, Advisory Committees und von der Öffentlichkeit akzeptiert. Alle Stellungnahmen müssen mit Angaben des Namens des Autors, der relevanten Erfahrung und des Interesses des Autors an dem Problem versehen sein.
b. Am Ende des Zeitraums für die Stellungnahme prüft der Issue Manager die eingegangenen Stellungnahmen und kann nach eigenem Ermessen geeignete Stellungnahmen in den Task-Force-Bericht oder anfänglichen Bericht aufnehmen, um den "Abschlussbericht" zu erstellen. Der Issue Manager ist nicht verpflichtet, alle Stellungnahmen aufzunehmen, die während des Zeitraums für die Stellungnahme vorgelegt werden, noch ist er verpflichtet, alle Stellungnahmen einer Einzelperson oder Organisation aufzunehmen.
c. Der Issue Manager erstellt den Abschlussbericht und legt ihn dem Vorsitzenden des Councils innerhalb der im PDP-Zeitplan vorgesehenen Frist vor.
10. Beratung durch den Council
a. Bei Eingang eines Abschlussberichts, ob als Ergebnis einer Task-Force oder in anderer Weise, (i) verteilt der der Vorsitzende des Councils den Abschlussbericht an alle Council-Mitglieder, (ii) beruft der Vorsitzende des Councils eine Council-Sitzung innerhalb der im PDP-Zeitplan genannten Frist ein, in der der Council auf eine Empfehlung hinarbeitet, die er dem Board vorlegen kann, und (iii) sendet der Vorsitzende des Councils eine formelle Einladung an den Vorsitzenden des GAC zur Mitteilung einer Meinung oder eines Ratschlags durch das GAC. Eine solche Sitzung kann in einer durch den Council für angemessen erachteten Weise einberufen werden, entweder als Sitzung mit persönlicher Anwesenheit, Konferenzgespräch oder via E-Mail. Der Issue Manager ist bei der Sitzung anwesend.
b. Der Council kann seine Beratung zu dem Problem vor der formellen Sitzung beginnen, auch in Sitzungen mit persönlicher Anwesenheit, Konferenzgesprächen, E-Mail-Diskussionen oder anderen Mitteln, die der Council wählen kann.
c. Der Council kann, wenn er dies wählt, die Meinungen externer Berater bei seiner Abschlusssitzung einholen. Die Meinungen dieser Berater sollten, wenn der Council auf diese vertraut, (i) in den Bericht des Councils an das Board integriert werden, (ii) speziell als die Meinungen externer Berater kenntlich gemacht werden und (iii) von einer detaillierten Erklärung (a) der Qualifikation und relevanten Erfahrung der Berater und (b) potenzieller Interessenkonflikte begleitet sein.
11. Empfehlung des Councils
Bei der Entscheidung, ob der Council eine Empfehlung zu dem Problem vorlegt (eine "Empfehlung des Councils"), strebt der Council einen Konsens an. Wenn eine Minderheit eine Konsensposition ablehnt, erstellt diese Minderheit eine Erklärung mit ihren Gründen für die Ablehnung und gibt diese an den Council weiter. Wenn die Diskussion der Erklärung durch den Council nicht zu einem Konsens führt, gilt eine durch mindestens 14 Mitglieder des Councils gestützte Empfehlung als Standpunkt des Councils und wird als Empfehlung des Councils an die Mitglieder weitergeleitet. Ungeachtet des Vorstehenden müssen alle durch die Council-Mitglieder im PDP geäußerten Standpunkte wie oben dargelegt in den Mitglieder-Bericht aufgenommen werden.
12. Bericht des Councils an die Mitglieder
Falls eine Empfehlung des Councils gemäß Punkt 11 angenommen wird, integriert der Issue Manager innerhalb von sieben Tagen nach der Council-Sitzung die Empfehlung des Councils zusammen mit allen anderen Standpunkten der Council-Mitglieder in einem Mitglieder-Bericht, der durch den Council genehmigt werden muss und anschließend den Mitgliedern vorgelegt wird (der "Mitglieder-Bericht"). Der Mitglieder-Bericht muss mindestens folgende Elemente enthalten:
a. eine klare Erklärung der Empfehlung des Councils,
b. den Abschlussbericht, der dem Council vorgelegt wurde und
c. e ine Kopie des Protokolls der Council-Beratung zu dem Richtlinienproblem (siehe Punkt 10), einschließlich aller Meinungen, die während dieser Beratung geäußert wurden, begleitet von einer Beschreibung der Personen, die diese Meinungen geäußert haben.
13. Abstimmung der Mitglieder
Nach der Vorlage des Mitglieder-Berichts und innerhalb der im PDP-Zeitplan vorgesehenen Frist wird den ccNSO-Mitgliedern die Gelegenheit gegeben, über die Empfehlung des Councils abzustimmen. Die Abstimmung der Mitglieder erfolgt elektronisch, und die Stimmen der Mitglieder werden innerhalb der im PDP-Zeitplan vorgesehenen Frist (mindestens 21 Tage lang) abgegeben.
Falls mindestens 50 % der ccNSO-Mitglieder Stimmen innerhalb des Abstimmungszeitraums abgeben, wird das resultierende Abstimmungsergebnis ohne weiteres Vorgehen verwendet. Falls weniger als 50 % der ccNSO-Mitglieder während des ersten Abstimmungsgangs ihre Stimme abgeben, wird das Ergebnis des ersten Abstimmungsgangs nicht verwendet, und das Ergebnis eines endgültigen, zweiten Abstimmungsgangs, der nach Benachrichtigung der ccNSO-Mitglieder unter Einhaltung einer Frist von mindestens 30 Tagen durchgeführt wird, wird verwendet, falls mindestens 50 % der ccNSO-Mitglieder ihre Stimme abgeben. Falls mehr als 66 % der Stimmen, die bis zum Ende des Abstimmungszeitraums eingehen, für die Empfehlung des Councils sind, wird die Empfehlung gemäß Punkt 14 unten als ccNSO-Empfehlung an das Board weitergeleitet.
14. Board-Bericht
Der Issue Manager integriert innerhalb von sieben Tagen nach einer ccNSO-Empfehlung, die gemäß Punkt 13 erfolgt, die ccNSO-Erklärung in einen Bericht, der durch den Council genehmigt werden muss und anschließend dem Board vorgelegt wird (der "Board-Bericht"). Der Board-Bericht muss mindestens folgende Elemente enthalten:
a. eine klare Erklärung der ccNSO-Empfehlung
b. den Abschlussbericht, der dem Council vorgelegt wurde und
c. den Mitglieder-Bericht
15. Abstimmung des Boards
a. Das Board kommt baldmöglichst nach Eingang des Board-Berichts vom Issue Manager zusammen, um die ccNSO-Empfehlung zu diskutieren, unter Berücksichtigung der Verfahren für die Prüfung durch das Board.
b. Das Board nimmt die ccNSO-Empfehlung an, sofern nicht eine Mehrheit von über 66 % des Boards entscheidet, dass eine solche Richtlinie nicht im besten Interesse der ICANN-Community oder ICANN ist.
1. Falls das Board beschließt, nicht gemäß der ccNSO-Empfehlung zu handeln, (i) formuliert das Board die Gründe für seine Entscheidung in einem Bericht an den Council (die "Board-Erklärung") und (ii) legt die Board-Erklärung dem Council vor.
2. Der Council diskutiert die Board-Erklärung mit dem Board innerhalb von dreißig Tagen nach Vorlage der Board-Erklärung beim Council. Das Board legt die Methode (z. B. per Telekonferenz, per E-Mail oder in anderer Weise) fest, in der der Council und das Board die Board-Erklärung diskutieren. Die Diskussionen werden in gutem Glauben und auf effiziente Art und Weise geführt, mit dem Ziel, eine beidseitig akzeptable Lösung zu erarbeiten.
3. Nach Abschluss der Diskussionen von Council und Board hält der Council eine Sitzung ab, bei der er seine Empfehlung des Councils bestätigt oder ändert. Eine von 14 oder mehr Council-Mitgliedern getragene Empfehlung wird als den Standpunkt des Councils wiedergebend betrachtet (die "Ergänzungsempfehlung" des Councils). Diese Ergänzungsempfehlung kann an die Mitglieder in einem ergänzenden Mitglieder-Bericht weitergeleitet werden, einschließlich einer Erklärung zu der Ergänzungsempfehlung. Den Mitgliedern wird Gelegenheit gegeben, über die Ergänzungsempfehlung unter denselben Bedingungen wie in Punkt 13 dargelegt abzustimmen. Falls mehr als 66 % der Stimmen, die während des Abstimmungszeitraums durch ccNSO-Mitglieder abgegeben werden, für die Ergänzungsempfehlung sind, wird die Empfehlung als ccNSO-Empfehlung an das Board weitergeleitet, und das Board nimmt die Empfehlung an, sofern nicht eine Mehrheit von über 66 % des Boards entscheidet, dass die Annahme einer solchen Richtlinie einen Verstoß gegen die treuhänderischen Pflichten des Boards gegenüber der Community darstellen würde.
4. Falls das Board die ccNSO-Ergänzungsempfehlung nicht annimmt, führt es seine Gründe dafür in seiner endgültigen Entscheidung aus ("Ergänzende Board-Erklärung").
5. Falls das Board entscheidet, eine ccNSO-Ergänzungsempfehlung nicht anzunehmen, ist das Board nicht berechtigt, eine Richtlinie zu dem mit der Empfehlung angegangenen Problem festzulegen, und der Status quo bleibt bis zu dem Zeitpunkt erhalten, an die dem ccNSO im Rahmen des ccPDP eine Empfehlung zu dem Problem macht, die das Board für annehmbar hält.
16. Umsetzung der Richtlinie
Nach der Annahme einer ccNSO-Empfehlung oder einer ccNSO-Ergänzungsempfehlung autorisiert das Board das ICANN-Personal bzw. weist das ICANN-Personal an, die Richtlinie umzusetzen.
17. Pflege der Unterlagen
Bezüglich jedes ccPDP, für den ein Problembericht angefordert wird (siehe Punkt 1) pflegt ICANN auf der Website eine Status-Webseite, auf der die Fortschritte jedes ccPDP ausführlich dargestellt werden. Dies umfasst eine Liste der relevanten Termine für den ccPDP, ebenso wie Verknüpfungen zu den folgenden Dokumenten, soweit diese aufgrund des ccPDP erstellt wurden:
a. Problembericht
b. PDP-Zeitplan
c. Bericht der Stellungnahmen
d. Regionale Erklärung(en)
e. Vorläufiger Task-Force-Bericht
f. Task-Force-Bericht
g. Anfänglicher Bericht
h. Abschlussbericht
i. Mitglieder-Bericht
j. Board-Bericht
k. Board-Erklärung
l. Ergänzender Mitglieder-Bericht und
m. Ergänzende Board-Erklärung
Darüber hinaus veröffentlicht ICANN auf der Website Stellungnahmen, die schriftlich in elektronischer Form eingegangen sind und speziell vorschlagen, dass ein ccPDP initiiert werden solle.
Anhang C: Aufgabenbereich der ccNSO
In diesem Anhang werden der Aufgabenbereich und die Grundsätze und Analysemethoden beschrieben, die bei jeder weiteren Entwicklung des Aufgabenbereichs der ccNSO-Richtlinienentwicklungsrolle verwendet werden. Wie in Artikel IX, Abschnitt 6(2) der Statuten vorgesehen, wird dieser Aufgabenbereich gemäß den Verfahren des ccPDP definiert.
Beim Umfang der Befugnisse und Zuständigkeiten des ccNSO muss die komplexe Beziehung zwischen ICANN und ccTLD-Managern/Registries im Hinblick auf Richtlinienprobleme berücksichtigt werden. Dieser Anhang soll die ccNSO, der ccNSO Council und das ICANN-Board und die ICANN-Mitarbeiter bei der Abgrenzung relevanter globaler Richtlinienprobleme unterstützen.
Richtlinienbereiche
Die Rolle der ccNSO in Bezug auf Richtlinien sollte auf einer Analyse des folgenden funktionalen DNS-Modells basieren:
1. Daten werden registriert/gepflegt, um eine Zonendatei zu generieren,
2. Eine Zonendatei wird wiederum in TLD-Nameservern verwendet.
Innerhalb einer TLD müssen zwei Funktionen ausgeführt werden (diese werden nachstehend ausführlicher dargestellt):
1. Eingabe von Daten in eine Datenbank (Dateneingabefunktion) und
2. Aufrechterhaltung und Sicherstellung der Wartung von Nameservern für die TLD (Nameserverfunktion).
Diese beiden Kernfunktionen müssen auf der Ebene der ccTLD Registry sowie auf höherer Ebene (IANA-Funktion und Rootserver) und auf niedrigeren Ebenen der DNS-Hierarchie durchgeführt werden. Dieser Mechanismus ist, wie RFC 1591 verdeutlicht, rekursiv:
Es gibt keine Anforderungen an Subdomains von Top-Level-Domains, die über die Anforderungen an die Domains auf höherer Ebene selbst hinausgehen. Das heißt, die Anforderungen in diesem Memo werden rekursiv angewendet. Insbesondere ist es allen Subdomains erlaubt, eigene Domainnameserver zu betreiben, in denen sie beliebige Informationen bereitstellen können, die der Subdomainmanager für geeignet hält (solange diese wahr und richtig sind).
Die Kernfunktionen
1. Dateneingabefunktion (DEF):
Betrachtet man dies detaillierter, so sollte die erste Funktion (die Eingabe von Daten in eine Datenbank und deren Pflege) in vollem Umfang durch eine Benennungsrichtlinie definiert werden. Diese Benennungsrichtlinie muss die folgenden Regeln und Bedingungen angeben:
(a) Regeln und Bedingungen, unter denen Daten erfasst und in eine Datenbank eingegeben oder unter denen Daten in der Datenbank geändert werden (auf der TLD-Ebene unter anderem, Daten, die eine Übergabe von Registrierer zu Registrierer oder den Wechsel des Registrierers widerspiegeln)
(b) Regeln und Bedingungen, nach denen bestimmte Daten allgemein und öffentlich verfügbar gemacht werden (beispielsweise über Whois oder Nameserver)
2. Nameserverfunktion (NSF)
Mit der Nameserverfunktion sind essenzielle Interoperabilitäts- und Stabilitätsprobleme im Zentrum des Domainnamensystems verbunden. Diese Funktion ist bedeutsam für Nameserver auf der ccTLD-Ebene, aber auch für die Rootserver (und das Rootserversystem) und Nameserver auf niedrigeren Ebenen.
Aufgrund ihrer eigenen Leistung und aufgrund von Interoperabilitäts- und Stabilitätsüberlegungen sind ordnungsgemäß funktionierende Nameserver von größter Bedeutung für den individuellen Benutzer ebenso wie für die lokalen und globalen Internet-Communities.
Bezüglich der Nameserverfunktion müssen daher Richtlinien definiert und eingerichtet werden. Die meisten beteiligten Parteien, einschließlich der Mehrheit der ccTLD Registries, haben die Notwendigkeit gemeinsamer Richtlinien in diesem Bereich akzeptiert, indem sie die relevanten RFCs einhalten, unter anderem RFC 1591.
Verteilung der Rollen hinsichtlich Richtlinien, Zuständigkeiten und Verantwortlichkeit
Es ist im Interesse von ICANN und im Interesse der ccTLD-Manager, das stabile und ordnungsgemäße Funktionieren des Domainnamensystems sicherzustellen. ICANN und die ccTLD Registries müssen jeweils gesonderte Rollen in dieser Hinsicht einnehmen, die durch die relevanten Richtlinien definiert werden können. Der Aufgabenbereich der ccNSO kann nicht festgelegt werden, ohne ein gemeinsames Verständnis der Zuweisung der Befugnisse zwischen ICANN und den ccTLD Registries zu erreichen.
Drei Rollen lassen sich unterscheiden, bezüglich denen die Verantwortung für jedes gegebene Problem zugewiesen werden muss:
- Richtlinien: d. h. die Fähigkeit und Befugnis, eine Richtlinie zu definieren
- Ausführung: d. h. die Fähigkeit und Befugnis, nach der Richtlinie zu verfahren und diese umzusetzen
- Verantwortlichkeit: d. h. die Fähigkeit und Befugnis, die verantwortliche Organisation für die Ausübung ihrer Befugnisse zur Rechenschaft zu ziehen
Erstens setzt Verantwortung eine Richtlinie voraus und dies grenzt die Richtlinienrolle ab. Abhängig von dem Problem, das angegangen werden muss, müssen diejenigen bestimmt und festgelegt werden, die an der Definition und Bestimmung der Richtlinie beteiligt sind. Zweitens setzt dies eine ausführende Rolle voraus, die die Befugnis zur Umsetzung und Handlung innerhalb der Grenzen einer Richtlinie definiert. Schließlich muss als Gegengewicht zur ausführenden Rolle eine Verantwortlichkeitsrolle definiert und bestimmt werden.
Die nachstehenden Informationen bieten eine Hilfestellung für Folgendes:
1. Abgrenzung und Identifizierung spezifischer Richtlinienbereiche
2. Definition und Festlegung von Rollen bezüglich dieser spezifischen Richtlinienbereiche
Dieser Anhang definiert den Aufgabenbereich der ccNSO im Hinblick auf die Entwicklung von Richtlinien. Der Aufgabenbereich ist beschränkt auf die Richtlinienrolle des ccNSO-Richtlinienentwicklungsprozesses für die nachstehend aufgeführten Funktionen und Ebenen. Es wird davon ausgegangen, dass die Genauigkeit der nachstehend dargelegten Zuweisungen der Kompetenzverteilung für Richtlinien, Ausführung und Verantwortlichkeit in einem ccPDP-Prozess zur Aufgabenfestlegung betrachtet wird.
Nameserver-Funktion (für ccTLDs)
Ebene 1: Rootnameserver
Richtlinien: IETF, RSSAC (ICANN)
Ausführung: Root Server System-Betreiber
Verantwortlichkeit: RSSAC (ICANN), (US DoC-ICANN MoU)Ebene 2: ccTLD Registry-Nameserver hinsichtlich Interoperabilität
Richtlinien: ccNSO-Richtlinienentwicklungsprozess (ICANN), ein ccNSO-Prozess kann zur Entwicklung von Best Practices organisiert werden
Ausführung: ccTLD-Manager
Verantwortlichkeit: teils ICANN (IANA), teils die lokale Internet-Community, einschließlich örtliche RegierungEbene 3: Benutzer-Nameserver
Richtlinien: ccTLD-Manager, IETF (RFC)
Ausführung: Registrierer
Verantwortlichkeit: ccTLD-Manager
Dateneingabefunktion (für ccTLDs)
Ebene 1: Root Level Registry
Richtlinien: ccNSO-Richtlinienentwicklungsprozess (ICANN)
Ausführung: ICANN (IANA)
Verantwortlichkeit: ICANN-Community, ccTLD-Manager, US-Handelsministerium, (nationale Behörden in bestimmten Fällen)Ebene 2: ccTLD Registry
Richtlinien: Lokale Internet-Community, einschließlich örtlicher Regierung, und/oder ccTLD-Manager gemäß örtlicher Struktur
Ausführung: ccTLD-Manager
Verantwortlichkeit: Lokale Internet-Community, einschließlich nationale Behörden in bestimmten FällenEbene 3: Zweite Ebene und darunter
Richtlinien: Registrierer
Ausführung: Registrierer
Verantwortlichkeit: Registrierer, Benutzer von Domainnamen auf niedrigerer Ebene