الوحدة 3 تقديم الطلب

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

الوحدة 3 أيضًا موضوعات أساسية إضافية، بما في ذلك:

• استقرار نظام اسم النطاق DNS وقواعد إنشاء العلامات لمنطقة الجذر.

• أنواع الطلبات والسلاسل.

• الرسوم والمدفوعات

• التماسات التغيير

تم تصميم هذه المعلومات لتوضيح عملية الطلب، وتمكين مقدمي الطلبات من الاستعداد بشكل كامل وتصفحها بثقة.

3.1 تقديم طلب

3.1.1 فترة تقديم الطلب

من المتوقع أن تبدأ فترة تقديم الطلبات في موعد أقصاه الساعة 23:59 بالتوقيت العالمي المنسق (UTC) في 30 أبريل/نيسان 2026 وأن تظل مفتوحة لمدة 105 أيام، وتغلق في 12 أغسطس/أب 2026 الساعة 23:59 بالتوقيت العالمي المنسق (UTC).

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

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

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

3.1.2 نظام إدارة طلبات TLD

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

3.1.3 أسئلة الطلب

سيتكون الطلب من الأقسام التالية التي يجب إكمالها عند تسجيل المستخدم:

1. معلومات المنظمة

2. المعلومات المالية

3. معلومات طلب gTLD.

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

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

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

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

3.1.4 السلاسل في الطلب

كل طلب مخصص لنطاق gTLD واحد وقد يتضمن سلسلة متباينة واحدة أو أكثر من السلاسل المتباينة القابلة للتخصيص، حسب الاقتضاء. يمكن أن يكون الطلب أيضًا لسلسلة متباينة قابلة للتخصيص واحدة أو أكثر من نطاق gTLD الحالي.²

3.1.5 اختيار سلسلة بديلة

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

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

يوضح هذا القسم أنواع الطلبات المختلفة لطلبات نطاقات gTLD الجديدة، بما في ذلك العام والمجتمعي والاسم الجغرافي والاسم المحجوز والعلامة التجارية وIDN ومتغير نطاق gTLD الحالي ومتغير IDN الأساسي لنطاق gTLD الجديد والطلبات المقدمة من الحكومات والمنظمات الحكومية الدولية ومقدمي الطلبات المدعومين (أنواع طلبات مقدمي الطلبات من الحكومة/المنظمات الحكومية الدولية ومقدمي الطلبات لدعم مقدم الطلب). قد يكون لكل نوع متطلبات وخطوات معالجة فريدة يجب على مقدم الطلب أن يكون على دراية بها عند تقديم طلب لهذه الأنواع القسم 7.1 أنواع السلاسل والطلبات.

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

الجدول 1-3: نظرة عامة على أنواع الطلبات والاختلافات الرئيسية في التعامل معها

3.1.7 سلاسل الاستخدام الحصري (النطاقات العامة المغلقة)

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

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

لا تصف النطاقات ذات العلامة التجارية فئة عامة من السلع أو الخدمات أو المجموعات أو المنظمات أو الأشياء وبالتالي لا تخضع للحظر المفروض على السلاسل العامة المغلقة. القسم 9.3 من المواصفات 13 من اتفاقية السجل الأساسية⁹ تنص على أن "نطاقات المستوى الأعلى للعلامات التجارية هي نطاقات المستوى الأعلى التي: (ii) يكون مشغل السجل أو الشركات التابعة له أو المرخص لهم للعلامات التجارية وحدهم هم المسجلون لأسماء النطاقات في نطاق TLD ويتحكمون في سجلات نظام اسم النطاق المرتبطة بأسماء النطاقات في أي مستوى في نطاق TLD." يرجى الاطلاع على القسم 7.3 تقييم أهلية TLD للعلامة التجارية للحصول على مزيد من المعلومات.

3.1.8 عمليات التحقق من صحة السلسلة قبل التقديم

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

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

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

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

3.1.8.3 مراجعة استقرار DNS

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

يجب أن تتوافق سلسلة gTLD المطلوبة مع المتطلبات التالية:

1. يجب أن تكون علامة ASCII إما NR-LDH¹⁰ أو علامة A صالحة كما هو موضح في القسم 2.3 من RFC 5890¹¹.

2. يجب أن تتكون علامة NR-LDH بالكامل من الأحرف (الحروف الأبجدية a-z) وفقًا للقسم 2.1 من RFC 1123.¹²

3. يجب أن تتوافق سلاسل IDN gTLD مع IDNA2008¹³ ‏(RFCs 5890-5893) وجميع RFCs ذات المسار القياسي التي تقوم بتحديث IDNA2008.

4. يجب أن تتوافق سلاسل IDN gTLD مع قواعد إنشاء العلامات لمنطقة الجذر المعمول بها¹⁴ راجع القسم 3.1.8.3.1 قواعد إنشاء علامات منطقة الجذر للحصول على معلومات إضافية حول RZ-LGRs ومعالجة الطلبات.

5. إذا تم تصنيف سلسلة gTLD كسلسلة متباينة إما لنطاق gTLD موجود في منطقة الجذر أو لنطاق gTLD أساسي مطلوب، فيجب أن تكون سلسلة متباينة قابلة للتخصيص لنطاق gTLD الأساسي (انظر أسماء النطاقات المدولة). القواعد RZ-LGR هي المصدر الوحيد لحساب السلاسل المتباينة لنطاق gTLD الأساسي وقيم التصرف الخاصة بها، سواء كانت قابلة للتخصيص أو محظورة.

