Skip to main content
Resources

قرارات مجلس الإدارة المعتمدة | الاجتماع الدوري لمجلس إدارة ICANN

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

  1. جدول أعمال الموافقة:
    1. الموافقة على المحضر
    2. تعيينات اللجنة الاستشارية للأمن والاستقرار
    3. عقد أول مراجعة لوظائف التسمية في IANA
    4. تجديد اتفاقية سجل TLD .coop
    5. تعيين رئيس ورئيس منتخب للجنة الترشيح لعام 2019
  2. جدول الأعمال الرئيسي:
    1. مشورة اللجنة الاستشارية الحكومية: بيان بنما الختامي (يونيو 2018)
    2. استراتيجية خادم الجذر
    3. المتابعة مع تبديل مفتاح توقيع شفرة الدخول الأساسية
    4. مزيد من النظر في تطبيقات .AMAZON.
    5. أعمال أخرى AOB

 

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

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

      تقرر بموجب القرار رقم (2018.09.16.01)، موافقة مجلس الإدارة على محاضر جلسات اجتماعات مجلس إدارة ICANN المنعقدة في 18 يوليو، و21 أغسطس 2018.

    2. تعيينات اللجنة الاستشارية للأمن والاستقرار

      حيث إنّ اللجنة الاستشارية للأمن والاستقرار (SSAC) تقوم بمراجعة عضويتها وإدخال التعديلات عليها بين الحين والآخر.

      وحيث لجنة عضوية SSAC بالنيابة عن SSAC تطلب من مجلس الإدارة تعيين ديفيد بيسيتيلو في SSAC لمدة تبدأ على الفور بعد موافقة مجلس الإدارة وتنتهي في 31 كانون الأول (ديسمبر) 2020.

      بموجب القرار رقم (2018.09.16.02)، يعيّن مجلس الإدارة ديفيد بيسيتيلو في SSAC لمدة تبدأ على الفور بعد موافقة مجلس الإدارة وتنتهي في 31 كانون الأول (ديسمبر) 2020.

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

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

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

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

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

    3. عقد أول مراجعة لوظائف التسمية في IANA

      حيث تنص لوائح ICANN الداخلية على "أن يقوم المجلس، أو أي لجنة مناسبة عنه، بمراجعات دورية و/أو خاصة (يطلق على كل مراجعة "IFR") على أداء PTI لوظيفة تسمية IANA مقابل الاشتراطات التعاقدية المنصوص عليها في عقد وظيفة تسمية IANA وSOW لوظيفة تسمية IANA المراد القيام بها عن طريق فريق مراجعة لوظيفة IANA ("IFRT") الذي يتشكل وفقا للمادة 18 من هذه اللوائح."

      وحيث ينص القسم 18.2.a من لوائح ICANN الداخلية على أن يتم إجراء IFR الدورية الأولى في موعد أقصاه 1 أكتوبر 2018.

      وحيث يحدد القسم 18.7 من لوائح ICANN الداخلية تأليف IFRT ويتطلب تعيين أعضاء ومنسقي فريق المراجعة وفقًا لقواعد وإجراءات منظمات التعيين.

      وحيث أن بعض منظمات التعيين قد عينت بالفعل أعضاء ومنسقين في IFRT.

      وحيث أن القسم 18.8.c من لوائح ICANN الداخلية ينص على أنه يتعيّن على المنظمات القائمة بتعيين أعضاء ومسئولي الاتصال المتبادل في IFRT العمل معا لتشكيل فريق مراجعة متوازن من حيث التنوع (يشمل التنوع الوظيفي والجغرافي والثقافي) والمهارات، وتسعى إلى توسيع عدد الأفراد المشاركين في المراجعات المختلفة؛ بشرط أن يتضمن فريق المراجعة أعضاء من كل منطقة جغرافية لـ ICANN، ولا يجوز لمجموعة سجلات أصحاب المصالح وccNSO تعيين أعضاء متعددين ممن يعدوا مواطنين بالدول من نفس منطقة ICANN الجغرافية.

      وحيث إن القسم 18.8.هـ من لوائح ICANN الداخلية ينص على وجوب قيام مجلس إدارة ICANN بتعيين عضو من فريق عمل ICANN للعمل منسق اتصال لتسهيل وتيسير خطوط التواصل الرسمية بين فريق المراجعة وICANN.

      وحيث يحدد القسم 18.3 من لوائح ICANN الداخلية نطاق ومسؤوليات فريق المراجعة.

      وحيث أن القسم 18.3.ي من لوائح ICANN الداخلية يشترط على فريق المراجعة "تحديد العمليات والمناطق الأخرى لتحسينها في أداء وظيفة تسمية IANA بموجب عقد وظيفة تسمية IANA وبيان العمل لوظيفة تسمية IANA وأداء الضوابط الأمنية الحساسة واللجنة التنفيذية حسب ارتباطه بإشراف هيئة المُعرِّفات الفنية العامة."

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

      بموجب القرار رقم (2018.09.16.03)، يدعو مجلس الإدارة بمدوره إلى مراجعة وظيفة تسمية IANA الأولى ويوجه رئيس ICANN والمدير التنفيذي أو من يعينهم (رئيسهم) لتقديم الدعم الإداري والتشغيلي الضروري لفريق المراجعة للقيام بمسؤولياته، بما في ذلك توفير وتسهيل المشاركة عن بعد لجميع الاجتماعات.

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

      بموجب القرار رقم (2018.09.16.05)، يجب إجراء عملية IFR ضمن الإطار المحدد في القسم 18.3 من لوائح ICANN الداخلية.

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

      حيثيات القرارين 2018.09.16.03 – 2018.09.16.06

      يعقد مجلس الإدارة أول مراجعة دورية لوظائف التسمية IANA أو ("IFR")، لاستيفاء المتطلبات بموجب القسم 18.2 من لوائح ICANN الداخلية التي تنص على أن يتم عقد أول IFR دورية في موعد أقصاه 1 أكتوبر/تشرين أول 2018. IFR هي آلية مساءلة جديدة تم إنشاؤها كجزء من انتقال إشراف IANA لضمان تلبية PTI لاحتياجات وتوقعات عملاء التسمية من خلال التقيد بالمتطلبات التعاقدية المنصوص عليها في عقد وظائف تسمية IANA و بيان وظيفة تسمية IANA [PDF, 626 KB].

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

      يدرك مجلس الإدارة أن نطاق IFR محدد جيدًا في القسم 18.3 من لوائح ICANN الداخلية. هناك إمكانية للتداخل مع مراجعة فعالية CSC المستمرة والمطلوبة في القسم 17.3 من اللوائح، والتي تنص على: "يجب مراجعة فعالية CSC بعد عامين من الاجتماع الأول للجنة CSC…سيتم تحديد طريقة المراجعة بواسطة ccNSO وGNSO." يجب أن تبدأ مراجعة فعالية CSC بحلول 6 أكتوبر 2018، أي بعد عامين من عقد اللجنة الدائمة للعملاء اجتماعها الأول. يكون التداخل المحتمل مع عنصر نطاق فريق مراجعة IFR "لتحديد العملية أو المجالات الأخرى لتحسين أداء…CSC…من حيث صلته بإشراف هيئة المُعرِّفات الفنية العامة." لضمان الاستخدام الفعال لموارد المجتمع، يشجع مجلس الإدارة فريق مراجعة IFR على اعتبار أي نتائج أو توصيات أو منهجية ومعايير مستقبلية تتبناها GNSO وccNSO فيما يتعلق بمراجعة فعالية اللجنة الدائمة للعملاء كمدخلات في عمله.

      تحتوي خطة التشغيل السنوية وميزانية ICANN للسنة المالية 2019 التي وافق عليها المجلس على موارد مدرجة في الميزانية لدعم IFR.

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

    4. تجديد اتفاقية سجل TLD .coop

      حيث أن مشغل سجل .coop لشركة DotCooperation ذ.م.م لديه اتفاقية حالية مع منظمة ICANN ومن المقرر أن تنتهي صلاحيته في 22 نوفمبر 2018.

      وحيث دخلت منظمة ICANN في مفاوضات مع مشغل السجل لتطوير اتفاقية تجديد مقترحة وبدأت فترة تعليق عام من 11 يونيو 2018 إلى 27 يوليو 2018 بشأن اتفاقية تجديد السجل المقترحة لـ .coop TLD لتلقي التعليقات من منظمتين. وتم تقديم ملخص وتحليل للتعليقات إلى مجلس الإدارة.

      وحيث قام مجلس الإدارة بمراجعة التعليقات وقرر عدم وجود حاجة إلى إجراء مراجعات على الاتفاقية المقترحة لتجديد سجل coop. بعد أخذ التعليقات بعين الاعتبار.

      وحيث تشتمل اتفاقية تجديد السجل coop. على أحكام جديدة تتسق مع الأحكام المقابلة لها في اتفاقية السجل الرئيسية لنطاق gTLD الجديد.

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

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

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

      أبرمت منظمة ICANN وشركة DotCooperation LLC اتفاقية سجل في 1 يوليو/تموز 2007 من أجل تشغيل نطاق المستوى الأعلى coop. تنتهي صلاحية اتفاقية سجل نطاق TLD لـ .coop الحالية في 22 نوفمبر/تشرين ثاني 2018 ويحق لمشغل السجل القيام بعملية تجديد افتراضي للاتفاقية الحالية. تم نشر اتفاقية تجديد السجل المقترحة ليتم التعليق العام عليها من 11 يونيو/حزيران 2018 إلى 27 يوليو/تموز 2018. وفي هذا الوقت، فإن مجلس الإدارة بصدد الموافقة على اتفاقية تجديد سجل .coop من أجل التشغيل المتواصل لنطاق المستوى الأعلى .coop بمعرفة شركة DotCooperation LLC.

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

      تعتمد اتفاقية تجديد سجل نطاق TLD .coop التي اعتمدها مجلس الإدارة على اتفاقية سجل نطاق TLD .coop الحالية مع التعديلات التي وافقت عليها منظمة ICANN وشركة DotCooperation LLC، وتشتمل على بعض الأحكام المشمولة في اتفاقية سجل gTLD الجديدة.

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

      أجرت مؤسسة ICANN فترة تعليقات عامة حول تجديد اتفاقية سجل .coop المقترح من 11 يونيو 2018 حتى 27 يوليو 2018. بالإضافة إلى ذلك، شاركت منظمة ICANN في مفاوضات مع مشغل السجل من أجل الاتفاق على مجموعة الأحكام المقرر تضمينها في اتفاقية تجديد سجل .coop المقترحة والتي تم نشرها للتعليق العام.

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

      تم إغلاق منتدى التعليقات العامة حول التجديد المقترح لاتفاقية تجديد سجل .coop بتاريخ 27 يوليو/تموز 2018 بعد تلقي ICANN لتعليقين (2). يمكن تلخيص التعليقات في الفئتين الواردتين أدناه.

      1. إدراج آليات حماية حقوق برنامج gTLD الجديد وسبل الحماية مثل التزامات المصلحة العامة في تجديد اتفاقيات سجل gTLD القديمة: عبر أحد المعلقين عن تأييده لإدراج بعض بعض آليات حماية الحقوق المقترحة في اتفاقية التجديد، مثل الإجراء الموحد للتعليق السريع وإجراءات تسوية خلافات ما بعد التفويض، وإدراج التزامات المصلحة العامة (أي الضمانات) الواردة في اتفاقية سجل gTLD الأساسية. كما عبر معلّق عن مخاوفه بشأن إدراج آليات حماية الحقوق في برنامج gTLD الأساسي في الاتفاقيات القديمة. وقد دفعوا بأن هذه الأحكام يجب عدم إضافتها كنتيجة للمفاوضات الثنائية ولكن يجب التعامل معها من خلال عملية وضع السياسات ("PDP") لـ GNSO.
      2. عملية التفاوض على التجديد المقترح لاتفاقية سجل TLD .coop ومفاوضات اتفاقية سجل gTLD القديمة بصورة عامة: شجع أحد المعلقين أن .coop تنتقل إلى المواصفات الفنية والتشغيلية من اتفاقية سجل gTLD الأساسية، إلا أن أمله خاب نظرًا لأن .COM و .NET لم يجددوا فتراتهم أيضًا. كرر معلق آخر اعتراضاته على عملية التفاوض، قائلاً إن موظفي GDD "يحددون من جانب واحد وضعًا جديدًا لاتفاقيات السجل" ويستبدلون "حكم (GDD) بدلاً من تطوير سياسة GNSO" بتجاوز "الصلاحيات وتجاوز الضمانات التي تهدف إلى الحفاظ على الشفافية والاندماج مع مجتمع أصحاب المصلحة المتعددين. "

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

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

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

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

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

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

      وعلى الرغم من وضع وتعديل URS من خلال العملية المشار إليها هنا، بما في ذلك مراجعة عامة ومناقشة في GNSO، فقد تم اعتمادها كسياسة إجماع وليس لمنظمة ICANN القدرة على جعلها إلزامية لأي نطاقات TLD بخلاف مقدمي طلبات نطاقات gTLD الجديدة المتقدمين خلال جولة نطاقات gTLD الجديدة لسنة 2012.

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

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

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

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

      ليس ثمة تأثير مالي كبير متوقع من اتفاقية تجديد سجل .coop

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

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

    5. تعيين رئيس ورئيس منتخب للجنة الترشيح لعام 2019

      حيث قامت لجنة حوكمة مجلس الإدارة BGC بمراجعة مستندات إبداء الاهتمام المقدمة من المرشحين لرئاسة لجنة الترشيح لسنة 2019 ("NomCom") والرئيس وأيضًا الرئيس المنتخب، وأنها قد نظرت في نتائج استعراض النظراء للجنة NomCom لسنة 2018، وأنها قد أجرت مقابلات شخصية للمرشحين.

      وحيث أوصت لجنة حوكمة مجلس الإدارة بتعيين جيه دامون آشكرافت رئيسًا للجنة الترشيح لسنة 2019 وتعيين شيريل آن ميلر رئيسة منتخبة للجنة الترشيح لسنة 2019.

      تقرر بموجب القرار رقم (2018.09.16.08)، تعيين مجلس الإدارة لكل من جيه دامون آشكرافت رئيسًا للجنة الترشيح لسنة 2019 وتعيين شيريل آن ميلر رئيسة منتخبة للجنة الترشيح لسنة 2019.

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

      تشترط لوائح ICANN الداخلية على مجلس الإدارة تعيين رئيس للجنة الترشيح (NomCom) ورئيسًا منتخبًا لنفس اللجنة. راجع لوائح ICANN الداخلية، المادة 8، القسم 8.1. وقام مجلس الإدارة بتفويض المسؤولية عن التوصية بالرئيس والرئيس المنتخب للجنة الترشيح للحصول على موافقة مجلس الإدارة فيما يتعلق باللجنة الحكومية لمجلس الإدارة (BGC). (راجع ميثاق اللجنة الحكومية لمجلس الإدارة على http://www.icann.org/en/committees/board-governance/charter.htm.) نشرت لجنة حوكمة مجلس الإدارة دعوة لإبداء الاهتمام (EOI) في 13 يونيو 2018 طالبة عروض إبداء الاهتمام EOI في موعد أقصاه 2 يوليو 2018 (راجع (https://www.icann.org/news/announcement-2-2018-06-13-en). تلقت لجنة حوكمة مجلس الإدارة وراجعت عددا من طلبات إبداء الاهتمام، وراجعت تقييم قيادة لجنة الترشيح NomCom لعام 2018 وأجرت مقابلات شخصية مع المرشحين قبل تقديم توصياتها. وقد نظر مجلس الإدارة في توصية لجنة BGC ووافق عليها فيما يخص منصب الرئيس المنتخب للجنة الترشيح لعام 2019 والرئيس المنتخب للجنة الترشيح لسنة 2019. كما يرغب المجلس أيضًا في توجيه الشركة إلى كل من قدم وثيقة إبداء الرغبة في المشاركة في قيادة NomCom لسنة 2019.

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

      ولا يوجد ثمة أثر مالي في إقرار توصية BGC على ICANN لم تكن متوقعة خلافًا لذلك، ولن يؤثر سلبًا على أمن النظام واستقرار ومرونة نظام اسم النطاق.

      علمًا بأن هذه العملية من الوظائف الإدارية التنظيمية التي لا تتطلب تعليقات عامة.

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

    1. مشورة اللجنة الاستشارية الحكومية: بيان بنما الختامي (يونيو 2018)

      حيث إن اللجنة الاستشارية الحكومية (GAC) قد التقت خلال اجتماع ICANN62 في بنما وأصدرت نصائح إلى مجلس إدارة ICANN في بيان ختامي [PDF, 576 KB] في 28 يونيو 2018 ("بيان بنما الختامي").

      وحيث كان بيان بنما هو موضوع حوار بين مجلس الإدارة وGAC في 31 يوليو 2018.

      وحيث قدم مجلس GNSO في خطابه [PDF, 160 KB] المؤرخ في 27 يوليو 2018 تعليقًا إلى مجلس الإدارة فيما يخص النصيحة الواردة في بيان بنما الختامي بخصوص نطاقات المستوى الأعلى العامة من أجل إبلاغ مجلس الإدارة والمجتمع بأنشطة سياسة gTLD التي قد ترتبط بالنصيحة المقدمة من GAC.

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

      تقرر بموجب القرار رقم (2018.09.16.09)، اعتماد مجلس الإدارة بطاقة الدرجات تحت عنوان "نصيحة GAC – بيان بنما الختامي: الإجراءات والمستجدات (16 سبتمبر 2018)"[PDF, 294 KB] ردًا على البنود الواردة في نصيحة GAC في بيان GAC الرسمي الصادر في بنما.

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

      تجيز المادة 12، القسم 12.2(أ)(9) من لوائح ICANN الداخلية لـ GAC بأن "تعرض القضايا على مجلس الإدارة مباشرة، إما عبر وسيلة التعليق أو المشورة المسبقة، أو عبر وسيلة إجراء التوصية خصيصًا أو وضع سياسة جديدة أو مراجعة السياسات الموجودة." وفي بيان GAC الرسمي الصادر في اجتماع بنما (28 يونيو 2018)، أصدرت مشورة إلى مجلس الإدارة حول: القانون العام لحماية البيانات (GDPR) وWHOIS وحماية أسماء ومختصرات المنظمات الحكومية الدولية (IGOs) في نطاق gTLDs ورموز الدول المكونة من حرفين في المستوى الثاني. قدمت GAC أيضًا متابعة للنصيحة السابقة بشأن البنود المؤجلة المتعلقة بالقانون العام لحماية البيانات (GDPR) وWHOIS من بيان GAC في سان خوان. تتطلب لائحة ICANN الداخلية من مجلس الإدارة أن يأخذ بعين الاعتبار مشورة لجنة GAC بشأن مسائل السياسة العامة عند صياغة السياسات واعتمادها. إذا قرر مجلس الإدارة اتخاذ إجراء لا يتوافق مع مشورة لجنة GAC، يجب عليه إبلاغ لجنة GAC وتوضيح أسباب عدم مراعاة المشورة. يجوز رفض أي نصيحة من GAC معتمدة بإجماع تام من اللجنة (وفقًا لما هو محدد في اللائحة الداخلية) فقط بموجب التصويت بنسبة لا تقل عن 60% من أعضاء مجلس الإدارة، وتبذل GAC ومجلس الإدارة عندئذ -بحسن نية وفي الوقت المناسب وبطريقة فعالة- جهدها من أجل التوصل إلى حل مقبول لكلا الطرفين.

      يتخذ مجلس الإدارة اليوم هذه الإجراءات لقبول جميع البنود المتعلقة بالقانون العام لحماية البيانات (GDPR) ونظام WHOIS، وحماية المنظمات الحكومية الدولية وسيؤجل النظر في بندي (2) التوصية المتعلقين برموز الدول المكونة من حرفين في المستوى الثاني، في انتظار إجراء مزيد من المناقشة مع GAC. سوف ينظر المجلس في ما إذا كانت هناك حاجة إلى مزيد من الإجراءات بعد هذه المناقشات. إجراءات مجلس الإدارة موضحة في بطاقة الدرجات المؤرخة في 16 سبتمبر/أيلول 2018 [PDF, 294 KB].

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

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

      علمًا بأنها وظيفة إدارية تنظيمية لا تتطلب تعليقات عامة.

    2. استراتيجية خادم الجذر

      حيث أن نهج ICANN الحالي في نشر عدد كبير من الخوادم الفردية ("L-Singles") وعدد صغير من المنشآت الكبيرة متعددة الخوادم ("L-Clusters") كان حتى الآن بمثابة دفاعًا مناسبًا ضد الهجمات على نظام خادم الجذر.

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

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

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

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

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

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

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

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

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

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

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

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

    3. المتابعة مع تبديل مفتاح توقيع شفرة الدخول الأساسية

      وحيث أن منظمة ICANN ملتزمة بتحديث KSK "بعد 5 سنوات من التشغيل" كما هو موثق في "بيان ممارسة DNSSEC لمشغل KSK لمنطقة الجذر".

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

      وحيث أنه - كجزء من تنفيذ هذه الخطة - جمعت منظمة ICANN بعض البيانات التي أثارت أسئلة تتعلق بتأثير تحديث KSK على المستخدمين الموقوفين.

      وحيث أوقفت منظمة ICANN التحديث في 27 سبتمبر 2017 لفهم البيانات التي يتم جمعها.

      وحيث أن منظمة ICANN - بالتشاور مع أعضاء مجتمع DNS الفني - اكتسبت فهمًا أكبر للبيانات التي تم جمعها.

      وحيث أن منظمة ICANN قدرت التأثير المحتمل لتحديث KSK.

      وحيث قامت منظمة ICANN بتحديث مستندات الخطة الكاملة وإنشاء "خطة محدثة لمواصلة تحديث KSK الجذر."

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

      وحيث أن العدد المتوقع من المستخدمين الموقوفين الذين تأثروا سلبًا بتجربة KSK أقل بكثير من الحد الذي حدده المجتمع وهو 0.5% من المستخدمين الموقوفين، ويجب أن يكون تحديد هذا التأثير السلبي وعلاجه مباشرًا للمتضررين.

      وحيث تعتقد ICANN أن الفوائد التي تعود على المجتمع من المضي في عملية الانتقال في الوقت المناسب تفوق صعوبة تحديد المخاطر.

      بموجب القرار رقم (2018.09.16.11)، يطلب مجلس الإدارة من منظمة ICANN المضي قدماً في عملية تحديث KSK كما هو موضح في "الخطة المحدّثة لمواصلة تحديث KSK الجذر."

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

      تم إيقاف خطة تحديث KSK الجذر لنظام أسماء النطاقات في 27 سبتمبر 2017 بسبب بيانات غير متوقعة، وتحديدا البيانات التي تم تلقيها نتيجة للتطبيقات المبكرة لـ RFC 8145 ، والتي أثارت أسئلة تتعلق بمدى استعداد أدوات التحقق من الصحة للتحديث التي كان من المقرر أن يكون منفذ في 11 أكتوبر 2017. قامت منظمة ICANN - بمساعدة أطراف آخرين - بتحليل تلك البيانات وقررت أن هناك دلائل تشير إلى أن نسبة مئوية صغيرة نسبيًا من موفري الحلول من المحتمل أن تتأثر سلبًا من خلال تحديث KSK، إلا أنه ثبت أيضًا أن البيانات غير مناسبة لتحديد عدد المستخدمين الموقوفين الذين سوف يتأثرون.

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

      وبهذا التعقيب، وضعت منظمة ICANN خطة ملخصة بعنوان "خطة لمواصلة عملية تبديل مفتاح توقيع شفرة الدخول الأساسية للجذر" من أجل تبديل مفتاح توقيع شفرة الدخول الأساسية في 11 أكتوبر/تشرين الأول 2018. ونشرت منظمة ICANN الخطة الملخصة من أجل مراجعة المجتمع لها في 1 فبراير/شباط 2018 (راجع <https://www.icann.org/public-comments/ksk-rollover-restart-2018-02-01-en>). وقد تم تمديد الوقت المسموح للتعليقات إلى ما بعد مدة 45 يومًا الاعتيادية وذلك للسماح بتقديم عروض تعريفية حول الخطة في اجتماع ICANN رقم 61 في سان خوان وفي اجتماع منتدى عمل هندسة الإنترنت IETF رقم 101 في لندن والمطالبة بمزيد من تعقيبات المجتمع في تلك المنتديات.

      كانت ردود المجتمع التي تم تلقيها حتى 2 أبريل/نيسان 2018 لصالح الخطة المنشورة بالإجماع، مع بعض الاقتراحات الخاصة بالتوعية الإضافية التي قامت بها منظمة ICANN بالفعل. واستنادا إلى استجابة المجتمع هذه، قامت منظمة ICANN بإنشاء "خطة محدثة للاستمرار في عملية استبدال KSK الجذر"، مع مراجعة مستندات خطة استبدال KSK الأصلية لإظهار الخطوات التي تم اتخاذها بالفعل والخطوات التي لا تزال هناك حاجة إلى اتخاذها باستخدام التواريخ المنقحة. وتتوفر هذه المستندات الخاصة بالخطة على <https://www.icann.org/resources/pages/ksk-rollover-operational-plans>.

      جاءت مساهمة المجتمع في الخطة المقترحة من مجموعة متنوعة من اللجان الاستشارية ومجموعات أصحاب المصلحة والمنظمات والأفراد. طلب مجلس الإدارة مدخلات واضحة من RSSAC وRZERC وSSAC بشأن الخطة المقترحة. فيما يلي ردود على طلب المجلس:

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

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

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

      هذه وظيفة إدارية تنظيمية لا تتطلب تعليقًا عامًا يتجاوز ما تم طلبه بالفعل.

    4. مزيد من النظر في تطبيقات .AMAZON.

      حيث إنه، في عام 2012، قامت Amazon EU S.à r.l. تقدمت شركة أمازون بطلب للحصول على .AMAZON وإصدارين من أسماء النطاقات الدولية (IDN) من كلمة "Amazon" ("تطبيقات .AMAZON"). كانت طلبات .AMAZON موضوع التحذيرات المبكرة للجنة الاستشارية الحكومية (GAC) المقدمة من حكومتي البرازيل وبيرو (بمصادقة بوليفيا والإكوادور وغيانا)، والتي وضعت شركة Amazon على علم بأن هذه الحكومات لديها سياسة عامة بشأن سلاسل الطلب.

      وحيث أنه في يوليو 2013 في بيان ديربان، كانت طلبات .AMAZON موضوعًا لنصائح GAC بالإجماع التي تنص على أنه لا ينبغي متابعة طلبات .AMAZON. في 14 مايو 2014، قبلت لجنة برنامج gTLD الجديد تلك المشورة وأمرت منظمة ICANN بعدم متابعة طلبات .AMAZON.

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

      وحيث تفردت شركة Amazon في يوليو 2017 بعملية المراجعة المستقلة (IRP) المقدمة في عام 2016. يوصي بيان عملية المراجعة المستقلة (IRP) بأن يعيد المجلس "تقييم طلبات Amazon على الفور" و"يصدر قرارًا موضوعيًا ومستقلاً بشأن إذا ما كان هناك، في الحقيقة، أسبابًا وجيهة وتستند إلى الجدارة تتعلق بالسياسة العامة لرفض طلبات Amazon".

      وحيث طلب مجلس الإدارة في 29 أكتوبر 2017 من GAC الحصول على معلومات إضافية بخصوص نصيحة GAC بشأن تطبيقات .AMAZON. في بيانها الصادر في أبو ظبي في نوفمبر 2017 ، نصحت GAC مجلس الإدارة "بمواصلة تيسير المفاوضات بين الدول الأعضاء في منظمة معاهدة التعاون لبلدان الأمازون (ACTO) وشركة الأمازون بهدف التوصل إلى حل مقبول للطرفين للسماح باستخدام موقع الأمازون كاسم نطاق لمستوى أعلى."

      وحيث أنه في 4 فبراير 2018، وافق مجلس إدارة ICANN على مشورة GAC ووجه رئيس ICANN التنفيذي والمدير التنفيذي "لتسهيل المفاوضات بين الدول الأعضاء في منظمة معاهدة تعاون الأمازون (ACTO) وشركة أمازون."

      وحيث قدمت شركة Amazon إلى GAC وACTO اقتراحًا جديدًا في أكتوبر 2017. بعد أن قدمت شركة Amazon اقتراحًا آخرًا محدثًا في فبراير 2018، أصدرت الدول الأعضاء في ACTO بيانًا في 5 سبتمبر 2018، أعلنت فيه "…أن دول الأمازون قد خلصت إلى أن الاقتراح لا يشكل أساسًا مناسبًا لحماية حقوقها الأساسية المتعلقة بتفويض "نطاق TLD في .amazon ". ذكرت دول الأعضاء في ACTO أيضًا أن وفد .AMAZON "يتطلب موافقة دول الأمازون" وأنها "لها الحق في المشاركة في إدارة نطاق TLD في .amazon."

      وحيث أكدت دول الأعضاء في ACTO في أكتوبر 2017 "…أن اسم أمازون - بأي لغة - هو جزء من التراث والهوية الثقافية لدول الأمازون، وأن استخدامه كاسم نطاق من المستوى الأول - ما لم تتفق دول Amazon على خلاف ذلك - يجب أن يحجز لتعزيز مصالح وحقوق شعب الأمازون وشمولهم في مجتمع المعلومات. "

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

      بموجب القرار (2018.09.16.12)، يتم توجيه رئيس ICANN والمدير التنفيذي لدعم تطوير حل لتفويض السلاسل الممثلة في تطبيقات .AMAZON التي تتضمن مشاركة استخدام نطاقات المستوى الأعلى هذه مع دول الأعضاء في ACTO لدعم التراث الثقافي للدول في منطقة الأمازون.

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

      بموجب القرار (2018.09.16.14)، يتم توجيه رئيس ICANN والمدير التنفيذي أو من ينوب عنه (من ينوب عنهم) لتقديم تحديثات منتظمة ومفصلة إلى مجلس الإدارة حول حالة تطبيقات .AMAZON.

      حيثيات القرارين 2018.09.16.12 – 2018.09.16.14

      يدعم هذا الإجراء نظر مجلس إدارة ICANN في نتائج عملية المراجعة المستقلة (IRP) المقدمة من شركة Amazon، وكذلك النظر في المشورة المقدمة من اللجنة الاستشارية الحكومية فيما يتعلق بطلبات .AMAZON. يتخذ مجلس الإدارة هذا الإجراء اليوم لتعزيز إمكانية تفويض طلبات .AMAZON كما هو موضح في إعلان لوحة IRP، مع الاعتراف بمشاكل السياسة العامة التي أثيرت من خلال مشورة GAC بشأن هذه التطبيقات.

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

      نبذة تعريفية

      تقدمت شركة أمازون بطلب للحصول على .AMAZON وإصدارين من أسماء النطاقات الدولية (IDN) من كلمة "Amazon" ("تطبيقات .AMAZON"). وردا على طلبات . AMAZON، قدمت حكومات البرازيل وبيرو، بتأييد من بوليفيا والإكوادور وغويانا، إنذارا مبكرا من خلال GAC، وفقا لدليل مقدم الطلب، والذي فيه ذكرت الحكومات المعنية ما يلي: "منح الحقوق الحصرية لهذا النطاق gTLD بالذات إلى شركة خاصة قد يمنع استخدام هذا النطاق لأغراض المصلحة العامة المرتبطة بالحماية والترويج والتوعية الناشئة بشأن المسائل المرتبطة بمجال الأمازون الحيوي البيئي. كما سيعيق إمكانية استخدام هذا النطاق لجمع الصفحات الإلكترونية المرتبطة بسكان هذه المنطقة الجغرافية." (الإنذار المبكر، متاح على https://gacweb.icann.org/display/gacweb/GAC+Early+Warnings?preview=/27131927/27197938/Amazon-BR-PE-58086.pdf [PDF, 79 KB].)

      بعد الإشارة في بيان بكين (نيسان (أبريل) 2013) أن طلبات Amazon تطلبت نظر GAC الإضافي، قدمت GAC المشورة الإجماع (فيما يلي مشورة GAC) إلى مجلس إدارة ICANN في بيان ديربان (18 تموز (يوليو) 2013) أنه لا ينبغي المضي قدما في طلبات Amazon ‏ (https://gacweb.icann.org/display/GACADV/2013-07-18-Obj-Amazon).

      في 14 ماي/أيار 2014، قبل مجلس الإدارة (الذي يعمل من خلال NGPC) مشورة GAC ووجه ICANN إلى عدم المضي قدما في طلبات Amazon. (القرار رقم ‎2014.05.14.NG03، متاح على https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-05-14-en#2.b.)

      في أكتوبر 2015، قدمت شركة Amazon اقتراحًا إلى الدول الأعضاء في منظمة معاهدة التعاون في منطقة الأمازون (ACTO) في محاولة للتوصل إلى حل يمكن أن يفيد الطرفين. إلا أنه دول الأعضاء في ACTO رفضت هذا الاقتراح. مما دفع شركة Amazon للبدء بعملية مراجعة مستقلة (IRP) في مارس 2016. انتهت عملية المراجعة المستقلة (IRP) في يوليو 2017 بإيجاد لوحة IRP لصالح شركة Amazon. بعد نتائج عملية المراجعة المستقلة (IRP)، وبناءً على مشورة GAC الإضافية، تم تكليف مجلس إدارة منظمة ICANN بدعم شركة Amazon ودول أعضاء ACTO بالتفاوض لإيجاد حل مناسب.

      في أكتوبر/تشرين أول 2017، في ICANN60 في أبو ظبي، قدمت شركة أمازون إلى الدول الأعضاء في GAC وACTO اقتراحا جديدا من أجل "حل وسط عملي". في فبراير 2018، بناءً على المفاوضات الإضافية التي اعتنقتها منظمة ICANN، قدمت شركة Amazon اقتراحًا آخرًا محدثًا. في 5 سبتمبر 2018، وبعد مراجعة الاقتراح المقدم من مجموعة عمل ACTO في اجتماع لمجلس تعاون Amazon، أصدرت الدول الأعضاء في ACTO بيانًا تُعلن فيه أن "…دول الأمازون قد خلصت إلى أن الاقتراح لا يشكل أساسًا كافيًا لحماية حقوقهم الأساسية المتعلقة بتفويض "لنطاق TLD في .amazon "."

      مقترحات شركة Amazon

      منذ شهر أكتوبر 2015، قدمت شركة Amazon مقترحات مختلفة إلى الدول الأعضاء في ACTO في محاولة منها للتوصل إلى حل مقبول لدى الطرفين. قامت الدول الأعضاء في ACTO برفض الاقتراح الأولي الصادر في أكتوبر 2015، مما أدى إلى قيام شركة Amazon بعملية مراجعة مستقلة نهائية. بعد قرار IRP الذي وُجدت فيه لوحة IRP لصالح شركة Amazon، وفي اجتماع ICANN60 في أبو ظبي، قدمت شركة Amazon إلى GAC اقتراحًا جديدًا لإيجاد "تسوية عملية." في فبراير 2018، عقب المفاوضات التي وصلت بها منظمة ICANN بين شركة Amazon ودول ACTO، قدمت شركة Amazon اقتراحًا آخرًا محدثًا. والذي بموجبه اقترحت شركة Amazon أربعة مسارات رئيسية للعمل:

      1. المساعدة في خلق رؤية عالمية لمنطقة الأمازون وشعبها، وحماية تراثهم الثقافي من خلال:
        1. إنشاء نطاق المستوى الثاني المتفق عليه بشكل متبادل للسماح بإظهار منطقة الأمازون عالميًا. تتحمل شركة Amazon تكلفة الموقع الإلكتروني حتى 1.000.000 دولارًا أمريكيًا ولمدة أربع سنوات؛
      2. المساعدة على منع إساءة استخدام أسماء النطاقات المرتبطة بمنطقة الأمازون وشعوبها من خلال:
        1. الموافقة على حجز عدد كبير من نطاقات المستوى الثاني باللغات الإنجليزية والإسبانية والبرتغالية؛
      3. إنشاء لجنة توجيهية للإشراف على تنفيذ الاتفاقية
      4. الانخراط في جهود حسن النية من خلال توفير اعتمادات الدول الأعضاء في ACTO لاستخدام خدمات ومنتجات شركة Amazon حتى 5000000 دولار.

      بالإضافة إلى ذلك، اقترحت شركة Amazon مساعدة الدول الأعضاء في ACTO على إنشاء برنامج معلومات للمساعدة في نشر فوائد الاتفاقية.

      مخاوف ACTO وردها على مقترحات شركة Amazon

      تدور تساؤلات الدول الأعضاء في ACTO فيما يتعلق باستخدام نطاق TLD في .AMAZON حول قدرة الدول والأفراد في منطقة AMAZON على استخدام أسماء النطاقات لأغراض المصلحة العامة. في تحذير مبكر أصدرته كل من البرازيل وبيرو في نوفمبر 2012، أعلن الدولتين ما يلي:

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

      في أكتوبر 2017، عقب الإعلان النهائي لفريق IRP بشأن .AMAZON ، أصدرت الدول الأعضاء في ACTO بيانًا أعادت فيه تأكيد:

      "…أن اسم أمازون - بأي لغة - هو جزء من التراث والهوية الثقافية لدول الأمازون، وأن استخدامه كاسم نطاق من المستوى الأول - ما لم تتفق دول Amazon على خلاف ذلك - يجب أن يحجز لتعزيز مصالح وحقوق شعب الأمازون وشمولهم في مجتمع المعلومات. "

      أخيرًا في 5 سبتمبر 2018 وبعد الاقتراح المحدث الذي قدمته شركة Amazon في فبراير 2018، بما في ذلك بعد التوضيحات التي طلبتها الدول الأعضاء في ACTO لفهم الاقتراح، أرسلت الدول الأعضاء في ACTO خطابًا إلى المجلس فيما يتعلق تفويض .AMAZON تفيد فيه أن هذا "يتطلب موافقة من دول الأمازون" وأن لديهم "الحق في المشاركة في إدارة نطاق TLD في .amazon." بالإضافة إلى ذلك ، تعلن الدول الأعضاء في ACTO أن "الاقتراح لا يشكل أساسًا كافيًا لحماية حقوقهم الأساسية المتعلقة بتفويض "لنطاق TLD في .amazon "."

      ومع ذلك، تذكر الدول الأعضاء أنها على استعداد "للمشاركة مع مجلس ICANN…بهدف حماية حقوقهم كدول ذات سيادة."

      البنود التي نظر فيها المجلس

      عند اتخاذ هذا الإجراء، نظر المجلس في:

      • مقترحات شركة Amazon في 6 أكتوبر/تشرين أول 2015 و 7 فبراير/شباط 2018؛
      • إعلان لجنة IRP في عملية المراجعة المستقلة الخاصة بـ .AMAZON؛
      • اقتراح شركة Amazon في أكتوبر 2017 للدول الأعضاء في GAC وACTO؛
      • إجراءات NGPC في 14 ماي/أيار 2014 بشأن طلبات .AMAZON وإجراءات مجلس الإدارة في 29 أكتوبر/تشرين أول 2017 و 4 فبراير/شباط 2018 بشأن تطبيقات .AMAZON؛
      • خطاب ACTO في 5 سبتمبر/أيلول 2018 والمرفقات ذات الصلة.

      الآثار

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

      وهذا هو وظيفة إدارية لا تتطلب تعليقات عامة.

    5. AOB

      لم يتم اتخاذ أي قرار.

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