Skip to main content
Resources

آليات المساءلة

هذه الصفحة متوفرة باللغات:

لقد أثبتت ICANN التزامها بالمساءلة والشفافية في كافة ممارساتها وإجراءاتها. وترى ICANN أن هذه المبادئ تعتبر إجراءات حماية أساسية في ضمان استمرار فعالية نموذجها التصاعدي لأصحاب المصلحة المتعددين. إن الآليات التي تحقق ICANN من خلالها المساءلة والشفافية تندرج في كل مستوى من مستويات تنظيمها وولايتها بدءًا من لوائحها الداخلية المفصلة في أطر عمل ومبادئ المساءلة والشفافية (التي اعتمدها مجلس إدارة ICANN في عام 2008) وتعزز سنويًا في الخطة الاستراتيجية والتشغيلية. ومن أجل تعزيز الشفافية والمساءلة، قامت ICANN بتأسيس آليات المساءلة لمراجعة إجراءات ICANN. في حين أن النصوص الكاملة لآليات المساءلة منصوص عليها في المادتين الرابعة والخامسة من لوائح ICANN الداخلية، وفيما يلي ملخص لهذه الآليات ولمحة توضيحية عنها.

عملية إعادة النظر

إعادة النظر آلية نصت عليها المادة الرابعة، القسم 2 من اللوائح الداخلية ، والتي تُجيز لأي شخص أو كيان متضرر ضررًا جوهريًا من إجراءٍ اتخذته ICANN (أو امتنعت عنه) أن يطلب مراجعة هذا الإجراء أو إعادة النظر فيه بواسطة المجلس.

يمكن لأي شخص أو كيان التقدم بطلب لإعادة النظر أو مراجعة إجراء اتخذته ICANN أو تراخت عنه ("طلب إعادة النظر") بحيث يكون ذلك الشخص أو الكيان قد تأثر سلبًا بما يلي:

  1. أي إجراءٍ أو تراخٍ من قبل العاملين قد يتنافى مع سياسات ICANN؛ أو
  2. أي إجراءٍ أو تراخٍ من قبل مجلس إدارة ICANN تم تنفيذه أو رفضه بدون النظر إلى المعلومات المادية، إلا في حال احتمال قيام مقدم الطلب بتقديمه، ولكن لم يتم تقديم المعلومات لينظر فيها المجلس وقت اتخاذ الإجراء أو رفض التصرف؛ أو
  3. أي إجراءٍ أو تراخٍ من قبل مجلس إدارة ICANN والذي تم نتيجة لاعتماد مجلس الإدارة على معلومات مادية خاطئة أو غير دقيقة.

في غياب الالتزام بهذه المعايير، لا تكون عملية إعادة النظر آلية لإعادة النظر في أي إجراءٍ (أو تراخٍ) لمجرد أن الشخص أو الكيان لا يوافق على الإجراء (أو التراخي).

يجب تقديم كافة طلبات إعادة النظر خلال خمسة عشر يومًا بعد:

  1. بالنسبة للطلبات التي تعارض أعمال مجلس الإدارة، تاريخ نشر المعلومات الخاصة بإجراء المجلس محل المعارضة لأول مرة في قرار، إلا إذا كان نشر القرار غير مصحوب بمسوغاته. وفي هذه الحالة، يجب تقديم الطلب خلال 15 يومًا من النشر الأولي للمسوغات؛ أو
  2. بالنسبة للطلبات الخاصة بمعارضة إجراءات العاملين، تكون بالتاريخ الذي أدرك فيه الطرف مقدم الطلب أو أوشك على إدراك إجراء العاملين محل المعارضة؛ أو
  3. بالنسبة للطلبات التي تعارض تراخي المجلس أو العاملين عن الإجراء، يكون بالتاريخ الذي توصل فيه الشخص المعني إلى أن الإجراء لن يُتخذ في الوقت المناسب.

