Skip to main content
Resources

قرارات مجلس الإدارة المعتمدة | الاجتماع الخاص لمجلس إدارة ICANN

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

تمت ترجمة هذه الوثيقة إلى العديد من اللغات للعلم فقط. ويمكن العثور على النص الأصلي والموثوق (بالإنجليزية) في: https://www.icann.org/resources/board-material/resolutions-2016-08-09-en

  1. جدول أعمال الموافقة:
    1. الموافقة على المحضر
  2. جدول الأعمال الرئيسي:
    1. ميثاق لجنة مراجعة تطور منطقة الجذر أو RZERC
    2. عقد تأسيس PTI
    3. اتفاقية مشرف الصيانة على منطقة الجذر
    4. بنود تأسيس ICANN المعاد صياغتها
    5. توصيات منظمة دعم الأسماء العامة بشأن اعتماد خدمات الخصوصية والوكالة
    6. دراسة توصية BGC بخصوص طلب إعادة النظر 16-3 (GAY.)
    7. دراسة الإعلان النهائي لهيئة المراجعة المستقلة بين Dot Registry وICANN
    8. دراسة طلب إلغاء طلب شركة HOTEL Top-Level Domain S.a.r.l's‏ (HTLD's) بشأن HOTEL.
  3. الجلسة التنفيذية – سري
    1. تعويض مخاطر محقق الشكاوى للعام المالي 2016
    2. تعويض المسئولين

 

  1. جدول أعمال الموافقة:

    1. الموافقة على المحضر

      تقرر بموجب القرار رقم (2016.08.09.01)، موافقة المجلس على محاضر اجتماعات مجلس إدارة ICANN في 25 يونيو و27 يونيو 2016.

  2. جدول الأعمال الرئيسي:

    1. ميثاق لجنة مراجعة تطور منطقة الجذر أو RZERC

      حيث إن، ICANN وضعت ميثاق لجنة مراجعة تطور منطقة الجذر (RZERC) المقترح بالاشتراك مع فريق عمل الإشراف على التنفيذ (IOTF) ومجموعة العمل عبر المجتمعات المعنية بتسمية الوظائف ذات الصلة (الإشراف - مجموعة العمل عبر المجتمعات CWG).

      وحيث إن، الميثاق المقترح متسق مع مقترح مجموعة تنسيق عملية انتقال الإشراف على وظائف IANA (ICG) الذي اعتمده مجلس الإدارة وأحاله إلى الإدارة الوطنية للاتصالات والمعلومات (NTIA) بتاريخ 10 مارس 2016.

      وحيث إن، ICANN بدأت فترة التعليق العام من 30 يونيو 2016 حتى 10 يوليو 2016 <https://www.icann.org/public-comments/draft-rzerc-charter-2016-06-10-en> على الميثاق المقترح <https://www.icann.org/en/system/files/files/draft-rzerc-charter-10jun16-en.pdf> [بصيغة PDF،‏ 43 كيلوبايت].

      وحيث إنه، قد اختتم منتدى التعليق العام على الميثاق المقترح في 10 من يوليو 2016، مع تلقي ICANN سبعة تعليقات من الأفراد والمنظمات/المجموعات على حدٍ سواء. وبعد مراجعة هذه التعليقات، نسقت ICANN مع الأطراف المتأثرة من مجتمع ICANN لمعالجة المخاوف وتنقيح الميثاق كما يجب.

      وحيث إن، ميثاق RZERC يقتضي استدعاء ممثلٍ من مجلس إدارة ICANN للعمل مع أعضاء اللجنة.

      فقد تقرر بموجب القرار رقم (2016.08.09.02)، اعتماد المجلس لميثاق RZERC بنسخته المنقحة استجابة للتعليق العام، ويُصرّح للرئيس والمدير التنفيذي، أو من ينوب (ينوبون) عنه، اتخاذ هذه الإجراءات حسب الاقتضاء لتشكيل لجنة RZERC.

      وتقرر بموجب القرار (2016.08.09.03)، أن يعيّن مجلس الإدارة سوزان وولف للعمل ضمن لجنة RZERC.

      حيثيات القرارين 2016.08.09.02 – 2016.08.09.03

      لماذا يتناول المجلس هذه القضية الآن؟

      في 10 مارس 2016، قام مجلس الإدارة باعتماد مقترح ICG لانتقال الإشراف على وظائف IANA وإحالته إلى إدارة NTIA وتوجيه ICANN نحو متابعة خطط التنفيذ. ومن المتطلبات الواردة في الجزء الخاص بتسمية مقترح ICG تشكيل لجنة دائمة لمراجعة التغييرات المعمارية المقترحة على محتوى منطقة الجذر لنظام اسم النطاق (DNS)، والأنظمة بما فيها عناصر الأجهزة والبرامج المستخدمة في إجراء التغييرات على منطقة جذر DNS، والآليات المستخدمة في توزيع منطقة جذر DNS. وعلى اللجنة، بقدر ما يراه أعضاؤها ضروريًا، تقديم التوصيات المتصلة بهذه التغييرات للنظر فيها من قِبل مجلس إدارة ICANN. وتمثلت موافقة المجلس بناءً على توصية اللجنة في الاستبدال المقترح للإشراف على مجموعة العمل عبر المجتمعات (CWG) للدور الحالي لوكالة الوطنية الأمريكية للاتصالات والمعلومات (NTIA)، والذي سيتوقف العمل به في حالة انقضاء عقد وظائف هيئة الإنترنت للأرقام المخصصة (IANA). وكجزء من خطط التنفيذ، أطلقت ICANN على اللجنة الدائمة اسم لجنة مراجعة منطقة الجذر (RZERC).

      ما المقترح الذي يجري النظر فيه؟

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

      من تمت استشارته من أصحاب المصلحة أو غيرهم؟

      تشاورت ICANN بشأن فريق عمل الإشراف على التنفيذ (IOTF) علاوة على وظائف الإشراف على CWG في تطوير الميثاق المقترح. وأتاحت ICANN أيضًا فترة تعليقات عامة حول الميثاق المقترح من 10 يونيو 2016 حتى 10 يوليو 2016، وأعقب ذلك تلخيص وتحليل للتعليقات.

      ما المخاوف أو المسائل التي أثارها المجتمع؟

      شارك سبعة (7) أعضاء من المجتمع في فترة التعليقات العامة. وأبدى أعضاء المجتمع تخوفًا رئيسيًا في تعليقاتهم.

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

      ما المواد المهمة التي استعرضها مجلس الإدارة؟

      كجزء من مداولات مجلس الإدارة، فقد قام باستعراض مواد متنوعة، تشمل على سبيل المثال لا الحصر المواد والمستندات التالية:

      هل هناك تأثيرات مجتمعية سلبية أو إيجابية؟

      تعد موافقة المجلس على الميثاق خطوة مهمة في عملية تخطيط التنفيذ لتحقيق أحد الشروط من اقتراح (ICG) المعتمد من مجتمع أصحاب المصلحة العالميين وبموافقة مجلس الإدارة في 10 مارس 2016.

      هل توجد تأثيرات أو عواقب مالية على ICANN (الخطة الاستراتيجية أو خطة التشغيل أو الميزانية) أو المجتمع أو العامة؟

      لا يوجد أي تأثير مالي متوقع.

      هل توجد أية مشكلات تتعلق بنظام DNS من حيث الأمان أو الاستقرار أو المرونة؟

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

    2. عقد تأسيس PTI

      حيث إنه، في 14 مارس 2014، أعلنت الإدارة الوطنية للاتصالات والمعلومات (NTIA) لدى وزارة التجارة الأميركية عن نيتها لنقل مهمة الإشراف على وظائف IANA إلى المجتمع العالمي لأصحاب المصلحة المتعددين.

      وحيث إنه، في 10 مارس 2016، وافقت شركة الإنترنت للأسماء والأرقام المُخصصة (ICANN) على وثائق الانتقال التالية وأحالتها إلى NTIA: ‏(1) اقتراح انتقال دور الإشراف على وظائف IANA لمجموعة تنسيق عملية انتقال الإشراف على وظائف IANA ("اقتراح ICG") و(2) تقرير مسار العمل 1 من مجموعة العمل المجتمعية لتعزيز مساءلة ICANN (يشار إليهما مجتمعين "باقتراحي الانتقال").

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

      وحيث إن، محاميي ICANN قد عملوا بجد مع المستشار المستقل لمجموعة العمل عبر المجتمع لتطوير مقترح لانتقال الإشراف على وظائف IANA بشأن الوظائف المتعلقة بالتسمية ("إشراف CWG") لإبرام عقد التأسيس الخاص بمؤسسة PTI الجديدة. ونُشرت مسودة عقد التأسيس للحصول على التعليقات العامة لمدة 30 يومًا.

      وحيث إنه، بعد انقضاء فترة التعليقات، تم إجراء تحليل مفصّل للتعليقات وأجريت تعديلات على مواد عقد التأسيس استجابة للتعليقات العامة. ونسقت ICANN مع شركة المحاماة المستقلة بخصوص المراجعات.

      وحيث إن، المستشار العام في ICANN أكد على أن مواد عقد تأسيس PTI المقترحة تتفق مع اقتراحي الانتقال وأوصى بشروع ICANN في تشكيل الشركة التابعة للسماح باستمرار خطط التنفيذ.

      تقرر بموجب القرار رقم (2016.08.09.04)، يفوض مجلس إدارة ICANN المدير التنفيذي أو من ينوب عنه، بالشروع في تشكيل مؤسسة PTI، بما في ذلك تقديم عقد تأسيس PTI المقترح بنسخته المنقحة بعد التعليق العام.

      حيثيات القرار 2016.08.09.04

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

      يعد عقد تأسيس PTI نتاجًا لعمل جماعي للمجموعات القانونية الداخلية والخارجية جنبًا إلى جنب مع العمل الدؤوب لإشراف CWG. وتم نشر عقد تأسيس PTI في فترة تعليقات عامة مدتها 30 يومًا وجرى استلام ثلاثة تعليقات. وقد نُظر في كل تعليق وتحليله، وتم تقديم توضيح فيما لو كان عقد تأسيس PTI يتطلب إجراء تعديل لعكسها على المسائل المطروحة ضمن التعليق.

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

      واعتمد مجلس الإدارة باتخاذ هذا الإجراء على:

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

      يتماشى تفويض تشكيل PTI مع التزام ICANN بالمساءلة والشفافية. ويؤكد هذا الإجراء على التزام ICANN بتنفيذ اقتراحي الانتقال وجميع عناصر هذين الاقتراحين.

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

      وهذه المسألة عبارة عن عمل إداري تنظيمي حيث تم تلقي التعليقات العامة حولها.

    3. اتفاقية مشرف الصيانة على منطقة الجذر

      حيث إن، إدارة NTIA طلبت رسميًا أن تعمل Verisign وICANN معًا لوضع اقتراح بشأن أفضل السبل لنقل دور NTIA الإداري المرتبط بإدارة منطقة الجذر بطريقة تحافظ على أمن واستقرار ومرونة نظام اسم نطاق الإنترنت في خطابها المؤرخ 4 مارس 2015 إلى ICANN.

      حيث إن، ICANN وVerisign أرسلتا، في أغسطس 2015، اقتراحًا إلى NTIA بناءً على طلبها <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf>‏ [PDF‏، 247 كيلو بايت]. يتألف المقترح من جزأين، هما فترة الاختبار الموازية لأنظمة إدارة منطقة الجذر (RZMS) واتفاقية مسؤول صيانة منطقة الجذر (RZMA) مع Verisign بحيث تواصل Verisign القيام بوظيفة مسؤول صيانة منطقة الجذر التي تتولى مسؤوليتها اليوم بموجب اتفاقية التعاون مع وزارة التجارة.

      وحيث إن، إدارة NTIA حددت في خطابها المؤرخ 9 يونيو 2016 إلى ICANN أن الانتهاء من اتفاقية RZMA والإتمام الناجح لفترة الاختبار الموازية شرطان مسبقان لانتقال الإشراف على وظائف IANA.

      وحيث إن، إكمال اتفاقية RZMA شرط من مجموعة الاقتراحات التي وافق عليها مجلس الإدارة في 10 مارس 2016 لنقل دور إشراف NTIA على وظائف IANA إلى مجتمع أصحاب المصلحة المتعددين العالميين، وبسبب أن قيمة اتفاقية RZMA تتجاوز 500000 دولار أمريكي إجمالاً، فإن ذلك يتطلب موافقة المجلس على تفويض سلطة التوقيع إلى المدير التنفيذي.

      وحيث إن، فترة الاختبار الموازي لنظام RZMS انتهت بنجاح في 6 يوليو 2016 <https://www.icann.org/news/announcement-2016-07-14-en>.

      وحيث إن، ICANN وVerisign أنهتا المفاوضات المتعلقة بشروط اتفاقية RZMA المقترحة بحيث تقوم Verisign بوظيفة مسؤول صيانة منطقة الجذر، ونشرتا اتفاقية RZMA لفترة إشعار مدتها 30 يومًا على النحو المطلوب من قبل مقترح مجموعة تنسيق عملية انتقال الإشراف على وظائف IANA (ICG)‏ <https://www.icann.org/news/blog/root-zone-management-transition-update-preservation-of-security-stability-and-resiliency>.

      وحيث إن، اتفاقية RZMA المقترحة تتضمن أحكامًا تجمع الشروط ذات الصلة من مجموعة العمل عبر المجتمع بشأن الوظائف المتعلقة بالتسمية (إشراف CWG).

      وحيث إن، اللجنة المالية بمجلس الإدارة استعرضت الموضوعات والتبعات المالية لاتفاقية RZMA ووجدت أن (1) التكاليف المقترحة من العقد كانت معقولة، (2) وأن عملية الشراء قد جرى مراعاتها، (3) وأن التكاليف كانت ميسورة، وأوصت بموافقة المجلس كنتيجة لذلك.

      تقرر بموجب القرار رقم (2016.08.09.05)، اعتماد اتفاقية RZMA المقترحة، وتفويض الرئيس والمدير التنفيذي، أو من ينوب عنه (ينوبون عنه)، باتخاذ الإجراءات اللازمة لاستكمال الاتفاقية وإنفاذها.

      حيثيات قرارات 2016.08.09.05

      لماذا يتناول المجلس هذه القضية الآن؟

      في الخطاب المؤرخ 4 مارس 2015، طلبت إدارة NTIA رسميًا أن تعمل Verisign وICANN معًا لوضع اقتراح بشأن أفضل السبل لنقل دور NTIA الإداري المرتبط بإدارة منطقة الجذر بطريقة تحافظ على أمن واستقرار ومرونة نظام اسم نطاق الإنترنت". وفي أغسطس 2015، أرسلت ICANN وVerisign اقتراحًا إلى NTIA ردًا على طلبها <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf>‏ [PDF‏، 247 كيلو بايت]. يتألف المقترح من جزأين، هما فترة الاختبار الموازية لنظام إدارة منطقة الجذر (RZMS) واتفاقية مسؤول صيانة منطقة الجذر مع Verisign بحيث تواصل Verisign القيام بوظيفة مسؤول صيانة منطقة الجذر التي تتولى مسؤوليتها اليوم بموجب اتفاقية التعاون مع وزارة التجارة.

      يعتبر إتمام اتفاقية RZMA أحد شروط مجموعة الاقتراحات التي وافق عليها مجلس الإدارة في 10 مارس لنقل دور إشراف NTIA على وظائف IANA إلى مجتمع أصحاب المصلحة المتعددين العالميين، وبسبب أن قيمة اتفاقية RZMA تتجاوز 500000 دولار أمريكي إجمالاً، فإن ذلك يتطلب موافقة المجلس على تفويض سلطة التوقيع إلى المدير التنفيذي.

      ومنذ أغسطس الماضي، أجرت ICANN وVerisign مناقشات ومفاوضات مستمرة بشأن شروط اتفاقية RZMA. وانتهت المفاوضات في يونيو ونشرت اتفاقية RZMA المقترحة لفترة إشعار عام مدتها 30 يومًا في 30 يونيو 2016. وانتهت فترة الإشعار العام التي بلغت 30 يومًا في 30 يوليو 2016 وقد نظر المجلس في اتفاقية RZMA المقترحة للموافقة عليها.

      ما المقترح الذي يجري النظر فيه؟

      تجيز اتفاقية RZMA المقترحة لـVerisign بالاستمرار في تقديم الخدمات لصيانة منطقة الجذر وتوقيع منطقة الجذر مع منطقة الجذر (ZSK) وتوزيع ملفات منطقة الجذر على مشغلي منطقة الجذر برسوم رمزية. وتبرم اتفاقية RZMA لمدة 8 سنوات مع اتفاقيات مستوى الخدمة القوية والتي يمكن تعديلها من خلال أي عملية مراقبة تغيير إذا طلب عملاء IANA إدخال تغييرات على اتفاقيات مستوى الخدمة المذكورة. وتسمح عملية مراقبة التغيير أيضًا إدخال تغييرات في نظام إدارة منطقة الجذر التي تتطور لتلبي احتياجات المجتمع. وفي حين أن فترة الثماني سنوات لاتفاقية RZMA تهدف إلى تعزيز أمن واستقرار ومرونة عمليات صيانة منطقة الجذر من خلال استمرار Verisign في دورها، ينص الاتفاق أيضا على قدرة المجتمع، من خلال عملية يقودها المجتمع على أساس إجماع الآراء، لجعل ICANN تنتقل الوظيفة إلى مقدم خدمة آخر بعد ثلاث سنوات. وقد نُشرت اتفاقية RZMA بالكامل في فترة إشعار بلغت 30 يومًا في 30 يونيو 2016 على النحو المطلوب في اقتراح ICG ويمكن الاطلاع عليها في <https://www.icann.org/iana_imp_docs/63-root-zone-maintainer-agreement-v-1-0>.

      من تمت استشارتهم من أصحاب المصلحة أو غيرهم؟

      عملت ICANN مع المجتمع على صياغة ميثاق للجنة مراجعة منطقة الجذر، الذي نُشِر للتعليق العام من 30 يونيو إلى 30 يوليو 2016.

      ما المخاوف أو المسائل التي أثارها المجتمع؟

      لم يرد إلى عناية ICANN أي مخاوف أو مسائل مهمة خلال فترة الإشعار العام التي استمرت حتى 30 يومًا.

      ما المواد المهمة التي استعرضها مجلس الإدارة؟

      كجزء من مداولات مجلس الإدارة، فقد قام باستعراض مواد متنوعة، تشمل على سبيل المثال لا الحصر المواد والمستندات التالية:

      ما العناصر التي رآها مجلس الإدارة ذات أهمية؟

      نظر المجلس بعناية في اتفاقية RZMA للتأكد من احتوائها على الشروط التي ستسمح لـ ICANN باستيفاء متطلبات المجتمع للانتقال، على سبيل المثال:

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

      هل هناك تأثيرات مجتمعية سلبية أو إيجابية؟

      الهدف الرئيسي من اتفاقية RZMA المقترحة واستمرار الشراكة مع .Verisign, Inc لأداء وظيفة مسؤول الصيانة هو تقديم عمليات آمنة ومستقرة لمنطقة الجذر من خلال عملية انتقال الإشراف على وظائف IANA وبعدها. كما أن اعتماد المجلس لاتفاقية RZMA المقترحة يضمن مواصلة تلبية توقعات عملاء IANA.

      هل توجد تأثيرات أو عواقب مالية على ICANN (الخطة الاستراتيجية أو خطة التشغيل أو الميزانية) أو المجتمع أو العامة؟

      لقد انفردت .Verisign, Inc تاريخيًا بأداء وظيفة مسؤول الصيانة بدون مقابل مادي، ويُفضل التعاقد مع .Verisign, Inc مباشرة على مواصلة أداء هذا العمل لضمان تحقيق الاستمرارية والأمان والاستقرار خلال فترة الانتقال. تخوّل شروط اتفاقية RZMA للمجتمع، من خلال عملية تستند على الإجماع بقيادة المجتمع، الحق في جعل ICANN تنقل وظيفة مسؤول الصيانة إلى مقدم خدمة آخر. يعيّن هذا العقد رسمًا سنويًا رمزيًا قدره 300000 دولارٍ أمريكي كمستحقات سنوية لشركة .Verisign, Inc مقابل أداء وظيفة مسؤول الصيانة. وقد راجعت اللجنة المالية لمجلس الإدارة الجوانب المالية وتداعيات اتفاقية RZMA المقترحة ومن ثم أوصت مجلس إدارة ICANN باعتماد اتفاقية RZMA، بناءً على هذه المراجعة.

      هل توجد أية مشكلات تتعلق بنظام DNS من حيث الأمان أو الاستقرار أو المرونة؟

      يضمن اعتماد المجلس لاتفاقية RZMA المقترحة استمرار تشغيل منطقة الجذر وأمنه واستقراره خلال فترة الانتقال وبعدها.

    4. بنود تأسيس ICANN المعاد صياغتها

      حيث إنه، في 14 مارس 2014، أعلنت الإدارة الوطنية للاتصالات والمعلومات (NTIA) لدى وزارة التجارة الأميركية عن نيتها لنقل مهمة الإشراف على وظائف IANA إلى المجتمع العالمي لأصحاب المصلحة المتعددين.

      وحيث إنه، في 10 مارس 2016، وافقت شركة الإنترنت للأسماء والأرقام المخصصة (ICANN) على وثيقتي الانتقال وأحالتهما إلى الوكالة الوطنية الأمريكية للاتصالات والمعلومات، وهما: (1) اقتراح انتقال دور الإشراف على وظائف IANA لمجموعة تنسيق عملية انتقال الإشراف على وظائف IANA ("اقتراح ICG") و(2) تقرير مسار العمل 1 من مجموعة العمل المجتمعية لتعزيز مساءلة ICANN (يشار إليهما مجتمعين "باقتراحي الانتقال").

      وحيث إنه، يلزم إعادة صياغة عقد تأسيس ICANN لكي يتوافق مع لوائح ICANN الداخلية وللاتساق مع "اقتراحي الانتقال".

      وحيث إن، محاميي ICANN قد عملوا بجد مع المستشار المستقل لمجموعة العمل عبر المجتمعات لتعزيز مساءلة ICANN (مساءلة CCWG) لإعادة صياغة عقد تأسيس ICANN. وقد نُشر عقد التأسيس المعاد صياغته وطُرح للتعليق العام لمدة تتجاوز 40 يومًا.

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

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

      فقد تقرر بموجب القرار رقم (2016.08.09.06) اعتماد مجلس إدارة ICANN للتعديلات المقترحة على عقد تأسيس ICANN، وأن يسري ذلك اعتبارًا من انتهاء سريان عقد وظائف IANA بين ICANN وNTIA.

      كما تقرر بموجب القرار رقم (2016.08.09.07)، أن يفوض مجلس إدارة ICANN المدير التنفيذي أو من ينيبه، بمتابعة تقديم عقد التأسيس المعاد صياغته بمجرد سريانه.

      حيثيات القرارين 2016.08.09.06 – 2016.08.09.07

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

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

      وكانت التغييرات المقترحة على مسودة عقد التأسيس استنادًا إلى التعليقات محدودة.

      واعتمد مجلس الإدارة باتخاذ هذا الإجراء على:

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

      ويتوافق اعتماد هذا العقد مع التزام ICANN تجاه المساءلة والشفافية، حيث إن هذا يكمّل وثيقة الحوكمة الأساسية التي يجب على ICANN تطبيقها لتزويد المجتمع بأدوات المساءلة الحديثة والمعززة. ويؤكد هذا الإجراء على التزام ICANN باعتماد تغييرات المساءلة.

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

      وهذه المسألة عبارة عن عمل إداري تنظيمي حيث تم تلقي التعليقات العامة حولها.

    5. توصيات منظمة دعم الأسماء العامة بشأن اعتماد خدمات الخصوصية والوكالة

      حيث إنه، في 31 أكتوبر، وافق مجلس GNSO على الميثاق الخاص بمجموعة عمل من شأنها وضع عملية تطوير السياسة التي تم طلبها من قبل مجلس ICANN بشأن اعتماد ICANN لمقدمي خدمات الخصوصية وتسجيل اسم نطاق الوكالة كما هو مذكور على http://gnso.icann.org/en/drafts/raa-pp-charter-22oct13-en.pdf‏ [PDF‏، 463 كيلوبايت].

      وحيث إنه، تبعت PDP خطوات عملية وضع السياسة (PDP) المنصوص عليها على النحو المحدد في لوائح ICANN، الأمر الذي نتج عنه تقرير نهائي تم تسليمه إلى مجلس GNSO بتاريخ 8 ديسمبر 2015.

      وحيث إن، مجموعة عمل عملية وضع سياسة مسائل اعتماد خدمات الخصوصية والوكالة توصلت إلى إجماع كامل على جميع توصياتها النهائية (يرجى الاطلاع على http://gnso.icann.org/en/issues/raa/ppsai-final-07dec15-en.pdf بصيغة [PDF‏، 1.24 ميغابايت]).

      وحيث إن، مجلس GNSO قام بمراجعة ومناقشة توصيات مجموعة عمل عملية وضع سياسة مسائل اعتماد خدمات الخصوصية والوكالة وتبني التوصيات في 21 يناير 2016 بالإجماع وبأغلبية الأصوات (انظر http://gnso.icann.org/en/council/resolutions - 201601.)

      وحيث إن، تصويت مجلس GNSO تخطى حدود التصويت المطلوبة (أي بأغلبية ساحقة) لفرض التزامات جديدة على الأطراف المتعاقدة مع ICANN.

      وحيث إنه، اعتمادًا على لوائح ICANN الداخلية، تم فتح فترة التعليق العام على التوصيات الموافق عليها لمنح المجتمع فرصة معقولة للتعليق على اعتمادها قبل اتخاذ الإجراءات من جانب مجلس إدارة ICANN، والتعليقات الواردة التي تم مراجعتها وذكرها (أنظر https://www.icann.org/en/system/files/files/report-comments-ppsai-recommendations-31mar16-en.pdf بصيغة [PDF‏، 299 كيلوبايت]).

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

      وحيث إنه، أبلغ المجلس GAC بنشر توصيات GNSO النهائية للتعليق العام بتاريخ 19 فبراير 2016 (أنظر https://gacweb.icann.org/download/attachments/27492514/2016-02-19-Steve-Crocker-to-Thomas-Schneider-GNSO-PDP.pdf?version=1&modificationDate=1456046942000&api=v2 بصيغة [PDF‏، 819 كيلوبايت]).

      وحيث إن، لجنة GAC نصحت مجلس إدارة ICANN في بيان مراكش الصادر في 9 مارس لعام 2016 أنها بحاجة إلى المزيد من الوقت للنظر في اهتمامات السياسة العامة المحتملة المتعلقة باعتماد توصيات PDP النهائية، والإشارة إلى أن اجتماع ICANN 56 لعام 55 سيكون فرصة مهمة لمواصلة النظر في هذه البنود (انظر https://gacweb.icann.org/download/attachments/28278854/GAC Morocco 55 Communique FINAL.pdf?version=1&modificationDate=1458046221000&api=v2 بصيغة [PDF‏، 567 كيلوبايت]).

      وحيث إنه، في 15 مايو 2016، أقر المجلس بتلقي توصيات عملية وضع السياسات لمنظمة GNSO وعزم على النظر فيها في اجتماعه الأول بعد اجتماع ICANN56 لتمكين لجنة GAC من تقديم المشورة في الوقت المناسب، إن وجدت (انظر https://www.icann.org/resources/board-material/resolutions-2016-05-15-en - 2.a).

      وحيث إنه، نصحت لجنة GAC في بيانها الصادر بهلسنكي في 30 يونيو 2016 مجلس إدارة ICANN بإصدار توجيه يقضي بوجوب مناقشة مخاوف لجنة GAC إلى أقصى حد ممكن عمليًا بواسطة فريق مراجعة التنفيذ الذي يجب أن ينعقد لتنفيذ التوصيات المعتمدة (انظر https://gacweb.icann.org/display/gacweb/Governmental+Advisory+Committee?preview=/27132037/43712639/20160630_GAC%20ICANN%2056%20Communique_FINAL%20.pdf بصيغة [PDF‏، 328 كيلوبايت]).

      تقرر بموجب القرار رقم (2016.08.09.08)، يتبنى المجلس جميع التوصيات النهائية لمجموعة عمل عملية وضع سياسة مسائل اعتماد خدمات الخصوصية والوكالة، باعتبار أنها تم إقرارها بموافقة جميع أعضاء مجلس GNSO في 21 يناير 2016 ("توصيات سياسة الخصوصية والوكالة")

      تقرر بموجب القرار رقم (2016.08.09.09)، يوجّه مجلس الإدارة الرئيس والمدير التنفيذي، أو من ينوب عنه بالتفويض، بوضع وإكمال خطة تنفيذ، بما في ذلك التكاليف والجداول الزمنية، لتوصيات سياسة الخصوصية والوكالة التي توافق لوائح ICANN الملحق أ وقواعد وتوجيهات فريق مراجعة التنفيذ المصدق عليها من قبل مجلس الإدارة في 28 سبتمبر 2015 (انظر https://www.icann.org/resources/board-material/resolutions-2015-09-28-en - 2.f)، وللاستمرار في التواصل مع المجتمع في مثل هذا العمل. وفي حال نشأت مسائل تتعلق بالسياسة في سياق مناقشات التنفيذ، يتم إحالتها إلى GNSO وفقًا لإطار عمل التنفيذ المرتبط بتوصيات سياسة GNSO، بما في ذلك قواعد وتوجيهات فريق مراجعة التنفيذ.

      تقرر بموجب القرار رقم (2016.08.09.10)، يقر المجلس بمشورة لجنة GAC الواردة من بيان هلسنكي بشأن توصيات سياسة الخصوصية والوكالة. وسوف يأخذ المجلس مشورة لجنة GAC في الاعتبار ويقدم مدخلات إلى فريق مراجعة التنفيذ للنظر في خطة التنفيذ.

      حيثيات القرارين 2016.08.09.08 – 2016.08.09.10

      لماذا يناقش مجلس الإدارة هذه القضية الآن؟

      مع البدء في المفاوضات مع مجموعة أصحاب المصلحة لإعداد صيغة جديدة من اتفاقية اعتماد أمين السجل (RAA) في أكتوبر 2011، طلب مجلس ICANN أيضًا تقرير مشكلات من GNSO يبدأ في عملية وضع سياسات (PDP) لـ GNSO فور الانتهاء من مفاوضات RAA وذلك للتعامل مع المشكلات المتبقية التي لم يتم التعامل معها في مفاوضات RAA. وفي يونيو 2013، اعتمد مجلس إدارة ICANN اتفاقية اعتماد أمين السجل RAA جديدة لعام 2013 وتم تحديد موضوع خدمات الخصوصية ووكيل الاعتماد باعتبارها القضية الوحيدة التي ينبغي حلها من خلال GNSO PDP. تم الإشارة إلى هذا الموضوع من قبل فريق مراجعة Whois والذي تم نشره في شهر مايو لعام 2012، حيث أشار الفريق إلى النقص الحالي في القواعد الواضحة والمتسقة المتعلقة بالخدمات، مما أدى إلى نتائج لا يمكن التنبؤ بها للجهات المعنية. ويعتقد فريق المراجعة أن التنظيم والرقابة المناسبة على هذه الخدمات من شأنه تلبية احتياجات أصحاب المصلحة ومخاوفهم وأوصى بالنظر بنظام اعتماد خاص لـICANN. سيتم تغطية جوانب معينة من الخدمات المرحلية لمواصفات RAA لعام 2013 حتى يتم وضع برنامج الاعتماد، والذي من المقرر أن ينتهي في 1 يناير 2017 أو تنفيذ برنامج الاعتماد من قبل ICANN أيهما يحل أولاً.

      وافق مجلس GNSO على جميع التوصيات النهائية الواردة من التقرير النهائي لمجموعة عمل PDP الصادر بتاريخ 8 ديسمبر 2015 في الاجتماع الذي عقد بتاريخ 21 يناير 2016، بالإضافة إلى تقرير توصيات صادر من المجلس في فبراير 2016. وقد تم افتتاح فترة التعليق العام وفقًا للوائح ICANN لتسهيل مشاركة الجمهور بشأن اعتماد التوصيات التالية وعقب ذلك تم توجيه توصيات PDP إلى المجلس لإبداء وجهة نظره. وفي 15 مايو 2016، عزم المجلس على النظر في اتخاذ إجراءات بخصوص التوصيات في الاجتماع الأول بعد اجتماع ICANN56 في هلسنكي لتمكين لجنة GAC من تقديم المشورة في الوقت المناسب فيما يتعلق بمخاوف السياسة العامة التي أثارتها توصيات PDP، إن وجدت. نصحت لجنة GAC في بيانها الصادر بهلسنكي مجلس الإدارة بإصدار توجيه يقضي بمعالجة مخاوف لجنة GAC إلى أقصى حد ممكن عمليًا أثناء مرحلة تنفيذ توصيات PDP.

      ما المقترح الذي يجري النظر فيه؟

      تشمل توصيات سياسة GNSO الحد الأدنى للمتطلبات الإلزامية لتشغيل خدمات الخصوصية والوكالة، والحفاظ على نقاط اتصال معينة للإبلاغ عن حالات الإساءة ونشر قائمة مقدمي الخدمة المعتمدين، والمتطلبات المتعلقة بمعالجة طلبات الكشف و/أو نشر تفاصيل الاتصال بالعميل من قبل بعض مقدمي الطلبات من الطرف الثالث، والشروط المتعلقة بالإفصاح عن ونشر مثل هذه التفاصيل، فضلًا عن رفض الكشف أو نشر المبادئ التي تحكم مقدمي الخدمات. ويمكن الاطلاع على القائمة الكاملة ونطاق التوصيات النهائية في المرفق أ من توصيات تقرير مجلس GNSO لمجلس الإدارة (انظر http://gnso.icann.org/en/drafts/council-board-ppsai-recommendations-09feb16-en.pdf بصيغة [PDF‏، 491 كيلو بايت].

      من الذي تمت استشارته من أصحاب المصلحة أو غيرهم؟

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

      بعد تقديم لجنة GAC للمشورة في بيانها الصادر بمراكش في 9 مارس 2016 وقرار مجلس الإدارة في 15 مايو 2016، انعقدت المناقشات أيضًا بين المجلس والمجتمع بخصوص هذا الموضوع في اجتماع ICANN56 في هلسنكي، فنلندا

      ما المخاوف أو المسائل التي أثارها المجتمع؟

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

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

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

      ما المواد المهمة التي استعرضها مجلس الإدارة؟

      قام المجلس باستعراض التقرير النهائي لمجموعة عمل PDP، وتقرير بتوصيات مجلس GNSO بخصوص الموضوع المقدم إلى مجلس الإدارة وملخص التعليقات العامة التي تم استلامها في فترة التعليقات العامة التي فتحت عقب تبني مجلس GNSO التوصيات الواردة في التقرير النهائي، وأخيرًا المشورة التي قدمتها GAC بخصوص هذا الموضوع، على النحو المنصوص عليه في البيانين الصادرين في مراكش وهلسنكي.

      ما البنود ذات الأهمية بالنسبة لمجلس الإدارة؟

      لقد تم وضع التوصيات باتباع عملية GNSO لوضع السياسة كما هو مبين في الملحق أ من لوائح ICANN الداخلية، وقد نالت الدعم بالإجماع من مجلس GNSO. كما هو مبين في لوائح ICANN الداخلية، فإن دعم مجلس بالإجماع يُلزم مجلس الإدارة بتبني التوصية بتصويت يبلغ أكثر من الثلثين، وقرر مجلس الإدارة أن السياسة لا تحقق المصلحة الفضلى لمجتمع ICANN وICANN.

      تسمح اللوائح للمدخلات من قبل GAC والتي تتعلق بمخاوف السياسة العامة التي سيتم إثارتها إذا تم تبني السياسة المقترحة من قبل المجلس. وأثارت لجنة GAC هذه الاحتمالية فيما يتعلق بـPDP هذه فضلاً عن أن المجلس سوف يواصل النظر في المشورة المقدمة من لجنة GAC.

      هل هناك تأثيرات مجتمعية سلبية أو إيجابية؟

      أن تطوير برنامج الاعتماد الكامل لمقدمي خدمة الخصوصية والوكالة ستتطلب موارد كبيرة وستأخذ فترة طويلة من الزمن. ومن المرجح أن المواصفات المرحلية الواردة في اتفاقية اعتماد أمين السجل (RAA) لعام 2013 تحتاج إلى تمديد بعد انقضاء تاريخ صلاحيتها الحالي في 1 يناير 2017، حتى يتسنى تطوير مثل هذا البرنامج.

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

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

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

      هل توجد تأثيرات أو عواقب مالية على ICANN (الخطة الاستراتيجية أو خطة التشغيل أو الميزانية) أو المجتمع أو العامة؟

      قد توجد آثار مالية على ICANN ترتبط بإنشاء برنامج الاعتماد الجديد الذي يشمل على وجه الخصوص مزودي خدمات الخصوصية والوكالة. ويجب أن تأخذ خطة التنفيذ في الحسبان التكاليف والأطر الزمنية للتنفيذ. وبما أنه من المقرر انتهاء المواصفات المرحلية الحالية في اتفاقية RAA المنطبقة مع هذه الخدمات في 1 يناير عام 2017، فسوف تستلزم الدراسة تمديد مدتها حال اعتماد توصيات PDP.

      هل توجد أية مشكلات تتعلق بنظام DNS من حيث الأمان أو الاستقرار أو المرونة؟

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

    6. دراسة توصية BGC بخصوص طلب إعادة النظر 16-3 (GAY.)

      تمت إزالة البند من جدول الأعمال.

    7. دراسة الإعلان النهائي لعملية المراجعة المستقلة بين Dot Registry وICANN

      حيث إنه، في 29 يوليو 2016، أصدرت هيئة إجراء المراجعة المستقلة (IRP) (الهيئة) إعلانها النهائي في إجراء المراجعة المستقلة IRP المقدم من Dot Registry, LLC ‏(Dot Registry) ضد ICANN (الإعلان النهائي).

      وحيث إن، أغلبية الهيئة أعلنت أن "الإجراءات التي اتخذها مجلس الإدارة والتي تقاعس عن اتخاذها كانت غير متوافقة مع عقد تأسيس ICANN ولوائحها الداخلية"، إذ إن "المجلس (من خلال لجنة BGC) أهمل بذل العناية الواجبة والحرص على تقديم قدرٍ معقول من الحقائق، كما أنه لم يفِ بالتزامات الشفافية"، وأن الأدلة المقدمة للهيئة لم تؤيد قرارًا يقضي بأن يكون المجلس (من خلال لجنة BGC) قد استند في قرارات إعادة النظر على أحكام مستقلة. (راجع الإعلان النهائي، ¶¶ 151-152.)

      وحيث إن، أغلبية الهيئة أعلنت كذلك أن "Dot Registry هي الطرف المتقدم" وأنه على ICANN أن تسدد لـ Dot Registry مبلغًا قدره 235294.37 دولارٍ أمريكي حال "إثبات أنه قد تم سداد هذه التكاليف المفروضة كافة". (المصدر نفسه. ¶ 154.)

      وحيث إن، "أغلبية الهيئة رفضت أن تستبدل بحكمها حكم CPE بشأن ما إذا كانت Dot Registry لها أولوية المجتمع". (نفس المصدر في ¶ 153.)

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

      وحيث إن، Dot Registry صرحت في خطابٍ مرسل إلى مجلس الإدارة، ضمن تصريحات أخرى، أن تقريرها الصادر في 90 صفحة كان كافيًا ومقنعًا لمساعدة المجلس في حسم الأمر بتمرير طلبات Dot Registry في تقييم CPE، وقد ناشدت التقرير ICANN مواصلة التعاقد مع Dot Registry على INC. وLLC. وLLP. (راجع https://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-06aug16-en.pdf‏ [PDF‏، 1.5 ميجابايت]).

      وحيث إن، الهيئة نظرت في معيار المراجعة الحالي الذي تعتمده BGC في مراجعة طلبات إعادة النظر وأبدت اعتراضها عليه.

      وحيث إنه، وفقًا للمادة الرابعة، القسم 3.21 من لوائح ICANN الداخلية، نظر المجلس في الإعلان النهائي.

      فقد تقرر بموجب القرار رقم (2016.08.09.11)، موافقة مجلس الإدارة على استنتاجات الإعلان النهائي المتمثلة في الآتي: (1) إن Dot Registry هي الطرف المتقدم في النزاع القائم بين Dot Registry, LLC ضد هيئة IRP التابعة لـ ICANN؛ وأنه (2) على ICANN أن تسدد لـ Dot Registry مبلغًا قدره 235294.37 دولارٍ أمريكي حال إثبات أنه قد تم سداد هذه التكاليف المفروضة كافة.

      كما تقرر بموجب القرار رقم (2016.08.09.12)، وبعد مراجعة المجلس للاستنتاجات الأخرى في الإعلان والاستنتاجات المتعلقة ببيانات أغلبية الهيئة بخصوص معيار مراجعة طلبات إعادة النظر المشار إليها أعلاه، أن ينظر المجلس في الخطوات التالية فيما يتعلق بطلبات Dot Registry لإعادة النظر أو نطاقات gTLDs قبل أن يتخذ المجلس أي إجراء آخر.

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

      حيثيات القرارين 2016.08.09.11 – 2016.08.09.13

      أطلقت Dot Registry, LLC‏ (Dot Registry) إجراءات عملية المراجعة المستقلة (IRP) معترضة على رفض اللجنة الحكومية لمجلس الإدارة (BGC) طلبات إعادة النظر الخاصة بـ Dot Registry بشأن تقارير تقييم أولوية المجتمع (CPE) التي استنتجت عدم تقدم طلبات Dot Registry لكل من INC. وLLC. وLLP. على التوالي في تقييم CPE.

      وتقدمت Dot Registry بطلب إتاحة الفرصة لها لتشغيل نطاقات المستوى الأعلى الجديدة LLC. وINC. وLLP. وتعد Dot Registry أحد المتقدمين التسع لنطاق LLC.، وأحد المتقدمين الأحد عشر لنطاق INC.، وأحد المتقدمين الأربعة لنطاق LLP. غير أن Dot Registry تعد المتقدم الوحيد الذي قدم طلبات مجتمعية لهذه النطاقات gTLDs.

      قررت هيئات CPE القائمة على تقييم طلبات Dot Registry أن الطلبات لم تستوفي المعايير اللازمة للتقدم في تقييم CPE، مانحة إياها خمس نقاط فقط من 14 نقطة لازمة للتقدم في تقييم CPE (تقارير CPE). وقامت Dot Registry بتقديم طلبات إعادة النظر رقم 14-30 و14-32 و14-33، ملتمسة إعادة النظر في تقارير CPE. وفي 24 يوليو 2014، رفضت اللجنة الحكومية لمجلس الإدارة (BGC) طلبات إعادة النظر، حيث إنها رأت أن Dot Registry "لم تثبت أن الهيئات انتهكت السياسة المقررة أو الإجراء المعمول به في إعداد تقارير CPE…."

      أطلقت Dot Registry هذا الإجراء IRP في 22 سبتمبر 2014، معترضة على رفض لجنة BGC لطلبات إعادة النظر الخاصة بـ Dot Registry، وعلى ما يبدو أنها معترضة كذلك على تعيين ICANN لوحدة الاستخبارات الاقتصادية (EIU) المزود الخارجي لإجراء تقييمات CPE، وعلى استجابة المجلس لمشورة مقدمة من اللجنة الاستشارية الحكومية لـ ICANN بخصوص نطاقات LLC. وINC. وLLP.

      في قرار 2-1، أعلنت أغلبية الهيئة أن Dot Registry ستكون الطرف المتقدم، وقررت أن "الإجراءات التي اتخذها المجلس والتي تقاعس عن اتخاذها كانت غير متوافقة مع عقد تأسيس ICANN ولوائحها الداخلية." (الإعلان النهائي في¶ 151.) ولاسيما أن أغلبية الهيئة أعلنت أن "المجلس (من خلال لجنة BGC) أهمل بذل العناية الواجبة والحرص على تقديم قدرٍ معقول من الحقائق، كما أنه لم يفِ بالتزامات الشفافية"، وأنه لم تُقدم أدلة كافية للهيئة تؤيد قرارًا يقضي بأن يكون المجلس (من خلال لجنة BGC) قد استند في قرارات إعادة النظر على أحكام مستقلة. (نفس المصدر في ¶¶ 151-152.) وكذلك أعلنت أغلبية الهيئة أن "على ICANN أن تسدد لـ Dot Registry, LLC مبلغًا قدره 235294.37 دولارٍ أمريكي تعويضًا لها عن الرسوم والمصروفات المذكورة التي تكبدتها Dot Registry, LLC حال القرار بأنه قد تم سداد هذه التكاليف المفروضة كافة". (نفس المصدر في ¶ 154.)

      وقد نوه مجلس الإدارة إلى أن أغلبية الهيئة صرحت أنه "في معرض التوصل إلى هذه الاستنتاجات، لم تقيم الهيئة ما إذا كان موظفو ICANN أو وحدة EIU تقاعسوا بأنفسهم عن الامتثال للالتزامات المفروضة بموجب عقد التأسيس أو اللوائح الداخلية أو [دليل مقدم الطلب (الدليل)]." (نفس المصدر في ¶ 152.) كما تجدر الإشارة كذلك إلى أن "أغلبية الهيئة رفضت أن تستبدل بحكمها حكم CPE بشأن ما إذا كانت Dot Registry لها أولوية المجتمع". (نفس المصدر في ¶ 153.)

      أغلبية الهيئة لم تنظر في معيار المراجعة الحالي المعتمد لدى BGC في مراجعة طلبات إعادة النظر أو تبدي اعتراضها عليه، بل صرحت بأنها اعتقدت أن المعيار الذي تطبقه لجنة BGC في "تقييم طلب إعادة النظر" ينبغي أن يكون متوقفًا على هذا السؤال: "هل الإجراء المتخذ متوافق مع عقد التأسيس واللوائح الداخلية و[الدليل]؟" (نفس المصدر في ¶ 79.) كما أشارت أغلبية الهيئة كذلك إلى أنه في مراجعة طلبات إعادة النظر، "يجب على BGC أن تحدد ما إذا كانت CPE (المتمثلة في وحدة EIU في هذه الحالة) وموظفو ICANN قد احترموا مبادئ النزاهة والشفافية وتجنب تضارب المصالح وعدم التمييز المبينة في عقد تأسيس ICANN واللوائح الداخلية و[الدليل]" (نفس المصدر في ¶ 88) كما أشارت إلى أن الأطراف الخارجية مثل EUI "ملزمة بالامتثال لعقد تأسيس ICANN ولوائحها الداخلية." (نفس المصدر في ¶ 101.)

      يقر المجلس البيانات المهمة التي أدلت بها الهيئة فيما يتعلق بمعيار المراجعة بشأن طلبات إعادة النظر وأنه سينظر في الخطوات التالية المتعلقة بطلبات إعادة النظر بشأن Dot Registry أو نطاقات gTLD الجديدة قبل أن يتخذ المجلس أي إجراء إضافي.

      نظر المجلس الإعلان النهائي كما هو مطلوب. وكما أشار هذا المجلس سابقًا، يتعامل المجلس بجدية شديدة مع نتائج واحدة من آليات المساءلة طويلة الأمد في ICANN.

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

      يلاحظ المجلس أيضًا أنه تلقى خطابًا من Dot Registry بتاريخ 6 أغسطس 2016 توضح فيه -من بين أمور أخرى- أن "تقرير الخبير المكون من 90 صفحة" "كاف وملزم بمساعدة المجلس" في إقرار أن طلبات Dot Registry قد اجتازت CPE" وتطالب بأن تقوم ICANN "بمتابعة عملية التعاقد مع Dot Registry بالنسبة للنطاقات INC. وLLC. وLLP." (انظر الملحق ح للمواد المرجعية وhttps://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-06aug16-en.pdf‏ [PDF‏، 1.5 ميغابايت].) ويبدي المجلس رغبته في التأكيد على أن غالبية أعضاء الهيئة رفضوا إحلال قرارها محل قرار CPE بشأن ما إذا كانت Dot Registry مؤهلة للحصول على أولوية المجتمع." (نفس المصدر في ¶ 153.)

      علاوة على ذلك، يلاحظ المجلس أنه توجد عدة طلبات أخرى لم يُبت فيها بشأن نطاقات gTLD هذه (تسعة تخص INC.، وثمانية تخص LLC.، وثلاثة تخص LLP.)، ويجب أخذ هذا أيضًا بعين الاعتبار. وعليه، كما سبق الإشارة إليه أعلاه، سينظر المجلس في الخطوات التالية قبل اتخاذ أي قرارات إضافية بشأن طلبات إعادة النظر الخاصة بـ Dot Registry أو طلبات INC. أو LLC. أو LLP.

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

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

      يُشَار إلى أن هذا الإجراء يمثل وظيفة إدارية هيكلية ولا يتطلب تعليقات عامة.

    8. دراسة طلب إلغاء طلب شركة HOTEL Top-Level Domain S.a.r.l's‏ (HTLD's) لنطاق HOTEL.

      حيث إن، كل من Travel Reservations SRL‏ (Despegar Online SRL سابقًا) وFamous Four Media Limited وFegistry LLC وMinds + Machines Group Limited و.Donuts Inc وRadix FZC (يُشار إليهم مجتمعين بمطالبي HOTEL.) طالبوا ICANN بإلغاء طلب شركة HOTEL Top-Level Domain S.a.r.l's‏ (HTLD's) لنطاق HOTEL.

      وحيث إن، طلب مطالبي HOTEL. يستند إلى علاقات عمل ديرك كريشينوسكي الواضحة بـ HTLD، إضافة إلى استغلاله لمسألة البوابة التي أتاحت للأطراف الوصول إلى معلومات سرية للمتقدمين لنطاقات gTLD الجديدة، بما فيها المعلومات الخاصة بالعديد من مطالبي HOTEL.

      وحيث إن، تحقيق ICANN الجنائي لمسألة البوابة كشف أن وصول السيد كريشينوسكي غير المصرح به إلى المعلومات السرية لم يتم حتى قدمت HTLD طلبها في 2012 وبعد أن انتخبت HTLD للمشاركة في CPE بتاريخ 19 فبراير 2014.

      وحيث إن، ICANN لم تكشف عن أي دليل بثبت أن: (1) المعلومات التي قد يكون السيد كريشينوسكي قد حصل عليها نتيجة لمسألة البوابة استخدمت لدعم طلب HTLD بشأن HOTEL.؛ أو (2) أي معلومات حصل عليها السيد كريشينوسكي مكَّنت طلب HTLD من تحقيق أغلبية في CPE.

      تقرر بموجب القرار رقم (2016.08.09.14)، خلص المجلس إلى أن إلغاء طلب HTLD بشأن HOTEL. غير مضمون.

      تقرر بموجب القرار رقم (2016.08.09.15)، يوجه المجلس الرئيس والمدير التنفيذي أو من ينوب/ينوبون عنه بالمضي قدمًا في معالجة طلب HTLD بشأن HOTEL.

      حيثيات القرارين 2016.08.09.14 – 2016.08.09.15

      تقدم كل من HTLD ومطالبي HOTEL. لـ HOTEL. وحفظت كلها في مجموعة احتجاج. وبما إن طلب HTLD كان مجتمعيًا، تمت دعوتها للمشاركة بطلبها في تقييم أولوية المجتمع (CPE) في 19 فبراير 2014. حققت HTLD أغلبية في CPE بتاريخ 11 يونيو 2014، مستبعدة مطالبي HOTEL. من الاستمرار في العملية.

      ودفع مطالبو HOTEL. بأن استغلال السيد كريشينوسكي لمسألة البوابة التي أتاحت للأطراف الوصول إلى معلومات سرية للمتقدمين لنطاقات gTLD الجديدة، بما فيها المعلومات الخاصة بالعديد من مطالبي HOTEL. إضافة إلى اعتماده على علاقات العمل الواضحة التي تجمعه بـ HTLD كان السبب وراء إلغاء ICANN لطلب HOTEL. الخاص بـ HTLD.

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

      وفيما يخص الادعاءات بشأن ارتباط السيد كريشينوسكي بـ HTLD عندما تحصل على المعلومات السرية، علمت ICANN أنه لم تكن تجمعه صلة مباشرة بطلب HTLD لنطاق HOTEL. بصفته جهة اتصال مصرحة أو مساهمًا أو مسؤولًا أو مديرًا. كان السيد كريشينوسكي مساهمًا بنسبة 50% وعضوًا منتدبًا لشركة HOTEL Top-Level-Domain GmbH, Berlin‏ (GmbH Berlin) والتي كانت مساهمًا صغيرًا (بنسبة 48.8%) في HTLD.

      ولم تكشف ICANN عن أي دليل يثبت أن: (1) المعلومات التي قد يكون السيد كريشينوسكي حصل عليها نتيجة لمسألة البوابة استخدمت لدعم طلب HTLD لـ HOTEL.؛ أو (2) أي معلومات حصل عليها السيد كريشينوسكي مكَّنت طلب HTLD من تحقيق أغلبية في CPE. قدمت HTLD طلبها في 2012 وانتخبت للمشاركة في CPE بتاريخ 19 فبراير 2014 وحظيت بالأغلبية في CPE بتاريخ 11 يونيو 2014. لم تحدث الحالة الأولى من وصول السيد كريشينوسكي غير المصرح به إلى المعلومات السرية حتى وقت مبكر من شهر مارس 2014 ولم تحدث عمليات البحث المتعلقة بمطالبي HOTEL. حتى 27 مارس و29 مارس و11 أبريل 2014. وعليه، فإن مجرد افتراض أن السيد كريشينوسكي اطلع على المعلومات السرية الخاصة بمطالبي HOTEL.، لن يكون لهذا الاطلاع أي تأثير على عملية CPE لطلب HTLD لنطاق HOTEL. فسواء كان طلب HTLD الذي لبى معيار CPE مستندًا إلى الطلب المقدم في مايو 2012 أو عندما حملت المستندات الأخيرة التي عدلت الطلب في 30 أغسطس 2013 - فقد حدث ذلك قبل أن يطلع السيد كريشينوسكي أو شركاؤه على أي معلومات سرية والذي حدث في الفترة من مارس وحتى أكتوبر 2014. إضافة إلى ذلك، ليس هناك دليل أو ادعاء من مطالبي HOTEL. بشأن وجود أي تفاعل بين لجنة CPE والسيد كريشينوسكي أو HTLD أثناء عملية CPE التي بدأت في 19 فبراير 2014.

      وزيادة في تأكيد قرار المجلس بتاريخ 10 مارس 2016 الذي "يلزم رئيس ICANN ومديرها التنفيذي أو من ينوب عنه باستكمال التحقيق الخاص بالمسائل المزعومة بشأن تكوين البوابة على وجه السرعة ورفع تقرير إلى المجلس لنظره بعد الانتهاء من التحقيق" (انظر قرارات المجلس في 10 مارس 2016، المتوفرة على https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a)، وقامت ICANN بإعلام HTLD بطلب مطالبي HOTEL. بإلغاء طلب HTLD للنطاق HOTEL. ومنحتها فرصة للرد وطلبت معلومات من HTLD بشأن ارتباطها بالسيد كريشينوسكي. وردًا على ذلك، أكَّد السيد فيليب غرابينسي العضو المنتدب الوحيد لشركة HTLD لمنظمة ICANN أنه وقت الواقعة محل الدعاء كان السيد كريشينوسكي مساهمًا بنسبة 50% وعضوًا منتدبًا في GmbH Berlin، والتي كانت مساهمًا صغيرًا (بنسبة 48.8%) في HTLD. كما أكد السيد غرابينسي أن السيد كريشينوسكي عمل مستشارًا لطلب HTLD حين قُدِّم الطلب (في 2012)، وأن السيد كريشينوسكي مثَّل HTLD في ثلاثة اعتراضات مربكة شنتها HTLD ضد الطلبات المقدمة من Despegar وBooking.com في 2013.

      صرح السيد غرابينسي كذلك بأن السيد كريشينوسكي وقت اطلع على المعلومات الخاصة لم يكن يمثل HTLD أو يدعم طلبها بشأن النطاق HOTEL. وأشار السيد غرابينسي إلى أن السيد كريشينوسكي لم يستخدم معرف دخول HTLD ولم يعلم موظفيها المسؤولين بشأن تصرفه ولم يقدم أي من المعلومات التي حصل عليها إلى HTLD أو موظفيها وأن موظفي HTLD لم يكن لديهم أي علم بتصرف السيد كريشينوسكي ولم يبدوا موافقتهم عليه.

      وأخيرًا، أشار السيد غرابينسي التغييرات الأخيرة التالية علتي طرأت على علاقة HTLD بالسيد كريشينوسكي: (1) أنهيت علاقة الخدمات الاستشارية التجارية بين HTLD والسيد كريشينوسكي اعتبارًا من 31 ديسمبر 2015؛ (2) تنحى السيد كريشينوسكي عن منصب العضو المنتدب لدى شركة GmbH Berlin اعتبارًا من 18 مارس 2016؛ (3) نقلت الشركة المملوكة بالكامل للسيد كريشينوسكي حصتها من الأسهم البالغة 50% في شركة GmbH Berlin إلى السيدة أولمر (عبر شركتها المملوكة بالكامل لها)؛ (4) ستنقل GmbH Berlin حصتها في HTLD إلى Afilias plc؛ (5) السيد غرابينسي هو الآن العضو المنتدب الوحيد لشركة HTLD.

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

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

      ولا يوجد ثمة أثر مالي لهذا القرار على ICANN ولن يؤثر في أمن واستقرار ومرونة نظام اسم النطاق.

      ويعتبر هذا القرار من الاختصاصات الإدارية التنظيمية ولا يتطلب إجراء تعليقات عامة.

  3. الجلسة التنفيذية – سري

    1. تعويض مخاطر محقق الشكاوى للعام المالي 2016

      حيث إن، لجنة التعويضات أوصت المجلس بالمصادقة على دفع تعويض مخاطر محقق الشكاوى للعام المالي 2016.

      تقرر بموجب القرار رقم (2016.08.09.16)، أن المجلس يوافق على دفع تعويض مخاطر محقق الشكاوى للعام المالي 2016.

      حيثيات القرار 2016.08.09.16

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

      إن تقييم أهداف محقق الشكاوى ناتج عن التقييم الذاتي لمحقق الشكاوى بالإضافة إلى مراجعة لجنة التعويضات متبوعة بتقديم توصية لمجلس الإدارة.

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

      ويشار إلى أن هذا الإجراء يمثل وظيفة إدارية هيكلية ولا يتطلب تعليقات عامة.

    2. تعويض المسئولين

      حيث أن، اجتذاب وإبقاء العاملين ذوي الكفاءة العالية هو أمر ضروري لعمليات ICANN، ترغب ICANN بتقديم تعويضات تنافسية للعاملين.

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

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

      وحيث إن، تعويض الرئيس وGDD والمستشار العام والأمين والمدير المالي والنائب الأول للرئيس لدعم وضع السياسات ومدير عام مكاتب ICANN الإقليمية – إسطنبول لم يتم تعديلها منذ تاريخ سريانها في 1 يوليو 2014.

      وحيث إن، تعديلات التعويضات للمديرة التنفيذية للعمليات والمدير التنفيذي للمعلومات ستحقق مواءمة أفضل مع التسلسل الزمني لمراجعات التعويضات للمسؤولين الأربعة الآخرين.

      وحيث إن، كل عضو بالمجلس أكد أنه لا تعارض الحزم التعويضية التي تُمنح لأي من مسؤولي ICANN.

      فقد تقرر بموجب القرار رقم (2016.08.09.17) أن يمنح المجلس الرئيسَ والمديرَ التنفيذي السلطةَ التقديريةَ لتعديل التعويضات عن العام المالي 2017 اعتبارًا من 1 يوليو 2016 لكل من: (1) أكرم عطا الله الرئيس وGDD و(2)جون جيفري، المستشار العام والأمين و(3) ديفيد أوليف، النائب الأول للرئيس لدعم وضع السياسات ومدير عام مكاتب ICANN الإقليمية - إسطنبول، وفقا لدراسة مستقلة عن تعويض مماثل، شريطة ألا تزيد المرتبات الأساسية السنوية الخاصة بهم في العام المالي 2017 بنسبة أكبر من 6% سنويًا عن معدلاتها الحالية.

      تقرر بموجب القرار رقم (2016.08.09.18) أن يمنح مجلس الإدارة الرئيس والمدير التنفيذي السلطة التقديرية لتعديل التعويض للعام المالي 2017 -اعتبارًا من 1 يوليو 2016- لكزافييه كالفيز، المدير المالي بموجب الدراسة المستقلة حول تلقي تعويض مشابه، مع مراعاة شرط عدم زيادة راتبه السنوي الأساسي للعام المالي 2017 عن 10% سنويًا من معدله الحالي.

      تقرر بموجب القرار رقم (2016.08.09.19) أن يمنح مجلس الإدارة الرئيس والمدير التنفيذي السلطة التقديرية لتعديل التعويض للعام المالي 2017 -اعتبارًا من 1 يوليو 2016- لسوزانا بينيت، المدير التنفيذي للعمليات بموجب الدراسة المستقلة حول تلقي تعويض مشابه، مع مراعاة شرط عدم زيادة راتبها السنوي الأساسي للعام المالي 2017 عن 3% سنويًا من معدله الحالي.

      تقرر بموجب القرار رقم (2016.08.09.20) أن يمنح مجلس الإدارة الرئيس والمدير التنفيذي السلطة التقديرية لتعديل التعويض للعام المالي 2017 -اعتبارًا من 1 يوليو 2016- لأشوين رانجان، المدير التنفيذي للمعلومات بموجب الدراسة المستقلة حول تلقي تعويض مشابه، مع مراعاة شرط عدم زيادة راتبه السنوي الأساسي للعام المالي 2017 عن 5% سنويًا من معدله الحالي.

      حيثيات القرارين 2016.08.09.16 – 2016.08.09.20

      جذب واستبقاء الموظفين ذوي الكفاءات العالية من خلال توفير حزمة تعويضات تنافسية أمر بالغ الأهمية للمنظمة. تحسين سوق العمل سيتيح المزيد من الفرص للموظفين من العيار الرفيع خارج ICANN.

      وقد طلب رئيس ICANN ومديرها التنفيذي أن يتم منحه السلطة التقديرية لزيادة المرتبات الأساسية عن العام المالي 2017 لكل من: (1) الرئيس وGDD والمستشار العام والأمين والنائب الأول للرئيس لدعم وضع السياسات ومدير عام مكاتب ICANN الإقليمية – إسطنبول) بحد أقصى 6% عن رواتبهم الأساسية الحالية؛ و(2) المدير المالي بحد أقصى 10% عن راتبه الأساسي الحالي؛ و(3) المديرة التنفيذية للعمليات بحد أقصى 3% عن راتبها الأساسي الحالي؛ و(4) المدير التنفيذي للمعلومات بحد أقصى 5% عن راتبه الأساسي الحالي. وقد أبلغ الرئيس والمدير التنفيذي المجلس أيضا أنه يعتزم ممارسة نفس السلطة التقديرية للموظفين مع أعضاء ICANN التنفيذيين العالميين الغير موظفين (الأمر الذي لا يتطلب موافقة المجلس).

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

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

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

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

      يُشَار إلى أن هذا الإجراء يمثل وظيفة إدارية هيكلية ولا يتطلب تعليقات عامة.

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