الخلاصة

  • يطلب RFC 1157، بعد اجتياز شروط الخطأ، تنفيذ إسنادات SetRequest كما لو أنها ضُبطت في وقت واحد بالنسبة إلى الرسالة. لا تثبت الاستجابة شخصاً بعينه، ولا التخزين الدائم، ولا اكتمال فعل قد تطلقه القيمة.
  • يفصل RFC 1905 بين التحقق والتعديل. خطأ التحقق لا يطبّق الإسنادات، أما commitFailed وundoFailed فيكشفان فشلاً وقع أثناء التعديل أو التراجع. لذلك لا يعني كل خطأ أن شيئاً لم يتغير.
  • ليس Marshall T. Rose مؤلفاً لـRFC 1157؛ مؤلفوه J. D. Case وM. S. Fedor وM. L. Schoffstall وJ. R. Davin. يرد اسم Rose في الشكر بصفته رئيس IETF SNMP Extensions Working Group، وشارك في تأليف وثائق SMI وMIB المبكرة.

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

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

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

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

تحتاج نسبة الأفكار إلى أصحابها للدقة نفسها. الأسماء الموقعة على RFC 1157 هي J. D. Case وM. S. Fedor وM. L. Schoffstall وJ. R. Davin. ليس Rose واحداً منهم. تذكره فقرة الشكر، وكان في The Wollongong Group، رئيساً لمجموعة IETF SNMP Extensions. أما RFC 1155، الخاص ببنية معلومات الإدارة وتعريفها، فقد كتبه Rose وKeith McCloghrie، وتحفظ وثائق MIB حدود التأليف الخاصة بها. يسجل ملف IETF عدداً كبيراً من أعمال Rose في إدارة الشبكات، وتذكر سيرته رئاسته لمجموعة SNMP ثم عمله مديراً لمجال إدارة الشبكات في IETF. الاعتراف بهذه الأدوار لا يحتاج إلى منحه توقيع وثيقة لم يوقعها.

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

بعد نجاح التحقق، يحاول الوكيل تطبيق الإسنادات كما لو كانت متزامنة. غير أن RFC 1905 يسمّي إخفاقات هذه المرحلة. يعني commitFailed أن إسناداً لم يكتمل، وعلى الوكيل محاولة إلغاء بقية التعديلات. ويعني undoFailed أنه لم يستطع ضمان استعادة الحالة السابقة بالكامل. تستدعي الأولى قراءة الحالة من جديد؛ وتفرض الثانية اعتبار الحالة مختلطة على نحو محتمل إلى أن يؤكدها رصد مستقل. إن تحويل كل خطأ إلى «رفض بلا أثر» يمحو هذا التحذير المهم.

ويحذر RFC 1905 أيضاً من تكرار المتغير نفسه بقيم مختلفة: يكون السلوك متعلقاً بالتنفيذ. لا تمنح القائمة الواحدة العميل ترتيباً محمولاً لطلب متناقض.

تقع الهوية والتفويض على أسطح أدلة متجاورة لكنها مستقلة. يفصل RFC 3411 بين معالجة الرسائل والأمن والتحكم في الوصول، ويعد SET الآمن من مسائل التطور الأساسية في SNMPv3. يستطيع USM في RFC 3414 توثيق هوية مبدأ بروتوكولي وحماية الرسالة. ويقيّم VACM في RFC 3415 نموذج الأمن واسمه ومستواه والسياق ونوع الرؤية واسم المتغير. تساعد هذه العناصر في إثبات المبدأ التقني الذي سمحت له سياسة بروتوكولية بالوصول. لكنها لا تعرّف تلقائياً الإنسان الذي استخدمه ولا التفويض المؤسسي الذي منحه حق التغيير.

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

Sources