Skip to main content
Resources

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

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

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

التعريفات

تُعرف المصطلحات التالية لأغراض هذه الوثيقة بما يلي:

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

الوظائف الحاسمة:الوظائف الحيوية بالنسبة لتشغيل سجل gTLD، وهي:

  1. قرار DNS
  2. مناطق الامتدادات الأمنية لنظام إسم النطاق DNSSEC الموقعة بشكل صحيح (حال تقديم DNSSEC من طرف السجل)
  3. نظام التسجيل المشترك (SRS) يتم عادة عن طريق بروتوكول التزويد المرن (EPP)
  4. خدمات دليل بيانات التسجيل (RDDS) مثل WHOIS الموَفَّرة من خلال المنفذ 43 وعبر خدمة عبر الموقع الإلكتروني.
  5. ضمان بيانات التسجيل

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

السجل الخَلَف: الطرف الجديد المتعاقد مع ICANN في اتفاقية سجل الـ gTLD بعد انتقال السجل.

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

ينص التأكيد على الالتزامات، في القسم 9.2، على أن أحد التزامات ICANN هو:

الحفاظ على أمن واستقرار ومرونة نظام اسم النطاق DNS.1

تبين لوائح ICANN الداخلية، القيم الجوهرية للمنظمة. القيمة الجوهرية رقم 1 هي:

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

تنص خطة تشغيل ICANN لـ 2006-2007 (القسم 1.1.2) على أن ICANN ستقوم بـ:

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

تم تطوير هذه العملية في السنة المالية 06-07 وتم تحديثه بشكل متواصل؛ وتدعى اليوم بإطار استمرارية السجل4. إن عملية إدارة الحوادث والأحداث المصورة في إطار استمرارية السجل، تُعَرف الحاجة للتعامل مع الحالات التي تتأثر فيها وظائف السجل الحاسمة سلبا.

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

