الخلاصة

  • تقترح draft-ietf-netconf-error-registries-00 سجلين لدى IANA لوسوم أخطاء بروتوكولات YANG وهوياتها، لكن النسخة الأولى ما زالت غير مكتملة ولا تجعل الاسم دليلاً على السبب الجذري.
  • يجب أن تحتفظ الأتمتة بالجلسة والعملية وهوية الطلب وقرار التفويض والمسار والهوية المقيدة بالوحدة والمعلومات المنظمة ونتيجة المعاملة والمعالجة وإعادة القراءة وأثر الخدمة.

تتلقى المنظومة invalid-value فتقرر إعادة المحاولة.

يبدو القرار منضبطاً: هناك اسم ثابت يمكن وضعه في قاعدة. لكن RESTCONF يسمح للوسم نفسه بأن يصاحب HTTP 400 أو 404 أو 406. وعند حماية مورد من الكشف، قد يرد الخادم بـ404 مع invalid-value كي لا يؤكد حتى وجود المورد. الجواب صحيح لأنه لا يكشف الحقيقة كلها.

هذه هي الحدود التي تجعل draft-ietf-netconf-error-registries-00 مهمة. نُشرت في 30 سبتمبر 2026 بوصفها وثيقة نشطة لفريق NETCONF، وتقترح «قائمة أخطاء بروتوكولات YANG» و«سجل هويات أخطاء YANG». الغاية أن يتوقف كل تنفيذ عن جمع قائمته الخاصة من عدة RFCs.

النسخة 00 مسودة إنترنت تستهدف Standards Track وتنتهي في 3 أبريل 2027. ليست RFC، ولا سجلاً معتمداً لدى IANA، ولا دليلاً على تنفيذ أو توافق تشغيلي. صفحاتها الخمس تفتح مسار الحوكمة ولا تنهيه.

يفترض السجل الأول أن يحفظ error-tag والقيم الصالحة لـerror-type وerror-severity وerror-info والوصف والمرجع. أما الثاني فيحفظ اسم الهوية وهويتها الأساس حيث تنطبق ومعلومات إضافية والمرجع. وتقترح المسودة سياسة IETF Review لكليهما.

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

لكن النسخة 00 تكشف أيضاً مقدار الدقة المطلوبة. أوصاف الحقول الثلاثة الأولى ما زالت TBD. وتقول إن المحتويات الأولية مأخوذة من الملحق A في RFC 6241، ثم تدرج خمسة وسوم فقط: in-use وinvalid-value وtoo-big وmissing-attribute وbad-attribute. ويتابع الملحق بعد ذلك بقيم منها access-denied وresource-denied وrollback-failed وdata-missing وoperation-not-supported وoperation-failed وmalformed-message.

وتحمل قائمة الهويات آثار التحرير الأولي. تتكرر filter-unsupported وinsufficient-resources وno-such-subscription. كما تغيب هويات موجودة في المراجع المذكورة: يحتوي RFC 8639 على stream-unavailable وsuspension-timeout وunsupportable-volume، ويحتوي RFC 8641 على cant-exclude وno-such-subscription-resync وon-change-unsupported وon-change-sync-unsupported وsync-too-big. وتشير المسودة إلى RFC 5226، بينما RFC 8126 هو الإصدار الحالي من BCP 26 وقد حل محله.

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

حتى السجل الكامل لن يصبح تقرير حادثة.

لا يختزل RFC 6241 خطأ NETCONF في رمز واحد. قد يحمل الرد عدة عناصر <rpc-error>. ويمكن لكل عنصر أن يحدد الطبقة المفاهيمية ووسم البروتوكول والخطورة ووسم التطبيق الخاص بالنموذج أو التنفيذ ومسار XPath ورسالة بشرية ومعلومات منظمة. هذه أبعاد أدلة مختلفة وليست حقولاً تجميلية.

يوضح RFC 8640 الهرم في أخطاء الاشتراك. ترتبط filter-unsupported بالوسم الأوسع invalid-value، وinsufficient-resources بـresource-denied، وon-change-unsupported بـoperation-not-supported، وsync-too-big بـtoo-big، وunchanging-selection بـoperation-failed. وتُنقل الهوية الأدق في error-app-tag مع اسم الوحدة، مثل ietf-subscribed-notifications:no-such-subscription.

حتى هذه الهوية لا تُقرأ خارج العملية. تختلف الهوية الأساس الممكنة بحسب ما إذا كانت RPC لإنشاء الاشتراك أو تعديله أو حذفه أو إنهائه أو إعادة مزامنته. وفي الإنشاء والتعديل يمكن أن يحمل error-info اقتراحات لمعاملات طلب لاحق. حذف العملية والوحدة والتلميحات يعني تحويل دليل مركب إلى كلمة وحيدة.

توضح unchanging-selection معنى الضغط المقصود. يسمح RFC 8641 بها عندما يشير الاختيار إلى بيانات غير موجودة أو إلى بيانات لا يحق للمستقبل قراءتها. وقد تظهر أيضاً بعد تغير التفويض بحيث لا تعود التحديثات المرئية ممكنة. تصحيح المسار، والحصول على صلاحية، وإعادة بناء المرشح بعد تغير السياسة إجراءات مختلفة. يجمعها البروتوكول لحماية التجريد ومنع تسريب المعلومات.

وتحمي no-such-subscription الحدود نفسها. وفق RFC 8639 قد يكون المعرّف غير موجود، أو يعود إلى مشترك آخر، أو يشير إلى اشتراك مضبوط لا تنطبق عليه RPC. يحصل الطالب على النتيجة الآمنة اللازمة: لا يمكن لهذه العملية أن تعمل على هذا المعرّف. ولا يحصل على نافذة تكشف سجلات الخادم.

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

السجل سلطة على الأسماء، لا عرّاف للأحداث.

يبدأ الحد الأدنى من الإيصال قبل الخطأ: البروتوكول والجلسة وRPC ومعرّف الطلب والفاعل المصادق عليه وقرار التفويض. ثم يحفظ datastore والمسار والوسم العام والهوية المقيدة بالوحدة وهويتها الأساس وerror-info وإصدار الخادم والوحدات ونتيجة المعاملة. وبعد التدخل يسجل التغيير المصرح به وإعادة قراءة الحالة والنتيجة المرصودة في الخدمة.

تمنع هذه السلسلة مساويات زائفة. لا يثبت 404 عدم الوجود. ولا تثبت هوية تطبيقية سبباً مادياً. ولا يثبت قبول طلب تالٍ تغير الحالة. ولا يثبت تغير الحالة عودة الخدمة.

يقدم مبدأ Heng Lu للمواصفة الأولية الدنيا توزيعاً سليماً للمسؤولية. يحدد مسار المعايير أصغر مفردات قابلة للتشغيل البيني وقواعد توسيعها. أما القرار اللاحق فيبقى لدى من يملك الوقائع اللاحقة: الخادم والمشغل ومالك الخدمة. يركز السجل حوكمة الاسم ولا يصادر الحكم السببي في الموقع.

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

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

المصادر