تقوم اللجنة الحكومية لمجلس الإدارة (BGC) بمراجعة ودراسة طلبات إعادة النظر. بالنسبة لجميع طلبات إعادة النظر المقدمة بشأن أي إجراء أو تراخٍ من قِبل العاملين، يفوّض مجلس الإدارة لجنته الحكومية صلاحية اتخاذ قرار نهائي وتوصية بشأن هذه المسألة. ولا يكون نظر المجلس في التوصية مطلوبًا. وإذا رأت اللجنة الحكومية لمجلس الإدارة ضرورة ذلك، جاز لها أن تقدم توصية إلى المجلس للنظر فيها واتخاذ إجراء في هذا الشأن.

وتقدم اللجنة الحكومية لمجلس الإدارة قرارها النهائي أو التوصية إلى المجلس خلال ثلاثين يومًا من تاريخ استلامها لطلب إعادة النظر، ما لم يكن ذلك غير ممكن. وفي حالة تقديم توصية من اللجنة الحكومية لمجلس الإدارة إلى المجلس، يصدر المجلس قراره بناءً على توصية اللجنة الحكومية لمجلس الإدارة في غضون ستين يومًا من استلام طلب إعادة النظر أو في أقرب وقت ممكن بعد ذلك.

قررت ICANN أنه يمكن إنفاذ عملية إعادة النظر إنفاذًا صحيحًا للمعارضات على قرارات الخبراء التي تقدمها اللجان المكونة من قبل موفري خدمات فض المنازعات الخارجيين في برنامج gTLD الجديد، إذا كانت المطالبة متمثلة في عدم التزام اللجنة بالسياسات أو الإجراءات المقررة للوصول إلى قرار الخبراء أو عدم التزام العاملين بالسياسات أو الإجراءات المقررة في قبول هذا القرار.

لمزيدٍ من المعلومات حول عملية إعادة النظر الخاصة بـ ICANN، يُرجى الاطلاع على المادة الرابعة من اللوائح الداخلية على الرابط http://www.icann.org/en/about/governance/bylaws#IV أو على صفحة إعادة النظر.

عملية المراجعة المستقلة ("IRP")

بالإضافة إلى عملية إعادة النظر، قامت ICANN كذلك بتأسيس عملية منفصلة لقيام طرف خارجي بمراجعة مستقلة لإجراءات مجلس الإدارة (أو امتناعه عن اتخاذها) والتي يزعم الطرف المتضرر أنها تتعارض مع مواد تأسيس ICANN أو اللوائح الداخلية. انظر المادة الرابعة، القسم 3 من اللوائح الداخلية.

يحق لأي شخص متضرر جوهريًا من قرارٍ أو إجراءٍ اتخذه مجلس الإدارة، ويؤكد أنه يتعارض مع مواد التأسيس أو اللوائح الداخلية، أن يقدم طلبًا لمراجعة مستقلة لذلك القرار أو الإجراء. ولكي يكون الشخص متضررًا جوهريًا، يجب أن يعاني من إصابة أو ضرر يرتبط مباشرة أو عرضيًا بمخالفة مزعومة من جانب مجلس الإدارة للائحة الداخلية أو مواد التأسيس، وليس نتيجة لتصرف أطراف خارجية وفقًا لإجراءات مجلس الإدارة.

يجب تقديم طلب عملية المراجعة المستقلة خلال ثلاثين يومًا من تاريخ نشر محاضر اجتماع مجلس الإدارة (ومواد إحاطة المجلس المرفقة، إن وجدت) الذي أصبح فيه الطرف المطالب واعيًا بالإجراء الذي يؤكد أن ICANN قد خالفت لوائحها الداخلية أو مواد تأسيسها. بالنسبة لطلبات عملية المراجعة المستقلة المتعلقة بقرار اللجنة الحكومية لمجلس الإدارة على طلب إعادة النظر، يجب تقديم هذه الطلبات خلال ثلاثين يومًا من نشر محاضر اجتماع اللجنة الحكومية لمجلس الإدارة الذي تم فيه البت في المسألة.