يتم دمج عمليات التحقق الموضحة أعلاه وتنفيذها من خلال TAMS. وهذا يعني أن عمليات التحقق ستحدث تلقائيًا عندما يدخل مقدم الطلب السلسلة في طلبه.

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

في القسم 7.7 تضارب الأسماء و القسم 2.5 الأمن والاستقرار، يتم وصف المشكلات والمتطلبات الإضافية المتعلقة بمراجعات الاستقرار والأمن.

3.1.8.3.1 قواعد إنشاء العلامات لمنطقة الجذر

3.1.8.3.1.1 إصدار قواعد إنشاء العلامات لمنطقة الجذر RZ-LGR المطبق والبرامج النصية واللغات المدعومة

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

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

سيتم استخدام إصدار RZ-LGR [6]، الذي يدمج البرامج النصية وأنظمة الكتابة المذكورة أدناه¹⁶ بناءً على المقترحات التي طورتها لجان إنشاء السلاسل المجتمعية (لجان إنشاء العلامات) وتم دمجها بواسطة قائمة من المراجعين الخبراء (لجنة الجمع).

العربية، الأرمنية، البنغالية، الصينية (الهان)، السيريلية، الديفاناغارية، الإثيوبية، الجورجية، اليونانية، الغوجاراتية، الغورموخية، العبرية، اليابانية (هيراغانا، كاتاكانا، كانجي [الهان])، الكانادا، الخمير، الكورية (هانغول، هانجا [الهان])، اللاو، اللاتينية، المالايالامية، الميانمار، الأوريا، السنهالية، التاميل، التيلوغو، التايلاندية.

تحتوي RZ-LGR على قواعد إنشاء العلامات LGR مميز لكل نص أو نظام كتابة. وقد يحتوي نظام الكتابة على أكثر من نص واحد، فعلى سبيل المثال؛ يتألف نظام الكتابة الياباني من نصوص الهيراغانا والكاتاكانية والكانجي (الهان).

2.1.8.3.1.2 طلبات البرامج النصية غير المدعومة

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

في مثل هذه الحالة، يجب على مقدم الطلب المحتمل أولًا العمل مع مجتمع النصوص لدمج النص ذي الصلة في RZ-LGR، باتباع إجراءات RZ-LGR¹⁷. وسوف تدعم ICANN هذه العملية بشكل نشط. يمكن لمقدم الطلب المحتمل أن يبدأ هذه العملية مع ICANN عن طريق إرسال بريد إلكتروني إلى globalsupport@icann.org في أي وقت. قد يتمكن مقدم الطلب من التقديم في فترة تقديم طلبات لاحقة، إذا تم دمج البرنامج النصي ذي الصلة وإتاحته في الإصدار المعمول به من RZ-LGR.

3.1.8.3.1.3 اختيار السلاسل الأساسية و المتباينة باستخدام RZ-LGR

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

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

إن اختيار السلسلة الأساسية (متى لم تكن هذه الأساسية نطاق gTLD موجود) ضمن مجموعة سلاسل متباينة لن يغير من السلاسل الإجمالية في مجموعة السلاسل المتباينة، لكنه سوف يغيِّر المجموعة الفرعية لمتباينات السلاسل المخصصة والمحظورة ضمن هذه المجموعة. لذلك، عند اختيار السلسلة الأساسية، يجب على مقدمي الطلبات مراعاة السلاسل المتباينة المخصصة والمحظورة المقابلة التي سيتم إنشاؤها. يمكن استخدام أداة قواعد إنشاء العلامات LGR التي توفرها ICANN على الرابط https://lgrtool.icann.org/ من أجل تحديد السلاسل المتباينة القابلة للتخصيص لأي سلسلة أساسية.

3.1.8.3.1.4 نتائج استخدام حسابات RZ-LGR

سيتم تطبيق القواعد RZ-LGR على سلسلة أساسية لتحديد ما إذا كانت السلسلة الأساسية صالحة كنطاق TLD وفقًا للقواعد RZ-LGR.

سوف يتم تطبيق القواعد RZ-LGR على سلسلة متباينة لسلسلة أساسية أو لنطاق gTLD حالي من أجل:

1. تحديد ما إن كانت السلسلة المتباينة صالحة لتكون نطاق gTLD حسب القواعد RZ-LGR أم لا.

2. تحديد ما إن كانت سلسلة متباينة لسلسلة أساسية أو لنطاق gTLD موجود محددة من جانب مقدم الطلب أم لا.

3. تحديد ما إن كانت سلسلة متباينة قابلة للتخصيص لسلسلة أساسية أو لنطاق gTLD حالي.

قد يتم وضع علامة غير صالحة على السلاسل التي تخلط نقاط التعليمات البرمجية في القواعد LGR لبرامج نصية مختلفة.

3.1.8.4 الطعن في عمليات التحقق من صحة السلسلة قبل التقديم

