RFC 5224: نتيجة السياسة ليست دليلاً على التنفيذ

الخلاصة

يسجّل RFC 5224 رمز الأمر 314 ومعرّف التطبيق 16777243 وAVP باسم Policy-Data ضمن مساحة OMA. هذه القيم تعرّف نوع الرسالة، ولا تمنح البيانات اكتمالاً أو تمنح المجيب سلطة تلقائية.
تسمح بنية OMA بالتقييم من دون تنفيذ. قد يعود القرار إلى المورد الطالب فيقرر هو كيف يتصرف، أو قد تنفذ PEEM داخلياً. لا يثبت ضوء نجاح واحد أي المسارين حدث.
يلزم ربط الطلب ونسخة السياسة ومصدر المدخلات والقرار وإيصال المنفّذ والتثبيت والتفعيل والاستبدال اللاحق والأثر المرصود في سلسلة واحدة قابلة للمراجعة.

الجواب سبق الفعل

في اختبار افتراضي، يرسل مورد طلب PDR عند الساعة 14:00. بعد ثانية يصل PDA متطابق الارتباط ويحمل نتيجة نجاح. تعرض لوحة التشغيل فوراً أن السياسة «طُبّقت». لكن موصل التنفيذ غير متصل، وحين يعود تكون قاعدة محلية أحدث قد سبقت القرار.

نجح ما قاسه Diameter بالفعل. الخطأ أن النظام منح هذا النجاح لطبقة لم تتحرك بعد.

RFC 5224 وثيقة معلوماتية قصيرة. تسجّل PDR/PDA تحت الرمز 314، وPolicy-Data تحت الرمز 1 في مساحة OMA، ومعرّف التطبيق 16777243. وتحيل الاستخدام التفصيلي المعياري لـDiameter إلى مواصفة PEM-1 التابعة لـOMA.

هذا التقسيم مهم: الوثيقة تنسّق الاسم والحامل، ولا تشهد على اختيار سياسة بعينها أو سلامة سياقها أو من نفّذها أو ما إذا تغيّر المورد في النهاية.

الرقم ينسّق البرمجيات ولا يعيّن صاحب السلطة

ما زال سجل معاملات AAA لدى IANA يعرض التخصيصات. تستخدم OMA رقم المورد 30079 وتعلن دعم التطبيق في تبادل القدرات. بذلك تتفق العقد على النحو الصحيح للرسالة.

لكن Application-Id ليس تفويضاً. وVendor-Id ليس حقاً لاتخاذ قرار بشأن كل مشترك أو خدمة. يوجّه Realm وHost الرسالة، ولا يثبتان أن الوجهة هي المرجع المخوّل لهذه الحالة.

يرث RFC 5224 اعتبارات الأمن من RFC 3588، ثم حلّ RFC 6733 محل بروتوكول الأساس. تحمي القناة هوية النظير وسلامة الرسالة، لكنها لا تثبت أن رصيداً أو موقعاً أو درجة مخاطر كانت حديثة، ولا أن النظير الموثّق يملك التفويض التجاري المطلوب.

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

القالب يصف البنية لا حقيقة المحتوى

تستخدم مواصفة PEM-1 حاويات BLOB وقوالب قياسية أو مخصصة لأن السياسات تحتاج مدخلات ومخرجات مختلفة.

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

وترسم OMA حدودها صراحة. آليات نشر الخيارات المدعومة خارج النطاق. كذلك لا تحدد الواجهة كيف تعالج PEEM المدخلات ولا كيف يعالج المورد الطالب المخرجات. تبدأ المسؤولية المحلية عند هذه النقطة.

لذلك يجب أن يربط إيصال الطلب bytes الأصلية لـPolicy-Data بالقالب ونسخته والفاعل والمورد والسياسة ونسختها ومصدر كل قيمة ووقت رصدها، إضافة إلى أي استدعاء مفوض. وإلا بقيت الرسالة قابلة للفك والقرار غير قابل للتفسير.

«معالجة السياسة» لها أكثر من نهاية

تعرّف PEM-1 معالجة السياسة بأنها تقييم، أو تقييم مع تنفيذ. وتعرض بنية PEEM المسارين بوضوح.

