الخلاصة

  • يستطيع IRR Auto-Manager إنشاء كائن مسار IRR أو ربطه عند إنشاء ROA، مع إبقاء خيار فصل دورة حياة السجلين بالحذف أو الإبقاء لاحقاً.
  • تطلب ACSP 2026.9 سجلاً لإجراءات IRR يماثل سجل ROA. وجود قائمتين متشابهتين يحسن الرؤية، لكنه لا يثبت وحده أي البنود نتجت عن نية تشغيلية واحدة.
  • يمكن لإيصال محدود يعبر السجلين أن يحفظ الحالة السابقة والاختيار والتعدد والنتيجة وسلسلة التصحيح، من دون مساواة تفويض ROA بإعلان RPSL.

عالجت ARIN عملاً صغيراً في مظهره، لكنه متكرر في التشغيل. كان حامل موارد الأرقام ينشئ Route Origin Authorization في منظومة RPKI، ثم يدير كائن مسار في Internet Routing Registry من خلال منظومة أخرى. إدخال زوج البادئة ورقم AS المنشئ مرتين يفتح باباً لتأخر إحدى الخطوتين أو نسيانها. يضم IRR Auto-Manager إنشاء كائن route أو route6 المطابق إلى مسار إنشاء ROA، ثم يربط السجلين.

لا يصح أن نبدأ النقد بإنكار هذه المنفعة. الأتمتة تقلل التكرار، ولا تلغي قرار المستخدم. يمكن إطفاء الخدمة على مستوى Org ID. وحتى إن كان الإعداد العام مفعلاً، يستطيع المستخدم رفض إنشاء كائن IRR في عملية محددة. وإذا وجد النظام كائناً مطابقاً غير مُدار، فله أن يستبدله بكائن يديره Auto-Manager أو يتركه كما هو. أما أداة Sync Up فتتيح إنشاء كائن مفقود لسجلات ROA القائمة، أو ربط كائن موجود لم يكن مرتبطاً.

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

والأهم أن السجلين لا يحملان المعنى نفسه. يمثل ROA تفويضاً موقعاً لمنشأ المسار، وقد يتضمن maxLength الذي يحدد أقصى طول للبادئات الأكثر تخصيصاً المسموح بإعلانها. أما كائن المسار في IRR فهو إعلان RPSL يرتكز على البادئة ورقم AS المنشئ. لا يحول Auto-Manager قيمة maxLength إلى سلسلة من كائنات IRR الأكثر تخصيصاً؛ بل يستخدم إدخال البادئة. هذا اختلاف مقصود يحمي الحد الفاصل بين التفويض والإعلان.

تعكس الواجهات البرمجية الحد نفسه. تتحكم roaSpec:autoLink عند الإنشاء في ربط موارد ROA بكائنات route أو route6 الملائمة، وإنشائها عند الحاجة. وتأتي autoLinked في الاستجابة بوصفها معلومة عن النتيجة. في المقابل، تظل واجهة IRR البرمجية قادرة على إدارة كائناتها مستقلة. تجمع العملية بين سطحين، لكنها لا تدمج نموذجي البيانات ولا سلطتيهما.

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

ما الذي يثبته سجل ROA الآن؟

تصف وثائق ARIN سجل Origin AS/Prefix Pair Change Log الذي يعرض سجلات ROA الجديدة والمعدلة للمنظمة خلال الأيام الـ365 الماضية. وإذا تجاوز السجل مئة بند قُسم إلى صفحات. تتضمن الأعمدة التوقيت، والإجراء Added أو Removed، والمصدر Web User أو API User أو ARIN System، ورقم AS المنشئ، والبادئة، والطول الأقصى، وChanged By. ويمكن للمستخدم طلب ملف CSV كامل عبر تذكرة؛ تقول ARIN إنها تراجعه وترد خلال يومي عمل، ثم يبقى الملف متاحاً للتنزيل 90 يوماً.

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

أما جانب IRR، فلا تصف الوثائق العلنية المفحوصة فيه تاريخاً مرئياً مماثلاً للإجراءات. في 11 مايو/أيار 2026، قدّم Randal Kohutek الاقتراح ACSP 2026.9 طالباً إضافة سجل لإجراءات كائنات IRR يساوي سجل إجراءات ROA. كانت الصياغة منضبطة: نظام IRR «لا يبدو» أنه يتضمن مثل هذا السجل. لا تثبت هذه الملاحظة أن ARIN تفتقر إلى سجلات داخلية أو تاريخ لقاعدة البيانات أو أدوات أمن ودعم.

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

تماثل الأعمدة لا يمنح العملية هوية

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

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

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

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

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

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

إيصال يتبع العملية لا قاعدة بيانات واحدة

يبدأ الإيصال بمعرف عملية مبهم لا يحمل بيانات شخصية، وبطابع زمني. يسجل نقطة البداية: ARIN Online أو RPKI API أو IRR API أو Sync Up أو ARIN System. ويذكر فئة الفاعل والمنظمة المخولة من دون نشر اسم شخص بلا ضرورة. كما يحدد القصد: إنشاء ROA أو تعديله أو حذفه، إنشاء كائن IRR أو ربطه، استبدال كائن غير مُدار، حذف IRR وحده، إبقاؤه غير مُدار، أو إعادة المزامنة.

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

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

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

يحتوي Auto-Manager بالفعل على انضباط مؤسسي مناسب: ينسق ولا يدمج، ويؤتمت ولا يغلق المخرج. تحدد ACSP 2026.9 الخطوة التالية. أفضل تنفيذ لا ينسخ أعمدة سجل ROA إلى IRR فحسب؛ بل يمنح التغيرين هوية تشغيلية مشتركة تثبت متى صدرا عن عملية واحدة ومتى كانا قرارين مستقلين، من دون تحميل الطابع الزمني معنى لا يستطيع إثباته.

المصادر