قبل الشروع في طلب للمراجعة المستقلة، يُحث المشتكي إلى الدخول في فترة مشاركة تعاونية مع ICANN لغرض إيجاد حل أو الحد من المشكلات التي سيتم طرحها أمام عملية المراجعة المستقلة. انظر http://www.icann.org/en/news/irp/cep-11apr13-en.pdf.

لمزيدٍ من المعلومات حول عملية المراجعة المستقلة الخاصة بـ ICANN، يُرجى الاطلاع على المادة الرابعة، القسم 3 من اللوائح الداخلية على الرابط http://www.icann.org/en/about/governance/bylaws#IV أو على صفحة عملية المراجعة المستقلة.

محقق الشكاوى

يعد محقق الشكاوى في ICANN مستقلاً ومحايدًا وتكون وظيفته الأساسية هي تقديم تقييم داخلي مستقل للشكاوى المقدمة من جانب أعضاء مجتمع ICANN الذين يعتقدون أن العاملين في ICANN أو مجلس إدارتها أو إحدى الهيئات التأسيسية التابعة لها تتعامل معهم بشكل غير عادل بخصوص المسائل التي لم تصبح موضوع عملية إعادة النظر أو عملية المراجعة المستقلة. يقوم محقق الشكاوى بالعمل كمدافع موضوعي لتحقيق العدالة ويسعى لتقييم وحل شكاوى الظلم أو سوء المعاملة الواردة من قبل فريق العمل حيثما أمكن، وكذلك شكاوى المجلس أو الهيئات التأسيسية التابعة لـ ICANN، بالإضافة إلى توضيح القضايا واستخدام وسائل حل النزاع مثل التفاوض والتسهيل و"الدبلوماسية السريعة" من أجل تحقيق هذه النتائج. انظر المادة الخامسة من لوائح ICANN الداخلية.

وليس لدى محقق الشكاوى صلاحية وضع أو تغيير أو تنحية أي سياسة أو قرار إداري من مجلس الإدارة أو أي تصرف أو إغفال. ولمحقق الشكاوى صلاحية التحري عن هذه الأحداث، واستخدام آليات فض المنازعات البديلة من أجل حلها. ويكون محقق الشكاوى وحده المخول بإعداد تقارير إلى مجلس الإدارة بما يراه مناسبًا فيما يتعلق بأي مسألة معينة، وحلها أو عدم القدرة على حلها.

لمزيدٍ من المعلومات حول محقق شكاوى ICANN، يُرجى الاطلاع على المادة الخامسة من اللوائح الداخلية على الرابط http://www.icann.org/en/about/governance/bylaws#V أو على صفحة محقق الشكاوى.

ما هو المجتمع المُمكن؟

المجتمع المُمكّن هو الآلية التي من خلالها يمكن للمنظمات الداعمة (SOs) واللجان الإستشارية (ِACs) لـ ICANN أن تعمل على إنفاذ صلاحيات المجتمع المُمكن بشكل قانوني وفق قوانين ولاية كاليفورنيا . وقد تم تحديد صلاحيات وضوابط المجتمع التي تحكم المجتمع المُمكن في بنود التأسيس لمؤسسة ICANN و لوائحها.

من يستطيع المشاركة في المجتمع المُمكن؟

بإمكان كافة المنظمات الداعمة وكذلك اللجان الإستشارية العامة والحكومية المشاركة في المجتمع المُمكن وتشمل:

كيف يستخدم المجتمع المُمكن صلاحياته؟

للمجتمع المُمكن عملية لإثارة المخاوف بخصوص إتخاذ إجراء من عدمه كان قد بدر عن مجلس إدارة ICANN أو عن ICANN نفسها. عملية التصعيد هذه تعطي الفرصة للمنظمات الداعمة واللجان الاستشارية لمناقشة الحلول الممكنة مع مجلس إدارة ICANN.

للمزيد من المعلومات، أضغط هنا للوصول الى صفحة المجتمع المُمكّن.

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