الخلاصة

  • قدم تيم مكغينيس في 10 أبريل/نيسان 2012 المسودة الأولى «No Reverse Unless Assigned»، AFPUB-2012-DNS-001-DRAFT-01، بوصفها تعديلاً على AFPUB-2005-v4-001. كانت فكرتها المركزية رفض إنشاء تفويض عكسي جديد لمساحة عناوين تديرها AFRINIC ما لم يكن الإسناد أو التخصيص الفرعي الموافق مسجلاً بصورة مناسبة في قاعدة بيانات AFRINIC.
  • ميزت المسودة الأولى بوضوح بين المستقبل والماضي. اقترحت الفقرة 3.2 تذكير السجلات المحلية التي لديها تفويضات عكسية قائمة لكن لا تظهر لها إسنادات أو تخصيصات فرعية، وتركت تفاصيل الإخطار للسكرتارية؛ إلا أن الفقرة 3.3 قالت صراحة إن التفويضات العكسية التي أُقرت قبل التصديق لن تُزال، وإن الأثر سيقع فقط على التخصيصات اللاحقة. لذلك لا يصح وصف Draft 1 بأنها خطة لقطع التفويضات القائمة.
  • دقة سجل الإسناد منفعة تشغيلية حقيقية، ووجود سجل PTR متسق قد يهم خدمات تعتمد على المطابقة بين العنوان والاسم. لكنه لا يحدد مسار الحزم، وغيابه لا يوقف توجيه IP بذاته. لهذا يجب تحليل رفض التفويض بقدر أثره الدقيق، لا بتضخيمه إلى «انقطاع الإنترنت» ولا بتصغيره إلى إجراء كتابي بلا تبعات.
  • AFRINIC أمين سجل خاص ومشغل خدمة سجل ومنسق تقني. يمكنها التحقق من المتطلبات الضيقة لطلب تفويض عكسي وتسجيل النتيجة وتصحيح الخطأ، لكنها ليست دولة أو مشرعاً أو جهة تنظيم أو شرطة أو نيابة أو هيئة عقاب أو مصادرة أو محكمة أو صاحب سيادة. وصف المسودة نفسها بأنها «آلية إنفاذ» لا ينشئ تلك السلطة.
  • تكمن ثغرة Draft 1 في أنها لم تقل كيف يميز الموظف بين سجل مفقود فعلاً وبين تأخر مزامنة، أو قيد موجود بدرجة تفصيل مختلفة، أو تحديث موثق لا يزال قيد المعالجة، أو خطأ مطابقة من جانب السجل. كما لم تضع خطاب رفض مسبباً، أو مهلة خدمة للتصحيح، أو مراجعة مستقلة، أو مسار تراجع سريع.
  • كان التحفظ الأهم في الفقرة 3.3 هو إبقاء آخر حالة عاملة للتفويضات السابقة بلا تغيير. المبدأ الذي ينبغي تعميمه ليس معاقبة من يفشل سجله، بل حماية السجل الصحيح والخدمة العاملة معاً: إخطار موثق، تحديد المنطقة والقيد المختلف عليهما، قبول الدليل التصحيحي، قرار قابل للمراجعة، واستمرار آخر حالة متحقق منها إلى أن يُحسم الخطأ.
  • سجل اجتماع AFRINIC-16 في 18 مايو/أيار 2012 أسئلة عن الفاعلية، وكلفة الموظفين، وقابلية التطبيق، والحاجة إلى موافقة إذا استُخدم مسح المنافذ، ثم سجل عدم وجود توافق وإعادة المقترح إلى القائمة البريدية. وظلت شرائح AFRINIC-17 تعرض Draft 1 في 29 نوفمبر/تشرين الثاني؛ ويقول التقرير السنوي لعام 2012 إن المقترحات التي نوقشت لم تحظ بالتوافق. هذه وقائع عملية خاصة، لا تصديقاً ولا حكماً بشرعية سلطة عامة.

اللحظة التي التقى فيها الدفتر بالخدمة

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

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

في الاجتماع السادس عشر لـAFRINIC في 18 مايو/أيار 2012، عرض تيم مكغينيس المقترح بعد تنحيه عن دور الرئيس المشارك في ذلك البند. يسجل التقرير الرسمي أن الدافع المعلن كان تحسين تسجيل الإسنادات في المصب، وأن التفويض العكسي اعتُبر حافزاً عملياً لأن شرط إظهار الاستخدام يظهر عادة عند طلب مساحة إضافية لاحقاً. وبحسب المحضر، نُسب إلى مقدم المقترح رقم يفيد بأن أكثر من 60 في المئة من مزودي خدمة الإنترنت سجلوا إسنادات، فيما لم يسجل ما يقرب من 40 في المئة أي إسناد. لكن التقرير لا يقدم مقام الكسر، ولا تاريخ الاستعلام، ولا طريقته، ولا عينة مستقلة، ولا تدقيقاً للنتيجة. لذا فالرقمان يثبتان ما قيل في الاجتماع، لا ما كانت عليه كل شبكة فعلاً.

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

ما اقترحته المسودة الأولى فعلاً

تعيد شرائح AFRINIC-17 بناء هوية النص وحدوده بدقة كافية. فهي تسميه AFPUB-2012-DNS-001-DRAFT-01، وتؤرخ تقديمه في 10 أبريل/نيسان 2012، وتنسبه إلى تيم مكغينيس، وتقول إنه يعدل AFPUB-2005-v4-001. كما تعرض شرحه لقاعدة «معلومات الشبكات العامة» بوصفها وسيلة لنشر معلومات الاتصال بالشبكات العامة عن طريق تسجيل الإسنادات. هذه مادة تاريخية مفيدة لأنها تمنع إعادة كتابة المسودة انطلاقاً من عنوانها وحده.

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

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

