الخلاصة

  • وصفت ICANN، في إخطار 25 سبتمبر 2026، عدم دفع Netpia.com, Inc. رسوم الاعتماد بأنه إخلال جوهري وأساسي. ووضعت متطلبات خدمة RDAP ورابط آلية طلب كشف البيانات في موضعين منفصلين من عدم الامتثال.
  • يتيح RDAP الاستعلام عن بيانات التسجيل الواجب نشرها؛ أما الصفحة المرتبطة من الواجهة الرئيسية فتشرح كيفية طلب النظر في بيانات غير عامة، ولا تمنح موافقة آلية على كشفها.
  • طلبت ICANN المعالجة بحلول 16 أكتوبر، وقالت إنها قد تبدأ إجراءات إنهاء الاعتماد إذا لم تتحقق المعالجة والرد. الإخطار نفسه ليس قرار إنهاء.

قد تسدّد شركة التسجيل دينها المستحق وتبقى أمام مستخدميها بوابتان غير محسومتين. الأولى آلة الاستعلام التي ينبغي أن تعيد بيانات عامة عن أسماء النطاقات التي ترعاها. والثانية تعليمات يتبعها من يطلب بيانات حُجبت عن النشر العام. في حالة Netpia، صاحبة الرقم 130 لدى IANA، يستدعي الإخطار اختبار كل بوابة بدليلها، لا الاكتفاء بإشارة محاسبية واحدة.

تحدد صياغة ICANN نطاق ما قررته. فعدم دفع رسوم الاعتماد، خلافاً للبند 3.9 من اتفاقية الاعتماد، هو الإخلال الذي سمّته «جوهرياً وأساسياً». ثم قالت إن الشركة عُدّت غير ممتثلة لمتطلبات دليل RDAP ولشرط وجود رابط مباشر على صفحتها الرئيسية يشرح آلية طلب كشف بيانات التسجيل غير العامة. وتوجد سبع مسائل أخرى تتصل بمعلومات الموقع والاتفاق تحت عنوان مستقل هو «Additional Concerns». لا ينبغي تجاهلها، لكن لا يجوز أيضاً دمجها جميعاً في وصف الإخلال المالي المحدد. أهمية الحالة هنا ليست زيادة عدد المخالفات في العنوان؛ بل التمييز بين نوعين من الوصول يحتاج كل منهما إلى تشغيل وإثبات.

في الجانب العام، تشير الرسالة إلى أن Netpia سجّلت rdap.ibi.net عنواناً أساسياً لخدمة RDAP. وتقول ICANN إن نظام مراقبتها SLAM رصد حالات تعطل متقطعة مع نتائج «down» متكررة أثناء الفترات المتأثرة، بحيث تفشل استعلامات النطاقات التي ترعاها الشركة حين تكون الخدمة متوقفة. هذا وصف ICANN لا قياساً مستقلاً أجرته BTW؛ ولا تعرض الرسالة مدة انقطاع إجمالية أو عدداً للنطاقات المتأثرة. لذلك تطلب ICANN دليلاً على إتاحة استعلام عام مجاني عن بيانات محدّثة لجميع أسماء gTLD النشطة التي ترعاها Netpia، وتطبيق دليل التنفيذ الفني وملف الاستجابة الصادرين في فبراير 2024، وتقديم اسم نطاق ترعاه الشركة لأغراض المراقبة. أصبح هذا الإصدار من الملف مطلوباً منذ أغسطس 2025. نجاح استعلام واحد لا يثبت استمرار الخدمة أو شمولها.

أما بوابة الطلب فلا ينبغي تحويلها إلى منفذ لنشر البيانات المحمية. توجب المادة 10.1 من سياسة بيانات التسجيل رابطاً مباشراً من الصفحة الرئيسية إلى شرح آلية طلب الكشف، بما في ذلك صيغة الطلب ومحتواه، ووسيلة الرد، والمدة المتوقعة. تقول ICANN إن هذه المعلومات لم تكن منشورة في الصفحة الرئيسية التي فحصتها. إضافة الرابط تجعل المسار قابلاً للعثور عليه؛ لكنها لا تحسم استحقاق كل طلب. تنص السياسة على النظر في الطلبات المستوفية بحسب مبرراتها، والرد عليها، مع بيان أسباب الرفض إن حدث. هكذا يبقى الوصول المنظم ممكناً من دون اعتبار البيانات غير العامة متاحة للجميع.

حدد الإخطار 16 أكتوبر 2026 موعداً لدفع الرسوم وإظهار امتثال RDAP ونشر رابط الطلب وتقديم عناصر أخرى. وإذا لم تُعالج المسائل ولم تصل المعلومات المطلوبة في الوقت المناسب، قالت ICANN إنها قد تبدأ إجراءات الإنهاء. كلمة «قد» تمنع تقديم النتيجة بوصفها واقعة منجزة. ويسجل التسلسل الزمني في الملحق ردوداً من Netpia اعتبرتها ICANN غير كافية؛ فلا يصح الزعم بأنها لم ترد قط. ولا تثبت الرسالة تسريب بيانات خاصة أو ضياع طلب كشف معين.

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

المصادر