الخلاصة

  • يقصر RFC 9890 شرط التفرد على الاسم الأول لوحدة YANG ووحدتها الفرعية، وعلى نطاق أسماء XML للنسخة الأولى من الوحدة. أما المراجعات اللاحقة فعليها أن تحتفظ بهذه الهوية.
  • تثبت الهوية الثابتة الانتماء إلى سلسلة مراجعات واحدة، لا نسخة محددة. وإعادة بناء قرار تشغيلي تتطلب تاريخ المراجعة وملف المصدر وبيانات YANG Library للخادم والميزات والانحرافات والمخطط والحالة التشغيلية.

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

هذه هي الأهمية العملية لوثيقة RFC 9890. نُشرت في مسار المعايير في أكتوبر 2025 لتحديث تعليمات IANA الخاصة بتسجيل أسماء وحدات YANG. لا تضيف عملية شبكية، ولا تغير رسالة في البروتوكول، ولا توثق نشراً حقيقياً. إنها تجعل نص القاعدة مطابقاً للممارسة القائمة في تسجيل الوحدة ومراجعاتها.

كان RFC 6020 يقول إن جميع أسماء الوحدات والوحدات الفرعية في السجل يجب أن تكون فريدة، وكذلك جميع نطاقات أسماء XML. وإذا طُبق ذلك حرفياً على كل صف تاريخي بدت المراجعة الثانية للوحدة نفسها تكراراً ممنوعاً. يفصل RFC 9890 بين التخصيص الأول واستمرار السلسلة: يجب أن يكون الاسم الأول والنطاق الأول فريدين، ثم تحتفظ المراجعات اللاحقة بهما.

التكرار الصحيح يحفظ سلسلة النسب

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

ينظم RFC 7950 هذه العلاقة في YANG 1.1. تسجل عبارات revision التاريخ التحريري بما فيه الإصدار الأول. ويمكن لعبارة import أن تستخدم revision-date لاختيار نسخة محددة؛ وإذا غابت يظل غير محدد من أي مراجعة أُخذت التعريفات. ويمكن حتى استيراد مراجعات متعددة للوحدة نفسها عندما تفصل بينها بادئات مختلفة.

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

يعرض سجل IANA لمعاملات YANG هذه البنية علناً. تظهر ietf-yang-types في ملفات مؤرخة في 2010 و2013 و2025. ليست ثلاث جهات استولت على الاسم نفسه، بل ثلاث مراجعات منشورة في سلسلة واحدة. تستطيع IANA توثيق التنسيق العام ومراجع الوثائق، لكنها لا ترى أي ملف خزّنه متحكم أو حمّله جهاز.

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

سلطة السجل تتوقف قبل الخادم

السجل أداة تنسيق. يمكنه إثبات أن الهوية العامة خُصصت بإجراء معلوم وأن مراجعة ارتبطت بوثيقة. لكنه لا يراقب حزمة برمجية أو ذاكرة متحكم أو عملية عاملة أو ميزة مفعلة أو انحرافاً خاصاً بالمصنّع.

يبدأ الدليل الأقرب إلى التنفيذ من YANG Library في RFC 8525. يستطيع الخادم الإعلان عن مجموعات الوحدات والوحدات المنفذة أو المستخدمة للاستيراد فقط، والمراجعات ونطاقات الأسماء والميزات المفعلة ووحدات الانحراف والمخططات ومخازن البيانات. تستخدم الوحدة المنفذة مراجعة واحدة عبر مخازن ذلك الخادم، في حين يمكن أن تتعايش عدة مراجعات كاعتماديات import-only.

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

لذلك تربط اللقطة القابلة للتدقيق الاستجابة بنقطة وصول موثقة وهوية الخادم ووقت الجمع. وتحفظ content-id وmodule-set وschema وdatastore وحالة implemented أو import-only والمراجعة ونطاق الأسماء والميزات والانحرافات وموقع المصدر. وفي البناء المضبوط يضاف الملف المسترجع وبصمته. عبارة «الوحدة موجودة» تحذف المعلومات التي ستفسر لاحقاً اختلاف جهازين.

المخطط الفعلي ليس النتيجة بعد

يعرف RFC 8342 مخطط مخزن البيانات بأنه مجموعة عقد المخطط للوحدات المدعومة بعد أخذ الميزات المفعلة والانحرافات في الحسبان. لذلك قد يتشارك خادمان الاسم والمراجعة ويقدمان مخططين فعليين مختلفين.

وجود عقدة في المخطط لا يثبت تطبيق الإعداد. قد يحتوي <running> على إعدادات ما زالت تحتاج إلى تحويل. يمثل <intended> ما يحاول النظام تطبيقه بعد التحويلات. ويجمع <operational> الإعداد المطبق مع حالة النظام. قد تفصل بينها قيود العتاد والبروتوكولات والأجهزة الأخرى وزمن الانتشار.

ينبغي إبقاء الأسئلة منفصلة: هل سُجلت الهوية العامة؟ ما الذي عرفه ملف المراجعة؟ هل راجعنا البايتات نفسها؟ أي مراجعة أعلن الخادم عنها؟ ما الميزات والانحرافات التي صنعت مخططه؟ من أجاز الإعداد؟ ماذا بقي في <intended>؟ ماذا ظهر في <operational>؟ وما الأثر الذي قاسه المشغل؟

لا تثبت إجابة طبقةً تالية. صف IANA لا يشهد للخادم، وYANG Library لا تمنح إذن الإعداد، ووجود قيمة في <running> لا يثبت تطبيقها، والحالة التشغيلية وحدها لا تثبت نتيجة العمل. هذا الفصل لا يقلل قيمة الدليل؛ بل يمنع تمديد سلطته إلى ما لا يراه.

قاعدة مشتركة صغيرة وقرار محلي

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

يتوافق ذلك كمبدأ تشغيلي مع ما يشرحه Heng Lu في Minimum Initial Specification and Localized Future Decision: يحدد المركز الحد الأدنى المشترك، وتبقى القرارات المستقبلية محلية. يحدد RFC 9890 الهوية الأولى وقاعدة استمرارها، ولا يحدد موعد ترقية الأجهزة.

وتذكرنا مقالة Running Code as Primary Evidence بأن النص الصحيح لا يكشف البرنامج العامل. السجل والمصدر والحزمة وLibrary وحالة مخزن البيانات أدلة لمزاعم مختلفة، ولا بد من وصلها دون دمجها.

أما Reality Layers and Symbolic Power فتفسر جاذبية الإشارة الخضراء الواحدة. تبدو واضحة لأنها تخفي الروابط الناقصة والمسؤولية المقسمة. للاسم سلطة رمزية مشروعة في التنسيق، لكنه لا يملك سلطة تثبيت المحتوى والتنفيذ والنتيجة.

المصادر