الخلاصة

  • سمح RFC 3318 بوضع * في مجموعة أدوار السياسة، فتطابق القاعدة الواحدة الواجهات التي تحمل الأدوار المطلوبة مع أي عدد من الأدوار الإضافية.
  • لم تمنح النجمة أولوية تلقائية؛ كان على PDP أن يحسم عدم التوافق، وعلى PEP أن يرفض التعارض الباقي بدلاً من تركيب سياسة محلية من عنده.

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

في بنية COPS-PR كان Policy Decision Point يختار معلومات السياسة، بينما مثّل Policy Enforcement Point الجهاز الذي يستقبل القرار. وقدمت SPPI لغة فئات وأمثلة Policy Information Base. أضاف RFC 3318 مفردات مشتركة للأدوار ومجموعات القدرات وإصدارات الحالة والقيود والأخطاء.

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

لم تكن الكتابة حرة. فرّقت المقارنة بين الأحرف الكبيرة والصغيرة، وكان ترتيب الأدوار معجمياً بحسب ASCII. كانت a+b الصيغة الصحيحة، أما b+a فلم تكن مجموعة أخرى بل تمثيلاً غير صالح للمجموعة نفسها. وسُمّيت المجموعة الخالية null. منعت الصيغة المعيارية اختلاف العرض من التحول إلى اختلاف في المعنى.

وسعت النجمة إعادة الاستخدام. في فئات install وinstall-notify طابقت *+a+b واجهة تحتوي a وb، إضافة إلى صفر أو أكثر من الأدوار الأخرى. لم يُسمح بإبلاغ * كدور حقيقي للواجهة، ولم تكن بديلاً داخل اسم الدور. أعطى RFC مثالاً صريحاً: تطابق *+b+e+g المجموعة a+b+c+e+f+g.

إذا اشتركت ثلاث واجهات في A وB، وأضافت على التوالي R1 وR2 وR3، كفت سياسة واحدة *+A+B لتغطيتها. وفّر PDP النسخ المكررة، وصارت نية المشغل «كل ما يحمل A وB» مباشرة.

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

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

أوضح مثال المالية والإدارة هذه الحدود. في البداية حملت واجهتان finance وحملت ثالثة manager. وعندما ترقى موظف في المالية، ظهرت مجموعة finance+manager. استطاع PDP تفضيل سياسة المدير أو إنشاء سياسة ثالثة، مثل DSCP 7 لمدير مالي. وحتى إن ساوت النتيجة سياسة سابقة، كان عليه تنزيل جواب صريح للمجموعة الجديدة.

لم يكن مسموحاً لـPEP أن يركب الجواب من السياستين القديمتين. لو فعل، لأمكن لأجهزة من موردين مختلفين إنتاج نتائج مختلفة من المدخلات نفسها، ولما استطاع المتحكم تفسير مصدر سلطة النتيجة. يترك الرفض إيصالاً قابلاً للتحقيق، بينما يبدو الدمج الصامت نجاحاً ويخفي انتقال القرار.

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

خلال هذا الانتقال كان يمكن أن تصل قرارات مبنية على الأدوار القديمة. لذلك لم تثبت العلامة الجديدة أن كل السياسات التابعة أعيد حسابها. وصف RFC 3084 دورة الطلب والقرار والتقرير، وحدد RFC 3159 نموذج PIB. ظلت نية الدور والقبول والحالة المحدثة وتثبيت السياسة وأثر الحزم أدلة منفصلة.

لم تحل حماية النقل خلاف المعنى. حذر RFC 3318 من أن سوء تهيئة المعلومات القابلة للضبط قد تكون له آثار خطرة. تثبت المصادقة المرسل ويحمي التشفير المحتوى، لكنهما لا يقرران هل تتقدم finance أم manager.

في 2016 نقل IESG RFC 3318 وCOPS-PR وSPPI إلى Historic، مشيراً إلى انتشار محدود وانتقال أعمال الإدارة إلى NETCONF وYANG. يمنع ذلك الادعاء بأن الآلية كانت ممارسة واسعة، ولا يلغي الدرس: يقلل البدل عدد القواعد، لا واجب تسمية من يحسم التعارض.

المصادر: RFC 3318، وRFC 3084، وRFC 3159، وتغيير حالة IESG لعام 2016.