الوحدة 7 إجراءات تقييم السلاسل والطلبات

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

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

تتناول الوحدة 7 عملية التقييم، بما في ذلك:

• نظرة عامة على أنواع الطلبات وطرق التعامل معها.

• فحص أنواع نطاقات TLD، مثل الأسماء الجغرافية وأسماء النطاقات المدولة.

• استراتيجيات للتخفيف من تضارب الأسماء.

• تقييم تشابه السلاسل

توفر هذه الوحدة نظرة تفصيلية على هذه العملية الأساسية المصممة بعناية لضمان استقرار نظام DNS وأمانه.

7.1 أنواع السلاسل والطلبات

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

• أسئلة الطلب: تتطلب بعض أنواع الطلبات من مقدم الطلب الإجابة على أسئلة متخصصة كجزء من طلبه (على سبيل المثال، الأسئلة المتعلقة بأهداف المجتمع لمقدم الطلب).

• الأولوية: قد تتلقى أنواع معينة من الطلبات الأولوية في قرعة تحديد الأولويات (على سبيل المثال، نطاق IDN).¹

• التقييم: قد تتطلب طبيعة الطلب أو تركيزه أو هدفه تقييمًا متخصصًا (على سبيل المثال، لاسم جغرافي).

• الخلاف: قد تكون إجراءات تسوية الخلافات الحاصلة متخصصة وفقًا لنوع الطلب (على سبيل المثال، تقييم أولوية المجتمع).

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

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

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

7.1.1 الطلبات العامة

الطلب العام هو الطلب الذي لا يقع ضمن أحد أنواع الطلبات المحددة في القسم 7.1.2 الطلبات المتخصصة ويخضع لمجموعة المتطلبات القياسية المحددة في دليل مقدم الطلب الحالي.

7.1.2 الطلبات المتخصصة

الطلبات المتخصصة هي تلك التي قد يكون لها متطلبات مختلفة حسب الطلب (على سبيل المثال، طلب للحصول على نطاق gTLD مجتمعي)، أو حسب السلسلة (على سبيل المثال، IDN)، أو حسب نوع مقدم الطلب (على سبيل المثال، منظمة حكومية دولية أو مقدم طلب لدعم مقدم الطلب). ويقدم هذا القسم نظرة عامة على أنواع الطلبات المتخصصة هذه. قد يكون الطلب مؤهلًا للحصول على تصنيفات متعددة في نفس الوقت؛ على سبيل المثال، يمكن تصنيف الطلب باعتباره IDN وطلب مجتمعي في آن واحد.

7.1.2.1 طلبات الحصول على نطاقات gTLD المجتمعية

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

• أسئلة الطلب: سيتم مطالبة مقدمي الطلبات الذين يصنفون طلبهم كطلب مجتمعي بالإجابة على سلسلة من الأسئلة الخاصة بطلبات المجتمع.⁴ وسيتم تقييم إجابات هذه الأسئلة إذا اختار مقدم الطلب المشاركة في تقييم أولوية المجتمع CPE. راجع الملحق 1 أسئلة الطلب (مجموعة الأسئلة 7 نطاقات gTLD المجتمعية).

• التقييم: تقييم سياسات التسجيل المجتمعية لاتفاقية السجل ("سياسات التسجيل المجتمعية") – من خلال تقييم التزامات السجل (RCE) – المقترح تضمينها في اتفاقية السجل فيما يتعلق بتشغيل نطاق gTLD المجتمعي المقدم عليه، سيتم إجراؤه أثناء تقييم الطلب، ما لم يختار مقدم الطلب المجتمعي المشاركة في تقييم التزامات السجل CPE، وهو خيار متاح فقط لطلبات المجتمع لتسوية الخلافات. وإذا اختار مقدم الطلب المشاركة في تقييم CPE، فسيتم إجراء تقييم RCE في وقت سابق، قبل تقييم الطلب، لأن هذا التقييم يجب أن يتم قبل أن يكون الطلب مؤهلًا للمشاركة في CPE. انظر القسم 7.8 التزامات المصلحة العامة، والتزامات السجل الطوعية، وسياسات التسجيل المجتمعية.

• الخلاف: في حالة حصول خلافات مع طلبات أخرى على نفس السلسلة، يجوز لمقدم الطلب اختيار المشاركة في تقييم أولوية المجتمع (راجع القسم 5.4) وربما من المحتمل المشاركة في مزاد ICANN. راجع القسم 5.2 الخلافات على السلسلة وإجراءات تسوية الخلافات.

• التعاقد: يتعين على مقدم الطلب أن يعدد سياسات التسجيل المجتمعية التي يتم تقييمها والموافقة عليها من قِبل ICANN، وحيثما كان ذلك مناسبًا، يتم تقييمها أثناء CPE، في المواصفة 12 من اتفاقية السجل الأساسية الخاصة به. انظر القسم 1.2.15 التعاقد. انظر أيضًا القسم 7.8.4 سياسات التسجيل المجتمعية أدناه فيما يتعلق بتقييم سياسات التسجيل المجتمعية.

• الرسوم: إذا اختار مقدم الطلب المشاركة في تقييم أولوية المجتمع CPE، فيجب عليه دفع رسوم تقييم إضافية. انظر القسم 3.3 الرسوم والمدفوعات.

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

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

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

راجع القسم 5.4 تقييم أولوية المجتمع للحصول على مزيد من المعلومات حول تقييم أولوية المجتمع والقسم 7.8 التزامات المصلحة العامة، والتزامات التسجيل الطوعية، وسياسات التسجيل المجتمعية.⁶

وسيتم أيضًا فرض رسوم على عملية تقييم التزام السجل (RCE) للمواصفة 12 (انظر القسم 3.3 الرسوم والمدفوعات).

7.1.2.2 طلبات الأسماء الجغرافية

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

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

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

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

• الرسوم: سيتم فرض رسوم مشروطة لمراجعة الأسماء الجغرافية (القسم 7.5.3.2). انظر القسم 3.3 الرسوم والمدفوعات.

7.1.2.3 طلبات الأسماء المحجوزة

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

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

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

7.1.2.4 طلبات نطاقات Brand TLD.

يمكن لمقدم الطلب تصنيف طلبه على أنه طلب لنطاق Brand TLD.. يتيح هذا النوع من الطلبات لمقدم الطلب استخدام اسم شركته أو علامته التجارية كنطاق TLD.⁹ نطاق Brand TLD. هو سلسلة متطابقة مع العناصر النصية (على سبيل المثال، اسم أو كلمة أو عبارة) لعلامة تجارية مسجلة نافذة بموجب القانون المعمول به،¹⁰ والتي يعمل مقدم الطلب على تشغيلها كنطاق Brand TLD.¹¹ ويجب على مقدمي الطلبات الذين يقدمون طلبات للحصول على نطاق .Brand TLD أن يتوقعوا متطلبات مختلفة في النواحي التالية من دورة حياة الطلب:

• أسئلة الطلب: سيتم طرح أسئلة إضافية على مقدم الطلب فيما يتعلق بالطلب الذي يتقدم إليه باعتباره .Brand TLD (على سبيل المثال، علامته التجارية). انظر الملحق 1 أسئلة الطلب.

• التقييم: سيتم مراجعة طلب الحصول على Brand TLD. لتحديد الأهلّية للحصول على حالة نطاق .Brand TLD¹² أنظر القسم 7.3 تقييم أهلّية Brand TLD.

• الخلاف: إذا كان هناك تنافس بين طلب وطلبات أخرى على نفس السلسلة المقدم عليها، فقد تتاح لمقدم طلب Brand TLD. الفرصة لتقديم التماس لتغيير السلسلة المقدم عليها لتسوية الخلافات. راجع القسم 5.2 الخلافات على السلسلة وإجراءات تسوية الخلافات.¹³

• التعاقد: إذا كانت مؤهلة، فسيتم تضمين المواصفة 13 في اتفاقية السجل الأساسية الخاصة بها للتنفيذ ¹⁴ انظر القسم 1.2.15 التعاقد.

• الرسوم: سيتم فرض رسوم مشروطة لتقييم أهلية Brand TLD.. انظر القسم 3.3 الرسوم والمدفوعات.

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

7.1.2.5 طلبات أسماء النطاقات المدولة

سيكون بمقدور مقدمي الطلبات التقدم بطلب للحصول على أسماء النطاقات المدولة IDN. يجب أن تتوافق طلبات IDN مع المتطلبات المحددة في القسم 3.1.9 أسماء النطاقات المدولة، ويمكن لمقدمي الطلبات أن يجدوا متطلبات مختلفة في النواحي التالية لدورة حياة الطلب:

• تحديد الأولويات: مع مراعاة الحدود والمتطلبات المحددة في القسم 3.7 ترتيب معالجة الطلبات وقرعة تحديد الأولوية، قد تتلقى طلبات أسماء النطاقات المدولة الأولوية في المعالجة على الطلبات التي ليست على أسماء النطاقات المدولة.

7.1.2.6 طلبات متباينات نطاقات gTLD الموجودة حالياً

سيتاح لمشغلي السجل الحاليين الفرصة للتقدم بطلب للحصول على سلاسل متباين نطاقات gTLD الحالية والتي من الممكن تخصيصها.¹⁵ يجب أن تتوافق طلبات سلاسل المتباين هذه مع المتطلبات المحددة في القسم 3.1.9 أسماء النطاقات المدوّلة، ويمكن لمقدمي الطلبات أن يجدوا المتطلبات المختلفة في النواحي التالية من دورة حياة الطلب:

• أسئلة الطلب: سيتم طرح أسئلة إضافية على مقدم الطلب فيما يتعلق بسلسلة المتباينات التي يتقدم بطلب للحصول عليها. انظر الملحق 1 أسئلة الطلب.

• تحديد الأولويات: مع مراعاة الحدود والمتطلبات المحددة في القسم 3.7 ترتيب معالجة الطلبات وقرعة تحديد الأولوية، قد يتم إعطاء الأولوية لطلبات سلاسل المتباينات القابلة للتخصيص على الطلبات التي ليست أسماء نطاقات مدوّلة.

