الخلاصة

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

كلمة واحدة ومحوران مختلفان

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

هذا الحد مفيد لأن تصنيف YANG المعتاد، config true، لا يعبّر عن كل الأشجار المختلطة التي تظهر في الأجهزة الفعلية. قد يحتاج الخادم إلى إنشاء عنصر في قائمة لا يستطيع العميل حذفه، مع السماح له في الوقت نفسه بضبط العناصر التابعة أو إضافة عناصر أخرى. كانت التطبيقات تشرح هذا الرفض في وثائقها؛ أما draft-ietf-netmod-immutable-flag-14 فيجعل السلوك قابلاً للاكتشاف آلياً.

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

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

لا تصل السمة إلا إذا طلبها العميل

لا يظهر الوسم في كل استجابة إعداد. يطلب العميل with-immutability عند قراءة مخزن النظام أو المخزن المقصود أو التشغيلي. ويكون الطلب غير صالح إذا وجّه إلى مخزن آخر بحسب المقترح. يستطيع عميل NETCONF البحث عن وحدة ietf-immutable-annotation في معلومات مكتبة YANG، بينما يستطيع عميل RESTCONF اكتشاف معرّف القدرة المحدد في المسودة.

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

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

قد يعني الغياب أن الحالة صحيحة

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

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

تضيف القوائم والقوائم الورقية حداً آخر. ترتبط البيانات الوصفية بمثيلات معينة لا بمفهوم القائمة المجرد. وقد تختلف العناصر داخل القائمة الواحدة. وبفعل قواعد بيانات YANG الوصفية يمكن أن يرث سلوك القائمة من الأب بينما يحمل عنصر بعينه حالته الخاصة. وفي قائمة مرتبة قد تشمل الحالة الموروثة منع الإضافة والحذف وإعادة الترتيب. عبارة عامة مثل «الحقل مقفل» لا تقول أي عملية أصبحت ممنوعة.

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

ظهور القيمة في running لا ينقل ملكيتها إلى العميل

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

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

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

فحص صلاحية الوصول يسبق فحص السمة

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

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

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

إيصال مصدر له حدود زمنية

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

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

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

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

تفاوت التبني جزء من التصميم

عند موعد إغلاق البحث، كانت المراجعة 14 قد حصلت على موافقة IESG ودخلت طابور محرر RFC، مع بقائها مسودة إنترنت نشطة. وأظهر تقرير التحقق من YANG في 10 سبتمبر/أيلول 2026 صفراً من الأخطاء والتحذيرات. هذه حقائق عن مسار الوثيقة، لا دليلاً على الانتشار بين المنتجات أو الشبكات.

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

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

المصادر