صُنِّف الفرق، لكن الترقية لم تُثبت بعد

الخلاصة

• تقارن draft-ietf-netmod-yang-schema-comparison-09 بين العبارات المحللة وشجرة البيانات الفعلية بعد التجميع، ثم تصنف التغييرات إلى تحريرية أو متوافقة رجعياً أو غير متوافقة رجعياً.
• تساعد النتيجة في مراجعة الإصدار واختيار النسخة الدلالية وتصميم تحويل البيانات. لكنها لا تثبت تطابق سياق الإدخال، أو غياب الفقد، أو التشغيل البيني، أو ثبات NACM، أو سلامة ترتيب النشر، أو تقارب الحالة التشغيلية.

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

نُشرت المراجعة 09 في 3 يوليو 2026. ويسجلها IETF Datatracker كمسودة Internet-Draft نشطة ضمن مجموعة NETMOD، لا كـRFC. ويعرض ملخص التحقق الحالي صفراً من الأخطاء وصفراً من التحذيرات. هذه حالة الوثيقة وأدوات فحصها، وليست دليلاً على التبني أو التوافق بين المنتجات أو نتيجة في الإنتاج.

لا بد من مقارنة شكلين للمخطط

تفصل المسودة بين parsed schema وcompiled schema. يبقى الشكل المحلل قريباً من شجرة العبارات المحملة قبل حل جميع المراجع والتحويلات. أما الشكل المجمّع فيبني النموذج الفعلي: يضم imports وsubmodules، ويحل uses وtypedef، ويطبق augment وdeviation وrefine، ويقيّم عبارات if-feature المفعلة.

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

لذلك تعرض المراجعة 09 تغييرات عقد البيانات المجمعة أولاً، ثم تقارن بقية العبارات المحللة من دون تكرار. وتشمل هوية التجميع اسم ومراجعة الوحدة القديمة والجديدة، والوحدات الفرعية المضمنة، والـfeatures المفعلة، والـimports المتسلسلة.

لا يعني الفرق الفارغ إلا أن هذه المدخلات المحددة لم تنتج فروقاً وفق القواعد. feature أخرى، أو مراجعة import مختلفة، أو deviation خاص بالجهاز، أو submodule آخر، كلها تصنع تجربة جديدة. لذا يجب أن يحفظ الإيصال الأول بصمات المصادر وهوية التجميع كاملة.

لكل تصنيف مصدر حكم

يصبح كل تغيير ED أوBC أوNBC. التغيير التحريري لا يبدل فضاء البيانات الصحيحة ولا يبطل وحدة مستوردة. والمتوافق رجعياً قد يوسع الفضاء من دون كسر المستوردين. وما يضيّق الفضاء أو قد يبطل مستورداً فهو غير متوافق.

ولا تكفي بداهة «النوع صار أوسع». فالانتقال من uint32 إلى uint64 يوسع المجال العددي، لكنه يغير تمثيل JSON وفق RFC 7951 من رقم إلى سلسلة. قد ينكسر العميل، ولهذا يمكن أن يكون التغيير NBC.

تُعد تغييرات pattern وwhen وmust غير متوافقة افتراضياً. أما description وreference وpresence فتحريرية افتراضياً، ومثيل الامتداد BC. ويستطيع المؤلف تجاوز هذه الافتراضات بعلامات دلالية مستمرة ed-change-at أوbc-change-at أوnbc-change-at.

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

التوافق الرجعي لا يعني ثبات السلوك

قد تكون إضافة leaf اختيارية BC، ومع ذلك يبدأ الخادم بملئها، والعميل بتسلسلها، والسياسة بقراءتها، والواجهة بعرضها. ويمكن لتغيير default أن يبدل السلوك الفعلي من دون لمس الإعداد المخزن. كما تغير when وmust وfeatures وdeviations مسارات التحقق والسطح الذي يعرضه كل جهاز.

لا تنفذ المقارنة RPCs، ولا تعيد تشغيل كل الإعدادات، ولا تراقب العملاء. يحدد RFC 8525 الوحدات والـfeatures والـdeviations التي يعلنها الخادم في YANG Library. لكن content-id هوية للمكتبة، وليس إثباتاً أن الشيفرة تنفذ كل قاعدة على نحو صحيح.

ويعمل NACM في RFC 8341 على محور مستقل. فقد تتغير المجموعات والقواعد وdefault-deny بينما يظل فرق المخطط صفراً، فتتغير العقد المقروءة والمكتوبة. ولهذا يجب اختبار مصفوفة الأدوار الفعلية.

التحويل يحتاج سجلاً للخسارة

تقول المسودة إن المخرجات قد تساعد أداة على تحويل instance data القديمة للمراجعة الجديدة. لكن المحول يظل من يقرر الحذف والربط والتطبيع وإدخال defaults والتوليد والرفض.

يوفر RFC 9195 نمطاً مناسباً لهوية المحتوى وأصله. ينبغي أن يربط إيصال التحويل بصمة النسخة القديمة وهوية مخططها بإصدار المحول وقواعده، وأن يحصي العقد المحذوفة والمولدة والمطبعة والمرفوضة. ثم تُبصم النتيجة، وتُفحص مقابل compiled schema المستهدف، وتُسجل اختبارات الرجوع أو الثوابت الدلالية.

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

تُفتح البوابات اللاحقة بالتنفيذ

تأتي بعد ذلك اختبارات التنفيذ: parsers أوخوادم مستقلة حين يلزم التشغيل البيني، وإعادة إعدادات وRPCs تمثيلية، وفحص error tags وdefaults والترميزات القياسية وتفاوض features وكل أدوار NACM المتأثرة. ويجب تثبيت binaries والوحدات والخيارات ومتجهات الاختبار.

ثم يُختبر ترتيب النشر. فالترقية المتدرجة تخلط عميلاً قديماً بخادم جديد والعكس، وقد تتباين features وdeviations بين النظراء. لا يحدد الفرق من يبدأ، ولا يضمن استمرار القياس عن بُعد، ولا يثبت أن النسخة القديمة تستطيع قراءة ما كتبته الجديدة عند rollback.

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

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

المصادر

المصادر الأولية: YANG Schema Comparison، المراجعة 09؛ سجل IETF Datatracker؛ YANG 1.1، RFC 7950؛ YANG Library، RFC 8525؛ NMDA، RFC 8342؛ NACM، RFC 8341؛ YANG Instance Data، RFC 9195؛ YANG Semantic Versioning، المراجعة 28؛ YANG Module Versioning، المراجعة 16. التسلسل الزمني: تاريخ Datatracker.