الخلاصة

  • تضيف مسودة نشطة من مجموعة NETCONF قيد revision دقيق أو version دلالي متوافق إلى اشتراك YANG-Push، كما تضيف إصدار الوحدة ومعرّف محتوى YANG Library إلى إشعارات بدء الاشتراك وتعديله.
  • تساعد هذه الإشارات على رفض بعض حالات انجراف المخطط أو اكتشافها، لكنها لا تثبت توافق الوحدات المستوردة، ولا أن المستقبل حمّل المخطط الصحيح، ولا أن التحويل والسياسة والتفويض والأثر الفعلي بقيت صحيحة.

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

في YANG-Push يوجد عمر للاشتراك وعمر آخر لمكتبة المخططات. يصف الاشتراك البيانات المختارة وسياسة الإرسال، بينما تحدد وحدات YANG وعمليات import وdeviation وidentity الفعالة شكل تلك البيانات. يمكن لاشتراك مضبوط أن يبقى بعد إعادة التشغيل أو ترقية البرنامج، ويمكن للمكتبة أن تتغير في اللحظة نفسها.

تعالج draft-ietf-netconf-yang-notifications-versioning-16، المؤرخة في 17 سبتمبر 2026، هذه الفجوة المحددة. يسجلها Datatracker بوصفها Internet-Draft نشطة ضمن مجموعة NETCONF، مرفوعة إلى IESG لمسار Proposed Standard، مع انتهاء IETF Last Call في 29 سبتمبر. لا تزال مسودة، وليست RFC نهائية ولا شهادة امتثال لمنتج.

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

تثبيت أثر محدد أم قبول تطور معلن

يحدد قيد revision تاريخًا دقيقًا للوحدة. وهو مناسب حين تكون إعادة البناء أهم من الاستمرار التلقائي. إذا لم يستطع الناشر توفير ذلك الإصدار يعيد revision-unsupported، ولا يختار بديلًا قريبًا في صمت.

أما قيد version فيطلب أحدث إصدار دلالي متوافق مع الشرط. وهو يسمح بالتطور داخل حد معلن. إذا لم يوجد إصدار مقبول تكون النتيجة version-unsupported. وإذا تعارض revision مع version في الطلب نفسه، يسجل incompatible-revision-and-version هذا التعارض. وترد الحالات الثلاث كأخطاء RPC من فئة application وبوسم invalid-value.

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

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

وعند البدء أو الاستمرار تحمل subscription-started وsubscription-modified اسم الوحدة وrevision وversion اختياريًا وyang-library-content-id. ويعد تغيّر revision أو version أثناء حياة الاشتراك تغيّرًا في سياسة الاشتراك، فيلزم إصدار subscription-modified.

الإصدار المعلن لا يثبت ما حمّله المستقبل

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

يمكن لمستودع المخططات أن يحتوي الملف الجديد بينما تعمل العملية بنوع مولد من نسخة أقدم. قد يقبل parser قيمة identity جديدة، ثم يحولها التخزين إلى unknown. وقد تكتب مرحلة التحويل حقلًا جديدًا بينما تستمر قاعدة التنبيه في قراءة المسار السابق. تمر فحوص الصحة كلها، ويبقى المعنى منقسمًا.

لذلك ينبغي وصل إيصال revision بأدلة الكود الجاري: build الناشر والمستقبل، معرّف الاشتراك، القيد المطلوب، مجموعة الوحدات الفعلية، لقطة YANG Library وبصمتها، بصمة المخطط المحمل، إصدار decoder والتحويل، ونتيجة replay لمجموعة ثابتة. تطابق الإصدار خانة واحدة في هذا السجل.

هذه هي أولوية الكود العامل: المواصفة تنسق القاعدة، والتنفيذ المرصود يثبت ما جرى. أظهر تحقق Datatracker في 28 سبتمبر صفر أخطاء وصفر تحذيرات لوحدة ietf-yang-push-revision. تلك بينة على أثر النموذج أمام أدوات التحقق، وليست بينة على موجه أو جامع أو قرار آلي.

كلمة «متوافق» لا تعرف كل اعتماد محلي

توفر أعمال YANG Module Versioning وYANG Semantic Versioning لغة لتمييز التغيير المتوافق من الكاسر للتوافق. بهذه اللغة يمكن للاشتراك أن يطلب نطاقًا مفيدًا. لكن مؤلف الوحدة لا يعرف كل افتراض غير موثق في كل مستهلك.

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

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

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

قد تتغير وحدة مستوردة فيما تبقى الوحدة المباشرة ثابتة

تعيد وحدات YANG استخدام typedef وgrouping وidentity من وحدات أخرى. لذلك قد يحتفظ اسم الوحدة المباشرة بrevision وversion نفسيهما بينما تتغير تبعية تمنح قيمة ما معناها. مراقبة الوحدة المباشرة وحدها تترك ثغرة في شجرة الاعتماد.

