الخلاصة

  • تمنح المراجعة 10 من مسودة المرشح الخاص كل جلسة NETCONF مساحة إعداد مستقلة، وتحدّثها ذريًا عندما يتغير running. ويجري كل commit تحديثًا ضمنيًا بنمط revert-on-conflict، فيتوقف عند أي تعارض غير محسوم.
  • يوزع الخياران الآخران الخسارة: يحفظ prefer-candidate القيمة الخاصة كي تحل لاحقًا محل القيمة الجارية، بينما يمحو prefer-running التعديل الخاص المتعارض. لا تثبت صلاحيات NACM ولا إعلانات القدرات لماذا فوّضت المؤسسة هذا الاختيار بعينه.
  • يلزم تفويض commit يربط أساس الفرع ومجموعة التعارضات والنمط المختار والقيم المفقودة وصاحب القرار والنطاق المعتمد والاختبارات وشروط confirmed commit وهدف التراجع. هذا مقترح Daniel Kade وليس مطلبًا من IETF.

تنتهي المساحات المنفصلة عند الجهاز نفسه

يوفر candidate datastore في RFC 6241 مساحة لتجهيز إعداد كامل قبل تفعيله. غير أن المساحة مشتركة، ويمكن لجلسة أخرى تعديلها. وهكذا قد يودع عميل، إلى جانب عمله، تغييرًا لم ينشئه وربما لم يره.

يمنع القفل بعض هذه الحوادث لكنه يعطّل العملاء الآخرين. وحتى القفل الجزئي في RFC 5717 لا يضمن أن يحتوي commit على تعديلات عميل واحد فقط، ولا يحل التحرير المتزامن للشجرة نفسها، كما يتطلب معرفة اعتماديات النماذج.

تعالج draft-ietf-netconf-privcand-10 هذا الخلط مباشرة. نُشرت في 24 أغسطس/آب 2026، وهي Internet-Draft نشطة ضمن مجموعة NETCONF وفي مرحلة Working Group Last Call ومقصود بها مسار Proposed Standard. ليست RFC بعد، ولا دليلًا على نشر فعلي أو إلزام عام.

في NETCONF يُتفاوض على النمط الخاص للجلسة كلها. تنسخ أول عملية معنية running إلى مرشح خاص بالجلسة، فلا تراه جلسات إعداد NETCONF الأخرى ولا تصل إلى تعديلاته. وعند إغلاق الاتصال أو فقدانه يُدمَّر المرشح وتُطرح التغييرات غير المودعة.

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

خصوصية الفرع تثبت ملكية المسودة، لا ملكية الخدمة.

يخص التعارض نقطة الانطلاق بقدر ما يخص القيمة

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

يربط تعريف التعارض بالنية المحتملة. يجب أن يكون كل من running والمرشح قد عدّل العقدة نفسها خلال فترة الإعداد، وأن يكون العميل ربما تصرف بطريقة مختلفة لو رأى نقطة البداية الجديدة. وقد يتعلق الأمر بالقيمة أو الوجود أو ترتيب المستخدم أو presence container أو leaf-list أو leaf أو بيانات YANG الوصفية. ويمكن للخادم إضافة فحوص واستخدام معرّف معاملة.

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

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

يحفظ اكتشاف التعارض وجود الخلاف؛ ولا ينشئ سلطة الحكم فيه.

الأنماط الثلاثة تحدد موضع الخسارة

revert-on-conflict إلزامي وافتراضي. يؤدي أي تعارض إلى فشل update من دون دمج. ويبدأ كل commit بتحديث ضمني بهذا النمط مهما كان الافتراضي المستخدم للتحديثات التلقائية. بعد الفشل يجب على العميل تعديل عمله أو طرحه أو استدعاء تحديث واعٍ بنمط مختار. ليست الوقفة عيبًا؛ فهي تحفظ لحظة يمكن فيها اعتماد الخسارة قبل وقوعها.

يحافظ prefer-candidate على القيم الخاصة المتعارضة ويدمج تغييرات running غير المتعارضة. وعند commit لاحق تستبدل القيم الخاصة القيم الجارية. الخاسر هو الغرض الذي دخل الإنتاج بعد إنشاء الفرع.

يدفع prefer-running القيم الجارية المتعارضة إلى المرشح ويمحو تعديلاته الخاصة في تلك المواضع. يبقى باقي الفرع، لكن جزءًا من الغرض الذي أعده صاحبه يختفي.

