Summary

  • يعيّر RFC 9922 أنواعاً وتجميعات YANG قابلة لإعادة الاستخدام للتاريخ والتكرار والتحقق وحالة الجدول، لكنه يترك طبيعة الإجراء وحل تعارض الجداول خارج نطاقه صراحة. لذلك يمكن لحالة «مفعّل» أن تكون صحيحة من غير أن تسمّي صاحب السلطة الحالية على الأثر.
  • يقترح Daniel Kade «إيصال سلطة الواقعة» لربط نسخة الجدول وبصمته، والإجراء والهدف، والراعي المؤسسي، والسياسة الجارية، وهوية التنفيذ، والزمن والنتيجة. الاقتراح تشغيلي تحريري، لا متطلب من RFC ولا ادعاء بوقوع خلل معروف.

يصل الأمر إلى المستقبل ولا يصل معه سياقه كله

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

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

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

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

صلاحية RFC 9922 صلاحية زمنية محددة

نُشر RFC 9922 في مارس 2026 بوصفه وثيقة Standards Track من IETF تمثل إجماع المجتمع بعد المراجعة العامة وإقرار IESG. يعرّف وحدة ietf-schedule بأنواع وتجميعات مشتركة لجدولة أحداث أو سياسات أو خدمات أو موارد بحسب التاريخ والوقت. ويغطي الواقعة الواحدة والفترة والتكرار، من قواعد بسيطة إلى تمثيل قريب من iCalendar.

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

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

يحمل تجميع generic-schedule-params حقلاً اسمه validity. يعرّفه RFC بأنه اللحظة التي لا يعد بعدها الجدول صالحاً للبدء؛ فلا تنفذ الوقائع اللاحقة. وتضيف الحدود الدنيا والعليا للبداية والنهاية، وسلوك الإسقاط، حواجز زمنية أخرى.

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

النسخة الجارية ليست سلسلة موافقة

تجميعات الحالة في RFC 9922 مهمة للعمل اليومي. يمكن أن يكون الجدول مفعّلاً أو معطلاً أو منتهياً أو قديماً أو متعارضاً. ويمكن إظهار النسخة، وآخر تحديث، وعدد الوقائع، والواقعة السابقة والقادمة، وآخر فشل وعدد الإخفاقات.

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

تظهر الحدود بوضوح في مقارنة RFC 9922 مع DISMAN-SCHEDULE-MIB الأقدم. فالنص يربط حقولاً كثيرة، لكنه يسجل schedOwner على أنه “Not Supported”. ويشير أيضاً إلى أن الوحدات اللاحقة قد تحتاج حقلي المصدر والأسبقية عندما تأتي الجداول من جهات متعددة.

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

يمكن أن تكون النسخة 7 أحدث نسخة، من غير أن تكون أحدث قرار. ويمكن لعبارة «نُفذ بنجاح» أن تعني فقط أن المحرك استدعى العملية. أما السلطة المؤسسية الحالية فما زالت واقعة مستقلة.

يحمي NACM الطلب، ويحتاج التنفيذ المؤجل إلى هوية معلنة

يعرّف RFC 8341 نموذج NACM للتحكم في عمليات ومحتوى NETCONF وRESTCONF. ترتبط الجلسة الموثقة باسم مستخدم ومجموعات، ويطبق الخادم القواعد النافذة عند بدء معالجة الرسالة. ويمكن لهذه القواعد حماية إنشاء الجدول وتعديله وحذفه، وحماية الإجراءات التي تعرضها الوحدة المستهلكة.

لذلك ليس صحيحاً القول إن YANG يخلو من التحكم في الوصول. السؤال هو أي هوية وأي سياسة تحكمان واقعة تقع بعد شهور.

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

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

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

الساعة الموثقة لا تمنح إذناً

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

يحدد RFC 3339 صياغة التاريخ والوقت. ويتيح RFC 7317 إعداد المنطقة الزمنية وNTP في أنظمة YANG. أما RFC 8915 فيعرّف Network Time Security ليثبت هوية مصدر الوقت، ويوثق الرزم، ويمنع إعادة الإرسال، ويربط الرد بالطلب.

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

ينبغي للسجل أن يفصل بين دليل الوقت ودليل السلطة: المصدر والموعد المرصود وعدم اليقين في جانب، والراعي والسياسة والهوية وقرار السماح أو المنع في جانب آخر. جمعهما في ضوء أخضر واحد يخفي موضع الخلل.

حجز الموارد يوضح سطح القرار المؤجل

يشرح RFC 8413 حجز موارد هندسة المرور للاستخدام المستقبلي. يمكن حساب مسار LSP وحجز السعة الآن، مع تأجيل إنشاء المسار إلى بداية النافذة. ويطلب الإطار ربط معلومات LSP المستقبلي بالحجز لمعرفة سبب حجز المورد وإدارة الاستباق والتحرير بعد الإلغاء. تبقى سياسة المشغل حاكمة للنسب وإعادة التحسين.

يحوّل RFC 8934 الفكرة إلى آليات PCEP. يحفظ PCE ذو الحالة قاعدة للـLSP المجدول، ويبدأ PCC الإنشاء عند الموعد، ثم قد يزيله عند الانتهاء بحسب السمات. الطلب والحساب والمزامنة والتفعيل والحذف لحظات منفصلة.

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

إيصال سلطة الواقعة

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

يربط الإيصال:

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

لا يعني هذا موافقة بشرية كل دقيقة. يمكن لقرار موقّع أن يغطي فئة إجراءات ومجموعة أهداف وسقف خطر ونطاق وقائع. وينتهي عند تغير النسخة أو الراعي أو الهدف أو السياسة أو الأثر المطلوب.

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

الغرض أن تصبح إجابة «لماذا جاز تشغيل هذه الواقعة؟» دقيقة بقدر إجابة «متى عملت؟».

الاعتراضات تضبط الحجم الصحيح

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

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

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

الرابع هو عمومية RFC 9922. نعم، لا ينبغي للوحدة المشتركة معرفة كل إجراء. لهذا يوضع التحكم في الوحدة المستهلكة أو طبقة الضمان، مع احترام حدود المعيار بدلاً من اتهام العمومية بالإهمال.

حدود الدليل

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

الإيصال المقترح ليس متطلباً من IETF. يحل RFC 9922 مشكلة توافق محددة بوصفه وثيقة Standards Track توافقية، ويحيل مخاطر الإجراء إلى الوحدات التي تستخدم تجميعاته على نحو صحيح.

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

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://www.rfc-editor.org/info/rfc9922/
  5. https://www.rfc-editor.org/rfc/rfc9922.html
  6. https://www.rfc-editor.org/rfc/rfc8341.html
  7. https://www.rfc-editor.org/info/rfc8413/
  8. https://www.rfc-editor.org/rfc/rfc8934.html
  9. https://www.rfc-editor.org/rfc/rfc3339.html
  10. https://www.rfc-editor.org/rfc/rfc7317.html
  11. https://www.rfc-editor.org/rfc/rfc8915.html
  12. https://www.rfc-editor.org/rfc/rfc8342.html
  13. https://www.rfc-editor.org/rfc/rfc7950.html
  14. https://www.rfc-editor.org/rfc/rfc6241.html
  15. https://www.rfc-editor.org/rfc/rfc8040.html