• التقييم: سيخضع مقدم الطلب للحصول على متباين قابل للتخصيص لنطاق gTLD الحالي للمراجعة من قِبل لجنة، ويُتوقع منه أن يقدم مبررًا للحاجة إلى المتباين (على سبيل المثال، شرح لكيفية اعتبار السلاسل الأساسية وسلاسل المتباين هي نفسها).¹⁶ وقد تتضمن المتطلبات الإضافية استخدام نفسموفر خدمة السجل RSP لسجل المتباين كالسجل الأساسي. راجع الملحق 1 أسئلة الطلب والقسم 7.10 تقييم تشابه السلاسل.

• التعاقد: سيتم إضافة المواصفة 14 إلى اتفاقية السجل الأساسية للتنفيذ. انظر القسم 1.2.15 التعاقد.

• الرسوم: سيتم إعفاء مشغلي السجل الحاليين الذين يتقدمون بطلب للحصول على سلاسل متباين قابلة للتخصيص لنطاقات gTLD الحالية من رسوم الطلب الأساسية لما يصل إلى أربع سلاسل متباين؛¹⁷ وستترتب على الطلبات التي تزيد عن أربع سلاسل متباين رسوم إضافية. انظر القسم 3.3 الرسوم والمدفوعات.¹⁸

7.1.2.7 طلبات أسماء النطاقات المدولة IDN الجديدة التي تتضمن متباينًا واحدًا أو أكثر

ستتاح لمقدمي الطلبات الفرصة للتقدم بطلب للحصول على IDN TLD جديد بالإضافة إلى سلاسل المتباينات القابلة للتخصيص. يجب أن تتوافق طلبات الحصول على IDN TLD جديد وسلاسل المتباينات القابلة للتخصيص الخاصة به مع المتطلبات المحددة في القسم 3.1.9 أسماء النطاقات المدولة، ومن المتوقع أن تجد متطلبات مختلفة في النواحي التالية من دورة حياة الطلب:

• أسئلة الطلب: سيتم طرح أسئلة إضافية على مقدم الطلب فيما يتعلق بنطاق IDN TLD وسلاسل المتباينات القابلة للتخصيص التي يتقدم بطلب للحصول عليها. انظر الملحق 1 أسئلة الطلب.

• تحديد الأولويات: مع مراعاة الحدود والمتطلبات المحددة في القسم 3.7 ترتيب معالجة الطلبات وقرعة تحديد الأولوية، قد تتلقى طلبات نطاقات IDN TLD، بما في ذلك سلاسل المتباينات القابلة للتخصيص، الأولوية في المعالجة مقارنةً بالطلبات التي ليست لأسماء النطاقات المدولة.

• التقييم: سيخضع مقدم الطلب للحصول على نطاق IDN TLD جديد وسلاسل المتباينات الخاصة به للمراجعة من قِبل لجنة، ويُتوقع منه أن يقدم مبررًا لطلبه مفسراً مدى ضرورة المتباين المقدم عليه (على سبيل المثال، شرح كيفية اعتبار السلاسل الأساسية وسلاسل المتباينة متشابهة).¹⁹ وقد تنطبق متطلبات إضافية، مثل استخدام نفس موفر خدمة السجل RSP لسجل المتباينات كالسجل الأساسي، بالإضافة إلى التأكد من أن أنواع TLD متسقة في سائر السلسلة الأساسية وسلاسل المتباينات. انظر القسم 7.10 تقييم تشابه السلاسل.

• التعاقد: سيتم إضافة المواصفة 14 إلى اتفاقية السجل الأساسية للتنفيذ. انظر القسم 1.2.15 التعاقد.

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

7.1.2.8 الطلبات المقدمة من المنظمات الحكومية الدولية أو الكيانات الحكومية

سيتم قبول الطلبات المقدمة من المنظمات الحكومية الدولية (IGO)²¹ أو الكيانات الحكومية²². يجب على مقدمي الطلبات في هذه الفئة مراعاة متطلبات الأسماء الجغرافية المحددة في القسم 7.5 الأسماء الجغرافية، وكذلك متطلبات الأسماء المحجوزة المحددة في القسم 7.2 الأسماء المحظورة والمحجوزة. ويمكن لمقدمي الطلبات هؤلاء إيجاد متطلبات مختلفة في النواحي التالية من دورة حياة الطلب:

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

• التقييم: سيتعين على أي كيان من هذا القبيل تقديم وثائق للتحقق من وضعه كمنظمة حكومية دولية أو حكومية، حسب الاقتضاء. انظر القسم 7.5.3.2 مراجعة الأسماء الجغرافية والقسم 7.2.2.2 مراجعة الأسماء المحجوزة.

7.1.2.9 طلبات مقدمي الطلبات المؤهلين للحصول على دعم مقدم الطلب

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

يمكن لمقدمي الطلبات المؤهلين للحصول على دعم مقدم الطلب أن يجدوا متطلبات مختلفة في النواحي التالية من دورة حياة الطلب:

• الخلاف: سيحصل مقدمو الطلبات الذين يشاركون في مزاد ICANN على ائتمان العطاء. راجع القسم 5.6.5 ائتمانيات العطاء لمقدمي طلبات برنامج دعم مقدم الطلب في المزادات.

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

• الرسوم: سيكون مقدم الطلب المؤهل للحصول على دعم مقدم الطلب مؤهلًا لدفع رسوم طلب مخفضة بالإضافة إلى رسوم تقييم مشروطة مخفضة. راجع القسم 3.3 الرسوم والمدفوعات بالإضافة إلى دليل برنامج دعم مقدم الطلب للحصول على مزيد من المعلومات.²³

7.1.3 أنواع تغيير الطلبات

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

7.2 نظرة عامة على الأسماء المحظورة والمحجوزة

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

ملاحظة: في دليل مقدم الطلب لعام 2012، يُشار الآن إلى القائمة المسماة "السلاسل غير المؤهلة للتفويض" باسم قائمة الأسماء المحجوزة، والقائمة التي كانت تسمى سابقًا "قائمة الأسماء المحجوزة في المستوى الأعلى" تُعرف الآن باسم قائمة الأسماء المحظورة.

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

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

7.2.1 الأسماء المحظورة

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

تكون سلاسل gTLD التالية وسلاسل المتباينات القابلة للتخصيص الخاصة بها في قائمة الأسماء المحظورة (راجع الحواشي السفلية للقوائم الفعلية) ولا يمكن التقدم بطلب للحصول عليها:

• أسماء النطاقات للاستخدام الخاص: هذه هي السلاسل المحددة المحجوزة بموجب المعايير الفنية لأغراض غير متوافقة مع التفويض، كما هو مذكور صراحةً في سجل أسماء النطاقات للاستخدام الخاص التابع لهيئة IANA.^26،27،28

• المعايير الفنية: أنظر القسم 3.8.3 مراجعة استقرار DNS للحصول على مزيد من التفاصيل.

• أسماء البلدان أو الأقاليم فيما يتعلق بالأسماء الجغرافية: أنظر القسم 7.5 الأسماء الجغرافية.

• الهيئات المرتبطة بـ ICANN وIANA وIETF والبنية التحتية للإنترنت: وتشمل هذه، على سبيل المثال، المنظمات الداعمة (SO) واللجان الاستشارية ²⁹(AC)التابعة لـ ICANN، وسجلات الإنترنت الإقليمية،³⁰ وهيئات IETF،³¹ ومعرفات النظام المضمنة من خلال السياسة المعتمدة القائمة على التوافق في الآراء.^32،33

الجدول 1-7: الهيئات ذات الصلة بـ ICANN وIANA وIETF والبنية التحتية للإنترنت

• سلاسل أخرى غير مسموح بها:

  • نطاقات TLD المفوضة.^34,

  • سلاسل gTLD التي تم التقدم بطلب للحصول عليها في جولات gTLD السابقة والتي لا تزال قيد المعاملة.³⁵

  • نطاقات ccTLD المتواجدة حالياً التي تم تقييمها بنجاح.

  • السلاسل المطلوبة حاليًا كنطاقات المستوى الأعلى لرموز البلدان لأسماء النطاقات المدوَّلة IDN ccTLD.

  • جميع سلاسل ASCII الأخرى المكونة من حرف واحد أو حرفين.

7.2.1.1 تحديد الأسماء المحظورة

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

7.2.1.1.1 الطعن على تحديد الأسماء المحظورة

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

7.2.2 الأسماء المحجوزة

نقسم عملية تقييم الأسماء المحجوزة إلى قسمين: تحديد الأسماء المحجوزة، هو فحص آلي يحدد ما إذا كانت السلسلة المقدم عليها تظهر في قائمة الأسماء المحجوزة، ومراجعة الأسماء المحجوزة، التي تتضمن عملية الاستثناء لمقدم الطلب للتقدم بطلب للحصول على اسم IGO-INGO دولي محدود والتحقق من الوثائق المطلوبة.³⁷

توجد سلاسل المنظمات الحكومية الدولية والمنظمات غير الحكومية الدولية المحدودة التالية في قائمة الأسماء المحجوزة ويمكن التقدم بطلب للحصول عليها من خلال عملية استثنائية فقط من قِبل الكيان ذي الصلة، شريطة أن يقدم الوثائق المناسبة كما هو مفصل في القسم 7.2.2.2 تحديد الأسماء المحجوزة أدناه:

• الأسماء المضافة بناءً على التوصيات الصادرة عن مجموعة عمل³⁸ IGO-INGO PDP فيما يتعلق بحماية معرفات IGO-INGO في جميع نطاقات gTLD،^39،40 بما في ذلك سلاسل المتباينات القابلة للتخصيص، مؤهلة للتفويض عند التحقق. أسماء الصليب الأحمر والهلال الأحمر (RCRC)،⁴¹ واللجنة الأولمبية الدولية (IOC)،⁴² والمنظمات الحكومية الدولية ⁴³(IGO)المنظمات الدولية غير الحكومية (INGO).⁴⁴

