الخلاصة

  • لم يكن ترحيل RIPE NCC تبديلًا واحدًا للصيغة: بدأ تشغيل النسخة الجديدة في 23 أبريل 2001، ثم صار auto-dbm مخصصًا لـRPSL في 14 مايو، وانتهى تحويل RIPE-181 في 15 أكتوبر.
  • تربط الأرشيفات Andrei Robachevsky بالعمل بصفته مدير مجموعة قواعد البيانات: شرح خصائص الاستعلام الجديدة في 2000، ووقّع في أبريل 2001 إعلان اكتمال المرحلة الأولى.
  • تحويل كائن مسجّل يغيّر كيفية حفظه وقبوله في السجل، لكنه لا يثبت وحده ملكية مورد عناوين، أو إعلان مسار BGP حالي، أو الطريق الذي تسلكه الحزم.

ترحيل على مراحل لا يراه المستخدم بالطريقة نفسها

أوضح إعلان 14 مايو أن auto-dbm لن يقبل بعد ذلك إلا RPSL. ومن أراد إرسال تحديث RIPE-181 كان عليه استخدام auto-181 لتحويله، مع موعد إغلاق محدد في 15 أكتوبر. كما استمر auto-rpsl في قبول RPSL، وطُبّق التقسيم نفسه على قاعدة الاختبار.

لهذا لم يكن السؤال التشغيلي مجرد «هل انتقلت قاعدة البيانات؟». كان على المسؤول معرفة الصيغة التي تنتجها كل أداة، والعنوان الذي ترسل إليه التحديث، وقواعد التحقق هناك، والمدة المتبقية لمسار التوافق. لا تحدد المصادر عدد البرامج التي لزم تعديلها ولا تقول إن كل مستخدم واجه انقطاعًا. لكنها توضح أن العناوين والصيغ والمهل كانت معلنة بحيث يستطيع المشغّلون مراجعة إعداداتهم.

وفي رسالة مؤرخة في 23 أبريل، أفاد Robachevsky بأن النسخة الجديدة تعمل وأن جميع الكائنات حُوّلت آليًا إلى RPSL ثم حُمّلت. لم يكن ذلك يعني أن كل مسارات الإدخال قُيّدت فورًا بالصيغـة الجديدة. ففي المرحلة الأولى ظل auto-dbm يقبل RIPE-181 بشروط: تُرفض السمات الفارغة أو المكتوبة خطأ، ولا يدعم هذا المسار مصادقة PGP، مع استمرار تطبيق قواعد تفويض RPSL. أما auto-rpsl فكان يقبل الصيغة الجديدة مباشرة. شمل التغيير تمثيل السجلات وطريقة الإذن بتحديثها.

صيغة الاستعلام تحدد ما يظهر للمستخدم

في أغسطس 2000، قدّم Robachevsky، المعرّف بصفته مدير مجموعة قواعد البيانات، وظائف واجهة الاستعلام v3 وطلب ملاحظات المجتمع. الاستعلام المطابق تمامًا يعيد الكائن الذي يطابق المجال المدخل؛ أما الاستعلام الأقل تحديدًا فيعيد أصغر مجال أوسع يحتويه. تقلل -K الرد إلى المفاتيح الأساسية. ويعرض استعلام المصادر معلومات قواعد البيانات والنسخ المتزامنة، ومنها نطاقات الأرقام التسلسلية المتاحة؛ كما تبحث الاستعلامات العكسية في سمات جهات الاتصال.

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

تسجل مسودة محضر مجموعة قواعد البيانات لاجتماع RIPE 38 عرضًا من Robachevsky مدته عشرون دقيقة عن الترحيل. وتذكر مستخدمي الاستعلام، ومستخدمي التحديث، والنصوص الآلية، والمرايا شبه الآنية ضمن الجهات المتأثرة بـRPSL والتحكم في الوصول وصيغة القاعدة وبروتوكول النسخ. الصفحة موسومة صراحة بأنها مسودة؛ لذا فهي دليل على ما سجّلته هذه النسخة من المحضر عن الجلسة، لا برهان منفرد على أن كل موعد لاحق تحقق. وتُستخدم الإعلانات اللاحقة والتقرير السنوي لإثبات اكتمال الانتقال.

التوافق له كلفة وموعد نهاية

يصف التقرير السنوي لـRIPE NCC لعام 2001 التحول بأنه استغرق ستة أشهر، من 23 أبريل إلى 15 أكتوبر. خلال تلك المدة، شغّلت المؤسسة التحويل وأعلنت القواعد؛ وكان على مديري الكائنات مراجعة أدوات التحديث، وعلى مشغلي المرايا التحقق من الصيغ والمزامنة، وعلى مطوري العملاء استيعاب دلالات الاستعلام الجديدة. لا تحصي المصادر ساعات العمل أو كلفته على كل مشارك ولا تسرد كل برنامج تأثر. لكنها تبين نقاط التحكم المؤسسية: الصيغة المقبولة، والتحقق من الصلاحيات، والعناوين، وتاريخ إغلاق جسر التوافق.

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

وتوضح RFC 2622 حدًا آخر. فهي تعرّف RPSL لغةً لوصف سياسات التوجيه، وتشرح دور كائن maintainer في تفويض تحديثات قاعدة البيانات. وتدرج أسماء Alaettinoglu وVillamizar وGerich وKessens وMeyer وBates وKarrenberg وTerpstra مؤلفين؛ ولا يظهر Robachevsky بينهم. لا يصح تحويل مشاركته الموثقة في الترحيل إلى ادعاء بأنه ألّف اللغة أو RFC 2622.

التسجيل ليس إعلانًا حيًا

كائن RIPE Database، وكائن سياسة في Internet Routing Registry، وملاحظة BGP تجيب عن أسئلة مختلفة. يبين الكائن المحوّل ما كانت قاعدة البيانات تحتفظ به آنذاك. ويصف كائن RPSL سياسة مسجلة. وقد يبين مجمّع المسارات أن نقطة رصد معينة شاهدت إعلانًا في وقت محدد. لا يحل واحد منها محل الآخرين. فالتسجيل وحده لا يثبت إمكانية الوصول الآن، أو تسليم الحزم، أو الملكية القانونية، أو التزام كل موجّه بالسياسة المدونة.

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

ما الذي يمكن نسبته إلى Robachevsky؟

في أغسطس 2000 وقّع Robachevsky رسالة مجموعة العمل بصفته مدير مجموعة قواعد البيانات وشرح استعلامات v3. وفي أبريل 2001 وقّع إشعار المرحلة الأولى الذي وصف التحويل الآلي والقيود المؤقتة لمسار RIPE-181. كما سمّته مسودة محضر RIPE 38 متحدثًا مخططًا له. هذه أدلة على مدير تواصل بشأن انتقال تقني وطلب آراء المستخدمين؛ وليست دليلًا على أنه كتب برنامج التحويل، أو قرر كل قاعدة منفردًا، أو راجع كل كائن.

تشغيل بنية عامة تحفظ السجلات يستتبع مسؤولية عن إتاحة متوقعة وتغييرات قابلة للتتبع. لكنه لا يمنح المشغّل ملكية ما يسجله. تدعم الوثائق بقوة التواريخ والواجهات والصيغ؛ ولا تحدد كلفة كل مشارك، أو اكتمال انتقال جميع المستخدمين، أو حالة أي مسار اليوم.

المصادر