الخلاصة

  • سجّلت IANA مساحة اسم لصيغة XML الواردة في RFC 5345. ينسّق التسجيل هوية المفردات ومرجعها، لكنه لا يثبت اعتمادها أو صحة محلل أو اكتمال التقاط أو ملاءمة بحث. والوثيقة نفسها معلوماتية من IRTF وليست مرشحة لأي مستوى من معايير الإنترنت.
  • تبدأ الحجة الموثوقة بموضع المجس وتغطيته، ثم pcap الخام، وسياسة checksum وإعادة التجميع، والتحويل إلى XML أو CSV، والترشيح وإخفاء الهوية، وإصدار كود التحليل. فقدان أي طبقة يحد ما يمكن للنتيجة أن تدّعيه.

وظيفة السجل أضيق من وظيفة الشهادة

عندما تسجل IANA معرفاً، تمنع التباساً في فضاء الأسماء وتربطه بمواصفة عامة. يستطيع برنامج أن يرى URI ويعرف أي قاموس يقصده الملف.

لا يقول السجل إن الملف صحيح نحوياً، ولا إن محتواه جاء من حزم كاملة، ولا إن المحلل نفّذ القواعد كما ينبغي. ولا يقيس عدد المشغلين الذين استعملوا الصيغة.

حتى الملف المطابق للمخطط قد يكون مشتقاً من مجس لم ير إلا VLAN واحداً. وقد يكون قد حذف قيماً لازمة للسؤال. وقد ينتج تحليلاً خاطئاً بكود صحيح نحوياً.

لهذا يجب أن تبقى عبارات التنسيق منفصلة: «الاسم مخصص» غير «الصيغة مطبقة»، و«الصيغة مطبقة» غير «البيانات كاملة»، و«البيانات كاملة ضمن المجس» غير «النتيجة التشغيلية صحيحة».

حالة الوثيقة تمنع تضخيم السلطة

نُشر RFC 5345 بوصفه وثيقة معلوماتية نتجت داخل NMRG في IRTF. تقول ملاحظة IESG إنه ليس مرشحاً لأي مستوى من معايير الإنترنت، وإن النشر لا يعني أن IETF حكمت بملاءمته لأي غرض.

تلك العبارة لا تقلل قيمة المنهج. إنها تمنع تحويله إلى التزام عالمي أو ختم ضمان.

يمكن للوثيقة أن تعرّف طريقة جمع وتبادل وأن تقترح أسئلة بحث. لا يمكن أن تكون دليلاً بذاتها على ممارسة حالية أو نسبة انتشار أو جودة منتج بعينه.

إذا أراد تقرير ادعاء الانتشار، فعليه إظهار ملفات أو إعدادات أو دراسات تشغيلية. وإذا أراد ادعاء الدقة، فعليه إظهار اختبارات وإعادة إنتاج.

المجس يسبق الصيغة

قبل XML توجد نقطة مراقبة. يطلب RFC اختيار موضع الالتقاط بعناية، ولا سيما في الشبكات المبدلة، والتأكد من وصول VLANات الإدارة اللازمة إلى المجس.

إذا منع switch نسخ بعض الحركة، فلن تستطيع أي صيغة لاحقة استعادتها. وإذا اقتصر filter على UDP 161 و162، فقد يصف الحالة المعتادة دون أن يثبت عدم وجود نقل آخر.

يجب التقاط الحزمة كاملة. القطع قد يبقي الرأس ويحذف القيمة. الخسارة تحت الضغط قد تحذف الذروة نفسها التي يريد البحث قياسها.

الغياب في ملف يعني فقط أن record مطابقاً لم يدخل هذا المسار. تحويله إلى «لم يقع الحدث» يحتاج تغطية موثقة.

أسبوع كامل لا يساوي الزمن الكامل

يوصي RFC بأسبوع على الأقل لالتقاط دورات يومية وأسبوعية، ويشجع مدة أطول. هذه نصيحة تصميم عينة.

لا يشمل الأسبوع تلقائياً صيانة شهرية أو حادثاً نادراً أو عملية ترقية أو تغيراً موسمياً. يجب أن تسجل metadata الأحداث المعروفة والأعطال والتغييرات خلال الفترة.

من دون هذا السياق، انخفاض polling قد يبدو تحسناً بينما كان نظام الإدارة متوقفاً. ارتفاع trap قد يبدو سلوكاً عادياً بينما كان نتيجة اختبار.

الزمن الذي تسجله الحزمة أيضاً ليس بالضرورة زمن تحديث الأداة الداخلية. قد يحدّث agent counters وفق خوارزمية تكيفية.

checksum قد يصف نقطة الالتقاط لا السلك

يمكن لنظام التشغيل أن يؤجل حساب checksum إلى NIC. يلتقط البرنامج الحزمة قبل ملء القيمة النهائية، فتبدو تالفة محلياً وهي صحيحة عند الإرسال.