في الحالات التي يعتقد فيها مقدم الطلب أنه يتم منعه من تقديم طلبه أو يتعين عليه تقديم مستندات إضافية لأن عمليات التحقق من صحة سلسلة ما قبل التقديم تم تطبيقها بشكل غير صحيح أو ترميزها بشكل خاطئ، فسوف تتاح له الفرصة لتقديم طعن في موعد لا يتجاوز 14 يومًا قبل إغلاق فترة تقديم الطلب،¹⁸ كما هو موضح بالتفصيل أدناه:

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

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

• مراجعة استقرار DNS: تسبب خطأ في النظام في حساب أداة مراجعة استقرار DNS الآلية والخطأ الذي تم تحديده في النظام في فشل مقدم الطلب في اجتياز مراجعة استقرار DNS. وبالتالي، لم يتمكن مقدم الطلب من المضي قدمًا في تقديم طلبه. لا تنطبق آلية الطعن هذه على البرامج النصية التي لا تدعمها القواعد RZ-LGR. أنظر القسم 3.1.8.3. و القسم 3.1.8.3.1.2 تطبيقات النصوص غير المدعومة..

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

3.1.9 أسماء النطاقات المدوّلة

أسماء النطاقات المدولة (IDNs ) هي أسماء نطاقات يتم تمثيلها بأحرف غير أحرف ASCII (الأحرف a-z، لنطاقات المستوى الأعلى). يتم تشكيل أسماء النطاقات هذه باستخدام أحرف من نص خارج ASCII (على سبيل المثال، العربية أو الصينية).

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

3.1.9.1 قواعد أسماء النطاقات المدولة IDNs ومتبايناتها

يجب أن تتوافق نطاقات IDN المطلوبة مع معيار IDNA2008¹⁹ ‏(RFCs 5890-5893²⁰) وجميع ما يليها. يجب أن يتوافق IDN أيضًا مع الإصدار المعمول به من RZ-LGR. أنظر القسم 3.1.8.3.1 قواعد إنشاء علامة منطقة الجذر.

يمكن تمثيل IDN بأحرف Unicode (تسمى U-label) وتعيين ASCII المكافئ لها مع البادئة "xn--" (تسمى A-label) وفقًا للمعيار IDNA2008. يجب أن تكون نطاقات IDNs المطلوبة (بتنسيق U-label) أطول من حرف واحد. وهذا يعني أن علامة U-label يجب أن تحتوي على نقطتي رمز على الأقل بقيمة²¹ الفئة العامة "L" كما هو محدد بواسطة معيار Unicode. لن يتم احتساب نقاط الرمز بقيمة الفئة العامة "M" ضمن الطول لأغراض تحديد ما إذا كان اسم النطاق الدمدول المقدم به طلب عبارة عن حرف واحد. لمعرفة متطلبات السلسلة الإضافية، راجع أيضًا القسم 3.1.8.3 مراجعة استقرار DNS.

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

يمكن استخدام أداة القواعد LGR التي توفرها ICANN لتحديد السلاسل المتباينة القابلة للتخصيص لنطاق gTLD الأساسي أو السلسلة المطلوبة.²²

3.1.9.2 تقديم طلبات IDNs

يمكن تقديم طلب من خلال TAMS للحصول على IDN مقدم طلب بشأنه يتوافق مع متطلبات السلسلة الإلزامية، بما في ذلك IDNA 2008، بالإضافة إلى القواعد RZ-LGR. عندما يعتبر حساب RZ-LGR أثناء الفحص الخوارزمي أن gTLD المطلوب "غير صالح" أو "محظور" (على سبيل المثال، في حالة أن السلسلة المطلوبة هي سلسلة متباينة)، فلن يتم قبول مثل هذا الطلب لسلسلة غير مطابقة بواسطة نظام تقديم الطلب أنظر Section 3.1.8.3 DNS Stability Review للحصول على قائمة أكثر اكتمالًا للفحوصات التي يتم إجراؤها. يمكن لمقدم الطلب الطعن في حساب RZ-LGR من خلال نظام تقديم الطلبات. See Section 3.1.8.3.1 Root Zone Label Generation Rules.

3.1.9.2.1 تقديم طلب لنطاق IDN أساسي جديد وسلاسله المتبايناته

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

يمكن التقدم للسلاسل المتباينة القابلة للتخصيص من المجموعة التي تم إنشاؤها باستخدام القواعد RZ-LGR. لا يمكن أن يسبق طلب الحصول على سلسلة متباينة قابلة للتخصيص طلب الحصول على نطاق IDN gTLD الأساسي الخاص بها. يجب التقدم لنطاق IDN gTLD الأساسي وأي من السلاسل المتباينة القابلة للتخصيص الخاصة به في نفس الجولة من خلال طلب واحد. بعد التقييم الناجح، سيتم تخصيص gTLD الأساسي والسلاسل المتباينة القابلة للتخصيص المطلوبة إلى نفس مشغل السجل من خلال اتفاقية سجل أساسية واحدة. ولا يمكن لمقدم الطلب التقدم بطلب للحصول على سلسلة متباينة محظورة من IDN الأساسي الجديد، وفقًا لحسابات RZ-LGR. راجع القسم 3.3 الرسوم والمدفوعات للحصول على تفاصيل حول رسوم التقديم للسلاسل المتباينة القابلة للتخصيص.

