الخلاصة

  • ذكر اقتراح ACSP 2026.3 أن وجود ROA للبادئة /16 مع maxLength /24 يجعل الطلبات من /16 إلى /24 للـOrigin AS نفسه زائدة، بينما تظل البوادئ من /25 إلى /32 قابلة للإنشاء وفق الاختبار المبلغ عنه.
  • أغلقت ARIN الاقتراح بوصفه مكتملاً بعد تحديث صفحة الأسئلة الشائعة، لكن المثال المنشور الآن يكتفي بعبارة «any prefix covered» ولا يحتفظ بالنطاق المرفوض أو بالمثال المسموح.
  • يمكن لوصل اختبار دلالي صغير ومؤرشف بالإصدارات أن يثبت قاعدة القبول في الويب وREST وOT&E من دون كشف شيفرة أو مفاتيح أو بيانات عملاء.

سرعة الاستجابة تستحق أن تُسجَّل أولاً

قدّم Chris Woodfield اقتراح ACSP 2026.3 في 13 يناير/كانون الثاني 2026. لم يكن النص اعتراضاً عاماً على صعوبة الوثائق؛ فقد نقل المثال المختلف عليه، ووصف ما رآه في الاختبار، وحدد موضع الاتساع في العبارة، واقترح بديلاً جاهزاً.

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

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

لذلك لا يدور السؤال حول حق ARIN في اعتماد قاعدة قبول أشد من الأشكال التي يجيزها تنسيق RPKI العام. السؤال هو: ما الدليل العلني الذي يربط الحالة الدقيقة التي قُبلت بالنتيجة التي حملت صفة «مكتملة»؟

الاقتراح نفسه احتوى اختبار القبول

بدأ المثال القديم المنقول في صفحة الاقتراح بكائن ROA للبادئة /16 وله maxLength /24. وكان يقول إن كائن ROA آخر للـOrigin AS نفسه سيُمنع إذا كانت باديئته داخل /16. أشار مقدم الاقتراح إلى أن اختباره كشف قاعدة أضيق.

وفق الرواية المنشورة، فإن طلباً جديداً للـAS نفسه بطول من /16 إلى /24 لا يمنح شيئاً يتجاوز التفويض القائم، ولذلك يُرفض باعتباره زائداً. أما /25 إلى /32 فتظل داخل فضاء العناوين الذي يشمله /16، لكنها تتجاوز الحد الأقصى الموجود. وفي الاختبار المبلغ عنه أمكن إنشاء ROA مستقل لها.

لم يكتف النص المقترح باستبدال كلمة overlapping بكلمة redundant؛ بل أبقى جانبي الحد: المجال الممنوع والمثال المسموح. والمثال الثاني هو الذي يمنع الخلط بين احتواء العنوان واحتواء السلطة. كما يحول العبارة إلى اختبار بسيط: باديئة على كل جانب من /24 ثم مقارنة النتيجة.

تقول صفحة الأسئلة الشائعة الحالية عن RPKI إن التجديد التلقائي ألغى الحاجة إلى النسخ، وإن ROA لم يعد مسموحاً له بالتداخل. وفي مثال /16 وmaxLength /24 تقول إن كائناً جديداً للـOrigin AS نفسه يُمنع لأي «prefix covered in the existing ROA». لكن النطاق من /16 إلى /24 لم يعد مكتوباً، كما اختفى المثال المضاد من /25 إلى /32.

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

التغطية والمطابقة ليستا العلاقة نفسها

يفصل RFC 6811 بين مفهومين متجاورين. تكون باديئة مسار Covered بواسطة VRP عندما تكون باديئة VRP مساوية أو أقل تخصيصاً وتتطابق بتات العنوان المعنية. لا يدخل الحد الأقصى للطول في هذا الاختبار. ولا تصبح الباديئة Matched إلا إذا كان طولها أيضاً دون حد VRP الأقصى أو مساوياً له وكان Origin ASN مطابقاً.

لا تكتب FAQ كلمة covered بصفتها مصطلحاً معيارياً ولا يلزم افتراض ذلك. لكن القارئ التقني يعرف المعنيين. فالبادئة /25 داخل /16 مغطاة من حيث العنوان، لكنها لا تطابق VRP حده الأقصى /24 حتى لو كان ASN واحداً. كان المثال المضاد المحذوف أقصر وسيلة لإظهار هذا الفرق.

أما RFC 6482 فيعرّف maxLength داخل الكائن الموقّع: إنه أطول باديئة مسموح للـAS بإعلانها، وغيابه يعني أن التفويض يقتصر على البادئة المطابقة تماماً. كما يسمح RFC بأن يحتوي ROA صحيح على باديئة تشملها خانة أخرى، بل وعلى خانتين متطابقتين، مع عدم التوصية بتكرار لا يمنح صلاحية إضافية.

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

الواجهات تعرض الحقول ولا تعرض المعادلة

يصف دليل ARIN الخاص بـROA الكائن بأنه Origin AS وبادئة وطول أقصى، ثم يكرر منع النسخ والتداخل ويحيل إلى FAQ. لا تقدم الصفحة مصفوفة حالات حدية.

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

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

توفر ARIN بيئة OT&E للاختبار من دون المساس بالإنتاج. وتقول إن لها مجموعة الخصائص نفسها، وتسمح بإنشاء ROA تجريبي وفحص حمولات معاملات RPKI قبل تغيير الإعدادات الحية. لكنها منفصلة عن الإنتاج، وتُستبدل بياناتها بلقطة شهرية، ولا تدعم البريد، ولا يراقبها موظفو ARIN بصورة نشطة.

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

خمس حالات تكفي لإثبات القاعدة

يمكن أن يبدأ الوصل برقم الاقتراح ومراجعة الوثيقة وإصدار قاعدة الخدمة وتاريخ نفاذها. وفي كل صف تُسجل القناة، وOrigin AS القائم، والبادئة وmaxLength، والطلب الجديد، والنتيجة المتوقعة، ورمز سبب ثابت. كما تُسجل نسخة OT&E وتاريخ التشغيل ويُربط أي إصدار لاحق بما استبدله.

الصفوف الخمسة هي: البادئة نفسها والـAS نفسه؛ باديئة أكثر تخصيصاً داخل maxLength؛ باديئة تتجاوز maxLength؛ فضاء العناوين نفسه مع Origin AS مختلف؛ ومعاملة ذرية تحذف القديم وتضيف البديل. تكفي بوادئ التوثيق وأرقام AS المحجوزة، فلا حاجة إلى بيانات عملاء أو مفاتيح إنتاج أو شيفرة داخلية.

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