ثم تأتي الفقرة 3.3، وهي قيد جوهري لا هامش لغوي. قالت المسودة إن AFRINIC لن تزيل التفويض العكسي لتخصيصات السجلات المحلية التي تمت الموافقة عليها قبل التصديق، وإن التخصيصات التي تأتي بعد ذلك وحدها ستتأثر. هذا يعني أن Draft 1 لم تقترح سحب التفويضات السابقة. كان فيها «جدّ» زمني: خدمة قائمة قبل التصديق تبقى قائمة، حتى إن لم يظهر تحت الكتلة إسناد أو تخصيص فرعي كما تريده السياسة. قد يكون هذا التمييز غير كامل من منظور العدالة بين أصحاب الموارد القديمة والجديدة، لكنه حدّ من دائرة الضرر وحمى الاستمرارية.

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

لماذا تهم دقة الإسناد

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

تصف NRS وظيفة AFRINIC بوصفها سجلاً إقليمياً يخصص موارد أرقام الإنترنت ويسجلها. هذا وصف لوظيفة دفتر وخدمة، لا لمنصب حكومي. وبالقدر نفسه، عرضت المسودة AFPUB-2005-v4-001 section 9.5 كما لو أن التسجيل في قاعدة Whois جزء من صلاحية الإسناد، ثم وصفت اقتراحها بأنه «آلية إنفاذ» لذلك الواجب. الكلمة تكشف منطق التصميم: لم يكن المراد فقط التأكد من صحة طلب DNS، بل إيجاد حافز يجبر تحديث سجل آخر. غير أن تسمية الإجراء إنفاذاً لا تمنحه قوة قانون عام. يستطيع عقد خاص أو إجراء خدمة أن يضع متطلبات فنية معقولة، لكنه لا يحول أمين السجل إلى جهة عقاب أو حَكَم في ملكية المورد.

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

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

ما يفعله DNS العكسي، وما لا يفعله

تحتاج القضية إلى قدر محدود من شرح التقنية. في DNS الأمامي، يبحث المستخدم عادة عن عنوان مرتبط باسم. وفي DNS العكسي لنظام IPv4، تُنظم مناطق تحت IN-ADDR.ARPA، وتتيح سجلات PTR ربط عنوان IP باسم. يعرّف RFC 1035 هذا النوع من السجلات وبنية العكس. ويشير RFC 1912 إلى أخطاء شائعة، ويوصي باتساق سجلات PTR مع سجلات A للمضيفين، ويحذر من أن الغياب أو عدم التطابق قد يسبب مشكلات وصول أو خدمة.

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

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

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

السجل ليس حكماً في الواقع كله

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

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

وفي حالة Draft 1، لم يكن النص يحدد معنى «مساحة العناوين تلك» عند مطابقة الإسناد بالمنطقة العكسية. فالمساحة قد تُرى ككتلة أم، أو مجموعة حدود تفويض، أو إسنادات أصغر. ولا تكشف المصادر كيف كانت AFRINIC ستنفذ المطابقة عام 2012. هذا الغموض ليس تفصيلاً قابلاً للتجاهل، لأنه يحدد من يمكن أن يقع في فخ سالب كاذب. إذا بحث النظام عن كائن بدرجة واحدة بينما سجل المشغل بياناته بدرجة أخرى مقبولة، قد يرفض طلباً صحيحاً لا بسبب نقص المسؤولية بل بسبب اختلاف النموذج.

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

حافز قوي فوق حقيقة ضعيفة

يفسر محضر AFRINIC-16 سبب جاذبية DNS العكسي كرافعة. ذُكر في النقاش أن هناك عتبة ناعمة قائمة تبلغ 80 في المئة لإظهار الإسناد أو التسجيل قبل طلب مزيد من المساحة. لكن صاحب التخصيص الذي لا يحتاج إلى كتلة إضافية قريباً قد لا يواجه ذلك الفحص. من منظور مصمم السياسة، يبدو ربط خدمة مرغوبة بالسجل وسيلة لدفع التحديث الآن لا عند طلب المورد التالي.

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

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

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

عدم التوافق ليس تفويضاً مؤجلاً

يسجل تقرير AFRINIC-16 عدم وجود توافق على المقترح وإعادته إلى القائمة البريدية. وبعد أكثر من ستة أشهر، في 29 نوفمبر/تشرين الثاني 2012، كانت شرائح AFRINIC-17 لا تزال تعرض Draft 1 بوصفها النسخة الحالية وتعيد إنتاج موادها التشغيلية. ثم وضع التقرير السنوي لـAFRINIC المقترح ضمن خمسة مقترحات نوقشت في 2012 وقال إن المقترحات التي نوقشت في AFRINIC-17 لم تحظ بالتوافق.

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

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

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

القيد الوقائي الذي يستحق البقاء

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

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

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

وهنا يظهر الفرق بين الاستمرارية المؤسسية واستمرارية الوظيفة. ما يحتاج إليه الإنترنت هو دفتر موثوق، وDNS عكسي مستمر، وWHOIS وRDAP وRPKI وسجلات تغيير وخدمات تعمل. لا يتبع من ذلك أن الشركة التي تدير هذه الوظائف تملك سلطة غير محدودة. ينبغي حماية الوظيفة حتى عند الاعتراض على البوابة، وحماية الدفتر حتى عند تقييد من يكتب فيه. «احم السجل، لا حارس البوابة» ليست دعوة إلى الفوضى؛ إنها قاعدة لتوزيع الثقة ومنع الاعتماد من أن يتحول إلى سيادة.

أين تنتهي وظيفة AFRINIC

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

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

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

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

القرار الجيد يبدأ بسؤال محدد

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

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

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

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

درس 2012 الذي لم يهرم

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

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

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