بمجرد تقديم طلب للحصول على نطاق IDN gTLD الأساسي، لا يمكن تغييره، باستثناء السلسلة الأساسية المطلوبة لطلب نطاق IDN gTLD للعلامة التجارية الذي تم وضعه في تنافس (راجع القسم 5.3 طلب تغيير سلسلة TLD للعلامة التجارية).²³

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

3.1.9.2.2 تقديم طلبات السلاسل المتباينة لنطاقات gTLD الحالية

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

يمكن التقدم بطلب للحصول على سلاسل متباينة قابلة للتخصيص لنطاق gTLD موجود من المجموعة التي تم إنشاؤها باستخدام RZ-LGR ويجب تقديمها في طلب واحد. بعد التقييم الناجح، سيتم تخصيص السلاسل المتباينة القابلة للتخصيص المطلوبة إلى مشغل سجل gTLD الحالي. سيتعين على مشغل السجل الانتقال إلى اتفاقية السجل الأساسية للجولة القادمة، وسيتم تخصيص gTLD الحالي وجميع السلاسل المتباينة من خلال اتفاقية سجل أساسية واحدة. ولا يمكن لمقدم الطلب التقدم بطلب للحصول على سلسلة متباينة محظورة لنطاق gTLD موجود، وفقًا لحسابات RZ-LGR. راجع القسم 3.3 الرسوم والمدفوعات للحصول على تفاصيل حول رسوم التقديم للسلاسل المتباينة القابلة للتخصيص.

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

3.1.9.3 المتطلبات والمعالجة

3.1.9.3.1 تحديد أولوية معالجة السلاسل المتباينة لنطاقات gTLD الحالية

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

3.1.9.3.2 مقدمو الطلبات المتعددون لنفس السلسلة الأساسية أو سلاسلها المتباينة

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

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

3.1.10 اختيار مزود خدمة السجل

يتعين على مقدمي الطلبات تحديد مزودي خدمة السجل (RSP) الذين سيقدمون خدمات السجل المهمة إذا انتقل طلبهم إلى التفويض. يمكن العثور على قائمة مزودي خدمة السجل RSP الذين تم تقييمهم في صفحة طلبات مزودي خدمة السجل (RSP).²⁵

يجوز لمقدمي الطلبات الاستعانة بمزودي خدمة السجل RSPs الخارجيين أو طلب موافقة ICANN لتقديم خدمات السجل الهامة بأنفسهم كمزودي خدمة السجل RSPs من خلال برنامج تقييم مزود خدمة السجل RSP.

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

3.1.10.1 توقعات اختيار RSP عند تقديم الطلب

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

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

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

يجوز لمقدم الطلب تحديد أو تغيير مزودي خدمة السجل المختارين بعد تقديم طلبه من خلال عملية التماس تغيير الطلب (القسم 3.8).

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

3.1.10.2 وظائف السجل وأنواع مزودي خدمة السجل RSPs

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

1. يتولى مزودو خدمة السجل الرئيسيين، الذين يديرون قاعدة بيانات التسجيل لنطاق gTLD، مسؤولية حفظ بيانات تسجيل النطاق، وتشغيل خدمات بروتوكول التزويد المرن EPP وبروتوكول الوصول إلى بيانات التسجيل RDAP لنطاق gTLD. لا يمكن أن يكون لنطاق gTLD إلا RSP رئيسي واحد.

2. مزودو خدمة السجل DNS RSP، الذين يقومون بتشغيل خادم DNS واحد أو أكثر لنطاق gTLD. قد يستخدم نطاق gTLD عدة DNS RSPs.

3. مزودو خدمة السجل DNSSEC RSPs، الذين يقومون بعمليات التشفير اللازمة للامتدادات الأمنية لنظام اسم النطاق DNSSEC. لا يمكن أن يكون لنطاق gTLD إلا DNSSEC RSP واحد.

4. مزودو خدمة السجل Proxy RSPs، الذين يقومون بالتحقق من صحة التسجيل للامتثال للقانون المحلي المعمول به في نطاق قانوني معين. يُرجى ملاحظة أن هذه خدمة سجل إضافية اختيارية يجب أن تتم الموافقة عليها من قِبل ICANN في برنامج تقييم مزود خدمة السجل RSP.²⁷ وقد يستخدم نطاق gTLD عدة Proxy RSPs، كل منهم يوفر الوصول إلى ولاية قضائية مختلفة.

من الممكن تقييم المنظمة لنوع واحد أو أكثر من RSPs في برنامج تقييم مزود خدمة السجل.²⁸

أثناء عملية الطلب، سيُطلب من مقدم الطلب تقديم RSPs التي ينوي استخدامها، وخدمات السجل الإضافية، إن وجدت، التي ينوي تقديمها في نطاقات gTLDs المقترحة. على الأقل، يجب على مقدم الطلب تقديم RSP رئيسي، وRSP DNSSEC، وRSP DNS.

3.2 الفحص الإداري والتحضير ليوم الكشف

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

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

3.3 الرسوم والمدفوعات

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

3.3.1 رسوم تقييم gTLD

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

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

