الخلاصة

  • قال Andy Clyde في RIPE 93 إن فريق Internet Society/Pulse يستخدم PeeringDB لتحليل نقاط التبادل، ويحتاج سجلات تعود إلى 2019 كي يعيد معالجة النتائج.
  • تحدد مسودة API v3 زمناً لوصول البيانات الحديثة، وتستثني الاستعلامات التاريخية من ذلك المقياس، وتطلب إعلان مدة حفظ البيانات القديمة من دون تحديدها بعد.

تستطيع واجهة جديدة أن تجيب بسرعة عن وضع اليوم، لكنها لا تعيد سجلاً لم يعد موجوداً. في جلسة PeeringDB ضمن RIPE 93 تحدث Andy Clyde من موقع الباحث في نقاط التبادل. استخدام فريقه للبيانات للقراءة والتحليل، وقدّر أن نقل العميل إلى الواجهة المقترحة قد يستغرق بضعة أسابيع. أما العودة إلى 2019 وإعادة الحساب فلا تحلها إعادة كتابة العميل وحدها.

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

تنص مسودة v3 الرسمية، المؤرخة في 18 سبتمبر، على واجهة عامة للقراءة فقط إلى جانب v2، وتحديث تدريجي ولقطات يومية. هدفها إظهار 99% من التغييرات الحديثة خلال دقيقة. وهي تستثني المرور على السجل التاريخي من هذا الهدف. كما تلزم PeeringDB بإعلان نافذة حفظ البيانات القديمة التي تقدمها، لكنها لا تعطي مدة محددة. وتبقى عناوين ملفات التفريغ الحالية كما هي في هذا العمل.

سؤال Clyde عملي: إلى أي تاريخ يستطيع الباحث الرجوع، وهل يستطيع بعد سنة أن يعيد التحليل بالمدخلات نفسها؟