يوسع content-id في YANG Library مجال الكشف. يعرفه RFC 8525 بأنه معرّف خاص بالتنفيذ لمحتوى المكتبة الحالي. إذا تغير، يعرف المستقبل أن مخزون المخططات في الجهاز تحرك، ويمكنه البحث عن تغير غير ظاهر في الوحدة المباشرة.

لكنه إنذار واسع لا تشخيص دقيق. قد يتغير بسبب وحدة لا علاقة لها بالاشتراك. ولا يحدد أي import تغير. وليس hash عالميًا للمقارنة بين منتجات مختلفة. اختلافه يعني «اجلب المكتبة وقارنها»، لا «هذا الاشتراك غير متوافق». وثباته يدعم الاستمرارية ضمن سلوك الناشر من غير أن يثبت كل تكافؤ دلالي.

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

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

إشعار التعديل لا يجعل الانتقال ذريًا

عند وصول subscription-modified قد تبقى رسائل صيغت بالمخطط السابق في الشبكة أو الطابور. وقد ترى workers متوازية الحدث بترتيب مختلف. وقد يحدث سجل metadata قبل أن تحمل كل عملية binding الجديد.

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

حتى subscription-terminated يثبت قرار الناشر فقط. لا يثبت أن الطوابير القديمة فرغت أو أن cache توقفت عن تحريك الأفعال أو أن المهام المشتقة ألغيت. يجب أن يصل إشعار الإنهاء إلى إجراءات الاحتواء والإيقاف والتأكيد المحلية.

والقدرة yang-push-module-revision-supported إعلان دعم. تساعد العميل على اختيار الإجراء، لكنها لا تثبت أن كل انتقال سيبلغ بصورة صحيحة. يلزم اختبار الترقية وإعادة التشغيل والفقد والتكرار وإعادة الترتيب.

التدفق الحي هو أول الأدلة وليس آخرها

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

لا تستعير طبقة سلطة طبقة أخرى. استمرار التسليم لا يثبت صحة التفسير. صحة التفسير لا تمنح حق الفعل. التفويض لا يثبت نجاح commit. والأثر المرصود لا يثبت وحده أن السبب هو القرار المقصود.

فصل Reality Layers يحسن التحقيق. إذا تغير content-id وأظهر diff وreplay عدم وجود أثر، يغلق التغير بوضوح. إذا بقي revision ثابتًا واختلف القرار، ينتقل الفحص إلى المستهلك. وإذا كان الفعل تقنيًا صحيحًا لكن هويته غير مخولة، فالمشكلة في التفويض لا في YANG.

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

تغيير شرط الإصدار تغيير في سياسة حساسة

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

يظل النقل الآمن والمصادقة المتبادلة في NETCONF وRESTCONF ضروريين. ويظل NACM مسؤولًا عن تقييد الوصول إلى الإعداد والحالة. ينبغي أن يسجل التدقيق الهوية والطريقة والقيمة السابقة والجديدة والاشتراك وحالة المكتبة وسبب الموافقة. ولا ينبغي لآلية استعادة التوفر أن ترخي شرطها بنفسها كي تعيد المؤشر الأخضر.

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

ادعاءات التنفيذ تبدأ قائمة الاختبارات ولا تنهيها

تذكر المسودة حالات أبلغ عنها المؤلفون في Huawei VRP و6WIND VSR وCisco IOS XR، مع مجموعات فرعية مختلفة. تفيد هذه المعلومات نقاش الجدوى واهتمام السوق. لكنها ليست تحققًا مستقلًا ولا برهان تشغيل بيني شامل.

يختبر التأهيل revision المقبول وغير المقبول، وversion غير المتاح، وتعارض القيدين، واختيار النسخة المتوافقة، والإنهاء بعد reboot، والتعديل أثناء التشغيل، وتغير الوحدة المباشرة، وتغير import وحده، وتغير مكتبة غير ذي صلة. ثم يضيف فقد إشعار دورة الحياة وتكراره وإعادة ترتيبه وrollback.

تربط النتيجة بالbuild الفعلي والتقاط الرسائل والحالة الدائمة للمستقبل. وجود اسمين في قسم تنفيذ لا يثبت أن تنفيذين مستقلين اتفقا على حد الانتقال نفسه.

اجعل الترقية قابلة لإعادة البناء والرجوع

قبل التغيير، تحفظ YANG Library والوحدات وbindings المولدة وصورة decoder ومواد replay. يقارن المرشح مع الاعتمادات العابرة، ويختبر القبول والرفض وأول حد غير متوافق.

أثناء التغيير، يسجل موضع إشعار دورة الحياة. إذا تغير content-id تجلب المكتبة بدل تخمين السبب. توقف الأفعال غير القابلة للعكس حتى ينجح replay المحلي. إذا لم يتحقق القيد يفشل النظام بوضوح ويحفظ السبب.

بعده، تقارن الكائنات المفكوكة والتحويلات والقرارات والآثار، وتراجع الطوابير وcache القديمة، ويختبر rollback منسق للناشر والمستقبل. النجاح ليس بقاء الاشتراك، بل القدرة على إثبات استمرارية المعنى المطلوب وتسمية ما بقي غير مؤكد.

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

المصادر