تبلغ رسوم تقييم ] gTLD227,000 دولاراً أمريكياً] لكل طلب لجميع مقدمي الطلبات، باستثناء الطلبات المقدمة من قِبل مقدمي الطلبات المؤهلين لبرنامج دعم مقدم الطلب (ASP) والطلبات المتنوعة التي تلبي المعايير أدناه. يجب دفع الرسوم عند استلام الفاتورة، ويجب أن تستلم ICANN الدفعة كاملة في موعد لا يتجاوز سبعة أيام بعد إغلاق فترة تقديم الطلب. إذا لم يقم مقدم الطلب بدفع رسوم تقييم gTLD خلال هذه الفترة التي تبلغ سبعة أيام، فلن تتم معالجة الطلب بشكل عام وسيتم إلغاؤه. في السيناريو غير المحتمل الذي ينتظر فيه مقدم طلب ASP نتائج تقييم ASP، قد يحتاج مقدم الطلب إلى تقديم طلب gTLD بدون سداد. وسيتم تعليق طلب gTLD حتى يتم تحديد رسوم تقييم gTLD المناسبة وتلقي الدفع.

3.3.1.1 رسوم تقييم gTLD للطلبات التي تحتوي على سلاسل متباينة

3.3.1.1.1 بالنسبة لمقدمي الطلبات الجدد

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

3.3.1.1.2 بالنسبة لمشغلي سجلات gTLD الحاليين من جولة عام 2012

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

3.3.1.2 رسوم تقييم gTLD لمقدمي طلبات برنامج دعم مقدم الطلب المؤهلين

سيحصل مقدمو الطلبات المؤهلون لبرنامج ASP على تخفيض بنسبة 75-85% من رسوم تقييم gTLD. وعليه، فإن رسوم تقييم gTLD المخفضة لمقدم طلب ASP المؤهل سوف تتراوح بين 34,500 دولاراً أمريكياً و56,750 دولاراً أمريكياً (بما في ذلك الوديعة 2,500 دولاراً أمريكياً المقدمة لتأكيد الجدوى المالية للبرنامج ASP). وسيعتمد المبلغ الدقيق على العدد النهائي لمقدمي الطلبات المؤهلين لبرنامج ASP. ستقوم ICANN بإبلاغ مقدمي الطلبات المؤهلين لبرنامج ASP بأنهم مؤهلون للحصول على خصم لا يقل عن 75%، ومن المتوقع أن يتم تقاسم مبلغ الخصم النهائي بعد 12-16 أسبوعًا من إغلاق فترة تقديم طلبات برنامج ASP. كما هو موضح في القسم 3.1.1.1 رسوم طلب gTLD للطلبات التي تحتوي على سلاسل متباينة، فإن الخصم على رسوم تقييم gTLD يشمل ما يصل إلى أربع سلاسل متباينة. سيتعين على مقدمي الطلبات المدعومين الذين يتقدمون بطلبات لأكثر من أربعة سلاسل متباينة دفع رسوم تقييم قدرها 227,000 دولاراً أمريكياً لكل متباين إضافي بعد المتباين الرابع.

3.3.2 التقييمات المشروطة

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

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

بالنسبة للتقييمات التي تم وضع علامة نجمة واحدة عليها (*)، سيحصل مقدم الطلب المؤهل لبرنامج ASP على نفس النسبة المئوية للتخفيض الذي حصل عليه على رسوم تقييم gTLD. قبل منح هذا التخفيض، ستطلب ICANN من مقدم الطلب لبرنامج ASP التحقق من أهليته المستمرة لتلقي المزيد من الدعم المالي (انظر أيضًا شروط وأحكام برنامج ASP).³¹

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

الجدول 2-3: التقييمات المشروطة والرسوم

3.3.3 المبالغ المستردة

3.3.3.1 استرداد رسوم تقييم gTLD

في ظروف معينة، قد يطلب مقدمو الطلبات استردادًا جزئيًا³² للرسوم المدفوعة إلى ICANN كجزء من عملية طلب نطاق gTLD الجديد، كما هو موضح أدناه. يختلف مبلغ الاسترداد بناءً على مرحلة العملية التي يتم فيها طلب الانسحاب أو تتغير حالة الطلب إلى "منتهي".(أنظر القسم 3.9 حالات الطلب).

ستتضمن عملية تقديم الطلبات في الجولة القادمة ثلاث نوافذ استرداد متميزة، على النحو التالي:

1. تمتد النافذة الأولى من استلام رسوم تقييم gTLD الخاصة بمقدم الطلب إلى عشرة أيام بعد يوم تأكيد السلسلة، وخلال هذه الفترة تكون 65% من رسوم تقييم gTLD المدفوعة مؤهلة للاسترداد.

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

3. تمتد النافذة الثالثة من بدء تقييم الطلب ومقدم الطلب حتى النقطة التي يدخل فيها مقدم الطلب في اتفاقية سجل مع ICANN، مما يسمح باسترداد 20% من رسوم تقييم gTLD المدفوعة.

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

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

2.3.3.1.1 انسحاب مقدم الطلب

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

3.3.3.1.2 الطلبات المنتهية

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

3.3.3.1.3 الاسترداد نتيجة لتغييرات جوهرية

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

3.3.3.1.4 استرداد الأموال للسلاسل التي تم تحديدها على أنها عالية الخطورة لتضارب الأسماء

