كُتبت المتطلبات، لكن الحل لم يُثبت بعد

الخلاصة

• تصف draft-ietf-netmod-yang-versioning-reqs-14 المشكلات وتضع خمس مجموعات من المتطلبات، من دون أن تبحث حلاً بعينه أو تؤيده.
• حالة WG Document وعبارة I-D Exists وخريطة البنود ووسوم BC/NBC تثبت وجود توثيق قابل للقراءة؛ ولا تثبت صحة التصنيف أو حماية عميل قديم أو نجاح الترحيل أو أمان التشغيل.

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

لقد عوملت خطة الاختبار كأنها نتيجة الاختبار.

تحمل المراجعة 14 من YANG Module Versioning Requirements تاريخ 20 يوليو 2026، ويذكر غلافها أن المسار المقصود Informational. ويعرضها Datatracker بوصفها Internet-Draft نشطة لدى مجموعة NETMOD، وWG Document بحالة IESG هي I-D Exists. يرسم الملخص الحد بدقة: الوثيقة تصف المشكلات وتحدد متطلبات أي حل، لكنها لا تبحث حلاً محدداً ولا توصي به.

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

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

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

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

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

تطلب المجموعة الخامسة إرشاداً ومسار انتقال من YANG 1.0/1.1 وشرح أثر تغيير المخطط غير المتوافق على instance data والمراجع. يوضح RFC 9195 طريقة تعريف content-schema للبيانات، غير أن قابلية استخدامها تحت مخطط آخر تظل رهناً بالمراجعات وfeatures وdeviations والنطاق والتوافق. لذلك يجب أن يحصي إيصال الترحيل القيم المعاد تسميتها والمحذوفة والمولدة والمملوءة افتراضياً والمرفوضة، وأن يختبر ثوابت المعنى ويبرهن أن الرجوع يستطيع قراءة الحالة الجديدة.

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

المصادر الأولية

تضم الحزمة الرسمية المجمدة المراجعة 14، وسجل Datatracker، وتاريخه، وقائمة وثائق NETMOD، إضافة إلى RFC 2119، وRFC 6020، وRFC 7950، وRFC 8049، وRFC 8299، وRFC 8525، وRFC 9195.