الخلاصة

  • تقترح مسودة فردية على IETF ستة مسارات RDAP لبيانات سجل توجيه الإنترنت، لكنها تجعل دعم ثلاث فئات من الكائنات وعضو السياسات اختيارياً.
  • استجابة /help الحالية لدى RIPE NCC لا تعلن الامتداد irr0. لذلك يبدأ اختبار الخروج من Whois بفحص ما يقدمه كل خادم فعلياً، لا بعدّ المسارات في المسودة.

لافتة الخروج ما زالت تحمل نجمة

في اجتماع RIPE 93، قال مشغّل إن دعم كائنات السجلات الإقليمية للتوجيه هو آخر ميزة ينتظرها قبل أن يضع Whois جانباً. وصل الآن نص يقترحها. وما زالت النجمة الصغيرة في أسفل اللافتة: بعض ما يبدو في الرسم مساراً جديداً ليس مطلوباً من الخادم أن ينفذه.

نشر IETF Datatracker في 29 أكتوبر المسودة draft-aggarwal-regext-rdap-irr-00. تضم قائمة المؤلفين أربعة أسماء، بينها Mahesh Aggarwal من RIPE NCC وJasdip Singh من ARIN. عنوانها «امتداد RDAP لكائنات سجل توجيه الإنترنت». والفكرة محددة: إتاحة بيانات IRR عبر RDAP في JSON منظم فوق HTTPS، بدلاً من ترك العملاء يجمعون النتيجة من واجهات متفرقة.

تعرض المسودة ستة أجزاء لمسارات البحث: irr0_route وirr0_routeSet وirr0_autnumSet وirr0_rtrSet وirr0_peeringSet وirr0_filterSet. يحتاج البحث عن route إلى بادئة وعنوان ASN المنشأ. ويمكن لرد autnum أن يحمل سياسات الاستيراد والتصدير بترتيبها، بما فيها صيغ متعددة البروتوكولات وimport-via وexport-via.

ثم تأتي الفجوة مكتوبة بوضوح في النص نفسه. دعم peering-set وrtr-set وfilter-set متروك لتقدير المنفّذ. وعضو irr0_policies في رد autnum اختياري كذلك. يمكن للعميل أن يفهم المفردات الجديدة، ثم يكتشف أن الخادم لا يقدّم الفئة التي تعتمد عليها أداة تشغيل يومية. ستة أسماء في مسودة لا تعني ست خدمات عاملة.

ليس ذلك خلافاً تجميلياً على JSON. تقول ARIN إن قاعدة IRR لديها منفصلة عن بيانات Whois العامة: يرسل أصحاب الموارد كائنات RPSL، وتسترجعها سجلات أخرى لاستخدامها في قرارات التوجيه. وتذكر ARIN ثلاث وسائل للحصول على البيانات: المراقبة شبه الفورية NRTM، وتنزيل الملفات، وWhois على المنفذ 43. كما تصف بعض كائنات NRTM لديها بأنها «مصرح بها» وفق شروط تخص تسجيل الموارد والجهة التي تتولى صيانة الكائن. تنطبق هذه الصفة على تدفق NRTM الذي تصفه ARIN.

تسجل وثائق قاعدة RIPE حالياً أربعة أنواع RDAP: autnum وdomain وip وentity. واستجابة /help التي فُحصت تعلن امتدادات أخرى، لكن irr0 غير موجود فيها. هذا الفحص خاص بنقطة نهاية RIPE NCC؛ ويتطلب وضع ARIN والخوادم الأخرى اختبارات مستقلة. وتظل المسافة بين المسودة والخدمة قابلة للقياس.

وتحسم صفحة Datatracker صفة الوثيقة: هذه مسودة إنترنت فردية، لا تؤيدها IETF ولا تتمتع بمكانة رسمية في مسار المعايير. حالة IESG هي I-D Exists. الخطوة التالية ليست إضافة شكل آخر، بل أن يجيب كل مشغّل عن سؤال يمكن اختباره: أي كائنات أستطيع جلبها، وأيها غائب؟

صيغة موحدة لا تكفي وحدها

يمكن للمسار المشترك أن يقلل تعدد المحللات وأن يجعل شكل الرد مألوفاً. لكنه لا يحوّل سجل RPSL إلى حقيقة مستقلة عن مصدره. كائن route يصف تسجيل سياسة؛ لا يثبت أن بادئته معلنة حالياً في BGP أو أن الشبكات تقبلها. وإذا تغيّر ترتيب عناصر السياسة أو فقدت مجموعة أعضاءها أثناء التحويل، فقد بقي JSON سليماً وفشل الترحيل في أهم اختباراته.

تطلب المسودة من الخادم الذي يدعم الامتداد أن يعلن irr0 في rdapConformance وفي استجابة المساعدة. يستطيع العميل قراءة الإعلان، لكنه لا يستنتج منه دعم كل فئة. على المشغل أن يختبر الفئات واحدةً واحدة، ويقارن حقولها بمخرجات RPSL، ويتحقق من بقاء ترتيب السياسات والمراجع إلى الكيانات وأحداث التسجيل والتعديل.

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

تحتاج الهجرة إذاً إلى إيصال تنفيذ لكل خادم: الامتداد المعلن، وفئات الكائنات التي تجاوب، وما يحدث للحقول الاختيارية، والفروق عن سجل RPSL. حين لا تتوفر هذه المقارنة، يبقى مسار Whois أو الخلاصة القديمة جزءاً من التشغيل. التوقف عنها بعد نجاح استعلام route واحد يشبه إغلاق المستودع لأن الباب الأمامي يعمل.

في RIPE 93 دعا المشغّل زملاءه إلى التحقق من الكائنات التي يستخدمونها يومياً. هذا هو الاختبار الصحيح. «لدينا RDAP» إجابة عن البروتوكول. أما الخروج من Whois فيحتاج إلى دليل أن السجلات التي تعتمد عليها الأدوات وصلت كما هي.

المصادر