مقدم الطلب الذي يقرر سحب طلبه في غضون 90 يومًا من تحديد السلسلة المطلوبة على أنها عالية الخطورة لتضارب الأسماء، والذي لا يقدم خطة تخفيف مخاطر السلسلة العالية لتضارب الأسماء للتقييم، مؤهل لاسترداد 100% من رسوم تقييم gTLD المدفوعة. ولن تكون أي طلبات للحصول على سلاسل تم تحديدها على أنها معرضة لخطر كبير من تضارب الأسماء في جولة سابقة و/أو لم تتم الموافقة عليها نتيجة لهذا التحديد مؤهلة للحصول على هذا الاسترداد (HOME. وCORP. وMAIL.).

3.3.3.1.5 الاسترداد عند حذف سلسلة بسبب عملية طلب نطاق IDN ccTLD

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

3.3.3.2 الاسترداد حسب حجم الطلب

لقد طبقت ICANN نهجًا متحفظًا في تقدير استرداد تكاليف التنفيذ قبل تلقي طلب واحد. ولضمان استرداد جهود التنفيذ، استند الجزء من رسوم تقييم gTLD المتعلق بتكاليف التنفيذ المقدرة على افتراض وجود 1000 طلب مدفع بالكامل. نتيجة لذلك، قد يتم تطبيق استرداد جزئي للرسوم في حال استيفاء شرطين: 1) استلام أكثر من 1000 طلب؛ و2) استرداد تكاليف التنفيذ لجولة عام 2026.

سيُطلب من مقدمي الطلبات الإشارة في وقت التقديم إلى ما إذا كانوا يرغبون في الحصول على استرداد المبلغ حسب الحجم، إذا كان ذلك ممكنًا.³⁴ إذا لم يقم مقدم الطلب باختيار خيار الحصول على استرداد المبلغ حسب الحجم، فسيتم اعتباره قد فقد قدرته على الحصول على استرداد المبلغ حسب الحجم. بعد يوم الكشف، سوف تقوم ICANN بإخطار المتقدمين الذين اختاروا خيار استرداد المبلغ إذا كان ذلك ينطبق. سيتم حساب مبلغ استرداد الحجم بناءً على عدد الطلبات المستلمة والمبلغ النهائي للتكاليف المتكبدة للتنفيذ. ستكون الطلبات المدفوعة فقط لجولة 2026 مؤهلة لاسترداد المبلغ، مع حصول طلبات ASP المؤهلة على استرداد مبلغ يتناسب مع مبلغ الرسوم المدفوعة.

3.3.4 الرسوم المطلوبة في بعض الحالات

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

• التكاليف الاعتراضات والطعون. أنظر القسم 4.5.6 تكاليف الاعتراضات والاستئناف.

• المزادات. أنظر مزاد القسم 5.6 ICANN لنطاقات gTLD الجديدة.

• التحقق من وثائق التماس تغيير سلسلة TLD للعلامة التجارية. أنظر القسم 5.3 التماس تغيير سلسلة TLD للعلامة التجارية.

3.3.5 الرسوم أثناء عمليات السجل

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

3.3.6 طرق الدفع

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

يجب تقديم المدفوعات إلى مزودي خدمة تسوية الخلافات وفقًا لقواعد مزود الخدمة. أنظر القسم 4.5.6 تكاليف الاعتراضات والاستئنافات.

3.4 يوم الكشف

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

3.5 فترة الاستبدال

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

3.6 يوم تأكيد السلسلة

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

3.7 ترتيب معالجة الطلب وقرعة تحديد الأولويات

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

بمجرد تعيين رقم أولوية الطلب، لن يتغير، ولا يمكن نقله بين مقدمي الطلبات أو الطلبات.

تنطبق قواعد محددة على تحديد أولوية الطلبات الخاصة بأسماء النطاق المدولة IDNs. أنظر القسم 3.7.3 تحديد أولوية طلبات IDN.

3.7.1 قرعة تحديد الأولويات

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

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

3.7.2 المشاركة في القرعة

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

لا يمكن لمقدمي الطلبات حضور القرعة شخصيًا ولكن يمكنهم متابعة الحدث المباشر افتراضيًا.

تتوقع ICANN الإعلان عن التفاصيل الكاملة للقرعة قبل 30 يومًا على الأقل.

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

3.7.3 تحديد أولوية طلبات IDN

سيتم سحب الطلبات المدخلة في القرعة بشكل عشوائي في مجموعات مكونة من 500 طلب حتى تحصل جميع الطلبات على رقم أولوية. سيتم إعطاء الأولوية لطلبات IDN في القرعة وفقًا للترتيب والقواعد التالية:

1. طلبات IDN للحصول على سلاسل متباينة قابلة للتخصيص لنطاقات IDN gTLD لعام 2012.

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

2. بمجرد سحب جميع الطلبات الخاصة بالسلاسل المتباينة لنطاقات IDN gTLDs لعام 2012، إذا كان هناك أقل من 125 طلب IDN متبقي يختار المشاركة في القرعة:

   • سيتم سحب جميع طلبات IDN أولًا وتخصيص أرقام الأولوية لها قبل أي طلبات غير IDN.

