الوكيل يدعم الوحدة، لكنه لا يفوّض التغيير: RFC 1303

الخلاصة

• يربط RFC 1303 وصف MODULE-CONFORMANCE لمجموعات MIB والتغييرات المعلنة فيها بـ sysObjectID للوكيل كي تختار محطة الإدارة تفاعلاً متوافقاً.
• الاسم والبنية النحوية وحالة التنفيذ ومستوى الوصول سجلات مختلفة؛ ويقول النص صراحة إن الوصول ذي المعنى بروتوكولياً مستقل عن سياسة التفويض الإداري.
• لا يثبت وصف القدرة، أو شكل الكتابة، أو رد الوكيل، هوية صاحب القرار أو الإذن أو نجاح التغيير أو بقائه أو أثره التشغيلي.

التحليل

الوصف يحدد الحوار ولا يملك العاقبة

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

تتيح MODULE-CONFORMANCE للمُنفّذ أن يصف مستوى الدعم ويربطه بـ sysObjectID. تقرأ المحطة المعرف، وتستشير قاعدة وصف، ثم تضبط سلوكها. وتكشف SUPPORTS وINCLUDES وVARIATION عن الوحدة والمجموعات والاختلافات. هذه فائدة توافقية محددة: معرفة أي سؤال يمكن أن يكون سؤالاً بروتوكولياً صالحاً.

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

المعنى في البروتوكول ليس الإذن في المؤسسة

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

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

كما تفرق الوثيقة بين SYNTAX للقراءة وWRITE-SYNTAX للكتابة عندما يحضران معاً. ويعرض المثال كائنات غير متاحة، وكائناً للقراءة فقط، وقيم قراءة لا تطابق قيم كتابة. ما نراه ليس بالضرورة ما يجوز استبداله؛ وما يمكن صياغته ليس بالضرورة ما يجيزه المسؤول؛ وما يقبله الوكيل ليس بالضرورة ما غيّر الخدمة.

اكتمال الطلب ليس اكتمال القرار

تسمي CREATION-REQUIRES القيم التي يجب تعيينها بعملية SNMP Set قبل أن ينشئ الوكيل مثيلاً لصف. وإذا غابت، فالوكيل لا يدعم ذلك الإنشاء عبر SNMP. هذه قاعدة عن اكتمال مرشح للواجهة، لا عن قرار تشغيل الشبكة.

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

المصادر

• RFC 1303 — A Convention for Describing SNMP-based Agents

RFC 1303 دليل على اصطلاح لوصف وكلاء SNMP عام 1992، وليس دليلاً على وكيل حقيقي أو تفويض أو Set ناجح أو إعداد دائم أو نتيجة شبكة.