الخلاصة

  • تعرّف draft-ietf-netmod-immutable-flag-14 وسم immutable الذي يقدمه الخادم، ومعامل الاسترجاع الصريح with-immutability. الآلية تصف سلوكاً موجوداً ولا تنشئه.
  • يخص الوسم نسخة عقدة بيانات، وقد يرثه الابن من الأب أو يعيد ضبطه صراحة. لذلك لا يحفظ المسار المنفرد أو الجدول المسطح النطاق الكامل للقيد.
  • يثبت خطأ invalid-value رفض طلب محدد. أما الثبات عبر المستخدمين والبروتوكولات والزمن، وتوافق مخازن البيانات، والحالة التشغيلية والتعافي، فكلها تحتاج إثباتاً آخر.

قد تعرض منصة الأتمتة إيصالين متجاورين: قراءة تحمل immutable=true، ثم محاولة كتابة بقيمة مختلفة تنتهي بـ invalid-value. يثبت الإيصالان أن الخادم أعلن قيداً وطبقه على ذلك الطلب. لكنهما لا يثبتان أن البايتات لن تتغير أبداً.

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

يسجل Datatracker النص المؤرخ في 2 يوليو 2026 بوصفه Internet-Draft نشطاً ضمن NETMOD وموجهاً إلى Standards Track. حالة التحرير والمراجعات وتقرير YANG تتعلق بالوثيقة؛ ولا تقيس منتجاً مسمى أو انتشاراً أو نتيجة في شبكة حية.

معنى الرد يبدأ من السؤال

لا يعيد الخادم الوسم افتراضياً. في NETCONF يضيف العميل with-immutability إلى <get-data>، وفي RESTCONF يستخدم معامل GET بلا قيمة. لا يصح الطلب إلا مع مخازن القراءة <system> و<intended> و<operational>. ومع مخزن آخر تفرض المسودة unknown-element. وإذا حمل معامل RESTCONF قيمة غير متوقعة، فالنتيجة HTTP 400 مع invalid-value.

إعلان القدرة سجل مستقل. يبحث NETCONF في YANG Library عن ietf-immutable-annotation، بينما يعلن RESTCONF عنوان capability مخصصاً. يثبت الإعلان أن الخادم يدعي فهم الواجهة، لا أنه وسم كل نسخة بصورة صحيحة أو نفذ الميراث أو غطى كل طريق للكتابة.

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

الشجرة جزء من الدليل

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

لهذا يفقد سجل الأوراق الموسومة true مصدر الميراث، بينما قد يخفي سجل الأب وحده استثناءً قابلاً للتغيير. يقيد RFC 7952 مكان الوسم أيضاً: يمكن وسم مدخل list أو leaf-list بعينه، أما المجموعة كلها فلا تصبح immutable إلا بالميراث من الأب.

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

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

قد يسبق قرار الوصول قرار عدم التغيير

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

عند تطبيق NACM، يأتي فحص الوصول أولاً. يتلقى المستخدم غير المخول access-denied، وقد لا يصل الخادم إلى اختبار immutable. لذلك لا يثبت اختلاف الخطأ بين مستخدمين أن الخاصية نفسها تعتمد على المستخدم؛ بل يفرض إعادة بناء ترتيب القرار.

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

يظل الخادم قادراً على التغيير

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

قد توجد الخاصية من دون إظهار <system>، وليس كل system configuration غير قابل للتغيير. لذلك لا ينبغي اختزال بنية الإعدادات كلها في هذا الوسم. وقد تظهر نسخة القيمة أو تختفي في running بينما تظل القيمة الفعلية في intended كما هي.

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

ثمانية إيصالات بدلاً من حكم واحد

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

تضم الحزمة الأولية المغلقة المسودة 14 وسجل Datatracker وتاريخه، وRFC 7952 و7950 و8342 و8525 و8526 و8527 و6241 و8040 و8341 و9907، وsystem-configuration 20: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-immutable-flag-14; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/history/; https://www.rfc-editor.org/rfc/rfc7952.html; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc8342.html; https://www.rfc-editor.org/rfc/rfc8525.html; https://www.rfc-editor.org/rfc/rfc8526.html; https://www.rfc-editor.org/rfc/rfc8527.html; https://www.rfc-editor.org/rfc/rfc6241.html; https://www.rfc-editor.org/rfc/rfc8040.html; https://www.rfc-editor.org/rfc/rfc8341.html; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-20; https://www.rfc-editor.org/rfc/rfc9907.html.

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