7.2.2.2 تحديد الأسماء المحجوزة

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

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

7.2.2.2.1 الطعن على تحديد الأسماء المحجوزة

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

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

7.2.2.3 مراجعة الأسماء المحجوزة

7.2.2.3.1 عملية الاستثناء للتقدم بطلب للحصول على الأسماء المحجوزة

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

ولتقديم طلب للحصول على اسم محجوز من خلال عملية الاستثناء، يجب على مقدمي الطلبات تقديم أنواع المستندات التالية في وقت تقديم الطلب:

• شهادة التأسيس، وإذا لزم الأمر، خطاب من المنظمة الأم.

• وثائق التأييد أو عدم الاعتراض بما في ذلك رسالة موقعة من السلطة العامة المعنية (إن وجدت).

7.2.2.3.1.1 التحقق من الوثائق المقدمة

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

وقد تقوم ICANN بالتشاور مع السلطات المعنية لمزيد من التحقق.

وإن كان ذلك ممكنًا، للحصول على المزيد من المساعدة في تحديد السلطة الحكومية أو العامة ذات الصلة بطلب ما، فقد يرغب مقدم الطلب في التشاور مع ممثل GAC ذي الصلة.⁴⁵

7.2.2.3.2 التقييم الموسع لمراجعة الأسماء المحجوزة

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

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

7.3 تقييم أهلّية Brand TLD.

سيكون بمقدو مقدمي الطلبات تصنيف الطلب ذاتيًا باعتباره نطاق Brand TLD.. ويسمح هذا النوع من الطلبات للشركات أو المؤسسات باستخدام اسم شركتها أو علامتها التجارية كنطاق TLD. انظر القسم 3.1.6 أنواع الطلبات والسلاسل.

7.3.1 أهلية تقييم أهلية Brand TLD.

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

يجوز لمقدم الطلب أن يطلب تقييم أهلية نطاق Brand TLD. في طلبه أو عبر التماس تغيير الطلب. راجع القسم 3.8 التماسات تغيير الطلب.

7.3.2 رسوم مشروطة لتقييم أهلّية نطاق Brand TLD.

يجب على مقدم الطلب الذي يطلب تقييم أهلية Brand TLD. أن يدفع رسوم تقييم إضافية كما هو محدد في القسم 3.3 الرسوم والمدفوعات. لن يتم إجراء تقييم أهلية Brand TLD. إلا بعد أن تتلقى ICANN الرسوم ذات الصلة.

7.3.3 تقييم ونتائج تقييم أهلّية نطاق Brand TLD.

للتأهل للحصول على تسمية Brand TLD.، يجب على مقدم الطلب تقديم ملف واحد أو أكثر من ملفات بيانات العلامة التجارية الموقعة (SMD) من مكتب مقاصة العلامات التجارية (TMCH). راجع إرشادات TMCH لمعرفة متطلبات الأهلية.⁴⁷

7.3.3.1 المشاركة مع مكتب مقاصة العلامات التجارية قبل تقديم طلب Brand TLD.

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

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

• يجب على مقدم الطلب للحصول على نطاق Brand TLD. بدون علاقة مع TMCH أو بدون ملفات SMD تغطي السلاسل التي يرغب بتقديم طلب للحصول عليها أن يبدأ عملية التحقق في مكتب TMCH.⁴⁸

• التأكد من إدراج أي علامات TLD مرغوبة في عناصر <mark:label> في ملفات SMD. يجب أن تتطابق أي سلسلة يرغب مقدم الطلب للحصول على Brand TLD. بالتقدم بطلب للحصول عليها تمامًا مع عنصر <mark:label> في SMD نافذ مؤرخ قبل تقديم الطلب.

• التأكد من إدراج أي رموز بمتباين مرغوبة لسلسلة Brand. الأساسية في عناصر <mark:label> في ملفات SMD. ويجب أن تتطابق جميع سلاسل المتباينات المقدم عليها لنطاق Brand TLD. تمامًا مع عنصر <mark:label> في SMD نافذ مؤرخ قبل تقديم الطلب.

• التأكد من أن عناصر <mark:goodsAndServices> صحيحة وكاملة وتتضمن كلمة قد يرغب مقدم الطلب في استخدامها في تغيير سلسلة Brand. وفقًا لطلب تغيير سلسلة Brand. (انظر القسم 5.3). ويجب أن تظهر الكلمات الإضافية المستخدمة لزيادة سلسلة Brand. المقدم عليها في عنصر <mark:goodsAndServices> لملف SMD نافذ ومؤرخ قبل تقديم طلب تغيير سلسلة Brand..

إذا لم تظهر الكلمات المستخدمة لزيادة السلسلة المقدم عليها في ملف SMD، فما زال من الممكن إرسال طلب تغيير سلسلة Brand. باستخدام وثائق بديلة. راجع القسم 5.3.2. متطلبات التماس تغيير سلسلة Brand..

7.3.3.2. معايير تقييم أهلّية نطاق Brand TLD.

سيتم إجراء تقييم أهلية Brand TLD. بواسطة لجنة تقييم أهلية Brand TLD.. ويجب على مقدم الطلب الذي يسعى للحصول على تسمية Brand TLD. أن يثبت أن الطلب يلبي المعايير التالية:

1أ. يجب أن تتطابق سلسلة gTLD المقدم عليها تمامًا مع العناصر النصية للعلامة التجارية المسجلة التي تم التحقق منها بواسطة مكتب TMCH في ملفات SMD المقدمة؛ أو

1ب. إذا قام مقدم الطلب بتغيير السلسلة المقدم عليها باستخدام طلب تغيير سلسلة Brand. (القسم 5.3)، فيجب أن تفي السلسلة النهائية بجميع المتطلبات المنصوص عليها فيه.

2. يجب أن يلبي مقدم الطلب والسلسلة النهائية (بما في ذلك جميع سلاسل المتباينات القابلة للتخصيص) جميع المتطلبات المنصوص عليها في المواصفة 13 من اتفاقية السجل الأساسية. انظر الملحق 4 اتفاقية السجل الأساسية.

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

7.3.3.3 الأسئلة التوضيحية لتقييم أهلّية نطاق Brand TLD.

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

7.3.3.4 نتائج تقييم أهلّية نطاق Brand TLD.

سيتم تضمين نتائج تقييم أهلية Brand TLD. في تقارير تقييم الطلب ومقدم الطلب، كما هو موضح في القسم 1.2.13 نشر تقارير تقييم الطلب ومقدم الطلب.

إذا نجح مقدم الطلب في اجتياز مرحلة تقييم أهلية Brand TLD.، فسيتم إضافة المواصفة 13 إلى اتفاقية السجل الأساسية المعمول بها إذا انتقل الطلب إلى مرحلة التفويض.

إذا لم ينجح تقييم أهلية Brand TLD.، فيحق لمقدم الطلب اختيار الاستمرار في طلبه بدون تصنيف Brand TLD.، أي بدون إضافة المواصفة 13.

إذا تم تقديم طلب Brand TLD. خارج نافذة تقديم الطلب من خلال التماس تغيير الطلب، أو إذا رغب مقدم الطلب بسحب طلبه للحصول على تسمية Brand TLD.، فسيتم فتح نافذة التعليق لمدة 30 يومًا.

7.3.4 الطعون والتقييم الموسع لتقييم أهلية نطاق Brand TLD.

سيكون بمقدور مقدمي الطلبات إعادة تقديم المستندات المطلوبة إذا كان التقديم الأولي لهذه المستندات غير ممتثل لما ينغي تقديمه من مستندات. وبسبب هذا، فإن التقييم الموسع أو آلية الطعن غير قابلة للتطبيق على هذا التقييم.

7.3.5 التنافس على نفس السلسلة وتغيير السلسلة

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

7.4 تقييم الإعفاء من القواعد السلوكية لمشغل السجل

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

7.4.1 الأهلية لتقييم الإعفاء من القواعد السلوكية

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

يجوز لمقدم الطلب أن يطلب إعفاءً من القواعد السلوكية في طلبه أو، بعد تقديم الطلب، باستخدام التماس تغيير الطلب. إن طلب الإعفاء من القواعد السلوكية مفتوح للجميع للمراجعة والإدلاء بالرأي من خلال فترة التعليق على الطلب (انظر القسم 4.1.3 التعليقات على الطلبات في عملية التقييم).

7.4.2 تقييم الإعفاء من القواعد السلوكية لسلاسل المتباين

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

7.4.3 الرسوم المشروطة لتقييم الإعفاء من القواعد السلوكية

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

7.4.4 معايير تقييم الإعفاء من القواعد السلوكية

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

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

2. لن يقوم مشغل السجل ببيع أو توزيع أو نقل السيطرة أو استخدام أي تسجيلات في gTLD وسلسلة (سلاسل) المتباينات، إذا لزم الأمر، إلى أي طرف ثالث ليس تابعًا لمشغل السجل؛ و

3. تطبيق القواعد السلوكية على نطاق gTLD والسلسلة (سلاسل) المتباين، إذا أمكن، لحماية المصلحة العامة.

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

7.4.5 الأسئلة التوضيحية لتقييم الإعفاء من القواعد السلوكية

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

7.4.6 نتائج تقييم الإعفاء من القواعد السلوكية

سيتم تضمين نتائج تقييم الإعفاء من القواعد السلوكية في تقارير تقييم الطلب ومقدم الطلب، كما هو موضح في القسم 1.2.13 نشر تقارير تقييم الطلب ومقدم الطلب.

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

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

7.4.6 الطعون والتقييم الموسع لتقييم الإعفاء من القواعد السلوكية

سيكون بمقدور مقدمي الطلبات إعادة تقديم المستندات المطلوبة إذا كان التقديم الأولي لهذه المستندات غير ممتثل لما ينبغي تقديمه من مستندات. وبسبب هذا، فإن التقييم الموسع أو آلية الطعن غير قابلة للتطبيق على هذا التقييم.

