الخلاصة

  • في RFC 2020 كان تسجيل إعداد ما يثبت النية؛ أما التدريب فكان يفصل الطلب عن النمط الذي قبلته الوصلة فعليًا.
  • كان للفصل أثر مادي: تنسيق الإطار الجاري يحدد MTU عند 1500 أو 4464 ثمانية، ولا تصبح ifOperStatus في وضع up إلا بعد وصول dot12Status إلى opened.

الكتابة ليست نهاية التغيير

اختارت dot12DesiredFramingType للتدريب التالي تنسيقًا متوافقًا مع IEEE 802.3 أو IEEE 802.5 أو أيًا منهما. أما dot12CurrentFramingType فأجابت عن سؤال آخر: ما التنسيق المستخدم الآن؟ حتى عندما يسمح الطلب بالخيارين، وجب على القيمة الجارية أن تستقر على تنسيق واحد.

ومن هذه النتيجة جاءت ifMtu: تساوي 1500 مع تنسيق 802.3 الجاري و4464 مع 802.5. قد يغيّر تعديل القيمة المطلوبة MTU بعد التدريب التالي، لكن قبول أمر SET لا يثبت أن التنسيق أو MTU قد تغيرا.

كما لم يكن شكل الإطار دليلًا على طريقة النفاذ. استطاعت IEEE 802.12 استعمال إطارات شبيهة بـ Ethernet أو Token Ring، لكنها استخدمت Demand Priority Access Method الخاص بها. لذلك رفضت RFC تطبيق MIB الخاصة بوصول Ethernet أو Token Ring لمجرد التشابه. والاستثناء أضيق: تنسيق Token Ring مع دعم فعلي للتوجيه بالمصدر.

التدريب هو حد الإثبات

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

فرّقت dot12Status بين الإغلاق، والفتح الجاري، والفتح المكتمل، وفشل الفتح، وفشل الوصلة. لا تكون ifOperStatus في وضع up إلا عند الفتح المكتمل. يمكن لأمر فتح أو إعادة ضبط أو تغيير تنسيق مطلوب أو نمط استقبالي أو دور تحكم أن يبدأ التدريب؛ لكنه لا يثبت اكتماله.

كرر النمط الاستقبالي العام البنية نفسها. حملت dot12DesiredPromiscStatus الطلب في حزمة التدريب التالية، وكان من حق الجهاز الرئيسي ألا يمنحه. تحديث ifPromiscuousMode يغيّر الرغبة ويبدأ إعادة التدريب، لكن القيمة بعده يجب أن تعرض النمط المستخدم لا المطلوب. وسجلت dot12LastTrainingConfig بتات آخر إطار تدريب خالٍ من الأخطاء.

وكلمة «رئيسي» وصفت دورًا بروتوكوليًا محدودًا: الطرف الذي يمنح العقد الطالبة إذن الإرسال. لم تثبت ملكية الجهاز أو سلطة تنظيمية أو وصول البيانات.

الحساب لا يثبت النتيجة

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

وكان حد الأمن صريحًا: لم تناقش الوثيقة مسائل الأمن. فالوصلة المفتوحة أو الإعداد المقبول لا يقدمان مصادقة أو سرية أو ضمانًا للتشغيل الآمن.

ساعتان وثائقيتان

لا تزال سجلات RFC Editor وIETF الحالية تصنف RFC 2020 بوصفها Proposed Standard، ولا تسمي RFC أبطلتها. ولم يُظهر بحث التصويبات نتيجة مطابقة في 11 سبتمبر 2026؛ وهذا وصف لقاعدة البيانات في ذلك اليوم.

أما IEEE فتصف IEEE 802.12-1995 اليوم بأنها Inactive-Withdrawn، وتسجل سحبها في 15 يناير 2001، وتضع مجموعة Demand Priority ضمن المجموعات المنحلة. هذه حالة لاحقة لوثيقة أخرى، وليست قياسًا للانتشار أو الأداء أو النجاح التجاري. تحويلها إلى حقيقة تشغيلية يكرر الخطأ الذي قاومته RFC.

المصادر