وقد وضعت العمليات الثلاث التالية ووُضحت في هذه الوثيقة:

  1. عملية انتقال السجل مع المشغّل التالي المقترح
  2. عملية انتقال السجل مع طلب تقديم المشاريع (RFP)
  3. العملية الانتقالية المؤقتة للمشغل الطارئ والاحتياطي للسجل

 

  1. عملية انتقال السجل مع المشغّل التالي المقترح

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

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

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

    • هل سيكون هناك تغيير في الجهة التي تقدم أيا من وظائف السجل الاحتياطية؟
    • هل لـ TLD مجتمع ذو صلة يجب استشارته؟
    • هل هذا نطاق gTLD واسم جغرافي وفقا للتعريف الوارد في دليل مقدم الطلب؟ (أو أن الدعم الحكومي كان مطلوبا وقت تقديم الطلب؟)
    • هل هناك أية قيود في اتفاقية التسجيل قد تؤثر على الانتقال؟

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

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

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

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

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

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

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

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

    إذا كان هناك تغيير في الجهة التي تقدم خدمات مشغل السجل الاحتياطي، فإن على المشغّل التالي تمرير اختبار ما قبل التفويض كما هو محدد في دليل مقدم الطلب عن نطاقات gTLD الجديدة. هذا هو الحال سواء كان المقدم الاحتياطي هو مشغل السجل أو طرفا متعاقدا مع مشغل السجل. وبمجرد الانتهاء من الاختبار بنجاح، يجب على مشغل السجل الجديد الشروع في تغيير المنظمة الراعية مع IANA في قاعدة بيانات منطقة الجذر لـ IANA. وبعد الانتهاء من خطوة IANA، سيقوم مشغل السجل التالي بنقل البيانات والخدمات، وسوف يقدم طلب إجراء تغييرات في سجلات DNS و RDNS أي (WHOIS) مع IANA.

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

  2. عملية انتقال السجل مع طلب تقديم المشاريع RFP

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

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

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

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

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

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

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

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

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

  3. العملية الانتقالية المؤقتة للمشغل الطارئ والاحتياطي للسجل

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

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

    ومن الجدير بالذكر أيضا أن عملية الانتقال هذه تعتبر إجراء مؤقتا لحماية المشاركين ومستخدمي نطاق gTLD. وسيبقى النقل المؤقت للوظائف الحيوية ساري المفعول حتى تحسم القضايا الرئيسية أو حتى ينقل نطاق gTLD إلى مشغل آخر باستخدام علميات انتقال السجل التي تم توضيحها سابقا. ومن أجل السماح بهذا الانتقال المؤقت، فإن اتفاقيات السجل لنطاقات gTLD الجديدة تشمل موافقة مسبقة من مشغل السجل على التغيرات في قاعدة بيانات IANA لسجلات DNS و RDNS أي (WHOIS)، في الحالات الطارئة.

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

    سوف تحافظ ICANN، على الأقل، على مشغلي سجل احتياطيين اثنين يتم اختيارهما مسبقا (مشغلين طارئين) بموجب عقد. سيتم إصدار عملية طلب تقديم مشاريع طارئة كل خمس سنوات لتجديد العقود و/أو تحديد واختيار مشغلي الطوارئ الجدد. سيكون مشغلو الطوارئ الذين تم تحديدهم من مناطق جغرافية مختلفة، وذلك لزيادة موثوقية مشغلي الطوارئ ككل؛ فإذا كانت هناك كارثة في أحد المناطق، تؤثر على قدرة مشغل الطوارئ على تنفيذ مهامه، فإن المشغلين الآخرين سيكونون مستعدين للتشغيل. شروط الأهلية الأساسية لمشغلي الطوارئ هي ثلاث سنوات على الأقل من الخبرة في تشغيل DNS وسنة واحدة من الخبرة في تشغيل RDSS (مثلا WHOIS) وخدمات EPP.

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

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

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

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

    قد تكون هناك حالات يجوز لمشغل السجل الاحتياطي الحالي أن يقوم بدور مشغل الطوارئ، ويكون ذلك إذا:

    • طلب مشغل السجل من ICANN الانتقال الطارئ إلى مشغل السجل الاحتياطي كمشغل طوارئ؛
    • مشغل السجل الاحتياطي الحالي يشغل الوظائف الحرجة ضمن شروط مستويات الخدمة المحددة في اتفاقية السجل؛
    • شركة مشغل السجل الاحتياطي ليست لها علاقة أو تابعة لمشغل السجل؛ و
    • قَبِل مشغل السجل الاحتياطي بتشغيل الـ gTLD تحت شروط أفضل أو تساوي تلك المتفق عليها من قبل مشغلي الطوارئ.

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

    سيكون لمشغلي الطوارئ متطلبات مستوى الخدمة (SLR) لتفعيل كل من الوظائف الحرجة على النحو التالي.

    وظيفة حاسمة متطلبات مستوى الخدمة
    DNS / DNSSEC 4 ساعات بعد طلب ICANN
    RDDS 24 ساعة بعد التوصل بالمعلومات
    نظام السجل المشترك SRS (بروتوكول التزويد المرن EPP)* 72 ساعة بعد التوصل بالمعلومات
    الحفظ الاحتياطي للبيانات 24 ساعة بعد البدء في عملية SRS

    *خوادم SRS المستعدة لقبول الطلبات من أمناء السجل.

    سيحتفظ مشغلو الطوارئ بأرشيف، ملفات المنطقة اليومية على الأقل، لجميع النطاقات العليا للسماح لمشغلي الطوارئ المحددين ليستأنفوا خدمة DNS بسرعة، في حالة الطوارئ. وبالنسبة للوظائف الحيوية الأخرى، سيتم الحصول على البيانات من ودائع التسجيل و/أو مستودع البيانات الحالية.

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

    خلال عملية الطوارئ للوظائف الحرجة لـ gTLD، لن يقوم مشغل الطوارئ بتكليف أمناء السجل بفاتورة عمليات SRS.

    عادة، لن يقبل مشغل الطوارئ نطاقات جديدة، أو تجديد النطاقات، أو تحويل النطاقات، أو حذف اسم نطاق من أمناء السجل. ومع ذلك، وفقا لبعض الحالات الاستثنائية سيتم قبول العمليات المذكورة آنفا، مثلا، في ظل طلب أمن السجل المعجل 5، أو UDRP، أو أي إجراءات قرار اسم النطاق الخاصة بـ ICANN. يمكن الموافقة على العمليات الكبيرة لانتقال النطاق من قبل ICANN للنطاقات التي تتم رعايتها من طرف أمناء السجل الذين لم يعودوا قادرين على خدمتهم (مثلا، تمت إزالة اعتماد أمين السجل). لن يقوم مشغل الطوارئ بإنهاء التسجيلات أو بتجديدها تلقائيا؛ وسوف يدرج في RDDS (مثلا، WHOIS) شرحا موجزا (معتمدا من قبل ICANN) فوق المسئولية القانونية (إن وجدت) كما هو موضح في القسم 1.1 من المواصفات 4 من اتفاقية السجل حول سبب وجود تاريخ انتهاء الصلاحية في الماضي. وسوف يسمح ببقية عمليات SRS لاسم النطاق العادية، كالاتصالات، والاستضافات (RFC 5730-34، 5910). سيعمل مشغل الطوارئ مع جميع أمناء السجل المعتمدين الذين لديهم نطاقات gTLD تحت رعايتهم.

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

    مخطط تدفق العملية الواجب اتباعها في حالة الطوارئ في الملحق 4.

    عند الانتقال من مشغل طوارئ إلى مشغل السجل السابق أو مشغل السجل الجديد، فإن مشغل الطوارئ سيتعاون مع المشغل الجديد من أجل تحقيق انتقال منظم مع الحد الأدنى من التأثير على المشاركين والمستفيدين من نطاق gTLD.

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



1 ICANN. (2009, September 30). Affirmation of Commitments. Retrieved from http://www.icann.org/en/documents/affirmation-of-commitments-30sep09-en.htm

2 ICANN. (2009, September 30). ICANN bylaws. Retrieved from http://www.icann.org/en/general/bylaws.htm#I

3 ICANN. (2006, June 22). 2006-2007 ICANN Operating Plan. Retrieved from http://www.icann.org/announcements/operating-plan-22jun06.htm

4 ICANN. (2009). gTLD Registry Continuity. Retrieved from http://www.icann.org/en/registries/continuity/

5 http://icann.org/en/registries/ersr/

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."