الخلاصة

  • تضيف المسودة الموصى بها مساراً يتيح للسجل الإقليمي المتأثر بدء ترتيب مؤقت لخدماته بنفسه؛ ويتيح مسار آخر البدء أو التجديد بموافقة ICANN وثلثي السجلات الإقليمية الأخرى.
  • حد التسعين يوماً وحق السجل المتأثر في استئناف الخدمات بعد استعادة القدرة والتحقق منها واضحان. أما من يجدد ترتيباً بدأه السجل نفسه فغير محدد صراحة.

تسليم الخدمة لا يغيّر هوية السجل

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

في الأول من سبتمبر 2026، نشرت AFRINIC إحالة إلى المسودة الموصى بها من ASO AC، وإلى النسخة المقارنة وتقرير المبررات. وتصف صفحة NRO النسخة الثالثة بأنها FINAL DRAFT، بينما يسجل جدول العملية أن ASO AC/NRO NC سلّمها إلى NRO Executive Council في 28 يوليو. وحتى 14 أكتوبر ما زالت عملية الإنهاء جارية، كما أن الموافقة أو الاعتماد في الربع الرابع لم يحدثا بعد بحسب الجدول. نحن أمام قاعدة مقترحة للنظام كله، لا إجراء نافذاً. ولا يثبت الإعلان أو النص أن AFRINIC أو أي سجل آخر عاجز حالياً عن تقديم خدماته. إعلان AFRINIC يشارك الحزمة؛ أما الأحكام محل التحليل ففي نص Version 3 المنشور لدى NRO.

مساران لبدء الترتيب

يمثل البند 5.1(a) تغييراً مهماً مقارنة بالنسخة الثانية. فإذا عجز السجل عن تقديم كل خدماته أو بعضها بما يكفي، يستطيع بدء Temporary Emergency Continuity Arrangement لخدماته هو. أما النسخة الثانية فاشترطت الإجماع بين جميع السجلات الأخرى وICANN لبدء الترتيب. وأبقت النسخة الثالثة مسار التنسيق الخارجي في 5.1(b)، لكنها خفّضت العتبة: يجوز لـ ICANN وثلثي السجلات الأخرى أيضاً بدء الترتيب أو تجديده، بعد النقاش مع السجل المتأثر ومجتمعه متى كان ذلك ممكناً بصورة معقولة.

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

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

يمكن قراءة النص بأكثر من طريقة. فذكر التجديد صراحة في (b) قد يعني أن هذا هو المسار الوحيد الذي حدده النص لتجديد الترتيب. ويمكن أيضاً اعتبار صلاحية السجل في البدء بموجب (a) شاملة لتجديد الترتيب الذي بدأه. ويربط 5.1(f) المسارين حين يسند تغيير النطاق إلى «الطرف أو الأطراف التي بادرت» بموجب (a) أو (b)، لكنه لا يحسم سؤال التجديد. هذه فجوة صياغية ينبغي توضيحها؛ وليست حكماً قانونياً نهائياً، ولا دليلاً على أن الترتيب الذي يبدأه السجل لا يمكن أن يستمر.

نطاق الخدمة يحدد أيضاً من يسيطر

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

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

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

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

يجب أن تُظهر الإجراءات مسار الانتقال

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

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

بحسب جدول NRO، ما زال إنهاء النص قيد العمل، مع تحديثات مقررة في اجتماعات قادمة للسجلات وICANN، ثم الموافقة والاعتماد في الربع الرابع. ويمكن اختبار النسخة التالية بثلاثة أسئلة: هل يستطيع السجل الذي فعّل 5.1(a) التجديد بنفسه؟ وإذا لم يستطع، فما قرار 5.1(b) المطلوب تحديداً؟ ومن يحدد النطاق إذا تغير مسار البدء؟ الإجابة الواضحة تحافظ على السرعة المقصودة في Version 3 وتجعل المسؤولية قابلة للتتبع عند انتهاء التسعين يوماً.

المصادر