لا تمنح الأسماء شرعية. ليس المرشح أحدث بالضرورة في الزمن المؤسسي ولا أفضل مراجعة. وقد يحتوي running علاجًا طارئًا مؤقتًا يفترض أن تزيله صيانة معتمدة. الموقع في نموذج البيانات ليس مرتبة قرار.

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

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

لـ NETCONF وRESTCONF ساعتان مختلفتان للقرار

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

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

يغير ذلك موضع الاعتماد. قد تعيش جلسة NETCONF خلال تغييرات الإنتاج وسياسة NACM ونافذة الصيانة. أما RESTCONF فيضغط الإعداد والتفعيل في طلب واحد. لا يمكن نسخ خطوة بشرية موضوعة بين edit وcommit من بروتوكول إلى آخر بلا إعادة تصميم.

إذن الوصول ليس تفويضًا لإسقاط تغيير آخر

تتيح RFC 8341 لـ NACM تقييد القراءة والكتابة والتنفيذ بحسب المستخدم والمحتوى. وتصف المسودة update بأنها حساسة وتحذر من تغييرات غير مقصودة بسبب الوصول غير المصرح. المصادقة المتبادلة والنقل الآمن ضروريان.

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

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

والمقارنة دليل لا حكم. يمدد المشروع RFC 9144 كي يقارن المرشح الخاص، حين يدعم الخادم نقاط المرجع، مع running أو نقطة الإنشاء أو آخر update. تتضح الفروق، لكن أثر الخدمة وكمال الاعتماديات وصحة التفويض لا تُستنتج منها.

ما الذي يحفظه تفويض commit

لا حاجة إلى datastore بروتوكولي جديد. المطلوب تفويض commit قصير العمر يرتبط بحسم مدمر واحد.

يثبت التفويض الجهاز والـdatastore والجلسة أو الطلب والهوية المصادق عليها ومالك الأتمتة. ويربط نقطة الإنشاء وآخر update بمعرّف ثابت لمراجعة running. ثم يحفظ delta المرشح الدقيقة وكل التعارضات التي أبلغ عنها الخادم، مع سياق الخدمة أو الأسلاف الذي تضيفه السياسة المحلية.

يسجل الافتراضي المعلن والأنماط المتاحة، وهل كان update تلقائيًا أم صريحًا، والنمط الذي طُبق. وتُكتب الخسارة مباشرة: قيم running التي سيكتب فوقها prefer-candidate، أو التعديلات الخاصة التي محاها prefer-running، أو الحالة المفتوحة والخطوة التالية المسموح بها تحت revert-on-conflict.

تُرفق نسخة سياسة NACM لتوثيق إطار الوصول لا لتقوم مقام الموافقة. ويسمي التفويض إنسانًا أو مسار أتمتة مسؤولًا، مع السبب ونطاق الخدمة ونافذة الصيانة وحد الأثر وتاريخ الانتهاء. وترتبط به نتائج المقارنة والتحقق واختبارات الخدمة التمثيلية.

أخيرًا يحدد استخدام confirmed commit ومهلته ومعرّفاته المستمرة عند الحاجة، وإشارات الصحة وهدف التراجع الدقيق. ويسجل الإغلاق النتيجة وبصمة running الجديدة. إذا تغير أي افتراض—الحالة الجارية أو السياسة أو النافذة أو المراقب—انتهى التفويض.

هذا اقتراح Daniel Kade، وليس RPC أو عقدة YANG أو مطلب IETF. ووظيفته حفظ سبب القرار بعد زوال الجلسة والمرشح وعلامات التعارض.

إمكان العودة لا يشرعن الاختيار الأول

confirmed commit حماية قوية. إذا انقطعت جلسة العميل أثناء commit مؤكد من مرشح خاص، تعود running فورًا وتُطرح التغييرات المقترحة. يحد ذلك من خطر فقد قناة التحكم.

لكن التراجع يجيب عن قابلية العودة لا عن سلطة الفائز. قد يكون قرار متجاوز للتفويض قابلًا للعكس تمامًا. وقد يكون قرار طارئ مشروع بلا تراجع موثوق؛ عندئذ يجب أن يوقف غياب التراجع التنفيذ، لا أن يمحو سؤال السلطة.

كذلك لا تعني discard-changes دائمًا العودة إلى الإنتاج الحالي. يعود المرشح إلى نقطة إنشائه أو آخر تحديث له، أيهما أحدث، وقد تختلف تلك الحالة عن running الآن.

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

المصادر