حررت اتفاقية السجل هذه (والمشار إليها هنا بلفظ "الاتفاقية") اعتبارًا في ___________ (ويشار إليه هنا بلفظ "تاريخ السريان") بين كل من هيئة الإنترنت للأرقام والأسماء المُخصصة، وهي مؤسسة نفع عام غير ساعية للربح ومقرها كائن في ولاية كاليفورنيا (ويشار إليها...

اتفاقية سجل

حررت اتفاقية السجل هذه (والمشار إليها هنا بلفظ "الاتفاقية") اعتبارًا في ___________ (ويشار إليه هنا بلفظ "تاريخ السريان") بين كل من هيئة الإنترنت للأرقام والأسماء المُخصصة، وهي مؤسسة نفع عام غير ساعية للربح ومقرها كائن في ولاية كاليفورنيا (ويشار إليها هنا بلفظ "ICANN")، وبين __________، وهي شركة _____________ (ويشار إليها فيما يلي هنا بلفظ "مشغل السجل").

1. تفويض وتشغيل نطاقات المستوى الأعلى؛ التعهدات والضمانات

   1. النطاق والتخصيص. نطاق المستوى الأعلى الذي تسري عليه هذه الاتفاقية هو ____ (نطاق "TLD"). عند بدء تاريخ السريان وإلى انتهاء مدة العقد (وفقًا لما هو منصوص عليه في البند 4.1) أو إنهاء هذه الاتفاقية بموجب المادة 4، أيهما يأتي أولاً، تعين ICANN مشغل السجل مشغلاً للسجل الخاص بنطاق TLD، مع مراعاة المتطلبات والحصول على الموافقات اللازمة لتفوض نطاق TLD والقيد في منطقة الجذر.

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

   3. التعهدات والضمانات.

1. يتعهد مشغل السجل ويضمن لـ ICANN ما يلي:

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

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

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

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

2. تعهدات مُشغل السجل

يتعهد مشغل السجل ويتفق مع ICANN على ما يلي:

1. الخدمات المعتمدة؛ الخدمات الإضافية. لمشغل السجل الحق في توفير خدمات السجل الموضحة بالفقرتين (أ) و(ب) من الفقرة الأولى من المادة 2.1 بالمواصفة 6 الملحقة بهذه الاتفاقية (والمشار إليها هنا بلفظ "المواصفة رقم 6") وخدمات السجل الأخرى المنصوص عليها في الملحق أ (ويشار إليها جميعًا بلفظ "الخدمات المعتمدة"). في حالة رغبة مشغل السجل تقديم أي خدمة سجل ليست من الخدمات المعتمدة أو التي تمثل تعديلاً جوهريًا على خدمة معتمدة (ويشار إلى كل منها بلفظ "خدمة إضافية")، يلتزم مشغل السجل بإرسال طلب لاعتماد هذه الخدمة الإضافية بما يتفق مع سياسة تقييم خدمات السجل الواردة على الموقع xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxx/xxxx.xxxx، حيث إن هذه السياسة خاضعة للتعديل من حين لآخر بما يتفق مع لوائح ICANN (وفقًا للتعديلات من حين لآخر، والمشار إليها بلفظ "لوائح ICANN") والمعمول بها على سياسات الإجماع (والمشار إليها بلفظ "RSEP"). ويجوز لمشغل السجل تقديم خدمات إضافية بشرط الموافقة الخطية من ICANN، وبموجب مثل هذه الموافقة، كما تعامل هذه الخدمات الإضافية كخدمات للسجل بموجب هذه الاتفاقية. ويجوز لـ  ICANN وفقًا لتقديرها المعقول، أن تطلب تعديلا على هذه الاتفاقية بحيث تشير إلى توفير أي من الخدمات الإضافية المعتمدة بموجب سياسة RSEP، على أن يكون التعديل في صورة مقبولة بشكل معقول للطرفين.

2. الامتثال لسياسات الإجماع والسياسات المؤقتة. يلتزم مشغل السجل ويطبق كافة سياسات الإجماع والسياسات المؤقتة الموجودة في <xxxx://xxx.xxxxx.xxx/xxxxxxx/xxxxxxxxx-xxxxxxxx.xxx>، اعتبارًا من تاريخ السريان ووفقا لما يتم وضعه واعتماده مستقبلاً بما يتفق مع لوائح ICANN، شريطة اعتماد هذه السياسات الخاصة بالإجماع والسياسات المؤقتة المستقبلية بما يتفق مع الإجراءات وما يتعلق بتلك الموضوعات ومع مراعاة القيود المنصوص عليها في المواصفة 1 والمرفقة بهذه الاتفاقية ("المواصفة 1").

3. مستودع البيانات. يلتزم مُشغل السجل بإجراءات مستودع بيانات السجل المنصوص عليها في المواصفة 2 المرفقة بهذه الاتفاقية ("المواصفة 2").

4. إرسال تقارير شهرية. خلال فترة (20) يوما من نهاية كل شهر تقويمي يلتزم مشغل السجل بتقديم تقاريره إلى ICANN بالتنسيق المنصوص عليه في المواصفة 3 المرفقة بهذه الاتفاقية (والمشار إليها بلفظ "المواصفة 3").

5. نشر بيانات التسجيل. يوفر مُشغل السجل وصولاً عامًا إلى بيانات التسجيل وفقًا للمواصفة 4 المرفقة بهذه الاتفاقية (والمشار إليها بلفظ "المواصفة 4").

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

7. التشغيل التوافقي للسجل والاستمرارية. يلتزم مُشغل السجل بمواصفات التشغيل التوافقي والاستمرارية وفقًا لما هو منصوص عليه في المواصفة 6 المرفقة بهذه الاتفاقية ("المواصفة 6").

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

9. أمناء السجل.

1. يجب تسجيل كافة تسجيلات أسماء النطاقات في نطاق TLD من خلال أمين سجل معتمد من ICANN، شريطة أنه لا يتعين على مشغل السجل استخدام أمين سجل إذا كان يسجل أسماء تحت الاسم الخاص به هو من أجل منع هذه الأسماء من التفويض أو الاستخدام بما يتفق مع المادة 2.6. مع مراعاة المتطلبات الخاصة بالمواصفة 11، يجب على مشغل السجل توفير وصول عادل لخدمات السجل لجميع أمناء السجلات المعتمدين من ICANN الذين يبرمون ويلتزمون بالاتفاقية المبرمة بين السجل وأمين السجل لنطاق TLD، شريطة أنه يجوز لمشغل السجل وضع معايير عادلة للتأهل لتسجيل الأسماء في TLD والتي ترتبط على نحو معقول بالعمل الصحيح لنطاق TLD. يجب على مشغل السجل استخدام اتفاقية موحدة غير تمييزية مع جميع أمناء السجلات المرخص لهم تسجيل الأسماء في نطاق TLD ("اتفاقية السجل-أمين السجل"). يجوز لمشغل السجل تعديل اتفاقية السجل-أمين السجل من حين إلى آخر؛ ويشترط على الرغم من ذلك موافقة ICANN على أية مراجعات مادية على هذه الاتفاقية قبل أن تصبح هذه المراجعات نافذة وملزمة لأي أمين سجل. يلتزم مشغل السجل بتزويد ICANN وسائر أمناء السجلات المعتمدين لتسجيل الأسماء في نطاق TLD بإشعار مدته خمسة عشر (15) يومًا على أقل تقدير بأي من المراجعات التي تجرى على اتفاقية السجل-أمين السجل قبل أن تصبح أية من هذه المراجعات نافذة وملزمة لأي أمين سجل. وخلال هذه الفترة، تحدد ICANN ما إذا كانت هذه المراجعات المقترحة غير ضرورية، أو ربما تكون مؤثرة أو ذات طبيعة مؤثرة. وإذا لم تقدم ICANN إشعارًا إلى مشغل السجل بقرارها في غضون فترة الخمس عشرة (15) يومًا التقويمية، تعتبر ICANN أنها قد أقرت بأن المراجعات المقترحة غير مؤثرة في طبيعتها. إذا قررت ICANN أو تم اعتبار أنها قد قررت بموجب المادة 2.9(أ)، بأن هذه المراجعات غير مؤثرة، فيجوز لمشغل السجل اعتماد وتنفيذ هذه المراجعات. إذا قررت ICANN بأن المراجعات مؤثرة أو قد تكون مؤثرة، عندئذ تتبع CANNI الإجراءات الخاصة بها فيما يتعلق بمراجعة واعتماد التغييرات على اتفاقية السجل-أمين السجل على <xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxx­amendment-procedure>، ولا يجوز تهيئة وتنفيذ هذه المراجعات حتى تعتمدها ICANN.

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

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

1. أسعار خدمات السجل.

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

7. وفيما يتعلق بتجديد تسجيلات أسماء النطاقات، يلتزم مشغل السجل بأن يقدم لكل أمين سجل معتمد لدى ICANN قام بتنفيذ اتفاقية السجِل- أمين السجل، إشعارًا كتابيًا مسبقًا بأي زيادة في الأسعار (ويشمل ذلك ما يكون نتيجة لحذف أي مبالغ مستردة أو خصومات أو تخفيضات أو ربط منتجات بأخرى أو برامج التسويق المؤهل أو البرامج التي تعمل على تخفيض السعر المفروض على المسجلين) خلال فترة لا تقل عن مائة وثمانين (180) يومًا تقويميًا. ومع عدم الإخلال بالفقرة السابقة، وفيما يتعلق بتجديد تسجيلات أسماء النطاقات: (1) يتعين على مشغل السجل فقط تقديم إشعار مدته ثلاثين (30) يومًا تقويميًا بأي زيادة في الأسعار إذا كان السعر الناتج يقل عن أو يساوي (أ) للفترة التي تبدأ من تاريخ السريان وتنتهي خلال اثني عشر (12) شهرًا بعد تاريخ السريان، السعر المبدئي xxxxxxx xxxx التسجيلات في TLD، أو (ب) عن الفترات اللاحقة، أي سعر قدم به مشغل السجل إشعارًا بموجب العبارة الأولى من هذه المادة 2.10 (ب) في غضون الاثني عشر (12) شهرًا التي تسبق تاريخ سريان زيادة السعر المقترحة، و (2) لا يتعين على مشغل السجل تقديم إشعار بأي زيادة في السعر لفرض رسوم مستوى التسجيل المتغير المنصوص عليها في المادة 6.3. يعرض مشغل السجل على أمناء السجلات خيار الحصول على تجديدات لتسجيل أسماء النطاقات بالسعر الحالي (أي السعر المعمول به قبل أي زيادة تم تقديم إشعار بها) لفترات تتراوح من سنة (1) إلى عشر (10) سنوات وفقًا لتقدير أمين السجل، ولكن بما لا يتجاوز عن عشر (10) سنوات.

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

9. يلتزم مشغل السجل بتوفير خدمة عامة للبحث عن DNS مستندة إلى الاستعلام لنطاقات TLD (أي تشغيل خوادم منطقة TLD للسجل) على نفقته وحده.

1. عمليات تدقيق الالتزام التعاقدي والتشغيلي.

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

11. تتحمل ICANN مصروفات إجراء أي من عمليات التدقيق هذه وفقا للبند 2.11(أ)، ما لم (1) يكن مشغل السجل (أ) يدير أو يخضع للإدارة أو قيد الإدارة المشتركة أو تابع بأي شكل من الأشكال لأي من أمناء السجلات المعتمدين من ICANN، أو (ب) تعاقد من الباطن على توفير خدمات السجل إلى أحد أمناء السجلات المعتمدين من ICANN أو موزع لأمين سجل أو أي من الشركات التابعة المعنية، وفي أي من الحالتين (أ) أو (ب) أعلاه، تتعلق المراجعة بامتثال مشغل السجل مع البند 2.14، وفي هذه الحالة يلتزم مشغل السجل بتعويض ICANN عن جميع التكاليف والمصروفات المعقولة المرتبطة بجزء التدقيق المرتبط بامتثال مشغل السجل مع البند 2.14، أو (2) تتعلق عملية التدقيق بتضارب في الرسوم التي يدفعها مشغل السجل بموجب هذه الاتفاقية بما يزيد عن 5% في ربع سنة محدد لتضرر ICANN، وفي هذه الحالة يلتزم مشغل السجل بتعويض ICANN عن كافة التكاليف والمصروفات المعقولة المرتبطة بهذا التدقيق بالكامل. وفي أي من الحالتين (1) أو (2) أعلاه، يتم سداد هذا التعويض بالإضافة إلى دفع رسوم مستوى التسجيل التالي المستحق بعد تاريخ تقديم بيان التكلفة الخاص بهذا التدقيق.

12. ومع عدم الإخلال بأحكام البند 2.11 (أ)، إذا تبين أن مشغل السجل لا يمتثل بتعهدات وضماناته الواردة في المادة 1 من هذه الاتفاقية أو تعهداته الواردة في المادة 2 من هذه الاتفاقية خلال عمليتي تدقيق متعاقبتين يتم إجراؤهما بما يتفق مع هذا البند 2.11، فيجوز لـ ICANN زيادة عدد عمليات التدقيق إلى مرة واحدة كل ربع سنة تقويمية.

13. يلتزم مشغل السجل بأن يقدم لـ ICANN إشعارًا فوريًا بمعرفة مُشغل السجل ببدء أي من الإجراءات المُشار إليها البند 4.3 (د) أو حدوث أي من الأمور المحددة في البند 4.3 (و).

12. وثيقة العمليات المستمرة. يلتزم مُشغل السجل بالأحكام والشروط ذات الصلة بوثيقة العمليات المتواصلة المنصوص عليها في المواصفة 8 المرفقة بهذه الاتفاقية ("المواصفة 8").

13. الانتقال في حالة الطوارئ. يوافق مشغل السجل على أنه في حالة الوصول إلى أي من عتبات الطوارئ الخاصة بوظائف السجل والمنصوص عليها في البند 6 من المواصفة 10، يجوز لـ ICANN تعيين مشغل سجل طوارئ مؤقت للسجل الخاصة بنطاق TLD (والمشار إليه بلفظ "مشغل الطوارئ") بما يتفق مع عملية نقل السجلات الخاصة بـ ICANN (والمتاحة على <xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxxxxxx-xxxxxxxxx>) (حيث يجوز تعديل هذه العمليات من حين إلى آخر، "عملية نقل السجلات") إلى أن يوضح مشغل السجل وبما يحقق xxx وقبول ICANN قدرته على استئناف عمل السجل لنطاق TLD دون معاودة هذا الإخفاق. وبعد هذا التوضيح، يجوز لمشغل السجل الانتقال مرة أخرى إلى تشغيل سجل TLD بما يتفق مع الإجراءات المحددة بعملية انتقال السجل على أن يدفع مشغل السجل كافة النفقات المقبولة التي تكلفتها (1) ICANN كنتيجة لتخصيص مشغل طوارئ و(2) من جانب مشغل الطوارئ بما يتفق مع تشغيل سجل TLD، وسوف يتم توثيق هذه النفقات بالتفصيل المناسب في السجلات التي سيتم توفيرها لمشغل السجل. في حالة تخصيص ICANN لمشغل طوارئ بما يتفق مع القسم 2.13 وعملية انتقال السجل يجب على مشغل السجل إمداد ICANN أو أي مشغل طوارئ آخر بكل البيانات المطلوبة (بما يتضمن مستودع البيانات بما يتفق مع القسم 2.3) والمتعلق بعمليات تشغيل السجل TLD الضروري للحفاظ على عمليات التشغيل ووظائف السجل التي قد تطلب على نحو معقول من جانب ICANN أو أي مشغل طوارئ آخر. يوافق مشغل السجل على جواز قيام ICANN بإجراء أية تغييرات تراها ضرورية لقاعدة بيانات IANA لسجلات DNS وWHOIS فيما يتصل بنطاق TLD في حالة تعيين مشغل طوارئ بموجب هذا البند 2.13. بالإضافة إلى ذلك، في حالة حدوث هذا الإخفاق، تحتفظ ICANN ويجوز لها إنفاذ حقوقها بموجب وثيقة العمليات المتواصلة.

14. مدونة سلوك السجل. فيما يتعلق بعمل السجل لـ TLD، يلتزم مشغل السجل بمراعاة ما جاء في مدونة سلوك السجل على النحو المبين في المواصفة 9 المرفقة بهذه الاتفاقية ("المواصفة 9").

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

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

17. الالتزامات الإضافية للمصلحة العامة. يلتزم مشغل السجل بمراعاة التزامات المصلحة العامة المنصوص عليها في المواصفة 11 المرفقة بهذه الاتفاقية ("المواصفة 11").

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

2.19 [ملاحظة: لنطاقات TLD المستندة إلى المجتمع فقط] التزامات مشغل السجل أمام مجتمع TLD. يضع مسجل السجل سياسات تسجيل تتماشى مع الطلب المقدم فيما يخص نطاق TLD لما يلي: (1) اصطلاحات التسمية داخل TLD، و(2) متطلبات التسجيل من قبل أعضاء مجتمع TLD، و(3) استخدام أسماء النطاقات المسجلة بما يتماشى مع الغرض المحدد في TLD المعتمدة على المجتمع. يدير مشغل السجل TLD بطريقة تسمح لمجتمع TLD بمناقشة والمشاركة في تطوير وتعديل سياسات وممارسات TLD. يضع مشغل السجلات إجراءات لفرض سياسات تسجيل TLD، وحل المنازعات الخاصة بالخضوع لسياسات تسجيل TLD، مع إنفاذ هذه السياسات الخاصة بالتسجيل. يوافق مشغل السجل على التنفيذ والالتزام بالإجراءات المقترحة لحل نزاعات قيود التسجيل وفقًا لما هو منصوص عليه في xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxx فيما يتعلق بالنزاعات بموجب هذا البند 2.19. يلتزم مشغل السجل بتنفيذ ومراعاة سياسات تسجيل المجتمع المنصوص عليها في المواصفة 12 المرفقة بهذه الاتفاقية.]

3. تعهدات ICANN

تتعهد ICANN وتتفق مع مشغل السجل على ما يلي:

1. الانفتاح والشفافية. اتساقًا مع مهمة ICANN المعلنة وقيمها الأساسية، تلتزم ICANN بالعمل بطريقة منفتحة وشفافة.

2. المعاملة المتساوية. لا تطبق ICANN المعايير والسياسات والإجراءات والممارسات بشكل غير مبرر أو بدو مساواة ولن تختص أي مشغل سجل بمعاملة خاصة إلا لسبب معين وواضح.

