Skip to main content
Resources

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

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

تمت ترجمة هذه الوثيقة إلى العديد من اللغات بغرض المعلومات فقط. ويمكن العثور على النص الأصلي والموثوق (بالإنجليزية) من: http://www.icann.org/en/groups/board/documents/resolutions-28sep13-en.htm

  1. جدول أعمال الموافقة
    1. ‌الموافقة على محضر اجتماع مجلس الإدارة
    2. ‌تفويض نطاق ccTLD لإيران بالنص العربي
    3. توصيات عملية PDP لقفل GNSO لأسماء النطاقات مع مراعاة إجراءات UDRP
    4. تنفيذ مراجعة منظمة الأسماء الداعمة لأسماء رموز البلدان (ccNSO)
    5. ‌استعراض GNSO
  2. جدول الأعمال الرئيسي
    1. تعيين رئيس ورئيس منتخب للجنة الترشيح لعام 2014
    2. ‌التعامل مع التكاليف التاريخية لنطاقات gTLD الجديدة
    3. ‌العملية المقترحة لتعديلات ميثاق مجموعة وجائرة أصحاب المصلحة في GNSO
    4. ‌توضيح فيما يتعلق بمقاييس المنافسة، وثقة واختيار العميل لبرنامج gTLD الجديدة حسب مراجعة تأكيد الالتزامات AoC

 

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

    1. الموافقة على محضر اجتماع مجلس الإدارة

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

    2. تفويض نطاق ccTLD لإيران بالنص العربي

      تقرر بموجب القرار رقم (2013.09.28.02)، وكجزء من ممارسة مسؤولياتها بموجب عقد وظائف IANA، راجعت ICANN وقيّمت الطلب المقدم لتفويض نطاق المستوى الأعلى لرمز الدولة اﺍییر ایران ("إيران") لمعهد الأبحاث في مجال العلوم الأساسية. تبين الوثائق أنه تم اتباع الإجراءات الصحيحة عند تقييم الطلب.

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

      حيثيات القرارين 2013.09.28.02 – 2013.09.28.03

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

      وفقاً لعقد وظائف IANA، قام طاقم عمل ICANN بتقييم طلب بتفويض نطاق ccTLD ويقدمون الآن تقريرهم إلى مجلس الإدارة للمراجعة. إن الهدف من مراجعة مجلس الإدارة هذه هي ضمان اتباع طاقم عمل ICANN للإجراءات الصحيحة.

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

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

      من تمت مشاورته من المساهمين أو غيرهم؟

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

      ما هي المخاوف أو القضايا التي أثارها المجتمع؟

      لم يتوصل الطاقم إلى أية مسائل أو مخاوف مهمة أثارها المجتمع فيما يتعلق بهذا الطلب.

      [تمت صياغة الحيثيات]

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

      لم يحدد مجلس الإدارة أية عوامل مثيرة للمخاوف في هذا الطلب.

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

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

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

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

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

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

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

    3. توصيات عملية PDP لقفل GNSO لأسماء النطاقات مع مراعاة إجراءات UDRP

      حيث إنه وفي 15 ديسمبر 2011، بدأ مجلس GNSO في عملية وضع السياسة (PDP) حول قفل أسماء النطاقات مع مراعاة إجراءات UDRP والتي تتناول خمسة مسائل تتعلق بالميثاق، والمنصوص عليها في https://community.icann.org/x/ma-bAQ.

      وحيث تبعت عملية PDP خطوات عملية وضع السياسة PDP المنصوص عليها على النحو المحدد في اللوائح، الأمر الذي نتج عنه تقرير نهائي تم تسليمه بتاريخ 5 يوليو 2013.

      وحيث توصلت مجموعة العمل (WG) الخاصة بقفل أسماء النطاقات مع مراعاة إجراءات UDRP إلى إجماع بالكامل على التوصيات المتعلقة بالقضايا الموضحة في الميثاق.

      وحيث قام مجلس GNSO بمراجعة ومناقشة التوصيات الخاصة بمجموعة العمل على قفل أسماء النطاقات مع مراعاة إجراءات UDRP، واعتمادها للتوصيات في 1 أغسطس 2013 بالأغلبية العظمي والتصويت بالإجماع (راجع http://gnso.icann.org/en/council/resolutions#201308).

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

      وحيث إنه وبعد تصويت مجلس GNSO، تم عقد فترة للتعليق العام على التوصيات التي تم اعتمادها، وتم تلخيص التعليقات الواردة والنظر فيها (http://www.icann.org/en/news/public-comment/locking-domain-name-recommendations-02aug13-en.htm).

      تقرر بموجب القرار رقم (2013.09.28.04)، اعتماد مجلس الإدارة لتوصيات سياسة مجلس GNSO حول قفل أسماء النطاقات مع مراعاة إجراءات UDRP وفقًا لما هو منصوص عليها في التقرير النهائي (راجع http://gnso.icann.org/ar/issues/locking/domain-name-final-05jul13-rpdf [PDF، 357 كيلوبايت]).

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

      حيثيات القرارين 2013.09.28.04 – 2013.09.28.05

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

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

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

      2. ما إذا كان إنشاء مخطط لخطوات العملية التي يمكن أن يتوقعها المسجل بشكل معقول كي تحدث خلال نزاع UDRP سيكون أمرًا مرغوبًا.

      3. ما إذا كان الإطار الزمني الذي يجب من خلاله أن يقوم المسجل بقفل النطاق بعد تصنيف UDRP ينبغي أن يتم توحيده.

      4. أ. هل يجب تعريف ما يمثل اسم النطاق "المقفل" أم لا.
      5. ب. هل بمجرد "قفل" اسم نطاق بناءً على إجراءات UDRP، قد يتم تغيير أو تعديل معلومات المسجل لاسم النطاق المذكور أم لا.

      6. ما إذا كانت هناك وسائل حماية إضافية ينبغي تعيينها لحماية المسجلين في القضايا التي يتم فيها إقفال اسم النطاق ويكون عرضة لإجراءات UDRP.

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

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

      يتم النظر في التوصيات التالية:

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

      التوصية رقم 2: تعديل الحكم المنصوص عليه في قواعد UDRP والذي ينص على أنه عند تسليم الشكوى إلى موفر إجراءات UDRP، فيجب على الشكوى كذلك أن "تحدد بأن نسخة من الشكوى […] قد تم إرسالها أو تحويلها إلى المدعى عليه (القسم 3، ب – 12) وتوصى بأنه، وكأفضل ممارسة، لا يتعين على المدعي إخطار المدعى عليهم بأن الشكوى قد تم رفعها وذلك لتجنب الشجار وتبادل السباب الإلكتروني. وسوف يتولى موفر UDRP المسئولية عن إخطار المدعى عليه بمجرد البدء في إجراءات التقاضي بصورة رسمية.

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

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

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

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

      التوصية رقم 5: باعتبارها أفضل الممارسات، يتم تشجيع المسجلين ومقدمي UDRP لتقديم وسائل جديدة تسمح لأطراف أخرى بتحديد ساعات / أيام العامل لكل منها، والتي يمكن لمهام UDRP ذات الصلة أن يتوقع عملها.

      التوصية رقم 6: يتعين على أمين السجل التأكيد إلى موفر UDRP في غضون يومي عمل اعتبارًا من استلام طلب7 توثيق من موفر UDRP بأن أية تغييرات لأمين السجل والمسجل قد تم حظرها وسوف يتم حظرها أثناء فترة الانتظار الخاصة بالإجراءات وتوثيق المعلومات المطلوبة8 من جانب مزود خدمات UDRP.

      التوصية رقم 7: إذا اعتبرت شكوى، يلتزم موفر UDRP بإرسال الشكوى إلى أمين السجل والمدعى عليه وإشعارهم ببدء إجراءات التقاضي الإداري في موعد أقصاه 3 أيام عمل9 اعتبارًا من استلام الرسوم التي يسددها الشاكي.

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

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

      التوصية رقم 10: كجزء من الإخطار إلى المسجل (إخطار شكوى – انظر القسم 4 من قاعد UDRP)، يخطر موفر UDRP كجزء من إشعاره إلى المسجل بإشعار المسجل بأن أية تصحيحات على معلومات التعاقد الخاصة بالمسجل أثناء فترة الانتظار المتبقية لإجراءات التقاضي يجب أيضًا إرسالها إلى موفر UDRP وفقًا لقاعدة UDRP رقم 5(2) و(3).

      التوصية رقم 11: يجب أن يشتمل هذا الإشعار كذلك على معلومات بأن أية تغييرات لرفع خدمات البروكسي / الخصوصية، بعد عملية "القفل"، يجب أن تخضع للنقاش / المعالجة من خلال هيئة UDRP مباشرة. توصي مجموعة العمل بإجراء مزيد من الاستعراض والمراجعة لهذه المسألة جزء من برنامج اعتماد الخصوصية / البروكسي.

      التوصية رقم 12: عند استلام إرسال قرار من الموفر، يتعين على أمين السجل وفي غضون 3 أيام عمل بإشعار كل طرف، والمزود، وICANN بتاريخ تنفيذ القرار بما يتفق مع السياسة (قاعدة ICANN رقم 16 والفقرة رقم 4(ك) والفقرة رقم 8(أ) من UDRP. وفي حالة الحكم لصالح الشكوى، يلتزم أمين السجل بتنفيذ أمر الهيئة على الفور بعد انقضاء 10 أيام عمل (UDRP الفقرة رقم 4(ك)). يتعين على الشاكي أو مندوبه المفوض تزويد أمين السجل بالمعلومات اللازمة فيما يخص عملية التنفيذ لقرار اللجنة، وقد يشتمل ذلك على المعلومات التي يجب أن تكون في Whois. في حالة الحكم لصالح المدعى عليه، يلتزم أمين السجل بحظر نقل اسم النطاق إلى أمين سجل أو مسجل آخر لمدة 15 يوم عمل اعتبارًا من تاريخ إرسال القرار من الموفر (UDRP الفقرة 8).

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

      التوصية رقم 14: يجب أن تشمل عملية التسوية الخطوات التالية: (1) تطلب الأطراف التعليق من موفر UDRP، و(2) تسوية الأطراف، (3) تقدم الأطراف "نموذج تسوية" موحد من موفر UDRP، و(4) يؤكد موفر UDRP لأمين السجل، نسخ كلا من المشتكي والمدعى عليه، سواء كانت شروط التسوية تشير إلى اتفاق المدعى عليه لنقل أو إلغاء اسم (أسماء) النطاق المتنازع ليها لمقدم الشكوى أو اتفاق الشاكي بأن يظل اسم (أسماء) النطاق مع المدعى عليه، و(5) اتفاق التسوية الذي تم تنفيذه من قبل أمين السجل، و(6) يؤكد الشاكي أن تنفيذ UDRP و(7) يرفض مقدم UDRP هذه الحالة.

      التوصية رقم 15: تلتزم ICANN، بالتعاون مع موفري UDRP، وأمناء السجلات وغيرهم من الأطراف المعنية، بوضع مواد تعليمية ومعلوماتية من شأنها المساعدة على إشعار الأطراف المتأثرة بهذه المتطلبات الجديدة وأفضل الممارسات الموصى بها بعد الاعتماد من جانب مجلس إدارة ICANN لهذه التوصيات.

      من تمت مشاورته من المساهمين أو غيرهم؟

      وفقًا لما يتطلبه ميثاق مجموعة عمل PDP، كان من المفترض على هذه المجموعة "كخطوة أولى، [أن] تطلب الحصول على تعقيب الجمهور حول القضية من أجل التوصل إلى فهم واضح للطبيعة الفعلية ونطاق المشكلات التي تحدث في قفل اسم النطاق مراعاةً لإجراءات UDRP". نتيجة لذلك، أجرت مجموعة العمل استبيانًا بين المسجل بالإضافة إلى UDRP كما هو مبين في القسم 5.1 من التقرير النهائي. بالإضافة إلى أسئلة محددة فيما يتعلق بممارسات وخبرات أمناء السجل ومقدمي UDRP، حيث طلب من المدعى عليهم تقديم التعقيبات حول أسئلة الميثاق. علاوة على ذلك، افتتحت مجموعة العمل منتدى تعليقات عام للحصول على تعقيبات المجتمع في 25 يوليو 2012.

      بالإضافة إلى التحديثات الدولية المقدمة إلى مجلس GNSO، تم تنظيم ورش عمل لعرض وطلب التعقيبات من مجتمع ICANN في اجتماع ICANN (راجع على سبيل المثال http://beijing46.icann.org/node/37193، http://toronto45.icann.org/node/34245 و http://prague44.icann.org/node/31807).

      تم طلب بيانات من مجموعة الدائرة / أصحاب المصلحة بالإضافة إلى التعقيبات من منظمات الدعم واللجان الاستشارية الأخرى التابعة لـ ICANN في مرحلة مبكرة من العملية. ولم يتم تلقي تعقيبات ردًا على هذه الطلبات. التقي رئيس مجموعة عمل PDP مع منظمة ccNSO في اجتماع ICANN المنعقد في براغ من أجل تبادل وجهات النظر حول هذا الموضوع (راجع http://ccnso.icann.org/meetings/toronto/summary.htm#neylon-greenberg للحصول على مزيد من التفاصيل).

      افتتحت مجموعة العمل منتدى للتعليق العام على التقرير الأولي في 15 مارس 2013.

      وقد خضعت جميع التعليقات التي وردت للمراجعة والفحص بمعرفة مجموعة عمل PDP الخاصة بقفل أسماء النطاقات بموجب إجراءات UDRP (راجع القسم 6 من التقرير الأولي).

      ما هي المخاوف أو القضايا التي أثارها المجتمع؟

      لم يتم التعبير عن أية مخاوف لدى المجتمع فيما يتعلق بالتقرير النهائي وتوصياته. تمت مراجعة جميع التعليقات الأخرى والنظر فيها بمعرفة مجموعة عمل PDP وفقًا لما هو منصوص عليها في القسم 6 من التقرير النهائي.

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

      راجع مجلس الإدارة تقرير توصيات مجلس GNSO إلى مجلس الإدارة، بالإضافة إلى ملخص للتعليقات العامة.

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

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

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

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

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

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

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

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

    4. تنفيذ مراجعة منظمة الأسماء الداعمة لأسماء رموز البلدان (ccNSO)

      حيث قرر المجلس بتاريخ 21 أبريل 2011 توجيه طاقم عمل ICANN، بالتنسيق مع لجنة التحسينات الهيكلية (SIC)، لوضع خطة تنفيذ مقترحة ووضع جدول زمني للتوصيات في التقرير النهائي لمجموعة عمل مجلس إدارة استعراض ccNSO [PDF، 868 كيلوبايت] ولتقديم هذه التوصيات للجنة التحسينات الهيكلية لاستعراضها وموافقة المجلس عليها (القرار 2011.04.21.06).

      وحيث إنه في اجتماع 18 يونيو 2011 اعترفت لجنة التحسينات الهيكلية SIC بالاستلام من طاقم خطة التنفيذ بعنوان "خطة مشروع تنفيذ تحسينات ccNSO" بتاريخ 9 يونيو 2011، وقرار التوصية لمجلس إدارة ICANN لاعتمادها.

      وحيث إنه، في الاجتماع المنعقد في 24 يونيو 2011، قرر المجلس بأن يقوم مدير ICANN التنفيذي بتوجيه فريق العمل للمتابعة في عملية التنفيذ بما يتفق مع وثيقة خطة التنفيذ خطة مشروع تنفيذ تحسينات ccNSO المؤرخة في 9 يونيو 2011 [PDF، 508 كيلوبايت] (القرار 2011.06.24.03).

      وحيث إنه في 27 سبتمبر 2013، أقرت لجنة SIC باستلام خطاب من رئيس ccNSO يعلن فيه عن إكمال تنفيذ مراجعة ccNSO إلحاقًا بالتحديث النهائي على خطة مشروع تنفيذ ccNSO، المؤرخ في سبتمبر 2013.

      وحيث إنه، وفي 27 سبتمبر 2013، وافقت لجنة SIC على التوصية بأن يتلقى مجلس إدارة ICANN التحديث النهائي لخطة مشروع تنفيذ ccNSO [PDF، 170 كيلوبايت]، المؤرخ في سبتمبر 2013، والإشارة إلى أن مرحلة التنفيذ الخاصة بمراجعة ccNSO قد اكتملت، والبدء في مرحلة التقييم المتأصلة في دورة المراجعة.

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

      تقرر بموجب القرار رقم (2013.09.28.07)، أن يوجه مجلس الإدارة رئيس ICANN ومديرها التنفيذي بتقييم التحسينات الناشئة عن مراجعة ccNSO بما يتفق مع مرحلة التقييم لدورة المراجعة التنظيمية.

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

      حيثيات القرار 2013.09.28.06 – 2013.09.28.08

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

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

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

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

    5. استعراض GNSO

      حيث إنه وبموجب لوائح ICANN الداخلية كان من المفترض أن تبدأ المراجعة الواجبة لـ GNSO في 2013.

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

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

      تقرر بموجب القرار رقم (2013.09.28.09)، أن يوجه مجلس الإدارة مجلس SIC إلى وضع جدول لمراجعة منظمة دعم الأسماء العامة (GNSO)، وهو ما تفرض المادة الرابعة، البند 4 من لوائح ICANN الداخلية بدءه في عام 2014، وأن تبدأ الاستعدادات للمراجعة بأسماء ما يمكن.

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

      تشترط لوائح ICANN الداخلية إجراء مراجعات على الهياكل داخل ICANN بصفة دورية كجزء من المساءلة المتصلة لـ ICANN. وفي سبيل تحقيق ذلك، تم البدء في أول مراجعة تنظيمية لـ GNSO في عام 2006. وكجزء من هذه المراجعة، تم نشر تقرير بمعرفة مجموعة السياسة العامة في جامعة لندن للاقتصاد LSE وكلية لندن للاقتصاد في مجال المشروعات، وهي إحدى الجهات القائمة على المراجعة والتي شاركت في إجراء المراجعة، وتمت عملية نشر التقرير في سبتمبر 2006 كما تم إصدار تقرير مجموعة عمل مراجعة GNSO التابع للجنة حوكمة مجلس الإدارة حول تحسينات GNSO وذلك في 3 فبراير 2008. ووفقًا للمادة الرابعة من اللوائح الداخلية لـ ICANN، البند 4، تبدأ المراجعة التالية بعد خمسة أعوام من إصدار التقرير النهائي، والتي تشترط بدء عملية المراجعة في الجزء الأول من 2013. أوصت لجنة التحسينات الهيكلية (SIC) إلى مجلس الإدارة بأن تستفيد ICANN من تأخير البدء في مراجعة GNSO الجديدة من أجل الاستفادة من التعقيبات ذات القيمة الواردة من عملية التخطيط الإستراتيجية التي تقوم بها ICANN والأعمال المتواصلة التي يقوم بها فريق مراجعة المساءلة والشفافية الثاني المجتمع بموجب تأكيد الالتزامات (ATRT 2). وتم البدء في فترة التعليق العامة في 15 يوليو 2013 من أجل جمع التعقيبات للاستفادة بها في إجراء لجنة التحسينات الهيكلية SIC حول التأجيل المحتمل لمراجعة GNSO. وقد أسفر رد المجتمع على التعليق العام عن ثمانية ردود وأوضحت سبع جهات من أصحاب الردود أن مراجعة GNSO يجب أن لا تؤجَّل. واشتملت الردود على ما يلي:

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

      وضم المشاركون في عملية التعليق العامة كل من مجموعة سجل العلامات التجارية، وجوجل، وموفر خدمة الإنترنت ودائرة موفري الاتصال، والدائرة التشغيلية غير الساعية للربح، ومجموعة أصحاب المصلحة غير التجاريين، ودائرة الملكية الفكرية، ودائرة الأعمال، وخدمات سجل ARI.

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

      ولتنفيذ التزام مجلس الإدارة بموجب اللوائح الداخلية من أجل "إجراء مراجعة دورية لأداء وتشغيل كل منظمة من منظمات الدعم، وكل مجلس لمنظمات الدعم"، توصي لجنة SIC أن تبدأ عملية التخطيط للمراجعة التالية لـ GNSO جديًا استعدادًا للمراجعة، والتي تبدأ بأسرع ما يمكن في 2014.

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

      ولا يُتوقع ثمة تأثير على أمن واستقرار DNS. وسوف تكون هناك تأثيرات مالية وتأثيرات على الموارد مرتبطة بمراجعة GNSO عند البدء فيها. وسوف يتم توفير الموارد والتكاليف وتخصيصها داخل ميزانية ICANN للعام (الأعوام) المالية التي تبدأ خلالها المراجعة وتكتمل.

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

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

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

      حيث قامت لجنة حوكمة مجلس الإدارة BGC بمراجعة مستندات إبداء الرغبة من المرشحين لمنصب رئيس لجنة الترشيح ("NomCom") والرئيس المنتخب لسنة 2014، وقامت بعقد مقابلات شخصية مع هؤلاء المرشحين ونظرت في نتائج تقييم 360 درجة من قيادة لجنة NomCom لسنة 2013.

      وحيث أوصت لجنة BGC بتعيين شيريل لانجدون-أور رئيسًا للجنة NomCom لسنة 2014 وتعيين ستيفان فان جيلدر رئيسًا منتخبًا للجنة NomCom لسنة 2014.

      تقرر بموجب القرار رقم (2013.09.28.10)، تعيين مجلس الإدارة لكل من شيريل لانجدون-أور رئيسًا للجنة الترشيح لسنة 2014 وتعيين ستيفان فان جيلدر رئيسًا منتخبًا للجنة NomCom لسنة 2014.

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

      تشترط لوائح ICANN الداخلية على مجلس الإدارة تعيين رئيس للجنة الترشيح (NomCom) ورئيسًا منتخبًا لنفس اللجنة. راجع المادة السابعة، البند 2.1 و2.2 على الموقع الإلكتروني التالي http://www.icann.org/ar/general/bylaws.htm#VII. قام مجلس الإدارة بتفويض مسؤولية تقديم التوصيات إلى رئيس لجنة الترشيح والرئيس المنتخب للحصول على موافقة مجلس الإدارة فيما يتعلق بلجنة الحكم التابعة لمجلس الإدارة. يرجى الاطلاع على ميثاق BGC على http://www.icann.org/en/committees/board-governance/charter.htm. نشرت لجنة BGC دعوة لتقديم إبداء الرغبة (EOI)، وقامت بمراجعة هذه الوثائق، وأجرت مقابلات شخصية مع المرشحين، وأشرفت على تقييم 360 درجة لقيادة NomCom لسنة 2013 قد تقديم التوصيات. وقد أخذ المجلس توصية لجنة BGC بعين الاعتبار ووافق عليها. كما يرغب المجلس أيضًا في توجيه الشركة إلى كل من قدم وثيقة إبداء الرغبة في المشاركة في قيادة NomCom.

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

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

    2. التعامل مع التكاليف التاريخية لنطاقات gTLD الجديدة

      حيث تكبدت ICANN تكاليف على مدار عدة سنوات في التصميم والإعداد لبدء برنامج gTLD الجديدة.

      وحيث إن التكاليف المتكبدة اعتبارًا من أكتوبر 2007 (تاريخ توصية GNSO على برنامج gTLD الجديدة) لبدء البرنامج ("تكاليف التطوير التاريخية") من المقرر سدادها إلى ICANN من حصة من رسوم طلبات برنامج gTLD الجديدة.

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

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

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

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

      تكبدت ICANN تكاليف في تحديد وتصميم وإعداد البدء في برنامج gTLD الجديدة طوال السنوات التي سبقت بدء البرنامج في يناير 2012 ("تكاليف التطوير التاريخية"). (راجع الملحق 1).

      وكجزء من تصميم البرنامج، فإن تكاليف التطوير التاريخية تم سدادها مقدمًا إلى صندوق ICANN التشغيلي وكان من المقرر استردادها من خلال حصة من رسوم الطلبات التي يتم تحصيلها من مقدمي الطلبات في برنامج gTLD الجديدة. ولضمان تلقي الأموال الكافية، اشتملت رسوم الطلبات على 25,000 دولار لكل طلب من أجل السماح لإعادة سداد تكاليف التطوير التاريخية إلى ICANN. وقد نتج مبلغ 25,000 دولار من خلال تقدير تاريخي لتكاليف التطوير الإجمالية الخاصة بالبرنامج وقسمتها على 500 طلب. كما تقرر بأن التكاليف التي تكبدتها ICANN والتي من المقرر سدادها من خلال حصة من رسوم الطلبات سوف تكون تلك التكاليف المتكبدة بين أكتوبر 2007، والتاريخ التقريبي لتوصيات سياسة GNSO حول نطاقات gTLD، وبدء البرنامج في يناير 2012.

      وقد قدرت ICANN تكاليف التطوير التاريخية بأنها حوالي 32.5 مليون دولار. وتم الإعلان عن هذا المبلغ باعتباره جزءًا من عرض ميزانية العام المالي 2013 في يونيو 2012. ويجري الانتهاء في الوقت الحالي من وثائقها التفصيلية من أجل التدقيق وإعلانها للمجتمع.

      وتمت تغطية مبلغ تكاليف التطوير التاريخية من خلال 25,000 دولار تم تحصيلها من المبالغ المحصلة بالفعل على الطلبات الواردة بواقع 48 مليون دولار (25 ألف × 1930 طلب)، قبل دمج المبالغ المعادة. والفارق بين مبلغ 48 مليون دولار (إعادة أموال أقل) والمبلغ التقريبي 32.5 مليون دولار يسهم في صافي الرصيد المتبقي للبرنامج.

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

      تم إنفاق ما يقرب من 17 مليون دولار على برنامج gTLD الجديدة اعتبارًا من يوليو 2012 إلى يونيو 2013، مع عائد مقابل إلى ICANN، وتم تحويلها إلى حساب ICANN التشغيلي في أغسطس 2013.

      وعلى الرغم من أن الهدف كان دومًا بأن يتم تحويل الأموال الناتجة إعادة سداد تكاليف التطوير التاريخية إلى صندوق ICANN الاحتياطي، ولم تتم صياغة هذا الهدف أبدًا في قرار صادر عن مجلس الإدارة. (راجع الملحق 1).

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

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

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

    3. العملية المقترحة لتعديلات ميثاق مجموعة وجائرة أصحاب المصلحة في GNSO

      حيث إن لوائح ICANN الداخلية (المادة 10، البند 5.3) تنص على أن "كل مجموعة أصحاب مصلحة [GNSO] وكل الدوائر المرتبطة بها يجب أن تحافظ على الإقرار والاعتماد لدى مجلس إدارة ICANN".

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

      وحيث إنه لا يوجد في الوقت الحالي إجراء لمجموعة أو دائرة أصحاب المصلحة في GNSO للحصول على موافقة من مجلس إدارة ICANN لتعديل ميثاقها.

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

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

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

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

      في يوليو 2009، وكجزء من برنامج التحسينات الشاملة لمنظمة دعم الأسماء العامة GNSO، اعتمد مجلس إدارة ICANN المواثيق الرسمية لأربع مجموعات أصحاب مصلحة GNSO جديدة (راجع قرار مجلس إدارة ICANN رقم 2009.30.07.09).

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

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

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

      وليس من المتوقع أن يكون لهذا الإجراء أي تأثير على استقرار أو أمن أو مرونة DNS.

      روابط الوثائق/الخلفية:

      رابط إلى منتدى التعليق العام للمجتمع.

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

    4. توضيح فيما يتعلق بمقاييس المنافسة، وثقة واختيار العميل لبرنامج gTLD الجديدة حسب مراجعة تأكيد الالتزامات AoC

      حيث إنه في 18 يوليو 2013، وجه مجلس إدارة ICANN المدير التنفيذي إلى البدء في العملية من أجل تشكيل فريق مراجعة المنافسة وثقة واختيار العميل (CCT) لتسهيل العمل الأولي حول جدوى واستخدام وفاعلية تكاليف اعتماد توصيات مجلس GNSO وALAC، بالإضافة إلى تحليل المقاييس المحتملة الأخرى المقرر إتاحتها لمراجعة CCT.

      وحيث يرغب مجلس الإدارة في توضيح قراره 2013.07.18.06 و2013.07.18.07 للتحديد بأن مراجعة CCT الفعلية لا يجري البدء فيها في هذا الوقت، بل تم اعتماد مجموعة تنفيذ استشارية للمنافسة وثقة واختيار العميل من أجل تشكيل الهيئة. ومن المقرر أن يكون العمل الخاص بالمجموعة الاستشارية عبرة عن تعقيبات على مراجعة CCT في وقت محدد في المستقبل عند بدء مراجعة CCT بما يتفق مع الجدول المشار إليه في تأكيد الالتزامات (AoC).

      تقرر بموجب القرار رقم (2013.09.28.13)، توجيه مجلس الإدارة للمدير التنفيذي بتشكيل مجموعة متطوعين (المجموعة الاستشارية التنفيذية للمنافسة وثقة واختيار العميل) مقدمًا قبل فريق مراجعة مستقبلي لتأكيد الالتزامات الخاصة بالمنافسة واختيار وثقة العميل، للأغراض التالية: (أ) تقييم وإعداد التقارير وتقديمها إلى مجلس الإدارة حول جدوى، وفائدة، ومدى فاعلية التكلفة لاعتماد توصيات مجلس GNSO وALAC، و(ب) تقييم التعقيبات الأخرى، والتي تشمل البيانات التاريخية فيما يتعلق بالمقاييس المستخدمة في تقييم الجولات السابقة لنطاقات gTLD الجديدة (2000، 2004) و(ج) الانخراط مع كل من GNSO وALAC وفريق العمل في مسعى للتوصل لاتفاق حول المقاييس، و(د) اقتراح مجموعة من المقاييس يتم وضعها من بمعرفة ICANN لإتاحتها لفريق استعراض AoC مستقبلي يقوم على فحص برنامج GTLD الجديدة.

      تقرر بموجب القرار رقم (2013.09.28.14)، إعادة صياغة المقاطع الواردة في القرار 2013.07.18.06 والقرار 2013.07.18.07 والتي ترجع بأن مراجعة CCT كان يجري البدء فيها في الوقت الذي تم فيه توجيه الدعوة لذلك داخل تأكيد الالتزامات.

      حيثيات القرارين 2013.09.28.13 – 2013.09.28.14

      ويوضح قرار مجلس الإدارة القرار السابق المتعلق بتقييم المقاييس المقترحة من خلال المجتمع من أجل استخدام مراجعة مستقبلية بموجب تأكيد الالتزامات (AoC) حول تأثير نطاقات gTLD في مجالات المنافسة، وثقة العميل واختياره.

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

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

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

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


1 يجب ملاحظة أن هذا القفل يجب ألا يمنع التجديد لاسم النطاق مراعاة لإجراءات UDRP وفقًا لسياسة حذف النطاقات المنتهية الصلاحية (EDDP).

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

3 لتقديم طلب إلى موفري الخصوصية / البروكسي بعد إنهاء برنامج اعتماد الخصوصية / البروكسي من جانب ICANN.

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

5 لا يجوز أن تحتوي البيانات المفصح عنها على شيء سوى البيانات المسجلة في سجلات موفر الخصوصية /البروكسي المعتمد / التابع.

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

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

8 يرتبط طلب التوثيق بطلب أمين السجل بأن يقدم للمورد توثيق للبنود المطلوبة.

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

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

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