يقترح RFC تعطيل offload أو تصحيح checksum أو تجاهله أثناء التحويل. لكل اختيار أثر إثباتي مختلف.

يجب تسجيل الإعداد والإصدار وعدد التصحيحات. وإلا قد يظهر تحديث tool كأنه انخفاض في فساد الشبكة.

وتتطلب fragmentات IP إعادة تجميع. فشل إعادة التجميع أو نقص fragment ليس دليلاً تلقائياً على أن agent أرسل PDU غير صالح.

pcap الخام يحفظ إمكانية المراجعة

يوصي RFC بحفظ pcap الأصلي مع XML وCSV. قد يظهر bug في converter بعد نشر النتيجة، أو يحتاج السؤال الجديد حقلاً لم تحتفظ به الصيغة المختصرة.

العودة إلى bytes التي رآها المجس تسمح بإعادة بناء الطبقات الوسيطة. أما الاكتفاء بمشتق فيجعل قرار التحويل القديم المصدر الوحيد للماضي.

pcap ليس مرآة كاملة. لا يحتوي ما لم يره المجس أو ما أسقطه filter أو ما وقع خارج الزمن.

كما أنه حساس: community strings وأسماء المستخدمين والعناوين والقيم والطوبولوجيا. قد تفرض القوانين أو حماية المشغل حذفه. عندئذ ينبغي إعلان أن بعض التحقق أصبح مستحيلاً، لا الادعاء بأن CSV حل محله.

XML وCSV عقدان مختلفان

صُمم XML ليحتفظ بتفاصيل SNMP المهمة وبعض معلومات طول ASN.1/BER. أما CSV فاختار حقولاً محددة ليكون أصغر وأسرع.

يصرح RFC بأن CSV لا يحفظ المعلومات اللازمة لفهم traps من SNMPv1. يمكن تحويلها وفق RFC 3584، لكن تشغيل التحويل خيار للمستخدم ويجب تسجيله.

بعد التحويل يصبح record مفيداً للمقارنة مع traps أحدث، لكنه ليس التمثيل الأصلي. خلط converted وnative بلا علامة يجعل سياسة الأداة تبدو تغيراً في الجهاز.

صلاحية CSV أو XML تعني أن النص يطابق عقداً. لا تعني أن السؤال البحثي يناسب الحقول المحتفظ بها.

الإخفاء يحمي ويغيّر

تحمل traces معلومات حساسة في headers والقيم وinstance identifiers وmetadata موضع المجس. يوصي RFC بإخفاء القيم أو حذفها قبل المشاركة وبحماية الأرشيف.

مبدأ filter-in يقول إن القيمة تبقى فقط عندما يعرف نوعها ويوجد تحول مناسب. الجهل ببنية القيمة ليس دليلاً على أمانها.

قد يحتاج التحليل إلى الحفاظ على الترتيب المعجمي لفهارس الجداول. التحولات التي تحفظه أقل قوة في الإخفاء عادة، لأن البنية المتبقية تساعد الربط.

وترتبط التحولات بمفتاح ودفعة. مجموعتان أخفيتا مستقلاً لا تملكان بالضرورة فضاء pseudonym واحداً. دمجهما بمساواة السلاسل قد يخلق هوية وهمية.

ينبغي أن تصف provenance الحقول المحذوفة، والخوارزمية، ونطاق المفتاح، والثوابت الباقية، والروابط المسموح بها.

عداد بلا discontinuity قد يروي قصة خاطئة

عدادان صحيحان لا يضمنان rate صحيحاً. قد يحدث reset أو wrap أو استبدال interface بينهما.

يشير RFC إلى sysUpTime وifCounterDiscontinuityTime. حذفهما ثم طرح القيمتين ينقل فرضية الاستمرارية إلى الرقم النهائي.

وقد لا يكون counter محدثاً لحظة الطلب. capture timestamp وقت استلام القيمة، لا برهاناً على لحظة القياس الفيزيائي.

وكذلك error-status=0: هو field في استجابة protocol. لا يثبت أن change بقي بعد restart، أو أن actuator تحرك، أو أن إنساناً مخولاً أمر به.

السلسلة المطلوبة أوسع من اسم الصيغة

لنتيجة قابلة للدفاع يجب ربط:

  1. السؤال والسكان المستهدفين؛
  2. موضع المجس وVLAN والاتجاه؛
  3. filter وsnap length والخسارة والزمن؛
  4. hash pcap وسياسة الاحتفاظ؛
  5. checksum وreassembly؛
  6. converter وschema؛
  7. filter/anonymization؛
  8. كود التحليل؛
  9. denominator وعدم اليقين؛
  10. دليل مستقل على الحالة أو السلطة.

اسم IANA يقع في البند السادس فقط. إعطاؤه سلطة البنود كلها هو الخطأ الذي يجب أن يمنعه التقرير.

المصادر