7.5 الأسماء الجغرافية

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

تتضمن معالجة الأسماء الجغرافية ما يلي:

• تحديد الأسماء الجغرافية: فحص على مستوى السلسلة وهو جزء من تقييم السلسلة.

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

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

7.5.1 معاملة أسماء البلدان أو الأقاليم

لن تتم الموافقة على الطلبات الخاصة بالسلاسل التي تمثل أسماء البلدان أو الأقاليم.⁴⁹ وتعتبر السلسلة اسمًا لدولة أو إقليم إذا كانت تلبي أيًا من المعايير التالية:

1. رمز مكون 3 أحرف مدرج في معيار ISO 3166-1.⁵⁰

2. اسم طويل مدرج في معيار ISO 3166-1، أو ترجمة للاسم الطويل إلى أي لغة.

3. اسم قصير مدرج في معيار ISO 3166-1، أو ترجمة للاسم القصير إلى أي لغة.

4. الاسم القصير أو الطويل المرتبط برمز تم تعيينه على أنه "محجوز بشكل استثنائي" من قِبل وكالة صيانة ISO 3166.

5. مكوّن قابل للفصل لاسم بلد أو إقليم مدرج في "قائمة أسماء البلدان والأقاليم القابلة للفصل"، أو ترجمة لاسم يظهر في القائمة، بأي لغة. انظر الملحق 2 المواد المتعلقة بالأسماء الجغرافية.

6. التبديلات والتحويلات للسلاسل التالية محجوزة ولا تتوفر للتفويض:

1. الأسماء الطويلة المدرجة في معيار ISO 3166-1.

2. الأسماء القصيرة المدرجة في معيار ISO 3166-1.

3. ارتباط الأسماء القصيرة أو الطويلة برمز تم تعيينه على أنه "محجوز بشكل استثنائي" من قِبل وكالة صيانة ISO 3166.

4. مكوّن قابل للفصل لاسم بلد أو إقليم مدرج في "قائمة أسماء البلدان والأقاليم القابلة للفصل، أو ترجمة لاسم يظهر في القائمة، بأي لغة."

السلاسل الناتجة عن التبديلات والتحويلات للرموز المكونة من 3 أحرف أبجدية المدرجة في معيار ISO 3166-1 متوفرة للتفويض، ما لم تكن السلاسل نفسها الناتجة عن التبديلات والتحويلات موجودة في تلك القائمة.⁵¹

7. اسم يُعرف به بلد ما بشكل عام، كما يتضح من الأدلة التي تثبت أن البلد معترف به بهذا الاسم من قِبل منظمة حكومية دولية أو منظمة معاهدة.7.5.2 الأسماء الجغرافية التي تتطلب وثائق من الحكومة أو السلطات العامة

7.5.2. الأسماء الجغرافية التي تتطلب وثائق من الحكومة أو

السلطات العامة

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

1. السلاسل التي تمثل، بأي لغة، اسم عاصمة أي بلد أو منطقة مدرجة في معيار ISO 3166-1.

2. أسماء المدن حيث يعلن مقدم الطلب أنه ينوي استخدام نطاق gTLD لأغراض مرتبطة باسم المدينة.

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

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

1. اتضح من بيانات مقدم الطلب ضمن الطلب أن مقدم الطلب سوف يستخدم نطاق TLD في المقام الأول لأغراض مرتبطة باسم المدينة؛ و

2. كانت السلسلة المقدم عليها طلب للحصول عليها اسم مدينة كما هو مدرج في الوثائق الرسمية للمدينة.⁵²

3. السلاسل التي تطابق تمامًا أسماء الأماكن الفرعية الوطنية، مثل المقاطعات أو المحافظات أو الولايات، المدرجة في معيار ISO 3166-2.

4. السلاسل المدرجة كمناطق اليونسكو⁵³ أو التي تظهر في قسم المناطق الجغرافية في "رموز البلدان أو المناطق القياسية للاستخدام الإحصائي (M49)".⁵⁴

ستقتصر ترجمات المناطق المدرجة في القائمة المذكورة أعلاه على اللغات المحددة في تلك القائمة. وسيتم تحويل أسماء المناطق التي لا تتوافق مع إطار عمل الأحرف المسموح بها في DNS إلى علامات DNS تحتوي فقط على أحرف وأرقام وواصلات كما هو موضح في قواعد إنشاء العلامات لمنطقة الجذر (RZ-LGR).⁵⁵

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

عندما يتم تطبيق قاعدة الـ60% وتكون المناطق مشتركة في القائمتين، فإن التركيبة الإقليمية الواردة في "رموز البلدان أو المناطق القياسية للاستخدام الإحصائي (M49)" لها الأسبقية.

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

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

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

يقع على عاتق مقدم الطلب مسؤولية ما يلي:

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

• تحديد الحكومات أو السلطات العامة ذات الصلة والتشاور معها.

• تحديد مستوى الدعم الحكومي المطلوب.

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

