الخلاصة

  • نقل RFC 3737 مسؤولية تخصيص جذور وحدات MIB المستقبلية لـRMON من مجموعة العمل إلى IANA، لكنه أبقى معرّفات OID المسندة سابقاً كما هي.
  • رسم حداً ضيقاً: تخصص IANA جذر MODULE-IDENTITY تحت rmon؛ أما مؤلفو الوحدة ومحرروها فيخصصون معرّفات الكائنات العادية داخلها.

قائمة كانت تعمل، إلى أن جاءت التصحيحات المتأخرة

تراكمت وحدات MIB الخاصة بالمراقبة عن بُعد تحت العقدة rmon في شجرة MIB-II، عند 1.3.6.1.2.1.16. وكانت مجموعة RMONMIB تحتفظ بقائمتها الخاصة لتخصيص الوحدات الجديدة. لا يصف RFC 3737 هذا الترتيب بأنه فشل؛ بل يقول إنه عمل على نحو معقول. لكن بعض الأخطاء لم تُصحح إلا في مرحلة متأخرة، وأصبحت بعض التخصيصات مهجورة. كما اختلفت الممارسة عن المسار المعتاد الذي يحصل فيه معيار MIB على جذره عند نشر RFC.

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

تلقت IANA الجذر، لا الوحدة بأكملها

نقل RFC 3737 سجل التخصيص إلى سجل SMI Numbers وطلب من IANA صيانته. ومنذ ذلك الحين، تخصص IANA جذور MODULE-IDENTITY فقط تحت rmon. ويواصل مؤلفو الوحدات ومحرروها تخصيص معرّفات OID العادية داخل كل وحدة وفق إجراءات MIB المعتادة. وكان RFC 2434، الساري حينها، يشترط Standards Action للجذر الجديد؛ وتخصص IANA الرقم عند نشر RFC.

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

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

المصادر