الخلاصة

  • لا يلغي YANG 2.0 الإصدارين 1 و1.1، ويمكن للنموذج الكامل أن يجمع وحدات بلغات مختلفة؛ غير أن قواعد include وimport صُممت باتجاه غير متناظر.
  • تسمح حالة import بلا revision ببقاء الوحدة القديمة A مع B بعد نقلها إلى 2.0، فتحول دون ترقية متسلسلة. لكنها لا تثبت اختيار العميل أو المخطط الفعّال أو التوافق أو التشغيل الفعلي.

تبدأ المسألة من شاشة خضراء. نُقلت B إلى YANG 2.0، بينما بقيت A بلغة YANG 1.1 وكانت تستورد B من دون تحديد revision. يعمل الخادم وتظهر الوحدتان في قائمته. قد يكون كل ذلك مطابقاً للمسودة، لكنه لا يبرهن أن عميلين حصلا على البايتات نفسها أو اختارا revision نفسها أو كوّنا شجرة schema متطابقة.

تنص المسودة revision 00، المؤرخة في 6 يوليو 2026، على أن YANG 2.0 لا يجعل RFC 6020 أو RFC 7950 متقادمين، وأن نموذج بيانات كاملاً قد يضم وحدات مكتوبة بأكثر من إصدار للغة. ويسجلها IETF Datatracker كـ Internet-Draft نشطة لفريق NETMOD. يشير رأس الوثيقة إلى Standards Track، لكنها ليست RFC ولا دليلاً على تنفيذ أو نشر.

عدم التناظر هو مسار الانتقال

يشترط القسم 12 أن تضم وحدة 2.0 وحدات فرعية من 2.0 فقط. ولا يجوز لوحدة 1 أو 1.1 أن تضم وحدة فرعية من 2.0، أو أن تستورد وحدة 2.0 مع تحديد revision. أما وحدة 2.0 فيجوز لها استيراد وحدة من YANG 1 أو 1.1 مع تحديد revision.

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

ثم تعالج المسودة وضع A وB. إذا استوردت A القديمة الوحدة B بلا revision ثم انتقلت B إلى 2.0، يجوز للخادم تنفيذ A وB معاً. عليه إعلان الوحدتين وفق قواعد التنفيذ، ويُستحسن أن يعلن A وأحدث revision من B ما زالت مكتوبة بـ YANG 1 أو 1.1. والغاية المعلنة منع انتقال تحديث B على شكل سلسلة تجبر A ثم كل من يعتمد عليها على إعادة الكتابة.

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

الإعلان له نطاق إثبات محدد

يمنع القسم 5.6.4 الخادم من تنفيذ أكثر من revision واحدة للوحدة ذاتها، ويميز بين وحدة implemented ووحدة import-only. ينظم RFC 8525 هذا الإعلان في module sets مع أدوار المطابقة وfeatures وdeviations ومعرّفات التغيير.

تثبت هذه القائمة ما أعلنه الخادم في لحظة معينة: وجود A، ومراجعات B المدرجة، ودور كل واحدة. لكنها لا تثبت الملف الذي قرأه العميل، ولا طريقة حل import غير المحدد، ولا نسخة parser، ولا تطابق المخطط الفعّال الناتج بين عميلين.

ولا تسد الأدوات المجاورة هذه الفجوة وحدها. يحسن module versioning هوية المراجعات، وتحدد Semver نطاقات، وتصف packages مجموعة، وتصنف schema comparison التغييرات، ويساعد اسم الملف على العثور على مادة. لا يحل أي منها محل سجل resolver والنتيجة المجمعة والتحقق والتشغيل.

سلّم الأدلة بعد التعايش

يتطلب ادعاء التوافق ثماني طبقات:

  1. حفظ البايتات الدقيقة والمصدر وnamespace وإصدار اللغة وrevision والهاش لكل وحدة ووحدة فرعية؛
  2. تسجيل إغلاق import/include كاملاً والاختيار عند كل import بلا revision؛
  3. التقاط YANG Library كاملة مع الأدوار وfeatures وdeviations وهوية module set والتوقيت؛
  4. تسجيل هوية parser أو compiler والتشخيص وبصمة معيارية للمخطط الفعّال؛
  5. اختبار عينات صحيحة وحالات خاطئة عمداً مقابل المخطط المجمد؛
  6. مقارنة traces لعملاء مستقلين؛
  7. اختبار القراءة والتعديل وRPC وaction وnotification والفشل وrollback؛
  8. مراقبة مخزني intended وoperational اللذين يميز بينهما RFC 8342، ثم سلوك الخدمة والاستعادة.

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

قيمة المسودة دقيقة: تمنع تحويلاً متسلسلاً لا حاجة إليه. أما إثبات العقد الفعّال لكل عميل فيبقى عملاً مستقلاً.

المصادر