إن شرط تضمين وثائق الدعم أو عدم الاعتراض على طلبات معينة لا يمنع أو يعفي الطلبات من أن تكون موضوع اعتراضات على أسس مجتمعية (انظر القسم 4.5.1.4 سبب الاعتراض: المجتمع لا يزال من الممكن رفض الطلبات إذا نجحت الاعتراضات التي تدعي وجود معارضة كبيرة من المجتمع المستهدف.

7.5.2 متطلبات الوثائق

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

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

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

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

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

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

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

7.5.3 معالجة الأسماء الجغرافية

7.5.3.1 تحديد الأسماء الجغرافية

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

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

7.5.3.2 مراجعة الأسماء الجغرافية

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

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

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

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

يجوز لهيئة GNP التواصل مع الكيان المُوقع على الخطاب للتأكد من نيته وفهمه للشروط التي يتم بموجبها تقديم الدعم أو عدم الاعتراض على الطلب.

7.5.3.2.1 التقييم الموسع لمراجعة الأسماء الجغرافية

ستكون مراجعة الأسماء الجغرافية مؤهلة للتقييم الموسع في الحالات التالية:

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

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

7.6 تقييم سلسلة المتباين

تعتبر سلسلة المتباين "نفس" سلسلة gTLD الرئيسية المقدم عليها أو gTLD المتواجدة حالياً ("السلسلة الأساسية") وذلك من قبل المجتمع المستخدِم لنفس الحروف الأبجدية كما هو محدد في قواعد إنشاء العلامات لمنطقة الجذر (RZ-LGR).⁵⁹ تحدد مجموعة القواعد الموجودة في RZ-LGR نطاقات المستوى الأعلى الصالحة وسلاسل المتباينات الخاصة بها.⁶⁰ ويجب على مقدم الطلب الذي يسعى للحصول على سلسلة متباين قابلة للتخصيص واحدة أو أكثر لاسم النطاق المدول الأساسي المطلوب أو نطاق gTLD الحالي أن يقدم مبررًا لضرورة كل سلسلة متباين. وسيتم تقييم هذا التبرير من قِبل لجنة تستخدم معيارًا عامًا للمعقولية استنادًا إلى المعايير التالية، في سياق نطاق IDN gTLD الأساسي المطلوب أو نطاق gTLD الحالي:

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

2. تعرف سلسلة المتباين على أنها مكافئة من قِبل مجتمع المستخدمين المقصودين.

3. المنافع ومجتمعات المستخدمين الذين سوف يستفيدون من إدخال سلسلة المتباينات المقدم عليها.

4. الخطوات التي سيتخذها مقدم الطلب لتقليل التعقيدات التشغيلية والإدارية لنطاقات متباين gTLD وأسماء نطاقات المتباين الناتجة عنها والتي تؤثر على أمناء السجلات أو البائعين أو المسجلين.

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

ويجب على مقدم الطلب استيفاء جميع المعايير لكل سلسلة من سلاسل المتباينات المقدم عليها للمتابعة والمضي قدماً في البرنامج. تؤثر نتيجة تقييم أي سلسلة لمتباين مقدم عليها على نتيجة تقييم IDN الأساسي المقدم عليه أو أي سلسلة متباين أخرى مقدم عليها في الطلب.

القدرة على إدارة سلاسل المتباينات المقدم عليها مع IDN الأساسي المقدم عليه أو نطاق gTLD الحالي سيتم تقييمها من المنظور الفني والتشغيلي، كما هو موضح في دليل موفر خدمة السجل RSP.⁶¹

7.6.1 متطلبات الطلب الإضافية لسلاسل المتباين

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

فيما يتعلق بأنواع الطلبات المتخصصة الثلاثة التالية:

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

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

• يجب على مقدم الطلب للحصول على اسم نطاق IDN كنطاق Brand. وسلاسل المتباينات الخاصة به أن يقدم دليلًا على أن السلسلة الأساسية وسلاسل المتباين المقدم عليها متطابقة مع العلامات التجارية المسجلة المملوكة والمستخدمة من قِبل مقدم الطلب. وهذا يعني أن أي سلسلة متباين يتم التقديم عليها يجب أن تُظهر أيضًا دليلًا على أنها متطابقة مع العلامات التجارية المسجلة المملوكة والمستخدمة من قِبل مقدم الطلب. راجع القسم 7.3 تقييم أهلية Brand TLD.

7.6.2 طلب الحصول على سلاسل متباين من قائمة الأسماء المحجوزة

عندما يكون الاسم المحجوز هو السلسلة الأساسية، يُسمح فقط للمنظمة المرتبطة بهذا الاسم المحجوز (راجع القسم 7.2.2 الأسماء المحجوزة) بالتقدم بطلب للحصول على سلاسل المتباينات الخاصة به في المستوى الأعلى. وعلى الرغم من أن سلسلة المتباين لا تحتاج إلى أن تكون اسمًا محجوزًا، يتم إنشاؤها كسلسلة متباين للاسم المحجوز باستخدام RZ-LGR. ولا يمكن أن يسبق طلب الحصول على سلاسل متباينات لاسم محجوز طلب الحصول على الاسم المحجوز، الذي يعمل كسلسلة أساسية لتوليد سلاسل المتباينات.

7.6.3 الاعتماد الإضافي لسلاسل المتباين

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

ومع ذلك، إذا تم استبعاد أي من سلاسل المتباينات المقدم عليها ولم تتمكن من المتابعة والمضي قدماُ في الاجراءات، فيجب على مقدم الطلب تقديم التماس تغيير الطلب (ACR) لإزالة سلسلة المتباينات المقدم عليها والتي تم استبعادها حتى يمكن للطلب أن يتقدم للأمام. وإذا كان التماس ACR ناجحًا، فسيبقى من الممكن المضي قدمًا في طلب الحصول على اسم IDN الأساسي المعني المقدم عليه وأي سلاسل متباين متبقية مقدم عليها والتي تكون غير مؤهلة.

7.7 تضارب الأسماء

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

ولتقييم وتخفيف مخاطر تضارب الأسماء بين نظام اسم النطاق DNS العالمي وأنظمة التسمية الأخرى، نفذت ICANN إطار عمل إدارة مخاطر تضارب الأسماء، بناءً على التوصيات الواردة في تقرير دراسة مشروع تحليل تضارب الأسماء الثاني،⁶⁴ وفقًا لتوجيهات مجلس إدارة ICANN في 7 سبتمبر/أيلول 2024.⁶⁵

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

7.7.1 وصول مقدم الطلب إلى بيانات المخاطر الممتدة

قبل فتح فترة تقديم الطلبات، سوف تنشر ICANN مجموعات البيانات المتعلقة بجميع السلاسل التي تتجاوز حدًا معينًا من حجم الاستعلام، والتي قد تساعد مقدمي الطلبات على تقييم مخاطر تضارب الأسماء.

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

من بين حوالي 1400 سلسلة فريدة تم التقدم بطلب للحصول عليها خلال الجولة السابقة، تم تقييم ثلاثة فقط (CORP.، وHOME.، وMAIL.) على أنها عالية المخاطر.⁶⁶ ومع ذلك، لا ينبغي لمقدمي الطلبات أن يفترضوا أنه إذا أشارت مجموعات البيانات إلى حجم منخفض من حالات تضارب الأسماء، فسيتم تقييم السلسلة على أنها آمنة للتفويض.

7.7.2 التقييم الأولي لتضارب الأسماء

ستخضع كل سلسلة يتم التقديم عليها وأي سلاسل متباينة قابلة للتخصيص للتقييم الأولي لتضارب الأسماء باستخدام مجموعات البيانات ذات الصلة التي يمكن الحصول عليها، على سبيل المثال، من سجلات خادم الجذر، وسجلات خادم DNS التكراري، وباستخدام كل من حجم وتنوع الاستعلامات، والأصول، وأسماء الاستعلامات (العلامات)، وأنواع الاستعلام؛ مؤشرات جودة تقنيات المعرّف ( ⁶⁷(ITHI؛ والأدلة النوعية التي يمكن أن تساعد في استنتاج شدة الضرر. والغرض من هذا التقييم، الذي سيتم إجراؤه وفقًا لإجراءات التشغيل⁶⁸ لتقييم تضارب الأسماء الأولي، هو التعرف بشكل أولي على السلاسل عالية الخطورة.

وسيتم إجراء التقييم الأولي بعد يوم تأكيد السلسلة (القسم 3.6)، وسيتم الإشراف عليه من قِبل فريق المراجعة الفنية (TRT). وستقوم ICANN بنشر تقرير التقييم الأولي الذي يصف التقييم ومنهجيته ونتائجه، بمجرد اكتماله. وسيتم تخصيص فترة للتعليق العام على التقرير للسماح للمجتمع بتقديم تعليقاته حول المنهجية والنتائج.

7.7.3 التفويض المؤقت والتقييم النهائي

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

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

أثناء التفويض المؤقت، سيتم تفويض سلسلة gTLD المقدم عليها إلى خوادم أسماء DNS التي تديرها ICANN وذلك لجمع البيانات حول حجم وطبيعة حركة DNS لهذه السلسلة. وسيتم استخدام أربع طرق تقييم مختلفة للإخطار وتوليد البيانات أثناء التفويض المؤقت. تم توضيح هذه في الملحق 2 من تقرير دراسة مشروع تحليل تضارب الأسماء الثاني وهي: عدم الانقطاع (NI)؛ الانقطاع المتحكم فيه (CI)؛ الانقطاع المرئي (VI)؛ والانقطاع المرئي والإخطار (VIN). وسيتم الإشراف على التقييم من قِبل فريق TRT، الذي يتكون من خبراء داخليين من أقسام ICANN ذات الصلة. وسيحدد فريق TRT، على أساس كل حالة على حدة، الطريقة أو الطرق التي سيتم استخدامها لكل تقييم.

سيقوم فريق TRT بتقييم البيانات التي تم جمعها أثناء التفويض المؤقت، والتي تتضمن استعلامات DNS إلى خوادم TLD، وتنوع الاستعلامات، والأصول، وأسماء الاستعلامات (العلامات)، وأنواع الاستعلامات، وما إلى ذلك، بالإضافة إلى البيانات التي تم جمعها باستخدام طرق التقييم، لتحديد ما إذا كانت السلسلة ستكون:

1. مصنفة على أنها عالية الخطورة، وفي هذه الحالة سيتم إزالة السلسلة على الفور من منطقة الجذر.

2. مؤهلة للمضي قدمًا في بقية مراحل معالجة الطلب.

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

7.7.4 قائمة سلاسل التضارب

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

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

7.7.5 تقييم خطة التخفيف من مخاطر تضارب الأسماء عالية الخطورة

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

يجب على مقدمي الطلبات تقديم التماس تغيير الطلب لإضافة خطة التخفيف في غضون 90 يومًا (قابلة للتمديد بناءً على طلب بأسس معقول حتى 180 يومًا) من (أ) تعيين السلسلة على أنها عالية المخاطر أو في موضع خلاف وتنافس، (ب) تسوية الخلافات. وإذا لم يتم تقديم التماس تغيير الطلب خلال هذا الإطار الزمني، فسوف تنتقل حالة الطلب إلى "منتهي". انظر القسم 3.9 حالات الطلب.

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

يجب أن تتضمن خطة التخفيف التي يقدمها مقدم الطلب ما يلي على الأقل:

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

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

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

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

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

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

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

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

7.7.5.1 الطعن في تقييم خطة التخفيف

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

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

يكون الموعد النهائي لتقديم الطعن خلال 21 يومًا من تاريخ استلام مقدم الطلب إشعارًا بقرار التقييم الذي يسعى إلى الطعن عليه. وستقوم لجنة الطعن بإبلاغ نتيجة إجراءات الطعن في غضون 30 يومًا من تقديم مقدم الطلب لمثل هذا الطعن.

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

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

7.7.6 التفاعل مع سلاسل المتباين

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

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

7.8 التزامات المصلحة العامة، والتزامات السجل الطوعية، وسياسات التسجيل المجتمعية

إن دور ICANN هو ضمان التشغيل المستقر والآمن لأنظمة المعرفات الفريدة للإنترنت.⁷² ويدعم برنامج نطاقات gTLD الجديدة هذا من خلال العديد من إجراءات الحماية المضمنة، بما في ذلك التقييم الشديد لسلاسل gTLD المقدم عليها، والطلبات، والمشغلين، وإنفاذ الامتثال لاتفاقية السجل.

تعد التزامات المصلحة العامة (PIC)، وبشكل خاص التزامات المصلحة العامة الإلزامية (انظر القسم 7.8.1) وضمانات التزامات المصلحة العامة PIC (انظر القسم 7.8.2)، أحد أشكال الحماية المهمة المضمنة في برنامج نطاقات gTLD الجديدة. وتمثل التزامات المصلحة العامة هذه التزامات ملزمة بموجب اتفاقية السجل في المواصفة 11، وتعمل ICANN على إنفاذ الامتثال لها. إن التزامات المصلحة العامة PIC الإلزامية وضمانات PICs موحدة في جميع اتفاقيات السجل ذات الصلة، وتم تنفيذها استجابة لمخاوف اللجنة الاستشارية الحكومية (GAC) بشأن الطلبات المقدمة في جولة الطلبات لعام 2012. وتشمل القضايا الأساسية التي تمت معالجتها حماية المستهلك، وحقوق الملكية الفكرية، والقطاعات السوقية المنظمة مثل القطاع المالي والصحي والجمعيات الخيرية.⁷³

بالإضافة إلى التزامات المصلحة العامة، يُسمح لمقدم الطلب باقتراح واحد أو أكثر من التزامات السجل الطوعية (RVC) (انظر القسم 7.8.3) لتوفير ضمانات إضافية فيما يتعلق بتشغيل سلسلة gTLD المقدم عليها. يجوز لمقدم الطلب أن يقترح التزامات السجل الطوعية RVC لمعالجة المخاوف التي لم تتم بعد معالجتها من خلال التزامات المصلحة العامة الإلزامية أو ضماناتها أو من خلال وسائل أخرى. كما هو موضح بمزيد من التفصيل في القسم 7.8.3 التزامات السجل الطوعية، تخضع التزامات السجل الطوعية المقترحة لعملية تقييم منفصلة، وهي تقييم التزامات السجل (RCE). ستوافق ICANN على التزامات السجل الطوعية المقترحة فقط إذا: (1) كانت التزامات السجل الطوعية تلبي معايير تقييم التزامات السجل (انظر القسم 7.8.3.3)؛ و(2) كان يتفق كل من مقدم الطلب وICANN على أن التزامات السجل الطوعية المقترحة، إذا تم تضمينها في اتفاقية السجل، ستكون قابلة للتنفيذ بموجب لوائح ICANN وكأمر عملي. كما هو الحال مع التزامات المصلحة العامة، فإن التزامات السجل الطوعية (بمجرد الموافقة عليها ودمجها في اتفاقية السجل) هي التزامات ملزمة في مواصفة اتفاقية السجل الأساسية 11.⁷⁴

تخضع كل من التزامات المصلحة العامة والتزامات السجل الطوعية لإجراءات تسوية الخلافات الخاصة بالتزامات المصلحة العامة (PICDRP).⁷⁵

كما هو مفصل في القسم 7.1 أنواع السلاسل والطلبات، يمكن لمقدم الطلب اختيار تعيين سلسلة gTLD المقدم عليها كنطاق gTLD مجتمعي. إذا حدد مقدم الطلب سلسلة gTLD المقدم عليها باعتبارها نطاق gTLD مجتمعي، فيجب عليه اقتراح سياسات التسجيل المجتمعية لاتفاقية السجل (انظر القسم 7.8.4) لتضمينها في اتفاقية السجل التي سيُعمل بها والتي سيتم تقييمها من قبل ICANN من خلال تطبيق معايير تقييم التزامات السجل (انظر القسم 7.8.3.3).

7.8.1 التزامات المصلحة العامة الإلزامية

التزامات المصلحة العامة الإلزامية مضمنة في كل اتفاقية من اتفاقيات السجل. تتطلب التزامات المصلحة العامة الإلزامية من كل مشغل سجل تنفيذ تدابير لحماية مسجلي نطاقات gTLD ومستخدمي الإنترنت على نطاق أوسع، وتتضمن التزامات تتعلق بما يلي: التخفيف من الأنشطة المسيئة؛ والفحوصات الأمنية؛ والشفافية في التشغيل. وتم تضمين التزامات المصلحة العامة الإلزامية في القسم 3 (أ)-(د) من المواصفة 11 من اتفاقية السجل الأساسية (انظر الملحق 4)، وهي:

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

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

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

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

لمزيد من المعلومات حول السلاسل العامة، راجع القسم 3.1.7 النطاقات العامة المغلقة/السلاسل العامة الحصرية.

7.8.2 ضمانات التزامات المصلحة العامة

تعتبر ضمانات التزامات المصلحة العامة أحكامًا مطلوبة في بعض اتفاقيات السجل، بالإضافة إلى التزامات المصلحة العامة الإلزامية المضمنة في جميع اتفاقيات السجل.

وتصنّف ICANN نطاقات gTLD التي تحتاج إلى ضمانات PIC إلى أربع مجموعات حسب المخاطر:

• القطاعات المنظمة/متطلبات الدخول المفتوحة: سلاسل تستدعي ثقة المستهلك ولكن مع مخاطر متزايدة

• ات عالية التنظيم/متطلبات الدخول المغلقة: سلاسل مرتبطة بالصناعات التي تتطلب ترخيصًا أو اعتمادًا

• احتمالية التعرض للتنمر/التحرش عبر الإنترنت: سلاسل يمكن أن تسهل التحرش.

• الوظائف الحكومية المتأصلة: سلاسل مرتبطة بنطاقات حكومية.

راجع معلومات أكثر تفصيلاً وأمثلة مدرجة في الجدول ضمن القسم 7.8.2.2 ضمانات التزامات المصلحة العامة المعمول بها حسب فئة السلسلة.

إذا قررت ICANN أثناء التقييم أن سلسلة gTLD المقدم عليها تندرج ضمن واحدة أو أكثر من الفئات الموضحة في القسم 7.8.2.2 ضمانات التزامات المصلحة العامة المعمول بها حسب فئة السلسلة، فيجب تضمين ضمانات التزامات المصلحة العامة المعمول بها (انظر القسم 7.8.2.3) في المواصفة 11 من اتفاقية السجل الأساسية المعمول بها دون تعديل.⁷⁷

تم وضع وتنفيذ ضمانات التزامات المصلحة العامة استجابةً لمشورة إجماع الجنة GAC في بيان ICANN46 الختامي الصادر في بكين⁷⁸ وقرار مجلس إدارة ICANN⁷⁹ اللاحق خلال جولة 2012 من برنامج نطاقات gTLD الجديدة.⁸⁰

7.8.2.1 تحديد مجموعة السلاسل

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

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

راجع القسم 4.1 التعليقات على الطلبات للحصول على مزيد من المعلومات حول فترات التعليق على الطلب.

7.8.2.2 ضمانات التزامات المصلحة العامة PIC المعمول بها حسب فئة السلسلة

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

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

الجدول 2-7: طار عمل ضمانات PIC

7.8.2.3 ضمانات PIC

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

الجدول 2-7: أنواع ضمانات PIC

7.8.3 الالتزامات الطوعية للسجل

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

إن قرار مقدم الطلب باقتراح التزامات السجل الطوعية يكون طوعيًا في العادة، باستثناء القرارات التي تعترف بها ICANN لحل اعتراض أو لمعالجة مشورة إجماع GAC (انظر الشرح في القسم 7.8.3.2.3.1 الموقف 1: التعهدات المقدمة من أجل التغلب على الاعتراضات أو مشورة إجماع لجنة GAC وستكون هذه الالتزامات ملزمة تعاقديًا إذا تمت الموافقة عليها وتضمينها في اتفاقية السجل. وقد تختلف التزامات السجل الطوعية RVC، مما قد يؤدي إلى زيادة الالتزامات المتعلقة بالمصلحة العامة أو تدوين التزامات أصحاب المصلحة. يمكن أيضًا لالتزامات RVC وضغ ضمانات قد تساعد في التغلب على مخاوف الطرف الثالث بشأن سلسلة gTLD المقدم عليها أو الطلب. على سبيل المثال، يمكن لمقدمي الطلبات اقتراح التزامات RVC ردًا على الاعتراضات أو التحذيرات المبكرة لأعضاء GAC أو مشورة إجماع GAC أو التعليقات على الطلب أو القضايا الأخرى التي قد تؤثر سلبًا على عملية تقييم الطلب. راجع القسم 3.8 التماسات تغيير الطلب والوحدة 4 مدخلات المجتمع والاعتراضات والاستئنافات لمزيد من التفاصيل حول هذه المواضيع.

يجوز لمقدم الطلب تضمين التزامات RVC المقترحة في طلبه أو طلب إضافة التزام لاحقًا من خلال عملية التماس تغيير الطلب (انظر القسم 3.8)، التي تتضمن فترة التعليق على الطلب وشروط أخرى.

ستظهر جميع التزامات RVC المقترحة المقدمة مع الطلب أو كالتماس تغيير طلب في قسم الطلبات العامة، التي يمكن الوصول إليها على موقع ويب برنامج نطاقات gTLD الجديدة⁸⁶، وستكون متاحة أمام الجميع للاطلاع عليها والتعليق خلال فترة التعليقات على الطلبات (انظر القسم 4.1 التعليقات على الطلبات).

7.8.3.1 العوامل التي يجب مراعاتها قبل اقتراح التزامات RVC

قبل اتخاذ قرار اقتراح التزامات السجل الطوعية RVC، يُحث مقدمي الطلبات على مراجعة لوائح ICANN؛ واتفاقيات ICANN ذات الصلة، بما في ذلك على سبيل المثال لا الحصر اتفاقية السجل واتفاقية اعتماد أمين السجل (RAA)؛ والسياسات القائمة على الإجماع والسياسات المؤقتة في ICANN. ويجب على مقدمي الطلبات وأي أطراف ثالثة تثير مخاوف بشأن أي طلبات أن تفكر فيما إذا كانت الأحكام الموحدة السابقة قادرة على توفير ضمانات كافية لسلسلة gTLD المقدم عليها، لتجنب الحاجة إلى تقييم وتنفيذ التزام طوعي للسجل مخصص.⁸⁷

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

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

لن تتم الموافقة على أي التزام طوعي للسجل RVC مقترح غير متوافق مع اللوائح والسياسات والاتفاقيات في ICANN، كما هو موضح في القسم 7.8.3.3 معايير تقييم التزامات السجل.

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

7.8.3.2 تقييم التزامات السجل

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

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

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

يُطلب من مقدم الطلب الذي يقدم التزامات RVC أو سياسات التسجيل المجتمعية دفع مبلغ ثابت لمرة واحدة لتغطية تكلفة تقييم التزامات السجل. للحصول على تفاصيل حول الرسوم المرتبطة بـRCE، راجع القسم 3.3.2 التقييمات المشروطة.

7.8.3.2.1 يجب على مقدمي الطلبات تحديد أغراض التزام RVC المقترح

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

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

7.8.3.2.2 قاعدة عامة: تقييم التزامات السجل للالتزامات الطوعية للسجل RVC المقترحة لا يؤثر على تقدم الطلب

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

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

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

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

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

الاستثناء 7.8.3.2.3: تقييم التزامات السجل للالتزامات الطوعية للسجل RVC المقترحة تؤثر على تقدم الطلب

يمكن لنتيجة تقييم التزامات السجل لالتزام RVC المقترح أن تؤثر على تقدم الطلب فقط في سيناريوهين. راجع القسم 3.9 حالات الطلب لمعرفة ما يمكن توقعه عندما يُعتبر الطلب غير قادر على المتابعة والتقدم.

لقسم 7.8.3.2.3.1 الموقف 1: الالتزامات التي تم اتخاذها للتغلب على الاعتراضات أو مشورة إجماع GAC

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

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

ويجب أن تتم الموافقة على الالتزام الطوعي للسجل من قِبل ICANN عبر تقييم التزامات السجل لحل الاعتراض أو للعمل على مشورة إجماع GAC. وبدون هذه الموافقة، لا يمكن المضي قدمًا في الطلب.⁹¹ انظر القسم 4.5.8.13 الاعتراضات والالتزامات الطوعية للسجل والقسم 4.3.3 مشورة إجماع GAC والالتزامات الطوعية للسجل.

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

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

7.8.3.2.3.2 الموقف 2: التماس تغيير الطلب المطلوب بعد رفض الالتزام الطوعي للسجل المقترح

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

في حالة عدم وجود ظروف استثنائية، إذا لم يقدم مقدم الطلب التماس تغيير الطلب في غضون 30 يومًا من الإخطار بأن الالتزام الطوعي للسجل المقترح لم ينجح في اجتياز التقييم، فلن يُسمح بالمضي قدمًا في الطلب.

7.8.3.2.4 توقيت تقييم التزامات السجل وإخطار النتيجة

فيما يتعلق بتوقيت تقييم التزامات السجل للالتزامات الطوعية للسجل المقترحة في ظل الموقف 1: الالتزامات التي تم اتخاذها للتغلب على الاعتراضات أو مشورة إجماع GAC (انظر القسم 7.8.3.2.3.1) وسياسات التسجيل المجتمعية المقترحة (انظر القسم 7.8.4) المقدمة من مقدمي الطلبات المجتمعيين المشاركين في تقييم أولوية المجتمع (CPE)، سيتم إجراء تقييم التزامات السجل في أقرب وقت ممكن بعد استلام ICANN للرسوم المطبقة. وتعترف ICANN بأهمية إجراء RCE في الوقت المناسب لضمان إمكانية استمرار العمليات التي تعتمد على ذلك بدون تأخير.

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

وفي غياب أي ظروف استثنائية، فإن الجدول الزمني المقدر لـRCE يتراوح بين 60 إلى 90 يومًا.

وستقوم ICANN بنشر وتحديث نتائج RCE لجميع الالتزامات الطوعية للسجل وسياسات التسجيل المجتمعية المقدمة بشكل منتظم على موقع ويب برنامج نطاقات gTLD الجديدة وإخطار مقدمي الطلبات المعنيين بالنتائج.⁹²

7.8.3.3 معايير تقييم التزامات السجل

سترفض ICANN أي التزام طوعي للسجل مقترح لا يتوافق مع لوائح ICANN.⁹³ انظر المعيار رقم 5 في الجدول أدناه للحصول على التفاصيل.

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

كل التزام في سياسة التسجيل المجتمعية (انظر القسم 7.8.4) والمقترح تضمينه في اتفاقية السجل المعمول بها يجب أيضًا أن يستوفي جميع معايير تقييم التزامات السجل حتى تتم الموافقة عليه.

راجع التعليمات الخاصة بالأسئلة 150-155 في مجموعة الأسئلة 7 نطاقات gTLD المجتمعية ومجموعة الأسئلة 11 التزامات السجل الطوعية (RVC) في الملحق 1 أسئلة الطلب للحصول على المتطلبات التفصيلية التي توجه نهج صياغة سياسات التسجيل المجتمعية المقترحة والتزامات السجل الطوعية التي سيتم تقييمها من خلال RCE.

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

الجدول 3-7: معايير تقييم التزام RVC

7.8.3.4 إضافات الالتزام الطوعي للسجل وتغييراته وإزالته

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

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

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

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

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

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

كما هو الحال مع الالتزامات الطوعية للسجل المقترحة للتضمين في اتفاقية السجل، يجب تقييم سياسة التسجيل المجتمعية التي يقترحها مقدم الطلب للتضمين في اتفاقية السجل المعمول بها وفقًا لمعايير RCE (انظر القسم 7.8.3.3). وستؤثر نتائج التقييم على ما إذا كان طلب المجتمع يمكن أن يمضي قدمًا. وعلى وجه التحديد، يجب على مقدم الطلب أن يكون لديه سياسات تسجيل مجتمعية معتمدة كشرط أساسي حتى يتمكن طلبه من المشاركة في تقييم أولوية المجتمع (CPE)، وهو خيار متاح فقط لطلبات المجتمع لحل الخلاف.⁹⁹ ومع ذلك، فإن الموافقة مطلوبة ليس فقط لطلب المجتمع للمشاركة في CPE، ولكن أيضًا للمضي قدمًا في عملية التقديم بعد تقييم RCE. بعبارة أخرى، إذا لم تكن هناك سياسات تسجيل مجتمعية يمكن أن توافق عليها ICANN لإدراجها في اتفاقية السجل، فلن يتمكن طلب المجتمع من التقدم – بغض النظر عما إذا كان في حالة خلافات أو ما إذا كان مقدم الطلب يختار المشاركة في تقييم أولوية المجتمع CPE.¹⁰⁰

وسيتم تضمين سياسة تسجيل المجتمع التي تلبي معايير RCE (انظر القسم 7.8.3.3) في اتفاقية السجل المعمول بها إذا تم المضي قدمًا في تفويض السلسلة المقدم عليها. راجع التعليمات الخاصة بالأسئلة 150-155 في مجموعة الأسئلة 7 نطاقات gTLD المجتمعية في الملحق 1 أسئلة الطلب للحصول على المتطلبات التفصيلية التي توجه نهج صياغة سياسات التسجيل المجتمعية المقترحة التي سيتم تقييمها من خلال RCE. وكما هو الحال مع التزامات المصلحة العامة والالتزامات الطوعية للسجل، فإن سياسة التسجيل المجتمعية المعتمدة ستكون خاضعة لإشراف فريق الامتثال التعاقدي في ICANN. وتخضع سياسات التسجيل المجتمعية المضمنة في اتفاقية السجل لإجراءات تسوية الخلافات القائمة حول قيود التسجيل (RRDRP) وإجراءات طلبات تغيير gTLD المجتمعية.¹⁰¹

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

7.8.5 إنفاذ ICANN

ستقوم ICANN بفرض الامتثال لالتزامات المصلحة العامة والالتزامات الطوعية للسجل وسياسات التسجيل المجتمعية التي تم تقييمها والموافقة عليها وفقًا لمعايير RCE (انظر القسم 7.8.3.3) والمضمنة في اتفاقية السجل مثل أي التزامات تعاقدية أخرى. ويمكن استخدام PICDRP لمعالجة الشكاوى المزعومة التي تفيد بأن مشغل السجل قد لا يمتثل لواحد أو أكثر من متطلبات التزامات المصلحة العامة أو الالتزامات الطوعية للسجل الخاصة به. ويمكن استخدام RRDRP لمعالجة الظروف التي يزعم فيها أن مشغل نطاق gTLD المجتمعي ينحرف عن سياسات التسجيل المجتمعية الموضحة في اتفاقية السجل. راجع القسم 1.2.17 إجراءات حل الخلافات بعد التفويض للحصول على مزيد من التفاصيل حول PICDRP وRRDRP.

7.9 مراجعة موفر خدمة السجل

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

7.10 تقييم تشابه السلاسل

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

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

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

7.10.1 نطاق تقييم تشابه السلاسل

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

لكل طلب، سيتم مقارنة السلسلة الأساسية (إذا لم يتم تفويضها بعد) وجميع سلاسل المتباينات القابلة للتخصيص¹⁰⁸ في مجموعة سلاسل المتباينات الخاصة بها مع ما يلي:¹⁰⁹

• نطاقات gTLD المفوضة حاليًا وكل سلاسل المتباينات القابلة للتخصيص والمحظورة الخاصة بها.

• سلاسل gTLD التي تم التقدم بطلب للحصول عليها في جولات gTLD السابقة والتي هي قيد المعالجة،¹¹⁰ وكل سلاسل المتباينات القابلة للتخصيص والمحظورة.

• نطاقات ccTLD الحالية التي تم تقييمها¹¹¹ أو تفويضها¹¹² بنجاح وجميع سلاسل المتباينات القابلة للتخصيص والمحظورة الخاصة بها.

• السلاسل المطلوبة حاليًا كنطاقات IDN ccTLD¹¹³ (انظر القسم 7.10.3.3 السلاسل المشابهة لنطاقات ccTLD التي تم تقييمها بنجاح أو تفويضها أو سلاسل المتباينات الخاصة بها) وكل سلاسل المتباينات القابلة للتخصيص والمحظورة.

• نطاقات gTLD الأخرى المقدم عليها في جولة الطلبات الحالية وكل سلاسل المتباينات القابلة للتخصيص والمحظورة الخاصة بها.

• مجموعة فرعية من الأسماء المحظورة¹¹⁴ وكل سلاسل المتباينات القابلة للتخصيص والمحظورة الخاصة بها.

• جميع سلاسل ASCII الأخرى المكونة من حرفين¹¹⁵ وجميع سلاسل المتباينات القابلة للتخصيص والمحظورة.

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

• نطاقات gTLD المفوضة الحالية وكل سلاسل المتباينات القابلة للتخصيص الخاصة بها.

• السلاسل التي تم التقدم بطلب للحصول عليها في الجولات السابقة من برنامج نطاقات gTLD الجديدة والتي لا تزال قيد المعالجة،¹¹⁶ وكل سلاسل المتباينات القابلة للتخصيص الخاصة بها.

• نطاقات ccTLD الحالية والتي تم تقييمها أو تفويضها بنجاح وكل سلاسل المتباينات القابلة للتخصيص الخاصة بها.

• السلاسل المطلوبة حاليًا كنطاقات IDN ccTLD (انظر القسم 7.10.3.3 السلاسل المشابهة لنطاقات ccTLD التي تم تقييمها بنجاح أو تفويضها أو سلاسل المتباينات الخاصة بها) وكل سلاسل المتباينات القابلة للتخصيص.

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

• مجموعة فرعية من الأسماء المحظورة¹¹⁷ وكل سلاسل المتباينات القابلة للتخصيص الخاصة بها.

• جميع سلاسل ASCII الأخرى المكونة من حرفين وجميع سلاسل المتباينات القابلة للتخصيص الخاصة بها.

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

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

الجدول 4-7: نطاق المقارنات التي أجرتها لجنة تقييم تشابه السلاسل

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

7.10.2 منهجية تقييم تشابه السلاسل

7.10.2.1 نفس السلاسل الأساسية أو سلاسل المتباين

يتم النظر في كل من أشكال الأحرف الكبيرة والصغيرة من أحرف ASCII، ويمكن استخدام أي تبديل للحالة في سلسلة لتقييم تشابه السلاسل، على سبيل المثال، "EXAMPLE" أو "Example" أو "example."

سيتم وضع علامة على الطلبات المقدمة من مقدمي طلبات مختلفين باستخدام سلاسل من نفس مجموعة سلاسل المتباين على أنها متشابهة بواسطة لجنة تقييم تشابه السلاسل.

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

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

7.10.2.3 إرشادات تقييم تشابه السلاسل

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

7.10.2.4 عملية لجنة تقييم تشابه السلاسل

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

ستقوم لجنة تقييم تشابه السلاسل بإجراء تقييم تشابه السلاسل بالخطوات التالية:

1. تجميع قوائم السلاسل للمقارنة:

   1. نطاقات gTLD الحالية

   2. السلاسل المقدم عليها في الجولات السابقة لبرنامج نطاقات gTLD الجديدة وما زالت قيد المعاملة

   3. نطاقات ccTLD الحالية

   4. نطاقات ccTLD المطلوبة

   5. سلاسل أخرى مطلوبة

   6. الأسماء المحظورة

   7. سلاسل ASCII المكونة من حرفين

2. النظر في جميع سلاسل المتباين القابلة للتخصيص من السلاسل المذكورة أعلاه باستخدام RZ-LGR.

3. النظر في جميع سلاسل المتباينات المحظورة للسلاسل المذكورة أعلاه باستخدام RZ-LGR الموجودة في نفس النص (سلاسل نصية مختلطة لنصوص Kana وHan وكما يسمح بها RZ-LGR).

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

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

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

7. تحديد وتوثيق (مع الحيثيات والأسباب) نتائج تقييم تشابه السلاسل.

7.10.3 نتائج تقييم تشابه السلاسل

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

1. سلسلة متشابهة بصريًا مع نطاق gTLD الحالي أو سلاسله المتباين.

2. سلسلة متشابهة بصريًا مع سلسلة تم التقديم عليها في الجولات السابقة من برنامج نطاقات gTLD الجديدة ولا تزال في مرحلة المعالجة هي أو سلاسل المتباين الخاص بها.

3. سلسلة متشابهة بصريًا مع نطاق ccTLD الحالي أو سلاسل المتباين.

4. سلسلة متشابهة بصريًا مع نطاق IDN ccTLD المقدم عليه أو سلاسل المتباين الخاصة به.

5. سلسلة مماثلة لسلسلة مطلوبة أخرى أو السلاسل المتباينة الخاصة بها.

6. سلسلة متشابهة بصريًا مع سلسلة مطلوبة أخرى أو السلاسل المتباينة الخاصة بها.

7. سلسلة متشابهة بصريًا مع اسم محظور أو سلاسله المتباينة.

8. سلسلة متشابهة بصريًا مع سلسلة ASCII المكونة من حرفين أو سلاسلها المتباينة.

9. السلسلة لا تشبه بصريًا أيًا من الفئات المدرجة.

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

جميع السلاسل من مجموعة السلاسل المتباينة، والتي تتكون من السلسلة الأساسية وكل سلاسل المتباينات القابلة للتخصيص والمحظورة، في نفس نتيجة تقييم تشابه السلاسل:

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

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

7.10.3.1 سلاسل متشابهة بصريًا مع نطاقات gTLD الحالية أو سلاسل المتباين الخاصة بها

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

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

7.10.3.2 سلاسل متشابهة بصريًا مع السلاسل ومتبايناتها التي لا تزال قيد المعالجة من الجولات السابقة لبرنامج نطاقات gTLD الجديدة

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

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

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

لا يجوز لمقدم طلب جديد التقدم بطلب للحصول على سلسلة هي جزء من نفس مجموعة سلاسل المتباين مثل السلسلة من الجولة السابقة لبرنامج نطاقات gTLD الجديدة الذي لا يزال قيد المعاملة.

7.10.3.3 سلاسل متشابهة بصريًا مع نطاقات ccTLD التي تم تقييمها بنجاح أو تفويضها أو سلاسل المتباين الخاصة بها

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

7.10.3.4 سلاسل متشابهة بصريًا مع نطاق IDN ccTLD المقدم عليه

يمكن طلب سلسلة IDN ccTLD من خلال عملية المسار السريع لنطاقات IDN ccTLD أو خليفتها وعلى نحو مستمر على أساس دوري.¹¹⁸ وعملية تقديم طلب سلسلة IDN ccTLD منفصلة ومستقلة عن عملية تقديم طلب gTLD. إذا وجد أن سلسلة gTLD المقدم عليها متشابهة بصريًا مع أي نطاق IDN ccTLD¹¹⁹ مقدم عليه، فإن لجنة تقييم تشابه السلاسل ستبلغ عنها باعتبارها تعارضًا مع IDN ccTLD المقدم عليه، وبدون تشكيل مجموعة خلافات، حيث أن مجموعات الخلافات خاصة فقط بسلاسل gTLD التي يتم التقديم عليها. وستتبع ICANN النهج الموضح أدناه لحل التضارب.

إن وجدت سلسلة gTLD تم التقديم عليها متشابهة بصريًا مع IDN ccTLD المطلوب، فسوف تحدد ICANN النتيجة استنادًا إلى حالة اكتمال عمليات التقييم الخاصة بكل منها. والسيناريوهات هي كما يلي:

• سيتم اعتبار طلب gTLD الذي أكمل بنجاح جميع مراحل التقييم ذات الصلة، بما في ذلك حل الخلافات والتنافس على السلسلة، إذا كان ذلك ممكنًا، والمؤهل للدخول في اتفاقية السجل الأساسية، مكتملًا، وبالتالي لن يتم استبعاد طلب gTLD (السلسلة الأساسية وسلاسل المتباينة المقدم عليها، إن كان ذلك ممكنًا) بواسطة طلب IDN ccTLD تم تقديمه حديثًا. وسيتم إخطار مقدم طلب IDN ccTLD وفقًا لذلك.

• وسيتم اعتبار سلسلة IDN ccTLD الأساسية المطلوبة التي تم التحقق من صحتها¹²⁰ مكتملة. ولذلك، لن يتم استبعاد سلسلة IDN ccTLD هذه (سلسلة IDN ccTLD الأساسية وسلاسل المتباينات المطلوبة، إذا وجدت) من خلال طلب gTLD تم تقديمه حديثًا.

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

• عند الانتهاء بنجاح من التقييم، سيتم قبول طلب IDN ccTLD ولن تتم الموافقة على طلب gTLD.

• لم يتم تقييم IDN ccTLD المطلوب بنجاح، أو تم سحبه من قبل مقدم طلب IDN ccTLD، فيمكن لسلسلة IDN gTLD المتابعة بتقييم الطلب.

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

لا يجوز لمقدم الطلب التقدم بطلب للحصول على سلسلة gTLD التي تعد جزءًا من نفس مجموعة سلاسل المتباين الخاصة بها مثل سلسلة ccTLD تم التقديم عليها والتي تم التحقق من صحتها.

7.10.3.5 السلاسل المتطابقة أو المتشابهة بصريًا مع السلاسل ومتبايناتها المقدم عليها

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

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

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

7.10.3.6 سلاسل متشابهة بصريًا مع اسم محظور

إن وجد أن أي سلسلة أو أي من سلاسل المتباينات الخاصة بها تم التقديم عليها بأنها متشابهة بصريًا مع أي اسم محظور¹²² أو أي من سلاسل المتباينات الخاصة به، فلن يتم تمرير الطلب وتقدمه.

7.10.3.7 التشابه البصري لسلسلة مع سلسلة ASCII مكونة من حرفين

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

7.10.3.8 نتائج تقييم تشابه السلاسل

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

الجدول 5-7: نتائج طلب نطاق gTLD من عملية تقييم تشابه السلاسل الذي أجرته اللجنة

7.10.4 الطعن في تقييم تشابه السلاسل

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

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

يمكن تقديم الطعن في التقييم خلال 21 يومًا من تاريخ استلام مقدم الطلب إشعارًا بقرار تقييم تشابه السلاسل. ستقوم لجنة تقييم تشابه السلاسل بإبلاغ النتائج الناتجة عن الطعن في التقييم في غضون 30 يومًا من تقديم مقدم الطلب لمثل هذا الطعن.

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

إذا لم تجد لجنة تقييم تشابه السلاسل أي خطأ واقعي أو إجرائي أو نظامي، فحينئذٍ:

• إذا كان الطعن يعتمد على تحديد أن السلسلة المقدم عليها متشابهة بصريًا مع نطاق gTLD موجود حالياً، أو أي سلسلة تم بالفعل التقديم عليها من جولة سابقة لبرنامج نطاقات gTLD الجديدة، أو أي نطاق ccTLD حالي، أو نطاق IDN ccTLD مطلوب تم التحقق من صحته، أو أي سلسلة ASCII أخرى مكونة من حرفين، أو أي اسم محظور آخر، فلن يتم المضي قدمًا في الطلب.

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

7.10.5 الاستثناء لنطاقات Brand TLD.

إذا استوفى النص المطلوب معايير الأهلية كنطاق Brand. (انظر القسم 7.1.2.4 طلبات نطاقات.Brand )، وتم العثور على نطاق Brand. المطلوب مشابهًا وفقًا للتفاصيل الواردة في الجدول 7-5: نتائج طلب نطاق gTLD نتيجة لتقييم تشابه السلاسل الذي أجرته اللجنة، وبالتالي لم تتمكن لجنة التقييم من المضي قدمًا أو تم إدراجه في مجموعة الخلاف، فسيتاح لمقدم طلب نطاق Brand. فرصة تغيير النص الخاص به. ويمكن إيجاد قواعد تغيير السلسلة لطلبات Brand TLD. في القسم 5.3 التماسات تغيير سلسلة Brand..¹²⁴