الخلاصة

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

قد تنتقل القاعدة، لكن معناها لا ينتقل بالضرورة

قد يبدو ملف السياسة قابلاً للنقل، ومع ذلك ينتج سلوكاً مختلفاً عند أطراف الشبكة. فقد يتلقى جهازان شرطاً وإجراءً يحملان الاسمين نفسيهما، لكن قدراتهما المحلية أو امتداداتهما أو شيفرة التقييم فيهما تختلف. هذا التمييز يقع في صميم RFC 3060، الإصدار الأول من «نموذج معلومات السياسة الأساسي» (PCIM)، المنشور في فبراير 2001.

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

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

«تصريحي» مع فراغ مقصود

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

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

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

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

كانت للمعمارية المحيطة وظائف مختلفة

فصل إطار القبول القائم على السياسات في RFC 2753 بين نقطة اتخاذ القرار (PDP)، حيث يُحسم القرار، ونقطة فرض السياسة (PEP)، حيث يؤثر القرار في عنصر الشبكة. ثم عرّفت RFC 2748 بروتوكول COPS لتبادل الطلبات والقرارات بين هذين الدورين. أما RFC 3084 فحددت استخداماً لـ COPS من أجل تزويد قواعد معلومات السياسات. هذه طبقات متجاورة، لكنها ليست شيئاً واحداً مع PCIM: بروتوكول النقل ونموذج التزويد ومخطط المعلومات تجيب عن أسئلة مختلفة.

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

غيّر الإصدار اللاحق النموذج، لا معيار الإثبات

حدّثت RFC 3460، المنشورة في يناير 2003، نموذج PCIM. أضافت عناصر، وأبطلت أخرى واستبدلتها، وعدّلت تمثيل الأولويات، وأدخلت استراتيجيات لاتخاذ القرار يحددها المدير. كان ذلك تطوراً حقيقياً في نموذج المعلومات. كما أظهر أن مفردات الإصدار السابق لم تكن مجمّدة: فقد أمكن للأعمال اللاحقة مراجعة كيفية التعبير عن مجموعات القواعد وخيارات التقييم.

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

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

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

المصادر