الخلاصة

  • يضيف RFC 10016 إلى NMDA مخزن <system> المخصص لإعداد يوفره النظام ولا يستطيع العميل حذفه. ومع أن المخزن للقراءة فقط، يمكن للعميل الإشارة إلى عقده، وتجاوز بعض قيمه المسموح بها في <running>، وإضافة فروع قابلة للإعداد تحت عناصر أنشأها النظام.
  • يصف origin=system مصدر القيمة، ولا يثبت اعتماد إنسان لها أو ثباتها أو تطبيقها. حذف التجاوز قد يعيد القيمة المحجوبة إلى <intended>، كما أن تغير العتاد أو الترخيص أو الميزة أو البرمجيات قد يغير العقد الموجودة في <system>.

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

وصف الطلب حركة البيانات ولم يصف أثرها. يتيح RFC 10016 رؤية هذا الأثر بإضافة مخزن تقليدي إلى بنية NMDA لما يوفره الخادم من إعداد. لا يستطيع عملاء NETCONF وRESTCONF الكتابة مباشرة إلى <system>، لكن محتواه يظل من المدخلات التي تصنع الإعداد الفعلي.

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

مخزن واضح لمصدر كان مبهماً

تفرق NMDA في RFC 8342 بين الإعداد المقصود تطبيقه وبين الإعداد والحالة المستخدمين فعلاً، وتتعامل مع مصادر تقليدية وديناميكية ومتعلمة ونظامية وافتراضية. ويوضح RFC 10016 أن كل إعداد حاضر في <system> يعد إعداداً نظامياً، سواء استُخدم مرجعاً أو طُبق في تلك اللحظة أم لا.

لا يستطيع العميل حذف هذا الإعداد. لذلك لا تدخل ضمن التعريف بيانات يوفرها الخادم ويسمح للعميل بمحوها. ينفذ الخادم المتوافق هوية ietf-system-datastore فوق نماذج YANG التي يحددها RFC 7950. ويمكن للعميل اكتشاف الدعم من معلومات YANG Library الواردة في RFC 8525.

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

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

المصدر محمي، لكن الأولوية متحركة

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

قاعدة الدمج حاسمة: العقدة المطابقة في <running> تربح عند تكوين <intended>. وإذا لزم توسيع قالب أو إزالة إعداد غير نشط أو إجراء تحويل آخر، يتحول كل مخزن على حدة قبل الدمج. لذلك لا تكفي مقارنة شجرتين خام لتحديد القيمة الفائزة.

لنفترض أن النظام يقدم A وأن المشغل يكتب B في <running>. تربح B ما دامت موجودة. وعندما يحذفها المشغل لا يحذف A، إذ لا يملك صلاحية حذفها من <system>. تعود A إلى <intended> وقد تُطبق. ولهذا فإن حذف التجاوز اختيار لقيمة بديلة، لا امتناعاً عن الاختيار.

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

المصدر ليس توقيع موافقة

يحدد RFC 7952 آلية البيانات الوصفية المستخدمة في تعليقات المصدر. ويوضح RFC 10016 أن الإعداد الآتي من <system> يحمل المصدر system ما لم يُضبط صراحة أو يُتجاوز في <running>. أما ما نشأ في <running> فيتبع قواعد المصدر في NMDA.

يجيب التعليق عن سؤال «أي جهة قدمت هذه العقدة؟»، ولا يجيب عن «من قبل أثرها؟». قد تأتي القيمة من صورة المنصة أو نظام الترخيص أو مدير الموارد أو عملية محلية، من غير قرار بشري حديث. وفي المقابل قد تكون الكتابة في <running> ناتج متحكم آلي لا فعل مشغل بعينه.

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

النية الصحيحة لا تثبت التطبيق

يلزم RFC 10016 الخادم بتحديث <intended> والتحقق منه فور كل تغير في <system>. ويقول أيضاً إن <running> ينبغي أن يبقى شجرة إعداد صحيحة بعد تغير النظام، لكنه يترك آلية تحقيق ذلك خارج النطاق. هذه ضمانات لمعالجة البيانات، وليست إثباتاً لوصول القيمة إلى العتاد.

لا يغير RFC معنى <operational>. وفي إطار RFC 8342 قد تفصل الموارد الغائبة وتأخر الانتشار والفشل والحالة المتبقية بين النية والواقع. فالسلسلة تحول <system> و<running> كل واحد مستقلاً، ثم تدمجهما في <intended>، وبعد ذلك تطبق النتيجة بشروط في <operational>. ولكل سهم عطل ودليل مختلفان.

يمكن الإبلاغ عن التغييرات عبر اشتراكات YANG وتحديثات المخازن التي يصفها RFC 8639 وRFC 8641. يثبت الحدث أن الناشر أرسله ضمن مجال الاشتراك. ولا يثبت وحده أن كل مستهلك عالجه وأعاد حساب سياسته وفحص الشجرة التشغيلية.

ولا ينبغي الخلط بين <system> و<factory-default>. يعرف RFC 8808 مخزن إعداد المصنع وعملية استعادته. أما <system> فيصف ما يوفره النظام الحالي في ظروفه الحالية. قد تتشابه بعض القيم، لكن الدور والزمن مختلفان.

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

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

ثم يسجل قابلية التغيير والدمج: هل التجاوز مسموح؟ أي عقدة في <running> تشير إلى المصدر أو تحجبه؟ ما الفروع التي أضافها العميل؟ ما التحويل الذي جرى على كل مخزن؟ وأي قيمة دخلت <intended>؟ قبل اعتماد حذف تجاوز، تظهر القيمة التي سيكشفها الحذف.

يقارن قسم التفعيل بين <intended> و<operational>، ويسجل وقت التطبيق وحضور المورد والتأخر والفشل والحالة المتبقية والمشاهدة الدقيقة التي بُني عليها القول إن القيمة سارية. قد يكون المرجع صحيحاً فيما المورد غير نشط، وقد تكون شجرة النية صحيحة فيما العتاد غائب.

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

هذا الإيصال اقتراح تحريري للحوكمة من Daniel Kade، وليس التزاماً جديداً يفرضه RFC 10016. غايته أن تبقى الجهة الظاهرة والقيمة الفائزة والقرار المعتمد والنتيجة المطبقة أربع حقائق منفصلة.

الأمن يبدأ بحق القراءة

لا تعني القراءة فقط أن البيانات غير مؤذية. يحذر RFC 10016 من أن <system> قد يكشف معرفات العتاد وسياسات أمنية وموارد حرجة. يجب تقييد الوصول إلى العقد والفروع الحساسة وتسجيل محاولات قراءتها. يقدم RFC 8341 نموذج NACM لضبط وصول مستخدمي NETCONF وRESTCONF.

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

يعطي RFC 10016 طريقة معيارية لرؤية إعداد النظام والتفكير فيه. لكنه لا يحول اختيار الآلة إلى نية المشغل، ولا يثبته إلى الأبد، ولا يصدق على تطبيقه. تبدأ السيطرة بالرؤية، وتكتمل بإثبات الأولوية والحالة التشغيلية.

المصادر