3. خوادم أسماء نطاقات TLD. تستخدم ICANN جهوداً تجارية معقولة لضمان أن أي تغييرات على خوادم أسماء TLD المقدمة إلى ICANN من قبل مشغل السجل (في الصيغة المناسبة مع العناصر الفنية المطلوبة والتي حددتها ICANN في xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/ سيتم تطبيقها من قبل ICANN خلال سبعة (7) أيام أو في أسرع وقت ممكن بعد التحقق الفني منها.

4. نشر معلومات منطقة الجذر. يشمل نشر ICANN لمعلومات اتصال منطقة الجذر لسجل TLD كلاً من مشغل السجل وبيانات جهات الاتصال الإدارية والفنية. أي طلب لتعديل معلومات الاتصال لمشغل السجل لا بد أن تقدم في الصيغة التي تحددها ICANN من حين لآخر على xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/.

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

1. المدة والإنهاء

   1. المدة. مدة هذه الاتفاقية هي عشر (10) سنوات تبدأ اعتبارًا من تاريخ السريان (ويجوز تمديد هذه المدة بموجب البند 4.2 "مدة الاتفاقية").

   2. التجديد.

1. يتم تجديد هذه الاتفاقية لفترات متتالية قدرها عشر (10) سنوات عند انتهاء صلاحيتها أو انتهاء فترة سريانها المحددة في القسم 4.1 وكل فترة زمنية تالية، إلا:

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

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

15. وفي حال وقوع الأحداث التي وردت في البند 4.2 (أ) (1) أو (2)، يتم إنهاء الاتفاقية في تاريخ انتهاء المدة الحالية في ذلك الوقت للاتفاقية.

1. الإنهاء من جانب ICANN.

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

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

18. يجوز لـ ICANN، بموجب إشعار إلى مشغل السجل، إنهاء هذه الاتفاقية في حالة (1) فشل مشغل السجل في تصحيح أي مخالفة مادية لالتزامات مشغل السجل المنصوص عليها في البند 2.12 من هذه الاتفاقية خلال ثلاثين (30) يوماً تقويميًا من إرسال ICANN إشعارًا بهذه المخالفة، أو في حالة عدم تفعيل مستند العمليات المستمرة لأكثر من ستين (60) يوماً تقويميًا متتالياً في أي وقت بعد تاريخ السريان، و(2) إذا قرر محكم أو محكمة ذات اختصاص قضائي بشكل نهائي أن مشغل السجل قد ارتكب مخالفة مادية لهذا التعهد، و(3) إذا أخفق مشغل السجل في تصحيح المخالفة المشار إليها خلال فترة عشرة (10) أيام تقويمية أو أي فترة أخرى قد يحددها المحكم أو المحكمة المختصة.

19. يحق لـ ICANN بموجب إشعار إلى مشغل السجل إنهاء هذه الاتفاقية في حالة (1) تنازل مشغل السجل لمصلحة الدائنين أو القيام بإجراء مشابه، أو (2) في حالة رفع دعاوى حجز أو مصادرة أو دعاوى مشابهة ضد مشغل السجل وتكون هذه الدعاوى بمثابة تهديد مادي لقدرة مشغل السجل على تشغيل سجل TLD، ولم يتم إلغاء هذه الإجراءات في غضون ستين (60) يومًا من تاريخ رفعها، أو (3) أن يتم تعيين وصي أو حارس قضائي أو مصفي أو ما يقابله محل مشغل السجل أو في حالة خضوعه للإدارة أو الرقابة على أي لمشغل سجل، أو (4) فرض حجز على أي ملكية لمشغل السجل، أو (5) أن يتم تقديم دعاوى من قبل مشغل السجل أو ضده بموجب أي قوانين خاصة بإشهار الإفلاس أو الإعسار أو إعادة الهيكلة أو أي قوانين أخرى تتعلق بإعفاء المدينين ولا يتم رفض هذه الدعاوى خلال ثلاثون (30) يومًا من رفعها، أو (6) أن يتقدم مشغل السجل بطلب للحماية بموجب قانون إشهار الإفلاس المعمول به في الولايات المتحدة، المادة 11 من الدستور الأمريكي، البند 101، وتعديلاتها، أو قانون أجنبي مقابل، أو في حالة التصفية أو الحل أو توقف عملياته أو تشغيل نطاق TLD.

20. يحق لـ ICANN بعد (30) يوماً من إشعار مشغل السجل إنهاء هذه الاتفاقية وفقاً للبند 2 من المواصفة 7 أو البند 2 و3 من المواصفة 11، مع مراعاة حق مشغل السجل في الاعتراض على هذا الإنهاء وفقًا لما هو منصوص عليها في الإجراءات المعمول بها والمشار إليها في هذه الاتفاقية.

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

22. ويجوز لـ ICANN وبموجب إشعار مدته ثلاثون (30) يومًا يتم إرسالها إلى مشغل السجل إنهاء هذه الاتفاقية وفقًا لما هو منصوص عليه في المادة 7.5.

(ح) [يسري القسم التالي فقط على المنظمات الحكومية الدولية أو الهيئات الحكومية.] يجوز لـ ICANN إنهاء هذه الاتفاقية بموجب البند 7.16.

4. الإنهاء من جهة مشغل السجل.

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

24. يستطيع مشغل السجل إنهاء هذه الاتفاقية لأي سبب بعد إرسال إشعار إلى ICANN مدته مائة وثمانين (180) يوماً.

5. نقل السجل بموجب إنهاء الاتفاقية. عند انتهاء المدة وفقا للبند 4.1 أو البند 4.2 أو أي إلغاء لهذه الاتفاقية بموجب البند 4.3 أو البند 4.4، يلتزم مشغل السجل بأن يقدم لـ ICANN أو أي مشغل سجل يخلفه والذي يمكن أن يكون معينًا من قبل ICANN لـ TLD وفقا لهذا البند 4.5، كافة البيانات (بما في ذلك البيانات المخزنة وفقا للبند 2.3) فيما يتعلق بعمليات تشغيل السجل اللازم لـ TLD للحفاظ على عمليات تشغيل ووظائف السجل والتي قد تتطلبها ICANN أو أي مشغل للسجل يأتي بعده. وبعد التشاور مع مشغل السجل، تقرر ICANN ما إذا كانت ستتم عملية نقل نطاق TLD إلى مشغل سجل تالي أم لا وفقًا لتقديرها وحدها وبما يتفق مع عملية نقل السجلات؛ شريطة أن توفر (1) تأخذ ICANN بعين الاعتبار أية حقوق ملكية فكرية لمشغل السجل (وفقًا لما يبلغ عنه مشغل السجل لـ ICANN) في تقرير ما إذا كانت عملية نقل نطاق TLD لمشغل سجل تالي و(2) إذا أوضح مشغل السجل وبما يحقق القناعة المعقولة لـ ICANN بأن (أ) كافة تسجيلات اسم النطاق في TLD تم تسجيلها والتصريح بها واستخدامها بشكل حصري لمشغل السجل أو الجهات التابعة له للاستخدام الحصري، و(ب) أن مشغل السجل لا يقوم ببيع أو توزيع أو نقل التحكم في أو استخدام أي تسجيلات في TLD لأي جهة أخرى غير تابعة لمشغل السجل، و(ج) نقل عملية التشغيل الخاصة بـ TLD غير الضرورية لحماية المصلحة العامة، فلا يجوز لـ ICANN نقل تشغيل TLD إلى مشغل السجل تالي عند انقضاء أو إنهاء هذه الاتفاقية دون موافقة من مشغل السجل (ولا يجوز الامتناع عن تقديم هذه الموافقة أو وضع شروط عليها أو تأخيرها لأسباب غير منطقية). ولتجنب أي شكوك، لا تمنع العبارة السابقة ICANN من تفويض TLD بموجب عملية طلب مستقبلية لتفويض نطاقات المستوى الأعلى، وفقا لأي عمليات أو إجراءات معارضة تقوم بها ICANN فيما يتعلق بعملية الطلب تلك والتي تهدف إلى حماية حقوق الجهات الأخرى. يوافق مشغل السجل على أن ICANN قد تقوم بتغييرات تراها ضرورية لقاعدة بيانات IANA لسجلات DNS وWHOIS مع اعتبار TLD في حالة انتقال TLD بما يتفق مع القسم 4.5. وأيضًا، تحتفظ ICANN أو من تقوم بتعيينه ويجوز لها إنفاذ حقوقها بموجب مستند العمليات المستمرة للحفاظ على نطاق TLD وتشغيله، بصرف النظر عن سبب الإنهاء أو انتهاء مدة هذه الاتفاقية.

[النص البديل للبند 4.5 نقل السجل عند إنهاء الاتفاقية الخاص بالمنظمات الحكومية الدولية أو الهيئات الحكومية أو الحالات الخاصة الأخرى:

"نقل السجل بموجب إنهاء الاتفاقية. عند انتهاء مدة هذه الاتفاقية بموجب البند 4.1 أو البند 4.2 أو أي إنهاء لهذه الاتفاقية وفقا للبند 4.3 أو البند 4.4 فيما يتصل بتعيين ICANN خلفًا لمشغل السجل لنطاق TLD، يوافق مشغل السجل وICANN على التشاور والتعاون فيما بينهما من أجل تسهيل وتنفيذ عملية نقل نطاق TLD بما يتفق مع هذا البند 4.5. بعد استشارة مشغل السجل، تحدد ICANN ما إن كانت ستنقل عمليات TLD إلى جهة سجل تلحق بها حسبما تراه وبما يتفق مع خطة استمرارية سجل gTLD لمشغل السجل بما يتفق مع عملية انتقال السجل. في حال قررت ICANN انتقال تشغيل TLD إلى مشغل سجل آخر بعد موافقة مشغل السجل (والتي لن تكون معقولة أو مشروطة أو مؤجلة) يجب على مشغل السجل إمداد ICANN أو مشغل السجل الوريث لـ TLD بأي بيانات متعلقة بعمليات التشغيل لـ TLD والضرورية للحفاظ على عمليات التشغيل والسجل التي قد تكون مطلوبة على نحو معقول من جانب ICANN أو مشغل السجل الوريث إضافة إلى مستودع البيانات بما يتفق مع القسم 2.3 أدناه. في حال عدم موافقة مشغل السجل على إمداد مثل تلك البيانات فإن أي بيانات سجل مرتبطة بـ TLD يجب إعادتها لمشغل السجل ما لم يتم الاتفاق على غير ذلك من جانب كل الأطراف. يوافق مشغل السجل على جواز قيام ICANN بإجراء أية تغييرات تراها ضرورية على قاعدة بيانات IANA لسجلات DNS وWHOIS فيما يتعلق بنطاق TLD في حالة نقل نطاق TLD بما يتفق مع البند 4.5. وأيضًا، تحتفظ ICANN أو من تقوم بتعيينه ويجوز لها إنفاذ حقوقها بموجب مستند العمليات المستمرة، بصرف النظر عن سبب الإنهاء أو انتهاء مدة هذه الاتفاقية"].

6. أثر الإنهاء. في حالة انتهاء الفترة الزمنية أو انتهاء هذه الاتفاقية، فإن التزامات وحقوق الأطراف الواردة هنا سوف تتوقف، شريطة أن لا يعفي هذا الانتهاء أو الإنهاء لهذه الاتفاقية الأطراف من أي التزام أو خرق حدث قبل انتهاء أو إنهاء الاتفاقية، بما في ذلك، وبدون تحديد، كل الالتزامات المالية التي تتضمنها المادة 6. بالإضافة إلى ذلك، تظل المادة 5 والمادة 7، البند 2.12، والبند 4.5، وهذا البند 4.6 سارية حتى بعد إنهاء أو انتهاء هذه الاتفاقية. لتفادي أي شك، تنتهي حقوق مشغل سجل TLD على الفور بعد انتهاء الفترة الزمنية أو انتهاء هذه الاتفاقية.

1. حل النزاع

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

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

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

27. يتحمل كل طرف المصاريف الخاصة به في وساطة. الطرفان مناصفة الرسوم والمصاريف من الوسيط. ويعامل كلا الطرفين المعلومات الواردة من الطرف الآخر بما يتفق مع الوساطة والمشار إليها بشكل مناسب بأنها سرية (وفقًا لما يقتضيه البند 7.15) معاملة المعلومات السرية لكل طرف بما يتفق مع أحكام البند 7.15.

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

2. التحكيم. تسوى النزاعات التي تنشأ بموجب أو فيما يتصل بهذه الاتفاقية وفقًا لأحكام البند 5.1، ويشمل ذلك الطلبات المتعلقة بالأداء الخاص، فيتم حلها من خلال تحكيم ملزم يتم بموجب قواعد المحكمة الدولية للتحكيم التابعة لغرفة التجارة الدولية. ويتم إجراء التحكيم باللغة الإنجليزية ويتم ذلك في مقاطعة لوس أنجلوس، ولاية كاليفورنيا. يكون أي تحكيم أمام محكم واحد، ما لم (1) تسعى ICANN للحصول على تعويضات جزائية أو تأديبية، أو عقوبات تشغيلية، أو (2) يتفق الطرفان كتابة على استخدام عدد أكبر من المحكمين، أو (3) ينشأ النزاع بموجب البند 7.6 أو 7.7. في حالة العبارة (1) أو (2) أو (3) في العبارة السابقة، يتم التحكيم في حضور ثلاثة محكمين على أن يختار كل طرف محكمًا واحدًا ويختار المحكمين الذين تم اختيارهما المحكم الثالث. من أجل الإسراع في التحكيم والحد من التكلفة، يجب على المحكم (المحكمين) وضع حدود للأطراف ليتعاملوا معها بما يتوافق مع لجنة التحكيم، وينبغي على المحكم (المحكمين) (1) تحديد أن الجلسة ضرورية، وتقتصر على يوم واحد (1)، شريطة أن تكون في أي تحكيم في ICANN للسعي للحصول على تعويضات جزائية أو تحذيرية أو عقوبات تنفيذية، فيجوز تمديد الجلسة إلى يوم واحد (1) آخر إذا وافق عليه الطرفين أو طلب من قبل المحكم (المحكمين) استنادا إلى تقرير محكم مستقل أو طلب معقول من الأطراف. وسيتمتع الطرف الفائز في التحكيم بالحق في استرداد التكاليف التي أنفقها وأتعاب محاماة معقولة يقوم المحكم (المحكمون) بتضمينها في أحكامهم. في حال قرر المحكمون أن مشغل السجل قد قام مرارًا وتكرارًا وبشكل متعمد بارتكاب مخالفة جوهرية ومادية لالتزاماته المنصوص عليها في المادة 2 أو المادة 6 أو البند 5.4 من هذا الاتفاق، فيجوز لـ ICANN أن تطلب من المحكمين إصدار أحكام بتعويضات جزائية أو تأديبية، أو عقوبات تشغيلية (بما في ذلك سبيل المثال لا الحصر أمر بالتقييد المؤقت لحق مشغل التسجيل في بيع التسجيلات الجديدة). ويعامل كلا الطرفين المعلومات الواردة من الطرف الآخر بما يتفق مع التحكيم والمشار إليها بشكل مناسب بأنها سرية (وفقًا لما يقتضيه البند 7.15) معاملة المعلومات السرية لكل طرف بما يتفق مع أحكام البند 7.15. وفي أي تقاضي يشمل ICANN بخصوص هذه الاتفاقية، ستكون دائرة الاختصاص ومكان إقامة الدعوى المخصص لهذا التقاضي في محكمة واقعة في مقاطعة لوس أنجلوس، ولاية كاليفورنيا، ومع ذلك، يكون للأطراف الحق في تنفيذ حكم المحكمة في أية محكمة لها دائرة اختصاص ذات أهلية.

[نص بديل للبند 5.2 التحكيم للمنظمات الحكومية الدولية أو الهيئات الحكومية أو الحالات الخاصة الأخرى:

"التحكيم. تسوى النزاعات التي تنشأ بموجب أو فيما يتصل بهذه الاتفاقية وفقًا لأحكام البند 5.1، ويشمل ذلك الطلبات المتعلقة بالأداء الخاص، فيتم حلها من خلال تحكيم ملزم يتم بموجب قواعد المحكمة الدولية للتحكيم التابعة لغرفة التجارة الدولية. تتم عملية التحكيم باللغة الإنجليزية وتعقد في مدينة جنيف، بسويسرا، ما لم يتم الاتفاق على مكان آخر بين مشغل السجل و ICANN. يكون أي تحكيم أمام محكم واحد، ما لم (1) تسعى ICANN للحصول على تعويضات جزائية أو تأديبية، أو عقوبات تشغيلية، أو (2) يتفق الطرفان كتابة على استخدام عدد أكبر من المحكمين، أو (3) ينشأ النزاع بموجب البند 7.6 أو 7.7. في حالة العبارة (1) أو (2) أو (3) في العبارة السابقة، يتم التحكيم في حضور ثلاثة محكمين على أن يختار كل طرف محكمًا واحدًا ويختار المحكمين الذين تم اختيارهما المحكم الثالث. من أجل الإسراع في التحكيم والحد من التكلفة، يجب على المحكم (المحكمين) وضع حدود للأطراف ليتعاملوا معها بما يتوافق مع لجنة التحكيم، وينبغي على المحكم (المحكمين) (1) تحديد أن الجلسة ضرورية، وتقتصر على يوم واحد (1)، شريطة أن تكون في أي تحكيم في ICANN للسعي للحصول على تعويضات جزائية أو تحذيرية أو عقوبات تنفيذية، فيجوز تمديد الجلسة إلى يوم واحد (1) آخر إذا وافق عليه الطرفين أو طلب من قبل المحكم (المحكمين) استنادا إلى تقرير محكم مستقل أو طلب معقول من الأطراف. وسيتمتع الطرف الفائز في التحكيم بالحق في استرداد التكاليف التي أنفقها وأتعاب محاماة معقولة يقوم المحكم (المحكمون) بتضمينها في أحكامهم. في حال قرر المحكمون أن مشغل السجل قد قام مرارًا وتكرارًا وبشكل متعمد بارتكاب مخالفة جوهرية ومادية لالتزاماته المنصوص عليها في المادة 2 أو المادة 6 أو البند 5.4 من هذا الاتفاق، فيجوز لـ ICANN أن تطلب من المحكمين إصدار أحكام بتعويضات جزائية أو تأديبية، أو عقوبات تشغيلية (بما في ذلك سبيل المثال لا الحصر أمر بالتقييد المؤقت لحق مشغل التسجيل في بيع التسجيلات الجديدة). ويعامل كلا الطرفين المعلومات الواردة من الطرف الآخر بما يتفق مع التحكيم والمشار إليها بشكل مناسب بأنها سرية (وفقًا لما يقتضيه البند 7.15) معاملة المعلومات السرية لكل طرف بما يتفق مع أحكام البند 7.15. وفي أي تقاضي يشمل ICANN بخصوص هذه الاتفاقية، ستكون دائرة الاختصاص ومكان إقامة الدعوى المخصص لهذا التقاضي في محكمة واقعة في مقاطعة جنيف بسويسرا ومع ذلك، يكون للأطراف الحق في تنفيذ حكم المحكمة في أية محكمة لها دائرة اختصاص ذات أهلية"].

3. تحديد المسؤولية. لن تتجاوز العقوبة المالية المجمعة الخاصة بـ ICANN عن انتهاكات هذه الاتفاقية مبلغ مساو للرسوم على مستوى التسجيل التي يدفعها مشغل السجل خلال الفترة السابقة الاثنى عشر شهرا وفقا لهذه الاتفاقية (باستثناء رسوم التسجيل المتغيرة المنصوص عليها في القسم 6.3، إن وجدت). وستكون المسؤولية النقدية الإجمالية لمُشغل السجل أمام ICANN -مقابل انتهاكات هذه الاتفاقية- محدودة بمبلغ الرسوم المدفوع إلى ICANN أثناء فترة الاثني عشر شهرًا السابقة (مع استبعاد رسوم مستوى السجل المتغيرة المنصوص عليها في القسم 6.3، إذا وجدت)، والتعويضات التأديبية والرادعة -إذا وجدت- وذلك وفقًا للقسم 5.2، باستثناء ما يتعلق بالتزامات تعويض مشغل السجل بموجب البند 7.1 والبند 7.2. وفي حالة عدم وجود حدث محدد، يكون كلا من الطرفين مسئولا عن تعويضات الأضرار الخاصة أو غير المباشرة أو العرضية أو التأديبية أو الرادعة أو التبعية الناشئة خارج هذه الاتفاقية أو المتعلقة بها أو تنفيذ الالتزامات المفروضة في هذه الاتفاقية أو عدم تنفيذها، باستثناء ما هو مفروض بموجب القسم 5.2 من هذه الاتفاقية. وباستثناء ما يرد في هذه الاتفاقية خلافًا لذلك، لا يُقدم أي من الطرفين أية ضمانات، سواء كانت صريحة أو ضمنية، فيما يتعلق بالخدمات التي يقوم هو أو موظفيه أو وكلائه بتقديمها أو النتائج التي تم الحصول عليها نتيجة عمله، بما في ذلك، على سبيل المثال لا الحصر، أية ضمانات ضمنية للرواج أو عدم xxxxxxxx أو الملائمة لغرض معين.

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

1. الرسوم

   1. رسوم مستوى سجل البيانات.

1. يدفع مشغل السجل لـ ICANN رسم مستوى السجل يساوي (1) رسم السجل الثابت وقدره 6,250 دولار لكل ربع سنة تقويمي و(2) رسم معاملة مستوى السجل (ويشار إليها جميعًا بلفظ "رسوم مستوى السجل"). تأتي رسوم التعاملات بمستوى السجل مساوية لعدد من الزيادات السنوية لتجديد تسجيل اسم النطاق المبدئي (على مستوى واحد أو أكثر، وبما في ذلك التجديدات المرتبطة بتحويلات واحد من أمناء السجلات المعتمدين من ICANN إلى آخر، ويشار إلى كل منها بلفظ "معاملة")، وخلال الربع التقويمي المضاعف بنحو 0.25دولار أمريكي، شريطة أن رسم التعاملات بمستوى السجلات لا تطبق إلا إذا كانت أسماء النطاقات أكثر من 50,000 معاملة حدثت في TLD خلال أي أربع أرباع سنة تقويمية متتالية أو أي فترة ربع من العام على الإجمال ("عتبة المعاملة") وبعد ذلك يطبق على كل المعاملات التي وقعت خلال كل ربع سنة تم فيها اجتماع منصة المعاملات، ولكن لا ينطبق على كل ربع سنة في المعاملات التي لم يتم الوفاء فيها بمنصة المعاملات. يبدأ التزام مشغل السجل بسداد رسوم ثابتة لمستوى السجل في تاريخ تفويض نطاق TLD في نظام DNS إلى مشغل السجل. السداد الأول لربع السنة الخاص بالرسوم الثابتة لمستوى السجل فيتم إثباتها استنادًا إلى عدد الأيام التقويمية بين تاريخ التفويض ونهاية الربع السنوي التقويمي التي يقع فيه تاريخ التفويض.

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

1. استرداد التكاليف لـ RSTEP. الطلبات المقدمة بواسطة مُشغل السجل من أجل التصديق على خدمات إضافة بموجب البند 2.1 يجوز إحالتها بمعرفة ICANN إلى لجنة التقييم الفني لخدمات سجل البيانات ("RSTEP") وفقاً لهذه العملية على الموقع xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxx/. في حال إحالة تلك الطلبات إلى RSTEP، يقدم مشغل السجل التكلفة بالفاتورة إلى ICANN xxxx xxxxxx RSTEP خلال أربعة عشر (14) يومًا تقويميًا من استلام نسخة من فاتورة RSTEP من ICANN، إلا إذا قررت ICANN وفقًا لتقديرها المطلق وحدها دفع كل تكلفة الفاتورة أو جزء منها لهذه المراجعة الخاصة بـ RSTEP.

2. رسم مستوى سجل البيانات المتغير.

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

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

1. رسوم التمرير. يلتزم مشغل السجل بأن يسدد إلى ICANN رسمًا (1) لمرة واحدة يساوي 5,000 دولار أمريكي للوصول إلى واستخدام دار مقاصة العلامات التجارية وفقًا لما هو منصوص عليه في المواصفة 7 (ويشار إليها بلفظ "رسم وصول RPM") و(2)¹0.25 دولار أمريكي حسب تسجيل العلامات التجارية للمرة الأولى وتسجيل المطالبات (حيث يتم استخدام هذه الشروط في RPM الخاصة بدار مقاصة العلامات التجارية والمنصوص عليها هنا بموجب المواصفة 7) ("رسوم تسجيل RPM"). يتم تقديم فواتير برسوم وصول RPM اعتبارًا من تاريخ سريان هذه الاتفاقية ويلتزم مشغل السجل بسداد هذا الرسم إلى الحساب الذي تحدده ICANN في غضون ثلاثين (30) يومًا تقويميًا بعد تاريخ تقديم الفاتورة. تلتزم ICANN بتقديم الفواتير إلى مُشغل السجل كل ربع سنة لرسوم تسجيل RPM، والتي تكون مستحقة بما يتفق مع إجراءات تقديم الفواتير والسداد المنصوص عليها في البند 6.1.

2. ^{التعديل على الرسوم.} مع عدم الإخلال بأي قيود على الرسوم المنصوص عليها في المادة 6، بدء العمل عند انتهاء السنة المالية لهذه الاتفاقية، وعند انتهاء كل سنة مالية لاحقاً خلال الفترة الزمنية، فإن الرسوم الحالية المحددة في القسم 6.1 والقسم 6.3 يمكن زيادتها، حسبما ترى ICANN، بنسبة تساوي نسبة الزيادة، إن وجدت، في (1) مؤشر سعر المستهلك لكل المستهلكين بالمدينة، متوسط مدن الولايات المتحدة (1982-1984 = 100) والذي تنشره وزارة العمل الأمريكية، مكتب إحصائيات العمل، أو أي مؤشر لاحق ("CPI") للشهر واحد (1) قبل بدء العمل للسنة المعنية، أكثر، من (2) مؤشر CPI الذي تم نشره لشهر واحد (1) قبل بدء العمل للسنة السابقة مباشرة. في حال وجود أي من هذه الزيادة، تقدم ICANN إشعاراً إلى مشغل السجل تحدد فيه مبلغ هذه الزيادة للتعديل المقترح. وتسري أية تعديلات على الرسوم بموجب هذا البند 6.5 اعتبارًا من اليوم الأول من ربع السنة التقويمي الأول بعد مدة ثلاثين (30) يومًا على الأقل بعد تسليم ICANN إشعارًا بهذا التعديل على الرسوم إلى مشغل السجل.

3. الرسوم الإضافية على الدفعات المتأخرة. بالنسبة لأية دفعات فات موعد سدادها بثلاثين (30) يوماً أو أكثر وفقاً للقسم 6.2، يدفع مُشغل سجل البيانات رسماً إضافياً على الدفعات المتأخرة بمعدل 1.5% شهرياً، أو إذا كانت أقل من ذلك، سيكون أقصى معدل يسمح به القانون الساري.

1. متنوعات

   1. تعويض ICANN.

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

[نصالبند 7.1(أ) البديل للمنظمات الحكومية الدولية أو الهيئات الحكومية:

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

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

1. إجراءات التعويض. إذا تم تقديم إدعاء لأي جهة أخرى تم تعويضها بموجب البند 7.1 أعلاه – فإن على ICANN أن تقدم إشعارا منها بذلك إلى مشغل السجل كواجب النفاذ. يتم تخويل مُشغل سجل البيانات، إذا تم انتخابه لذلك، بموجب إشعار يتم تسليمه في الوقت المناسب إلى ICANN، لاتخاذ إجراءات فورية للسيطرة على عملية الدفاع عن هذه المطالبة والتحقيق فيها ولاستخدام وتشغيل محامين مقبولين بدرجة معقولة لدى ICANN للتعامل مع نفس المطالبة والدفاع عنها، على نفقة مُشغل سجل البيانات وحده، بشرط أن يتم في جميع الأحوال تخويل ICANN للسيطرة على الدعوى القضائية بالمشاكل الخاصة بصلاحية سياسات ICANN أو تفسيراتها أو تصرفها وذلك على نفقتها وحدها. وستقوم ICANN بالتعاون – على حساب ونفقة مشغل التسجيل – في جميع الجوانب المعقولة مع مشغل التسجيل ومحامييها في التحقيق والحكم والدفاع عن مثل هذا الادعاء أو أي طعن ينشأ عنه، وقد تشارك – على حسابها ونفقتها الخاصة – من خلال محاموها أو غير ذلك في مثل هذا التحقيق والحكم والدفاع عن مثل هذا الادعاء وأي طعن قد ينشأ عنه. ولن يتم ضم أية تسويات لأية إدعاءات تتضمن حلا يؤثر على ICANN بخلاف سداد المال بقيمة قد تم تعويضها كاملة من قبل مشغل السجل بدون موافقة ICANN. إذا لم يقم مشغل السجل بفرض سيطرة كاملة على الدفاع عن هذا الادعاء الخاضع لمثل هذا الدفاع وفق هذا الفصل 7.2 فإنه سيحق لـ ICANN بأن تدافع عن الادعاء بمثل هذا الأسلوب الذي قد تعتبره ملائما على حساب ونفقة مشغل السجل وسيقوم مشغل السجل بالمشاركة في هذا الدفاع. [ملاحظة: لا يسري العمل بهذا البند 7.2 على المنظمات الحكومية الدولية أو الهيئات الحكومية.]

2. مصطلحات معرفة. ومن أجل أهداف هذا الاتفاق – ما لم يتم تعديل هذه التعريفات بموجب سياسة الإجماع بتاريخ مستقبلي – وفي هذه الحالة سيتم اعتبار التعريفات التالية معدلة ومعاد صياغتها في مجملها كما نصت عليه سياسة الإجماع وسيتم تعريف الأمن والاستقرار كما يلي:

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

36. نظراً للهدف من هذه الاتفاقية، يعني تأثير "الاستقرار" (1) أن خدمة السجل غير ملتزمة بالمعايير المناسبة القابلة للتطبيق والتي تم اعتمادها ونشرها بواسطة هيئة معايير تم تأسيسها جيداً ومعترف بها ومعتمدة، مثل تتبع المعايير أو طلبات التعليق (FRC) الخاصة بأفضل الممارسات الحالية المناسبة والتي ترعاها IETF أو (2) يمكن لها أن تنشئ حالة تؤثر بصورة عكسية على الإنتاجية أو زمن الاستجابة أو الاتساق أو ترابط الاستجابات بخوادم الإنترنت أو النظم الأخيرة، حيث تعمل وفقاً للمعايير المناسبة القابلة للتطبيق والتي تم اعتمادها ونشرها بواسطة هيئة معايير تم تأسيسها جيداً ومعترف بها ومعتمدة مثل تتبع المعايير أو أفضل الممارسات الحالية لطلبات التعليق المناسبة وتعتمد على معلومات التفويض الخاصة بمشغل السجل أو خدمات التوزيع الخاصة به.

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

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

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

38. في غضون ثلاثين (30) يومًا تقويميًا اعتبارًا من أي من هذه الإشعارات بموجب البند 7.5(أ)، يجوز لـ ICANN أن تطلب معلومات إضافية من مشغل السجل تؤكد (أ) الالتزام بهذه الاتفاقية و(ب) أن الطرف الذي يستحوذ على هذه النسبة الموجبة للإدارة أو يبرم هذا التنازل أو التعاقد المادي من الباطن (يشار إليه في أي حالة بلفظ "الطرف المتعاقد") وتحقيق xxxxxx الأم النهائي للطرف المتعاقد للمواصفات المعتمدة من ICANN أو سياسة حول معايير مشغل السجل تكون سارية في حينه (ويشمل ذلك ما يتعلق بالموارد المالية والقدرات التشغيلية والفنية)، وفي هذه الحالة يتعين على مشغل السجل تقديم المعلومات المطلوبة في غضون خمسة عشر (15) يومًا تقويميًا.

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

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

41. وفيما يتصل بأي من هذه التنازلات أو التغيير في نسبة الملكية أو ترتيبات التعاقد المادي من الباطن، يلتزم مشغل السجل بعملية نقل السجلات.

42. مع عدم الإخلال بما سبق، (1) فإن أي تغيير مكتملة في نسبة الملكية الموجبة للرقابة والإدارة لا يمكن إلغاؤها من خلال ICANN، ويشترط رغم ذلك أنه إذا قررت ICANN بشكل معقول الامتناع عن تقديم موافقتها على هذه المعاملة، فيجوز لـ ICANN إنهاء هذه الاتفاقية بموجب البند 4.3(ز)، و(2) يجوز لـ ICANN التنازل عن هذه الاتفاقية دون الحصول على الموافقة من مشغل السجل بموجب الموافقة من مجلس إدارة ICANN بالتزامن مع عملية إعادة هيكلة أو إعادة تأسيس أو إعادة تشكيل ICANN بعد تحمل المتنازل له صراحة للأحكام والشروط الواردة في هذه الاتفاقية، و(3) يجوز لمشغل السجل التنازل عن هذه الاتفاقية دون الحصول على الموافقة من ICANN مباشرة إلى شركة فرعية مملوكة بالكامل لمشغل السجل، أو، إذا كان مشغل السجل ذاته شركة فرعية تابعة، فيكون إلى الشركة الأم المباشرة أو إلى شركة فرعية أخرى مملوكة بالكامل للشركة الأم المباشرة، بموجب تعمل الشركة الفرعية أو الشركة، حسب ما ينطبق، صراحة للأحكام والشروط الواردة في هذه الاتفاقية، و(4) تعتبر ICANN قد وافقت على أي تنازل أو تعاقد أساسي من الباطن أو تعيير في معاملة الرقابة والتي يكون الطرف المتعاقد هو المشغل الحالي لنطاق عام من المستوى الأعلى بموجب اتفاقية سجل بين هذا الطرف المتعاقد وICANN (شريطة أن يكون هذا الطرف المتعاقد في ذلك الوقت ملتزمًا بالأحكام والشروط الواردة في اتفاقية السجل تلك في كافة الجوانب المادية)، ما لم تقدم ICANN إلى مشغل السجل اعتراضًا خطيًا على هذه المعاملة في غضون عشرة (10) أيام تقويمية اعتبارًا من استلام إشعار بهذه المعاملة بموجب البند 7.5. ومع عدم الإخلال بأحكام البند 7.5(أ)، في حالة إجراء عملية تنازل بموجب الفقرة (2) أو (3) من هذا البند 7.5(و)، يلتزم الطرف المتنازل بتزويد الطرف الآخر بإشعار خطي بعد أي عملية تنازل مشار إليها.

1. التعديلات والتنازلات.

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

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

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

46. إذا قرر مجلس إدارة ICANN بشكل معقول أن تعديلاً مرفوضًا يندرج في فئة الموضوع المنصوص عليه في البند 1.2 من المواصفة 1، فيجوز لمجلس إدارة ICANN اتخاذ قرار (تتم الإشارة إلى تاريخ هذا القرار هنا بلفظ "تاريخ اعتماد القرار") يطلب فيها تقرير مشكلات (حيث تم تعريف هذا البند في لوائح ICANN) من خلال منظمة دعم الأسماء العامة (منظمة "GNSO") بشأن مضمون هذه التعديل المرفوض. ويشار إلى أن عملية وضع السياسات التي تقوم بها GNSO عملا مثل تقرير العدد المطلوب إليها هنا بأنها "PDP". وإذا كانت هذه النتائج PDP في تقرير نهائي معتمد من قبل أغلبية عظمى GNSO (كما هو محدد في لوائح ICANN) التي إما (1) توصي باعتماد التعديل مرفوضا سياسة إجماع أو (الثاني) توصي بعدم اعتماد التعديل مرفوضا سياسة الإجماع، و ، في حالة (1) أعلاه، يتبنى المجلس هذه السياسة توافق، المسجل الامتثال لالتزاماتها وفقا للقسم 2.2 من هذا الاتفاق. في كلتا الحالتين، سوف ICANN التخلي عن التعديل مرفوضا، وأنه لن يكون له أي تأثير على أحكام وشروط هذه الاتفاقية. وعلى الرغم من الأحكام السابقة من هذا القسم 7.6(د)، لا يجوز أن يطلب من مجلس إدارة ICANN لبدء PDP فيما يتعلق التعديل مرفوضا إذا، في أي وقت في فترة اثني عشر (12) شهرا السابقة لتقديم مثل التعديل مرفوضا لمشغل السجل موافقة وفقا للقسم 7.6(ج)، وكان موضوع هذه التعديل مرفوضا موضوع خلصت أو التخلي عن خلاف ذلك أو إنهاء PDP الذي لم يسفر عن أغلبية عظمى توصية GNSO.

47. إذا كان (أ) تعديل مرفوض لا يندرج ضمن الفئات الموضوع المنصوص عليها في القسم 1.2 من المواصفة 1، (ب) وكان موضوع التعديل مرفوضا، في أي وقت في فترة اثني عشر (12) شهرًا تسبق تقديم مثل هذا التعديل المرفوض لموافقة مشغل السجل وفقا للقسم 7.6(ج)، موضوع PDP المنتهي أو الذي تم التخلص منه الذي لم يسفر عن توصية أغلبية عظمى لدى GNSO، أو (ج) لم ينجم عن PDP تقرير نهائي يدعم GNSO إما (أ) توصي باعتماد التعديل المرفوض كسياسة إجماع أو (ب) توصي بعدم اعتماد التعديل المرفوض كسياسة إجماع (أو خلاف ذلك PDP التي تم التخلي عنها أو إنهاءها لأي سبب من الأسباب)، ثم ، في أي حالة من هذا القبيل، قد لا يزال اعتماد هذه التعديل المرفوض وتصبح فعالة على النحو المبين أدناه. من أجل اعتماد التعديل المرفوض، يجب تلبية المتطلبات التالية:

1. يجب أن يكون موضوع التعديل المرفوض ضمن نطاق مهمة ICANN وبما يتفق مع تطبيق متوازن من قيمها الأساسية (كما هو موضح في لوائح ICANN)؛

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

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

9. يجب على مجلس إدارة ICANN تقديم التعديل المرفوض جنبا إلى جنب مع شرح خطي للمنطق المتصل بتحديد أن التعديل المرفوضيلبي الشروط المنصوص عليها في الفقرات الفرعية (1) من خلال (ثالثا) أعلاه، للتعليق العام لمدة ما لا يقل عن ثلاثين (30) يوما تقويميا، و

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

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

48. بصرف النظر عن أحكام المادة 7.6(هـ)، لا يعتبر تعديل المجلس تعديل معتمد إذا، خلال فترة ثلاثين (30) يوم تقويمي بعد الحصول على موافقة من قبل مجلس إدارة ICANN على تعديل المجلس، والفريق العامل، نيابة عن رئيس قلم قابل للتطبيق، يقدم إلى مجلس إدارة ICANN بديلا لتعديل المجلس ("التعديل البديل") الذي يلبي المتطلبات التالية:

1. يحدد النص الدقيق الذي اقترحه الفريق العامل لتعديل هذا الاتفاق بدلا من تعديل المجلس؛

12. يعالج سبب وجيه ومقنع في المصلحة العامة التي حددها مجلس إدارة ICANN كمبرر لتعديل المجلس، و

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

لا يعتبر أي تعديل مقترح لا يلبي متطلبات الفقرات الفرعية (1) إلى (2) في الجملة السابقة مباشرة بديل التعديل بموجب هذه الاتفاقية ولذلك لا تلغي أو تؤجل فعالية تعديل المجلس. وإذا حصل التعديل البديل بعد تقديمه إلى مجلس إدارة ICANN على موافقة مشغل السجل، يلغي التعديل البديل تعديل مجلس الإدارة ويعتبر تعديلاً معتمدًا بموجب هذه الاتفاقية ( ويسري العمل به ويعتبر تعديلاً على هذه الاتفاقية في تاريخ ستين (60) يومًا تقويميًا بعد تاريخ تقديم ICANN إشعارًا بالموافقة على هذا التعديل البديل إلى مشغل السجل، ويعتبر تاريخ السريان هذا هو تاريخ سرين التعديل بموجب هذه الاتفاقية)، ما لم، وفي غضون فترة ستين (60) يومًا تقويميًا بعد تاريخ إشعار مجموعة العمل لمجلس إدارة ICANN بموافقة مشغل السجل على هذا التعديل البديل (وخلال هذا الوقت تشارك ICANN مع مجموعة العمل فيما يتعلق بالتعديل البديل)، فيجوز لمجلس إدارة ICANN بموجب تصويت تأكيدي لثلثي الأعضاء على الأقل في مجلس إدارة ICANN ممن لهم الحق في التصويت على هذه الأمور، مع الأخذ في الاعتبار أي سياسة لـ ICANN تؤثر على هذه الأهلية، ويشمل ذلك سياسة تضارب المصالح المعمول بها لدى ICANN، رفض هذا التعديل البديل. إذا لم (أ) يلقى التعديل البديل موافقة مشغل السجل في غضون ثلاثين (30) يوما تقويميا من تاريخ تقديم هذا التعديل البديل لمشغلي السجل المعمول به (مع قيام مجموعة العمل بإشعار ICANN بتاريخ هذا التقديم)، أو (ب) إذا رفض مجلس إدارة ICANN التعديل البديل بتصويت ثلثي الأصوات، فإن تعديل مجلس الإدارة (وليس التعديل البديل) يكون ساريًا ويعتبر تعديلاً على هذه الاتفاقية في تاريخ ستين (60) يومًا تقويميًا بعد تاريخ تقديم ICANN إشعارًا إلى مشغل السجل (والذي يعتبر تاريخ سريانه هو تاريخ سريان التعديل بموجب هذه الاتفاقية). إذا رفض مجلس إدارة ICANN التعديل البديل، يتعين على المجلس نشر تبرير مكتوب يحدد تحليله للمعايير المنصوص عليها في الأقسام 7.6.1(و)(1) إلى 7.6.3(و)(2). قدرة مجلس إدارة ICANN لرفض التعديل البديل بموجب هذه الاتفاقية لا يعفي المجلس من واجب ضمان أن أي تعديل المجلس يستوفي المعايير المنصوص عليها في القسم 7.6.1(هـ)(1) إلى 7.6.5(هـ)(4).

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

50. يجوز لمشغل السجل التقدم خطيا بطلب إلى ICANN للإعفاء من التعديل المتفق عليه (كل طلب من هذا القبيل المقدمة من مشغل السجل بموجب هذه الاتفاقية، وهو "طلب الإعفاء") خلال فترة ثلاثين (30) يوما تقويميا من تاريخ تقديم إشعار إلى ICANN مشغل السجل على هذا التعديل وافق . كل طلب الإعفاء سوف المنصوص عليها أساسا لمثل هذا الطلب وتوفير الدعم مفصلة للإعفاء من التعديل المتفق عليه. وقد يتضمن التعديل المتفق عليه وصفا تفصيليا ودعما لأي بدائل أو تنوعا للتعديل المقترح من مشغل السجل. قد يمنح طلب الإعفاء عند الاتفاق الواضح مع عرض مشغل السجل التوافق مع التعديل المتفق لعيه عند معارضته للقوانين المعمول بها أو يتعارض مع المواد العاملة للحالات المالية على المدى الطويل أو ينتج عن عمليات تشغيل مشغل السجل. لن يمنح أي طلب إعفاء إن حددت ICANN أي حرية معقولة وليس منح طلب الإعفاء التي قد ضارة من ناحية المواد على المسجلين أو تؤدي إلى إنكار الفوائد المباشرة للمسجلين. في غضون تسعين (90) يوما تقويميا من استلام ICANN لطلب الإعفاء يجب على ICANN إما الموافقة (قد تكون مشروطة التي الموافقة أو تطرح بدائل أو الاختلاف من التعديل المتفق عليه) أو تنكر طلب الإعفاء كتابة، خلال الوقت الذي سوف التعديل المتفق عليه تعديل هذا الاتفاق. إذا تمت الموافقة على طلب الإعفاء من جانب ICANN، فإن التعديل المتفق عليه لا تعديل هذه الاتفاقية، شريطة، أن أي ظروف، والبدائل أو أشكال مختلفة من التعديل المتفق عليه المطلوبة من قبل ICANN تكون فعالة، وإلى مدى تطبيق، سوف تعديل هذا الاتفاق اعتبارا من التعديل تاريخ السريان. إذا تم رفض طلب الإعفاء من جانب ICANN، يعدل التعديل المعتمد هذا الاتفاق اعتبارا من تاريخ نفاذ التعديل (أو، إذا انقضى هذا التاريخ، ويعتبر هذا التعديل نافذا على الفور وافق على تاريخ هذا الإنكار)، شريطة أنه يجوز لمشغل السجل، في غضون ثلاثين (30) يوما تقويميا بعد استلام تقرير ICANN، الطعن في قرار ICANN لرفض طلب الإعفاء وفقا لإجراءات تسوية المنازعات المنصوص عليها في المادة 5. سيتم اعتبار أن التعديل المتفق عليه الذي لم يعدل هذا الاتفاق خلال معلق من عملية تسوية المنازعات. لتجنب الشكوك، تتم الموافقة فقط على طلبات الإعفاء المقدمة من مشغل السجل المتفق عليها من ICANN بما يتفق مع القسم 7.6(ي) والتي توافق عليها ICANN بعد الوساطة بموجب البند 5.1 أو من خلال لجنة قرار التحكيم بما يتفق مع البند 5.2 ويستثنى مشغل السجل من أي تعديل متفق عليه ولا يتم قبول طلبات الإعفاء الممنوحة إلى مشغل السجل (سواء من خلال ICANN أو من خلال لجنة التحكيم) حيث أنها لن تكون فاعلة بموجب هذه الاتفاقية أو مشغل السجل المعفي من التعديل المتفق عليه.

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

52. لأغراض هذه الاتفاقية القسم 7.6 ستكون المصطلحات التالية لها المعاني التالية:

1. "مشغلي السجل العاملين" تعني بشكل مجمع مشغلي سجل النطاقات من المستوى الأعلى لاتفاقية السجل التي تحتوي على فقرة مشابهة للقسم 7.6 بما يتضمن مشغل السجل.

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

16. "التعديل المقيد" يعني ما يلي: (أ) تعديلا على المواصفات 1 أو (ب) استثناء المدى المحدد بالقسم 2.10 وتعديل محدد على الأسعار المدفوعة من مشغل السجل للمسجلين لعمليات تسجيل اسم النطاق أو (ج) تعديل على تعريف خدمات السجل المحددة مسبقا بالفقرة الأولى من القسم 2 من المواصفات 6 أو (د) تعديل على طول فترة الاتفاقية.

17. "السبب الأساسي والملزم في المصلحة العامة" ويقصد به أي سبب مبرر من خلال هدف مصلحة عامة واضحة وهامة ونوعية تكون في إطار مهمة ICANN ومتسقًا مع التطبيق المتوازن للقيم الأساسية المتبعة في ICANN وفقًا لم هو منصوص عليه في لوائح ICANN.

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

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

1. عملية التفاوض.

1. إذا رغب المدير التنفيذي ("CEO") لـ ICANN أو رئيس مجموعة أصحاب المصلحة المسجل ("الرئيس") في مناقشة أي مراجعة (مراجعات) في هذا الاتفاق، يقوم الرئيس التنفيذي أو الرئيس، حسب الاقتضاء، بتقديم إشعار خطي إلى الشخص الآخر، والذي ينص بالتفصيل المعقول على التنقيحات المقترحة على هذا الاتفاق ("إشعار التفاوض"). ومع عدم الإخلال بما سبق، لا يجوز للرئيس التنفيذي أو الرئيس (1) اقتراح تعديلات على هذا الاتفاق تعدل سياسة الإجماع الموجودة ثم، (2) اقتراح تعديلات على هذه الاتفاقية وفقا لهذا القسم 7.7 في أو قبل 30 يونيو 2014، أو (3) اقتراح تعديلات أو إرسال إشعار التفاوض أكثر من مرة واحدة خلال أي فترة اثني عشر (12) شهرًا تبدأ في 1 يوليو 2014.

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

56. إذا، وبعد انتهاء فترة مناقشة، يتم التوصل إلى اتفاق بشأن التنقيحات المقترحة، يجب على ICANN نشر التنقيحات المقترحة المتفق عليها بصورة متبادلة على موقعها على الانترنت للتعليق العام لمدة لا تقل عن ثلاثين (30) يوما تقويميا ("فترة النشر") وتقديم إشعار بهذه المراجعات لجميع مشغلي السجلات المنطبقين وفقا للبند 7.9. تلتزم ICANN ومجموعة العمل بالنظر في التعليقات العامة المقدمة بشأن التنقيحات المقترحة خلال فترة النشر (بما في ذلك التعليقات المقدمة من مشغلي السجلات المنطبقين). بعد انتهاء فترة النشر، يتم تقديم المراجعات المقترحة للحصول على موافقة مشغل السجل (وفقًا لم هو محدد في البند 7.6) والحصول على موافقة مجلس إدارة ICANN. إذا تم الحصول على هذه الموافقات، تعتبر التنقيحات المقترحة على التعديل موافقة معتمدة (وفقًا لما هو منصوص عليه في البند 7.6) من جانب مشغلي السجلات المعتمدين، وتعتبر تعديلا على هذه الاتفاقية بموجب إشعار مدته ستين (60) يوما تقويميا من ICANN إلى مشغل السجل.

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

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

20. يجب على الوسيط إجراء الوساطة وفقا لقواعد وإجراءات الوساطة التيسيرية التي يحدد بعد التشاور مع الطرفين. يجب على الأطراف مناقشة النزاع بحسن نية ومحاولة، بمساعدة الوسيط للتوصل إلى حل ودي للنزاع.

21. يتحمل كل طرف المصاريف الخاصة به في وساطة. الطرفان مناصفة الرسوم والمصاريف من الوسيط.

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

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

58. إذا لم تتوصل ICANN ومجموعة العمل بعد عملية الوساطة إلى اتفاق بشأن التنقيحات المقترحة، فيجوز للمدير التنفيذي أو الرئيس تزويد الشخص الآخر بإشعار خطي ("إشعار تحكيم") يطالب ICANN ومشغلي السجل العاملين لحل النزاع عن طريق التحكيم الملزم وفقا لأحكام التحكيم من القسم 5.2، تخضع لمتطلبات وقيود هذا القسم 7.7(هـ).

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

25. لا يجوز تقديم أي نزاع بشأن التنقيحات المقترحة للتحكيم إلى حد ارتباط موضوع التنقيحات المقترحة (1) بسياسة الإجماع، أو (2) يندرج ضمن فئات الموضوعات المنصوص عليها في القسم 1.2 من المواصفة 1، أو (3) يسعى إلى تعديل أي من الأحكام أو المواصفات التالية من هذه الاتفاقية: المادة 1، و3 و6؛ البند 2.1، و2.2، و2.5، و2.7، و2.9، و2.10، و2.16، و2.17، و2.19، و4.1، و4.2، و7.3، و7.6، و7.7، و7.8، و7.10، و7.11، و7.12، و7.13، و7.14، و7.16؛ و البند 2.8 والمواصفة 7 (ولكن فقط إلى حد سعي هذه التنقيحات المقترحة إلى تنفيذ RPM ولم يشملها البند 2.8 والمواصفة 7)؛ الملحق أ، والمواصفات 1، و4، و6، و10، و11.

26. سوف الوسيط إحاطة لوحة المحكم فيما يتعلق ICANN ومقترحات الفريق العامل منها تتعلق التنقيحات المقترحة.

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

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

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

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

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

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

إذا كان موجهًا إلى ICANN، يتم الإرسال على العنوان:
Internet Corporation for Assigned Names and Numbers
00000 Xxxxxxxxxx Xxxxx, Xxxxx 000
Xxx Xxxxxxx, XX 00000-0000

USA
هاتف: x0-000-000-0000
فاكس: x0-000-000-0000
عناية: الرئيس والمدير التنفيذي (President and CEO)

مع إرسال نسخة مطلوبة إلى: المستشار العام البريد الإلكتروني: (وفقًا لما يتم تحديده من وقت لآخر).

إذا كان موجهًا إلى مُشغل السجل، يتم الإرسال على العنوان:
[________________]
[________________]
[________________]

هاتف:

مع نسخة مطلوبة إلى:
البريد الإلكتروني: (وفقًا لما يتم تحديده من وقت لآخر).

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

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

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

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

14. الأحكام القضائية. تحترم ICANN أي قرار صادر عن محكمة دائرة مختصة بما في ذلك أي قرارات من أي دائرة لم يشترط فيها موافقة أو عدم معارضة الحكومة لتفويض TLD. ومع هذا فبموجب أي حكم لهذه الاتفاقية، لن يكون تنفيذ ICANN لمثل هذا الحكم خرقا لهذه الاتفاقية

15. السرية

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

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

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

[ملاحظة: يسري البند التالي على المنظمات الحكومية الدولية والكيانات الحكومية فقط.]

7.16 فقرة خاصة تتعلق بالمنظمات الحكومية الدولية أو الأجهزة الحكومية.

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

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

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

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

(هـ) وعليه يقدم مشغل السجل ويضمن ما يلي وفقا لما يعرفه وقت تاريخ تنفيذ الاتفاقية عدم وجود متطلبات لـ ICANN تتعارض مع أية انتهاكات للقانون المعمول به.

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

* * * * *

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

شركة الإنترنت للأرقام والأسماء المُخصصة

إعداد: _____________________________
[_____________] الرئيس والمدير التنفيذي التاريخ:

[مُشغل السجل]

إعداد: _____________________________
[____________] [____________]
التاريخ:

الملحق أ الخدمات المعتمدة

يحدد دليل مقدم طلبات نطاقات gTLD (المتوفر على الموقع xxxx://xxxxxxxx.xxxxx.xxx/xx/xxxxxxxxxx/xxx) وسياسة RSEP الإجراءات الخاصة بالنظر في خدمات السجل المقترحة. يجوز لمشغل السجل توفير أي خدمات تقتضيها أحكام هذه الاتفاقية. بالإضافة إلى ذلك، تم تحديد الخدمات التالية (إن وجدت) على وجه الخصوص بأنها معتمدة من ICANN قبل تاريخ سريان هذه الاتفاقية، ويجوز لمشغل السجل تقديم هذه الخدمات:

تعيين سياسات الإجماع والسياسات المؤقتة

1. سياسات الإجماع.

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

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

      1. المشاكل التي يعد القرار المنتظم أو المُنسَّق ضروريًا فيها بشكل معقول؛ لتسهيل إمكانية تشغيل و/أو أمان و/أو استقرار الإنترنت أو نظام أسماء النطاقات ("DNS")؛

      2. المواصفات الوظيفية والأداء لتقديم خدمات مشغل السجل؛

      3. أمان واستقرار قاعدة بيانات السجل لنطاق TLD؛

      4. سياسات السجل الضرورية بشكل معقول لتنفيذ سياسات الإجماع المتعلقة بعمليات تشغيل السجل أو مُسجلي السجل؛

      5. حل النزاعات المتعلقة بتسجيل أسماء النطاقات (فيما يتعارض مع استخدام أسماء النطاقات هذه) أو

      6. القيود المفروضة على الملكية المشتركة لمشغلي السجلات وأمناء السجلات أو موزعي أمناء السجلات واللوائح والقيود فيما يتعلق بعمليات التسجيل والتسجيل ودمج استخدام بيانات التسجيل والمسجل في حالة عدم وجود مشغل السجل وأمين السجل أو موزع لأمين السجل.

   3. وتشمل هذه الفئات من المسائل المشار إليها في القسم 1.2 من هذه المواصفة؛ على سبيل المثال لا الحصر:

      1. مبادئ تخصيص الأسماء المسجلة في TLD (مثل: أولوية التسجيل لمن يبادر بالحجز، التجديد الملائم، منح فترة تعليق بعد انتهاء الصلاحية)؛

      2. وحظر مزودي الامتداد والمُسجلين من تخزين أسماء النطاقات بكميات كبيرة أو المضاربة فيها؛

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

      4. والاحتفاظ بمعلومات دقيقة ومحدَّثة تتعلق بعمليات تسجيل أسماء النطاقات والوصول إليها، والقيام بإجراءات لمنع عرقلة عمليات تسجيل أسماء النطاقات التي ترجع لتعليق أو إنهاء عمليات التشغيل بواسطة مُشغل سجل أو مُسجل؛ بما في ذلك الإجراءات المتعلقة بتعيين المسؤولية عن تشغيل أسماء نطاقات مسجلة في TLD الذي تأثر بهذا التعليق أو الإنهاء.

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

      1. تضع سعرًا لخدمات السجل، أو تضع حدودًا له؛

      2. تعمل على تعديل بنود أو شروط تجديد أو إنهاء اتفاقية السجل، أو؛

      3. تعديل القيود المفروضة على السياسات المؤقتة (المحددة أدناه) أو سياسات الإجماع؛

      4. تعمل على تعديل الشروط المتعلقة بالرسوم التي يدفعها مُشغل السجل لxxxx XXXXX، والمبيَّنة في اتفاقية السجل، أو

      5. تعديل التزامات ICANN لضمان المعاملة العادلة لمشغلي السجلات والتصرف بطريقة منفتحة وشفافة.

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

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

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

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

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

1. متطلبات مستودع البيانات

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

الجزء أ - المواصفات الفنية

1. الإيداعات. سوف يكون هناك نوعين من الإيداعات: كامل وتبايني. بالنسبة لكلا النوعين، فإن عالم الأشياء الخاصة بالسجل المقرر أن تكون مستودعًا للبيانات هي الأشياء اللازمة من أجل عرض كفة خدمات السجل المعتمدة.

   1. "الإيداع الكامل" ويتألف من البيانات التي تعكس حالة السجل اعتبارًا من 00:00:00 بتوقيت UTC (التوقيت العالمي المنسق) في تاريخ تقديم هذا الإيداع الكامل إلى وكيل المستودع.

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

2. جدول الإيداعات. يلتزم مُشغل السجل بتقديم مجموعة من ملفات المستودع يوميًا على النحو التالي:

   1. وكل يوم أحد، يجب تقديم إيداع كامل إلى وكيل المستودع بحلول 23:59 بالتوقيت العالمي المنسق.

   2. أما الأيام الست (6) الأخرى من الأسبوع، يجب تقديم إيداع كامل أو إيداع تبايني مقابل إلى وكيل المستودع بحلول الساعة 23:59 بالتوقيت العالمي المنسق.

3. مواصفات تنسيق المستودع.

   1. تنسيق المستودع. الأشياء الخاصة بالسجل، مثل النطاقات وجهات الاتصال وأسماء الخوادم وأمناء السجلات إلخ، سوف يتم تجميعها في ملف يتم إنشاؤه بالطريقة المشار إليها في draft-arias-noguchi-registry-data-escrow، راجع الجزء أ، البند 9، المرجع 1 من هذه المواصفة وdraft-arias-noguchi-dnrd-objects-mapping، راجع الجزء أ، البند 9 المرجع 2 من هذه المواصفة (ويشار إليها جميعًا بلفظ "مواصفة DNDE"). وتصف المواصفة DNDE بعض العناصر بأنها اختيارية، وسوف يقوم مشغل السجل بتضمين تلك العناصر في المستودعات إذا كانت متوفرة. وإذا لم يكن مشغل السجل RFC بالفعل، فيلزم باستخدام أحدث نسخة تمهيدية لمواصفة DNDE المتاحة في تاريخ السريان. ويجوز لمشغل السجل، وفقًا لاختياره استخدام إصدارات أحدث لمواصفة DNDE بعد تاريخ السريان. وبمجرد نشر مواصفة DNDE باعتبارها RFC، يلتزم مشغل السجل تنفيذ تلك النسخة من مواصفة DNDE، بما لا يقل عن مائة وثمانون (180) يومًا تقويمًا بعد ذلك. وسوف يتم استخدام ترميز حروف UTF-8.

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

4. معالجة ملفات الإيداع. يوصى باستخدام عملية الضغط من أجل تقليل وقت تحويل الإلكتروني للبيانات، ومتطلبات سعة التخزين. يستخدم تشفير البيانات لضمان خصوصية مستودع بيانات السجل. الملفات المعدة لضغط والتشفير تكون في صيغة OpenPGP ثنائية حسب صيغة رسالة - RFC 4880، راجع القسم 9، المرجع 3 من هذه المواصفة. الخوارزميات المقبولة لتشفير المفتاح العام، والتشفير المتناسق العام، والمزج والضغط هي عمليات التشفير المسردة في RFC 4880، وغير المشار إليها بأنها منتقصة في سجل IANA من نوع OpenPGP، راجع الجزء أ، البند 9، المرجع 4 من هذه المواصفة، وهي أيضًًا مجانية بدون رسوم. الإجراءات المتبعة لتتبع ملف بيانات في صيغة نصية أصلية هي:

   1. ملف XML الخاص بالمستودع وفقًا لما هو مشار إليه في الباب أ، القسم 9، المرجع 1 من هذه المواصفة يجب تسميته بأنه ملف الاحتواء وفقًا لما هو مشار إليه في الباب 5 ولكن بامتداد XML.

   2. ويتم تجميع ملف (ملفات البيانات) في ملف tar غير مضغوط يسمى بالاسم (1) ولكن بامتداد tar.

   3. رسالة OpenPGP المضغوطة والمشفرة يتم إنشاؤها من خلال استخدام ملف tarball كإدخال فردي. أسلوب الضغط المقترح هو ZIP حسب RFC 4880. يتم تشفير البيانات المضغوطة باستخدام المفتاح العام لوكيل المستودع. الخوارزميات المقترحة لتشفير المفتاح العام هي Elgamal وRSA حسب RFC 880. الخوارزميات المقترحة لتشفير المفتاح المتناسق هي TripleDES، وAES128 وCAST5 حسب RFC 4880.

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

   5. يتم إنشاء ملف توقيع رقمي لكل ملف معالج باستخدام المفتاح الخاص بمشغل السجل. ويكون ملف التوقيع الرقمي بصيغة OpenPGP الثنائية حسب RFC 4880 القسم 9، المرجع 3 ولا يتم ضغطه أو تشفيره. الخوارزميات المقترحة للتوقيعات الرقمية هي DSA وRSA حسب RFC 4880. الخوارزمية المقترحة لxxxx في التوقيعات المقترحة هي SHA256.

   6. وبعد ذلك يتم تحويل الملفات المعالجة وملفات التوقيعات الرقمية إلى وكيل المستودع من خلال آليات إلكترونية آمنة، مثل SFTP، وSCP، وHTTPS الخاصة بتحميل الملفات، إلخ، وفقًا لما هو متفق عليه بين وكيل المستودع ومشغل السجل. التسليم غير الإلكتروني من خلال وسيط مادي مثل أجهزة CD-ROM، أو DVD-ROM، أو أجهزة تخزين USB يمكن استخدامها إذا رخصت بها ICANN.

   7. بعد ذلك يقوم وكيل المستودع بالتحقق من كل ملف بيانات تم نقله (معالجته) من خلال استخدام الإجراءات المشار إليها في الجزء أ، القسم 8 من هذه المواصفة.

5. اصطلاحات تسمية الملفات. تتم تسمية الملفات وفق الاصطلاحات التالية: {gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} حيث:

   1. {gTLD} تستبدل باسم gTLD؛ في حالة IDN-TLD، يتم استخدام الصيغة المتوافقة مع ASCII (تسمية أ)؛

   2. يستبدل {YYYY-MM-DD} بالتاريخ المقابل للتاريخ المستخدم كعلامة مائية لتوقيت المعاملات؛ أي بالنسبة للإيداع الكامل المقابل إلى 2009-08-02T00:00Z، يكون النص المستخدم "2009-08-02"؛

   3. يتم استبدال {type} بأي من التالي:

      1. "full"، إن كانت البيانات لإيداع كامل؛

      2. "diff"، إذا كانت البيانات تمثل إيداعًا تباينيًا؛

      3. "thin"، إذا كانت البيانات تمثل ملفًا تجميعيًا للوصول لبيانات التسجيل، وفقًا لما هو محدد في القسم 3 من المواصفة 4؛

   4. يتم استبدال {#} بموقع الملف ضمن سلسلة الملفات، بدءًا من "1"؛ إن كان ملفًا واحدًا، فيتم استبدال الرمز بالرقم "1".

   5. يتم استبدال {rev} برقم المراجعات (أو إعادة إرسال) الملف بدءًا من "0":

   6. يتم استبدال {ext} بـ "sig" إذا كان ملفًا للتوقيع الرقمي للملف شبه متجانس. أو يتم استبداله بـ "ryde" خلافًا لذلك.

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

7. الإشعار بالإيداعات. سيقوم مُشغل السجل -بالتزامن مع تسليم كل إيداع- بتسليم بيان خطي (قد يكون عبر بريد إلكتروني مصادق عليه) إلى وكيل المستودع وICANN (من خلال استخدام API المشار إليها في draft-lozano-icann-registry-interfaces، راجع الباب أ، القسم 9 من المرجع 5 في هذه المواصفة ("مواصفة الواجهة"))؛ على أن يحتوي على نسخة من التقرير الذي تم إنشاؤه عند إنشاء الإيداع، والحالات التي تم فيها مراقبة الإيداع بواسطة مُشغل السجل، ويتميز بالكمال والدقة. يلتزم مشغل السجل بتضمين "id" الخاص بالإيداعات و"إعادة إرسال" الخصائص في البيان الخاص به. والخصائص موضحة بالتفصيل في الجزء أ، البند 9 المرجع 1 من هذه المواصفة.

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

8. إجراءات التحقق.

   1. يجري التحقق من ملف التوقيع الخاصة بكل ملف تمت معالجته.

   2. وإذا كانت الملفات المعالجة أجزاء من ملف أكبر، يتم تجميع هذا الملف.

   3. يتم إلغاء تشفير كل ملف تم الحصول عليه في الخطوة السابقة وإلغاء ضغطه.

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

   5. إذا اشتمل الجزء أ، القسم 9، المرجع 1 من هذه المواصفة على عملية توثيق، فيتم تطبيق ذلك في هذه الخطوة.

إذا تبين وجود أي تعارض في أي من هذه الخطوات، يتم اعتبار المستودع غير كامل.

9. المراجع.

   1. مواصفة مستودع بيانات أسماء النطاقات (العمل الجاري)، xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxx-xxxxxxx-xxxxxxxx-xxxx-xxxxxx

   2. تخطيط أشياء بيانات تسجيل أسماء النطاقات (DNRD)، xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxx-xxxxxxx-xxxx-xxxxxxx-xxxxxxx

   3. تنسيق رسائلOpenPGP، xxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx

   4. معلمات OpenPGP، xxxx://xxx.xxxx.xxx/xxxxxxxxxxx/xxx‑parameters/pgp‑parameters.xhtml

   5. واجهات ICANN للسجلات ووكلاء مستودعات البيانات، xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxxx-xxxxx-xxxxxxxx-xxxxxxxxxx

الجزء ب - المتطلبات القانونية

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

11. الرسوم. يجب أن يدفع مُشغل السجل -أو يدفع آخر نيابة عنه- رسومًا لوكيل المستودع مباشرةً. وإذا فشل مُشغل السجل في دفع أية رسوم في التاريخ (التواريخ) المحدد، فسيقدم وكيل المستودع إشعارًا خطيًا إلى ICANN بعدم الدفع هذا، ويمكن أن تدفع ICANN الرسم (الرسوم) المستحقة من قبل، خلال خمسة عشرة (15) يومًا تقويميًا بعد استلام الإشعار الخطي من وكيل المستودع. وبعد دفع ICANN للرسوم المستحقة من قبل، يجب أن تطالب ICANN مُشغل السجل بهذا المبلغ، الذي سيكون عليه إرساله إلى ICANN إضافة إلى قيمة دفع الرسوم التالية، بموجب اتفاقية السجل.

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

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

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

14. النسخ. يجوز السماح لوكيل المستودع بنسخ أي إيداع؛ من أجل الالتزام ببنود وشروط اتفاقية المستودع.

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

    1. انتهت صلاحية اتفاقية السجل بدون تجديد، أو تم إنهاؤها، أو

    2. لم تتلقى ICANN إشعارًا وفقًا لما هو مشار إليه في الجزء ب، القسم 7.1، و7.2 من هذه المواصفة من وكيل المستودع في غضون خمسة (5) أيام تقويمية بعد تاريخ التسليم المحدد للإيداع، (أ) قدمت ICANN إشعارًا إلى وكيل المستودع ومشغل السجل بهذا الإخفاق، و(ب) لم تتلقى ICANN، في غضون سبعة (7) أيام تقويمية بعد هذا الإشعار، أي إشعار من وكيل المستودع

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

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

    5. قام مُشغل السجل: (1) بإيقاف مزاولة نشاطه في الفترة العادية، أو (2) بإعلان إفلاسه أو أفلس، أو حدث له أي شيء مشابه لما يحدث وفقًا لقوانين المقاضاة في أي مكان بالعالم، أو

    6. إذا تعرض مشغل السجل لتوقف وظائف السجل الحيوية وأكدت ICANN على حقوقها بموجب البند 2.13 من هذه الاتفاقية

    7. أو قامت محكمة مختصة أو هيئة تحكيم أو هيئة قضائية أو هيئة حكومية بتفويض ICANN بتحرير الإيداعات

    8. أو بموجب عمليات تقديم التوافق التعاقدي والتشغيلي وفقًا لما هو منصوص عليها في البند 2.11 من هذه الاتفاقية.

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

16. التحقق من الإيداعات.

    1. خلال أربع وعشرون (24) ساعة بعد استلام كل إيداع أو إيداع مصحح، يجب أن يقوم وكيل المستودع بالتحقق من صحة تنسيق واكتمال كل إيداع، وأن يسلم إلى ICANN إشعارًا يتم إنشاؤه لكل إيداع. ويتم تسليم التقارير إلكترونيًا باستخدام API المشار إليها في draft-lozano-icann-registry-interfaces، راجع الجزء أ، القسم 9، المرجع 5 من هذه المواصفة.

    2. إذا تبين لوكيل المستودع أن أي إيداع قد فشل في إجراءات التوثيق أو أن وكيل المستودع لا يتلقى أي إيداع مقرر، فيتعين على وكيل المستودع إشعار مشغل السجل سواء عن طريق البريد الإلكتروني أو الفاكس أو الهاتف وICANN (من خلال استخدام API المشار إليه في draft-lozano-icann-registry-interfaces، راجع الجزء أ، القسم 9، المرجع 5 من هذه المواصفة) بعدم الالتزام أو عدم الاستلام في غضون أربع وعشرين (24) ساعة من استلام الإيداع غير المتوافق أو الموعد النهائي لهذا الإيداع حسبما ينطبق. وبعد الإشعار بفشل هذا التحقق أو التنفيذ، يجب أن يبدأ مُشغل السجل في تطوير التعديلات والتحديثات والتصحيحات وطرق إصلاح الإيداع الأخرى اللازمة لتسليم وتمرير الإيداع في إجراءات تجاوز التحقق، وتقديم طرق الإصلاح هذه إلى وكيل المستودع، بأسرع ما يمكن.

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

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

1. تنسيق التقرير الشهري لمشغل السجل ومحتواه

يلتزم مشغل السجل بتوفير مجموعة واحدة من التقارير الشهرية لكل نطاق gTLD، وذلك باستخدام API المشار إليه في draft-lozano-icann-registry-interfaces، راجع المواصفة 2، الجزء أ، القسم 9، المرجع 5 مع المحتوى التالي.

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

1. تقرير المعاملات لكل أمين سجل. يتم وضع هذا التقرير في ملف بتنسيق قيمة منفصلة بفاصلة وفقًا لما هو محدد في المواصفة RFC 4180. وتتم تسمية الملف "gTLD-transactions-yyyymm.csv"، حيث إن "gTLD" هي اسم gTLD، وفي حالة IDN-TLD، يتم استخدام التسمية-أ؛ و"yyyymm" هي سنة وشهر تقديم التقرير. يجب أن يحتوي الملف على الحقول التالية لكل أمين سجل:

رقم الحقل	اسم الحقل	الوصف
01	registrar-name	اسم شركة أمين السجل بالكامل كما هو مسجل مع IANA
02	iana-id	في الحالات التي يعمل فيها مشغل السجل بصفة أمين سجل (أي دون استخدام أمين سجل معتمد من ICANN) يجب استخدام 9999، أو يجب استخدام معرف IANA لمعرف أمين السجل الراعي وفقًا لما هو محدد في ttp://xxx.xxxx.xxx/xxxxxxxxxxx/xxxxxxxxx-xxxx
03	total-domains	إجمالي أسماء النطاقات قيد الرعاية في أي حالة EPPولكن بانتظار الإنشاء والتي لم يتم تطهيرها حتى الآن
04	total-nameservers	إجمالي خوادم الاسم (سواء كانت عناصر مضيف أو مضيفين لخادم الاسم باعتباره خصائص لأسماء النطاقات) المرتبطة بأسماء النطاقات المسجلة لنطاق TLD في أي حالة EPP ولكن بانتظار الإنشاء والتي لم يتم تطهيرها حتى الآن
05	net-adds-1-yr	عدد من النطاقات المسجلة بنجاح (أي ليست في حالة انتظار إنشاء EPP) مع فترة مبدئية مدتها سنة (1) واحدة (وعدم الحذف داخل فترة السماح المضافة). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة الإضافة.
06	net-adds-2-yr	عدد من النطاقات المسجلة بنجاح (أي ليست في حالة انتظار إنشاء EPP) مع فترة مبدئية مدتها سنتان (2) (وعدم الحذف داخل فترة السماح المضافة). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة الإضافة.
07	net-adds-3-yr	عدد من النطاقات المسجلة بنجاح (أي ليست في حالة انتظار إنشاء EPP) مع فترة مبدئية مدتها ثلاث (3) سنوات (وعدم الحذف داخل فترة السماح المضافة). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة الإضافة.
08	net-adds-4-yr	عدد من النطاقات المسجلة بنجاح (أي ليست في حالة انتظار إنشاء EPP) مع فترة مبدئية مدتها أربع (4) سنوات (وعدم الحذف داخل فترة السماح المضافة). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة الإضافة.
09	net-adds-5-yr	عدد من النطاقات المسجلة بنجاح (أي ليست في حالة انتظار إنشاء EPP) مع فترة مبدئية مدتها خمس (5) سنوات (وعدم الحذف داخل فترة السماح المضافة). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة الإضافة.
10	net-adds-6-yr	عدد من النطاقات المسجلة بنجاح (أي ليست في حالة انتظار إنشاء EPP) مع فترة مبدئية مدتها ست (6) سنوات (وعدم الحذف داخل فترة السماح المضافة). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة الإضافة.
11	net-adds-7-yr	عدد من النطاقات المسجلة بنجاح (أي ليست في حالة انتظار إنشاء EPP) مع فترة مبدئية مدتها سبع (7) سنوات (وعدم الحذف داخل فترة السماح المضافة). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة الإضافة.
12	net-adds-8-yr	عدد من النطاقات المسجلة بنجاح (أي ليست في حالة انتظار إنشاء EPP) مع فترة مبدئية مدتها ثماني (8) سنوات (وعدم الحذف داخل فترة السماح المضافة). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة الإضافة.
13	net-adds-9-yr	عدد من النطاقات المسجلة بنجاح (أي ليست في حالة انتظار إنشاء EPP) مع فترة مبدئية مدتها تسع (9) سنوات (وعدم الحذف داخل فترة السماح المضافة). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة الإضافة.
14	net-adds-10-yr	عدد من النطاقات المسجلة بنجاح (أي ليست في حالة انتظار إنشاء EPP) مع فترة مبدئية مدتها عشر (10) سنوات (وعدم الحذف داخل فترة السماح المضافة). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة الإضافة.
15	net-renews-1-yr	عدد من النطاق التي جرى تجديدها بنجاح (أي ليست في حالة انتظار إنشاء EPP) إما تلقائياً أو عن طريق الأمر مع تجديد فترة جديدة مدتها سنة واحدة (1) (وليس حذف داخل فترة سماح الجديد أو التجديد التلقائي). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة التجديد أو التجديد التلقائي.
16	net-renews-2-yr	عدد من النطاق التي جرى تجديدها بنجاح (أي ليست في حالة انتظار إنشاء EPP) إما تلقائياً أو عن طريق الأمر مع تجديد فترة جديدة مدتها عامان (2) (وليس حذف داخل فترة سماح الجديد أو التجديد التلقائي). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة التجديد أو التجديد التلقائي.
17	net-renews-3-yr	عدد من النطاقات التي جرى تجديدها بنجاح (أي ليست في حالة انتظار إنشاء EPP) إما تلقائياً أو عن طريق الأمر مع تجديد فترة جديدة مدتها ثلاث (3) أعوام (وليس حذف داخل فترة سماح الجديد أو التجديد التلقائي). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة التجديد أو التجديد التلقائي.
18	net-renews-4-yr	عدد من النطاقات التي جرى تجديدها بنجاح (أي ليست في حالة انتظار إنشاء EPP) إما تلقائياً أو عن طريق الأمر مع تجديد فترة جديدة مدتها أربع (4) أعوام (وليس حذف داخل فترة سماح الجديد أو التجديد التلقائي). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة التجديد أو التجديد التلقائي.
19	net-renews-5-yr	عدد من النطاقات التي جرى تجديدها بنجاح (أي ليست في حالة انتظار إنشاء EPP) إما تلقائياً أو عن طريق الأمر مع تجديد فترة جديدة مدتها خمسة (5) أعوام (وليس حذف داخل فترة سماح الجديد أو التجديد التلقائي). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة التجديد أو التجديد التلقائي.
20	net-renews-6-yr	عدد من النطاقات التي جرى تجديدها بنجاح (أي ليست في حالة انتظار إنشاء EPP) إما تلقائياً أو عن طريق الأمر مع تجديد فترة جديدة مدتها ستة (6) أعوام (وليس حذف داخل فترة سماح الجديد أو التجديد التلقائي). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة التجديد أو التجديد التلقائي.
21	net-renews-7-yr	عدد من النطاقات التي جرى تجديدها بنجاح (أي ليست في حالة انتظار إنشاء EPP) إما تلقائياً أو عن طريق الأمر مع تجديد فترة جديدة مدتها سبعة (7) أعوام (وليس حذف داخل فترة سماح الجديد أو التجديد التلقائي). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة التجديد أو التجديد التلقائي.
22	net-renews-8-yr	عدد من النطاقات التي جرى تجديدها بنجاح (أي ليست في حالة انتظار إنشاء EPP) إما تلقائياً أو عن طريق الأمر مع تجديد فترة جديدة مدتها ثمانية (8) أعوام (وليس حذف داخل فترة سماح الجديد أو التجديد التلقائي). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة التجديد أو التجديد التلقائي.
23	net-renews-9-yr	عدد من النطاقات التي جرى تجديدها بنجاح (أي ليست في حالة انتظار إنشاء EPP) إما تلقائياً أو عن طريق الأمر مع تجديد فترة جديدة مدتها تسعة (9) أعوام (وليس حذف داخل فترة سماح الجديد أو التجديد التلقائي). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة التجديد أو التجديد التلقائي.
24	net-renews-10-yr	عدد من النطاقات التي جرى تجديدها بنجاح (أي ليست في حالة انتظار إنشاء EPP) إما تلقائياً أو عن طريق الأمر مع تجديد فترة جديدة مدتها عشرة (10) أعوام (وليس حذف داخل فترة سماح الجديد أو التجديد التلقائي). يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة التجديد أو التجديد التلقائي.
25	transfer-gaining-successful	عدد من تحويلات النطاقات التي يقوم أمين السجل والتي تم الانتهاء منها بنجاح (سواء بصورة صريحة أو تمت الموافقة عليها تلقائيًا) ولم يتم إلغاؤها في غضون فترة مهلة التحويل. يجب الإبلاغ عن معاملة في الشهر الذي تنتهي فيه فترة مهلة التحويل.
26	transfer-gaining-nacked	عدد عمليات تحويل النطاقات التي تمت بمعرفة أمين السجل هذا والتي تم رفضها (على سبيل المثال، EPP transfer op="reject") من خلال أمين سجل آخر
27	transfer-losing-successfully	عدد من تحويلات النطاقات التي يقوم أمين سجل آخر والتي تم الانتهاء منها بنجاح (سواء بصورة صريحة أو تمت الموافقة عليها تلقائيًا)
28	transfer-losing-nacked	عدد عمليات تحويل النطاقات التي تمت بمعرفة أمين سجل آخر والتي تم رفضها أمين السجل هذا (على سبيل المثال، EPP transfer op="reject")
29	transfer-disputed-won	عدد نزاعات النقل التي كسبها أمين السجل هذا (والتي تم الإبلاغ عنها في الشهر الذي تقرر حدوثها فيه)
30	transfer-disputed-lost	عدد نزاعات النقل التي خسرها أمين السجل هذا (والتي تم الإبلاغ عنها في الشهر الذي تقرر حدوثها فيه)
31	transfer-disputed-nodecision	عدد نزاعات النقل التي تضم أمين السجل هذا بقرار منقسم أو بدون قرار (والتي تم الإبلاغ عنها في الشهر الذي تقرر حدوثها فيه)
32	deleted-domains-grace	النطاقات التي تم حذفها في غضون فترة سماح الإضافة (ولا تشمل الأسماء التي تم حذفها في حالة EPP المقرر إنشاؤها). يجب الإبلاغ عن حذف في الشهر الذي يتم فيه تحرير الاسم.
33	deleted-domains-nograce	النطاقات التي تم حذفها خارج فترة سماح الإضافة (ولا تشمل الأسماء التي تم حذفها في حالة EPP المقرر إنشاؤها). يجب الإبلاغ عن حذف في الشهر الذي يتم فيه تحرير الاسم.
34	restored-domains	أسماء النطاقات المستردة من فترة الاسترداد
35	restored-noreport	العدد الإجمالي للأسماء المستعادة التي فشل المُسجل في تقديم تقرير استعادة بها
36	agp-exemption-requests	العدد الإجمالي لـ AGP (إضافة فترة سماح) طلبات الإعفاء
37	agp-exemptions-granted	العدد الإجمالي لـ AGP (إضافة فترة سماح) طلبات الإعفاء
38	agp-exempted-domains	العدد الإجمالي للأسماء المتضررين الممنوحة من AGP (إضافة فترة سماح) لطلبات الإعفاء
39	attempted-adds	عدد محاولا أوامر إنشاء أسماء نطاقات (الناجحة والفاشلة)

يتضمن السطر الأول أسماء الحقول تماماً كما هو موضح في الجدول أعلاه بأنه "خط رئيسي" كما هو موضح في القسم 2 من RFC 4180. ويجب أن يشتمل السطر الأخير من كل تقرير كل عمود في جميع المسجلين؛ الحقل الأول من هذا الخط يجب قراءة "الإجمالي" في حين أن الحقل الثاني يجب أن يترك فارغاً في هذا السطر. لا تصف خطوط أخرى الخط الموصوف أعلاه والذي يتعين إدراجه. وسوف تكون فواصل السطور <U+000D، U+000A> وفقًا لما هو محدد في RFC 4180.

2. تقرير نشاط وظائف السجل. يتم وضع هذا التقرير في ملف بتنسيق قيمة منفصلة بفاصلة وفقًا لما هو محدد في المواصفة RFC 4180. تتم تسمية الملف "gTLD-activity-yyyymm.csv"، حيث إن "gTLD" هي اسم gTLD، وفي حالة IDN-TLD، يتم استخدام التسمية-أ؛ و"yyyymm" هي سنة وشهر تقديم التقرير. يجب أن يحتوي الملف على الحقول التالية:

رقم الحقل	اسم الحقل	الوصف
01	operational-registrars	عدد أمناء السجلات التشغيليين في نهاية فترة الإبلاغ
02	ramp-up-registrars	عدد أمناء السجلات الذين حصلوا على كلمة مرور للوصول إلى OT&E في نهاية فترة الإبلاغ
03	pre-ramp-up-registrars	عدد أمناء السجلات الذين طلبوا الوصول، ولكن لم يدخلوا حتى الآن في فترة القوة في نهاية فترة الإبلاغ
04	zfa-passwords	عدد كلمات المرور لملفات المنطقة النشطة في نهاية فترة الإبلاغ
05	whois-43-queries	عدد استعلامات WHOIS (المنفذ-43) التي تم الرد عليها خلال فترة الإبلاغ
06	web-whois-queries	عدد استعلامات Whois المستندة إلى الويب والتي تم الرد عليها خلال فترة الإبلاغ، ولا يشمل ذلك Whois القابلة للبحث
07	searchable-whois-queries	عدد استعلامات Whois القابلة للبحث والتي تم الرد عليها خلال فترة الإبلاغ، إن عرض ذلك
08	dns-udp-queries-received	عدد استعلامات DNS الواردة عبر نقل UDP خلال فترة الإبلاغ
09	dns-udp-queries-responded	عدد استعلامات DNS الواردة عبر نقل UDP والتي تم الرد عليها خلال فترة الإبلاغ
10	dns-tcp-queries-received	عدد استعلامات DNS الواردة عبر نقل TCP خلال فترة الإبلاغ
11	dns-tcp-queries-responded	عدد استعلامات DNS الواردة عبر نقل TCP والتي تم الرد عليها خلال فترة الإبلاغ
12	srs-dom-check	عدد طلبات "فحص" أسماء نطاقات SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
13	srs-dom-create	عدد طلبات "إنشاء" أسماء نطاقات SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
14	srs-dom-delete	عدد طلبات "حذف" أسماء نطاقات SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
15	srs-dom-info	عدد طلبات "معلومات" أسماء نطاقات SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
16	srs-dom-renew	عدد طلبات "تجديد" أسماء نطاقات SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
17	srs-dom-rgp-restore-report	عدد طلبات "استعادة" أسماء نطاقات SRS (أي EPP وأي واجهة أخرى) لتقديم تقرير استعادة والتي تم الرد عليها خلال فترة الإبلاغ
18	srs-dom-rgp-restore-request	عدد طلبات "استعادة" أسماء نطاقات SRS (أي EPP وأي واجهة أخرى) لـ RGP والتي تم الرد عليها خلال فترة الإبلاغ
19	srs-dom-transfer-approve	عدد طلبات "نقل" أسماء نطاقات SRS (أي EPP وأي واجهة أخرى) للموافقة على عمليات التحويل والتي تم الرد عليها خلال فترة الإبلاغ
20	srs-dom-transfer-cancel	عدد طلبات "نقل" أسماء نطاقات SRS (أي EPP وأي واجهة أخرى) لإلغاء عمليات التحويل والتي تم الرد عليها خلال فترة الإبلاغ
21	srs-dom-transfer-query	عدد طلبات "نقل" أسماء نطاقات SRS (أي EPP وأي واجهة أخرى) للاستعلام عن التحويل والتي تم الرد عليها خلال فترة الإبلاغ
22	srs-dom-transfer-reject	عدد طلبات "نقل" أسماء نطاقات SRS (أي EPP وأي واجهة أخرى) لرفض عمليات التحويل والتي تم الرد عليها خلال فترة الإبلاغ
23	srs-dom-transfer-request	عدد طلبات "نقل" أسماء نطاقات SRS (أي EPP وأي واجهة أخرى) لطلب عمليات التحويل والتي تم الرد عليها خلال فترة الإبلاغ
24	srs-dom-update	عدد طلبات "تحديث" أسماء نطاقات SRS (أي EPP وأي واجهة أخرى) (ولا يشمل ذلك طلبات استعادة RGP) والتي تم الرد عليها خلال فترة الإبلاغ
25	srs-host-check	عدد طلبات "فحص" مضيف SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
26	srs-host-create	عدد طلبات "إنشاء" مضيف SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
27	srs-host-delete	عدد طلبات "حذف" مضيف SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
28	srs-host-info	عدد طلبات "معلومات" مضيف SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
29	srs-host-update	عدد طلبات "تحديث" مضيف SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
30	srs-cont-check	عدد طلبات "فحص" جهة اتصال SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
31	srs-cont-create	عدد طلبات "إنشاء" جهة اتصال SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
32	srs-cont-delete	عدد طلبات "حذف" جهة اتصال SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
33	srs-cont-info	عدد طلبات "معلومات" جهة اتصال SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ
34	srs-cont-transfer-approve	عدد طلبات "نقل" جهة اتصال SRS (أي EPP وأي واجهة أخرى) للموافقة على عمليات التحويل والتي تم الرد عليها خلال فترة الإبلاغ
35	srs-cont-transfer-cancel	عدد طلبات "نقل" جهة اتصال SRS (أي EPP وأي واجهة أخرى) لإلغاء عمليات التحويل والتي تم الرد عليها خلال فترة الإبلاغ
36	srs-cont-transfer-query	عدد طلبات "نقل" جهة اتصال SRS (أي EPP وأي واجهة أخرى) للاستعلام عن التحويل والتي تم الرد عليها خلال فترة الإبلاغ
37	srs-cont-transfer-reject	عدد طلبات "نقل" جهة اتصال SRS (أي EPP وأي واجهة أخرى) لرفض عمليات التحويل والتي تم الرد عليها خلال فترة الإبلاغ
38	srs-cont-transfer-request	عدد طلبات "نقل" جهة اتصال SRS (أي EPP وأي واجهة أخرى) لطلب عمليات التحويل والتي تم الرد عليها خلال فترة الإبلاغ
39	srs-cont-update	عدد طلبات "تحديث" جهة اتصال SRS (أي EPP وأي واجهة أخرى) والتي تم الرد عليها خلال فترة الإبلاغ

يتضمن السطر الأول أسماء الحقول تماماً كما هو موضح في الجدول أعلاه بأنه "خط رئيسي" كما هو موضح في القسم 2 من RFC 4180. لا تصف خطوط أخرى الخط الموصوف أعلاه والذي يتعين إدراجه. وسوف تكون فواصل السطور <U+000D، U+000A> وفقًا لما هو محدد في RFC 4180.

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

4. خدمات نشر بيانات التسجيل

   1. خدمات دليل بيانات التسجيل. وإلى أن تتطلب ICANN بروتوكولاً مختلفًا، يلتزم مشغل السجل بإدارة خدمة نشر بيانات السجل المتوفرة عبر كل من المنفذ 43 وبما يتفق مع المعيار RFC 3912 وموقع الويب على العنوان <whois.nic.TLD> موفرة بذلك وصول عام مجاني مستند إلى الاستعلام للعناصر التالية على الأقل بالتنسيق التالي. تحتفظ ICANN الحق في تحديد الأشكال والبروتوكولات البديلة، وبناء على هذه المواصفات، فإن المسجل ينفذ مثل هذه المواصفات البديلة في أقرب وقت ممكن عمليا.

ينبغي تنفيذ مشغل السجل معيارًا جديدًا ليدعم عملية الدخول على بيانات تسجيل اسم النطاق (SAC 051) بعد ما لا يتجاوز مائة وخمسة وثلاثون (135) يومًا بعد ما تقوم ICANN بتقديم الطلب إذا: 1) ينتج IETF معيارًا (مثل، تم نشره، على الأقل، كمعيار مقترح RFC كما هو محدد في RFC 2026)؛ و2) تنفيذه معقول تجاريًا في محتوى الإجمالي لعملية المسجل.

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

2. ويكون تمثيل كل كائن البيانات كمجموعة من أزواج مفتاح/قيمة، مع الأسطر التي تبدأ مع مفاتيح، متبوعا بنقطتين ومساحة كمحددات، تليها قيمة.

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

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

بيانات اسم النطاق:

1. تنسيق الاستفسار: whois EXAMPLE.TLD

2. تنسيق الرد:

اسم النطاق: EXAMPLE.TLD
معرف النطاق: D1234567-TLD
خادم WHOIS: whois.example.tld
رابط URL للإحالة: xxxx://xxx.xxxxxxx.xxx
تاريخ التحديث: 2009-05-29T20:13:00Z
تاريخ الإنشاء: 2000-10-08T00:45:00Z
تاريخ انتهاء السجل: 2010-10-08T00:44:59Z
أمين السجل الراعي: EXAMPLE REGISTRAR LLC
معرف IANA لأمين السجل الراعي: 5555555
حالة النطاق: clientDeleteProhibited
حالة النطاق: clientRenewProhibited
حالة النطاق: clientTransferProhibited
حالة النطاق: serverUpdateProhibited
معرف المسجل: 5372808-ERL
اسم المسجل: EXAMPLE REGISTRANT
منظمة المسجل: EXAMPLE ORGANIZATION
شارع المسجل: 123 EXAMPLE STREET
مدينة المسجل: ANYTOWN
ولاية/مقاطعة المسجل: AP
الرمز البريدي للمسجل: A1A1A1
دولة المسجل: EX
هاتف المسجل: +1.5555551212
الهاتف الداخلي للمسجل: 1234
فاكس المسجل: +1.5555551213
الفاكس الداخلي للمسجل: 4321
البريد الإلكتروني للمسجل: XXXXX@XXXXXXX.XXX
معرف المدير: 5372809-ERL
اسم المدير: EXAMPLE REGISTRANT ADMINISTRATIVE
منظمة المدير: EXAMPLE REGISTRANT ORGANIZATION
شارع المدير: 000 XXXXXXX XXXXXX
مدينة المدير: ANYTOWN
ولاية/مقاطعة المدير: AP
الرمز البريدي للمدير: A1A1A1
بلد المدير: EX
هاتف المدير: +1.5555551212
الهاتف الداخلي للمدير: 1234
فاكس المدير: +1.5555551213
الفاكس الداخلي للمدير:
البريد الالكتروني للمدير: XXXXX@XXXXXXX.XXX
معرف الفني: 5372811-ERL
اسم الفني: EXAMPLE REGISTRAR TECHNICAL
منظمة الفني: EXAMPLE REGISTRAR LLC
شارع الفني: 123 EXAMPLE STREET
مدينة الفني: ANYTOWN
ولاية/مقاطعة الفني: AP
الرمز البريدي للفني: A1A1A1
بلد الفني: EX
هاتف الفني: +1.1235551234
الهاتف الداخلي للفني: 1234
فاكس الفني: +1.5555551213
الفاكس الداخلي للفني: 93
البريد الإلكتروني للفني: XXXXX@XXXXXXX.XXX
خادم الاسم: NS01.EXAMPLEREGISTRAR.TLD
خادم الاسم: NS02.EXAMPLEREGISTRAR.TLD
DNSSEC: signedDelegation
DNSSEC: unsigned
>>> آخر تحديث لقاعدة بيانات WHOIS: 2009-05-29T20:15:00Z

5. بيانات المسجل:

   1. تنسيق الاستعلام: whois "registrar Example Registrar، Inc."

   2. تنسيق الرد:

اسم المسجل: Example Registrar, Inc.
الشارع: 0000 Xxxxxxxxx Xxx
المدينة: Marina del Rey
الولاية/المقاطعة: CA
الرمز البريدي: 90292
البلد: US
رقم الهاتف: +1.3105551212
رقم الفاكس: +1.3105551213
البريد الإلكتروني: xxxxxxxxx@xxxxxxx.xxx
خادم WHOIS: whois.example-registrar.tld
رابط URL للإحالة: xxxx://xxx.xxxxxxx-xxxxxxxxx.xxx
جهة اتصال الإدارة: Joe Registrar
رقم الهاتف: +1.3105551213
رقم الفاكس: +1.3105551213
البريد الإلكتروني: xxxxxxxxxxxx@xxxxxxx-xxxxxxxxx.xxx
جهة اتصال المدير: Jaxx Xegistrar
رقم الهاتف: +1.3105551214
رقم الفاكس: +1.3105551213
البريد الإلكتروني: xxxxxxxxxxxxx@xxxxxxx-xxxxxxxxx.xxx
جهة اتصال الفني: Xxxx Geek
رقم الهاتف: +1.3105551215
رقم الفاكس: +1.3105551216
البريد الإلكتروني: xxxxxxxx@xxxxxxx-xxxxxxxxx.xxx
>>> آخر تحديث قاعدة بيانات WHOIS: 2009-05-29T20:15:00Z

6. بيانات ملقم الاسم:

   1. تنسيق الاستعلام: whois "NS1.EXAMPLE.TLD"،whois "nameserver (اسم خادم الاسم)"، أو "(عنوان whois "nameserver (IP
      
      
      

   2. تنسيق الرد:

اسم الخادم: NS1.EXAMPLE.TLD
عنوان IP: 192.0.2.123 عنوان IP: 2001:0DB8::1
أمين السجل: Example Registrar, Inc.
خادم WHOIS: whois.example-registrar.tld
عنوان URL للإحالة: xxxx://xxx.xxxxxxx-xxxxxxxxx.xxx
>>> آخر تحديث قاعدة بيانات WHOIS: 2009-05-29T20:15:00Z

7. تنسيق مجالات البيانات التالية: حالة النطاق، الأسماء الفردية والتنظيمية، عنوان، الشارع، المدينة، الولاية/المقاطعة، الرمز البريدي، والبلد، أرقام الهاتف والفاكس (سيتم توفير الامتداد كما هو موضح أعلاه) وعناوين البريد الإلكتروني وينبغي تأكيد البيانات والأوقات على الخرائط المحدد فيEPP RFC 5730-5734 لذلك عرض هذه المعلومات (أو القيم التي يتم إرجاعها في ردود WHOIS) يمكن معالجتها بشكل موحد وفهمها.

8. لكي يكون مطابقًا لواجهة ICANN الشائعة لـ WHOIS (InterNIC)، ينبغي أن يكون مخرج WHOIS في تنسيق النص المبين أعلاه.

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

   1. سيقدم مشغل السجل إمكانية البحث في خدمة الدليل المعتمدة على شبكة الإنترنت.

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

   3. سيقدم مشغل السجل إمكانيات التطابق الكامل، على الأقل في أحد الحقول التالية: معرف أمين السجل، اسم خادم الاسم وعناوين IP خادم الاسم (فقط ما يطبق على عناوين IP المخزنة من قبل السجل، على سبيل المثال سجلات الملصق).

   4. يوفر مشغل السجل إمكانيات بحث بولياني على الأقل المشغلات المنطقية التالية للانضمام إلى مجموعة من معايير البحث التالية: و، أو، أم لا.

   5. ستضمن نتائج البحث أسماء النطاق التي تتطابق مع معايير البحث.

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

10. ينبغي على مشغل السجل توفير رابط على الموقع الأساسي لـTLD (مثل، الموقع المقدم إلى ICANN للنشر في موقع ICANN) إلى صفحة شبكة الإنترنت المخصصة من قبل ICANN التي تحتوي سياسة WHOIS والمواد التعليمية.

1. الوصول لملفات المنطقة

   1. وصول الطرف الثالث

      1. اتفاقية الوصول لملف المنطقة. سيدخل مشغل السجل في اتفاقية مع أي مستخدم للإنترنت الأمر الذي سيتيح للمستخدم الوصول إلى ملقم إنترنت مضيف أو ملقمات مصممة خصيصا بواسطة مشغل السجل وتنزيل بيانات ملف المنطقة. سيتم توحيد الاتفاقية وتيسيرها وإدارتها من قبل موفر دخول بيانات المنطقة المركزية، التي قد تكون ICANN أو من ينوب عنها (مقدم CZDA). سيوفر مشغل السجل (بشكل اختياري من خلال مقدم CZDA) الدخول إلى بيانات ملف المنطقة لكل قسم 2.1.3 من هذه المواصفات، والقيام بذلك من خلال استخدام تنسيق الملف الموصوف في قسم 2.1.4 من هذه المواصفات. مع عدم الإخلال بما سبق، (أ) يجوز لمقدم CZDA رفض طلب الدخول على أي مستخدم لا يلبي طلبات الاعتماد في قسم 2.1.2 أدناه؛ (ب) قد يرفض مشغل السجل طلب الدخول إلى أي مستخدم لا يوفر اعتمادات صحيحة أو شرعية بموجب القسم 2.1.2 أدناه أو في المكان الذي ستخالف فيه المعتقدات المعقولة لمشغل السجل شروط قسم 2.1.5 الموضحة أدناه، و (ج) قد يلغي مشغل السجل الدخول إلى أي مستخدم إذا كان لدى مشغل السجل دليل لدعم أن هذا المستخدم قد انتهك شروط قسم 2.1.5 الموضحة أدناه.

      2. متطلبات الاعتماد. سيطلب مشغل السجل، من خلال تسهيل مقدم CZDA، من كل مستخدم تزويده بمعلومات كافية لتحديد المستخدم بشكل صحيح وموقعه. وسوف تشمل معلومات المستخدم هذه، دون حصر، اسم الشركة، اسم الاتصال والعنوان ورقم الهاتف والفاكس وعنوان البريد الإلكتروني وعنوان بروتوكول الإنترنت.

      3. منح حق الوصول. كل مشغل سجل (بشكل اختياري من خلال مقدم CZDA) سيوفر ملف المنطقة FTP (أو غيرهم من السجلات المقدمة) خدمة لـURL الخاص بـ ICANN وإدارته (على وجه الخصوص، <TLD>.xxx.xxxxx.xxx حيث <TLD>هي TLD المسؤول عنها السجل) خاص بالمستخدم للوصول إلى أرشيفات بيانات منطقة السجل. يمنح مشغل السجل للمستخدم حق وصول محدود وغير مباشر وغير قابل للنقل لملقم مشغل السجل ولنقل نسخة من ملفات مناطق نطاقات المستوى الأعلى (أي خوادم اختيارية لمقدم CZDA) وأي ملفات اختباريه مشفرة مقترنة خاصة بها وليس بأكثر من 1 لكل مدة 24 ساعة باستخدام FTP أو غيرها من بروتوكولات النقل الأخرى التي قد تحددها ICANN. لكل خادم للوصول إلى ملف المنطقة، ملفات المنطقة في دليل المستوى الأعلى تسمى <zone> .zone.gz، مع <zone> .zone.gz.md5 و<zone> .zone.gz.sig للتحقق من التنزيلات. إذا كان مشغل السجل (أو مقدم CZDA) يوفر البيانات التاريخية، فإنه يستخدم نمط تسمية <tld>-yyyymmdd.zone.gz، وما إلى ذلك.

      4. معايير تنسيق الملفات. سيوفر مشغل السجل (بشكل اختياري من خلال مقدم CZDA) ملفات المنطقة باستخدام تنسيق فرعي لتنسيق الملف الأساسي القياسي كما هو محدد في RFC 1035، قسم 5، بما في ذلك جميع السجلات الموجودة في المنطقة الفعلية المستخدمة في DNS العامة. التنسيق الفرعي على النحو التالي:

         1. يجب أن يتضمن كل سجل جميع الحقول في سطر واحد على النحو التالي: <domain-name> <TTL> <class> <type> <RDATA>.

         2. يجب أن تستخدم الفئة والنوع الاستذكار القياسي ويجب أن يكون في الحالة العليا.

         3. TTL يجب أن يمثل عدد عشري صحيح.

         4. يُسمح باستخدام /X و/DDD داخل أسماء النطاق المسموح به.

         5. ويجب أن تكون جميع أسماء النطاق في حالة عليا.

         6. يجب استخدام تبويب واحد كفاصل للحقول داخل السجل.

         7. يجب أن تكون جميع أسماء المجال مؤهلة بالكامل.

         8. لا توجد توجيهات للمنشأ.

         9. لا يوجد استخدام للعلامة "@" للدلالة على الأصل الحالي.

         10. لا يوجد استخدام "لأسماء النطاقات الفارغة" في بداية السجل للاستمرار في استخدام اسم المجال في السجل السابق.

         11. لا توجد توجيهات مضمنة.

         12. لا توجد توجيهات TTL.

         13. لا يوجد استخدام للأقواس، على سبيل المثال، الاستمرار في قائمة الحقول في سجل عبر خط الحدود.

         14. لا فائدة من التعليقات.

         15. لا أسطر فارغة.

         16. سجل SOA واحد ينبغي تقديمه في أعلى (مضاعف) ملف المنطقة ونهايته.

         17. مع استثناء سجل SOA، يجب أن تكون جميع السجلات في ملف مرتبة حسب الترتيب الأبجدي.

         18. منطقة واحدة لكل ملف. في حالة تقسيم TLD لبيانات DNS في مناطق متعددة، بعضها يذهب إلى ملف منفصل اسمه على النحو الوارد أعلاه، مع كل الملفات المجمعة باستخدام tar مجتمعة في ملف يسمى <tld> zone.tar.

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

      6. شرط الاستخدام. سيوفر مشغل السجل، من خلال CZDA، لكل مستخدم الوصول إلى ملف المنطقة لفترة من الوقت لا تقل عن 3 (ثلاثة) أشهر. سيسمح مشغل السجل للمستخدم بتجديد منح وصولهم.

      7. لا توجد رسوم على الوصول. سيوفر مشغل السجل، وسييسر مقدم CZDA، عملية الوصول لملف المنطقة للمستخدم دون مقابل.

   2. التعاون

      1. المساعدة. يتعاون مشغل السجل ويوفر المساعدة المعقولة إلى ICANN وموفر CZDA لتسهيل الوصول الفعال لبيانات ملف المنطقة من خلال المستخدمين المسموح لهم على النحو المتوقع بموجب هذا الجدول.

   3. وصول ICANN. يقدم مشغل السجل الوصول الكبير إلى ملفات المنطقة من أجل TLD إلى ICANN أو من يعينه على أساس مستمر بطريقة معقولة يتسنى لـ ICANN من خلالها التحديد من وقت لآخر. ستتوفر عملية الوصول يوميًا. ستشمل ملفات المنطقة بيانات SRS التي تم الالتزام بها في اقرب وقت ممكن لـ 00:00:00 UTC.

   4. الوصول لمشغل الطوارئ. يقدم مشغل السجل وصولاً تجميعيًا إلى ملفات المنطقة من أجل TLD إلى مشغلي الطوارئ المعينين من قبل ICANN على أساس مستمر بطريقة معقولة يتسنى لـ ICANN من خلالها التحديد من وقت لآخر.

2. وصول بيانات التسجيل الكبيرة إلى ICANN

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

      1. المحتويات. يوفر مشغل السجل على الأقل، البيانات التالية لكافة أسماء النطاقات المسجلة: اسم النطاق ومعرف كائن المستودع (roid) ومعرف أمين السجل (IANA ID) والحالات وآخر بيانات محدثة وتاريخ الإنشاء وتاريخ انتهاء الصلاحية وأسماء ملقم الاسم. بالنسبة لأمناء السجلات الرعاة، يوفر على الأقل ما يلي: اسم أمين السجل ومعرف كائن مستودع أمين السجل (roid) وأسماء المضيفين لملقم Whois أمين السجل وURL لأمين السجل.

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

      3. الوصول. سيكون لدى مشغل السجل ملف (ملفات) متوفرة للتنزيل اعتبارًا من 00:00:00 UTC في اليوم المخصص للإحالة من قبل ICANN. سيتوفر الملف (الملفات) للتنزيل من قبل SFTP على الرغم أن ICANN فد تطلب وسائل أخرى في المستقبل.

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

1. جدول الأسماء المحجوزة

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

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

2. عناوين من حرفين. يتم حظر جميع مسميات ASCII المكونة من حرفين عن التسجيل أو تخصيصها إلى مشغل السجل في المستوى الثاني داخل نطاق TLD. ولا يجوز تنشيط هذه التسميات في نظام DNS، ولا يجوز إطلاقها للتسجيل لأي شخص أو كيان بخلاف مشغل السجل، شريطة جواز إطلاق هذه السلاسل للتسميات المكونة من حرفين إلى الحد الذي يتوصل فيه مشغل السجل من التوصل إلى اتفاق مع الحكومة المعنية ومدير رمز الدولة للسلسلة وفقًا لما هو محدد في المعيار ISO 3166-1 alpha-2. يجوز لمشغل السجل أيضًا اقتراح إطلاق هذه الحجوزات استنادا إلى تنفيذ الإجراءات وذلك لتجنب حدوث ارتباك مع رموز البلد المتطابقة، مع مراعاة الحصول على الموافقة من ICANN. عند الانتهاء من تعيين مشغل السجل باعتباره مشغلاً للسجل الخاص بنطاق TLD، ينبغي نقل جميع هذه المعرفات التي تظل ممنوعة من التسجيل أو تخصيصها لمشغل السجل بما يتفق مع تعليمات ICANN. يجوز لمشغل السجل تخصيص هذه الأسماء ذاتيًا وتجديده دون استخدام أمين سجل معتمد من ICANN، وهو ما لن يعد معاملات لأغرض البند 6.1 من هذه الاتفاقية.

3. الحجوزات الخاصة بعمليات السجل.

   1. يجب حظر مسميات ASCII التالية من التسجيل أو التخصيص على مشغل سجل في كافة المستويات للاستخدام فيما يتصل بتشغيل السجل لنطاق TLD: WWW وRDDS وWHOIS. يجب تخصيص تسمية ASCII التالية على مشغل سجل في كافة المستويات للاستخدام فيما يتصل بتشغيل السجل لنطاق TLD: NIC. يجوز لمشغل السجل تنشيط WWW، وRDDS، وWHOIS في نظام DNS، ولكن يجب تنشيط NIC في نظام DNS، حسب الضروري لتشغيل نطاق TLD. ولا يجوز إطلاق أي من WWW، أو RDDS، أو WHOIS أو NIC أو تسجيلها لأي شخص (بخلاف مشغل السجل) أو جهة أخرى. عند الانتهاء من تعيين مشغل السجل باعتباره مشغلاً للسجل الخاص بنطاق TLD، ينبغي نقل جميع هذه الأسماء المحمية أو المخصصة بما يتفق مع تعليمات ICANN. يجوز لمشغل السجل تخصيص هذه الأسماء ذاتيًا وتجديده دون استخدام أمين سجل معتمد من ICANN، وهو ما لن يعد معاملات لأغرض البند 6.1 من هذه الاتفاقية.

   2. ويجوز لمشغل السجل التنشيط في نظام DNS وفي جميع المستويات ما يصل إلى مائة (100) اسم (بالإضافة إلى متغيرات IDN الخاصة بها، متى انطبق ذلك) واللازمة لتشغيل أو تعزيز نطاق TLD. يجب أن يتصرف مشغل السجل بصفته حامل الاسم المسجل لهذه الأسماء حيث إن هذا اللفظ محدد في اتفاقية اعتماد أمين السجل (RAA) الحالية في ذلك الوقت لـ ICANN. وتعتبر عمليات التنشيط هذه بمثابة معاملات لأغراض البند 6.1 من هذه الاتفاقية. يجب على مشغل السجل إما (1) تسجيل هذه الأسماء من خلال أمين سجل معتمد من ICANN، أو (2) التخصيص الذاتي لهذه الأسماء وفيما يتعلق بهذه الأسماء أن يقدم إلى ICANN وتحمل المسئولية أمامها عن التوافق مع سياسات الإجماع الخاصة بـ ICANN والالتزامات المنصوص عليها في البنود الفرعية 3.7.7.1 إلى 3.7.7.12 من اتفاقية RAA السارية في ذلك الحين (أو أي فقرة أخرى بديلة عنها تنص على الأحكام الخاصة باتفاقية التسجيل بين أمين سجل وحامل اسم مسجل). ووفقًا لتقدير مشغل السجل وبما يتفق مع كافة الأحكام المنصوص عليها في هذه الاتفاقية، يجوز إطلاق هذه الأسماء للتسجيل لشخص أو كيان آخر.

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

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

   1. الاختصار (باللغة الإنجليزية) لكافة أسماء البلدان والمقاطعات الواردة في قائمة ISO 3166-1 list، وتعديلات ذلك من حين إلى آخر، بما في ذلك الاتحاد الأوروبي، وهي المحجوزة بشكل استثنائي على قائمة
      ISO 3166-1 ، ونطاقها الممتد في أغسطس 1999 على أي طلب يحتاج إلى تمثل اسم الاتحاد الأوروبي <xxxx://xxx.xxx.xxx/xxx/xxxxxxx/xxxxxxx_xxxxx/xxx_0000_xxxx_xxxxx/xxx-0000-0_xxxxxxxx_xxxxx.xxx>؛

   2. مجموعة الخبراء التابعين للأمم المتحدة فيما يتعلق بالأسماء الجغرافية ودليل المرجع التقني لمقاييس الأسماء الجغرافية وأسماء الجزء الثالث من بلدان العالم؛ و

   3. تم إعداد قائمة بالدول الأعضاء في الأمم المتحدة باللغات الرسمية الست للأمم المتحدة من جانب مجموعة العمل حول أسماء الدول لمؤتمر الأمم المتحدة حول مقاييس الأسماء الجغرافية؛

شريطة، أن حجز أسماء خاصة للبلدان والمقاطعات (بما في ذلك متغيرات IDN بما يتفق مع سياسة تسجيل IDN الخاصة بمُشغل السجل، متى ما كان منطبقَا) يجوز إطلاقها إلى حد وصول مشغل السجل لاتفاق مع الحكومة (الحكومات) المعنية. لا يجب على مشغل السجل تنشيط هذه الأسماء في نظام DNS، شريطة أنه يجوز لمشغل السجل اقتراح إطلاق هذه الحجوزات، مع مراعاة المراجعة من جانب اللجنة الاستشارية الحكومية لـ ICANN والحصول على الموافقة من ICANN. عند الانتهاء من تعيين مشغل السجل باعتباره مشغلاً للسجل الخاص بنطاق TLD، ينبغي نقل جميع هذه الأسماء التي تظل ممنوعة من التسجيل أو تخصيصها لمشغل السجل بما يتفق مع تعليمات ICANN. يجوز لمشغل السجل تخصيص هذه الأسماء ذاتيًا وتجديده دون استخدام أمين سجل معتمد من ICANN، وهو ما لن يعد معاملات لأغرض البند 6.1 من هذه الاتفاقية.

5. اللجنة الأوليمبية الدولية، وحركة الصليب الأحمر والهلال الأحمر. وفقًا للتعليمات التي ترد من ICANN من حين إلى آخر، فإن الأسماء (بما في ذلك متغيرات IDN الخاصة بها، أينما كان مناسبًا) المتعلق باللجنة الأوليمبية الدولية، وحركة الصليب الأحمر الهلال الأحمر المدرجة على xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxxxx سوف تحظر من عملية التسجيل أو تخصيصها على مشغل سجل في المستوى الثاني داخل نطاق TLD. يجوز إضافة الأسماء الإضافية لكل من اللجنة الأوليمبية الدولية وحركة الصليب الأحمر والهلال الأحمر (بما في ذلك متغيرات IDN) إلى القائمة بموجب إشعار مدته عشرة (10) أيام تقويمية من ICANN إلى مشغل السجل. ويجوز تفعيل هذه الأسماء في نظام DNS، ولا يجوز تحريرها للتسجيل لأي شخص أو جهة خلاف مشغل السجل. عند الانتهاء من تعيين مشغل السجل باعتباره مشغلاً للسجل الخاص بنطاق TLD، ينبغي نقل جميع هذه الأسماء الممنوعة من التسجيل أو تخصيصها لمشغل السجل بما يتفق مع تعليمات ICANN. يجوز لمشغل السجل تخصيص هذه الأسماء ذاتيًا وتجديده دون استخدام أمين سجل معتمد من ICANN، وهو ما لن يعد معاملات لأغرض البند 6.1 من هذه الاتفاقية.

6. المنظمات الحكومية الدولية. بحسب التعليمات التي تصدر بين الحين والآخر من قِبل ICANN، ينبغي لمشغل السجل تنفيذ آلية الحماية المحددة من قِبل مجلس إدارة ICANN المرتبطة بحماية المعرفات للمنظمات متداخلة الحكومات. وتتوفر قائمة بالأسماء المحجوزة لهذا البند 6 على xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxxxx. يجوز إضافة الأسماء الإضافية (بما في ذلك متغيرات IDN) إلى القائمة بموجب إشعار مدته عشرة (10) أيام تقويمية من ICANN إلى مشغل السجل. يجب عدم تفعيل أي من هذه المعرفات المحمية للمنظمات الحكومية الدولية في DNS، ويجب عدم تحريرها للتسجيل لأي شخص أو جهة خلاف مشغل السجل. عند الانتهاء من تعيين مشغل السجل باعتباره مشغل السجل لـ TLD، ينبغي نقل جميع مثل هذه المعرفات المحمية بحسب تعليمات ICANN. يجوز لمشغل السجل تخصيص هذه الأسماء ذاتيًا وتجديده دون استخدام أمين سجل معتمد من ICANN، وهو ما لن يعد معاملات لأغرض البند 6.1 من هذه الاتفاقية.

6. التشغيل التوافقي للسجل ومواصفات الاستمرارية

   1. التوافق مع المعايير

      1. DNS. يلتزم مشعل السجل ويخضع لالتزامات RFC الحالية وتلك التي تنشر مستقبلاً من قبل قوة مهام هندسة الإنترنت (IETF) بما في ذلك كل المعايير والتعديلات والإضافات اللاحقة المتعلقة بكل من DNS وعمليات خادم الأسماء ومنها على سبيل المثال لا الحصر التزامات RFC رقم 1034، و1035، و1123، و1982، و2181، و2182، و2671، و3226، و3596، و3597، و4343، و5966. يجوز أن تتضمن تسميات DNS فقط على شرطات بالموضع الثالث والرابع إذا كانت تمثل أسماء نطاق IDN صالحة (وفقا لما هو محدد أعلاه) في تشفير ASCII الخاص بها (على سبيل المثال، "xn--ndk061n").

      2. EPP. يلتزم مشغل السجل ويخضع لالتزامات RFC الحالية وتلك التي تنشر مستقبلاً من قبل قوة مهام هندسة الإنترنت (IETF) بما في ذلك كل المعايير والتعديلات والإضافات اللاحقة المتعلقة بكل من توفير وإدارة أسماء النطاقات باستخدام بروتوكول التوفير الممتد (EPP) بما يتفق مع التزامات RFC رقم 5910، و5730، و5731، و5732 (في حالة استخدام أدوات المضيف)، 5733 و5734. إذا قام مُشغل السجل بتنفيذ فترة مهلة سجل (RGP)، فيلتزم بما جاء في معيار RFC 3915 وما يأتي بعده. إذا احتاج مشغل السجل إلى استخدام الوظيفة خارج التزامات RFC الأساسية لـ EPP، فيتعين على مشغل السجل توثيق امتدادات EPP في تنسيق مسودة إنترنت متبعًا الإرشادات التوجيهية الواردة في RFC 3735. ويلتزم مشغل السجل بتوفير وتحديث المستندات ذات الصلة لكافة عناصر وامتدادات EPP المدعومة إلى ICANN قبل النشر.

      3. DNSSEC. على مشغل السجل التوقيع على ملفات منطقة TLD الخاصة به لتنفيذ تقنية امتدادات أمان نظام اسم النطاق ("DNSSEC"). وخلال الفترة الزمنية لسريان الاتفاقية، يخضع مشغل السجل لكل من RFC رقم 4033، و4034، و4035، و4509 وما يأتي بعدها، واتباع أفضل الممارسات الموضحة في RFC رقم 4641 وما يأتي بعدها. إذا قام مُشغل السجل بتنفيذ رفض التواجد المعتمد المبعثر لتقنية امتدادات أمان DNS، فعليه التوافق مع RFC 5155 وما بعده. يتعين على مشغل السجل قبول مواد المفتاح العام من أسماء النطاقات الفرعية بطريقة آمنة حسب أفضل الممارسات المتبعة في هذا المجال. كما ينشر السجل أيضًا على موقع الويب الخاص به بيانات ممارسات DNSSEC (أو DPS) ليصف عناصر وإجراءات الأمان الحيوية للتخزين المادي الأساسية، والوصول واستخدام المفاتيح الخاصة به وتأمين قبول مواد المفتاح العام للمسجلين. ويلتزم مشغل السجل بنشر DPS الخاصة به متبعًا التنسيق المشار إليه في RFC 6841.

      4. IDN. إذا كان المسجل يقدم أسماء النطاقات الدولية ("IDN")، فيلتزم بمراعاة كل من RFC رقم 5890، و5891، و5892، 5893 وما يأتي بعدها. ويلتزم مشغل السجل بإرشادات ICANN التوجيهية حول IDN على <xxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxx/xxxxxxxxxxxxxx-xxxxxxxxxx.xxx>، حسب ما يتم تعديله أو تنقيحه أو إلغاؤه من حين إلى آخر. لا بد أن يقوم مشغل السجل بنشر وتحديث جداول IDN وقواعد تسجيل IDN الخاصة به في مستودع IANA لممارسات IDN كما هو محدد في توجيهات ICANN بشأن IDN.

      5. IPv6. لا بد أن يتمكن مشغل السجل من قبول عناوين IPv6 كسجلات مرفقة في نظام سجلاته ونشرها في DNS. لا بد أن يعرض مشغل السجل نقل IPv6 العام على الأقل لاثنين من خوادم أسماء السجلات الواردة في منطقة الجذر فيما يتعلق بعناوين IPv6 المسجلة مع IANA. يجب على مشغل السجل اتباع "تعليمات DNS التشغيلية لنقل IPv6" كما هو موضح في BCP 91 والتوصيات والاعتبارات المشار إليها في RFC 4472. يقوم مشغل السجل بعرض نقل IPv6 عام بخصوص خدمات نشر بيانات التسجيل كما هو معرف في المواصفة 4 من هذه الاتفاقية؛ مثل Whois لـ (RFC 3912)، خدمة Whois القائمة على الويب. ولا بد أن يعرض مشغل السجل نقل IPv6 العام لنظام التسجيل المشترك (SRS) إلى أي مسجل، في فترة لا تزيد عن ستة (6) أشهر بعد استلام أول طلب كتابة كم مسجل معتمد من gTLD يرغب في العمل على SRS على Pv6.

   2. خدمات السجل

      1. خدمات السجل. يتم تعريف "خدمات السجل" ضمن سياق اتفاقية السجل هذه، كالآتي: (أ) تلك الخدمات التي تعتبر عمليات للسجل بالغة الأهمية للمهام التالية: استلام البيانات من المسجلين والخاصة بتسجيلات أسماء النطاقات وخوادم الأسماء؛ تزويد المسجلين بمعلومات الحالة المعنية بخوادم منطقة TLD؛ نشر ملفات منطقة TLD؛ تشغيل خوادم DND الخاصة بالسجل؛ ونشر معلومات الاتصال وغيرها من المعلومات الخاصة بتسجيلات خادم اسم النطاق في TLD كما تتطلبه هذه الاتفاقية؛ (ب) المنتجات أو الخدمات الأخرى والتي يطالب مشغل السجل بتقديمها بسبب وجود سياسة الإجماع المعرفة في المواصفات 1؛ (ج) أي منتجات أو خدمات أخرى فقط يستطيع مشغل السجل تقديمها، نتيجة لوضعه كمشغل سجل؛ و(د) التغييرات المادية على أي خدمة سجل ضمن نطاق (أ) أو (ب) أو (ج) أعلاه.

      2. حظر أحرف البدل. بالنسبة لأسماء النطاقات التي لم يتم تسجيلها، أو لم يقدم المسجل سجلات سليمة بشأنها مثل سجلات NS أو ليتضمنها ملف منطقة DND، أو إن كانت حالتهم لا تسمح لهم بنشرهم في DNS، فإنه يحظر استخدام سجلات الموارد العشوائية كما سبق وصفه في RFC رقم 1034 و4592 أو أي وسيلة أو تقنية لموالفة سجلات موارد DNS أو استخدام إعادة التوجيه ضمن DNS من قبل السجل. عند إرسال استعلام بشأن أسماء النطاقات هذه، لا بد أن ترجع خوادم الأسماء المصرح بها الاستجابة "Name Error" (والتي تعرف أيضًا بـ NXDOMAIN) ،RCODE 3 كما تم وصفه في RFC 1035 وأرقام RFC ذات الصلة. تنطبق تلك البنود على كل ملفات منطقة DNS على كافة المستويات في هيكل DNS الذي يحتفظ مشغل السجل (أو أي جهة تابعة تعمل في خدمات التسجيل) ببياناته ويرتب لصيانتها، أو توليد العوائد من عمليات الصيانة.

   3. استمرارية السجل

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

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

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

   4. تخفيف xxxxxxxx

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

      2. الاستخدام الضار لسجلات الملصق المعزولة. يلتزم مشغل السجل باتخاذ إجراء للتخلص من سجلات الملصق المعزولة (وفقًا لما هو محدد على xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/­security/sac048.pdf) عند التزويد بأدلة في شكل مكتوب على أن هذه السجلات موجودة فيما يتعلق بالسلوك الخبيث.

   5. فترات التسجيل الأولية والخاصة بالتجديد المدعومة

      1. فترات التسجيل الأولية. يجوز القيام بتسجيل أسماء مسجلة في السجل بزيادات مرة كل عام واحد (1)، حتى عشر (10) سنوات كحد أقصى. لتجنب حدوث أي شك، لا يجوز زيادة عمليات التسجيل الأولية عن عشرة (10) أعوام.

      2. فترات التجديد. يجوز القيام بتجديد الأسماء المسجلة بزيادات مرة (1) كل عام، حتى عشر (10) سنوات كحد أقصى. لتجنب حدوث أي شك، لا يجوز زيادة عمليات تجديد الأسماء المسجل لفترة التسجيل عن عشرة (10) أعوام اعتبارًا من وقت التجديد.

   6. إدارة حالات تصادم الأسماء

      1. فترة عدم التنشيط. لا يجوز لمشغل السجل تنشيط أي من الأسماء في منطقة DNS لنطاق TLD الخاص بالسجل (باستثناء ما يكون لـ "NIC") حتى انقضاء 120 يوم تقويمي على أقل تقدير بعد تاريخ سريان هذه الاتفاقية. يجوز لمشغل السجل تخصيص أسماء (مع مراعاة البند الفرعي 6.2 أدناه) أثناء هذه الفترة فقط إذا أطلع مشغل السجل السجلين بوضوح على عدم القدرة على تنشيط الأسماء حتى انتهاء فترة عدم التنشيط.

      2. تقييم حالات تصادم الأسماء

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

         2. مع عدم الإخلال بأحكام البند الفرعي 6.2.1، يجوز لمشغل السجل متابعة عملية تنشيط الأسماء في منطقة DNS دون تنفيذ التدابير المشار إليها في البند 6.2.1 فقط إذا (أ) قررت ICANN أن نطاقات TLD للسجل مؤهل لهذا المسار البديل لتنشيط الأسماء، و(ب) يحظر مشغل السجل كافة أسماء النطاقات من المستوى الثاني المحدد بمعرفة ICANN والمنصوص عليها في <xxxx://xxxxxxxx.xxxxx.xxx/xx/xxxxxxxxxxxxx-xxx-xxxxx/xxxxxxxxxxxx-0-00xxx00-xx> حيث قد يتم تعديل هذه القائمة بمعرفة ICANN من حين إلى آخر. ويجوز لمشغل السجل تنشيط الأسماء بموجب هذا البند الفرعي وبعد ذلك تنشيط الأسماء بما يتفق مع البند الفرعي 6.2.1.

         3. مجموعات الأسماء الخاضعة للتخفيف أو الحجب بموجب الأقسام 6.2.1 و6.2.2 سوف تكون مستندة على تحليل ICANN لمعلومات DNS بما في ذلك بيانات "يوم في حياة الإنترنت" التي يقدمها مركز عمليات وتحليل وأبحاث DNS والمعروف باسم (DNS-OARC) على <xxxxx://xxx.xxx-xxxx.xxx/xxxx/xxxx/xxxx>.

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

         5. وإذا قررت ICANN بأن نطاق TLD غير مؤهل للمسار البديل لتنشيط الأسماء، فيجوز لـ ICANN اختيار عدم تفويض نطاق TLD الذي ينتظر إجمال التقييم النهائي لحوادث تضارب الأسماء لنطاق TLD، وإكمال مشغل السجل لكافة تدابير التخفيف اللازمة. يفهم مشغل السجل أن تدابير التخفيف التي تشترطها ICANN كشرط لتنشيط الأسماء في منطقة DNS لنطاق TLD قد تشتمل، على سبيل المثال لا الحصر، تدابير التخفيف مثل التدابير المشار إليها في البند 3.2 من خطة إدارة حوادث تضارب أسماء نطاقات gTLD الجديدة التي اعتمدتها لجنة برنامج gTLD الجديدة التابعة لـ ICANN أو (NGPC) في 7 أكتوبر 2013 كما هو منشور على <xxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxxxx/xxxxxxxxx/xxxxxxxxxxx-xxx-xxxx-xxxxx-0-00xxx00-xx.xxx>.

      3. تناول تقارير تضارب الأسماء

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

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

7. الحد الأدنى لمتطلبات آليات حماية الحقوق

   1. آليات حماية الحقوق. ينفذ مشغل السجل ويلتزم بآليات حماية للحقوق ("RPM") المنصوص عليها في هذه المواصفة. وبالإضافة إلى تلك الآليات، يجوز لمشغل السجل تطوير وتطبيق آليات إضافية لحماية الحقوق تعيق أو تمنع تسجيل أسماء النطاقات التي تنتهك أو تسيء استخدام الحقوق القانونية لطرف آخر. يضمّن مشغل السجل كافة آليات RPM اللازمة بموجب المواصفة 7 وأية آليات RPM إضافية يتم تطويرها وتنفيذه من خلال مشغل السجل في اتفاقية السجل-أمين السجل التي تم إبرامها من خلال أمناء السجلات المعتمدين من ICANN والمرخصين لتسجيل الأسماء في نطاق TLD. ويلتزم مشغل السجل بالتنفيذ بما يتفق مع المتطلبات المنصوص عليها هنا لكل آليات RPM الإلزامية المنصوص عليها في دار مقاصة العلامات التجارية اعتبارًا من تاريخ هذه الاتفاقية، ووفقًا لما هو منشور على xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxx-xxxxxxxxxxxx ("متطلبات دار مقاصة العلامات التجارية")، والتي يجوز مراجعتها في الجوانب غير المادية بمعرفة ICANN من حين إلى آخر. ولا يجوز لمشغل السجل تفويض أي مالك لحقوق الملكية الفكرية المنطبقة باستخدام أي من مجموعات معلومات العلامات التجارية، أو الإشعارات أو خدمة التوثيق بالإضافة إلى أو بدلاً من دار مقاصة العلامات التجارية المعينة من ICANN. وإذا كان هناك تضارب بين الأحكام والشروط المنصوص عليها في هذه الاتفاقية ومتطلبات دار مقاصة العلامات التجارية، يتم الأخذ والعمل بالأحكام والشروط المنصوص عليها في هذه الاتفاقية.

   2. آليات فض المنازعات. يلتزم مشغل السجل بالآليات التالية لفض المنازعات حيث قد تتم مراجعتها من حين إلى آخر:

1. إجراء حل نزاع ما بعد التفويض للعلامات التجارية (PDDRP) والإجراءات المقترحة لحل نزاعات قيود التسجيل (RRDRP) التي اعتمدتها ICANN (والمنشورة على xxxx://xxx.xxxxx.xxx/xx/­resources/registries/pddrp و xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/­rrdrp، على التوالي). يوافق مشغل السجل على تنفيذ والالتزام بأية تعويضات تفرضها ICANN (والتي قد تشتمل على أي من التعويضات المعقولة، بما في ذلك لتجنب حدوث أي شك، إنهاء اتفاقية السجل بموجب البند 4.3(هـ) من الاتفاقية) بعد قرار من هيئة PDDRP أو RRDRP مع الإقرار بالالتزام بهذه القرار

2. ونظام التعليق السريع الموحد ("URS") الذي اعتمدته ICANN (والمنشور على xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxx)، ويشمل ذلك تنفيذ القرارات الصادرة من خلال مراجعي URS.

8. أداة العمليات المستمرة

   1. تنص أداة العمليات المستمرة (أ) على موارد مالية كافية لضمان استمرار التشغيل لوظائف التسجيل الأساسية المتصلة بـ TLD والمنصوص عليها في البند 6 من المواصفة 10 في هذه الاتفاقية لمدة ثلاثة (3) سنوات بعد أي إنهاء لهذه الاتفاقية في أو قبل مرور خمسة أعوام اعتبارًا من تاريخ السريان ولمدة عام واحد (1) فقط ولكن قبل أو في موعد مرور ستة (6) أعوام من تاريخ السريان، و(ب) أن تكون في صورة (1) خطاب اعتماد جاهز وغير قابل للرجوع فيه، أو (2) إيداع نقدي غير قابل للرجوع فيه، على أن يفي كل منهما بالمتطلبات المنصوص عليها في البند 50(ب) من المرفق بالوحدة 2 - أسئلة ومعايير التقييم - في دليل مقدمي طلبات gTLD، وفقًا لم هو منصوص ومستكمل بمعرفة ICANN قبل تاريخ هذه الاتفاقية (والمضمن بموجب ذلك بالإشارة إليه في هذه المواصفة 8). يبذل مشغل السجل قصارى جهده لاتخاذ جميع الإجراءات اللازمة للحفاظ على استمرار أداة العمليات المستمرة لمدة ست (6) سنوات اعتبارا من تاريخ نفاذه، والحفاظ على ICANN بوصفها الطرف الثالث المستفيد منه. وإذا اختار مشغل السجل الحصول على خطاب اعتماد قائم وغير قابل للرجوع فيه ولم يكن من الممكن تحقيق البند أعلاه، فيجوز لمشغل السجل الحصول على خطاب اعتماد بمدة عام واحد و"ومركز أخضر" ينص على التمديدات السنوية، وبدون تعديل، ولعدد غير محدد من الفترات الإضافية إلى أن يقوم البنك المصدر بإشعار ICANN بالانتهاء الأخير أو إلى أن تحرر ICANN خطاب الاعتماد وفقًا لما يثبت خطيًا، وإذا كان خطاب الاعتماد يستوفي المتطلبات المنصوص ليه في البند 50(ب) من المرفق بالوحدة 2 - أسئلة ومعايير التقييم - في دليل مقدمي طلبات gTLD، وفقًا لما نشرته ووفرته ICANN قبل تاريخ هذه الاتفاقية، شريطة أنه إلى قام البنك المصدر بإشعار ICANN بانتهاء خطاب الاعتماد المذكور قبل مرور ستة (6) أعوام اعتبارًا من تاريخ السريان، يجب أن ينص هذا الخطاب الخاص بالائتمان على أحقية ICANN في سحب الأموال المضمونة بموجب خطاب الاعتماد قبل هذا الانتهاء. ويجب أن يشترط خطاب الاعتماد من البنك المصدر تقديم إشعار إلى ICANN مدته ثلاثون (30) يومًا تقويميًا على أقل تقديم بأي من هذا الانتهاء أو عدم التجديد. وفي حالة انتهاء صلاحية خطاب الاعتماد أو إنهاء في أي وقت قبل مرور ست (6) سنوات من تاريخ السريان، فيتعين على مشغل السجل الحصول على مستند عمليات متواصلة بديل. ويجوز لـ ICANN سحب الأموال بموجب خطاب الاعتماد الأصلي، إذا لم يتم العمل بمستند عمليات متواصلة بديل قبل انتهاء خطاب الاعتماد الأصلي. على مشغل السجل تقديم نسخ إلى ICANN من جميع الوثائق النهائية المتعلقة باستمرار أداة العمليات مع الحفاظ على إخبار ICANN بما يستجد من تطورات لمواد تتعلق بأداة العمليات المستمرة. عدم موافقة مشغل السجل أو السماح بأي تعديل أو تنازل أو استمرار للعمليات المستمرة أو غيرها من الوثائق المتعلقة بها دون الحصول على موافقة خطية مسبقة من قِبل هيئة ICANN (مثل هذه الموافقة لا تحجب بشكل غير معقول).

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

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

9. مدونة سلوك مشغل السجل

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

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

4. تسجيل أسماء النطاقات وفقًا لحقه الخاص، باستثناء الأسماء المسجل من خلال أمين السجل المعتمد من ICANN، ويشترط على الرغم من ذلك، جواز قيام مشغل السجل (أ) بحجز الأسماء عن التسجيل بموجب البند 2.6 من الاتفاقية و(ب) يجوز الامتناع عن التسجيل أو التخصيص لمشغل السجل بما يصل إلى مائة (100) اسم بموجب البند 3.2 من المواصفة 5؛

5. تسجيل الأسماء في نطاق TLD أو النطاقات الفرعية للنطاق TLD استنادًا إلى الوصول ذي الملكية الخاصة لمعلومات حول عمليات البحث وطلبات الحل من خلال المستهلكين لأسماء النطاقات التي لم يتم تسجيلها حتى الآن (والمعروفة اصطلاحًا باسم "التشغيل الأمامي")؛

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

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

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

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

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

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

1. مواصفات أداء السجل

   1. التعريفات

      1. DNS. يشير إلى نظام أسماء النطاقات كما هو معرف في RFC رقم 1034، 1035 وأرقام RFC ذات الصلة.

      2. الحل المناسب لـ DNSSEC. هناك سلسلة ثقة صحيحة من DNSSEC من مرساة ثقة الجذر إلى اسم نطاق خاص، على سبيل المثال نطاق TLD، عبارة عن اسم نطاق مسجل بموجب TLD، إلخ.

      3. EPP. يشير إلى البروتوكول Extensible Provisioning Protocol المعرف في RFC 5730 وأرقام RFC ذات الصلة.

      4. عنوان IP. يشير إلى IPv4 أو عناوين IPv4 دون أي تمييز بينهما. عندما يكون هناك حاجة إلى إجراء تمييز، يتم استخدام عناوين IPv4 أو الإصدار IPv6.

      5. تحقيقات. تستضيف الشبكة المستخدمة لأداء (DNS، EPP، إلخ) اختبارات (أنظر أدناه) التي تقع في مواقع عالمية مختلفة.

      6. RDDS. تشير خدمات دليل بيانات التسجيل إلى خدمات WHOIS وخدمات WHOIS المستندة إلى الويب المجمعة وفقًا لما هو محدد في "المواصفة 4" من هذه الاتفاقية.

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

      8. SLR. متطلبات مستوى الخدمة هو مستوى الخدمة المتوقع لمعلمة معينة يجري قياسه في اتفاقية مستوى الخدمة (SLA).

   2. مصفوفة اتفاقية مستوى الخدمة

	المعامل	SLR (شهريًا)
DNS	توفر خدمة DNS	زمن توقف الخدمة 0 دقيقة = 100% توفر
	توفر خادم أسماء DNS	≥432 دقيقة زمن توقف الخدمة ( 99%)
	RTT حل TCP DNS	≥1500 ميللي ثانية، لنسبة 95% من الاستعلامات على الأقل
	RTT حل UDP DNS	≥500 ميللي ثانية، لنسبة 95% من الاستعلامات على الأقل
	زمن تحديث DNS	≥ 60 دقيقة، لنسبة 95% من التحديثات على الأقل
RDDS	RDDS توافر	≥ 864 دقيقة زمن توقف الخدمة ( 98%)
	توافر RDDS RTT	≥2000 ميللي ثانية، لنسبة 95% من الاستعلامات على الأقل
	RDDS وقت التحديث	≥ 60 دقيقة، لنسبة 95% من التحديثات على الأقل
EPP	توفر خدمة EPP	≥ 864 دقيقة زمن توقف الخدمة ( 98%)
	RTT أمر جلسة EPP	≥ 4000 ميللي ثانية، لنسبة 90% من الأوامر على الأقل
	RTT أمر استعلام EPP	≥ 2000 ميللي ثانية، لنسبة 90% من الأوامر على الأقل
	RTT أمر تحويل EPP	≥ 4000 ميللي ثانية، لنسبة 90% من الأوامر على الأقل

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

3. DNS

   1. توفر خدمة DNS. يشير إلى قدرة مجموعة خوادم أسماء محددة على أنها مرخصة لاسم نطاق معين (مثل TLD)، للإجابة على استعلامات DNS من تحقيقات DNS. لكي يتم اعتبار الخدمة متوفرة في فترة زمنية معينة، لا بد على الأقل أن يكون لاثنين من خوادم الأسماء المسجلة في DNS نتائج معرفة من "اختبارات DNS" إلى كل من "عناوين IP" المسجلة في DNS والتي قوم خادم الاسم بحلها. إذا كان أكثر من 51% من اختبارات DNS تشير عدم توافر الخدمة خلال فترة زمنية معينة، فتعتبر خدمة DNS غير متوفرة.

   2. توفر خادم اسم DND. يشير إلى قدرة "عنوان IP" المسجل DND العام لخادم أسماء معين محدد على أنه مرخص لاسم النطاق، على الإجابة على استعلامات DND من مستخدم الإنترنت. كافة "عناوين IP" مسجل DNS عام لكل خوادم الأسماء لاسم النطاق الذي تتم متابعته سيتم اختبارها بشكل فردي. إذا كان 51% أو أكثر من "اختبارات DNS" تحصل على نتائج غير معرفة/غير مجاب عنها من "عنوان IP" لخادم الاسم خلال مدة زمنية محددة، فإن "عنوان IP" لخادم الاسم لن يعتبر متاحًا.

   3. وقت RTT لحل UDP DNS. يشير إلى RTT لسلسلة من حزمتين، استعلام UDP DNS واستجابة UDP DNS ذات الصلة. إذا كانتRTT أكبر 5 مرات من SLR المقابلة، فسيتم اعتبار RTT غير معروف.

   4. وقت RTT لحل TCP DNS. يشير إلى RTT لسلسلة من الحزم من بداية اتصال TCP حتى نهايته، بما في ذلك استقبال استجابة DNS لاستعلام DNS واحد. إذا كانت RTT أكبر 5 مرات من SLR المقابلة، فسيتم اعتبار RTT غير معروف.

   5. وقت RTT لحل DNS. يشير إما إلى "وقت RTT لحل UDP DNS" أو "وقت RTT لحل TCP DNS".

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

   7. اختبار DNS. يعني استعلام DND واحد غير متعدد أرسل إلى "عنوان IP" (من خلال UDP أو TCP). إذا كان DNSSEC متاحًا في منطقة DND المستعلمة، لكي يعتبر الاستعلام أنه تمت الإجابة عليه، لا بد أن تكون التوقيعات محققة إيجابيًا مقابل سجل DS تم نشره في المنطقة الأصل، إن لم يكن الأصل موقعًا مقابل مثبت ثقة مهيأ بشكل ثابت. لا بد أن تتضمن إجابة الاستعلام على المعلومات المعنية من نظام السجل، وإلا سيتم الاستعلام لم تتم الإجابة عليه. الاستعلام الذي يتضمن "RTT حل DNS" أكثر 5 أضعاف من SLR المقابل، سيعتبر لم تتم الإجابة عليه. النتائج المحتملة لاختبار DNS هي: رقم بالميللي ثانية يقابل "RTT حل DNS" أو، غير معرف/غير مجاب.

   8. قياس معلمات DNS. في كل دقيقة، سوف يقوم كل تحقيق DNS بإجراء "اختبار DNS" لكل من UDP أو TCP لكل "عنوان IP" مسجل في DNS عام لخوادم الاسم الخاصة باسم النطاق الذي يجري مراقبته. إذا كانت نتيجة "اختبار DNS" غير معروف/لم يتم الرد عليها، سيتم اعتبار عنوان IP المختبر غير متوفر من هذا التحقيق إلى أن يحين وقت إجراء اختبار جديد.

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

   10. توزيع استعلامات UDP وTCP. تقوم تحقيقات DNS بإرسال UDP أو TCP "اختبار DNS" بما يقارب توزيع هذه الاستعلامات.

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

4. RDDS

   1. توافر RDDS. يشير إلى قدرة كل خدمات RDDS الخاصة بـ TLD، على الاستجابة إلى الاستعلامات الواردة من مستخدم الإنترنت بالبيانات المناسبة من نظام السجل المعني. إذا 51% أو أكثر من مجسات اختبارات RDDS نرى أي من الخدمات RDDS أنه غير متوفر خلال فترة زمنية معينة، سيتم النظر في RDDS متوفر.

   2. RTT استعلام WHOIS. يشير إلى RTT لسلسلة الحزم من بدء اتصال TCP إلى نهايته، بما في ذلك استقبال استجابة WHOIS. إذا كانت RTT هو 5 مرات أو أكثر من SLR المقابلة، فسيتم اعتبار RTT غير معروف.

   3. RTT استعلام WHOIS المعتمد على الويب. يشير إلى RTT لسلسلة الحزم من بداية اتصال TCP إلى نهايته، بما في ذلك استقبال استجابة HTTP لطلب HTTP واحد. إن قام مشغل السجل بتنفيذ عمليات متعددة الخطوات للحصول على المعلومات، يتم فقط قياس آخر خطوة. إذا كانت RTT أكثر 5 مرات أو أكثر من SLR المقابلة، فسيتم اعتبار RTT غير معروف.

   4. RTT استعلام RDDS. يشير إلى "RTT استعلام WHOIS" و"RTT استعلام WHOIS" المستند إلى الويب معًا.

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

   6. اختبار RDDS. يعني استعلام واحد أرسل إلى "عنوان IP" خاص من واحدة من خوادم واحدة من الخدمات RDDS. تكون الاستعلامات عن كائنات موجودة في نظام السجل ولا بد أن تحتوي الاستجابات على المعلومات ذات الصلة، وإلا سيتم الاستعلام لم تتم الإجابة عليه. الاستعلامات ذات RTT التي تكون أعلى 5 مرت من SLR المقابلة تعتبر لم يتم الرد عليها. النتائج المحتملة لاختبار RDDS هي: عدد بالميللي ثانية يقابل RTT غير معرف/غير مجاب.

   7. قياس معلمات RDDS. كل 5 دقائق، سوف تختار تحقيقات RDDS عنوان IP واحد من كافة "عناوين IP" المسجلة لنظام DNS العام التي يجري مراقبة خوادم RDDS لها وإجراء "اختبار RDDS" على كل واحد. إذا كان اختبار RDDS النتيجة هي غير معروف/لم يتم الرد عليها، وسيتم اعتبار خدمة RDDS المقابلة أنه غير متوفر من أن التحقيق حتى حان الوقت لإجراء اختبار جديد.

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

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

5. EPP

   1. توافر خدمة EPP. يشير إلى قدرة خوادم TLD EPP كمجموعة على الاستجابة إلى الأوامر الواردة من مسجلين لدى سجل معتمد، والذي سبق مصادقتهم على الخوادم. لا بد أن تتضمن الاستجابة على بيانات من نظام السجل. أمر EPP مع "أمر EPP لـ RTT" أكبر 5 مرات أعلى من SLR المطابق سوف يعتبر لم يتم الرد عليه. إن كانت أكثر من 51% من اختبارات EEP أثبتت عدم توفر خدمات EEP خلال فترة زمنية معينة، فتعتبر EEP غير متوفرة.

   2. ٌRTT أمر جلسة EPP. يشير إلى RTT لسلسلة الحزم التي تتضمن إرسال أمر جلسة إضافة إلى استقبال استجابة EPP لأمر جلسة EPP واحد. بالنسبة لأمر تسجيل الدخول، هو يحتوي على الحزم اللازمة لبدء جلسة TCP. بالنسبة لأمر الخروج، هو يحتوي على الحزم اللازمة لإغلاق جلسة TCP. أوامر جلسة EPP هي الأوامر المشار إليها في البند 2.9.1 من EPP RFC 5730. إذا كانت RTT هو 5 مرات أو أكثر من SLR المقابلة، فسيتم اعتبار RTT غير معروف.

   3. RTT أمر استعلام EPP. يشير إلى RTT لسلسلة الحزم التي تتضمن إرسال أمر استعلام إضافة إلى استقبال استجابة EPP لأمر استعلام EPP واحد. لا يحتوي على الحزم اللازمة لبدء أو إغلاق أي جلسة من جلسات EPP أو TCP. أوامر استعلام EPP هي الأوامر المشار إليها في البند 2.9.2 منEPP RFC 5730. إذا كانت RTT هو 5 مرات أو أكثر من SLR المقابلة، فسيتم اعتبار RTT غير معروف.

   4. RTT أمر تحويل EPP. يشير إلى RTT لسلسلة الحزم التي تتضمن إرسال أمر تحويل إضافة إلى استقبال استجابة EPP لأمر تحويل EPP واحد. لا يحتوي على الحزم اللازمة لبدء أو إغلاق أي جلسة من جلسات EPP أو TCP. أوامر نقل EPP هي الأوامر المشار إليها في البند 2.9.3 من EPP RFC 5730. إذا كانت RTT هو 5 مرات أو أكثر من SLR المقابلة، فسيتم اعتبار RTT غير معروف.

   5. RTT أمر EPP. يشير إلى "RTT أمر جلسة EPP"، أو "RTT أمر استعلام EPP" أو "RTT أمر تحويل EPP".

   6. اختبار EPP. يعني إرسال أمر EPP واحد إلى "عنوان IP" معين لأحد خوادم EPP. أوامر الاستعلام والتحويل، باستثناء الأمر "إنشاء"، لا بد عن تختص كائنات موجودة في نظام السجل. لا بد أن تتضمن الاستجابة على بيانات من نظام السجل. النتائج المحتملة لاختبار EPP هي: رقم بالميللي ثانية يقابل "RTT أمر EPP" أو، غير معرف/غير مجاب.

   7. قياس معلمات EPP. كل 5 دقائق، سوف تختار تحقيقات EPP واحد من "عنوان IP" لخوادم EPP الخاصة بنطاق TLD الذي يجري مراقبته وإجراء "اختبار EPP"؛ يجب عليها التغيير كل يوم بين الأنواع الثلاثة 3 المختلفة من الأوامر وبين الأوامر داخل كل فئة. إذا كانت نتيجة اختبار EPP غير معروف/لم يتم الرد عليها، يتم اعتبار خدمة EPP غير متوفرة من هذا التحقيق حتى حان الوقت لإجراء اختبار جديد.

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

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

6. عتبات الطوارئ

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

وظيفة حاسمة	عتبة الطوارئ
خدمة DNS (جميع الخوادم)	4-ساعات إجمالي وقت تعطل / أسبوع
الحل المناسب لـ DNSSEC	4-ساعات إجمالي وقت تعطل / أسبوع
EPP	24-ساعات إجمالي وقت تعطل / أسبوع
RDDS (WHOIS/WHOIS المستند إلى الويب)	24-ساعات إجمالي وقت تعطل / أسبوع
مستودع البيانات	مخالفة اتفاقية السجل وفقًا لما هو مشار إليه في المواصفة 2، الجزء ب، البند 6.

7. تصعيد الطوارئ

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

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

1. بدء تصعيد الطوارئ بمعرفة ICANN

عند الوصول إلى نسبة 10% من عتبات الطوارئ وفقًا لما هو مشار إليه في البند 6 من هذه المواصفة، تقوم عمليات الطوارئ في ICANNببدء عملية تصعيد طوارئ مع مشغل السجل المعني. وتألف عملية تصعيد الطوارئ من العناصر التالية كحد أدنى: الإلكتروني (أي البريد الإلكتروني أو الرسائل القصيرة SMS) و/أو إشعار الاتصالات الصوتية إلى إدارة عمليات الطوارئ لدى مشغل السجل مع المعلومات التفصيلية المتعلقة بالمسألة التي يجري xxxxxxx، ويشمل ذلك دليل حول فشل المراقبة بين فريق ICANNومشغل السجل، والالتزام بالبدء في عملية تصحيح المشكلات سواء من خلال خدمة المراقبة أو الخدمة التي يجري مراقبتها.

2. بدء تصعيد الطوارئ بمعرفة أمناء السجلات

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

3. إشعارات التعطل والصيانة

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

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

8. تعهدات قياس الأداء

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

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

1. التزامات المصلحة العامة

1. يلتزم مشغل السجل باستخدام أمناء السجلات المعتمدين من ICANN فقط على أن يكون من الأطراف الموقعة على اتفاقية اعتماد أمين السجل المعتمدة من خلال مجلس إدارة ICANN في 27 يونيو 2013 في تسجيل أسماء النطاقات. ويجب الاحتفاظ بقائمة بأمناء السجلات هؤلاء من خلال ICANN على موقع ICANN على الويب.

2. ويلتزم مشغل السجل بتشغيل السجل لنطاق TLD بما يتفق مع كافة الالتزامات وبيان العزم وخطط الأعمال الواردة في الأقسام التالية من طلب مشغل السجل إلى ICANN للحصول على TLD، على أن يتم توحيد هذه الالتزامات وبيانات النية وخطط الأعمال بموجب ذلك بالإشارة إليها في هذه الاتفاقية. تسري التزامات مشغل السجل بموجب هذه الفقرة بمعرفة ICANN ومن خلال عملية فض منازعات المصلحة العامة التي أقرتها ICANN (والمنشورة على xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxx)، والتي يجوز مراجعتها في الجوانب غير المادية بمعرفة ICANN من حين إلى آخر ("PICDRP"). ويلتزم مشغل السجل بـ PICDRP. ويوافق مشغل السجل على تنفيذ والالتزام بأية تعويضات تفرضها ICANN (والتي قد تشتمل على أي من التعويضات المعقولة، بما في ذلك لتجنب حدوث أي شك، إنهاء اتفاقية السجل بموجب البند 4.3(هـ) من الاتفاقية) بعد قرار من أي هيئة PICDRP مع الإقرار بالالتزام بهذه القرار

[يجب على مشغل السجل إدراج أقسام خاصة للطلب هنا، إذا كان مطابقًا]

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

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

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

3. ويلتزم مشغل السجل بتشغيل نطاق TLD بطريقة شفافة بما يتسق مع المبادئ العامة للانفتاح وعدم التمييز من خلال إقرار ونشر والالتزام بسياسات تسجيل واضحة.

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

المواصفة 12

سياسات تسجيل المجتمع

يلتزم مشغل السجل بتنفيذ ومراعاة سياسات تسجيل المجتمع المنصوص عليها أدناه و/أو المرفقة بهذه المواصفة 12.

[أدخل سياسات التسجيل]

1 يخضع لموافقات أخرى.

التعديل على الرسوم.

1