3. ومع ذلك، إذا كان هناك 125 أو أكثر من طلبات IDN المتبقية التي تختار المشاركة في القرعة:

   • 25% (125) من المجموعة الأولى المكونة من 500 طلبا ستكون عبارة عن طلبات IDN، التي يتم اختيارها عشوائيًا كجزء من القرعة. وسيتم بعد ذلك سحب طلبات IDN المحددة هذه أولًا وتخصيص أرقام الأولوية لها.

   • ستشتمل نسبة 75% المتبقية (375) من الطلبات في المجموعة الأولى التي ستحصل على أرقام الأولوية على كل من طلبات IDN وطلبات غير IDN. سيتم اختيار هذه عشوائيًا من مجموعة الطلبات المتبقية المشاركة في القرعة وسيتم اختيارها وإعطائها الأولوية بشكل عشوائي.

4. لكل مجموعة لاحقة مكونة من 500 طلبا تختار المشاركة في القرعة:

   • سيتم اختيار أول 10% من كل مجموعة من طلبات IDN بشكل عشوائي، ثم سحبها أولًا وإعطائها الأولوية، ثم الاستمرار حتى لا يتبقى أي طلبات IDN.

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

3.7.4 الطلبات غير المشمولة في قرعة تحديد الأولويات

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

في كل مجموعة مكونة من 500 طلبا، يجب أن تتكون أول 10% من طلبات IDN حتى لا يتبقى المزيد للسحب. سيتم اختيار الطلبات المتبقية في كل مجموعة بشكل عشوائي وإعطائها الأولوية من مجموعة طلبات IDN وغير IDN المتبقية.

3.7.5 استثناءات المعالجة وفقًا لرقم الأولوية

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

3.8 التماسات تغيير الطلب

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

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

3.8.1 نظرة عامة على التماسات تغيير الطلب

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

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

يجوز لمقدم الطلب أن يطلب إجراء تغييرات على العديد من جوانب طلبه، كما هو موضح في القسم 3.8.3 أنواع التماسات تغيير الطلب والعمليات المطلوبة. ومع ذلك، لا يجوز لمقدم الطلب تغيير السلسلة التي تقدم بطلب للحصول عليها، إلا في الحالات التي يكون فيها مقدم الطلب مؤهلاً للحصول على TLD للعلامة التجارية (انظر القسم 7.3. تقيسم أهلية العلامة التجارية) ويكون في حالة خلاف. تتبع التماسات تغيير سلسلة العلامة التجارية العملية الموضحة في القسم 5.3 التماسات تغيير سلاسل العلامات التجارية.³⁹

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

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

3.8.2 معايير تحديد التماس التغيير

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

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

هل هناك أدلة تدعم التأكيد أو الادعاء بأن التغيير مطلوب لغرض تصحيح الخطأ فقط؟

2. الشرح: يتطلب هذا المعيار أن يقدم مقدم الطلب توضيحًا للتغييرات المطلوبة. إذا لم يتم تقديم توضيح، يتم منح مقدم الطلب فرصة لإصلاح الأمر.

هل تم تقديم توضيح معقول؟

3. سبب التغيير:

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

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

هل التغيير مماثل لتغييرات أخرى تمت الموافقة عليها بالفعل؟ هل يمكن أن يدفع التغيير آخرين إلى طلب تغييرات مماثلة يمكن أن تؤثر على آخرين أو تثمر عن تأثيرات غير مرغوبة على البرنامج؟

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

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

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

هل سيؤثر التغيير على نتائج التقييم أو على التنافس على السلسلة أو قد يؤدي إلى الاعتراضات؟

7. التوقيت: يحدد هذا المعيار ما إذا كان توقيت التماس التغيير يؤثر على المعايير من 4 إلى 6 أعلاه. إذا تبين أن التوقيت يؤثر على هذه المعايير، فسيكون ذلك مؤثرًا بشكل كبير.

هل يؤثر التوقيت على معالجة الطلب بطريقة ما؟

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

3.8.3 أنواع التماسات تغيير الطلب والعمليات المطلوبة

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

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

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

الجدول 3-3: أنواع التماسات تغيير الطلب والعمليات المطلوبة

3.8.4 سير عمل التماس تغيير الطلب

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

• التماسات تغيير الطلب: سير العمل 1: التماسات تغيير الطلب المتعلقة بجميع المجالات باستثناء سياسات تسجيل المجتمع والالتزامات الطوعية للسجل سير العمل 1. أنظر القسم 3.8.4.1.

• التماسات تغيير الطلب: سير العمل 2: تتبع التماسات تغيير الطلب المتعلقة بسياسات تسجيل المجتمع والالتزامات الطوعية للسجل سير العمل 2.

كل سير عمل مصمم لتلبية المتطلبات والاعتبارات المحددة المرتبطة بأنواع التماسات تغيير الطلب المعنية. أنظر القسم 3.8.4.2.

3.8.4.1 التماسات تغيير الطلب: سير العمل 1

ستتبع جميع التماسات تغيير الطلب، باستثناء تلك المتعلقة بسياسات تسجيل المجتمع والالتزامات الطوعية للسجل، سير العمل الموضح أدناه:

1. التقديم: يقوم مقدم الطلب بتقديم التماس تغيير الطلب ACR.

