الخلاصة

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

ختم صحيح على أمر لا يملكه المرسل

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

تقترح مسودة «نموذج لتبادل السياسات الموزعة» حاوية YANG لسياسة واحدة تنتقل بين مكونات إدارة دورة الحياة. تشترط area وlanguage وpolicy-content وowner وauthor، بينما يرد origin وتوقيع المنشأ كحقلين اختياريين في النموذج المعروض. المحتوى التنفيذي معتم بالنسبة للحاوية. فهي تنقل تعريف السياسة وبياناتها، ولا تفسر بنفسها قواعد Rego أو أوامر حماية تدفق الشبكة. تتحدد آثار النص في بيئة التنفيذ التي تتلقاه.

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

بوابة مرسومة بخط عريض، ومفتاحها اختياري

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

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

يسجل متعقب IETF الوثيقة بوصفها مسودة فردية نشطة في حالة I-D Exists. ليست هناك في هذه المصادر واقعة تشغيلية موثقة أو قرار موحد صادر عن فريق عمل. ومع ذلك، تسمي المسودة بنفسها فجوة الحوكمة: قد يكون مصدر السياسة معروفاً، ولا تكون له سلطة تعريفها في المنطقة التي ستستقبلها.

دفتر عبور يذكر سبب السماح

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

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

المصادر