قد تعيد PEEM قراراً إلى المورد الطالب، فيبقى هذا المورد مسيطراً على كيفية التعامل معه. وقد تنفذ PEEM بنفسها وربما لا تعيد قيمة. كما يوجد نموذج للتقييم فقط بلا فعل سياسة أو تنفيذ من PEEM.

يفصل نموذج المكونات بين PV وPF. يقيّم PV ويعيد النتيجة؛ وينفذ PF الفعل الناتج وقد يفوض موارد أخرى. وجودهما في منتج واحد لا يلغي الفرق بين إنتاج القرار وإتمام الفعل.

يحافظ IETF على الفصل نفسه. يضع RFC 2753 القرار في PDP والتنفيذ الفعلي في PEP. ويعرّف RFC 3198 enforcement بأنه تنفيذ قرار السياسة. وجوب التنفيذ قاعدة معيارية؛ حدوثه في معاملة محددة واقعة تحتاج إلى إيصال.

داخل «النتيجة» طبقات متعددة

يحمل Diameter Result-Code أو Experimental-Result. وكلمة Experimental هنا اسم لحاوية نتيجة خاصة بالمورد، وليست دليلاً على تجربة رُصد أثرها في الشبكة.

تضيف PEM-1 قالب Output Status وفيه statusCode إلزامي لحالة المعالجة النهائية أو الخطأ. ثم قد تنتج السياسة قراراً أو بيانات يفسرها الطالب. يمكن أن تنجح الطبقات الثلاث قبل أي تغيير في المورد.

قد تُقبل الرسالة، وتكتمل المعالجة، ويعود القرار، ثم يرفض المنفّذ أو يثبت جزءاً أو يخسر أمام حالة أحدث. والعكس ممكن: قد تنفذ PEEM داخلياً وتعيد حالة محدودة.

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

يستخدم الربط NO_STATE_MAINTAINED. لا يحتفظ الخادم بحالة جلسة Diameter ولا يرسل العميل إنهاء. يثبت الجواب التبادل، ولا ينشئ تاريخاً دائماً لتثبيت السياسة أو استبدالها.

موثوقية النقل ليست تنفيذ السياسة

يتناول RFC 3539 المراقبة والفشل والطلبات المعلقة والتكرار في AAA. يفسر الوصول وإعادة المحاولة، ولا يثبت الأثر. ويصف RFC 2989 قدرات AAA؛ وجود القدرة ليس إيصال معاملة. كما يبين RFC 7683 وRFC 4006 أن الحمل وحالة التطبيق ونتيجة الخدمة تحمل معاني مستقلة.

السلسلة الدنيا تحفظ الطلب ومساره والنظير الآمن والفاعل والمورد ونسخة السياسة والقالب ومصدر المدخلات واعتماديات التقييم، ثم تفصل نتيجة Diameter عن حالة PEEM ومخرج السياسة. وبعدها تحفظ هوية المنفّذ وإيصاله والهدف والحالة السابقة والتثبيت وقراءة الحالة والتفعيل والفشل الجزئي والرجوع والقرارات الأحدث والأثر المقاس.

لا يُعاد كتابة الماضي. القرار الذي استُبدل لاحقاً كان قد عاد فعلاً. فشل التثبيت لا يحوّل الجواب القديم إلى فشل؛ بل يضيف كسراً في الحلقة التالية. بذلك تبقى السببية والتعويض ممكنين.

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

أعاد محرّك السياسة نتيجة، أما التنفيذ فظلّ حدثاً آخر

لماذا هذا مهم

الخلاصة

الجواب سبق الفعل

الرقم ينسّق البرمجيات ولا يعيّن صاحب السلطة

القالب يصف البنية لا حقيقة المحتوى

«معالجة السياسة» لها أكثر من نهاية

داخل «النتيجة» طبقات متعددة

موثوقية النقل ليست تنفيذ السياسة

المصادر

سياق أعمق للملف الشخصي

الدائرة الاستراتيجية

تحالف القيادات

إحاطة الدائرة الاستراتيجية

إحاطة تحالف القيادات