2. المراجعة الإدارية: تقوم ICANN بتحديد ما إذا كان نوع التماس تغيير الطلب ACR مسموحًا به بشكل عام، كما هو موضح في الجدول الموجود في القسم 3.8.3 أنواع التماسات تغيير الطلب والعمليات المطلوبة. إذا لم يُسمح بالتغيير، فسوف تبلغ ICANN مقدم الطلب بأن التماس تغيير الطلب ACR لم تتم الموافقة عليه.

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

4. القرار: بعد الانتهاء من المراجعة، ستقوم ICANN بإبلاغ مقدم الطلب بقرارها بالطرق التالية:

   1. في حالة عدم الموافقة على التماس تغيير الطلب ACR، سيتم إبلاغ مقدم الطلب.

   2. إذا تمت الموافقة على التماس تغيير الطلب ACR، سيتم نشر التغييرات المقترحة على موقع برنامج نطاقات gTLD الجديدة على الويب، وسيتم تحديث الطلب وإبلاغ مقدم الطلب. بالإضافة إلى ذلك، سيتم إبلاغ مقدم الطلب بإحدى النتائج التالية:

      1. لا يتطلب الأمر فترة تعليق أو إعادة تقييم (تنتهي العملية هنا).

      2. يجب أن تكون هناك فترة للتعليق (راجع الخطوة 5).

      3. مطلوب فترة للتعليق وإعادة التقييم (انظر الخطوتين 5 و6).

5. فترة التعليقات: إذا كانت هناك حاجة إلى فترة تعليق، فسيتم نشر التماس تغيير الطلب ACR لفترة تعليق مدتها 30 يومًا. وستتيح هذه الفترة وقتًا للمجتمع لمراجعة الجزء المتغير من الطلب وتقديم التعليقات عليه.

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

الشكل 1-3 : التماسات تغيير الطلب: سير العمل 1

3.8.4.2 التماسات تغيير الطلب: سير العمل 2

ستتبع التماسات تغيير الطلب المتعلقة بسياسات تسجيل المجتمع والالتزامات الطوعية للسجل (RVC) العملية الموضحة أدناه.

1. التقديم: يقوم مقدم الطلب بتقديم التماس تغيير الطلب.

2. المراجعة الإدارية: تقوم ICANN أولًا بتحديد ما إذا كان نوع التماس تغيير الطلب ACR مسموحًا به بشكل عام، وفقًا للجدول الموجود في القسم 3.8.3 أنواع التماسات تغيير الطلب والعمليات المطلوبة. إذا لم يُسمح بالتغيير، فسوف تبلغ ICANN مقدم الطلب بأن التماس تغيير الطلب ACR لم تتم الموافقة عليه.

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

4. القرار: تقوم ICANN بتحديد ما إذا كان التغيير جوهريًا وتتخذ الخطوات التالية:

   1. إذا لم تكن التغييرات جوهرية، يتم نشر التغييرات المقترحة على موقع برنامج نطاقات gTLD الجديدة على الويب، ويتم تحديث الطلب وإبلاغ مقدم الطلب (تنتهي العملية هنا).

   2. إذا كانت جوهرية، أنظر الخطوة 5.

5. تقييم التزام السجل (RCE:( تتطلب التغييرات الجوهرية تقييم التزام السجل.

6. القرار: عند الانتهاء من تقييم التزام السجل RCE، ستتخذ ICANN قرارًا بشأن التغيير المطلوب.

   1. إذا نجح التغيير المطلوب في اجتياز تقييم التزام السجل RCE، انتقل إلى الخطوة 7.

   2. إذا لم ينجح التغيير المطلوب في اجتياز تقييم التزام السجل RCE، فلن يتم تحديث الطلب كما هو مطلوب عبر التماس تغيير الطلب ACR وسيتم المضي قدمًا بدون التغيير المطلوب.

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

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

8. فترة التعليقات: سيتم إطلاق فترة التعليق لمدة 30 يومًا. تحتفظ ICANN بالحق في إعادة بدء المفاوضات أو مناقشة التعليقات التي أثيرت خلال هذه الفترة مع مقدم الطلب.

الشكل 2-3 : التماسات تغيير الطلب: سير العمل 2

3.9 حالات الطلب

سيكون للطلب إحدى الحالات التالية:

• الملف مفتوح: تجري معالجة الطلب في برنامج نطاقات gTLD الجديدة.

• الملف معلق: يحتوي الطلب على أنشطة معلقة قد تؤثر على تقدمه، على سبيل المثال آليات المساءلة أو الاعتراضات.

• منسحب: يتم إنهاء الطلب طوعًا من قِبل مقدم الطلب. وهذه العملية لا رجعة فيها.

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

• منتهي: لن يستمر الطلب في البرنامج وقد استنفد مقدم الطلب الطعون والاستئنافات المتاحة.⁴⁸

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

• متعاقد: يتم تعيين حالة "متعاقد" بعد التوقيع الكامل على اتفاقية السجل الأساسية. ويصبح مقدم الطلب بعد ذلك مشغل سجل للسلسلة أو السلاسل المطلوبة.

• مفوض: تمت إضافة النطاق TLD إلى منطقة جذر DNS.